計画の究極は「遠足のしおり」

みなさんこんばんわ。

あー…また仕事の日々が来ますね。憂鬱です。まぁ、憂鬱だからってパフォーマンスが下がるほど無粋じゃないですけど。でもやっぱりテンションは高い方がいいに決まってます。

仕事ってだけで上がりませんけどね。

さて、ソフトウェア品質のことばかり語っていますが、私の中で「品質」っていうと、実際には「ありとあらゆるもの」の品質が気になるわけで、別にソフトウェアあるいは成果物の品質に特化しているわけではありません。

当然、表題にあるような「プロジェクトマネジメント」にもマネジメント品質があると思っていますし、マネジメントの質が高まれば、それだけでトラブルが起きる可能性が圧倒的に低下すると思っています。

なかでも、最重要なのは「計画」です。

個人的には、計画そのものが重要なのであって、計画書の有無はどちらでもいいと考えていますが、計画書があるなしではその成功率は全然変わってきます。

しかし、それは「計画書」を意味のあるものにし、意味のある使い方をした場合のみです。一般的に、私が見てきたプロジェクトマネジメントでは、計画し、計画書を書くマネージャーは数多くいたと思いますが、いかんせん、その計画や計画書をまったく度外視して、都度調整するだけに明け暮れ、疲弊していった人が多かったのではないでしょうか。

ほんと

　「それって、マネジメントなの？」

と聞きたくなることもしばしばでした。

マネジメントとは

マネジメントは、日本語では「マネージャー=管理職」と呼ぶために、「管理」と意訳してしまう傾向が強いと思います。

ですが、実際には”評価・分析・選択・改善・回避・統合・計画・調整・指揮・統制・組織化”など様々な経営的要素が含まれた言葉であり、欧米ではマネジメントのことをどちらかというと、「運営」や「経営」という意味で使います。日本では「やりくり」と意訳した方が良いのではないでしょうか。

つまり、プロジェクトマネジメントとは『プロジェクト経営』『プロジェクトやりくり』のことを指し、そのマネージャーとは、プロジェクトという小規模な組織の経営者であることを意味します。

社員の代わりにメンバーがいて、リーダーが別途いるなら彼らが管理職のような存在です。一般的な企業であれば１年を一つのくくりにして年度を持ち、年度ごとの計画を打ち立てます。プロジェクトでは契約期間が一つのライフサイクルになるだけで、同じ扱いです。

また、企業には年度の初めに年間予算があって、計画的に活用するようになっています。プロジェクトでも、自社から予算が出るか、契約によって見積もった額が予算となるかの違いで、基本的には同じ扱いです。

逆にいえば、プロジェクトマネジメントが安定して運営できるマネージャーとは、小規模な会社経営者としても卒なくこなせると言うことです（実際には法務・労務・財務などが絡むので、まったく同じとは言いませんが）。

ＩＴ系の業界では、優れたリーダーやマネージャーが独り立ちして起業しやすいのはそう言うことです。ほかの業界でも、プロジェクト運営がしっかりできる人の中には起業した人も多いかもしれません。

プロジェクトを始動させるために

あらためて申しておきますと、プロジェクト始動にあたって参加するメンバーやプロジェクトにかかわる様々な関係者（上司や、業者、外注なども含む）全員が周知され、理解していなければならない事項はないか？という問いに対し、「ない」と言い切れさえすれば、計画は無理に行う必要もありません。

・プロジェクトの具体的な目標や目的とは何か
・どんなメンバーが参加するのか
・それぞれどんな役割を担うのか
・なにかやってはならないルールや決め事はあるのか
・どのように協力し合うのか
・どんな方針に基づいて仕事へ取り組めば良いか　等々

つまり、計画とは、これから行う活動に対して「成功」させるための道筋を描き、実際に活動する者たちにとって「不安」や「懸念」を晴らし、誤った判断や行動などを起こさせないようにするためのものです。

ですので、関係者全員がすべてを把握し、理解しているというのであれば、あえて計画する必要も、計画書を作る必要もないということです。

しかし、そのようなこと、本当にありえるでしょうか。

計画や計画書が日の目を見ることはないのか

過去、数多くの計画書を見てきました。

その多くは、各企業の用意した定型フォーマットにただ穴埋めしていっただけのものであったり、逆に我流で作成しただけに、不足する情報（特に具体性に欠ける表記）が多すぎて、誰得なのかわからない計画書になっていたりと、あまり有用性を感じるものは見たことがない気がします。

必ずしも計画書を作成する必要はありませんが、それでも次のようなシチュエーションを考えた場合、やはり私は作っておくべきではないかな？と思うのです。

　・参画者のなかに新人や経験不足の若手がいる
　・スケジュール的に途中から参画するメンバーが予定されている

こうした時、彼らに説明する"だけ"で、理解してもらえるでしょうか。すべて頭の中に叩き込んで、常に注意して取り組んでくれるでしょうか。

仮に、プロジェクトの発足時にキックオフミーティングをしたとしても、途中参画者には伝わるのでしょうか。

計画書の中には、ビッグワード満載のふわっとしたものも多かったりします。基準値や目標値ばかり書かれていて、具体的にその数字をどう使えばいいかわからないものもあります。工程が進むごとに仕様やスコープが刻一刻と変化する中で、まったく改訂されずに放置プレイに甘んじる計画書も多々見てきました。

結局、計画なんてあってもなくても影響はなく、ただただ漫然とその日その日の指示に従うだけのチーム体制が出来上がっていくのです。

そうなると、もうマネージャーの力量次第、属人的なマネジメントに従って、プロジェクトを運用するばかりです。

