八雲文庫ブログ

組版できる新感覚の小説・画像投稿サイト「八雲文庫」の運営日誌です。

【2018年6月版】プレゼンテーション共有サービス『Speaker Deck』の使い方

2018年6月4日にGithubMicrosoftに買収されたニュースが世間(主にIT界隈の人たち)を賑わせていますが、実は当ブログで解説記事を投稿した以下のサービスに関してもひっそりと大きな変更がありました。

yakumobooks.hatenablog.jp

なんと当ブログでも使っていたプレゼンテーション共有サービス「Speaker Deck」の運営会社がGithubからFewer and Faster社に移り、デザインが劇的に変わりました。また、スライドもモバイルから見やすくなる対応が入ったようです。サイト全体のデザイン変更に伴い前回撮ったキャプチャがほぼ全て使い物にならなくなってしまったため、まだ把握しきれているわけではありませんが簡単な違いも含めて新しい記事として今回再度ご説明させて頂きます。以前のデザインやSpeaker Deckの基本的なサービス内容を知りたい方は前回の記事をご参照ください。

Speaker Deckにログインする

サイト全体が黒を基調としたものから白ベースのデザインになりました。ログインやアカウント作成への導入は以前と同様右上にボタンが配置されています。また、Githubのアカウントを持っていればすぐにログインできるのも変わりません。

f:id:yakumobooks:20180608232517p:plain

ただ、アカウント作成画面の右下に「このサイトキーは非表示のキャプチャで無効になっています。」と書かれたreCAPTCHAのダイアログが見えるのですが理由は不明です...。

f:id:yakumobooks:20180608232713p:plain

スライドをアップロードする

タイトルバー右上の「Upload a deck」からアップロード画面に移動します。

f:id:yakumobooks:20180608232827p:plain

アップロード画面では点線のエリアにファイルをドラックアンドドロップするか、クリックしてファイル選択ダイアログを表示することでPDFをアップロードします。スライドだけではなく投稿フォームもモバイル対応したようで、全体的に縦に長いデザインとなりました。CSSデザインには主にBootstrap 4が使われているようです。

f:id:yakumobooks:20180608232928p:plain

タイトルを決める

公開するかどうかの選択はチェックボックスから「Draft(下書き)」「Published(公開)」ボタンに変わりました。

f:id:yakumobooks:20180608232959p:plain

日本語タイトルの場合スライドのURLがローマ字になるのは前回と変わらないようです。URLにこだわりがある場合は以下のようにスラッシュの後ろにURLにしたい文字列を指定してください。

サンプル

https ://speakerdeck.com/yakumobooks/sanpuru

サンプル / Sample

https ://speakerdeck.com/yakumobooks/sample

スライドを共有する

スライド自体に埋め込みURLやシェアボタンがつきました。シェアボタンはFacebookボタンが欠けた状態で表示されるので今現在不具合があるかもしれません。また、スライドのURLにリクエストパラメーター「?slide=1」がついたことでページ指定でスライドを埋め込んだりシェアできるようになりました。(以前からできていたらすみません)

f:id:yakumobooks:20180608233327p:plain

スライドを管理する

アカウント名のプルダウンにある「My decks」で投稿したスライドの一覧を表示できます。公開されていないスライドにつくマークは「PRIVATE」から「DRAFT」に変更されました。

f:id:yakumobooks:20180609001058p:plain

「DRAFT」のものはURLを入力しても見ることはできません。前回はNot FoundページにGithubのマスコット「Octocat」が表示されましたが、現在はシンプルに「見つかりませんでした」と表示されます。

f:id:yakumobooks:20180609001104p:plain

OctocatはSpeaker Deckに大々的に出ていたわけではありませんが、マスコットが去ってしまうのは少し寂しい気もします。

f:id:yakumobooks:20180609002951p:plain:w250
Octocat


さて、簡単な変更点は以上となりますが、当然ですが埋め込みURLは以前同じものが利用できますので今回の更新で既存の記述に影響はありません。Githubの買収に関しては自分には影響はないだろうと思っていましたが、まさかのSpeaker Deckの移管とデザイン変更で非常に驚きました。運営元が著名で信頼のあるGithubから変わってしまいましたが、このタイミングでデザインを変えるだけではなくモバイル対応するなどスピード感のある戦略を取っていますので、今後も期待して見守っていきたいと思います。

Scalaで作ったWebサービス 電子書籍型投稿小説サイト「八雲文庫」

AWSの利用料を定期的にSlackに通知する仕組みをTerraformで自動構築

