以下では、“気づき”、“思い込み”がＩＴプロジェクト管理とどのように関係しているかについて順に述べます。

（１）　気づき

　知識や経験が少ない子供にものごとを教えるのは、大人に教えるのに比べ、大変難しい面があります。大人にとって当たり前のことが、子供にとっては何を意味するのか全く理解できないことが多いからです。子供の教育は理屈で教えるのでなく、“気づき”に重点を置かなければならないからです。初めてのことに気づくのは一人ひとりがもっている体験に大きく依存します。教える側が一方的に説明して終わりにすることはできません。やる気がなければ“気づき”は生じないでしょうし、興味がなければやる気はでません。

　私は心理学を学んだことがありませんから、私の述べることを頭から信じてもらっては困るのですが、私は子供の“気づき”のおおもとは遊びにあるのではないかと思っています。自然の中で遊んでいるといろいろな動植物に出くわします。考える以前に既に“ある”ものを受け入れています。虫にもいろいろな違いがあり、草木にも違いがあります。子供はいつの間にかその違いに気づいています。同じものと違いがあるものを認めると、自然に数の概念が生れます。年上の子が「いっぴき、にひき、さんびき、・・・」と言うのを聞いて、既に分っている同じものの数を「あっそうか」と気づくでしょう。学校では、「いっぴき」に１、「にひき」に２、「さんびき」に３という文字を対応づけるだけで算数を教えることができるようになります。

　友達と遊んでいると、あの子はやさしいと思ったり、意地悪だと思ったり、言葉にはできないながらも、好きだと感じたり、嫌だと感じたりするでしょう。やさしいと思っていた子が急に意地悪になったりする経験もするでしょう。幼いころは分らなかった人の気持ちが、いろいろな子供達と交わるにつれて一人ひとりの違いに気づき始めるでしょう。思春期にさしかかると、それまで曖昧だった自分に気づき、自分を客観的に見つめることができ、はっきりと自分と他人を区別します。

　このようにして子供は遊びを通して自然や社会を認識して行きます。

　気づくことに重心が置かれた子供の学習は知識や経験が豊かになるにつれて、理屈で理解するようになります。大人になれば、論理的思考に重心が置かれ、“気づき”による学習の比率が小さくなって行きます。しかし、“気づき”による学習は大人にとっても重要な意味があります。失敗を重ね、悩みに悩んでいるとき、他人の一言で悩みの出口に気づくことがあります。つまり、“気づき”とは学習の本質と言えるでしょう。

　では、ＩＴプロジェクト管理に於ける“気づき”の重要性はどこにあるのでしょうか。私は、暗黙知の伝承は“気づき”にあると思っています。本人がもっている知識や経験を背景に気づいてもらうことが暗黙知の伝承の本質ではないかと思うのです。

　ITプロジェクト管理に於ける暗黙知の伝承方法については、前稿：「プロジェクト管理における暗黙知と形式知（その２）」で述べましたが、ここでは伝承内容については何も触れていません。

　暗黙知は“共同化”プロセス、即ち、ITプロジェクトのメンバが共通の場で、体験共有、相互理解、共感、観察、模倣、訓練、演習、ＯＪＴ、ブレーンストーミングなどの活動を通して伝承します。

　例として、ソフトウェアの設計レビューについて考えて見ましょう。設計書を用いたレビュー会議に於いて、レビュアーが設計者の説明の曖昧さに気づいて質問するとします。そのときの設計者の反応として、

（ａ）	直ぐに自らの誤りに気づく
（ｂ）	直ぐにはレビュアーの指摘内容が理解できず、逆に意図を質問する
（ｃ）	「自分の考えは正しい」と反論する

などがあります。

　（ａ）のケースは、設計者はレビュアーに近い能力を持っていると言えるでしょう。しかし、（ｂ）と（ｃ）のケースは、もしレビュアーの指摘が正しいとすれば、設計者には理解不足があるか、誤解している可能性があります。（ｂ）のケースではレビュアーと対話する中で自分の誤りに気づき、設計のやり直しをするでしょう。

