第9回 ソフトウェアは目に見えない
野村隆（eLeader主催）
2005/11/23
| 将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 |
■リーダーシップの基礎はコミュニケーション
前回の「コミュニケーションはリーダーシップの基礎」で、リーダーシップトライアングルの構成要素の中でも基礎となる「Communication」（コミュニケーション）について説明しました。
今回の記事では予定どおり、リーダーシップトライアングルの構成要素の「Vision」（ビジョン）／「Management」（マネジメント）を解説します。
 |
| 図1 リーダーシップトライアングル。今回は「Vision」（ビジョン）、「Management」（マネジメント）について解説する |
リーダーシップトライアングルでは、リーダーシップの基礎であるコミュニケーションの上に、リーダーとして先の見通しを示すビジョン、管理者として適正にプロジェクトを管理するマネジメント、そして人としてのココロ（心）を表す「Love」が配置されます。この3要素がそろって初めて、リーダーシップがしっかりと上に載るという考え方です。
リーダーシップトライアングルの中心をなす「Love」（ココロ）の解説は次回に譲ろうと考えています。今回はビジョンとマネジメントに焦点を絞ります。
■マイルストーンの利用方法
まずビジョンについて解説します。
リーダーたるもの、ビジョン、つまり先の見通しを提示して部下を率いなくてはいけないということはご理解いただけると思います。先の見通しを示さずに、ただ単に「頑張れ！」「働け！」では、リーダーとはいえませんよね。
先の見通しを示す方式としては、日付を設定したマイルストーンをプロジェクト全体の目標として設定することが有効です。プロジェクトの期間の長短や規模の大小にもよりますが、1〜2カ月に1つはマイルストーンを設けて、その日付に向かって全体の士気を向上させることが重要です。
マイルストーン設定において重要なことは、日付を設定するだけでなく、マイルストーンの完了要件として具体的な成果物を設定し、成果物の作成を義務付けることです。
「プログラム統合試験完了：12月15日」というマイルストーンを設定したとしましょう。プロジェクト全員の意識が12月15日に向かうので、マイルストーンを設定すること自体はよいことです。ビジョンを示しています。しかし、ただ漫然と「プログラム統合試験完了」という言葉を使うだけでは、効果が薄いです。「プログラム統合試験完了」の意味を明確にするためにも、完了時点で必要な成果物を定義することが重要なのです。
例えば、「プログラム統合試験完了」の定義として、項目がすべて試験されることだけではなく、プログラム統合試験完了報告書の作成完了・承認まで含まれるとしたらどうでしょう。単に試験を遂行するだけでなく、試験の報告書の作成が完了し、必要な完了承認を得るまでの作業を12月15日までに完了させるという理解が、プロジェクト全体で確実となります。そうなると、12月15日より数週間前に試験の実作業は完了し、試験の報告書を作成する必要があることが明確となります。
このように、マイルストーンにおいて完了必須の具体的な成果物を定義すると、プロジェクト全体の意識を合わせることが可能となります。
さらに、単発ではなく複数のマイルストーンを設定し、その連続性を説明することでプロジェクトの概要が理解できるようにすると、プロジェクトメンバーのプロジェクト状況の理解は均一なものとなります。
前回も触れましたが、SI（システム開発）プロジェクトにはさまざまなバックグラウンド（経歴・能力）を持った人が集まります。ユーザー代表、アプリケーション開発の専門家、ハードウェアやソフトウェアの専門家というように、さまざまな経験・能力を持つ人が集まってプロジェクトを遂行します。
バックグラウンドの異なる人は、プロジェクトにおける作業への興味や関心も異なります。こうしたメンバーに、プロジェクト全体の状況について一定レベルの理解をしてもらいたくても、細かい作業内容をすべてというのは現実的ではありません。概要レベルで状況を理解してもらうしかないわけです。この概要レベルでの状況理解を助けるのが、マイルストーンによるプロジェクトの状況説明なのです。
■キャリアビジョンを示す
マイルストーンによるビジョンの提示と同時に、特にSIプロジェクトにおいて重要なことは、リーダーがキャリアのビジョンを示すことと考えます。
SIプロジェクトにおいて作業に従事している作業者は、ITエンジニアが多いでしょう。ITエンジニアである彼らにキャリアのビジョンを提示することは、とても重要です。
ITエンジニアにキャリアのビジョンを示し、作業が自分のキャリアにプラスになると理解されれば、彼らは作業に専念できるものだからです。それはそうです、日々の仕事が将来のキャリア形成に役立つことが理解できれば、自発的に仕事ができるでしょう。
例えばJava言語を使って、データベース接続周りのプログラミングをしているプログラマがいたとしましょう。この人に単に「金曜までにプログラム作っておけ！ 遅れるなよ！」というのは簡単です。しかしこのようなコミュニケーションでは、プログラマは仕事をやらされている、こき使われているという印象を持ち、「やればいいんでしょ、やりますよ」と後ろ向きな気持ちになってしまうでしょう。
一方、このプログラマに以下のような説明をしたらどうでしょうか。「データベース接続機能の開発は、たいていの業務アプリケーション開発で発生する作業だ。今後の仕事でも重宝される経験になる。データベース接続は言語を問わず必要な機能だから、Javaでの実装を知っておけば、別の言語でもつぶしが利く。それにこのプロジェクトでは、3カ月後にパフォーマンステストが控えている。現在の作業の延長でデータベースのパフォーマンスチューニングの作業に当たってもらうことも、選択肢としてある。将来のキャリアとしてデータベースのチューニングに興味があるならば、いまの仕事はその下積みにもなっているんだ」
どうでしょうか。将来のキャリアの要素として現在の作業が具体的に位置付けられれば、現在の仕事に集中できるでしょう。
現在の仕事が将来のキャリアアップにつながるという説明を怠るリーダーの下では、作業者は「やらされている」という感覚を持ち、将来に不安を覚えながら作業に従事します。従って作業者は日々の仕事に真剣にならないし、不安が不満に代わり、文句ばかりいうようになります。
「なぜ作業者が真剣にならないのか」と不満に思うリーダーの方は、いま一度部下のキャリアを考え、キャリアビジョンを提示するよう心掛けてみてはどうでしょうか。
■視覚では判断できないソフトウェア
次に、マネジメントについて解説します。
解説にあたり、人間の五感、つまり視覚、聴覚、嗅覚、味覚、触覚について考えましょう。人間の五感のうち、一般的に最も発達しているといわれているのは、視覚だと思います。「百聞は一見にしかず」ということわざもあるとおり、人間にとって、目で見て理解できるものが最も納得しやすいものです。
犬は人間ほど目がよくないが嗅覚が発達しているといわれますね。犬になったことはないので細かいことは分かりませんが、犬はいろんなにおいをクンクンかいで何らかの判断を下すわけです。この雑草は食べることができるか、いま自分はほかの犬の縄張りに入っていないかなどなど。人間はまあ、賞味期限が切れた牛乳のにおいをかいで飲めるかどうか判断する程度のことはあっても、嗅覚で何かを判断することはまれでしょう。
人間では、視覚で判断することが無意識のうちに行われているといえましょう。こう考えると、視覚が使いにくい領域においては、判断力が鈍ったり判断を誤ったりすることが多いといえるのではないでしょうか。
SIプロジェクトにおいては、進ちょく管理・工程管理・品質管理が重要といわれています。私はこの理由を、ソフトウェアは目で見ることが難しいからと理解しています。
目で見ることが難しいという特性を持つソフトウェアでは、人間の得意な視覚が使いにくいので、判断がつきにくいのです。
プロジェクトルームの隣でビルの工事をしていたときのことを思い出します。工事現場に丸い柱を搬入するトラックを見て、ふと考えました。工事現場で丸い柱を注文して、業者が三角の柱を持ってきたら、その場でNGを出すでしょう。搬入すること自体が時間の無駄です。即断で「三角はいらない、丸を持ってこい！」といえますよね。判断を間違いようがありません。
しかし残念ながら、ソフトウェア産業においては、開発業者がまったくトンチンカンなものを持ってきても、いったん納品を受け、テストしないと品質が分からないわけです。納品メディアがCD-Rであれ、磁気テープであれ、送信されたファイルであれ、メディアを外見から不良品と判断できる人はいません。いたとしても、異常に勘の鋭い人か占い師くらいでしょう。普通の人間ではできない離れ業です。
上記の工事現場の例のように、丸い柱を注文したにもかかわらず三角の柱であるような明らかな不良品を持ってこられても、納品されたソフトウェアをインストールして一定のテスト工程を踏み、工数、つまり予算を消費しない限り、不良品かどうかは分からないわけです。
もったいないなあ、と思います。だからといって、すべてのソースコードを印刷してバインダーで見えるようにしたからといって、量が膨大だし、プログラマでないと内容を理解できないわけです。ソースコードを印刷したから、進ちょく・品質がきちんと管理されるかというと、明確にNOですよね。読むことが到底不可能な無駄な紙の山ができるだけです。
■見えないからこそ必要なマネジメント
じゃあ、どうすればいいのでしょうか。進ちょく管理という意味では、適切な単位で可視化して作業を定量化し、作業の終了要件を定義することが大事ですね。例えばプログラム・モジュール・クラスという作業単位を定義し、数値化する。数値化された作業の総量を把握し、作業総量がどの日程で完了するかをスケジュールにするわけです。
品質管理という意味では、目で見ることが困難なソフトウェアの品質を保証するためには、レビューとテストしか方法はないと理解しています。プログラム仕様書も含めて、レビューとテストをいかに適切に実施するかという議論しかないのです。
例えば、すべてのプログラム・モジュールの設計仕様書がレビューされたか（網羅性）を保証するために一覧でレビューの進ちょくを管理する、レビュー作業自体の品質を保証するためにレビューチェックリストを作成するなどという解決策を、いかに考えるかが重要です。最近ではピアレビューとかペアプログラミングのような、実作業者に閉じた品質保証の方法も一般的になってきています。
上記のようなレビューやテストというソフトウェアの品質保全については、さまざまな優れた方法が世の中にたくさんあります。例えばCMM、PMBOKなどです。
私はCMMやPMBOKの知識がないわけではありませんから、その解説をすることはできます。しかしこの連載ではあえて避けて通ります。CMMやPMBOKはあくまでもリーダーシップを確立するための、いい換えれば連載第1回「WhyとHow、どちらで悩みますか？」での「Whyの軸」でポジティブにキャリアを積むための「道具」であると理解しているからです。
確かに道具は大事です。大工さんが道具としてのノコギリとかカナヅチ（現在の建築工法でノコギリとカナヅチを使っているかは分かりませんが）を知らないで大工さんではあり得ないのと同様です。SIプロジェクトの管理者・リーダーとして、道具としてのCMM、PMBOKを理解していないわけにはいきません。
ただ、道具をよく知っていても、使う人が魂を入れなければ意味がないと私は考えます。魂、ココロ、つまりリーダーシップトライアングルでいうところの「Love」が大事なのです。いい方を換えると、道具の使い方は連載第1回での「Howの軸」に当たります。「Whyの軸」、つまりなぜ道具を使うのかを正しく把握するには、ココロの要素が重要となるのです。よって今回の連載では、CMMやPMBOKといった道具はとても重要で、学習する対象であるという整理にとどめ、内容は別の優れた本やサイトに譲りたいと思います。
次回は、上記で重要だと言及した、リーダーシップトライアングルの構成要素の「Love」を解説する予定です。ご期待ください。
私が主催するブログサイトはリーダーシップトライアングルの構成要素、Communication／Vision／Management／Loveによってトピックが分類されています。興味のある方は参照してくださるとご理解が深まるかと思います。サイトトップページの右上に分類が表示されています。
| 筆者プロフィール |
| 野村隆●大手総合コンサルティング会社のシニアマネージャ。無料メールマガジン「ITのスキルアップにリーダーシップ！」主催。早稲田大学卒業。金融・通信業界の基幹業務改革・大規模システム導入プロジェクトに多数参画。ITバブルのころには、少数精鋭からなるITベンチャー立ち上げに参加。大規模（重厚長大）から小規模（軽薄短小）まで、さまざまなプロジェクト管理を経験。SIプロジェクトのリーダーシップについてのサイト、ITエンジニア向け英語教材サイトも運営。 |
| 関連記事 | |||
|
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