サービスを運営しているとどうしても気になるのが運営費。特にクラウドサービスを使っていると料金体系が従量課金なので時間/日単位で請求額が増えるので気がつくと予定以上の支払いとなることもあります。自分としては現状気にする程ではないのですが、最近使い始めたSlackに定期的に通知してくれる機能があればなぁ、ということで自作することにしました。自作したもう1つの動機としてはFaaS(Function as a Service)が様々な用途での発展が期待できそうなので今後も見据えて触れておきたかったという気持ちも大きかったりします。

github.com

Githubの方に説明は書いていますがGoogle翻訳に頼りきった拙い英語なので改めて記事の中で解説します。Githubで公開したソースはあくまでAWSの利用料のみ通知する仕組みにしていますが、実際自分で使っているものはAWS以外のサービスの利用料も取得して併せてSlackに通知するようにしています。当然ですがそうした場合は当該のサービスも外部から請求額を取得できることが前提となります。

フロー概要

f:id:yakumobooks:20180505000931p:plain

  1. CloudWatch EventsにLambda関数の定期実行を設定
  2. Lambda関数で事前に暗号化されたSlackの着信WebHookのURLを復号化
  3. Cost Explorer APIを利用してサービスごとの料金を取得しSlackにメッセージを送信

Terraformで上記構成をAWS上に自動で構築するわけですが、その時に重要になるのが図には出てこない太字部分<Slackの着信WebHookのURLをKMSで暗号化する作業>になります。TerraformのソースでいうとData Source: aws_kms_ciphertextを使用している部分にあたります。plaintext引数に文字列を設定しciphertext_blob属性で暗号化された文字列を取得することができます。KMSに暗号化・復号化用のマスターキー (CMK)を作るわけですが、このキーの管理コストが月に$1かかります。着信WebHookのURLがそこまでセキュアな情報ではなくURLがLambda上で平文で管理されることを許容できるのであればKMSを使わない選択もあるかと思います。ただ、アクセスキーやパスワードといった機密情報をLambdaで扱う要件があるのであればKMSは使ったほうが良いでしょう。

Labmdaに必要な権限

  • KMSによる復号化
  • CloudWatch Logsへの出力
  • Cost Explorer APIからの利用料の取得

上記を可能にするポリシーはTerraformで表すと以下のようになります。

data "aws_iam_policy_document" "lambda_slack_policy" {
  statement {
    sid       = "1"
    actions   = ["kms:Decrypt"]
    effect    = "Allow"
    resources = ["${aws_kms_key.key.arn}"]
  }

  statement {
    sid       = "2"
    actions   = [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ]
    effect    = "Allow"
    resources = ["arn:aws:logs:*:*:*"]
  }

  statement {
    sid       = "3"
    actions   = ["ce:GetCostAndUsage"]
    effect    = "Allow"
    resources = ["*"]
  }
}

Slackにメッセージを通知するPythonプログラム

AWSの管理コンソールから「Lambda>関数>関数の作成」に進み、「設計図」から「cloudwatch-alarm-to-slack-python3」を選ぶとSlackにメッセージを送信するPython3.6プログラムのテンプレートが入手できます。今回作成したソースもそちらをベースに作成しました(ちなみにPythonをちゃんと書いたのはこれが初めてです)。テンプレートの方ではSlackに送るメッセージにタイトルと本文しか設定していませんが、Slackではメッセージに豊富な装飾が可能ですので詳しくはSlackの公式ドキュメントをご参照ください。

api.slack.com

AWSの料金の取得には昨年末(2017年12月)から使えるようになったCost Explorer APIを使用します。クラスメソッド株式会社様の以下の記事が参考になるかと思います。

Cost ExplorerのAPIの提供が開始されました | Developers.IO

Python3で書いた場合は以下のようになりました。

    ce = boto3.client('ce')
    ce_res = ce.get_cost_and_usage(
        TimePeriod = {
            'Start': '<開始日>',
            'End'  : '<終了日(指定した日は含まない)>'
        },
        Granularity = 'MONTHLY',
        Metrics     = ['BlendedCost', 'UnblendedCost'],
        GroupBy     = [{
            'Type': 'DIMENSION',
            'Key' : 'SERVICE'
        }]
    )

上記スクリプトで開始日と終了日(の前日まで)の期間の各サービスの使用料金が取得することができます。集計単位は月(MONTHLY)か日(DAILY)のいずれかを指定します。今回は使いませんでしたがfilterパラメータを使用すると複雑な条件式でフィルタリングすることもできます。詳しくはAPIドキュメントを参照してください。

