レガシーを解決する開発プロセス / Process of development for a problem solving

Transcript

1. Copyright © NHN Techorus Corp. レガシーを解決する開発プロセス
2. Page　2 ⾃⼰紹介 ⾓ 俊和 NHNテコラス株式会社 執⾏役員 SME事業部 事業部⻑ Twitter: @techsmith8 facebook: toshikazu.sumi ・職種：Webアプリエンジニア, インフラエンジニア,   商品企画, マーケター, ビジネスデベロップメント ・業種：10年以上インフラ事業をやっています。 ・趣味：ロードバイク（年間⾛⾏距離10000kmくらい）
3. Page　3 ⾃社紹介 NHNテコラス株式会社 •  ライブドアのネットワーク事業部が⺟体。 •  メインブランド：DATAHOTEL（データホテル） •  インフラ事業者としては2000年から続く⽼舗。サーバ稼働数1万台以上。 •  ホスティング、ハウジング、システムインテグレーション、セキュリティソ リューションなど提供 【沿⾰】 - 2000.04 株式会社オン・ザ・エッヂ のデータセンター事業「データホテル」提供開始 - 2007.04 株式会社ライブドア 設⽴ - 2012.01 株式会社データホテルに商号変更 - 2014.11 テコラス株式会社に商号変更 - 2015.10 NHNテコラス株式会社に商号変更
4. Page　4 今⽇のお話 ・⾃社向けシステム開発が苦⼿な会社が  サービスを短期間で⽴ち上げた話。 ・システム開発プロセスというよりも、  プロジェクトマネジメントのお話。
5. Page　5 ⾃社向け開発でよく起きる問題
6. Page　6 社内向け開発でよく起きる問題（１） •  受託案件はビジネス⾯のメリットが明快だが、  社内向けの開発はメリットが明らかになっていないことが多い •  実態：技術導⼊／ツール導⼊の⽬的化 •  あるべき姿：売上増加、業務効率化、コスト削減、ミスの減少等 •  決裁権のある⼈がメリットを理解できていないため、必要なリ ソースを確保できない（ヒト・カネ・モノ） 問題：ビジネスのゴールが不明確なため、リソースが確保できない 【その結果...】 •  少⼈数・低予算・⽚⼿間で取り組むことになり、⻑期化 •  メリットが不明確なのでメンバーのモチベーションがあがらない •  突然、案件⾃体が終了となることも。
7. Page　7 社内向け開発でよく起きる問題（２） •  ビジネス⾯のメリットは明確。周囲も期待しているパターン •  しかし、誰が何をいつまでに開発すれば良いのか決まっていない •  「とりあえずPoC（概念実証）で始めよう」→仕様が良く変わる。 •  「最近だとこっちの技術の⽅がスジがいいのではないか？」 •  他部署から横槍が⼊って⽅針が変更となってしまう •  「ついでにこれも作ってほしい」 問題：開発内容と体制が不明確なため、頻繁に仕様が変わる 【その結果...】 •  頻繁に「ちゃぶ台返し」が発⽣ •  終わりのない追加開発と改修。⻑期化 •  ⻑期化すると、OSSのバージョンが上がって作り直しになることも •  当然、メンバーのモチベーションはダダ下がり
8. Page　8 社内向け開発でよく起きる問題（３） •  開発すべきものは明確になっているパターン •  開始後に検討漏れが多数発覚 •  当初の想定より⼤幅に⼯数が増加し、計画遅延に 問題：⾒積精度が悪くスケジュールが遅延する 【その結果...】 •  開発担当は社内（偉い⼈）からの信⽤を失う •  結局、⻑期化 •  当然、メンバーのモチベーションは（以下略）
9. Page　9 社内向け開発問題のまとめ 【社内向け開発問題まとめ】 1.  ビジネスのゴールが不明確。リソースが確保できない 2.  開発内容と体制が不明確。頻繁に仕様が変わる 3.  ⾒積精度が悪くスケジュールが遅延 社内向け開発は要件・設計が曖昧なまま開発に進んでしまい、 ⻑期化してしまうことが多い。（＝上流⼯程が弱い） 新技術を⽤いてレガシーを打破したいけど、うまくいかない。
10. Page　10 今回の要求
11. Page　11 経営層からのお題 お題： 「新技術を使っていい感じのサービスを⽴ち上げること」 •  OpenStackを⽤いたインフラ基盤の構築 •  具体的なサービス内容は未定 •  納期は半年（てきとう） •  親会社もうまく絡めてね♡ うまくいかないパターンです
12. Page　12 プロセスの⾒直し
13. Page　13 今回の開発プロセス 1. ビジネスゴールの合意 2. プロジェクト計画の策定 3. 仕様決め合宿 4. 開発〜テスト プロセスを⾒直した結果、問題が解消した。
14. Page　14 （１）ビジネスゴールの合意 【プロセス】 1.  徹底的に現状を調査 2.  ROIの試算。この取り組みがメリットを⽣むことを明確にする（定量） 3.  ビジネス計画を作成し、ステークホルダーの承認を得る。 【ビジネス計画】 •  いつまでに •  何を開発すると •  会社の数字がどう変わるのか（売上増／コスト削減） まず徹底的に現状を調査し、この取り組みが会社にとってどのような売上／利 益を⽣むのかを数字化。開発計画の承認をもらう。 ポイント：計画に説得⼒を持たせるために現状分析に時間をかける。
15. Page　15 具体的なアクションと成果物 【アクション】 1.  競合調査 •  国内外競合50社のサービスを契約して内容を調査。 •  サービスを⽐較表にまとめて特⻑を分析 •  国内外競合のプレスリリース・決算発表資料を分析(10年分) 2.  サービス内容／事業計画を作成 【成果物】 •  競合サービス⽐較表 •  ポジショニング分析、SWOT等 •  リーンキャンパス •  新サービスの機能要素⼀覧（MUST/WANT) •  事業の損益シミュレーション ※単⽉⿊字化と損益分岐点の到達時期 ※今回は事業⽴ち上げのケースなのでマーケティング計画などもありますが割愛 2週間
16. Page　16 効果 【効果】 •  ビジネスメリットを決裁者に理解してもらうこと で、投資を引き出すことができた。 •  ⼗分な予算のもと、⼈数をかけて開発することが できたため、プロジェクトが短期間化した。 •  メリットが明確なのでメンバーの施策理解度が⾼ くなり、ボトムアップで改善提案が出るように なった。
17. Page　17 （２）プロジェクト計画の策定 【プロセス】 1. プロジェクト計画書の作成 •  開発物を細かいコンポーネントに分割し、担当分担 •  チーム、リーダーなどの役割分担の明確化 •  協⼒を得たい他部⾨に役割を付ける（レビュワー等） ※横やりが⼊るのを防ぐ •  会議体など、コミュニケーションのルールを細かく設計 2. キックオフ（計画広報→宴会） はじめに詳細なプロジェクト計画書を策定し、 「ゴール、作業範囲、QCD、役割」の認識をあわせた。 ポイント：関係者に⾃分の役割と責任範囲を認識してもらう。
18. Page　18 具体的なアクションと成果物 【成果物】 •  プロジェクト計画書 •  プロジェクト概要（⽬的、ビジネスメリット、理念） •  品質、コスト、納期の優先順位（QCD） •  体制図 •  会議体設計表 •  会議の⽬的 •  曜⽇／時間 •  ファシリテーター、承認者、参加メンバー •  チーム・役割分担表 •  プロダクトオーナー、チームリーダー、メンバー、レビュワー •  チームごとの開発スコープ •  スケジュール表 •  週単位の⼤⽇程 •  チームごとのWBS 2週間
19. Page　19 効果 【効果】 •  開発要件の認識が共通化できた。  （いつまでに何を開発すればいいのか） •  他部署キーマンに役割を付けたことで、「ちゃぶ 台返し」を防⽌できた。 •  品質・納期の優先順位を明確化したため、仕様決 め議論がスムーズに進められた
20. Page　20 （３）仕様決め合宿 【プロセス】 •  概要：「仕様詰め合宿」を開催 •  ⽬的：サービスのMUST機能要素を仕様に落とし込むこと •  参加者：全員（プロダクトオーナー、開発メンバー、関連会社など） •  期間：キックオフ翌⽇からの5⽇間。朝から晩まで会議室で⽸詰 •  進め⽅： •  主要な仕様を「ホワイトボードに書く」→「スマホで撮影」→「共有」 •  3つの会議室を朝から晩まで抑え、3チームに分かれて打ち合わせ。 •  コーヒーとお菓⼦を随時差し⼊れ ざっくりした要件の状態から設計終了までをキックオフ直後の合宿でやりきる。 短期間で「明⽇から開発が始められる」状態まで持っていく。 ポイント：詰め込み合宿でロケットスタートをかける。
21. Page　21 成果物 【成果物】 •  機能要件表 •  画⾯仕様書（全画⾯） •  シーケンス図（全処理） •  ER図 •  サーバ構成図 •  WBS（開発タスク⼀覧） 【参考：規模感】 •  ⼯数：150⼈⽉ •  開発期間：6ヶ⽉ 5⽇間 ポイント：上記は「ホワイトボード」です。清書は後⽇。
22. Page　22
23. Page　23 効果 【効果】 •  仕様の抜け漏れが最初期に発覚。納期に合うように 要件を調整できた •  システムの全体像が⾒通せる状態になった。 •  企画側・関連会社と合同で全体像を確認したのでそ の後の⼿戻りが少なかった。 •  キックオフ直後に朝から晩まで苦楽をともにしたこ とで⼀体感と当事者意識が⽣まれた。 •  「本当に作るの？」から「本当に作るぞ」に
24. Page　24 （４）開発〜テスト 【ビジネスゴールの合意】 •  関係者のビジネス理解度が⾼い •  ⼗分な予算 【プロジェクト計画】 •  メンバーが望まれている役割を認識  （⾃分が何を開発・発⾔・調整するのか） •  横槍が⼊らない 【仕様決め合宿】 ・⾒積もりの精度が⾼い ・全員がシステム全体像を理解 ・要件の⼿戻りがない ・⾼い当事者意識 スムーズに進⾏。 エンジニアは開 発に専念できた。
25. Page　25 結果
26. Page　26 結果 新インフラ基盤の構築は4年以上難航していたプロジェクトだったが、 体制・やり⽅を仕切り直してゼロスタートした後、半年で終了（⾒込み） 【これまで】 •  期間：4年以上に⻑期化 •  ROI：不明確 •  要件：何度も⼿戻り •  仕様：何度も変更 •  雰囲気：よろしくない 【今回】 •  期間：半年でほぼ完了 •  ROI：明確 •  要件：⼿戻りなし •  仕様：変更なし •  雰囲気：いい感じ
27. Page　27 まとめ キックオフ直後の仕様決め合宿オススメです 1.  受託案件よりもメリットが曖昧な社内向け開発であるからこ そ、上流⼯程に⼒を⼊れることが⼤切 2.  迷いをなくすため、仕様決めは短期間で⽚付ける⽅が良い •  以下の3プロセスに⼒を⼊れた結果、開発がスムーズに進んだ。 1.  ビジネスゴールを明確化し、決裁者の合意を得る。 2.  細かいプロジェクト計画書を作り、役割認識を合わせる 3.  「何を作るのか」を⼀気にまとめきる •  このプロセスは⾃社向け開発全般で適⽤可能 •  コスト削減 •  業務プロセス改善 •  システム移⾏ など