@kenmaroです。
普段は主に秘密計算、準同型暗号などの記事について投稿しています。
秘密計算に関連するまとめの記事に関しては以下をご覧ください。
概要
個人開発について何度か記事を書いていたり、
ツイッターでも個人開発のことをツイートしたりしていましたが、
自分のアイディアを実現するために開発する、という活動が楽しく、沼っています。
この辺は
ここに詳しくまとめていますので是非ご覧ください。
この個人開発活動の一環として、この度
「ProtoHub」というテックブログサービスをリリースしました。
「ProtoHub」はものづくりをする全てのエンジニアを対象としたブログプラットフォームです。
といいつつ、厳密に言えば「作ってみた、実装してみた」系の記事を投稿する場所にしたいと思っています。
そういう意味で、Protoはプロトタイプから取っています。
これをキータの記事で宣伝するのもどうかと思う一方、
キータは素晴らしいプラットフォームであるため、少しだけ開発に至った経緯などを説明させてください。
開発経緯
開発をする上で学んだことや成果のアウトプット先、開発する上での貴重な情報資源として多く活用される技術ブログのウェブサイトは日本国内でも国外でもいくつか存在していますが、
私たちは既存サービスの以下のような課題点に着目し、
それらを解決するために「ProtoHub」を開発しました。
既存サービスの課題
- 記事の再現性がわからない（記事に沿って開発して本当に目的の実装が実現できるのかがそもそも判断が難しい）
- 記事の誤記載や記載漏れによって開発者の時間が同時多発的に奪われる（閲覧者の多くが記事の同じ場所でつまづいたり、本来必要でないデバッグを余儀なくされる）
- 古い記事は９割ブラウザバックされる（特に知識のアップデートが早いエンジニアリング業界において、記事の旬は２年ほどであり、それ以前の記事は存在価値が急速に落ちる）
少しだけ詳しく書いてみます。
記事の再現性がわからない
これはあるあるだと思います。
実装してみた系の記事が多い中で、「本当に動くの？？」と思ったこと、ないでしょうか？
また、結構丁寧に書かれている記事だな、自分もやってみよう！と思い、実装を開始したものの、
途中でハマり、結局開発が頓挫してしまったり、思ったより大幅に時間を投下しなくてはならなかったりした経験、ありますよね。
私はハッカソンに出るのが好きで、今まで５個くらい出場したことがあります。
何か作りたいもののテーマが決まった後は、基本的には技術ブログの作ってみた系の投稿を漁り、
なにか実装を真似できないか、と考えることがほとんどだと思いますが、
この時にその記事に再現性があるかどうかの判断は、読者の経験によるもの、もしくはセンスになります。
この選定をミスった場合、ハッカソンとしてはデスマーチ化することが多いです。
ですので、結局公式ドキュメント最強説ではあるのですが、公式ドキュメントにリッチなチュートリアルコードがなかった場合など、やはり技術ブログに頼ることになり、再現性の問題は残ります。
記事の誤記載や記載漏れによって開発者の時間が同時多発的に奪われる
これに関しても、大体は再現性の問題と同じです。
開発において、技術ブログを読むときは基本的に自分が初めて取り組む技術スタックだったり、知識の浅い分野の記事であることが多いでしょう。
したがって、記事の記載に間違いがあったり、大事なことが書かれていなかった場合、それに気づくことは困難です。
結果として、その部分を実装する段階になって「なぜか動かない」とか、「謎のエラーがでる」
とかになってしまい、結局他の記事を参考にしてそのエラーを回避したり、最悪の場合今までやったことを全て捨てて、違う手法で実装したりすることが普通でしょう。
ここで、大事なのは、そのあなたが読んだ記事を読んでいる人は他にもたくさんいて、その人達もその記事の同じ箇所でハマっている可能性が高いということです。
これは、その記事の誤記載などにより、多くのエンジニアの時間が「同時多発的に奪われている」という非常に重い問題だと思います。
これを解決するためには、記事を編集してアップデートする必要があるわけですが、多くの記事は編集のすべての権限は記事のオーナーに帰属しています。
つまり、編集リクエストを送ったり、コメントを送ったりしたとしてもその記事がオーナーによって編集される保証はないわけですし、
オーナーにとっての負担も大きいです。
コメントでここが間違ってますよ、と書くことで、読者が間違いを前もって把握し回避できる可能性ももちろんありますが、
もちろん最適なのは記事そのものがアップデートされていくことだと思っています。
古い記事は９割ブラウザバックされる
これもあるあるでしょう。これも結局は記事が年数と主にアップデートされていかないのが原因で生じます。
理論系の記事であれば流行り廃りは少ないと思いますが、実装系の記事であれば、２年もすれば記事としては古いものになります。
キータで言えば、サービスがスタートして１０年くらい？だと思いますので、
乱暴な計算をすれば、キータに保存されている全記事のうち、８割くらいは古い記事として価値が非常に低い、
ということになります。この意味でも、記事がいい感じにアップデートされていく、そんな機能が欲しいなと思っていました。
ひとつの解決策として、ウィキペディアみたいな記事の管理の仕方は一つ考えられるかなと思います。
マスターとしての記事があり、有志の人は誰でも記事を編集できる、編集は承認する人が入って数いれば反映される、
みたいな感じでしょうか。
しかし、このシステムはドキュメントのような対象についてはしっくりくるものの、個人が執筆する記事についてはあまりしっくり来ないなあと思いました。
記事に関しては書いたオーナーがいて、その人が編集権限を持っているという構図は正しいからです。
また、ウィキペディアのような媒体ではだれでも編集できるが故に誰の貢献度が高いのか、というようなことは見えない一方で、
技術ブログであればもちろん書いた人に貢献性があり、それが見える化されており、書いた人が評価やフィードバックを得るような構造はあってしかるべきだと思います
結果として、どのようにして記事をよりよくアップデートしていくか、ということは考えていくべき問題だと思います。
以上の問題点を、「ProtoHub」は以下のように解決していく、それが「ProtoHub」が提供できる価値だと考え、開発に取り組みました。
「ProtoHub」が提供する価値
- ユーザ参加型の「記事による実装の再現性」の可視化（ユーザはコメント共に再現性や、再現に必要な時間コスト等を投稿でき、閲覧者は実装の再現性を確認し実際に実装するか選択することができる）
- ユーザ参加型の記事のアップデート（ユーザは記事をForkすることで、記事のオーナー権限を取得できる。取得後は自分の記事のように記事をアップデートすることができる。また、フォークの履歴は可視化されており、最初のオーナーの貢献度は守られる）
ユーザ参加型の「記事による実装の再現性」の可視化
ユーザは、コメントに付随して、記事の再現性に関する情報、具体的には「再現できたかどうか」と、「どのくらいの時間をかけて再現できたか」を入力できます。
また、それらの情報は統計情報として記事画面右手にグラフとして可視化され、ユーザはそれらの統計情報を吟味して、実際にその記事の内容を実装するか、など判断をすることができます。
ユーザ参加型の記事のアップデート
GitHubのフォーク機能を知っている人はそれをイメージしてもらえれば一番わかりやすいです。
フォーク機能は、他ユーザの書いた記事を自分の記事としてクローンすることを言います。
フォークをした記事のオーナー権限は当然、フォークしたユーザですから、編集権限も移譲されます。
したがって、もし元の記事に間違っている箇所があったり、自分の環境では動かない場所などがあれば、その情報を追記することができます。
仮にそのフォークされて編集された記事の方が再現性が高いとすれば、自然とユーザのフィードバックも、そのフォークされた記事に対してポジティブなものになるため、
自然と良い記事、かつ新しい情報にアップデートされている記事にユーザが集まるようになると考えています。
また、フォークはもとの記事を改変するわけではなく、おおもとの記事の執筆者、つまりオーナーは、フォークツリーを辿ることで可視化されるため、
もともとの記事を書いた人に対しての貢献性も担保されます。
このフォークの機能を今回「ProtoHub」に実装することで、必要な箇所には積極的にアップデートが加えられ、記事の柔軟性が高まると考えています。
まとめ
今回は、我々が個人開発する「ProtoHub」という技術ブログプラットフォームについて告知をしました。
我々が課題に感じているポイント、「ProtoHub」を開発するに至った経緯についてお伝えできたのではないかと思っています。
また、開発時のシステムアーキテクチャなどや運用費用などは別記事にまとめているので、
個人開発を考えている人はぜひ参考にしてみてください。
まだなにを達成したわけではないですが、運用も長期的にできるよう、これから注力していこうと思っていますので、
もし興味を持ってくれた方がいらっしゃったら是非記事を投稿してみてはどうでしょうか。
今回はこの辺で。