CostExplorer — Boto 3 Docs 1.7.12 documentation

ドキュメントを読むと結果が複数ページに渡る場合があるようで、その場合は次ページの結果セットを取得するためのトークンを使ってリクエストを再送する必要があるようです。

メトリクスには"BlendedCost" , "UnblendedCost" , "UsageQuantity"の3つを指定できます。UsageQuantityは少し特殊でそのままだと異なる単位(時間やByteなど)を纏めて集計した結果を返そうとしてくるので使用する際はフィルターと組み合わせて単位が混ざらないようする必要があるようです。

メトリクス 意味
BrendedCost 無料枠の分配やボリュームディスカウントの適用によって発生するブレンド価格で算出された利用料金
UnblendedCost AWSサイト内に掲載されている通常価格で算出された利用料金
UsageQuantity 利用時間やデータ転送などリソースによって異なる単位の利用量

ちなみにAWSの利用料はCost Explorer API以外にもCloudWatchのAWS Billing and Cost Management メトリクスからも取得できますが、取得できる項目はかなり限られます。

AWS Billing and Cost Management のディメンションおよびメトリクス - Amazon CloudWatch

ネット上ではAWSの使用料を取得する方法としてCloudWatchのメトリクスを使われている方が多いようですが、(Cost Explorer APIが比較的最近使えるようになったというのもあるとは思いますが)それもそのはず、なんとCost Explorer APIは呼び出すたびに$0.01取られます。前述のKMSの料金も合わせると、毎日料金を通知したら現在のレートで140円程かかります。ということで間違っても大量にAPIを呼び出してしまわないよう注意しましょう。

f:id:yakumobooks:20180506022954p:plain

開発のために何回か呼び出していたら既に$0.1を超えていました。

最後に

今回のサーバーレス構成は料金通知以外にも様々な応用が可能ですので是非ご活用頂ければと思います。そして運営しているサービスへのアカウント登録を宜しくお願いします(ダイレクトマーケティング)。

プレゼンテーション共有サービス『Speaker Deck』の使い方

※当記事はSpeaker DeckがGithub運営だった頃の古い記事です。比較のために残してありますので最新版は以下の記事をご参照ください。

yakumobooks.hatenablog.jp

Scalaで作ったWebサービス 電子書籍型投稿小説サイト「八雲文庫」

情報共有会にて個人開発したWebサービスについて発表する機会がありましたので、技術者向けに簡単な紹介スライドを作成しました。今回は会でも使用したプレゼンテーションを共有するサービス『Speaker Deck』の使い方についてご説明します。

Speaker Deckとは

speakerdeck.com

Speaker DeckはPDFをアップロードするだけで簡単にWeb上でスライドを共有できるサービスです。運営会社はソフトウェア開発プロジェクト共有サービスの最大手であるGithubです。海外のサービスですので全て英語ですが、機能自体は非常にシンプルですので画面操作についてはほぼ迷うことはないのではないかと思います。類似サービスのSlideshareとは違いスライドの再アップロードが可能ですが、テキスト情報にアクセスすることはできません(過去にアクセシビリティに関する記事を投稿しておいてなんですが)

Speaker Deckにログインする

右上の「Sign Up」からアカウントを作成しましょう。Githubのアカウントを持っていればすぐにログインすることができます。

f:id:yakumobooks:20180422055050p:plain

f:id:yakumobooks:20180422055059p:plain

スライドをアップロードする

タイトルバー右上の「Upload」からアップロード画面に移動します。

f:id:yakumobooks:20180422055107p:plain

「Select a PDF to Upload」ボタンを押してファイル選択ダイアログからアップロードしたいPDFを選びましょう。ドラッグアンドドロップでもアップロードすることができます。私はスライドはPowerPointで作成し、保存するときに「PDF または XPS」を選択してPDFとして出力したものをアップロードしました。

f:id:yakumobooks:20180422055113p:plain

タイトルを決める

タイトル(Name)と概要(Description)を決めて保存しましょう。「Publish this deck」にチェックを入れなければ公開はされません。

f:id:yakumobooks:20180422055118p:plain

タイトル名がそのままURLになりますので日本語タイトルの場合はローマ字に変換されます。URLにこだわりがある場合は以下のようにスラッシュの後ろにURLにしたい文字列を指定しましょう。

サンプル

https ://speakerdeck.com/yakumobooks/sanpuru

サンプル / Sample

https ://speakerdeck.com/yakumobooks/sample

スライドを共有する