一番怖いのは、機能しない進捗管理

既にマネージャーになって久しく、自ら開発は行わずに、折衝と予算管理がメインとなると、ものすごく杜撰な進捗管理が横行することがあります。

よく見るのが

　・進捗が「％」で報告されている
　・進捗報告の基準が決められていない

というケースです。

よくある光景に見えますが、このままではスケジュール管理は形骸化してしまうリスクを多分にはらんでいます。もしも、報告者の意図が次のようなものであった場合はどうでしょう。

　『全部で１０機能つくるうち、
　　７つ作成できたから…７０％くらいかな？』

と言うように、成果物作成の状況を単純計算で報告していることはよくあります。しかし、マネジメントしている側としては、本当に聞きたいのは「どこまで進んだか？」ではなく、「期日までに終了できる見込みはあるか？」です。もし、

　『元々２週間のスケジュールなので
　　現在７０％ってことは、あと３日で終わるってことか』

と解釈してしまっているとしたらどうでしょう。

たった１つ、「報告のルール」を"あらかじめ"決めておかなかっただけで、こういった誤認識をお互いに持ったまま、チーム活動が進んでいくことになってしまいます。

こう言った各作業に充てられた一つひとつの作業やマネジメント品質に対する意識の高さは、ユーザーの目にはまったく映ってくれません。ですから、ユーザー側も気にしませんし、ユーザーが気にしないからプロジェクトチーム内でも重要視されないという負のスパイラルが成立します。

そして、チームメンバーが重要視しないから、いざ始めてみると色々な進め方に影響を与えるような事態に発展しかねないことになるのです。

タイムマネジメントは、ありとあらゆる「仕事」の要となるものです。
ソフトウェア開発という手段をとっていても、有期的なプロジェクト活動であれば、それは全く同じ重要性を持ちます。

けれども、計画が杜撰なプロジェクトでは、残業等を強制することでメンバーに負担をかけたり、期日を伸ばしたり、予算を搾り取ることでユーザーに迷惑をかけたり、何かと歪が出てくるケースを数多く見てきました。

計画の理想は「遠足のしおり」

遠足のしおりを思い起こしてください。

子供たちにもわかるように書かれていたり、親御さんたちにも伝わるように書かれていたり、なにより「具体的にどうすればいいか」まで書かれていて、大人ならそれだけで引率がなくても遠足ができてしまうほどに完成度が高いものだったりします。

翻って、私たちが作る計画書はどうでしょう？

難しいことを難しく書いているだけで、一度も見ない人すらいるようなものがありませんでしたか？

たとえば、"旅行"に関する計画書は軒並み「分刻み」のスケジュールだったりするため、ビジネスで使う計画書に比べれば、圧倒的に精度が高かったりします。ビジネスであそこまで精度の高いスケジュール管理を行っている人なんてそうそう見ません。するとしても、セルフマネジメントまでが精いっぱいでしょう。

なかには、日々チャットなどを使って情報連携していたり、Wikiのようなものでまとめていたりするプロジェクトもあると思います。それはそれでいいと思います。最初にも言ったように、必ずしも計画書である必要はありませんから。

ですが、「請負」契約である場合は、あらかじめ予算を決定し、期限を決め、納品すべき成果物を明らかにして、契約を結ぶという特性上、どうしても計画というものは必要になってきます。

自社開発のようなものであればアジャイル系の開発モデルで行っても、「予算」「期限」だけ決めれば、ＰｏＣも兼ねてやれるところまでやる…というスタンスも成立するでしょう。

けれども、請負の場合は「予算」「期限」「成果物」「スコープ」などに厳密性が求められますし、企業としても工事進行基準など会計上の課題もあって、なかなか融通が利くものでもありません。

さらに、ユーザー側にとっても年間計画上の予算は決まっていますので、仕様がコロコロ変わるたびにスケジュールやコストをかさ増しされても困るわけです（追加予算申請することもできるでしょうが、「計画性がない」と言われて評価を下げてくる企業もあるため、ユーザー側の担当者も自分の人生を勘案した時、おいそれと予算追加を認めるわけにはいかなかったりするのです）。

そうした背景もあって、「請負」契約で受注するプロジェクトの場合は、よほどのことがない限り、計画的に進めることが求められ、且つよほど正確性の高い計画であることが要求されるわけです。

「計画」の出来としての目標は

　・そこに定められている通りにすれば、高い確度で成功すること
　・キックオフの時点で、メンバーが不安を抱かなくていいようにすること
　・途中参画者はそれを見ただけで、自らの役割に困らないようにすること
　・メンバーが、マネージャーやリーダーに聞きにいかずとも、
　　計画書を見直すだけでよい状態にすること
　・変更があっても、コントロールできる準備が整っていること

ではないでしょうか。

もちろん、そんなものなくても、「随時聞いてくれ」「都度わからないことがあったら質問してくれ」というのもアリだと思います。ただし、それは回答者が常に回答できる状態であった場合、という条件付きではないでしょうか。

「頻繁にユーザーのところに出かけている」、「社内に戻ってきても延々と誰かと打ち合わせしている」と言うのでは、

　「聞きに来るな」

と言っているのと大差がありません。

マネジメントも一つの仕組みです。会社の経営において、ほとんどの手続きや業務がフロー化されて、手順が定まっているために、毎度毎度経営者のところに聞きに行く…と言うことはないでしょう。

同じように、プロジェクト活動の中も整理して、仕組み（「ルール」「標準」「基準」「手順」）とし、聞かなければわからないという状況を少しでも減らすことができれば、マネジメントももっと楽に運用できるのではないでしょうか。