エス・エム・エスで開発を担当している髙木です。
今回は社内向けの書籍レビューサイトをClaude Codeで作った話と、運用してみてわかったことを率直に共有します。技術書の購入制度は世の中に広く受け入れられており、社内にあった形で運用されていると思います。よりよい活用を目指すためにレビューサイトを作ってみたという内容になっているため、同じ関心事を持っている方に読んでいただければと思います。
書籍購入制度について
弊社には書籍購入制度があります。
これは福利厚生ではなく業務に必要な投資という位置づけで、かなり頻繁に利用されています。
この制度を使っている身としては、以下の感覚がありました。
- 誰がどの本を買っているかが見えにくい
- よく買われている本がわからない
- 購入した本からどういうインプットが得られたかを聞く機会がない
誰がどの本を購入したかをスプレッドシートで管理されていたため、この情報を活用しようと考えました。記載されていた情報は、以下の6つでした。
- No.
- 購入日
- 購入者の氏名
- 書籍タイトル
- 購入先のURL
- 購入サイト
最初考えていたのは統計を取ることでした。それだとどういう本が買われているという傾向だけがわかり、情報を活かせるイメージが湧きませんでした。それならば本の情報を投稿できる機能としてレビューサイトのような機能をもたせたら面白くなりそうと思い、社内用のレビューサイトを作ろうと思いました。
社内用のレビューサイトに価値はあるのか？
価値はあると考えていました。技術書の評価は、個人だけでなくチームの状況やコンテキストに大きく依存します。もちろん一般的なレビューサイトも参考になると思いますが、「自社の開発環境で役立つか」という観点では情報が不足しがちです。クローズドな環境であれば、企業内のコンテキストを前提としたレビューが投稿できます。「うちのプロジェクトではこう活用できた」といった実用性の高いレビューが集まるのではと考えました。またレビューの投稿のハードルも一般的なレビューサイトに比べると低く、投稿したことがない人も投稿できるような環境が作れるのではと考えていました。
もともと私が持っていた課題感を解消する面もあったため、レビューサイトの価値は高そう！という感覚がありました。
スプレッドシートに登録されたデータによる技術的な制約
冒頭でスプレッドシートがつかえそうという話をしましたが、実はこのデータをそのまま使うことにはいくつか課題がありました。
課題1：利用者の情報が氏名しかない
このスプレッドシートにはユーザーの情報に関して氏名の情報しかありません。基本的にユーザーをユニークにする際、IDを付与したりメールアドレスを付与することが多いと思います。今回登録されている情報が氏名しかないため、氏名をベースにシステム設計を考える必要がありました。登録される情報自体を調整するという話もあるのですが、他部署が絡むことと今回のアプリケーションの価値が確認できていない中で運用の変更を依頼することに抵抗感があったため現状のスプレッドシートで進めることにしました。
さすがに氏名の入力自体は信頼性の高いものを使用したいため、Google認証を利用してアプリケーションを作ろうと考えました。弊社の社員はGoogleアカウントを持っているため、認証周りはすべてGoogleアカウントによせれば棚卸しなどの管理業務からも解放されるので一石二鳥でした。
課題2：本の情報がユニークではない
このスプレッドシートに書かれている情報はタイトルと購入先のURLです。レビューサイトとしては書影などを使用したいため、これらをGoogle Books APIから本の画像や著者名を取得しようとしたとき、本のタイトルで検索をかけると異なる本を取得してしまうケースがあります。また記録されたタイトルに誤字があったりするため、それらの本が別の本として登録されてしまいます。
これらを回避するか許容するかはアプリケーションに求める品質次第ですが、今回は重複登録されることを許容しています。それぐらい本をユニークにするというのは面倒だったため、重複されることを前提としてアプリケーション設計をしました。
これらを踏まえたときに、認証方式とアプリケーションとしての設計が決まりました。商用サービスだったら絶対に許容できない設計ですが、社内限定だったら許容できるラインで設計を考えました。厳密にやろうとすると大変なところも、許容できるラインで作れば手がからなさそうでした。
Claude Codeでの実装
実装にはNext.jsを採用し、コードはすべてClaude Codeに書いてもらいました。実装期間は約2か月です。ただし業務の合間に進めていたので、注力すればもっと短期間で作れたと思います。体感的には1週間ちょっとぐらいだと思います。今だともっと早くできるかもしれないです。アイディアを形にするまでの期間が圧倒的に短いのは、LLMを活用する大きなメリットです。ひとりでプロダクトを作りつつ、情報の整理と実装の担当を分けられるのも良さだと思いました。
Google Cloudでインフラを組んだ経験がなく不安な面もありましたが、AWSを例に上げつつプロンプトを組むことで着実に組み上げられていきました。もともとある知識を別のインフラにも適用しつつ、構成管理もスムーズにできました。
一方で、生成されるコード量が多すぎてレビューがどんどん大変になっていきました。人間がボトルネックになりますが、同時にストッパーでもあります。このバランスを取っていかないと、Claude Codeを主体とした開発は難しいと感じました。最終的に説明責任を果たすのは人になるため、すべてを理解した状態を作るのか一定の信頼をおいてレビューの頻度を減らすのか、そのあたりのバランスを考え続けていく必要があると思いました。
作ってみたもののレビューが少ない…
構築したレビューサイト自体はよくできたと思っています。しかしほとんどレビューは投稿されませんでした。
悲しい気持ちは全くなく、やっぱりそうだよなぁという感覚が強いです。なぜなら僕自身もレビューを投稿できていないからです。
レビューを投稿するのは難しい
レビューとして文章を書くとなったとき、本をどの程度読んだら投稿して良いものでしょうか？
- 目次だけ読んで書く
- 特定の章だけ読んで書く
- 全体を流し読みして書く
- 最後までしっかり読んで書く
人によってその本に期待するものは大きく違います。そのため本からの学び方も人によって異なり、その結果としてレビューの内容やタイミングも変わります。
つまり人によって書きたい内容やタイミングは異なります。この辺りがアプリケーションから提示されないと、自然と「最後までしっかり読んで書く」が前提となり、書くほどではないという感想になり書かなくなってしまうと思われます。したがってレビューの投稿タイミングを制御できていなかったことは、アプリケーションの思惑と実態がずれてしまってよくなかったと思っています。
改善するなら
今回うまく軌道に乗らなかったことを受けて、どういった改善をするのかをいい機会なのでこのタイミングで検討してみます。
改善案1:ステータスを追加する
「読み始めた」「読んでいる」「読み終えた」だけでなく、「途中でやめた」「積んでいる」といったステータスも含められると良いと思います。やめてしまった理由や、途中まで読んだ感想も立派なレビューになります。ステータスに応じて投稿できる内容を変えることで、完読しないと投稿できないという心理的なハードルを下げられると思っています。
たとえば「途中でやめた」ステータスでは、「どこまで読んだか」「なぜやめたか」だけを書けるシンプルな入力欄にする。「読んでいる」ステータスでは、気になったフレーズや章ごとのメモを気軽に残せるようにする。こうした設計であれば、本を読む過程そのものがレビューの素材になり、読み終えてからまとめなければという義務感が薄れると思います。
改善案2:もっと存在を知らせる
そもそも社内における認知度が低く、書くハードル以前に認識されていないことで利用されていない可能性もあります。Slackで一度宣伝した程度なのでもっと存在をアピールするなどの活動は必要かもしれません。社内Wikiに使い方を書いたり、このサービスの思想を伝えたりすることは必要だと思いました。
個人的には付加価値を高めていったあとにしないと二の舞いになってしまうと思うので、利用者が少ないことを活かして改善活動を優先させようとは思っています。
レビューが投稿されればそれで良いのか？
ここはなんとも言えないポイントだと思いました。ハードルを下げるということで質が下がっては意味がないと思います。とはいえ、何も価値のないサイトに人が訪れるほど暇ではないですし、訪れたからには価値を提供する必要があると思います。そういう場だからこそ自分でも価値を提供したいと思えると僕は考えています。
でも何もない状態のところに「レビューを投稿してください」というのは、ハードルが高く難しいのは事実です。なのでそこのハードルを下げつつも、投稿されているものに意味がある・価値がある状態を目指していくのが良いと思いました。
レビューサイトのもうひとつの目的
実はこのサイトにはもうひとつの目的がありました。
以前の記事で書いた「自発的に書きたい人が出てくる仕組みづくり」の一環として考えていました。
テックブログで記事を書くには、文章を外部の人にもわかる形で構成する必要があります。書籍レビューという比較的カジュアルな場で文章でのアウトプットに慣れてもらい、テックブログへの橋渡しにできればと考えていました。
今回作成したアプリケーションでは、その目的に至る前段で止まってしまったので、もっと活発に使われるようになった先で改めて考えていこうと思いました。
最後に
動くアプリケーションを作るのが簡単になった一方で、使ってもらうことの難しさは変わっていないと思いました。社内という限定的な場ですら難しいので、世の中にアプリケーションを普及させていくハードルは変わらず高いのだろうと想像しました。
まだまだ足りないアプリケーションではありますが、もう少しメンテナンスしていってどう転ぶかを見ていきたいです。またテックブログで報告すると思います。