投稿したスライドを共有しましょう。右側の「Share」からTwitterFacebookへの投稿や、ブログなどへの埋め込み用のタグを取得できます。確認が終わったら「Edit this presentation」から「非公開」の状態を「公開」に変更することができます。

f:id:yakumobooks:20180422055123p:plain

スライドを管理する

アカウント名のプルダウンにある「My Decks」で投稿したスライドの一覧を表示できます。「Publish this deck」にチェックを入れなかったものは「非公開(PRIVATE)」として扱われます。

f:id:yakumobooks:20180422055126p:plain

「PRIVATE」のものはURLを入力しても見ることはできません。

f:id:yakumobooks:20180422055939p:plain


いかがでしたでしょうか。PDFをアップロードするだけ、という非常にシンプルなサービスですのでわざわざ使い方を説明するまでもないかもしれませんが、他のサービスと比較されたい方もいらっしゃるかと思いましたので記事にさせていただきました。宣伝となりますが、私が開発しましたブラウザで読める電子書籍型ビュワーを提供している八雲文庫でも現在PDF取り込み機能を鋭意実装中です。管理人のモチベーション維持のためにも是非アカウントの登録をお願いします。

本が身近に感じられるウェブサービス“八雲文庫”が目指すモノとは

f:id:yakumobooks:20180328004613j:plain

今まで八雲文庫でできることについてばかり触れてきましたので、本投稿ではサイトを公開した経緯や解決しようとしている課題について自分自身の整理も兼ねて纏めていきたいと思います。管理人がこれから目指していく目標に少しでも共感やご賛同頂ける点があれば是非サイトのご利用をご検討ください。

何故作ろうと思ったのか

まずは以前にも書きましたが技術者としてHTMLで紙の本っぽさをどこまで再現できるか挑戦してみたかった、というのがあります。エンジニアとしてある程度の経験も積みそろそろ自分だけのプロダクトを作りたい気持ちが大きくなっていたので、何か形として見せられるモノを作ってみようというのが最初の動機です。そのため広く使われるサービスを作ろうという想いはどちらかというと希薄でした(ので今とても苦労しています)。

そんな中で何か良い題材はないかと考えていた時に、スマートフォンゲームがとてつもない勢いで普及し始め周りで本を読む人が減ったことに気がつき、イチ読書好きとして危機感を覚えたことがサービス構築の1つのきっかけとなりました。あくまで主観なのですが、スマートフォンが普及する前と後では電車の中で本を読む人は激減したように思います。スマートフォンゲームと同じくらい手軽に書籍が読めればもっと本を読んでくれるだろうか、投稿サイトのような感覚で書籍を読んだり作ったりできれば面白い作品が読み放題で自分も嬉しいな、という発想からそれを実現できるサービス構築を目指しました。

また、当時は電子書籍が少しずつ広まり世間が賑わっていた頃でしたが不満の声も散見しており、電子書籍を独自にブラウザ上にレンダリング*1しようと考えていた自分の手法なら色々と解決できるのでは?とニーズの予感もあり実際の開発に至りました。

【当時の不満の声】

  1. 閲覧に専用の端末が必要
  2. 複数書籍を同時に開けない
  3. カラー表示できない
  4. 動作が重い(これは当サイトも微妙...)
  5. 背表紙で並べられない
  6. 内表紙(袖表紙)がない
  7. フォーマットが統一されていない etc.

目指したのは今までにない電子書籍プラットフォーム

f:id:yakumobooks:20180327232009p:plain
八雲文庫の目指すサービスイメージ①

八雲文庫は「フォーマット」ではなく「プラットフォーム」です。テキストを貼り付けるだけでブラウザで読める電子書籍として作品を公開できる、というのは現在の機能なのですが、今後の構想として様々なフォーマット間の橋渡しをする「フォーマット変換ツール」としての役割を果たせればと考えています。ここでいう「フォーマット」とは電子書籍フォーマットだけではなく、他サイトで定められている記法やマークダウン、さらには画像やPDFも含みます。様々な解析を用いて当サイトが内部的にもつ中間フォーマットに変換することでフォーマット間の相互変換を可能にしたいと考えています。また、図には描いていませんがフォーマット変換の最終目標は現実の「紙の本」への変換であると思っているので当サイトでは固定レイアウトにこだわっています。八雲文庫のビューワーはフォーマット変換をかける前の広い意味での「プレビューワー」であり、作品の「評価版(プレビュー版)」の公開場所としてお使い頂ければと思っています。

目的ではなく手段としての電子書籍

