サービス開発に関わる人（プランナー/プログラマー/デザイナーなど誰でも）がよりよいサービス開発のあり方について、お題になった本を通じて、共通認識をもったり知識を交換したり、建設的に議論したりするための読書会用資料です。 2012年4月からは「アジャイルサムライ」。本資料は読書会第3回の分です。 具体的な進め方の策定について。

1. サービス開発者の読書会
by ConnectStar
2012.5.8

2. アジャイルサムライ5章
具体化させる
1. 技術的な解決案を描く
2. リスクの検討「夜も眠れない問題」
3. 期間を見極める
4. 何を諦めるべきかはっきりさせる
5. 何がどれだけ必要なのか

3. 1.技術的な解決案を描く
• コネスタでは、エンジニアに完全に
一任しているよね。いいね。
• 受託じゃないから新しい技術に
チャレンジしやすいのかな？
今のスタイルの問題点ってある？
（10分）

4. 1.技術的な解決案を描く
今のスタイルの問題点ってある？
• アーキテクチャ図を出す目的ってなんだ？
• 開発レベルのリスク管理に関しては、PJチーム
毎じゃなくて、エンジニア間で横断的にやった方
がいい？
• 例えば、使っているフレームワークを理解してい
て、そのフレームワークの最新の情報をゲットし
たら、誰でも共有できるように。
→常に最新のバージョンにするポリシーにする？

5. 1.技術的な解決案を描く
今のスタイルの問題点ってある？
• アーキテクチャ図を出す目的ってなんだ？
→なんとなく共有する？全体像を把握するためにも？
→今も、スマフォアプリを作るためにどの技術を選ぶ
のか？を全員で意思決定しているじゃん！！
→iOSのバージョンのことまではやってないよね。こ
の件はマーケティングに関連することでもあるし、今
後はやった方がいいのかも！？
→何を相談すべきは、エンジニアが判断して積極的に
議題に上げるようにする。

6. 1.技術的な解決案を描く
今のスタイルの問題点ってある？
• アーキテクチャレベルで話するのは、今後の戦
略を練る上でも重要だし、プロデューサー側で
も、最低限の知識を持っておくべき。
→勉強会とかもっと引き続きやろうね！
• ただ、ちゃんとした紙に落とさない、ホワイト
ボードにすぐに落とせるレベルでよい。
• 諦めない！話す！（どうせ分からないじゃん諦
めない。）

7. 1.技術的な解決案を描く
今のスタイルの問題点ってある？
• svn→gitに一斉に切り替えるようなものは、サービ
スレベルでなくて、コネスタの方針的に捉えて取り
組む必要がある。（他herokuやるか？Redmine止
める？githubとか）
→決定したら、導入・移行のタイミングをきちっと
決めてロードマップ化する。(今週木曜日)
→採用にも関わってくるよね。
• ただ、ここら辺は基本的には、開発を始める前に決
めておくべき？見直しを半年に一回くらいしよう。

8. 2.
リスクの検討
• ここでいうリスクって外部要因の
リスクの事かな？
2Cサービスならではの
リスクって何だろう。
（20分）

9. 2.リスクの検討
2Cサービスならではのリスクって何だ？
• 新しい技術の取り入れに想定以上の時間
かかる。
• 新しいiOSの対応
• FacebookAPIの変更
• Amazonのサーバーのトラブル
• DBの管理
• 個人情報の流出

10. 2.リスクの検討
2Cサービスならではのリスクって何だ？
• 事業パートナーとの契約の問題
• ユーザー数が大量でパンクする
（うれしい悲鳴）スケーリング
• アプリの審査に通らない
• 今は限られたリソースの中で出来る限り
対応してるはず！

11. 3.
期間を見極める
• 6ヶ月ってながいよね。
我々は？
→α版の初期開発は3ヶ月でがよい感じ？
→次の章でやり方の方法が出るよ！
フリーディスカッション
（10分）

12. 4.
何を諦めるのか明確に
• 時間・品質・予算→リソースは固定で
スコープで調整する。
• でも、自社サービスで最も大切なもの
は「捉えどころのないもの」なんじゃ
ない？

13. 4.
何を諦めるのか明確に
「荒ぶる四天王」と「とらえどころのな
いもの」間のトレードオフの考え方
（20分）

14. 4.何を諦めるのか明確に
荒ぶる四天王」と「とらえどころのないもの」間の
トレードオフの考え方
• 「時間」とはリリース締め切り日の
事？ずるずるやらないって決める
→自社サービスだとズルズルなりそう
な事がリスク
例えば、運用に入ったら、今週末にリ
リースするってことを意識しつつ、ス
コープを毎日見直す。

15. 4.何を諦めるのか明確に
荒ぶる四天王」と「とらえどころのないもの」間の
トレードオフの考え方
• 週末リリースの締め切りを意識
• スコープを毎日見直す
• でもコアとなる「とらえどころのな
い∼」が実現できないのであれば…
• ここで、締め切りを延ばす事を検討

16. 5.
何がどれだけ必要か
• 2Cサービス開発では、チームメンバー
「顧客」役割の人材の確保が難しそ
う。
ペルソナで仮定・妄想するしかない？
もっといい方法はないか？
（10分）

17. 5.何がどれだけ必要か
ペルソナで仮定・妄想するしかない？
もっといい方法はないか？
• ステークホルダーの立ち位置がエンド
ユーザー？
• 意思決定を下す、「顧客」の役割は私
たちがやるしかないのか。

18. まとめ
• 4章の部分がきちっと決まってされ入れ
ば、5章の部分は自社サービスの場合は
とても柔軟に自立的に実行できる。
• ただし、甘えが生じる可能性もあるの
で気をつけろ！
• リーンの勉強をしてから我々なりの手
法を具体的に落として行きたい。

19. Keep
• 事前に資料を作った。
• 時間通りに終った。
• 毎週やってる！
• アジャイルサムライに飽きてない！

20. Problem
• 最初の盛り上がりが…
• 本読んでるけど、内容忘れてる

21. Try
• 最初に前回のKPTを見よう！
• ゲストよぼう！
• もし読んでても、もう一度、直前に読
もうぜ！
• 幹事は告知しよう