先の第三回分ですが、改行ズレを起こしてしまう編集方法をしてしまったため、改めて再構成させてもらいました。ご容赦下さい。（タイトルも変わっています）　それでは、以下、改定版。

開発工程管理や、スケジュール管理、体制、マネジメント等、システム開発に関する「マニュアル」は整備され、企業内で用意されるだけではなく、書籍やネット上にも揃っています。にも関わらず、なぜ未だにトラブルや動かないシステムが話題になるのでしょうか？
ひょっとすると「日本人気質」がその要因の一つではないか？との思いから、今回はその観点から語ってみたいと思います。

目次
●日本人って、こんな考え方していない？
●システム開発で失敗を呼ぶ「日本人気質」チェックリスト
●「日本人気質」が原因で失敗しないために

●日本人ってこんな考え方していない？
ちょっと大げさな（日本人って）書き方をさせてもらってしまいますが、プロジェクトを開始する際、こんなことを思われたことはありませんか？
・公式の場では、正論を言う。
・開発手法・技法などの解説書（本論は、マニュアルと表現）は、参考程度に使うモノ。
・ノウハウは、教えられるものではなく、自身で努力して得るものだ。
・開始時から、後ろ向き発言はしたくない。（自信がないと思われるかも）
・同じプロなんだから、何か必要なことが起こったら知らせてくれるハズ。
・理解力に差はあまりないはずだから、同じように考えてくれるハズ。
・役割分担（縦割り）を超えた発言は、僭越だ。
・第三者チェックは避けたい。（関係ない他人に干渉されたくない）
・責められたくないので、途中報告は、穏便に済ませたい。
・契約内容は大事だけど、顧客信頼を得る方がもっと大切だ。
・何か事が起こると、「不測の事態」と言い、反省を避ける。
などなど、皆様は、如何でしょうか？

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

●「日本人気質」が原因で失敗しないために
答えは、「対応すべき当然のことを、当然として実践すること」に尽きてしまうのですが、特にプロジェクト運営においては「性悪説で運営し、嫌われることにも臆さない対応」が、必要不可欠です。（当然ながら、スムーズなプロジェクト運営においては、やり方や、表現方法、接し方、提示の方法論などには、それぞれのメンバーにあった工夫が必要ですが・・・）
1.     出来ること、出来ないこと、曖昧なことをハッキリ提示すること。（当然のことながら、代替え案付がベスト）
2.     想定外のことが分かった時は、速やかに開示すること。自身で、抱え込むことが無いようにする。開示することは「善」であり、「言いつける」ではないという意識付けをすること。（他のチームのコトであっても）
3.     自身で解決し得るレベルのモノ、コトなのかの判断を速やかに行うこと。　　（報連相は、タイムリーさに徹すること）
4.     課題などを提示する際には、必ず「対策案」を一緒に示すこと。　（実行確約の確認と、不履行時（リスク発生時）の対応を明示すること）
5.     中断、撤退要件を、事前に明確にしておくこと。合意しておくこと。（難しいことではあるが、引きずらない取り組みが重要）
6.     原理原則をないがしろにしないこと。（日本人気質事項を払拭すること、不要なプライドは抑制すること）
7.     常に、構築システム全体感を意識、認識した取り組みを行うこと。（自身のチームのことだけを考えず、常に全体との関連性を意識すること）
8.     ヒューマンエラーは、必ず発生する可能性があるという意識で取り組むこと。そうした認識で、マニュアル、過去の事例を活用すること。
9.     プロジェクトを監査する際は、必ず「３現主義（現場、現実、現物）」に基づいた取り組みを行うこと。（進捗報告を受ける時、本人の報告記載内容と口頭報告だけで済まさず、必ず「現物（裏付け）」を確認すること。

当然ながら、ここに記したことだけで解決する訳ではありません。しかし、まだ「人で作る」ということが避けられない世界ですので、関係者の「気質、性格、タイプ」を理解した取り組みが必要です。（それを支えるフォロー体制も忘れずに）　　　　　　　　　　　　継続的に検証することで、回避できるトラブルも多いはずです。　　　　　　　　　　　　　、「生成AIがさらなる進化するまで」かもしれませんが・・・？）