プロジェクトをマネージメントするうえでの技術
管理職になりたてのとき、結構どうしていいかわからなかったりしました。
できる人は悩まないのでしょうが、意思決定はなかなかにストレスのかかる作業です。この決定が複数の人たちやPJを左右するからです。リーダーシップ研修などでは「これをすることがリーダーシップだ！」という感じでぐいぐい引っ張っていくことを無条件に要求しますが、では何が正しいのか？どう判断したら正解なのか誰も教えてくれません。「かっこいいのはズバリ判断することだ」といわれても困ります。
そんなに経験があるわけでもないのに、重要な判断について、「どうしたらいいか？」「どうするのか」「方針は？」など始終あらゆる人から詰められてしまいます。
私が実践してきた方法を紹介します。
① 意思決定ができないことで悩んでないか
② 腹をくくれ
③ 自分で手におえないと判断したら
原理原則を守ることは重要です。ここでいう原則はプロジェクトマネージメントにおける当たり前にやらなければならないことです。プロジェクトマネジメント知識体系ガイド（PMBOK）
無視してなし崩し的にPJを進めていく、というのも方法としてはあります。
能力のあるPMが小規模PJにおいて、すべての人に自分自身で指示を出してすべてを把握している場合は、好きに自分のやり方で進めるのもいいでしょう。
PJが大きくなった場合、規模が小さくてもPMがスーパーマンでない場合はその方法は絶対にダメです。
一例をあげると小規模開発者から、上がっていった人にありがちですが、PJ推進において必要な、プロジェクト計画書の作成、プロジェクトキックオフの実施、規定類の整備などを軽視して、不要なものと判断して、作らないことがあります。
これはよくありません。要員が自分の手足ならばよいですが、少なくとも自律的に動くことを期待するならば、PJが行く先を共有することは必須です。
PJ計画書というと大げさですが、中身は何かというと、いろいろありますがおもなものは、PJがどんなものかの「概要」、何のためにやるかの「目的」、いつまでにどのやり方でどの順番でやるのかの「スケジュール」、だれが何をやるか誰と絡めばいいかの「体制」、どこで何をつかってやるかの「環境」や、推進するための会議をどうするかの「コミュニケーション計画」。などが書かれたもので、各機能を持った人が集まってできるのがPJだとするならば、あらかじめ伝えておかなければならないことが書かれたものなのです。
「プロジェクト計画書」などとかっこいい冊子になっていなくても場合によっては紙一枚でも構わないのです。実はいらないと言っている人も作っているか、ばらばらでも作る羽目になっていることでしょう。
案件によっては調達仕様書に必要事項が書かれている場合や、客先PMOから求められる場合があります。
このようなPJ計画書に限らず、PJ推進プロセスにおいて必要とされていることは実態としても必要で組織にPJ推進に関するガイドライン等が設定されているならば、その存在意義、意図を踏まえて実効的に実施すべきでしょう。(形だけ意味のないものを作るなら時間の無駄なので)
ちなみに、物事の存在意義、意図を読み取り、理解する力も能力として必須です。（斜に構えるだけでは何にもならないという意味ですね）
形だけの作業を省く件については、きちんと本来的な意味を理解して、その作業の存在した理由を理解し、それがほかの方法で担保されているときに限り省くことが可能であろうと考えます。
くれぐれも勝手に無駄と聞けつけてやるべきことをやらないことはしないでください。
これは頑固であれという意味ではありません。強い意志とはやりきる意思といってもいいかもしれません。
途中で投げ出さない、へこたれないということです
一度決めたら曲げないということもありますが、曲げないのは基本方針「やりきる」というところにすべきで、方法に関しては、「やりきるために」柔軟に変えながら進めていくべきです。(「改善)、「イノベーション)ともいう)
実行レベルに近い決定事項を守り、状況を無視してかたくなにやり続けると、組織がおかしくなってしまうこともままありますので、「やりきる」ことを重視し、「そのためには何でもする」という強い意志が必要です。
プロジェクトには絶対に何らかのトラブルが発生します。発生しない物はありません。キーマンの病気や事故といったどうにもならないと思えるような外的要因が発生するかもしれません。突然の無理な仕様変更要求が来るかもしれません。虚偽報告によるサービスイン前の受入試験での実はプログラムが何もできていない事件が発生するかもしれません。
その時にくじけることなくやりきる能力が一番最初に、絶対に必要なのです。
自分自身のパーソナルスキルの側面と管理技術的な面があります。両方重要で、特にパーソナルスキルの部分は、下手をすると、ひたすらコンピューターに向かってプログラミングしてきた我々にとっては苦手とする部分かも知れません。わかっていることと実践できることは違いますが、それが顕著に出る部分でもあります。とにかく勇気を持って頑張る必要があります。
一方管理技術はというと、管理されることはあっても管理側としての意図意味が分かっていないため、相当に意識しながら勉強する必要があるかもしれません。
今までの経験があるから何とかなるだろうという甘い考えではだめです。
間違いなくこれらの技術の勉強は必要です。ここではどんなものであるかの紹介をします。
とはいえ具体的な方法論もNaOHKI説での展開を時間があるときに追加で述べさせていただきたいと思います。
他のものの本にあるパーソナルスキルという用語とは少し違う解釈になっていることはご容赦いただきたいのですが「(イ)強い意志」から「(キ)意思決定」までがパーソナルスキルでそれ以降が勉強と経験で身につく管理スキルです。
(イ)強い意志
(ウ)原則論(決められたプロセスを実施する)
(エ)コミュニケーション能力
(オ)交渉力
(カ)方針決定
(キ)意思決定
～ここで別れる～
(ク)リスク管理
(ケ)品質管理
(コ)要員育成
(サ)課題・問題管理
(シ)レビュー
(ス)必要な知識
こうしてみるとわかるように精神論的なものが最初に多いように感じるかも知れませんが、これが意外に重要です。
これらのパーソナルスキルがないと知識だけあっても人を率いていけませんし、圧力に負けて心が折れてしまうことも多いです。
まずは一般的な話から。
SEの気分のまま、経験だけでそのままPMにあろうとすると、いわゆる顧客のためにシステムインテクレーションを行うプロジェクトで、管理を徹底することを要求される場合は通用しないことがあります。
どのようなスキルが必要で、自分が開発するのとはどう違うのか簡単に触れる
実際のPM技術に関しては、それ専用のものの本（PMBOKとか）を参照してください。
――(ア)身に付けるべき基本的なスキル
――(イ)強い意志
――(ウ)原則論(決められたプロセスを実施する)
――(エ)コミュニケーション能力
――(オ)交渉力
――(カ)方針決定
――(キ)意思決定
――(ク)リスク管理
――(ケ)品質管理
――(コ)要員育成
――(サ)課題・問題管理
――(シ)レビュー
――(ス)必要な知識
について書きます
例によって時間があるときに書きますのでのんびりお待ちください
大昔の話。
毎週進捗会議をして、各サブシステムから進捗をヒアリングします。シンプルな書式で、工程ごとに進捗率の目標と実績を報告してもらうものです。
各サブシステムごとに進んでいたり、遅れていたりするのですが、おおむねスケジュール通りに進んでいました。遅れているサブシステムは監視対象になって細かく進捗を見られます。それこそねほりはほり。
そんなこんなでサービスインを控え、ユーザ総合試験をすることになりプログラムを動かしてみようということになったのですが、あるサブシステムだけが何やら見てもらいたくなさそうです。説得して見せてもらったのですが、プログラムが動きません。それどころか、プログラムが完成していません。進捗上は内部の総合試験をほぼ終わっていて、動きそうです。どうしたことでしょう・・・実は報告者が、実態を見ておらず、期日に合わせて数字だけ更新した資料を毎週提出していたのでした。
虚偽報告です。ＰＭとしてはこれをされてしまうと手の打ちようがありません、さすがに嘘をつかれた場合には・・・
「運が悪かった！」のでしょうか？
解：発見できるか？
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
効果
ウオークスルーを実施することで、意外にたくさんの質問や、気が付かなかったこと、当たり前と思っているのは自分だけだったというようなことが発見できます。これらを議事メモに落とします。
ウオークスルー議事まとめ
議事メモは各テーマごとに作成し、課題事項、ユーザに対する制限事項、その他議事項目などに分類しながら作成します。
展開と実施
この議事メモは必ず展開をして対応を必ず書くようにします。
担当者をマネージャがいれ、その人に対応及びその具体的内容を入れてもらいます。ここでの具体的内容は、課題の内容に対する対処ではなく、課題自体を課題管理するとか何もしないとかというレベルの内容を管理します。そうしないとプロジェクトの課題管理表と二重管理になるからです。
課題管理に載ったら通常の課題管理に基づいて管理します。
最後に復習です。
このシステムウオークスルーで期待するアウトプットはPJによって様々と思いますが、以下の3点があげられます。
①課題管理表
②サービスレベル一覧（制限事項一覧）
③みんなの理解
あくまでもPJ推進の基本設計レビューと同じ位置づけで、システムのアーキテクチャー上の問題点・課題をあぶりだすのが目的で、洗い出せたら通常の課題管理やPJ推進設計工程に引き継いで実施していきます。
当事者意識をもってシステム全体がどう動くかをみんなでシミュレートすることが重要です。
これらはＩＴアーキテクトが本来行っている手順の一部ですが、誰にでもできるように一般化してその人がいなくても一定のことができるようにすることが必要です。
まずは、ウオークスルー観点を入力として進め方一覧を作ります。
進め方一覧
ウオークスルーの内容と用意するツール、進め方では導入説明者を明示して何を議論に先立って説明してもらうかを明示します。
当日、ウオークスルーはすべてのサブシステムのリーダクラスに集まってもらいます。そのサブシステムの中身を説明してもらう必要があるため、中身が分かっている人が必須です。
司会はシステムの統括責任者が行うのが最適です。実際にウオークスルーを行っている中で指示をしたり、判断をすることが必要だったり、横断的な観点で話す必要があるからです。
１）テーマに沿ってまずは導入説明を行います。
導入説明はウオークスルーの最初10分くらいで軽く行います。本当に概略を説明するだけにしておきます。
ツールはシステム構成図を用いることが多く、なぜならデータの流れを見るのに最適な図であり使うと話がしやすいからです。
２）導入説明が終わったら、今後は観点をベースに、
○業務運用が考慮されているか（月次イベント・年次イベント）
○実際使う人が利用可能か（運用可能か）
○運用時間帯を考慮したつくりになっているか（制限事項は抜き出す）
○データの流れはどうなるか（無理なデータの流れになっていないか）
○必要なときに必要なデータが利用可能な状態で存在しているか
○技術的な無理はしていないか実際に業務を動かしてみたらどうなるか
など、そのシステムで懸念されている観点や運用観点でシステムとして動くかを実際に机上シミュレーションします。
システムの動きを机上シミュレーション
このとき、関連するサブシステムの人に質問をしながら心配事は無いか、分からないところは無いか、質問は無いかを聞きながら進めます。
その場で議論したり、課題の解決指示をすることもあります。
みんなが当事者意識を持ってシステムのイメージを持ってシミュレーションしていくのがコツです。
洗い出しの方法
ユーザの運用業務視点での業務AP・基盤AP・HW/PP・システム監視を通じて、システムのグループ間の整合が取れているかを検討すべきテーマの洗い出しを目的として行います。
あるプロジェクトの例です。
少数のリーダで、今回の場合はサブシステムリーダー以上で集まって行いましたが、ブレーンストーミング形式でプロジェクト全体責任者が誘導司会をしながら、網羅的に意見が出るようにしながら「心配事」「ユーザ視点で今回何が起こるか」「前から変わる点」「異常としてどんなことが想定できるか」などの観点でランダムに出していきます。
今回は１時間くらいで130件出ました。これをプロジェクトマネージメントチームが持ちかえって分類し、ファイルの「ウオークスルーテーマ」タブのように整理します。
このときにどういうウオークスルーテーマにするかがセンスを問われるところです。
「公開用ウオークスルー観点」
（内容は参考です：特定のPJを意識したものではありません）
先立っての準備としてこれを公開し、各担当に確認追記をしてもらいます。
「後での整理事項」は多くのグループをまたがないのでウオークスルーをするまでも無いが、課題管理するか質問としてグループが回答するか、みんなに周知すべき事項のものです。質問一覧として各担当に割り振り回答を記載してもらうものです。
テーマとして書いたもののほか、ウオークスルーに入れた方が良いかを各リーダに検討してもらい、入れる必要があるものはウオークスルーテーマに記載してもらいます。
「ブレーンストーミングアウトプット」はブレーンストーミングをやったときに出た内容です。
この○の結果を元にファイル中の「質問回答一覧」「説明会項目・課題管理項目」タグを整理します。
☆「質問回答一覧」
質問回答一覧はブレーンストーミングで出てきた各者の疑問点です。
解答欄に回答の記載をしてもらいます。回答方法は直接回答を記載しても良いし、資料の場所を提示することでも良いと思います。
☆ 説明会項目
説明会項目はブレーンストーミングで出た内容のうち、ぜひ説明会で説明してほしいといわれている項目です。
説明会を実施してもらいます。ウオークスルーに絡めてその中で説明をしてしまっても良いと思います。
☆ 課題管理項目
課題管理項目はブレーンストーミングで出た内容のうち課題管理したほうがいいのではないかという意見があるものです。
担当者が課題管理の要不要判断して課題管理すべきものは内部課題として課題管理してもらいます。
問題提起
業務とインフラがうまく整合があっていないとか、あっているかわからないというような事に出会ったことは無いでしょうか？わたしはよくあります。
システムアーキテクチャはシステムを実現するに当って一貫性を持って設計する必要があります。そのためには○○システムアーキテクトが実現する業務を踏まえてグランドデザインを行い、それをトップダウンで細分化して実装に落としていく必要があります。
とはいえ、現行システムのリプレース案件などで各サブシステムからのボトムアップでシステムをくみ上げる例もどうしても出てきます。
その場合にありがちなのが、システムの全体はすでになんとなくできてしまっいて、それぞれがその「制限」の中で実装を工夫している状態です。この「制限」が問題で実は一貫性のあるシステムでは変えるべきところである可能性があります。これを放置すると、ねじれたシステムが出来上がります。
どうしてそうなるのか。
いくつか原因は考えられますが、ちゃんと調整している(と思っている)にもかかわらず起きてしまう場合もあります。システムの内部課題として各々から質問として「これはどうなっているのか？」というものに対して、質問を受けた側は実装を考えた上で「こうなっている」と回答をすると、それが質問をした人にとっては前提条件となり大変だと思いつつもそのまま解決する方法を工夫して進めてしまっている場合です。本来は、実装に関して相談をしながら進めるのが良いのですが、お互いにその時点では案が無かったり時間が無かったりすると質問で終わらせてしまう場合にそうなりがちです。
全体整合をあとからとる
この場合はどうしたら良いでしょうか。今からでも遅くありません。全体の整合性を検証(システムウォークスルー)してみましょう。業務からHW・運用まで全般にわたっての人を集める必要があります。大人数になるかもしれません。
一人が全部わかるならばその人をシステムアーキテクトにして設計すれば良いだけなのですが、この場合は複数の人の知識や知恵を出し合って検証する必要があることを前提としています。
効率的なシステムのデザインという観点をぶらさなければ、全体工数を抑えることができるかもしれません。無理を解決する工数が削減できるからです。
システムリスクも減りますから後工程での工数も削減できます。
ここで言うシステムウォークスルーは、
「業務運用：業務AP：インフラAP：ミドルウエア：ハードウエア：監視運用
にわたって一貫性のある問題の無い設計になっているかの検証」とします。
アーキテクトはシステムグランドデザインを行う「役割」です。
システムウオークスルーの具体的な進め方についてお話いたします。
①テーマの洗い出し
②ウオークスルーの実施
③議事録の展開とトラッキング
という流れになります。
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。
