モチベーションクラウドシリーズ（MCS）アドベントカレンダーの15日目を担当するWhiplusと申します。
平日は組織改善クラウド「Motivation Cloud」グローバル版の開発に管理と遂行していますが、休日は世界各地での鉄道旅行に没頭しています。今回は「開発の旅」についてお話ししたいです。
概要
- 開発は旅と同じよう、良い価値と体験を作るプロセスである。
- 無計画の旅と比べて、良く準備された旅はより上質である。三種の神器さえあれば素晴らしい開発の旅を実現できる。
- 開発は、一人の旅よりチームの旅である。重要なポイントは、いつでも視界共有ができている状態である。
開発は、旅である
2013年冬、サンフランシスコからシアトルの列車で、僕は全国ライブツアーをしている黒人ラッパーから話かけられた。
「君は今、どこに行くの？」
「一ヶ月かけて北米を鉄道で一周して、今は最後の都市に行く途中です。」
「君は夢を実現しているんだね！」
そうかな。自分も気づいていないのだけれど、「夢の実現」みたい遠い話は、その時その場で既にできている。世界を変えるほど大きな夢ではないけれど、セントラルパークでピックニックをしたり、グーグルの食堂でご飯を食べたり、一個一個の願望は、一つの旅で現実になっている。
開発も同じではないだろうか？一つのチームで数ヶ月をかけて、顧客の夢を実現することもできる。旅を自分のために最高の体験をつくるプロセスと例えれば、開発は顧客のために最高の価値と体験をつくる旅である。旅支度が必要のものは、開発にも同じく適用される。
さて、開発の旅を準備するために3つの装備、いわゆる三種の神器を紹介しよう。
いや、私はノープランでいきなりの旅をしたい
と思う方も多くいらっしゃるかな？僕も元々はそちらのタイプだ。
行きたいところはたくさんある、食べたいグルメもたくさんある。しかし、時間は有限である。「ああ、時間が足りない！」と叫びながら駅や空港に駆け込むなんて、旅につきものだ。
ノープランの開発も同じではないだろうか。開発しながら、より良い顧客価値や体験を実現するために要件を追加したり、保守性を向上するためにリファクタリングをしたり、やりたいことはいっぱいある。限られた時間で、一人ひとりは無限にやりたいことがあるので、迷走したり、チームメンバーの不信感が増すことはしょっちゅうだ。だから、「なぜ」「どうやって」「いつなに」を一緒に構築し、合意を形成することが大事だ。
三種の神器は、この「なぜ」「どうやって」「いつなに」を定めるために生まれたものだ。
① 第一種の神器「Wishlist」：夢と物語を一緒に語って作ろう
この前も話したが、旅に出れば夢を実現できる。だから旅をする前に、自分がなぜ行きたいなのかを明確化しなければいけない。私の場合は、旅の前に必ずWishlistを書く。
大きな目的や夢も書くし、行ける場所、食べられるもの、参加できるイベント、検証できる仮説...などなど可能なアクティビティも全部出し切る。そして目的を振り返って、そのアクティビティは積極的に行きたいか、絶対に行きたくないか、どうでもいいかを選択取捨する。
最後残ったものは、いわゆるWishlistである。その旅は、Wishlistの項目を実現するために存在する。
開発も同じだ。一つの開発プロジェクトには、必ず目的と要件がある。通常は、プロダクトマネージャーがきちんと完璧に、その目的と要件が記載された「要件定義書」を用意する。
だがプロダクトマネージャーも顧客ではないため、100%顧客の視界で物事を視ることはできないので、チームの力と多様性を発揮し、多種な立場で視界を共有することは大事だ。私のチームでは、「要件定義レビュー」を徹底している。つまり、プロダクトマネージャーが提供した要件定義書をチーム全員で
- 所定の操作が完成すれば目的が達成できるか
- 異常操作に関して要件の抜け漏れがあるか
- 技術上、実現可能か
などの基準で議論し合って、ユーザーの夢（目的）は何か、その夢を実現するための物語（ユーザーストーリー・要件）は何かを一緒に理解し決定する。それによって、よりユーザーの正解と近い要件を決めることができるのみならず、これから一緒に開発の旅を歩む上でも、同じ方向を向くことができる。
プロダクトマネージャーが提供した要件定義書は、あくまで旅の公式ガイドブックだ。皆がより楽しい旅を実現するためには、ガイドブックの基礎の部分で、より充実した「Wishlist」を作る必要がある。
② 第二種の神器「Route map」：地図を理解し、路線を協力して定めよう
おそらく旅に際して、「地図」は一番大事なものではないだろうか。Wishlistで行き先と目的を決めても、地図がないと合理的な路線をアレンジできないという訳だ。都市と都市の距離や交通を理解して初めて、スムーズな旅が実現できる。
開発でも、現状のシステム構造を知らないまま、コンポーネントをいじったら他の画面を崩壊させたり、あるいは、テーブル構造を変更したらシステムデグレードを起こしてしまうかもしれない。だから、開発の設計段階で、今回のプロジェクトと関連する構造を理解しなければならない。私のチームでは、実装前の「設計段階」をすごく重視している。テーブルとコンポーネントの構造や、APIインタフェースの方針は開発メンバーが必ず合意を取る。しかも、旅する前に現地のローカルの人に聞くとより地理や環境を理解できるように、「基本設計レビュー」というベテランエンジニアを招待する設計の合理性を改善する場も設けている。だから経験が浅いエンジニアでも安心に安定的なシステムを作ることができる。
限られた時間で良い顧客価値や体験を実現するためにも、ローカルガイド（ベテラン）と一緒に「Route map」を描く活動は、最短路線を定めることができるのだ。
③ 第三種の神器「Schedule」：時間とバッファを決めるからこそ、柔軟的な時間調整ができる
旅では、「時間」は最大の資源であり、最大の制約でもある。一回でも電車や船に間に合わなければ、旅を全体的に崩壊させ得る。それによって次に行きたい場所や食べたいものも全部駄目になる。だから、守るべき時間を守ることで、旅に自由を与えられる。
開発も、一つの工程で一日の遅延があるだけで、それ以降すべての工程を崩壊させ、リリースが遅れるなどお客様に迷惑かける可能性がある。だから、「Schedule」に対するコントロールはクリティカルである。旅で空港に行く前に2時間ほどの時間を設けなければいけないように、開発の各工程でも、バッファを設けなければいけない。バッファがあるこそ、リリースの遅延の可能性を下げることができるし、仮にバッファなしでスケジュール通り完成しても、より良い仕様の検討や、システムの進化をさせる機会を持つことができる。
私のチームは、エンジニアマネージャー（EM）の用意するスケジュールは毎日共有されるし、経営陣との意思疎通という「開発計画レビュー」もできている。地平線方向の「夢」と足元の「路線」だけではなく、目の前の「Schedule」のマイルストーンがあるから、適度な危機感と達成感を感じられる。
終わりに
以上、開発に旅立つために、用意できる3つの神器を紹介しました：
- Wishlist: プロダクトマネージャーをはじめ、みんなで話し合った決めた「要件定義書」。これは「Why」の神器。
- Route map: ベテランエンジニアを巻き込み、システムを理解した上で作成した「基本設計書」。これは「How」の神器。
- Schedule: 開発者・マネージャー・経営者とつながるマイルストーンを載せた「開発計画表」。これは「When・What」の神器。
新人エンジニアだから、おそらくすでにご存知の内容ばかりを書いておりますが、開発のプロセスはもちろん、より良い旅を作るヒントもなればいいなと思いました。（笑）