「最終目標が紙の本」と聞くと時代の流れと逆行しているように思われるかもしれません。電子書籍は読むにしても作るにしてもその手軽さが大きなメリットでありその利便性を否定するつもりは全くありません。が、実は管理人は電子書籍端末は所持しておらず、本はもっぱら紙で読む派なのです。唯一持っている電子書籍は技術書を買ったらついてきたPDFくらいです。人並みに読書は好きですが愛書家というほど蒐集している訳でもないので今のところ本棚から本は溢れていませんし、私は集中力がそれほどある方ではないので1つの媒体で色んな本が読めてしまうと1冊に集中できなさそうなので紙の本で読んでいます。ただ、紙にしろ電子にしろ、書籍の閲覧・作成のハードルを少しでも下げることが世にいう「活字離れ」に歯止めをかけることに繋がるのではないかと個人的に考えています。また、紙の本を電子の本にしようとする技術進化流れの中で、電子の本を紙にしたいと思う技術者が1人くらいいても良いのではと思っています。

無意識に広がる本との距離を繋ぎ留めたい

f:id:yakumobooks:20180312232421p:plain
八雲文庫の目指すサービスイメージ②

私は出版業界の人間ではないので本に関する知見もほとんどなく偉そうなことは何も言えません。ですがやはり小さな頃から親しんでいる本に対しては特別な思い入れがあり、現状の出版不況については思うところがあります。溢れかえる膨大な情報と技術の進化、メディア環境の変遷に伴って私たちの可処分時間は細分化され、私自身もついスマートフォンに時間を使いがちになってしまっています。それでもたまに本を買って読み、物語を楽しんだり知識を吸収することで充実感を得ており人間的な成長にも繋がっていると日々感じています。

サービスの構築を通して文字組を学び、本とは何かについて真剣に向き合ったことでその素晴らしさを再認識し、気がつくと離れつつあった自分と本との距離も再び縮まったような気がします。サイトを訪問してくださった方にも本が本来もつ豊かな表現力を少しでも体感して頂いて「やっぱり本って良いよね」という気持ちを伝えられればと思い、現在も細々と運営を続けています。

*1:文字を日本語組版に則って配置することを便宜上「レンダリング」と表現していますが適した用語ではないかも

個人でチラシを作るには?4つの方法と実際に作成したチラシを公開!

f:id:yakumobooks:20180329024519j:plain

3/29 画像を更新しました。 裏面もありますのでとりあえず最後までお読み頂けると幸いです。

運営しているサイトの宣伝のために始めたSNSでの活動とブログの開設が一段落し、さて次は何をしようかと考えあぐねていたところ知人から「チラシでも作ってみたら?」というアドバイスを頂いたのでこの度チラシを作ってみることにしました。

個人でできる宣伝活動は他にも色々あるかと思いますが、『紙1枚に収まるように伝えたいことをドキュメントに纏める』という手法はビジネスの現場でもよく実践しますし、自分のプロダクトのターゲットは誰でユーザーにどのようなメリットをもらたすのかを自分自身が一度きちんと整理すべきだと思っていたのでその点でもチラシ作りが最適だと考えました。

私はデザインもマーケティングも素人同然ですのでご覧の方の参考になるかは分かりませんが、今後もこのブログでは「宣伝したいものはあるけど何をして良いか分からない」という人と同じ目線で調べたことや実践したことを共有させて頂ければと思います。今回はチラシを作るために考えられる選択と、実際に作成したチラシを公開します。

1.無料のテンプレートを使う

raksul.com

印刷通販の大手ラクスルではチラシを作成するための無料のテンプレートを公開しています。ラクスルでは印刷に加えてポスティング新聞折り込みも手配できますので作ったチラシをすぐに配布することができます。新聞は新聞社によってターゲットの年齢/年収をある程度絞れるのでネットよりもより限定した層への訴求が期待できそうです。ただ、新聞は年々購買率が下がっているようなので配布したい地域が既に決まっている場合は早めに始めた方が良いかもしれません。

2.プロに任せる

www.tokion.bz

「下手の考え休むに似たり」とも言いますしお金があるなら無理に素人があれこれ考えるよりもプロにお願いした方が良いでしょう。株式会社トキオンでは追加料金なしでデザインから印刷までのフルパッケージのチラシ作成サービスを提供しています。会社概要の主要取引先を見ますと電通博報堂といった大手広告代理店も利用しているようです。ラクスルと組み合わせてもチラシの作成から配布まで最安で3~4万円で収まるのではないでしょうか。デザインを依頼する相手が必ずしもプロでなくても良いのであればクラウドソーシングでコンペを発注すると安上がりで多くのデザイン案を入手できるかもしれません。

