オープンセミナー岡山 2017.5.13

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. 「何を作るのか」を一気にまとめきる
• このプロセスは自社向け開発全般で適用可能
• コスト削減
• 業務プロセス改善
• システム移行
など