新生clusterを支えるスプレッドシート技術

この記事はCluster Advent Calendar 2019の22日目の記事です。

昨日は、葉柚子さんの「Clusterを一年使って感じたこと」でした。clusterのサービスとしての洗練具合、そして社内の距離感というのは私が入社したときもかなり気に入った点だったのを思い出しました。

誰?

はじめましての方ははじめまして、xyxです。Unityを触っている系のソフトウェアエンジニアやってます。

…言ってみて気づくのですが、最近あんまりコード書いてないぞ？何やってたんだっけ？思い返してみると、人と話してscrapboxとスプレッドシートに日本語書いてたらだいたい一日が終わっている気がします。(コード書いてる日もある)

そういえば前職ではtech leadって名乗ってたっけ。

大規模アップデートに向けて準備中のcluster社内ですが、15人ぐらいのエンジニアリングプロジェクトがどんな感じで進んでいくのか、自分がその中でどういうことを考えているか。タスク見積もり用のスプレッドシートという具体例を出しながら、ちょっとでも伝えられたらいいな～というのがこの記事です。

「大規模アップデート」

この記事を読んでいる方はたぶん知っていると思いますが、clusterの大規模アップデートを来年初旬に行うことが半月ほど前にアナウンスされました。

【お知らせ】
2020年初旬にclusterの大規模アップデートを行うため、その開発との兼ね合いでアーカイブ機能を一旦終了する運びとなりました。

アーカイブ購入者様には詳細についてメールいたします。併せて、弊社代表からのメッセージもご覧ください。https://t.co/OmAXESD4po#clusterVR pic.twitter.com/3I0TuCjqA4

— cluster公式∞ゲームワールド杯投票受付中🏆 (@cluster_jp) November 25, 2019

この「大規模アップデート」ですが、実は社内では新生clusterプロジェクトと呼んでいて、サービス全体を新しい体験へと再構築するものになります。

新生clusterプロジェクトは2019年秋に始動しましたが、その道程は平坦なものではありませんでした(重厚な音楽とともにドキュメンタリーが始まる)…

というようなストーリーを後から脚色して書くことはできます。

が、継続的に提供されるサービスにおいて、プロジェクトの始まりや終わりが、どんなものなのか、現実にはどんな感じか、見ることは少ないかもしれません。

clusterは、いくつかのプログラムと多くの機能が有機的に結合してひとつのサービスを成しています。新しいプロジェクトといえども、リリースすれば完了というものではなく、継続的にサービスを成長させていくものであるはずです。

まず、そのようなプラットフォーム的サービス一般の話として、私が経験したプロジェクトの一生というのを書いてみます。

プロジェクトの一生

経験上、5人～20人ぐらいで何か新しいことが始まるときはいくつかフェーズがありますが、ここでは4つに分けてみましょう。(もちろん、いろんな道筋を辿るプロジェクトがあるでしょうが…)

1. 始まってない
2. 始めようとする
3. やってる
4. 終息

“始まってない”状態

• やっていき機運が何らかの要因で高まる
• インフォーマルな雑談を通じて、ひとり～数人だけが知ってる情報が大量に生成される
• プロジェクトに名前がなく、自分がそれに属してるのかわからない人が大多数

“始めようとする”状態

“やってる”状態

• 人々が定例ミーティングに慣れて、未来の詳細化と実際のコーディング作業が並列で進む
• マイルストーンごとの、進捗が数値化できている (正確とは言ってない)
• 進捗が明確化した結果、マイルストーンの優先順位変更が起きることもある

終息

• 何らかマイルストーンの達成(だいたいはリリース)後
• お祝いがある(ときもある)
• 未来のタスクは無限に積まれているけど、一貫した方向性を失っている
• 終了宣言はあったりなかったりする
  

今日は、私が“始めようとする”～”やってる”状態の中盤ぐらいまでどう考えているか、そしてそこで使っている見積もり可視化用のスプレッドシートの話をします。

プロジェクトの不確実性と可視化

「エンジニアリング組織論への招待」という本があって、

実現すること = 不確実性を0(現実に実装された状態)にすること 

という考え方が示されています。

1. やりたいことの曖昧なイメージ (不確実性: 最大)
2. プロダクト仕様・技術仕様 (不確実性: 中ぐらい)
3. ソフトウェア・運用  (不確実性: 0)

概念的にはこういう手順で徐々に具体化されます。(これを愚直にやるのがいわゆるウォーターフォール開発、らしいです。)

しかし現実には、微小な詳細がプロジェクト全体に影響を及ぼすことが頻繁にあって、それをうまく扱って不確実性を下げる必要があるし、効率化もできるというのがおもしろいところです。

遅くなるパターン

例: ライブラリAを導入すれば3日で実現できそうな機能Aだったけど、導入すると謎の要因で社内の自動ビルドシステムが動かなくなって開発効率が1/10に低下した。原因調査と修正には不定の時間がかかり、ライブラリ無しでの独自実装には半月ぐらいかかりそう。