crowdworks.jp

3.モバイルアプリで作る

asobo-design.com

デザインツールの使い方がわからない方やそもそもデザインするためのデスクトップPCをお持ちでない方でも手軽にお手持ちのモバイル端末でチラシが作れます。基本的にテンプレートを選んでテキストを貼り付けていく形式なのでどのアプリでも直感的に作成できそうですが、細部にこだわった図形操作はできないようなのでそれでも良い場合は利用を検討してみてはいかがでしょうか?リンク先ではiOSアプリのみ紹介されていますがAndroidアプリも増えてきているようです。

4.自分で作る

saruwakakun.com

お金をかけられないがちょっと凝ったものを作りたい私は上記サイトを参考にしつつ自分で作成しました。PhotoshopIllustratorは使ったことがないのですがフリーの画像編集ソフト「Gimpで遊んでいたことがあるのでその知識を活用しました。実は八雲文庫内の画像やアイコンのいくつかもGimpで手作りしています。

GIMP - GNU Image Manipulation Program

リンク先のヘッダー内「DOWNLOAD」から各OS別のインストール用実行ファイルを入手できます。アプリ自体は英語ですが、ダウンロードページを下の方にスクロールすると日本語化パッチもありますので併せてダウンロードしましょう。そしてGimpで作ったチラシの表面が当記事最初の画像で、裏面がこちらです。

f:id:yakumobooks:20180329024523j:plain

プログラミングとは違いデザインには正解がなくあれやこれやと修正を重ねるうちに予想以上に時間がかかってしまいました。デザインのプロの方から見ると突っ込みどころ満載かもしれませんが、個人的には学校祭のポスター作り気分を楽しめましたしそこそこ満足しています(個人の満足感ではなく見る人に伝わるか否かが重要なのですが。。)

Twitterのトップ画像もチラシを元に作り直したのでご興味のある方は御覧ください。トップ画像に最適な 1500ピクセル x 500ピクセル に合うように文字サイズを変更したり組み替えたりしています。ブラウザによって表示がずれるのでトライ&エラーで何度か確認する必要がありました。

twitter.com

チラシというとアナログなイメージがありますがこうしてブログに掲載するだけで電子チラシとしての役目も果たしますし、自分が他の人にプロダクトの説明するときにとりあえず紙を渡すだけで良いのでツールとしての汎用性は非常に高いと思います。リリースを控えた個人開発者の方でまだチラシを作っていない方はチラシ作りを検討してみてはどうでしょうか。

f:id:yakumobooks:20180329024527j:plain

私はこれまで長いことぼっちエンジニアを貫いてきましたが、今回のチラシ作りを機に今年はネット上の活動と併せて現実でも色々と動いていこうと思います。あと、本当に今更ですがマーケティングの勉強として以下の書籍を読んでいます。

honto.jp

Web Speech APIで実現するオーディオブックとウェブアクセシビリティ

f:id:yakumobooks:20180129233248j:plain

新機能紹介

ということで、八雲文庫ではこのたび公開した書籍をオーディオブックとしてもご利用頂けるようになりました。既存の投稿作品にも自動的に音声読み上げ機能がつきますので更新等の必要はありません。手前味噌ではありますが、八雲文庫のビュワーはインストールして使用するアプリケーションと違い進化し続けるブラウザの革新的な機能を積極的に取り入れることができるのが強みだと思っています。ご自身の作品をオーディオブックにしてみたいという方は是非八雲文庫にご投稿ください。

f:id:yakumobooks:20180129235603p:plain

朗読を聴きながら書籍のページ送りも可能ですので目と耳の両方で作品を楽しむこともできます。

f:id:yakumobooks:20180129235609p:plain

私は今までオーディオブックというものを使ったことがなかったのでその良さを知らなかったのですが、いざ自分で使ってみると心地よいリズムで頭の中の音読を進められ、より快適な読書体験を味わえることが分かりました。オーディオブックに馴染みのない方も是非一度お試し頂ければと思います。

yakumobooks.com

Web Speech APIの使い方

さて、タイトルにもありますが、ブラウザでの音声読み上げにはWeb Speech APIの内の1つであるSpeechSynthesis(音声合成)を使用しています。SpeechSynthesisを使用するとJavascriptだけでテキストの音声読み上げを実現することができます。メジャーなモダンブラウザであれば使用できますし、その使用方法も驚くほど簡単です。

developer.mozilla.org

