物事を検討する際のアプローチ
今日はシステムエンジニアに関するネタです。
何か物事を検討する際、まず最初に検討対象を把握してから検討する必要がありますよね。
若手の内は先輩が検討すべき対象を切り分けて指示してくれると思いますが、経験を積んでいざリーダーやプロジェクトマネージャーを任されると、自分で物事を整理し、作業を分割して、メンバーに仕事をお願いしながらプロジェクトを進めていくことになります。
そのような仕事の仕方に慣れていない初心者の方向けに、物事を検討する際の基本的な考え方をお教えします。
例えば、新たなプロジェクトを受注する為に、お客様向けに提案資料を作る必要が発生したとしましょう。
提案資料では色々な事項を盛り込む必要がありますが、今回は簡略化のため「スケジュールの」作成を例に取ります。
尚、スケジュールの作成にあたっては、大きくウォーターフォール型のアプローチとアジャイル型のアプローチがありそれぞれ進め方が大きく異なりますが、今回はウォーターフォール型のアプローチを前提とすることにします。
「スケジュール」の検討をはじめ、物事を検討する際は、まず全体像を抑えて、それぞれの構成要素を詳細化していくというアプローチを心がけることをおすすめします。
とかくシステムエンジニアの方に多いと感じるのですが、システムエンジニアは各々得意な領域があることから、自分が得意で思いつくところから書き出していく方がいらっしゃいます。そのやり方で進めると、自分の得意な領域だけすごく詳細で、それ以外の事項が漏れたり考慮が足りないという事態に陥りやすいです。
実は私も若い頃はそのようなタイプで、上司から「視野が狭い！」と注意されたこともありました。今なら上司が言っていた意味が分かります。「やみくもに自分の得意なところだけ考えるのではなく、まずは全体を整理して考慮漏れがないように考えなさい」ということですね。
ちなみに、当時の私は「視野が狭いってどういうことだろう？」と正直あまり分からず、とりあえず「はいっ！すみませんっ！！」と謝ってその場をつくろい、そしてまた迷走し怒られる、というタイプでした。原因の深堀りや学びを考えることをしないと事態は好転しないですね（苦笑）。
まず全体像を抑えて、それぞれの構成要素を細分化していく
もしかしたら「何を当たり前なことを・・・」と思われる方もいらっしゃると思いますが、私も経験があるのですが、意外と目の前の仕事に直面すると基本が疎かになることもあると思います。
かなり昔の話ですが、私は合気道を習っていたことがあります。
合気道では”基本動作”という、一人で行う体の使い方の型がいくつかあり、毎回稽古の一番最初にその動きを練習します。実はこの基本動作はどの技にも通じていて、基本動作を極めるとどんな技でも繰り出することができるということで、「基本こそ奥義」という話を聞いたことがあります。
私はこの言葉を聞いた時に「奥義と呼ばれる一番すごい技は、実は一周回って一番最初に覚える基本的なことを極めた先にあるんだ」ということが強く印象に残り、何か壁にぶつかった際にはこの言葉を思い出して基本に戻ることを心がけています。
Step1. まず全体像を抑える
まず最初にやるべきことは、全体像を抑えることです。
思いついたことを並べるだけだと漏れが発生しやすくなりますので、まずは全量を抑えたぞ、という区切りを持ちましょう。そうすることで、大きな漏れが発生しにくくできます。
自分の頭の整理の為に、まずは紙やPC（テキストエディタ・Excel・マインドマップなど）を用意して、今回検討すべきことを端的に書き出しましょう。
今回の例で言えば、「スケジュール」です。
次に「スケジュール」を構成する要素を洗い出します。
その際に注意すべきことは、漏れや重複がない状態で構成要素を洗い出すことです。よく言われるMECE（ミーシー、「Mutually Exclusive and Collectively Exhaustive」の略）で構成要素を洗い出すということです。
構成要素をMECEで洗い出す際には、できれば何かお手本になるものがあるとやりやすいです。
なぜなら、自分で一から全部考えようとすると、非常に時間が掛かったり、（考慮が及ばず）漏れが発生しやすくなるためです。
今回の例で言えば、システム開発プロジェクトにおけるウォーターフォール型のスケジュール（全体のスケジュールのことを特にマスタースケジュールと呼びます）は型がある程度決まっています。
例えば、以下のように分けられます。
- アプリケーション開発：今回導入するシステムや、それに伴う業務の流れを検討し、システムを形にするメインの一連の作業。
- インフラ構築：新システムの実行環境（ネットワーク・ハードウェアなどのインフラや、ミルドウェア製品などの基盤）を用意する一連の作業。
- ユーザー教育：新しいシステムの利用や新しいシステムを前提とした業務に変更するにあたり、ユーザーと業務やシステムの使い方を共有する一連の作業。
- 運用保守：新しいシステムに対するIT担当者の運用保守作業を整理・手順化する一連の作業。
- 移行：現行システムから新システムへの切替や、データの移行を行う為に、移行の段取り・手順・ツールを整理して、事前確認のうえ移行を行う一連の作業。
- 他システム対応：データ連携を行う他システムに対して改修や運用の変更が必要ある場合、他システム担当者に対応してもらう一連の作業。
プロジェクトによっては、これ以外の作業が発生するものもありますので、どれにも当てはまらない場合は追加します。
Step2. それぞれの構成要素を詳細化していく
次に、それぞれの構成要素を詳細化していきます。
今回の例で言えば、
- 「アプリケーション開発」には、システムに対する要件の詳細化や概要を定める”要件定義”、要件を実現する為の具体的な実現方法を考えて仕様に落とし込む”設計”、仕様を基にプログラムを開発する”開発”、開発で作成したものが要件や仕様を満たしているかを確認する”テスト”、のような作業があります。
- 「インフラ構築」には、インフラや基盤に対する要件の詳細化や設計を行う”基盤設計”、設計内容を基に環境を用意する”基盤構築”、環境をアプリケーション開発担当に引き渡して開発・テスト作業を支援する”基盤保守”、のような作業があります。
- 「ユーザー教育」には、ユーザーに対して新しいシステムや業務の概要に加え導入スケジュールやユーザーにやってもらうことを共有する「広報」、ユーザーマニュアルの作成やユーザーへの説明会を実施する”ユーザートレーニング”、システムリリース前にユーザーに使用感を確認してもらう”ユーザー受入テスト”、のような作業があります。
- 「運用保守」には、新システムに対する運用保守作業を整理する”運用設計”、各作業に対する手順書やツールを用意する「運用準備」、作成した手順書やツールを使って想定通りに作業できるかを確認する「運用テスト」、のような作業があります。
- 「移行」は、移行対象を洗い出してそれぞれの移行方式を整理したり移行全体のスケジュールを整理する”移行計画”、移行計画に基づいて手順書やツールやタイムスケジュールなど移行作業時に必要なものを作成する”移行準備”、作成したタイムスケジュール・手順書・ツールを用いてリハーサルを行い妥当性を検証する”移行リハーサル、実際にシステム切替やデータ移行を行う”本移行”、のような作業があります。
- 「他システム対応」には、新システムと既存他システムとのデータ連携において、連携方式やインターフェース（データ構造やデータ項目）や実行時間などが変わる場合は、他システム担当者に変更点を伝えて改修してもらいます。そして「アプリケーション開発」の”テスト”工程（その中でも外部結合テストと呼ばれる作業）にて、想定通りに連携できるかテスト環境で検証します。
このようなやり方を取ることで、漏れや重複を防ぎながらスケジュールを作成することができます。
また、自分が詳しくないところは、詳しい人に意見やアドバイスを求めてより精度をあげることもできます。この際、全体像と何について聞きたいかが明確になっているので、アドバイスする側も話しやすいというメリットもあります。
まとめ
物事を考える際は、まずは全体像を抑え、それぞれの構成要素を詳細化していくというアプローチを心がけましょう。
とかくシステムエンジニアは、自分で思いついたことをただ列挙していくことで、得意な領域は詳細に洗い出されるものの、全体としては大きな漏れが発生する、ということが起こりやすいです。それを防ぐ為にも全体像を描いてから徐々に詳細化するアプローチをすることで、漏れや重複を防げます。
また、構成要素の洗い出しや詳細化する際には何かお手本になるものがないか探してみましょう。お手本があると、作業時間の短縮、漏れの発生確率を抑える効果があります。お手本を基に今回の事案に当てはめて、検討内容を精緻化しましょう。
ちなみに、プロジェクト全体のスケジュールの立て方のお手本については、私のバイブルの大場さんの本に具体的に記載されています。
マスタースケジュールの作り方、そこから詳細スケジュール（中日程やWBS）の作り方のアプローチが具体的で分かりやすく記載されています。プロジェクトの見積や計画を立てる際は、これを見ながら作成すると成功確率がぐっと上がると思います。
ゼッタイ失敗しない！驚異のプロジェクト実行術 準備編～始める前に押さえておこう（日経BP Next ICT選書） Kindle版
コメント