早くなるパターン

例: 機能B (2週間)+機能C(2週間)と思っていたけど、UIのボタンひとつの位置を調整することで、汎用的な機能G(2.5週間)で両方のケースを実現できることがわかった。n%のユーザーしか使っていない機能cをなくせば、すでにある機能Xを転用して1週間で実現することもできる。

基本的にはこういう確率的な選択肢が常に無数に存在しています。ノベルゲームとかシミュレーションゲームっぽくもあります。選択肢を詳細化するための選択肢、というのもあって、先程の例だと:

最初

“ライブラリAを導入すれば3日で実現できそうな機能だったけど、導入すると謎の要因で社内の自動ビルドシステムが動かなくなった。どうしよう。”

選択肢1 聞き取りする(0.5日)

• 開発者5人ぐらいが影響を受けてる。効率は1/10ぐらいだしストレスも溜まりそう。

選択肢2 見積もりする(1日)

• 90%: “…原因調査と修正には不定の時間がかかり、ライブラリ無しでの実装には半月ぐらいかかりそう。”
• 10%: 残念、見積もりしてる人が風邪で寝込んでしまって来週まで分からない！

プロジェクト全体では、このような互いに関連した要素と選択肢が常に100個ぐらいは存在している印象があります。

人間ひとりが同時に考えられる物事はせいぜい数個ぐらいなので、

• 文章化して忘れても思い出せるようにする
• 組織として分散処理しやすい形に変形する (どうやって?)
• そもそも考える必要のない余計な情報をプロジェクトに投入しない

という選択も重要になります。

プロジェクトにいる人間はだいたい固定なので、必要な情報が無くてやることがない人がいる、という状態も避けたいところです。

まとめると、

• 人の手が空かないようにする
  • 直近の事象ほど具体化する、着手可能なタスクが0にならないようにする
• 不確実性の低減
  • 他の事象と相互作用が強そうなものは早めに具体化する (すくなくとも、相互作用が及ぶ範囲を限定する)
  • やらない事柄を合意して、より遠い未来に追いやる

あたりを継続的にやっていくことになります。

自分の中のイメージだとこの図のような感じです。

• すでに進行中/完了済みの実装や調査タスク (□)
• やりたいこと・未処理の重要そうな情報/要求 (雲)
• それらの間の相互作用 (―)

基本的には、確定した部分についてはプロダクトとしての仕様も技術的仕様も木構造になっていきます(木構造が一番理解しやすいので)。しかし、現実は難しいので、直感的ではない相互作用が発生する場合もあります。

たとえば、画面Aと画面Bはユーザーにとってはぜんぜん違う機能だけど、実は同じコードで実現されているので、片方だけを変えることが難しい、というケースがあります。

視点の種類自体も無数にあるので、常にコミュニケーションを維持することでなんとかして不確実性を低く保つことになります。

そんな中、唯一全員で共通して使われる、もっとも抽象的な視点がマイルストーンです。

• マイルストーン1: ○月ぐらい △が実現されている
• マイルストーン2: □月ぐらい △が実現されている
• …

今のクラスターの組織規模だと、このぐらいの粒度ではCXOが直接関与して、何がいつ欲しいかを今のプロジェクトで判明した情報をもとに擦り合わせていくことになります。

どうやる

ここまで、(クラスターに限らない)プロジェクトの構造の話をしてきました。そろそろ、私がタスクを細分化して、それを共有する過程で使っているスプレッドシートの話をしようと思います。

けれど、新生clusterの中身はまだ秘密です。

ここでは架空のVRMアバター編集ツールを想定した例を使います。

クラスター社内ではイシュー管理ソフトにはAtlassian Jiraを使っています。しかし、プロジェクトのタスク管理用のソフトは特に無いので、スプレッドシートでなんとかならないかというところからはじめました。

タスクの細分化と期限の記入ができればいいかと思い、ガントチャート・ジェネレーターを30分ぐらい触ってみました。

いいところ

• 日付とか入れると自動で絵を書いてくれる、休日を扱ってくれる
• タスク分割が軽量でやりやすい

わるいところ

• マイルストーンを超えてタスクを移動するのが難しそう
• 日付を具体的に入力しないと何も計算できない

全体的に、要求されてる情報の精度が精密すぎて厳しいな、と感じました。プログラミングしていると1日予定のタスクがやってみると0.5~3日になるのは日常茶飯事ですし、サーバーとクライアントや、デザイナーとクライアントエンジニアで共同で進めるパターンも多いので、精密な割当と日数見積もりを数ヵ月分重ねていくのは不可能です。

そのへんを雑にやりたいな～と思って、作ってみたシートがこれです。Google Apps Scriptを使ってない、かなり単純なものです。

カラム

• プロダクト的優先度 (マイルストーンに対応)
• 内容 (複数カラムで親子関係が表現できるだけ)
• 誰がやるか
• 見積もり日数
• 不確実性

