ステークホルダーを巻き込む開発/設計

1. ステークホルダーを巻き込む開
発/設計
Tatsuya Shimada@usaganikki

2. 自己紹介
リクルート住まいカンパニーからきました
最近は新テクTというところでR&Dみたいなことしてます

3. 話すこと

4. スタートアップ的な動きをしていくには？？
- 4月からR&D部隊的なところのリーダー的な立場に
- 短期的、長期的にビジネス課題を解決、付加価値を与えるような技術を見つ
け、その技術、使い方が適切か高速に検証することが必要
- 設計から開発を自由にやりつつ、一緒に考えていく体制が必要
ステークホルダーを巻き込んだ開発/設計

5. スタートアップ的な動きをしていくには？？
・・・をしたいためにやったことです
開発の流れは作れつつあるのですが設計については・・・
もっといい感じのやり方&具体案などがあれば教えてください！！！！！

6. 何をしたか

7. プロダクトのフェーズによって開発/
設計フローを変える

8. 0➡ 1 or 1➡ 100

9. 0➡ 1
サービス立ち上げ時
- ふわっとした要件からエンジニアがつっぱしるのはアリ、だがキーマンには開
発、設計方針を必ず伝える、できれば目に入る位置に現在の全体像がわかるも
のを配置、理解できるものを見せると相互理解が進む
- MVPを達成するために高速で回転するための仕組みを伝えるのがここのポイン
ト、細かい設計は議論しないほうがうまいくいった

10. 0➡ 1
- できるだけシンプル、枯れた設計に従い疎結合を心がける、このときは設計の
例外を作らないほうがピポッドが楽
- リリース後に絶対にリファクタ期間を設ける、ここでいうリファクタは設計から変
更が入るという大きいものであることを必ず伝える
- マイクロマネジメントも困るが、丸投げによる認識のズレも困るので、レビューが
できそうな人をこの段階で探しておくと良い
- 「とりあえず作って」からの「設計なしに走る」は絶対にNG

11. 1➡ 100
サービスグロース時
- プロダクトとしてある程度の成果が出て方向性が大体決まった
- サービスとして何が利用者に刺さるかだいぶわかってきた
- MVPの達成から、品質の向上、価値の付与に、チームの動き方を変える

12. 1➡ 100
ここの具体策がない
- そもそも設計って責任分界点を明確にしてグロースしやすくする材料なのに
フェーズによって変わるものなのか？
- ステークホルダーを巻き込まないと後々めんどくさくなるのは間違い無いのだが
どれくらい巻き込むべきなのか？
- 今は簡単なクラス図を簡単にしたものを見せて設計の合意をとっているつもりだ
が、本当にそれでいいのか・・・

13. 1➡ 100
内部エンジニアと会話した結果
- ステークホルダーに設計に口出されるとか嫌
- 設計って立ち上げ時期とグロース時期で変わるものなの？
- ってかプロダクト次第じゃない？

14. ♂

15. 結論

16. 共通のゴールは持っておく
- 議論をする際絶対に必要になるのはこのプロダクトによって何を達成したいか
- ステークホルダーが多くなってくると、何を達成したいかが決まらないまま動いて
しまいがち

17. 設計を有効に使うには？
- いろんな人と仕事していくうちに設計は無いと絶対に困るということは改めて理
解できた
- フェーズによって設計方針って特に変える必要ってないのかもしれない・・・
- 必要なのはステークホルダーに今何を重要視してプロダクトを作っているかとい
うことでプロセス（設計）は信用してもらうってのが健全？

18. スタートアップ的に動くには
- エンジニアとして信用してもらう！
- 現在の進捗、プロダクトを常に見えるシステムを作れば信用は得られる！
- こっちがスタートアップ的に動けばステークホルダーがボトルネックになるので非
常に動きやすくなる！
- あきらめないこころ！！！