プロジェクト管理（鉄道RAMS，自動車ISO26262）のエッセンス資料 （私の日立製作所での最後の成果物）
大前提 日本国憲法
第十二条 この憲法が国民に保障する自由及び権利は、国民の不断の努力によつて、これを保持しなければならない。又、国民は、これを濫用してはならないのであつて、常に公共の福祉のためにこれを利用する責任を負ふ。
憲法には，”自由及び権利は、国民の不断の努力によつて、これを保持しなければならない。”という一文がある。
働いていない人であっても，”不断の努力によって”保持するべきものがあるのであるから，プロジェクトを任された者においては，プロジェクトとして，”不断の努力によって”保持すべきものも必ず存在する。
日本国憲法を大前提として，プロジェクト憲法を以下のように決める。
第一条 リーダー及びメンバーが，プロジェクト内にて問題点を発見ないし申告した場合，問題点を改善することこそが目的である。
この原則に立ち返り，問題点を発見ないし申告したこと自体について叱責が生じることはない（法律違反を除く）。叱責が生じた場合，叱責を働いた人物こそが処分の対象となり得る。
第二条 リーダーは，自ら主体的に，プロジェクトに存在する問題点を発見する不断の努力を払う義務を持ち，問題点に対する全責任を持つ。
メンバーが問題点を申告しなかったことを理由に，メンバーを叱責する権限は持たない。メンバーが問題点を申告できない状態を認知できなかったこと，申告できない雰囲気を作ったことこそがリーダーの責任である。責任の所在に伴い，リーダー自身が処罰の対象となり得る。
第三条 リーダーは，メンバーの思考及び遂行について不断の努力によって尊重し，褒める義務を持ち，同時に，メンバーから学ぶ義務を持つ。メンバーは，自分の思考及び遂行について，リーダーにより認められる権利を持つ。
リーダー自身が実行可能なソリューションを，メンバーに押し付けるようなことがあってはならない。メンバーの得手不得手を理解し，メンバーに合ったソリューションを一緒に考えることのほうが先決である。
第四条 プロジェクト参加者は，最低１日１回，PDCAチェックを実施する。プロジェクトが大きい場合は，サブプロジェクトに分割することが可能である。
この場合，サブプロジェクトの全員が集まって行うPDCAチェックを実施し，プロジェクトリーダーは，最低限サブプロジェクトリーダー全員を集めたPDCAチェックを実施する。これは，プロジェクトリーダーが，末端の問題を吸い上げることを目的とする。
リーダーについてもPDCAチェックを行い，メンバーに対して手本を示す義務がある。
第五条 プロジェクト参加者は，Web上にて構築したシステムにアクセスし，成果物をアップロードする。また自分の置かれた状況に対して可能な限り記載する。リーダーは，メンバー全員の進捗において確認する義務を持つ。メンバー自身も，なるべく多くのメンバーの進捗を確認したほうが良い。
１．リーダーに関する規定
まず，リーダーは，学校における先生に相当する役割との認識を持たなければならない。
学校の先生であれば，例えば４０人クラスにいれば，その４０人全員の進捗を把握し，パフォーマンスを改善する義務を負う。
陥りやすい過ちとして，できるメンバーだけ伸ばせばよいのではないことに注意すべきである。リーダーが本当に考慮すべきは，できないメンバーのパフォーマンスをいかにして改善するかである。そして，できないメンバーのパフォーマンスを改善するノウハウこそが，組織全体を活性化させることはもとより，リーダーにとって次回からも生かせるノウハウとなるのである。
検討項目
・PDCAチェック（毎日実施。例えば始業前に計画をたて，退勤前に反省を行うのが良い。できれば全体で行う。）
1.メンバーの作業内容の把握。（重複部分，抜け，技量の巧拙などの把握。）
2.このメンバーであれば１日にてどこまでできるはずか，の想定と結果確認。
3.Web上にて，任意にメンバーの状況の確認。特に不調のメンバーに関して重点的な確認。
4.プロジェクト全体において，仕様書などの検討抜けのチェック。
5.不断の努力によつて，日本国憲法第十二条を守る。
6.プロジェクト憲法が守られているかの相互チェックを行う。
もし，リーダー１人では，”１日にてどこまでできるはず”という想定ができないほどにプロジェクトが大きい場合は，サブリーダーを設定してもよい。この場合，リーダーはサブリーダーを管理し，毎日のPDCAサイクルを回せるようにする。
例えば，始業直後/終業直前に，サブリーサー主催のPDCAチェックミーティングを行う場合は，リーダー主催のサブリーダー会議をそれぞれその後に行い，リーダーが全員の持つ問題点を的確に把握できるようにする。
サブリーダーの分割は，”このメンバーの力量と気力と体調ならば，１日にてどこまでできるはず”と想定できる単位になるまで，これを繰り返す。
但し，間違えてはならないのは，あくまでプロジェクトの全権者はリーダーということである。リーダーは，”このメンバーの力量と気力と体調ならば，１日にてどこまでできるはず”とまでは把握できずとも，頻繁かつ公平にメンバーと会話を行い，特に不調なメンバー及び若い/経験の浅いメンバーについて進捗/状態を把握する義務がある。この補助として，Webシステムを積極的に活用する義務を持つ。
リーダーは，プロジェクトのメンバーの進捗が把握できなくなった時点で，不断の努力によって保持すべき義務を果たしていないと看做される。
リーダーの上位上長は，やはり”不断の努力によって”リーダーと頻繁にコンタクトを取り，リーダーがメンバーの進捗が把握できなくなったと判断した時点で，リーダーに対して指導し，指導しても改善が認められない場合は，更迭を行うべきである。
メンバーが考えてきた意見に関して，違うからと怒ったり叱ったりするリーダーがいるが，絶対に叱ってはいけない。自分で考えるメンバーはなかなかいない。
それにも関わらず，メンバーは自分で考えてきたのである。その意見は尊重する義務が，リーダーには存在する。
仮にメンバーの意見がリーダーの意見と違っているとしても，リーダーの意見が100点で，メンバーの意見が0点ということは有りえない。
点数で表せば，例えば，リーダーの意見が80点で，メンバーの意見が40点なのである。
ひょっとすると，リーダーの意見が40点で，メンバーの意見が80点であり，リーダーが理解できていない可能性さえある。
リーダーは，メンバーがこの40点を取れた部分をしっかり評価した上で，どこをどう伸ばせば，自分にアイデアのある残りの40点が改善できるか，メンバーの能力や指向，得意なものなどを考慮に入れ，メンバーの気持ちに立って説明すべきである。そうすることにより，メンバーは40点の部分については自信を持ち，次回は40点以上の成果が出せる。
ここで叱ってしまえば，メンバーは0点からの出発となり，折角芽生えつつあった40点分の自信を喪失してしまう。仮にリーダーの指導により，このメンバーが今回は80点の成果を出せるとしても，このメンバーの身につき，次回に生かせるのは10点程度である。
すなわち，40点を認め伸ばすほうが，メンバーを育て，次回以降のパフォーマンスを改善することに貢献するのである。
リーダーは，メンバーを自分の意見どおりに変えようとするのではなく，メンバーの得手に合わせるよう，リーダーが主体的に”不断の努力によって”，メンバー個々に合わせたソリューションを考え出すべきである。
リーダーにしかできないソリューションを，メンバーに押し付けるようなリーダーがいるのであれば，本件はプロジェクト憲法第三条に反する。そのリーダーは，メンバーによりリーダーの上位上長に申告され，改善を要望される。改善が行われない場合，糾弾，または更迭の可能性を負う。
システムとしては，リーダーの意見に従わせることが必要なことも多いが，可能な限り，”不断の努力によって”，リーダーの意見でさえも一例として提示するにとどめ，メンバーにリーダーの案を下地として，さらに新たな案を考えられるように仕向ける方が良い。
これは，メンバーがノウハウを蓄積することにより成長を促進し，その結果，当該メンバーの急激なパフォーマンス向上が期待できるためである。
若い/経験の浅いメンバーには，リーダー自らがとりわけ気をかけるべきである。経験の浅いメンバーに教育を任せてしまう，或いは若い/経験の浅いメンバーは放っておき，自力での向上に期待するのは間違いである。これは，若い/経験の浅いメンバーを頑張って戦力にした方が，プロジェクトトータルの戦力が早急に向上し，結束力が高まるからである。また，リーダー自身が率先して若い/経験の浅いメンバーを教えることは，リーダー自身の能力，とりわけ理解力および説得力の向上に役立つことを，リーダーは認識するべきである。
そして，若いメンバーが頑張りを見せ，プロジェクトに新たな考えを吹き込むことこそが，プロジェクトを最も活性化することを，リーダーは認識するべきである。
なお，Webシステムからログを取得することにより，エビデンス資料は自動的に保管される。
以上の内容をリーダーが実行できているとすれば，鉄道版RAMSであろうが自動車版ISO26262であろうが，どこにどの資料を作成したか，どこの資料が規格の何に当たるか，監査時にはリーダー自身が説明できるはずである。
リーダー自身が説明できないのであれば，リーダーがプロジェクトを十分把握していない。
これはプロジェクト憲法第二条及び第四条に違反する。
2.メンバーに関する規定
・PDCAチェック（毎日実施。例えば始業前に計画をたて，退勤前に反省を行うのが良い。できれば全体で行う。）
1.担当範囲内における作業の実施。
2.問題点の報告と，それに併せた自分の考えの主張。
3.他のメンバーとの悩みや検討事項の共有（ノウハウの共有），改善点の検討。
4.不断の努力によつて，日本国憲法第十二条を守る。
5.プロジェクト憲法が守られているかの相互チェックを行う。
PDCAチェックにより，プロジェクト全員の成果物の進捗管理を毎日行う。
Web上のシステムにて，プロジェクト全員が任意の時間に状況を報告し，確認する。
メンバー同士が直接出会って会話をする，または電話やメールなどは補助の手段とすること，これらはもちろん推奨されるべきことではあるが，あくまで正となる情報はWebに置き，全員が任意に確認できることを基本とする。
【プロジェクト開始の前提】
計画ドキュメントを作成し，その正確性が重要との認識があるが，これは誤りである。
例えば，体重4000gで元気に生まれた子供だけがすくすくと育ち，2000gで瀕死の状態で生まれた子供の人生が一生不遇なものかといえば，全くそうではないことを考えれば明らかである。
本当に必要なのは，しっかりした計画ドキュメントなどではない。
毎日毎日不断の努力によって繰り返す，PDCAサイクルの繰り返しである。
仮に，1000人必要なプロジェクトがあったが，いいかげんに10人として見積もっていたとしよう。
10人としても，毎日毎日不断の努力によってPDCAサイクルをまわしていけば，１週間もすれば800人くらい必要な予想まではつくはずである。
PDCAサイクルを回すということは，正解に漸近していくということでもある。
これは，例えば頻繁な利用を経て，ソフトが枯れていくことや，新形式のメンテナンス手法が確立してくることなどからも容易に理解可能と思われる。
すなわち，計画は極論すればめちゃくちゃでもいいのである。
毎日毎日PDCAでチェックすることこそが大切なのである。
然るに，例えばあるプロジェクトでは，リーダーを，他プロジェクトも兼任している本部長として，PDCAのチェックポイントを１ヶ月とした。
このため，PDCAのチェックポイントにおいて，リーダーがメンバーを気遣うべきはずのところ，メンバーからリーダーへの説明の場と化してしまった。さらにリーダーがその結果に対してメンバーに対して叱責を行ったため，なんのためのPDCAチェックかが分からなくなってしまった。不要な資料の作成が増え，メンバーの不満も高まった。
これは，いまから考えれば，時間の無駄遣いである。
それが想像できなかった，リーダーこそが失格である。
本資料によれば，プロジェクト憲法第一条～第四条全条違反である。
このようなプロジェクトは今後二度とつくらないように，リーダー，メンバーともに肝に銘じなければならない。
リーダーが検討すべき事項は以下のような項目と想定される。
リーダーがプロジェクト憲法を守っていれば，特段難しいこととは思えない。
あとは，リーダーが適当にやってみて，PDCAサイクルを１ヶ月くらい回し続けて，自分から主体的に発見すること。
1.最初に決めないといけないものは，そのシステムの機能仕様である。
2.仕様が決まると，その製作に必要な機器構成，技術が決まる。
3.機器構成が決まると，仕様書の体系が決まる。
4.仕様書の体系に合わせて工程が決まる。
5.工程のパスが決まると，人員が決まる。
6.上記計画により，具体的に製作を行う。
1.の段階にて，システムに必要とされる機能，性能，全体寸法などが決まる。
2.の段階にて，システムに必要な構成に対して安全性を配分する。
→安全性の洗い出し，SILの同定
Safety Plan の作成
Systematic Fault への検討
3.の段階で，ハード，ソフトの仕様書体系が決まる。
6.が完成した段階で，Safety Case が完成
品質管理活動，安全管理活動は，一般的なもので良いと思われる。
下記よりファイル形式をダウンロードできます
https://docs.google.com/document/d/1Qc9UuJvIpkZrxv1dNfRgv9ZcOrS75pjfJp3n1ddiITA/edit?usp=sharing
« ジブリ汗まみれ「山口智子さんとの対談その３」の回を聴いて思ったこと | トップページ | 日立製作所の個人情報保護法違反メール(2012/8/2の内容の再掲) »
「日立製作所個人情報保護法違反」カテゴリの記事
- 日立製作所の上告審訴訟救助資料書き直しました。それにしても裁判所，夏井高人の資料一切検討してないってw(2015.06.02)
- 日立製作所に対する上告の訴訟救助の申請書，とりあえずこんな感じの下書きでどうでしょう？(2015.06.02)
- 本日私が受け取った，平成26年(ネ)5348号 日立製作所個人情報開示請求控訴審の，敗訴判決文です。皆さん判決文なんてなかなか見ないでしょう。 (2015.05.20)
- やはり敗訴させられました。また判決文アップします。裁判所前で星野文昭さん再審請求の支援者さんとお話しました。(2015.05.20)
- 今朝内藤さんのtwitterコメント返信に書いた文章です。長いのでこちらにも。(2015.05.15)
トラックバック
この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/1860320/51452595
この記事へのトラックバック一覧です： プロジェクト管理（鉄道RAMS，自動車ISO26262）のエッセンス資料 （私の日立製作所での最後の成果物）:
« ジブリ汗まみれ「山口智子さんとの対談その３」の回を聴いて思ったこと | トップページ | 日立製作所の個人情報保護法違反メール(2012/8/2の内容の再掲) »
コメント