作業リストを作る
プロジェクトの作業リストを作成するためには、次の２つのパターンがあります。
プロジェクトの作業を、その手順を考えながら詳細化する（作業手順で分解）
プロジェクトの成果物を分解することで、それを作成する作業が洗い出される（成果物で分解）
しかし、作業手順で洗い出しを行うと成果物に漏れが起こりやすく、また成果物視点で作業の洗い出しを行うと「どうやって成果物を作るのか」が曖昧になってしまうというデメリットがあります。
では、２つのパターンそれぞれの弱点をカバーするためにはどうすればいいのでしょうか。
すべての作業は成果を生み出すためにある
聞きなれない言葉ですが、対訳されていない原文には"deliverable"という言葉があります。読み方は、デリバラブル(デリヴァラブル)。
意味は、直訳で「届けることができる」「提供できる」「もたらすことができる」となりますが、意訳では
納品物および、納品物に直接関係する要素成果物
となります。
そもそもマネジメントの概ねの対象となっている請負契約プロジェクトですが「請負」契約である以上、ビジネスにおいて検収対象となるのは作業や頑張り、努力ではなく、
結果、成果、成果物
にしか支払い義務がありません。
これは法律が定めているものであり、契約にて明確に上書きしない限り遵守しなければならない大原則となります。
請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。
すなわち、deliverableだけに対価を支払っているということになります。裏を返せば、最終的に納品物に関係する活動以外で請求することはできないということです。
ではみなさんは、上司やリーダーあるいはお客さまから依頼されている作業や、求められている成果物の一つひとつが「確実に」「100%」
納品物を作り上げるために絶対必須である
かどうか吟味したことはありますでしょうか？
たとえば、雑談や談笑交じりの会議体や、結論が出ても出なくてもどっちでもいい定期的な会議体などは、本当に納品物をお客さまにお届けするために必要不可欠なものでしたか？
たとえば、なんとなくお客さまにWBSを渡されて「当社はいつもこれを作ってもらっているので」と言われて、その作業に対して工数を見積もるだけで、本当に納品物作成のために必要な中間成果物であるという認識で対応していましたか？
プロジェクトで失敗する要因の１つに、"deliverable"と各作業や各中間成果物との相関関係や因果関係、依存関係を検討もせず、言われたことをただ言われるがままに受入れ、なにも疑わず、言いなりになっているだけの作業と化していることが挙げられます。
コンサルティングや要件定義などの提案活動を行う者は与えられたものとを与えられたまま受け入れるのではなく、まずはその妥当性と正当性を検討、検証し、本当にお客さまの要求を満たすために必要なことであるかどうかを判断しなければなりません。
しかし、そう言った視点でプロジェクトに取り組めるマネージャーと言うのは極わずかです。
技術的には決して特別なことをするわけではないのですが、だからと言って今までしてこなかった人が急に「やれ」と言われても、その面倒くささと、大変さをイメージしただけで立ち竦むのもわかります（慣れてしまえば大したことでもありませんが）。
そこで重要となってくるのが、先ほどの２パターンのいいところだけを組み合わせたハイブリッドＷＢＳです。
ハイブリッド式では、
どちらかのパターンを“主軸”にし
もう一方のパターンでそれを“補強”する
という組み合わせ方になっています。
では、どちらのパターンを“主軸”に据えるべきなのかみなさんはお分かりになるでしょうか？
正解の前に、いま一度 “プロジェクト”とは何かを振り返って見ましょう。
プロジェクトとは「ある期間の中で独自の成果を生む活動」です。
つまり、プロジェクトにおけるすべての作業は最終的な成果物を生み出すために行われ、逆に最終的な成果物に繋がらない作業は一切必要としません。
なんとなく「必要だ」と言う人はいますが、明確な根拠はありません。少なくとも国際的な標準化機構の中では「成果につながらない仕事は、プロジェクトの活動とは認めない」としています。
それに異を唱えるのであれば相応の根拠の提示が必要ですが、私には無理です。どんなに異を唱えたところでその内容が正しいことを証明する論拠を持ち合わせていません。
従ってプロジェクトでは「作業はなにか？→作業によって生まれる成果物はなにか？」ではなく、
「最終的な成果物を構成する成果物はなにか？
→それらの成果物を生み出すための作業はなにか？」
の順番で考えた方が非常に効率的です。
なぜなら前者の順序の場合、生み出される成果物とプロジェクトの最終的な成果物を見比べて過不足を検証し、その結果によっては作業を見直すことが必要になってくるからです。
よって、正しくはハイブリッド式では成果物で分解する方法を主軸にします。そして、分解された成果物を“骨格”とし、それらの成果物をどのように作るのかをパターン１の作業手順の分解によって“肉付け”していくのです。
なお、ここまで話をシンプルにするため“成果”＝“成果物”として説明していますが、プロジェクトの成果は必ずしも“モノ”ではない場合もあります。
たとえば、新サービスを提供する体制の構築など“ヒト”が対象になるケースもありますし、意識の改革や知名度の向上といった直接目に見えない価値を求めるプロジェクトだってあります。
状態の変化が成果となっていることもありますが、どちらにしても監視または測定が可能な状態でなければなりません。
これらは「新しいモノを手に入れる」というより「変化によってある状態を実現する」ことで成果を生み出すプロジェクトであると言えますが、そのような場合は「最終的に実現すべき状態」を出発点として変化させる“領域”を細分化することで成果物と同じように分解することが可能です。
たとえば、新体制を構築するプロジェクトでは“営業”、“事務処理”、“顧客サポート”など役割の領域を分割していけば良いのです。
作業手順を分解するための“基本形”
「成果物を分解した上で、各成果物を生み出すための作業手順を肉付けする」ということは分かりましたが、ここでまた困ってしまいます。
一体、作業手順をどうやって洗い出せば良いのでしょうか？
その一つの考え方として、成果物がどのような作業の流れによって作られるのかその“基本形”を知っておくと便利です。
この考え方は、みなさん概ね持っているかと思います。
持ってない人は、まだマネジメントをしたことがない新人や担当かも知れません。
たとえば、「〇〇設計書」と言う成果物を作業リストに載せたとします。
実際には、ステップ１として「検討や準備」あるいは事前に「調査」する時間も必要になるかもしれません。まずは行動を開始するために必要なインプットの収集と段取りを決めることは誰しもが考えることでしょう。
特に現行システムからのリプレースなどの場合、現行システムの設計書や仕様書が破損、劣化しているとプログラムソースからのリバースエンジニアリングをしなければならないケースも少なくありません。
こうした作業を想定もせず、工数を見積り、予算をはじき出すと確実に
赤字化またはトラブルプロジェクト
に陥ることになります。
そして、必要な情報（インプット）が揃い、それらを活用する段取りが確定すれば設計書の作成に取り掛かります。
しかし、成果物は作成して終わりではありません。
多くのエンジニアが進捗報告で冒す過ちが、ステップ２の「実施」が完了したら…すなわち「作成が終わったら100%だと思っている」点です。進捗はその作業リストが完全に完了し、次の作業リストに取り掛かっていい状態となって100%です。
作業がただ完了しただけでは欠陥や不良を積み残したまま先に進む結果になりかねません。そうした問題を先送りにすればするほど手戻りコストが大きくなることは20年近く前から延々と言われてきたことです。
しかし、エンジニアの中には"作る"ことしか頭になく、進捗報告当初には残作業を甘く見積もって高めの進捗率を報告する傾向があります。
これを"90%シンドローム"と言います。
この症状は、成果物の作成だけでなくいたるところで発生します。
たとえば、テスト工程においても「テスト項目の消化率」だけで進捗を報告しがちですが、それで成立するのは１件も不具合が出なかった時だけです。１件でも不具合が発生した瞬間、不具合対策の工数が発生し、大幅にスケジュールに影響を与えることになってしまいます。
そして、ステップ３でレビューなどの「チェック」を経て、「承認」してもらわなければなりません。
作成者自身の思い込みが混入しないようにするため、必ず第三者がチェックする必要があります。プログラムソースでさえ、クロスチェックやペアプログラミングと言う手法が考案された歴史があるのはそのためです。にもかかわらず「自分だけは大丈夫」という人が後を絶ちません。後になって問題が発見されればさらに工数がかかることになります。
それらが完了して、初めて次の作業に移れます。
中には、こうした取り組みをしないままに作成者の自己満足で進めさせるプロジェクトもあるかも知れませんが、そうしたプロジェクトでは稀に次工程以降や納品後にとんでもない事故を起こして、お客さまや周囲に迷惑をかけることが起きていませんでしょうか。
２つの注意点
ここまででハイブリッド式の基本的な考え方が掴めたかと思いますが、注意すべき点が２つあります。
共通化できる成果物はまとめておく
１点目は、成果物を分解する際の注意点です。
それは、「別々の成果物を構成するものであっても、共通化できる成果物はひとまとめにしておく」ということです。そのことによって、実際に作業を行う際に同じことを何度も行わなくて済み、効率的に作業できるためです。
たとえば、夕食にチキンカレーと肉ジャガを作ることになったとします。
（現実にそのような組み合わせが嬉しいかどうかは別として、たとえば翌日以降のために作り置きするかもしれませんし）ジャガイモとニンジンは同じ材料が使えるので、まとめて皮を剥いて切り分けてしまった方が効率的です。
このような場合には、上図のように共通的なものを抜き出して“共通材料”などとしてひとまとめにしておきます。部品化し、再利用性を高めることで「品質」と「効率」をバランスよく向上させることが可能になります。
こうした考え方をオブジェクト中心アプローチ（OOA）と言います。
オブジェクト指向のエッセンスを取り入れることで、より業務は制度と生産性を上げていくことが可能になります。オブジェクト指向と言うと、どうしてもプログラムの構成で難しく考えるものだと勘違いしがちですが、オブジェクト指向の根源は、私たちの生活モデルから既にあるもので何も特別なものではありません。
たとえば既製品の衣服などがまさにいい例です。
ファッションモデルなどが着ている服を見て、体型や身長などが同じサイズのものを購入される人がほとんどですよね。これは同じ体型（インターフェース）であればほかの人（オブジェクト）でも継承できるということです。
また同じデザイン（クラス）の衣服のコンセプトを継承していれば、色の組み合わせや素材などを変更しても基本的に再利用が可能という多態性（ポリモーフィズム）を持っているという点も同じです。
オブジェクト指向はむしろ普段の考え方と親和性が高いものですので、日頃のありとあらゆるところで取り込むべき考え方といえるでしょう。
ただし、こうした共通化（正規化）された再利用可能な部品は、時としてボトルネックになりかねないことにも注意しておかなければなりません。共通化したがために、その作業が遅れると、影響を受けるほかの作業も増え、致命的な遅延となりかねないデメリットも持ち合わせます。
だからこそ、共通化した部分などは
一番優秀なメンバーを充て
一番外的要因による影響を受けにくい環境を用意し
一番確実に計画通り完了させられるように配慮する
必要があります。チームとしてそのサポート／マネジメントができないのであれば「冗長工数を承知で共通化を断念する」「リスクを承知で共通化を強行する」しかありません。前者であれば確信犯的に工数・コストを食いつぶしていくことになりますし、後者であれば予期せぬトラブルが発生したときに右往左往する覚悟が必要となります。
どの単位で4ステップにするかを考える
２点目は、作業手順を洗い出す際の注意点です。
それは、必ずしも分解された成果物すべてに4ステップの作業が必要となる訳ではないという点です。
先ほど説明した４ステップは基本形ではありますが、当然すべてがそうなるわけはありません。何事も例外や応用と言うものはあります。
たとえば、夕食を作るときに「チェック／承認」をすべての成果物に対して行うと、
「お母さん、玉ネギの切り方はこれで大丈夫でしょうか？」
「お母さん、チキンの大きさはこれで良いでしょうか？」
「お母さん、ライスの量はこんなものでしょうか？」
と、ほぼ嫌がらせみたいになってしまいます。しかも最初の１回だけでなく、毎日毎食ごとに同じことを確認していたらお母さんはノイローゼになってしまうかもしれません。
通常は出来上がった料理単位ぐらいでOKを貰えば良いですよね。あるいは最初回に１度聞けば、同じ食事に関しては二度目以降確認する必要はないでしょう。
同じように、ある程度ルール化（標準化）し１つチェックすればあとはある程度任せるということもあります。4ステップを考えるときには、どの階層の成果物でどのステップが必要かを考慮しながら作業を洗い出す必要があるのです。
これらを踏まえ、ハイブリッド式の作業リストの作り方をまとめると次のような手順となります。
(1)プロジェクトの成果物を細分化する
(2) 共通化できる成果物をまとめる
(3)各成果物の作成に必要な作業を4ステップに沿って洗い出して肉付けする
※ただしすべての成果物に4ステップの作業がある訳ではない
それでは、実際の作業リストの例を見てみることにしましょう。
この表では「成果物」を分割している箇所を青色、「作業手順」で分割している箇所を薄い青色に色分けしています。
例は何でもいいのですが、ＩＴの開発の進め方は実は「建設業」の進め方を模倣したもので建設や建築との親和性が高くなっていますから、こうした例を見ても違和感は無いのではないでしょうか。
そして建設の考え方は元々「製造業」の流れを汲んでいるため、製造業の考え方とも酷似している部分が多々あります。
たとえば、進捗管理にガントチャートを使っているのも、元を正せば工事現場や建築現場の工程表や日程表を真似したものです。
また、オブジェクト指向における２３のデザインパターンにも、建築用語がいくつか取り入れられています。
会計の基本である「工事進行基準」や「工事完成基準」なども本来は"工事"に当てはまる会計処理方法ですが、当たり前のようにＩＴ業界で適用されています。
まぁ当然ですね。
作るものが異なるだけで、「進め方が同じ」「契約形態も同じ」「納品・検収も同じ」。経理的なお金の動きはすべて同じ仕組みなのですから、同じルールが適用されるに決まっています。
基本的にＩＴ業のなかで使われている多くのノウハウは、ＩＴ業界のなかで作られたものではなく、そのほとんどがほかの業界のベストプラクティスを模した…わかりやすく言えばパクったものにすぎません。そもそもの源流はＩＴ業界が生まれるよりももっと古くからあるもので、かつ使いこなしているからこそ成功率の高い業界が多い中でＩＴ業界は依然としてプロジェクトの成功率が５割前後（調査団体次第では３割前後という結果も）という状態をキープしているという事実です。
従来のノウハウであり、ベストプラクティスを活用させていただいているにもかかわらず、正しく使いこなせているマネージャーやエンジニアがそれほど多くないことに問題があるのかもしれません。
わかっておいてほしいのは、最後に出来上がるべきモノ（スコープ）から始めて、その構造を分解し、ある程度管理が出来る単位にしたらさらに作業に分解していくことで業務の全体像が素人の目に見てもわかりやすくなる、ということです。
これによって、マネージャーはもちろん、新人を含むメンバー全員やお客さまも安心して仕事を任せられることができるようになり、そしてその作業ごとに進み具合を管理することで対策を講じる必要性の有無が判断できるようになるということです。
計画があるとないとでは、対策や助力の必要性を周囲は気づいてあげられず、気が付くほど（隠しきれないほど）になってからではすでに手遅れになる可能性に大きな差が出るということです。
いいなと思ったら応援しよう！
