■マイルストーンの利用方法　
まずビジョンについて解説します。　
リーダーたるもの、ビジョン、つまり先の見通しを提示して部下を率いなくてはいけないということはご理解いただけると思います。先の見通しを示さずに、ただ単に「頑張れ！」「働け！」では、リーダーとはいえませんよね。　
先の見通しを示す方式としては、日付を設定したマイルストーンをプロジェクト全体の目標として設定することが有効です。プロジェクトの期間の長短や規模の大小にもよりますが、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という言葉の定義をさせてください。 ここでいうLoveとは、男女の愛とか、好き好きという恋愛感情とは異なります。Loveとは儒教でいう仁愛です。他者への思いやりの心、自分の感情をコントロールして正しく生きる精神ともいえます。　
ビジョンとマネジメントも重要な要素ですが、Love、ココロなしではリーダーシップは成立しないと考えています。リーダーシップトライアングルの形も、ココロを抜くと不安定になるように表現しました。　
ビジョンとマネジメントがなければリーダーシップは成立しません。これは当然でしょう。ビジョンがないため先が見えず、マネジメントがないため適正な管理もされないプロジェクトでリーダーシップを発揮しようとしたら、どうなるでしょうか。蛮勇といいますか、ヤケクソになって前後の見境もなく突き進むような、理性も知性もなく無駄の多い指導者になってしまうでしょう。これでは適正にリーダーシップが発揮されているとはいえないと思います。　
ココロはどうでしょう。本当にリーダーシップに必要なのでしょうか。ビジョンとマネジメントだけでもリーダーシップが成り立つのであれば、別にココロはなくてもいいのではないかといえますからね。　
私は、リーダーシップの必要条件にはLove、ココロがあると考えます。リーダーシップが成立するためにはココロが必要なのです。その理由を、本連載第6回「正しい行いは将来を変える」を引用しながら説明したいと思います。　
■「正しい行いをする」という気持ち　
連載第6回「正しい行いは将来を変える」より 　
「楽をしたいと思ったときにも正しいことをしましょう」　
仕事をしていると、「楽したいなあ、手を抜きたいなあ」という衝動に駆られることがあるでしょう。人間は弱い存在なので、こういう誘惑に駆られることは誰にでもあります。　
例えば、以下のような場合でしょうか。　
プログラム設計書に設計ミスを見つけた。修正自体に結構工数がかかるし、変更による影響範囲を調査するとなると、ほかのチームにも影響調査を依頼しなくてはならず、数日はかかる。設計書の納期は明日だ。設計ミスには誰も気付かないだろうから、後工程の開発段階で修正すればいい。今日のところはこのままにしておこう。 　
プログラムを開発しているが、どうしても納期までに完成しない。先週の報告で進ちょくに問題なしといってしまった手前、いまさら遅れましたともいえない。主要な機能は開発したから、例外処理の一部くらいなくても動くには動く。どうせバレないから一部開発せずに納品しよう。 　
プログラムのテストをしているが、不具合(バグ)が取り切れない。並行で作業しているほかのチームは不具合を順次解消しているのに、私のチームは不具合が毎週増加している。このままでは、後工程の統合テストに間に合わない。不具合解消済みとうその報告をしてもバレないだろうから、後工程の統合テストで不具合を直せばいいだろう。今週はオンスケジュールと報告してごまかそう。 　
(中略)　
楽をしたいという誘惑に駆られるだけでなく、実際に不正なことをしてしまう人は「誰でもやっていることだ。どうせバレないからやってしまえ」とでも思っているのでしょうか。　
(中略)　
自分にうそをつくことはできません。このような手抜きに慣れてしまうと、最終的には自分自身を律することができなくなります。　
ちょっと視点を変えてこの問題を考えましょう。皆さん、小さいころのことを思い出してください。親、兄弟、親戚、先生、友人などいろいろな人からいろいろなことを教わったでしょう。家庭では特に何を教わりましたか。意識するしないにかかわらず、家庭では具体的な知識や知恵よりも、道徳観・倫理観を学ぶのではないかと思っています。　
少々前に人から聞いた話ですが、最近中高生の万引が後を絶たないそうです。万引をした中高生は、逮捕(正しくは補導でしょうが、あえてこの言葉を使います)された後こういうそうです。　
「バレたら商品を棚に戻せばいいんだろ。それか親に金払ってもらえば、店ももうかるだろ」　
要は、彼らは「万引＝窃盗＝犯罪行為」という理屈が分かっていないわけです。万引きを回避するための店側のコストや店の人の気持ちにも、思いが至らないようです。　
さらにいうと、これらの中高生の親もまた親で、万引したわが子を注意するどころか、以下のように開き直るそうです。　
「ちゃんとお金を払って商品を買う。何なら余計に払う。何が問題なの？」　
罪悪感のかけらもないとのことです。思うにこういう親子は、長い世代、こういう残念な考え方を家庭の中で脈々と伝承してきたのでしょうね。　
さて、この辺でビジネスの話題に戻りましょう。　
万引是認親子が残念な考え方を継承してきたこと同様、会社組織においても、残念な考え方を継承していることがあります。不正な行為を当たり前のように繰り返す人が多い組織があるのです。　
連載第6回で挙げた上記の例は、少々アレンジしてありますが、すべて本当にあったことです。「信じられない！ そういう人の良心(両親？)を疑う！」という人は、正常な神経の人なのでしょう。少なくとも私はそれが正常と信じたいです。　
「ああ、よくある話だよね。おれなんてもっとひどい話を知っているよ」という人は、個人的には極めて残念です。　
そういう場合、本人よりもその人が所属している組織に問題があることが多いです。組織全体に不正を是認する風潮があれば、自然に全員が不正をはたらくわけです。　
先の万引是認親子の例では、子どもよりも親の方が問題だと思います。これも同じ理屈です。本人の問題というよりはむしろ、本人が所属している家庭・組織の問題だというわけです。　
ですから、連載第6回にも書いたとおり、以下のような考え方が重要なのです。　
あくまでも自分のために、自分の将来のために、いまがつらくても正しいことをしようという考え方が重要です。このような行為の積み重ねが、ひいては自分の将来を変える「立命」につながるのです。　
どうでしょうか。「正しいことをしよう」という考え方ができるかどうかは、気持ちの問題だと思います。万引はいけないということを説明するにしても、議論の根拠となる理論があるわけではないでしょう。理路整然と説明することには一定の困難を伴うでしょうし、そもそも万引は犯罪だから、理屈抜きでやってはいけないわけです。　
「万引をしない、罪を犯さない」という気持ちを持つことは、ココロの問題といえましょう。同様にSI(システム開発)プロジェクトにおいても、「うそをつかない、手抜きをしない」という気持ちを持つことはココロの問題でしょう。　
このようなココロの強さ、英語でいえばメンタル・タフネスを持つことが、プロジェクト遂行上重要になると私は考えます。ですから、ココロ、リーダーシップトライアングルでいうLoveが、リーダーシップを発揮するために必要となると考えます。　
■3つの「識」　
考え方を変えて、もう少しココロの重要性を考えましょう。　
この連載で何回か紹介している安岡正篤氏の考え方を引用します。彼の著書『佐藤一斎「重職心得箇条」を読む』(致知出版社刊)に、以下のくだりがあります。　
知識というものはごく初歩というか、一番手近なもので、知識がいくらあっても見識というものにはなりません。見識というのは判断力です。見識がたたないとどうも物事は決まらない。見識の次に実行という段になると、肝っ玉というものが必要となる。これは実行力です。これを胆識と申します。知識、見識、胆識、これが「識」というものの三つの大事なことです。　
知識・見識・胆識について、私なりに整理させてください。　
ここでいう知識とは、知っていることですね。単に知っているか知らないかという単純なレベルです。見識のレベルになると、知識の積み重ねから総合的な判断を下すことができます。胆識のレベルでは、見識に基づいて判断したことを実行に移せる、行動力をもって実現できるということと理解しています。　
SIプロジェクトにこの考え方を当てはめましょう。　
知識とは、例えばOracleを知っている、SAPを知っている、ネットワークを知っているというレベルです。知識はSIプロジェクトではとても重要です。知識のない人をいくら採用してもプロジェクトは機能しません。ただし、この連載で繰り返し説明しているように、知識がある人だけが集まっても、プロジェクトはうまく機能しないです。　
見識は、私の理解では、知識の集積から出てくる判断力ですね。　
TCP/IPの知識、ルータのアクセスリスト(ポート番号やIPアドレスを使って経路をスクリーニングする)の知識、UNIXで使われるポート番号の知識、アプリケーションのポート番号の知識(Oracleは1521番など)、開発環境・テスト環境・本番環境のセキュリティレベルの知識などは、上記の知識のレベルです。　
これらの知識をすべて理解して初めて、開発環境のネットワークのセキュリティを設計することができますよね。開発環境からテスト環境ではOracleの1521番を通すアクセスリストをルータに設定するが、本番環境には1521番ではアクセスさせないなどのルールを決めることができます。　
ほかの例として、Webアプリケーションのトランザクション管理のポリシーを理解するには、Webブラウザから発信されるHTTPの特性、HTTPを受けるWebサーバ(Apacheなど)の処理特性、Webアプリケーションサーバ(Tomcatなど)のトランザクション管理の処理方式、Oracleのトランザクションの考え方、OracleのRedoログと耐障害性の考え方などさまざまな知識が必要です。それらの知識の集合体として、Webアプリケーションのトランザクション管理ポリシーを決定することができます。　
つまり見識は、知識の集大成を基に総合的な判断をすることと理解しています。　
IT業界での役割分担を考えると、プログラマとかSEと呼ばれる人がだいたい知識のレベルで仕事をし、上級SEとかITコンサルタントと呼ばれる人が見識のレベルで仕事をしていると、私は理解しています。　
■プロジェクトマネージャに必要な「胆識」　
では胆識は、IT業界ではどのように当てはまるのでしょうか。　
思うに、胆識こそプロジェクトマネージャが持つべき考え方です。プログラマやSEが知識のレベルで仕事をし、上級SEやITコンサルタントが見識のレベルで仕事をするのと同様に、プロジェクトマネージャは胆識のレベルで仕事をするべきなのです。　
胆識とは、安岡正篤氏が「見識の次に実行という段になると、肝っ玉というものが必要となる。これは実行力です。これを胆識と申します」と書いているとおり、実際に行動して、遂行することです。　
SIプロジェクトに当てはめると、知識レベルのことをSEやプログラマが考え、見識レベルのことを上級SEやITコンサルタントが判断します。具体的には、知識レベルで実装の仕様を決定し、見識レベルでこうすればシステム全体は動くという判断をします。つまり現場の仕事は知識・見識のレベルで終わってしまうと私は考えます。　
ただ、現実のシステム開発プロジェクトでは、こうすれば実装できるというところまで煮詰まっても、その実装仕様が実現されないことがあるのです。　
例えば、購買部門の担当者の承認を得ないと実装に必要なパッケージソフトが購入できない、外部システム接続の仕様決定の過程で、実装しなくてはいけない仕様を先方のシステムとこちらのシステムのどちらが実装するかでもめる、契約書上グレーゾーンになっている作業について協力会社間で争いになり、やらなくてはいけないことが放置されるなどなど。　
これらの問題を解決するには、責任を持って意思決定し、行動力を持って仕事を前に進める意識とでもいうべきものが必要です。これが胆識だと私は理解しています。　
このように行動力を発揮して実現させる気持ち、心構えは、リーダーシップトライアングルでいうところのココロです。従って、ココロはリーダーシップを発揮するにあたって必要な条件であると思います。　
前回「ソフトウェアは目に見えない」の最後で、以下のように書きました。　
確かに道具は大事です。大工さんが道具としてのノコギリとかカナヅチ(現在の建築工法でノコギリとカナヅチを使っているかは分かりませんが)を知らないで大工さんではあり得ないのと同様です。SIプロジェクトの管理者・リーダーとして、道具としてのCMM、PMBOKを理解していないわけにはいきません。　
ただ、道具をよく知っていても、使う人が魂を入れなければ意味がないと私は考えます。魂、ココロ、つまりリーダーシップトライアングルでいうところの「Love」が大事なのです。いい方を換えると、道具の使い方は連載第1回での「Howの軸」に当たります。「Whyの軸」、つまりなぜ道具を使うのかを正しく把握するには、ココロの要素が重要となるのです。　
「楽をしたいと思ったときにも正しいことをしましょう」という考え方、「胆識」のレベルの仕事という考え方、つまりリーダーシップトライアングルでいうLove、ココロの力がなければ、前回の連載でいうところのCMM、PMBOKといった「道具」が生きないのです。　
Love、ココロ、仁愛があって初めてリーダーがリーダーたり得ること、リーダーシップの必要条件がそろうことがご理解いただけたと思います。