Step-１：最初は、社内品質向上運動や社内規範に合う「気づき」「ひらめき」を分類し（「ピンー」と来るものを）そのまま報告する。
各プロジェクトマネジャー会議用＆人事研修のタイミングを合わせる。
（初期段階で各人の「気づき」の評価はしない。余りフィルターを掛けない方が良いのではないか・・・）
自分に内在する、この「認知システム」を気づかせる事で振る舞いが変わってくる。
研修は手掛かりを与え「気づき」はそのアウトプットである。
Step-2：良い指摘や個人「気づき」であっても、全体が明るくなったやチームの声が大きくなったや成果の要因でないか？と
思われるものを時系列で、プロジェクトの進行に合わせDB化する。そして誰からのアクセスも保証する。
紹介
Step-3：組織内「品質委員会」等IT統制下で、各PM担当が自分の領域内で起きた事の評価、効果や取組状況を報告。
Step-4：起点である「気づき」とプロジェクトの進行を第３者が、定性・定量面合わせ成功要因を探ってゆく。
全社に発表前に、本人の忌憚なきコメントをいただくこと。
※実施にあたっては社内組織の諸活動により整合性を保ちながらのスタイルは個別に変わってくるものです。
その構築理念では、書籍：北大路書房刊の『自己調整学習と動機づけ』、も参考になる。
※全社的な「IT監査」「ITガバナンス」の一貫として,機能する様になれば、効果発揮できるであろう。
この場合、自組織で採用されているIT統制（「COBIT4.1」、「日本公認会計士協会IT委員会報告第３号Ⅲｰ2」等）と平仄を合わせるのが寛容となりましょう。
＜参考＞
『COBIT®』（Control Objectives for Information and related Technology）では、その意義として経営目標とそれを支えるITインフラストラクチャー（IT基盤）の乖離をコントロール（統制）するものであると定義され、取締役の義務とされている。そして、ITは経営目標に対して有効性、効率性、信頼性、可用性、網羅生、機密性をその要件としている。ITプランの計画から調達。導入、サービス提供とサポートそして保守運用と評価の全般に渡ってその守備範囲と定めている。
特に、P07でIT人材の管理、DS7で利用者の教育と研修など情報サービス部門のみならず経営方向と現場実態の両睨み外交を必須としている。
そしてシステム監査では、IT資源がビジネス目標に対して充足して満たされているかの視点で監査をする。IT資源はハード、ソフトの基盤や「人」の資源が満たされているかの視点である。目標に対して必要要員が確保（量質）されて遂行されているかである。 ISACAでは、自社内の自立的システム監査機能としてCSA;Control Self-Assessment技法の中で、全てのレベルの従業員参加、訓練のもとで「継続的な改善、学習カーブ」が成功要因とされている。
また、本邦FISC監査指針では、情報システム組織に「教育・研修等の記録」を義務づけている。
情報システム部門は、自分達のレベルアップ（しなければこの荷物は重い）のみならず、他部門教育管理なで担わされている。自分達が、一歩リードし規範のモデルとならねば誰も付いてこないのでないか。 システム管理者は、経営目標をこなして行くに足りる人材が備わっているか、足らねば調達したり、内部研修による人材養成は義務でもある。ビジネス変革が激しい中、益々、経営目標との乖離が大きくなっていないか今の時点で再認識したいものである。
「現状」と「将来のあるべき姿」の間に、求められる成長パスに乗っているかである。
３：IT's-Prevensionの為の究極なる手順
特に、ミッションクリチカルなシステム業務に携わる部署にあっては、それを運用し全組織で品質向上を目指さねばならない。その為のシステム提供部門は「FMEA」、「FTA」、「FMEAとFTAの結合」概念を導入するのが、ISの究極目標に近づく手段となるのでないか。
「FMEA」、「FTA」、「FMEAとFTAの結合」概念を自社流にモディファイし、それを築き上げ運用する過程で、熟練した進行役と適切な参加者が求められ、（プログラム瑕疵、ヒョーマンエラー相乗作用による事故は、時として訴訟までに発展するが、容認できる欠陥はこれまでに一度も起たことがないものだけ・・・という確固たる信念のもとに欠陥ゼロを目指す気概を成功を近づけるのでないか）そしてフォーカスエリアの明確な理解（会社の緊急度と専門知識の総合判断力が要求される＝これが企業力となり顕在化する）が、企業価値の向上/企業レプテェーションの高揚につながるのである。
「FMEA」は、1949年米国軍用手順（MIL-P-1629）として「故障モード、影響、致命度の解析における手順」として策定され、「FTA」は、1960年代米国のミニットマン・ミサイルが誤って打ち上げられる事態を懸念して、ボーイング社が兵器のあらゆる面を分析する方法として開発されたといわれています。その後、技術の民生活用で自動車産業、原子力発電等の分野で安全性解析や危険性解析のために普及しているが、ソフトウェアの文献や開発プロセスに現れ始めたのは1980年半ばとされる。※書籍紹介
業務アプリケーション分野にも巨大化と複雑性が増しており、基盤提供会社（OSやミドルソフト提供）のみならず、ミッションクリティカルなシステムを構築する分野や社内品質委員会の尺度に有用な手段となるのでないか。
※http://www.defectprevention.org/book.aspx
※参考図書：http://www.defectprevention.org/Recommended.aspx
※日本語図書：『ソフトウェアの欠陥予防』 テストより確実な品質改善法 日経BPソフトプレス刊
※日本語図書：『脅威モデル セキュアなアプリケーション構築』 日経ＢＰソフトプレス刊