「マイルストーン」「不確実性」は重要なので、自動で着色して直感的にしています。

具体的な日付を入れるところがまったくないところがポイントです。

使い方ですが、まずプロジェクト全体に思いを馳せて、必要なタスクとそれぞれの日数を書いていきます。この段階だと、日数というよりは、自分が把握してる情報の存在を全て書き出して、それを誰が見れば進行していくかに重点を置きます。

新生clusterプロジェクトでは、この表を書こうと私が思った段階ですでにプロダクトマネージャーが作成したユーザーストーリーの草案があったので、それを参考に私一人で数時間で100個弱を書き出しました。必要ならば違う分野の2~3人で書き出す会をやってみてもいいと思います(合意形成が目的ではないので、人は少ないほうが速い)。

これにプロダクト的なマイルストーンをいれてみるとそれぞれどのぐらいの時期に完了しそうなのかがわかるので、それをもとにいろいろなステークホルダーと順番や何をどこに入れるかを調整します。

ある程度安定してきて、他の人にチラ見せして問題なさそうなことを確認すれば、マイルストーンを発表するkick-offミーティングの機運です。(こういうタイプの、聞いてる人の意識を短時間で転換する技術は私はまだまだ未熟なところなので他の人に任せることが多いです…精進せねば。)

これ以降は、定例ミーティングを設置して関係者全員がdaily~weeklyぐらいで情報が行き渡るようにするのが良さそうです。

見積もりの精度は継続的に上げていきたいところですが、基本的には3つのことを行います。

• 不確実タスクの具体化: 技術調査タスク(1~2日) + 残りの分、のように分割して技術調査を高優先度で実行する
• 着手が近付けば、その人に聞き取って日数を修正
• 全体の並列度は周りの様子を見て主観的に埋める

並列度はこんな感じでたまに測定して平均値を使ってます。今のところ安定していますが、これが上昇・下降トレンドになれば、もっと洗練された計算式を使うほうがいいかもしれません。

情報を見せないことの価値

このスプレッドシートをよく見ると、終わる予定日と進捗率がかなり薄い色で書かれています。

書かれてない情報(たとえば予想の誤差の感覚)無しで見て欲しくない、という気持ちを色に込めています。ここをアクセス制限してしまうとプロジェクト進行が密室で決まっているような雰囲気になるので、色を薄くすることで見ようと思えば見れる(けどあんまり信頼できなさそうな)見た目にしています。

一方で、口頭会話では「○月までに機能Aがリリースされることはない」、というような断定を私は意図的に多くしています。

思ってることをそのまま言語化すると、「しばらくは機能Aはリリースしないよ」あたりになるのですが、聞く人によって「しばらく」が1週間なのか1ヶ月なのかは解釈が分かれます。これはランダムな情報をばらまいて不確実性を上げる結果になってしまいます。

断定することで伝える側がコントロールできる余地が増えるし、だいたいの人間は口頭で聞いた数字を正確に覚えていないので、ちょうどよく実際の精度(○月±1ヶ月とか)ぐらいの印象が伝わる気がしています。

ここまで書いておいてあれですが、実はこのスプレッドシートはプロジェクトが後半に差し掛かってくると価値が減ってきます。

実際に実装されて動作する機能が出てくると、バグも発見されてきます。そのとき、スプレッドシートとバグ管理ツールで同期が取れていないので相対的にどのぐらいタスク量があるのかわからなくなってしまします。

この局面でどうするのがいいかは私には未解決問題ですが、そろそろ考えないといけないな～っと思っている今日日です。

まとめ

長々と書いてきましたが、スプレッドシートそのものはあくまでツールに過ぎません。実際に私が行っている作業を言語化するのは難しいのですが、たぶん:

• プロダクトマネージャーと常に情報を同期して、ユーザー視点機能と技術的機能の構造の差を減らしておく
• プロジェクトの全ての技術的決定事項がどこ/誰にあるか把握して常に答えられる状態を維持する
• 言語化が難しくて判断に時間もかけられないけど、決めておかないとプロジェクトが滞るような細かい事象をひたすら決めて文章・口頭で共有していく (名前を決めたり)
• まだ見つかってない不確実要素を発見する (社内で話をしたり、社外のドキュメントやブログを読んだり)
• 上を全部やってまだ暇があれば、自分でコードを書いて実装を進める

ソフトウェアエンジニアと聞いて想像されるような、集中してプログラミングをしている状態とはだいぶ違います。

プロジェクトのだいたいどの部分を見ても、他の人が自分より詳しいというのは寂しくもあります。とはいえそれを受け入れて、自分の意志を薄く展開してプロジェクトの(つまり他のメンバーの)方向性と同化しつつ大きな秩序を構築していく感覚は結構好きです。

たくさんありますね。いったいclusterはどう発展していくのでしょうか。2020年の発表にご期待ください。

明日の記事は、なんで屋さんの「clusterで遊んだら友達増えた話(予定)」です。