メタバースtech blogはじめました。
今年になってengineering managerが2人生まれましたが、そのうちのひとりなxyxです。
2017年からadvent calendarをやっていたり、AWS Summitで発表したり、Go Conference 2022のスポンサーしたり、と社内の技術情報を発信してきましたが、tech blogはありませんでした。
メタバース、盛り上がってますね。
すごく面白いことをやってるのに、知られてないのはもったいない！
ということで、clusterの開発風景をより広く知ってもらうため、tech blogを始めることにしました。
これからいろんなエンジニアのいろんな記事が読めると思います！
clusterでの設計
私はどうやら設計と組織の交差点、みたいなところに興味があるようです。(EMなのでそれはそう、ではありますが。)
参考: 昔書いた記事
新生clusterを支えるスプレッドシート技術 ・ ソフトウェアと言霊
今回は、clusterの技術設計に主に使われている文書の形であるdesign docの話をします。
design docとは？
これがdesign docです！
design docには、実現したいことと実現方法が書かれています。
この形式の発祥の地を私は知らないのですが、以下の本にも書かれているようにGoogle社内では広く使われている文書形式です。
https://www.oreilly.co.jp/books/9784873119656/
従業員が10万人を超える巨大エンジニアリング組織でうまくいってるらしい。いい話だな～。それはそれとして、自分たちの組織ではどうするべきか？
会社には文化・組織・ビジネス・プロダクト、いろんな要素があり、その組み合わせはユニークなものです。なので、他社の成功例を外見だけ真似たプロセスはカーゴ・カルトになってしまうかもしれません。
この記事では、私が入社した2019年からの3年間を振り返ってみます。
design docの歴史
文書にはそもそも保存する場所が必要。ということで、ドキュメントツールの歴史をまとめてみました。
この環境でdesign docがどのように導入されていったか見てみましょう。
導入前夜: 2019~2020前半
会社全体でエンジニアが10人以下で、tech leadという役割もなかった時代。
誰が何に詳しいかを、全員が暗黙的に知っていました。実装メモはscrapboxに存在していて、稀に不安な時だけ他の人に見てもらっていました。
コードに書きにくいような、ごく一部の設計がconfluenceに書かれたりしていました。
導入期: 2021Q1
このころはエンジニア10人ぐらいで、暗黙な共有はそろそろ限界があるな～と思っていた時期です。
この時期に、コードベースと組織、それぞれで転換点があったのです。
技術スタックの増加
2020年末に表示を圧倒的に高速化するというのをやっていました。https://note.com/cluster_official/n/n764ffc8cf06b
実はこれは、AndroidとiOSのコードベースが増えていて、別のコードベースが生まれることを意味していて、情報共有が今より難しくなるだろうなーという予感もありました。
エンジニアの採用加速
https://speakerdeck.com/clusterinc/we-are-hiring?slide=33
2020年から採用を加速していくため、新しいエンジニアをスムーズに受け入れられる体制を構築する機運がありました。
私としては、ついに来たか！と、前職で使ってなじみ深いdesign docを導入してみることにしました。
最初に書かれたのは、MQTTからroom serverへの移行計画の文書でした。これは、clusterの空間内同期の1~2年先までにわたる展望を書いた文書で、まさに「残る必要のある文書」でした。(room serverが何かはこの記事が参考になります)
この文書を皮切りに、10本超のdesign docがscrapbox上に書かれていく中で、design docの意義の認識が深まり、運用の限界も見えてきました。
design docの果たす役割は、少なくとも二つあります。
- 後世のための設計の記録
- 設計の合意形成の場
このうち、1は十分果たせていたのですが、2を実現するにはscrapboxは不向きであることが分かってきました。端的に、
文章とコメントが別れてないと議論が収束しない
ということが分かってきました。scrapboxは考えを発散させていくには非常に向いているツールなのですが、ある程度選択肢を絞ったうえで、部分的に議論を深めて合意に至る、という使い方がしづらいのです。
そもそも、チームでの設計とは、この設計なら十分いいんじゃない？(= 後で問題起きたとしても、修正手伝うよ)という妥協点を共同で、考える時間が限られている中で、探し求めるプロセスだといえます。
この機能を果たせないままdesign docを運用するのはあまりにももったいない。
普及期: 2021Q2~2021Q4
導入期の知見をもとに、2021/3には早速google docにテンプレートを移行し、ここからさらにdesign docの数が増えていくことになります。
この時期は順調にエンジニアの人数もdesign docの数も増えていき、今では100件以上が書かれています。
design docの組織に対するメタ機能
こうして、design docがない状態からある状態に組織が移り変わっていくのを間近に見ることで、いくつかの機能・特性に気づきました。
これらの特性が数年後にどう機能するかは未知の部分もありますが、現状では良いものと思ってます。
technical writing機会の提供
design docは技術文書なので、書く機会が増えるにつれて否応なくtechnical writingをする機会を提供しますし、そのreviewを受けるときにはフィードバックをもらうことになります。
設計における自然言語の力は大きいと思ってる(cf. ソフトウェアと言霊)ので、technical writingを強いるシステムというのはまぁいいことなんじゃないかな、と思います。
設計のエビデンス
そもそも設計が行われたという事実そのものと、設計過程の記録の価値は高いです。
あるコンポーネントに何らかの問題が発生して修正を迫られたり、仕様を変えたくなることは往々にしてあります。設計過程の記録は、どこまで考えて再設計を行うべきなのか、新しく作り直すべきか、という判断の役に立ちます。
開発に対する各メンバーの貢献を組織として正確に認識するためにも、著者や議論関係者がログに残っていることは重要です。
設計の権威勾配を強化する媒体
design docを後から見る人は、このシステムって○○さんが設計したんだ、というのを目にすることで、権威として認識します。
権威というのは、迷ったら時に頼ればよい人ということなので、それが認識されていくのは問題解決の時間を縮める効果があると思ってます。
自己成就的概念
最終的にはコードが期待通り動いて、それがメンテナンス可能で、知識が組織内で伝達されれば良いので、本質的にdesign docが絶対的な解というわけではないです。
とはいえ、「design docを書くこと」=「設計すること」と多くの人が思うことで、design docは自分自身の機能を補強するように機能します。
たとえば、評価システムと結合するとで、うまいdesign docを書ける = うまい設計ができる、ということになるので、上手く書くように練習するインセンティブが働きます。そして、このサイクルは「うまいdesign docを書いた」人が昇格し、ジュニアな人を評価する側になることで完成します。
さらに、組織の設計の多くがdesign doc形式で書かれていると、それを読み書き・レビューする能力はドメイン知識を把握して産み出すことと限りなく一致していきます。
なので、感染性ミームとして、design docは組織内に自らの立場を確立していくことになります。
一回導入されれば安定する概念なので、プロセスの維持コストが減るという観点で良い特性です。とはいえ、議論の余地があまりないものを形式だけ整えた、やってる感を出すためだけのdocが増えないようにしないとな、とは思っています。
情報処理の圧縮効果
組織での情報処理に関して、SECIモデルという概念があります。
- 個々のメンバーの中にある暗黙知を言語化し : 表出化
- 言語化された知識を組み合わせ : 結合化
- 結合された知識を暗黙知取り込み : 内面化
- 複数人が共同作業することで暗黙知が摺り合う : 共同化
というサイクルにより、組織内の情報が生まれていくという概念です。
design docは表出化～結合化を担い、共同でのprojectやepic(clusterでの機能開発単位)をやることで内面化～共同化が進む、という形でサイクルが構成されていると見ることができます。
重厚長大な仕様書と違い、比較的高頻度に書かれて読まれていく、半分消費的なものであることで、サイクルが高速に回るという側面があります。
私自身を振り返ってみても、設計のカンみたいなところがどう養われたかというと、他人の書いたdesign docを読みまくった経験がかなり大きいです。
人が一生で体験できない量の設計を目にして、それを内面化することができる。さらに、そこに組織・サービス独自の概念が含まれていると、組織に独自の知識体系が構築されていることになります。
組織と密結合した知識体系は、非常にコピーしづらい参入障壁として機能します。
clusterでの設計の未来
design docについて、いろいろ書いてきました。
基本的には、「良いものなので、みなさんも導入してみましょう」と思ってます。
とはいえ、クラスターの現状が完成系だとは思っていません。
今後やってみたいな、と思ってることがいくつかあります。
承認フロー
design docを誰がレビューするか、どのタイミングでレビューするか、今のところシステマチックに決まっていません。
「興味ある人が見て」というのはスケール限界があるので、「見るべき人が見る」のがもっとシステム的に補助されるとよいなと思ってます。それによって、見落としも減るし、知識共有もはかどるはず。
とはいえ、安直なフローによって、不必要な承認や形骸化した文書が必要とされて開発速度が落ちると本末転倒なので、いい方法を探したいなーと思ってます。
miro
世間でリモートワークが増えたことも関連して、オフラインのホワイトボードより優れたツールとして流行ってきました。クラスターもそれに漏れずmiroを多用してます。
設計に図は不可欠で、miroで作った図を張り付けたり、desgin docとは別にアーキテクチャの解説図やフローチャートがあったりします。
miroは、複数階層の情報を含む巨大な図でも快適に描ける点が素晴らしく、いわゆる作図系のツールとも、リアルのホワイトボードとも一線を画しています。
総体が書かれている図があるのに、小さな画像として切り取ることはもったいなく感じています。design docとあわせて、組織的にmiroを運用できるフォーマット・プロセスが作れれば良いな、と思ってます。
さいごに
いかがでしょうか？
初回からボリューム多めでお届けしました。
これからも記事を出していくので、読者登録よろしくお願いします～。