　（ｃ）のケースでは、設計者は自分の考えが正しいと信じているため、やっかいになることがあります。設計者を正しい方向に導くには、矛盾を突くなど、設計者が納得するまで対話しなければなりません。明らかな誤りの場合、修正は容易ですが、変更容易性、拡張性、相互運用性などソフトウェア・アーキテクチャの問題になると、当座のことしか考えていない設計者にその必要性を理解してもらうのは骨がおれます。論理にばかり気が回って、ソフトウェア・アーキテクチャの重要性に“気づき”が生じないのです。こういう場合には、いろいろな事例を挙げて、何故失敗したかを追体験してもらうのが良いのですが、それでも納得しない設計者には一度失敗をさせないと理解されないかもしれません。しかし、中には何度失敗しても懲りない設計者もいますので、そのときは担当を外す以外に道がないかも知れません。

　このように、“気づき”は暗黙知の伝承の本質的働きであると考えられます。ITプロジェクト管理においては、管理者・担当者の“気づき”を促すために、実際の経験と日々の学習を怠らないことが肝要です。

（２）　思い込み

　（１）（ｃ）のケースで少し触れましたが、“思い込み”はなかなか面倒な問題です。

　“思い込み”は一つの考え方、独自の考え方、パターン化した考え方に慣れ親しんでいると起こりがちです。周りの環境が変化したとき、その変化に旨く対応できなくなります。これが思い込みの弊害です。

　小さな思い込みの例は、チームでソフトウェア開発を行い、障害が発見された場合、関連するモジュールのどこに問題があるか検討しているとき、自分が担当しているモジュールに原因があると考えたくないものですから、原因は担当外のモジュールにあると他者に調査を振るケースがあります。先ずは自分を疑ってみると言う謙虚さが要求されます。

　もう少し大きな例として、「品質問題が起きるのはテストが不十分だからだ」というのがあります。テストさえ十分に行っていれば、品質問題は防げるはずと考えるのは必ずしも正しくありません。もし、設計やコードに曖昧な論理が組み込まれている場合、テストをいくら重ねても品質を向上させるのは困難です。行きつ戻りつの状態を延々と続けることになるでしょう。このような思い込みをしていると、「テスト部隊さえしっかりしていれば、出荷品質は完全」という判断をしてしまいます。設計やコードが正しいか否かの判断はテストではなく、レビューに依ります。

　もう一つの例は組織に関わるものです。比較的大きなソフトウェアの開発・維持（保守）を行うには、少なくとも企画・営業・開発・品質管理部門が必要となります。このような組織で開発するソフトウェアの品質問題に焦点を当て、考えて見ましょう。経営者や管理者の中には、ある種の思い込みをしている人がいます。単純化して纏めると、次のようにレベル化できます。

（ａ）	品質管理部門を設置すれば、品質は改善維持できる。
（ｂ）	品質管理部門が100％機能すれば、品質は改善維持できる。
（ｃ）	開発部門と品質管理部門が100％機能すれば、品質は改善維持できる。
（ｄ）	企画・営業・開発・品質管理部門が100％機能すれば、品質は改善維持できる。

　（ａ）は、経営者や管理者が、品質管理部門を設置すれば、後は自然に旨く行くものだと信じているケースです。組織だけ作っても、部門が機能しなければ、無駄なコストになるだけです。このレベルで考えている経営者や管理者は今時存在しないと思いますが、２，３０年前にはそうとも取れることをやっていました。

　（ｂ）は品質管理部門が、自らのミッションは、開発部門から受け取ったソフトウェアに関して、

・	（機能・総合）テストを実施する
・	品質状況を把握し、報告する

と捉え、開発部門に対して発言力がないか、もしくは弱いケースです。開発部門から品質管理部門に渡された時点のソフトウェアの品質には差があります。非常に悪い品質をこの段階でテストにより向上させることは不可能です。

　（ｃ）は一般的なケースです。開発部門と品質管理部門とが密に連携して品質改善に努力したとしても、顧客ニーズをしっかり捉えているか、マーケットに投入するに足る機能を完備しているかという視点が抜けていては、せっかくの努力が水泡と帰します。顧客ニーズを満足しているか、営業し易い製品に仕上がっているかという視点から確認する必要があります。

　（ｄ）は（ｃ）の不足を補ったケースです。（ｄ）のケースに満足して、これ以上やることがないと思い込んでいることはないでしょうか。（ｄ）のケースでは経営者の関与が足りません。全社の製品開発への目配りが十分でなく、重要なソフトウェア開発に対するリソース配分を誤ると命取りになることがあります。

　このように、品質問題を取上げてみても、思い込みは危険を孕んでいると言えます。

■