システム開発におけるディレクションのすゝめ / the way to direction

今後、リーダー、ディレクター、マネージャをやる方向け。
* ディレクションとは？
* システム開発におけるプロジェクト(案件)の進め方。

Transcript

1. Copyright © Xchange Solutions All right reserved. システム開発における ディレクションのすゝめ 株式会社エクスチェンジ ソリューションズ 2017/08/02 野田 健夫 Fukuoka.php Vol. 23
2. 2 Copyright © Xchange Solutions All right reserved. こんにちは！ 野田 健夫（のだたけお） https://twitter.com/nodatakeo https://www.facebook.com/nodatakeo 株式会社エクスチェンジ ソリューションズ
3. 3 Copyright © Xchange Solutions All right reserved. 今日の話 今後、リーダー、ディレクター、マネー ジャをやる方向け。  ディレクションとは？  システム開発におけるプロジェクト(案件)の進 め方。
4. 4 Copyright © Xchange Solutions All right reserved. ディレクションとは？ 目的に到達するためにプロジェクトの企画、 構築、運用など幅広い視点に立ち、円滑に 業務を推進するために情報を整理し、それ をもとに指示・判断を行うこと。 分かりやすく言えば… 現場を監督すること
5. 5 Copyright © Xchange Solutions All right reserved. ディレクターの役割 目的へ導く手引きをするプロフェッショナル。 目的への到達に必要な情報・リスク管理を行 い、指示・判断するのが主な仕事。 チームが抱えるリスクを最小にし、未然に問 題を防ぐ。
6. 6 Copyright © Xchange Solutions All right reserved. ディレクションとマネジメント ディレクションとマネジメントは表裏一体。 ディレクションは、最終的な成果物を実現 するための意思決定や判断、指示に重きを 置く。 マネジメントは、管理や組織など人に重き を置く。
7. 7 Copyright © Xchange Solutions All right reserved. まず第一に お客様、開発メンバー、パートナーなど 関係各所と立場は違ってもゴールへ向か うために対等に話ができる関係を作る。 問題を明確にできない関係だと、プロ ジェクトが失敗する可能性が飛躍的に高 まる。 日ごろから関係づくりを大事に行う。
8. 8 Copyright © Xchange Solutions All right reserved. 要求・ヒアリング 目的（ゴール）の設定を行う。 何のためのシステムか明確にする。 目的は一つでも解決手段（ソリュー ション）は無限の組み合わせがある。 どうしてそのように至ったのか本当の 目的を引き出し、お客様に最適と思わ れる提案をできるようにする。
9. 9 Copyright © Xchange Solutions All right reserved. オレゴン大学の実験 http://itpro.nikkeibp.co.jp/article/COLUMN/20080828/313626/
10. 10 Copyright © Xchange Solutions All right reserved. 見積もり・要件定義 「予算」「成果物」「納期」といった 条件や制約事項を明確にする。 基本的に要件定義がある程度まとまっ た段階で工数を出し、見積もりをする。 不確定要素があるときは、前提条件を つけ、全体の工数がぶれないようにす る。
11. 11 Copyright © Xchange Solutions All right reserved. 要件定義の重要性  お客様と我々の持っている認識の差を埋めるた めのものである。  関係者全員が制作にかかわる定義(スコープ)と して明確に認識できるものでなければならない。  この時の定義内容は、お互いに齟齬がないよう 徹底的に何度も共有する。  不足があった場合は、次期追加案件やスケ ジュールの調整を引き出すための担保になるの で手を抜かない。
12. 12 Copyright © Xchange Solutions All right reserved. 要件定義時に気を付けるポイント  用語を正しく使う。表記の統制が取れていないと誤解のもととなる。  アクセス速度、データ容量などSLA(Service Level Agreement)を忘 れず定義すべし。  お客様から性能は出てきにくい。過去の経験から類推する。  パフォーマンス劣化など、システムのサービスレベルに影響する要 件・仕様は慎重に取り決める。  物にはすべて、費用対効果がある。明らかにパフォーマンスが劣化する要望につ いては、説明を行い、仕様、要件を変えるよう進言する。  システム化するか、手作業にするか、保守作業とするか。  必ず毎日、毎月、毎週など定期的に発生する作業は要件に含める。  保守にかかわっている場合、手作業はできるだけ減らす。
13. 13 Copyright © Xchange Solutions All right reserved. 要件定義の標準規格  Concept of Operations (CONOPS)  どのように運用されるかを記したもの。  システム要求を明示。  IEEE1362-1998  Software Requirement Specification(SRS)  どのようにシステム化するかを示したもの。  IEEE830-1998 機能とか用語とかインターフェイスとか性能とかいろいろあ りますが、「目的」は絶対に外さないように注意！
14. 14 Copyright © Xchange Solutions All right reserved. それって本当にできるの？ 技術的裏付けをとる。 リスク要因は、制限事項を設定する。 過去の実績、事例を積み上げて実現可 能性を高める。
15. 15 Copyright © Xchange Solutions All right reserved. 工数の出し方 開発フェイズの各作業を分割していく形で 工数を割り出し、積み上げる(WBS) 1. 要件定義 2. 設計 3. 実装 4. テスト 5. リリース ※基本3人日以上の内容は分割する。 ゴールまでの道筋をつける
16. 16 Copyright © Xchange Solutions All right reserved. 見積りの前提条件 見積もり時の必要情報が不十分な場合も多い ため、そのときは必ず前提条件を記載する。 • デザインについては、簡易的なものはこちらで用意します。デザイン 化が必要であれば別途お見積りいたします（管理画面等の場合） • サーバーインフラ構築、運用費用は含まれておりません（先方から提 供を受ける場合や特に指定がない場合は、明示的に記載）。 例：
17. 17 Copyright © Xchange Solutions All right reserved. スケジュールの作り方  WBSをもとにアサインされる人員を加味してスケ ジュールを組む。  マイルストーンを必ず明確にする。  環境提供や接続テストなど自分たち以外の外部の動 きもスケジュールに含める。  ボトルネックとなるタスクが発生しないようスケ ジュールを行う順序を考えて組み込む。
18. 18 Copyright © Xchange Solutions All right reserved. チーム結成 KICK OFF MTGは必ず行う。新たなメン バーが追加される際には、それぞれの役割 を明確にするためにも打ち合わせの場を設 ける。 プロジェクトの成否はスタートにかかわる 部分が大きい。道筋が明確なほどメンバー が道を外れるリスクを小さくできる。
19. 19 Copyright © Xchange Solutions All right reserved. 進行管理  定期的に開発環境に最新モジュールを反映し、状況をディ レクター自身が把握できるようにする。  予定は、必ずしも当初立てたものの通りに進まない。  追加されたタスクはうやむやにせず、しっかりスケジュー ルへ反映する。  スケジュールの組み換えは「悪」ではない。プロジェクト の進行とともに変化があるのは当然のことである。スケ ジュールは正しい情報を反映し、場面ごとに判断できるよ うにする。  現実から乖離したスケジュール管理はチームを疲弊させ、 無理をさせ、その結果、事故につながるので注意。
20. 20 Copyright © Xchange Solutions All right reserved. 問題解決の方法 人を投入することで解決できる方法も ある。 お金は、物事を解決する手段としてい ろいろなことに使えるが、これに頼る のは最後の手段。 問題解決はあとになればなるほどこじ れるので、注意！
21. 21 Copyright © Xchange Solutions All right reserved. リリース 納品物とスケジュールを守る。 リリース時も事故が起こりやすい。リリー ス手順を作成するなど、事前につぶせるリ スクを排除して細心の注意を払う。
22. 22 Copyright © Xchange Solutions All right reserved. さいごに  プロジェクトは一人の力では成功しない。多く の力によって支えられていることを忘れない。  人は感情に動かされる。ときに杓子定規でなく、 柔軟に。  問題の多くはコミュニケーションの問題。様々 な壁を取り払って目的を達成しよう。  プロジェクトの進め方を知っていると人生のい ろいろな場面で役立ちます！