音声読み上げ機能の追加に伴い、八雲文庫では作品の音声用テキストを取得できるAPIをご用意しました。通常のHTMLテキストだとルビと本文が重複して読まれてしまいますので、音声用テキストではルビのみを返すようにしています。また、Cookieやブラウザストレージと連携して読み進めた位置を保持することを想定しテキストを行単位で分割して返しています。以下のHTMLをローカルで実行して頂ければ八雲文庫APIを利用した読み上げ機能をすぐに体験することができます。(APIのエンドポイントは"public/v1/books/audio/<書籍番号>"となります。書籍番号は各書籍URLのリクエストパラメーター"?b=<書籍番号>"を使用するとお好みの書籍を取得できます。)

ご利用に関する免責事項:八雲文庫における読み上げ機能及びAPIは現在試験的な機能ですので予告なく仕様の変更、公開停止する場合がありますのでご了承ください。

ウェブアクセシビリティについて考える

オーディオブックのメリットには「ながら読み」というのもあるとは思いますが、もう一つのメリットは視力が衰えてしまった高齢者や視覚に障がいのある方でもコンテンツを楽しめるということがあるかと思います。今回追加した「読み上げ機能」を含めサイト全体はまだ視覚障がい者の方に向けた作りとはなってはいませんが、これから八雲文庫は少しずつ老若男女が楽しめるバリアフリー電子図書館となるべくサイトの構成を見直していきたいと思っています。その一歩として、「ウェブアクセシビリティ」に関する学習も進める必要があります。

そもそもウェブアクセシビリティとは?という方のために以下のリンク先の一文を引用させて頂きます。

ウェブアクセシビリティとは:みんなのウェブ

高齢者や障害者など心身の機能に制約のある人でも、年齢的・身体的条件に関わらず、ウェブで提供されている情報にアクセスし利用できること」

ウェブアクセシビリティの公的な規格としてはW3Cの勧告である『Web Content Accessibility Guidelines 2.0 (WCAG2.0)』とJIS規格である『JIS X 8341-3:2016』があります。WCAG2.0は2012年に『ISO/IEC 40500:2012』としてISO標準となりました。どちらもレベルA、レベルAA、レベルAAAという3つのレベルの達成基準が定められており、技術に依存しない記述内容となっています。

ウェブアクセシビリティの土台には「知覚可能」、「操作可能」、「理解可能」、及び「堅ろう(牢)(robust)」の4つの原則があり、各原則の下に12のガイドラインが存在します。ガイドラインの下には61の達成基準がありそれぞれに先の3つのレベルが割り当てられています。

サイト運営者はいつまでにどのレベルを目指すかやその対象範囲をウェブアクセシビリティ方針として標榜する、ということがウェブアクセシビリティに対応したサイト作りの第一歩のようです。

ウェブアクセシビリティ方針策定ガイドライン

ウェブアクセシビリティをテストするためにブラウザ上のテキストを音声で読み上げる方法は、一般的にはスクリーンリーダーというソフトウェアを用います。有料のソフトウェアの購入は難しいので今回はオープンソースのスクリーンリーダーを試してみました。

www.nvda.jp

自サイトに対し使用してみた結果は、当然ではありますがスクリーンリーダー使用者にはサイトの内容はほとんど伝わらないということでした。特にクリックやタップを前提とした作りが多いページではキーボード操作しか選択肢のない閲覧者にとってはコンテンツの挙動を把握することができません。また、OSやブラウザとの相性が悪いのかしばらく使用しているとスクリーンリーダーが落ちてしまう現象も頻繁に発生しました。そういった点を踏まえ、八雲文庫ではまずは達成基準の「キーボード操作」を満たせるようHTMLを見直し、適宜Web Speech APIによる音声ナビゲーションもできるようにすることを目指していきたいと思います。参考としてですが、内閣府ホームページのウェブアクセシビリティ達成基準チェック結果は以下のリンク先で見ることができます。

ウェブアクセシビリティ検証結果 - 内閣府

八雲文庫のリリースから2ヵ月、まだまだサイトの良さをユーザーに伝えきれていませんし、そもそもサイト自体がユーザーの欲求を満たせるレベルには至っていないのかもしれません。元々自身の技術力の向上のために始めたサイト運営ではありますが、1人でも多くの方に文芸作品の素晴らしさを伝えられるよう、日々サイトの品質を向上させ今後のマーケティングにも活かしていきたいと思います。

5つ星評価はもう古い?各種サービスの評価機能について調べました

f:id:yakumobooks:20180116232849j:plain

