第八章｜プロジェクトは「段取り」と「言葉」で回る
ここまで、仕事やプロジェクトを
「考える前に整える」という視点で見てきた。
時間、戦略、会議、資料、プレゼン、数字。
どれも個別のスキルの話に見えるかもしれないが、
共通しているのは
「言葉と構造を先に決めているかどうか」という一点だった。
ただ、ここで一つ、現実的な問題が残る。
整えるだけでは、仕事は前に進まない。
設計しただけでは、プロジェクトは終わらない。
実際の現場では、
人は迷い、判断は遅れ、想定外は必ず起きる。
その中で「どう動かすか」が、次の問いになる。
第二部では、
ここまで整えてきた考え方を前提に、
プロジェクトを「動かす側」の話をする。
正解を知っている人の話ではない。
判断に迷い、失敗し、修正しながら、
それでも前に進めようとした現場の話だ。
プロジェクトは、
計画ではなく、運用で評価される。
ここからは、
プロジェクトマネジメントを、実装の言葉で語っていく。
１.プロジェクトマネジメントの導入｜なぜ今プロジェクトという考え方なのか
―― 用語に入る前に、プロジェクトとは何かを整理する話
「プロジェクトマネジメント」と聞くと、
専門的な手法やツールを思い浮かべる人は多い。
WBS、ガントチャート、進捗管理、リスク管理。
確かに、それらは重要だ。
だが、現場で本当にプロジェクトを左右しているのは、
もっと手前のところにある。
誰が、何を、どこまでやるのか。
その認識が、きちんと揃っているかどうか。
プロジェクトが止まるとき、
多くの場合、問題は技術や工数ではない。
段取りが曖昧なまま走り出してしまったか、
言葉の定義が揃っていなかったか。
第一部では、
仕事を進めるために必要な
「考える前の整え方」を見てきた。
ここからは、その前提をもとに、
仕事をプロジェクトとして動かす話に入る。
プロジェクトとは、
計画を立てることではなく、
合意を積み重ね、判断を続ける行為だ。
段取りを決め、
言葉を揃え、
迷いながらも前に進めていく。
第八章では、
その入り口として、
なぜプロジェクトは「段取り」と「言葉」で回るのかを
整理していく。
プロジェクトに参画するものの基礎
さて、プロジェクトマネジメントについて語る。もしかしたら、「わたしは取り急ぎ目の前の目標はシステム開発者・技術者であって、プロジェクトマネジメントに関して今学習しても遠い未来のこと」という向きがあるかもしれない。しかしながら、ここまで本テキストを学習し、頭の中で反芻してきたあなたならば、モノゴトは大きな枠から理解するのが一番の早道・近道なので、早く仕事を覚えたいのであれば、大きな部分の理解が必須である。
システムの開発手法の一つである、ウォーターフォールモデルというものがある。古くから人間の社会に適応する形でブラッシュアップされてきた。それはいろいろと分析すると、V字のモデルで理解するのが適していて、図のようになる。
当たり前の情報かもしれないが、初学者向けに、順番を列挙する。システムの開発プロジェクトを、ウォーターフォールモデルで実施しようということになったならば、
① 要求分析
② 要件定義
③ 基本（外部）設計
④ 詳細（内部）設計
⑤ コーディング（製造）
⑥ コードレビュー
⑦ 単体テスト（ユニットテスト：UT、とも言う）
⑧ 結合テスト（インテグレーションテスト：IT、とも言う）
⑨ システムテスト（総合テスト：ST、とも言う）
⑩ 受入テスト（ユーザーアクセプタブルテスト：UAT、とも言う）
の順番に工程が進む。まずはこの図を暗記して、スラスラとアウトプットできるようにすること。システム開発の世界では、ほぼ全員がこの図を頭にイメージしながら話をする。よって共通言語のようなものだ。
それぞれの工程でどんなことをするのか、については、他の参考書の丸写しになるだけなのでここでは割愛する。あなた自身が投入されたプロジェクトの工程（フェーズ）に従って、実施する内容を整理するのがよい。
上記の➀～⑩で示した工程は、プロジェクトのスタートから、カットオーバー（プロジェクトや組織の文化によって、サービスイン等と呼称する）までの言わば目次だ。実際には別の章でも述べるが、ITへの投資そのものは、もっと巨大な、企業体というコングロマリットが、未来を見据えて中期経営計画を立案し、そこから単年度の予算が組まれ、それを実現するために各種プロジェクトが組まれる。
上図のプロジェクトという箱の中身は大きく設計→開発→検証となっている。それを更に細分化したものが、前ページの➀～⑩に当たる。
ちなみに、『計画→実行→検証』という流れは、ITに限ったことではなく、どんなプランであっても当たり前のようにある。学生や生徒だったころに、PDCAというコトバを聞いたことがあるかもしれない。この言葉が社会人必須のコトバになっているのは、普段の社会人生活そのものが『計画→実行→検証』の繰り返しだからだ。なにも難しいことを言っているわけではない。ドライブに行くならば、道順を考えることが計画だし、運転をすることが実行だ。そして、渋滞に巻き込まれてしまったら、今度行くときには高速道路にしようとか、検証する。それと同じことが、お仕事でも起きるだけだ。
もう一つ社会人の常識用語を。それは『ヒト・モノ・カネ・情報』のセットである。企業活動は、第5章で詳述したように、この『ヒト・モノ・カネ・情報』が不可欠で、そのうちの情報を伝達する仕組みとして、ITが存在する。コンピュータは疲れを知らないし、繰り返しの処理はどんなに人間が面倒であっても処理してくれる。０と１しか分からないくせにコンピュータに頼りっきりになっているのが現代の高度資本主義社会というものだ。
グリコの失敗
グリコという企業が、ＩＴプロジェクトの移行失敗によって、商品の出荷ができなくなったのは記憶に新しい。小売業に扱ってもらっている商品が、出荷できなくなるというのはどういう事態か。考えてほしい。
グリコという世界的な企業であっても、4か月の間、商品が出荷できないということは、スーパーマーケットやドラッグストア、コンビニの棚からグリコの商品がなくなることを意味する。小売店は、棚がスカスカなのを嫌う。売れている商品（売れ筋という）だったら、もっと発注しないと、機会損失になり、ひいてはお客様離れに繋がる。売れていない商品（死に筋という）だったら、さっさと発注をストップしないと、在庫ばかり増え、在庫の増加は、空間や面積を圧迫する。小売業は、例えば100円の商品に対して、わずかな利益を転嫁して109円で売ってたりする。それなのに売れない商品は置いておけないというわけだ。
グリコの商品が、1日や2日届かないだけなら棚を空けて待つことができるが、先のめどが立たないということであれば、小売店は、その空いた棚を、他社の商品で埋めるだろう。そうすることが、結果、お客様の増加につながることを信じているのだ。
一般人の我々からすると、システムがストップしてしまったのならば、手作業でやればいいのではないかと考えてしまう。かつての日本ならばそうなっていたはずだ。しかし、高度にＩＴが整備された中では、例えば「ＡスーパーマーケットチェーンのＢ店にヨーグルトを20個納品」ということが目標であっても、その目標を達成するための手段が入り組みすぎていて、便利さとはトレードオフで手作業の時代には戻れない。もはやこうなっては、システムの正常稼働を座して待つしか、出荷を再開できないというわけだ。
親玉の企業であれば会計上、特別損失などで処理し、翌年度以降はまた需要が戻り、回復するかもしれない。しかし、サプライチェーンマネジメントのシステムの上にいる中小の会社は、4か月もグリコ関連の製品や半製品、原材料の動きが止まってしまうので、死活問題となる。
かつてみずほ銀行は3行合併の際に、大規模なシステム障害を起こし、それは企業のみならず、マス顧客であるところの一般の預金者にまで影響を与えた。数行前で、死活問題と述べたが、銀行が止まるということは、『ヒト・モノ・カネ・情報』のすべてが止まるということを意味する。システム移行に関しては金融庁という「お上」の決済が必要となる。もう二度と、みずほ銀行のトラブルを繰り返さないためだ。
システムの移行という段階においては、そういう未曽有の事故が発生することを予期し、コンティンジェンシープランと呼ばれる計画を立て、テレビ番組でもないのにリハーサルを何度も行い、ものすごい緊張感の中で移行が行われる。グリコやみずほ銀行の事例を上げたが、笑い話ではない。担当者の心中を慮るに、当日のストレスはいかばかりかと胸が痛い。
移行は、前の投稿に列挙した⑩の受入テストの後になる。かように、➀～⑩までを丸暗記したら終わりではなくて、プロジェクトには、その前工程や後工程に様々な重要なイベントがあるため、まずは幹としてのＶ字モデルを頭に叩き込んで、マインドマップなどの手法でよくされるように、そこから派生する枝葉の部分を後から、レベルを少し下げて理解していく。
あなたはスマホ等の便利な機能をまったく持たずに、自然の中の道を歩いているとしよう。目に映る風景は様々に変化すれど、道しるべとなるものは数キロごとに置かれた赤いポストだけだと仮定する。
そうしたら、あなたはまずポストを目印にする。そして、数キロごとでは心もとないので、例えば池とか沼とか、森林とか、川とか、そういう次に目立つものを目印にする。これが以前コラムに書いたレベル２である。決して道端に落ちていた空き缶とか、偶然居合わせた犬や猫を目印にしてはいけない。
そういうように頭を働かせないと、膨大なシステム開発の、何かを指す呼称ばかり追いかけてしまうことになり、それは付加価値を生む仕事ではない。仕事は、呼称を一生懸命暗記することを求められているわけではないので、どういう括りで、何が目的なのかを整理することを心がけてほしい。
工程は、図の通りに理解するとよい、と繰り返し伝えておく。ウォーターフォール、つまり滝の流れに従って、水が上から下に流れる、専門用語っぽい言葉では、上流工程から下流工程に向かって流れる。そして、横の矢印は、工程間の関連性のリンクだ。
プロジェクトを運営する一員として、お客様企業に派遣で行くことの多い技術者も、この流れに逆らうことはできない。ウォーターフォール型システム開発の弱点を解消したかのようにとらえられることの多いアジャイル開発だって、短期間で『計画→実行→検証」を繰り返すことには変わらない。スクラム開発だXPだと色々用語は出てくるが、そういうものに飛びつく前に基礎をしっかり把握することが重要だ。
要員の面談などでも、V字モデルを理解しているか、は頻出の質問だ。普遍的な質問なんてありえないが、これを理解しているかどうかを尋ねて、工程の名称を列挙させるだけでも、立派なスクリーニングになる。つまり、➀～⑩を理解していなければ、それで面談が通らなかったりする。
次に頻出の質問を記載しておこう。
「あなたは、課題と問題とリスクについて定義できますか？」
プロジェクトに関わらず、課題管理と問題管理は明確に異なるものである。そして課題とリスクをごちゃまぜにしてしまっているプロジェクトも、散見される。いい機会なので、課題と問題とリスクをきちんと整理しておこう。キーワードは「顕在」だ。
なぜこのプロジェクトマネジメントの項目が、第9章なのか、そろそろお分かりいただけただろうか。
頭の働かせ方を知らずに、些末な名称・呼称を記憶するのは、仕事をする上で障害にこそなれ、メリットには何もならないということを伝えたかったのだ。だってあなたは、仕事の効率を上げたいんでしょう？その方法は普遍的で、じっくりやるしかない。
※本note記事は、これまでに公開してきた記事をもとに、構成を見直し再編集したものです。
👉第九章 プロマネの仕事は、判断と信頼の積み上げだ
【 固定リンク 】
プロジェクトマネジメントは、言葉でできている
