TOP＞プロジェクト管理＞ マネージャーにこそ必要な実作業の体験
実践型プロジェクト管理
経験が物語る実践型プロジェクト管理

第４回：実作業者のモチベーションを考慮した会議
 著者：イマジンスパーク  深沢 隆司   2006/3/29
前のページ  1  2   3  次のページ
マネージャーにこそ必要な実作業の体験

   マネージャーは5〜10万ステップぐらいのコーディングを業務として1度は実際にやってみるべきでしょう。きっと、とても沢山のことが学べると思います。もし可能ならば、オブジェクト指向ではなくて旧式の、リンクの範囲でシンボルが重複できない環境がよいと思います。

   5〜10万ステップで何か1つの機能を実現するにあたり、サブルーチン名などが一切重複してはいけないような環境の中で、内部設計やコーディングをしてみましょう。頭で考えてみるだけではなく、実際に取りかかってみなければ体でコーディングの大変さがわかりません。

   さらに、「60ステップ以上は1つのルーチンとしてはいけない」というような、「〜はやってはいけない」といったコーディング規約が沢山あると、凄いこと（とんでもなく大変な作業）になります。

   研修でやるような50行や100行程度のコーディングではなく、上記のようなヘビーなコーディングを、OSのインストールを含む開発環境のセットアップから納品までに渡って、1つずつ自分で調べながら実施してみるべきでしょう。

   そうすれば、近年はオブジェクト指向などによって大幅に改善されているとはいえ、すぐに「少しでもプログラマや仕様策定者が仕事・思考をしやすいような環境を実現することが、マネージャーの最も大切な仕事である」ということがわかるはずです。そして、マネージャーの仕事が「ドキュメントほか、途中経過の成果物やルールなどを安易に増やすことではない」ということに気が付くと思います。

   それから、マネージャーは何かを「問題視」して文句をいわなくても、プロジェクトや会議は進められるということを理解する必要があります。むしろ180度逆で、（自分の指示によってできあがってきた）成果物を受入れ、その能力を認めることです。

   これは能力の高い人の方には、かえって難しいことかも知れません（ただし、これができないならば、マネジメント能力は高いといえないでしょう）。筆者はもともとプログラマをやりたかったにもかかわらず、コーディングをするとバグだらけとなります。ですから、自分より遙かに少ないバグでコーディングできる人がうらやましいですし、凄いことだと感じています。

   能力の高い人は、「なんでこんな結果なんだ。自分が実作業者だったならば、よりよい結果だったに違いない」と思うでしょうが、そうではありません。「本来伝えるべきことを伝えていなかったのは、自分の方なのではないか」という視点で自分の行ったコミュニケーションを振り返ってみる必要があります。

   「スペックパターン開発プロセス」では、例えばコーディングにあたって「〜をやってはいけない」という校則のようなコーディング規約などを提示するのではなく、実作業者の能力を信じます。

   その上で、「これについては、こう実現してください」という、上流工程を丁寧に行った結果として、そのまま使えるテスト済み・承認済みのバグフリーのソースコードを「モデル・ソース」として実作業者に提示します。「深沢式 会議法・議事録術」や「モデル・ソース」など、「スペックパターン開発プロセス」では、あらかじめ詳細な情報を示さずに「あれはダメ、これはダメ」という様な問題指摘型で業務システム開発を進めるのではなく、先に「手本となりうることをやって見せ、提供する」というのが、考え方の基本です。

   次回、コーディング規約についてと、それに関連して少し「スペックパターン」についてのお話をしたいと思います。
会議でリスクを伝えた際に起こりうること

   会議でせっかく懸念事項（リスク）を伝えても、結果として表2のようなことが起こる場合がしばしばあります。

  • 懸念事項を伝えたことによって、その原因が自分ではないにも関わらず、たいした議論もないままに自分自身の評価が下がってしまうかも知れないと感じること
  • 懸念事項を伝えたところで、誰かの協力を得られることがない、もしくは議論の対象とはならず、面倒くさがられるという実感が残ること
  • 懸念事項を伝えた当人が、たいした議論や根拠もないまま懸念事項への対処をすることになる。もしくは安易に誰か他の者による対処が決定され、懸念事項の存在を伝えた人が迷惑なことをしたようなムードになること
  • マネージャーが檄を飛ばすだけ、ヘタをすればパニックになったり、怒ったりしかねない状況になること
  • 結果として、報告書の作成や追加の作業などが山ほど発生する可能性があるので、自分で何とか対処できそうな限りはギリギリまで懸念事項の存在すら伝えない方が上手くいく可能性が高いと思うこと

表2：会議でリスクを伝えても起こりうること

   懸念事項を伝えたところで、プロジェクト全体の事態が好転するわけではありません。それどころか、個人的に山ほど悪いことが起こる可能性があるような会議の中では、誰ひとりとして高いモチベーションで発言をするわけがないと考えています。

   不安だから懸念事項を伝えようと思っても、伝えたらますます悪いことが起こるという不安があるわけです。この状況では、いくらPMBOKにある通りに会議でリスクを議題としたところで意味がありません。
前のページ  1  2   3  次のページ

イマジンスパーク 深沢 隆司
 著者プロフィール
株式会社イマジンスパーク   深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。
INDEX
第4回：実作業者のモチベーションを考慮した会議
  会議のモチベーション
マネージャーにこそ必要な実作業の体験
  わざわざ実作業者のモチベーションを下げる会議