今や、開発工程管理や、スケジュール管理、体制、マネジメント等、開発に関する「マニュアル」は整備され、揃っているのに、何故未だにトラブルや動かないシステムということが話題になるのだろうか。ひょっとすると、「日本人気質」がその要因の一つではないかとの思いから、今回はその観点から語ってみたいと思います。内容は、チェック項目的な表現としておりますので、該当ありか無しかを検証（〇×）頂くということもありかと思います。ただ、記載順序や内容レベルなどマチマチになってしまっているかと思いますので、その点はご容赦ください。

１．どのような気質、性格、タイプ？
01.マニュアルの内容は理解しているが、プロジェクト事情は多種多様であ
　り、内容通り実践するのは「帯に短し襷に長しだ」と考えている？
02.マニュアルの教育は受けたが、座学の教育の場はあくまで「教育であり、　
　実践とは違う」と考えている？　（努力義務的な認識？）
03.マニュアル通りにしか実践できないのは、「頭が悪い、能力が低い奴が　
　やること」と考えている？
04.標準化されたマニュアルより、自身の「経験」「ノウハウ」の方を優先
　すべきと考えている？
05.失敗事象より、成功事例を重要と考えている？　（失敗事象を伝承すべき
　とは考えていない？）
06.某自動車会社での「なぜ、どうして」を最低５回は自問するということに
　感心はするものの、そこまで実践する必要は無いと考えている？
07.性善説で、推進して良いと考えている？（それが可能なら、開発に必要な
　リソースを低く抑えられるし、楽であると考えている？）
08.自身のことは、「棚に上げられない」と考えている？（自身がやってこな
　かったこと、出来ていないことは、他人には指示出来ない？）
09.一度始めた（決定した）ことに対しては、止められない、止めたくないと
　考えてしまう？（成功追求型？ぐずぐず引っ張ってしまいがち？）
10.自身の能力の限界を認めたくないタイプ？　（けして、出来ないと言わな
　い、他の人のノウハウを活用するのは苦手？）
11.自分の常識は、他の人の常識でもあると思いがち？（理解し、やってくれ　
　るハズ、出来るハズと思ってしまう、しまいたいタイプ？）
12.課題を上げるのは自身の役割だが、対策を考えるのは「上司、リーダー」　
　の役割と考えている？
13.課題、リスク事項は上げるが、そのコスト換算まではしないタイプ？
　（商談検討会などの場で、契約金額を上げる指示を極力回避したい）
14.他のグループ、個々人がやっていることに対して、口を出したがらない
　タイプ？（余計なことだと考えている？）
15.一夜漬けタイプ？（追い込まれるまで、本気になれないタイプ？事前に、
　突っ込まれたくないタイプ？）
16.報告（特に悪い報告）は、事後またはギリギリまで延ばすタイプ？（怒ら
　れるなら一度で済ませたいし、まだ大丈夫（楽観主義）と思い込む）
17.顧客に頼られると、弱いタイプ？（yesマンこそ、顧客本位と思い込んで
　いたりしない？）
18.契約条項などは、あまり気にしないタイプ？（お金より、自身の信用や、
　活躍の場（信頼）を重んじるタイプ？）
19.契約の「話し合い（本契約に記載が無い事項、疑義が生じた場合は、双方　
　誠意をもって話し合う）」という条項があるは、当然と考えている？
20.自身の受託範囲だけを重視し、システム全体感を意識することは出来れば
　避けたいタイプ？（全体のことは、総責任者の問題だと考えている？）
21.商談などで、顧客予算を気にするあまり、必要なマネジメント、チェック
　体制などに手心を掛けてしまうタイプ？（この程度で何とかなるかも？）
22.事前に、自身のノウハウ判断で顧客と予算などについて「握ってしまう」
　ことがある？（予算審査会などの形骸化を招きかねない自覚無し？）
23.追求したがらないタイプ？（他の人を追い込むことへの忌避感あり？自身
　が突っ込まれることは避けたいタイプ？憎まれっ子にはなりたくない？）
24.突っ込まれると、被害者意識を強く感じてしまうタイプ？（第三者介入は
　回避したい？冷静でいられなくなるタイプ？）
25.ノウハウの習得は、出来る人の「背中を見て得よ」を良しとするタイプ？（教育などでの伝承より、有効と考えている？）

２．対策案
　答え的な話は、「対応すべき当然のことを、当然として実践すること」に尽きてしまうのですが、特にプロジェクト運営においては「性悪説で運営し、嫌われることにも臆さない対応」が、必要不可欠ではないかと考えています。当然ながら、そのやり方や、表現方法、接し方、提示の方法論などには、それぞれのメンバーにあった工夫をして下さい）

01.出来ること、出来ないこと、曖昧なことをハッキリ提示すること。
（当然のことながら、代替え案付がベストです）
02.想定外のことが分かった時は、速やかに公開すること。自身で、抱え込む
　ことが無いようにすること。（他のチームのことであっても）
03.自身で解決し得るレベルのモノ、コトなのかの判断を速やかに行うこと。　　（報連相のタイムリーさを徹すること）
04.課題などを提示する際には、必ず「対策案」を一緒に提示すること。　
（実行確約の確認と、不履行時（リスク発生時）の対応を明示すること）
05.中断、撤退要件を、事前に明確にしておくこと。合意しておくこと。　　　（難しいことではありますが、引きずらない取り組みが重要と考えます）
06.原理原則をないがしろにしない。　
（第1項に上げた事項を払拭すること。不要なプライドは、抑制すること）
07.常に、構築システム全体感を意識、認識した取り組みを行うこと。　
（自身のチームだけのことを考えず、常に全体との関連性を意識すること）
09.ヒューマンエラーは、必ず発生する可能性があるという意識で取り組む
　こと。そうした観点で、マニュアル、過去の事例を活用することが大切。
08.プロジェクトを監査する際は、必ず「３現主義（現場、現実、現物）」
　に基づいた取り組みを行うこと。（進捗報告などを、報告書と担当者の
　口頭報告だけで済まさず、必ず「現物（裏付け）」を確認すること。

　当然ながら、ここに記したことだけで解決するなどと考えている訳ではありません。しかしながら、まだ「人で作る」ということが避けられない世界ですので、関係者の「気質、性格、タイプ」を理解した取り組みが必要であり、重要であると考えています。（それを支えるフォロー体制も忘れずに）
　是非、この機会に再検証の観点として継続検証頂ければと思います。
（ただ、「生成AIがさらなる進化するまで」かもしれませんが・・・・？）
　次回以降、引き続き「IT人材関連」に関わる事柄について紹介していきたいと考えていますので、宜しくお願い致します。