第12回 「見える化」だけでは見えないもの
野村隆（eLeader主催）
2006/2/23
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップトライアングルにおける位置付け
この連載では、前回までリーダーシップトライアングルについて説明してきました。今回からは個別の題材を取り上げ、システム開発プロジェクトにおけるリーダーシップを中心に、連載のタイトルのとおり「私の視点＝私点」を皆さんにお届けしようと思っています。
各回の題材は、何らかの形でリーダーシップトライアングルと関連しています。各回の記事とリーダーシップトライアングルとの関係を明確にすることで、記事の内容を皆さんによりよくご理解いただけると考えています。
今回の内容は、リーダーシップトライアングルのCommunicationとManagementに関係しています。CommunicationとManagementについては、本連載第8回「コミュニケーションはリーダーシップの基礎」、第9回「ソフトウェアは目に見えない」を参照いただければと思います。
 |
| 図1 リーダーシップトライアングル。今回はCommunicationとManagementに関連した内容を紹介する |
■軍隊における報告
記事の冒頭でいきなり「軍隊」という言葉を使うのもちょっと気が引けますが、ご容赦ください。戦争とか軍隊とかいう言葉が誤解を生みやすいのは承知していますが、記事を最後まで読んでいただければ分かるように、私には軍国主義を煽るつもりも戦争を賛美するつもりもありません。
軍隊における報告はいろいろな情報を含んでいるのですが、情報の中にも重要で本質的なものと、割合低く見られたものとがあったといいます。『何のために生きるのか』（致知出版社刊）において、五木寛之氏は以下のように説明しています。
日露戦争のころに大本営が、情報将校という、その当時でいう情報部員を大陸とかシベリアへたくさん派遣して情報収集をさせました。彼らが集めた情報のなかには、重要な情報、本質的な情報と、わりあい低く見られた情報とがあったという。敵の兵力とか大砲の数とか兵馬の数字とか補給線の様子とか、こういう情報は必要な情報ではあるけれども、あまり高級な情報とされなかった。むしろ敵の兵士たちの士気、あるいはその国の国民たちが、いまどう思っているか、そういう感情を分析して、それをきちんと把握して伝える情報を最も高度な情報として大事にしたらしい。（中略） たとえば、クロポトキンが数万の大軍を率いて奉天にやってくる。日本軍にとっては大きな脅威ですね。そのときに、敵の兵力はこれだけある、火力はこれだけある、機関銃は何丁ある、敵のほうが圧倒的に勝っているから日本は負ける。こういう情報は低い情報なんです。 むしろ大切なことはこういう情報です。クロポトキンは名将であり、数万の大軍は大きな兵力であるけれども、その兵士を分類してみると、ロシア人の兵士だけではない。植民地のポーランドから徴発した兵士やチェコの兵士、あるいは周辺の農村部のウクライナとかアルメニアの兵士たちもたくさんいる。いま本国ではロシア革命が進行しつつあって、農村の兵士たちはロシア皇帝のためにいのちを投げ出して死のうとは思っていない。そして植民地の兵士たちは忠誠心もたいしたことはない。だから、数万の大軍ではあるが、その士気はさほど高くないから恐るるに足らない―――。こういう分析がいちばん高級な情報とされたらしいのです。これらはまさに相手の心情をつたえているわけですね。そういう情報を真の情報というのだと思うんです。 |
こういう考え方は、何も日露戦争のときだけの話ではありません。織田信長も桶狭間の戦いの際、今川義元の大軍の隙をついて勝機を見いだしました。敵の士気の高さや敵が何を考えているかという情報は、勝つための状況判断に必要な、時代を超えた「高級な情報」なのです。
■システム開発プロジェクトにおける「見える化」
システム開発プロジェクトの管理に話を切り替えましょう。
一般的によくいわれる話ですが、システム開発プロジェクトでは「見える化」、つまり進ちょく状況を把握するために、数値化して可視化することが大切です。
「見える化」の重要性を説明するために、あえて悪い例を紹介します。
私が以前に従事したある大規模プロジェクトには、多くの協力会社が参加していました。その中にいつも進ちょくや品質に問題のあるチームがあり、そのチームの会議にオブザーバーとして参加したときのことです。
進ちょく会議では、担当者から口頭で報告がありました。今週はこんな問題があった、人が足りないから仕事が進まない、別のチームで決定すべきことが決まっていないから担当者の待ち時間が多くて困る、というような報告です。
斜に構えた技術者たちが「こんな状況だから仕事ができないんだよねー」と後ろ向きな文句を連発し、会議が進行します。
私はオブザーバーなので黙って聞いています。
問題点を挙げてさんざん文句をいうからには、問題の原因究明をして対策を練り、担当者と期日を決めて問題解決に乗り出すのかなと思っていると、リーダー格の人が「まあみんな大変だけれども、できるところから作業していこう！」と意味不明な整理をして、問題解決については一切検討されません。
私はオブザーバーなので黙って聞いています。
その後進ちょく報告があるのかな、と思って聞いていると、またリーダー格の人が「みんなからの報告は聞いたから、報告書にまとめておくよ。問題があって進ちょくが予定どおりでないということだね。じゃあ、明日からまた頑張ってください」と会議を締めくくりました。
これでは駄目ですよね。数字に基づいた会話はまったくしておらず、担当者の感情や感覚に基づいた報告を受けて、リーダーが適当に作った報告書を提出。こんな管理手法では、進ちょくを把握できるはずもありません。
オブザーバーとして参加した私が、担当者が感想文を朗読するような報告会では駄目だという報告をし、改善に向けて活動し始めたことはいうまでもありません。
■「見える化」の定義
繰り返しますが「見える化」とは、進ちょく状況を把握するために数値化して可視化すること、つまりシステム開発プロジェクトにおける作業を何らかの形で数値化することです。
例えば設計段階であれば、作成対象の設計書の数で把握することや、作業の段取り（タスク・ステップ）の数で把握することができるでしょう。
開発段階であれば開発対象のプログラム数、テスト段階であればテスト対象の試験項目数というように、数値化できる単位を見つけ出し、その数字を管理するということです。作業項目は作業のボリュームを表現しています。そのボリュームをどれだけの人員でこなしたかも含めて進ちょく管理をすると、PMBOKでいうところのEVMSにつながります。
この連載では、システム開発プロジェクトにおける数値化・「見える化」の具体的手法については取り上げません。話が横道にそれてしまい、冗長となるからです。システム開発プロジェクトの「見える化」とは、作業を数値化し、ここまでいったら仕事は終わりということを数字で定義し、週次・日次で管理する手法のこととご理解ください。
具体的にいうと、「150個のプログラムを開発完了したら、開発工期の仕事は完了。開発生産性を考えると、今週は60まで進んでいれば、工期の最後で150個のプログラムが完了することが見込まれる。しかし実際は55しか進んでおらず、現時点で5遅れている」というように、状況を数値化し可視化します。
数値化された管理をしていないと、先に紹介した悪い例のような、感覚に基づいたプロジェクト運営となってしまいます。
 |
| 今回のインデックス |
| ITエンジニアを続けるうえでのヒント（12） （1ページ） |
| ITエンジニアを続けるうえでのヒント（12） （2ページ） |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