通知表から街中のアンケート、社会人になってからの人事考課に至るまで評価というとよく目にするのが5段階評価です。インターネットの世界も同様に映画やホテル、グルメ等の口コミレビューサイトやモバイルアプリ等のコンテンツプラットフォームも星による5段階の評価を採用しているところが多くあります。もちろん一口に5段階といっても「良い|悪い」などの言葉で表す場合や「☆」で表す場合などそれぞれ違いがありますので十把一絡げにはできません。

小説・画像投稿サイトである八雲文庫にはまだ作品を評価する機能(所謂レーティング機能)がありません。そもそも投稿ユーザーが集まっていないので今のところ必要ない、というのも(悲しいですが)理由としてあるのですがサイトを企画した当初から普段よく目にする評価機能に漠然とした不信感があり正解が見い出せなかったため実装を見送った経緯があります。そこで今回は自身のサイトの参考とするために他サービスの評価機能の現状について調べてみました。

Amazon

「星による5段階評価」

【関連記事】

www.dhbr.net

Youtube

「高評価|低評価」(「星による5段階評価」から変更)

【関連記事】

jp.techcrunch.com

App Store & Google Play

「星による5段階評価」

【関連記事】

news.livedoor.com

Netflix

「高評価|低評価」(「星による5段階評価」から変更)

【関連記事】

www.lifehacker.jp www.gizmodo.jp

Airebnb

「星による5段階評価(清潔さ、立地といったカテゴリ毎)」

【関連記事】

星評価の仕組みは? | Airbnbヘルプセンター jp.techcrunch.com

Uber

「星による5段階評価(双方向評価)」

【関連記事】

www.lifehacker.jp thebridge.jp

https://www.uber.com/ja-JP/newsroom/ratingsupdate/

食べログ & ぐるなび

「星による5段階評価」

【関連記事】

www.news-postseven.com 応援!おすすめメニューランキングとは?- 応援!おすすめメニューランキング|ぐるなび

価格.com

「星による5段階評価(製品毎に異なる評価項目毎)」

【関連記事】

kakaku.com

メルカリ

「星による5段階評価」(「良い|普通|悪い」から変更)

【関連記事】

www.mercari-shiraco.com

Pixiv

「いいね!」(「10段階評価機能」から変更)

【関連記事】

togetter.com

カクヨム

「星による3段階評価(Good!|VeryGood!!|Excellent!!!)」

【関連記事】

https://kakuyomu.jp/works/1177354054881351447/episodes/1177354054882844881

調査結果

5つ星評価をやめるサービスもあるようですが全体としては5つ星評価はまだまだ主流のようです。ただ、任意の評価項目に星をつけるタイプがあるのに対し完全に星のみに抽象化してしまうタイプがあったり、1つ星が不快を表すタイプに対しGoodを表すタイプがあるなど、サービスによって星1つの意味をとっても違いがあります。

Amazonの関連記事に記載したリンク先がとても興味深かったので引用させて頂きます。

極端な意見を持つ消費者ほど、レビューを投稿する傾向が強い。「自慢と愚痴」バイアスといわれる現象である。結果として、評価分布はしばしばJ字型になる(英語論文)。大半が5つ星、一部が1つ星となり、その中間の評価がほとんどないという傾向だ。また、肯定的な評価が並ぶと、後により多く肯定的な評価を誘発することも示されている(英語論文)。 http://www.dhbr.net/articles/-/4474

評価機能は1つ間違えるとコンテンツやユーザーに低評価のレッテルを貼ったり逆に評価の吊り上げに利用できてしまいます。お店や投稿作品に低評価がついてしまった場合は改善して評価を挽回することも中々難しく、先の引用のように肯定的な評価が多い場合は全てが操作されていないにも関わらず特定のものばかりに評価が集中してしまう恐れもあります。少なくともレーティング機能を作為的に操作可能な余地を残したままで提供することはユーザーのためにならないように思います。

小説投稿サイトでは閲覧者は多数の作品から人気の高い作品を見つけたいはずですし投稿者は投稿した作品が評価されれば今後のモチベーションに繋がります。表示上どのような表現となるかは分かりませんが作品毎の評価が分かるような何らか仕組みは取り入れたいと考えています。誰もが納得する評価機能というのは難しいとは思いますが、サービス運営者として少しでも『公平・公正』な評価が実現できるよう慎重に考えていきたいと思います。それよりもまずユーザーを増やすことが目下の課題ではありますが。

ちなみに、八雲文庫には評価機能はありませんが通報機能はありますので公序良俗違反等の規約違反な投稿に対するアクションは可能です。ユーザー評価にお疲れの著者様は筆休めに投稿してみてはいかがでしょうか?