業務委託CTO的な役割を2年近くやって気づいた「30人くらい迄のテックベンチャーで求められること5選」〜その1、開発計画立ててって何すればよいの?〜
【開発計画とは?求められる背景は?】
「まずは開発計画を作って欲しい」
スタートアップ一人目のシニアエンジニアだったり、CTO経験者ならば一度は言われた事があるのではないかと思います。もちろんエンジニアチームを率いるリーダーやフリーランスエンジニアで開発業務を受託した場合でも言われることはあるでしょう。そもそも開発計画ってよく使われる単語ですがしっかり腹落ちする正式な定義はなかなか見当たりません、私も会話の中で聞くことはよくありますがぶっちゃけ何を定義してるのかよく分からない状況のまま話が進んでしまう事は非常に多いです。
ですのでこの言葉を聞いたら要件定義と同じくまずはヒアリングしまくって課題を明らかにするところから始めます、例えば・・
「計画で何を把握したいですか?デリバリー目標?機能要件?費用?」
「計画の需要者は貴方(CEO想定)ですか?それとも他に需要者がいますか?」
「現時点で計画はありますか?計画有無に関わらず開発に関して何を課題と感じていますか?」
まあ大体は「全部必要!」みたいな感じになるのですけどw全部必要ならばそれはそれで構わないので今度は優先順位をつけます。
「属している業界動向と会社のポジションからX月までにY機能の提供が必要、但し資本政策都合からコストはZがリミットとなる」
「まずは自分(CEO)が把握したいが、計画をベースとして投資家へ状況を説明するのにも必要」
「口頭で伝えてる計画はあるがチームが期待通りに成果を出してないので必要性を感じている」
これらも「全部優先!」になりがちなのですが、企業の最終目的は金を稼ぐ事であるのは間違いないので売上向上(または費用削減や投資効率向上)の期待値を何となく付けて優先順位順としてやってくのが良いと思います。
プログラミングする時も同じですが解決すべき課題を明らかにする事がまずは最重要です、企業や環境によって課題の種類や優先順位は異なるのであまり先入観やバイアスを持たないように都度ヒアリングします。事業に関してはCEOの方がよく理解しているはずなので事業の課題をエンジニア目線で説明できる事が抽象的な要件です。
【どういう期待に答える文書要点があるべきなのか?】
少しケーススタディ風に記載したのですが重要な点が幾つか含まれてます。そもそもは自分で作れない(理由は様々あります)から依頼されてるわけなのですが、どういったスキルや判断を求められてるのでしょうか?ここから読み取ると大まかに分けて下記の5点くらいとなります。
1. 必要としている機能はいつまでにどのくらいのコストで出来るか(QCD的な観点)
2. 会社として計画している開発成果にどこまでコミットしているのか(アカウンタビリティ的な観点)
3. 他の開発メンバーに納得してもらい成果に繋げる説明にはどうすればよいか(WBS的な観点と理由付けの観点)
4. 開発による技術的成果が社内外含むインパクトにどの程度繋がるか(製品・採用・資本市場それぞれへの広報的な観点)
5. (もしあれば)取ろうとしているアプローチに不備は無いか?ショートカットできないか?(テックスペシャリストとしての観点)
これらそれぞれについて詳細に応える計画となると作るのが結構大変だと思います。またあくまで計画は計画なので、ササッと作って走り出しながら軌道修正していく方が小規模なスタートアップならば必要とされる事だと思います。以上のことから省エネで最低限必要事項を満たしてそうなフォーマットとして「プレスリリースドリブン開発計画」というのを私はよく使っています。
【PRDD(プレスリリースドリブン開発)パターンとは?】
名前の通りなのですが「X月にYという内容でプレスリリースを打つ」という前提で開発計画を作ります。どこかでProductRoadMapのテンプレを見た時に「大体四半期くらいのタームで」「実現したい要求を記述する」みたいなフォーマットでした。これはもちろん必要なのですが、スタートアップの場合は一つ一つの動きがインパクトを産む必要があると思うので「この要求を満たした新機能
のプレスリリースを打ったらどういう反応になるのか?」という目線だとビジネスサイドや経営陣にも理解しやすいと考えました。ちなみにこれはオリジナルでも何でもなくAmazonでも採用されてる方法なのでご存知の方も多い有名な方法だと思います。更に深堀りするポイントとして先述した「製品、採用、資本市場のどれに向けてのプレスリリースか?」という事を意識すると解像度が上がる気がします。加えるとするならば「業界向け」みたいなリリースもあるのですが、これについては殆ど実利が無いと個人的に感じてるので割愛しています。
【実際に作ってたPRM的な文書】
では実際に作ってみたらどんな感じでしょうか?
例として写真整理SaaSからプラットフォーム化、toCサービスに繋げる場合のストーリーで考えてみました(あくまでもドキュメントの例示として作ってるので企画内容の質についてはご放念下さい・・)
https://docs.google.com/spreadsheets/d/1Ar3cVAO3TzDJywfjI5rJO7K03pHbM2ohRo2Nh_cd7hY/edit#gid=0
この程度なら余裕で作れるよ!という方も多いと思いますが、実際にこういうドキュメントを作ってアップデートし続けるというのは意外と出来てないのではないでしょうか。スタートアップの計画は頻繁に更新されるので、都度この程度の雑な解像度で良いので「今は何をしたいんだったっけ?」が共有されてると迷走を防ぎやすいかと思います。あくまでも提供価値が大事なので最終的にどういう実装や製品になるかはカオスであっても良いと思います。
今回はここまでとして、次回はこのロードマップを基にコスト計画を作っていきたいと思います。