TOP
＞
プロジェクト管理
＞ はじめに
経験が物語る実践型プロジェクト管理
第１回：システム開発のスピードアップをはかる
著者：
イマジンスパーク 深沢 隆司
2006/2/15
1
2
3
次のページ
はじめに
はじめまして、株式会社イマジンスパークの深沢です。本連載では、システム開発をどのように進めていけば成功できるのかを著者の経験に基づいて解説します。システム開発についての有益な理論は多くありますが、うまく実践できなければ机上の空論にとどまってしまいます。そうならないように理論をうまく適所で適用していけるよう、実際に著者が実践してプロジェクトを成功に導いたアイデアを紹介していきます。
本連載をユーザ（顧客）側／開発側のシステム開発関係者の双方に読んでいただければと思います。本連載で伝えたいことは、「
実際にシステムを利用する人たちに少しでも快適に思ってもらえるシステムを提供するにあたり、どうすれば実際にコーディングするプログラマは確実かつ効率的に作業できるか。ユーザが本来必要とするシステムとはいったいなにか
」という課題に対する一案です。
はじめが肝心
システム開発に限らず、どのようなことに対してもいえると思いますが、はじめが肝心です。しかしシステム開発において、初期段階でシステム開発の詳細が明確になっていることはほとんどありません。またシステム開発だけに限らず、詳細を明確にしていくこと自体が難しい作業です。
だからといって、「追い追い明らかにしていけばよい」という気楽なスタンスでプロジェクトにとりかかると、大抵は必要な時期までに詳細を明らかにすることはできません。
そうならないためにも、最初から「少しでも早い時期に、可能な限り詳細まで明らかにする」という気持ちで物事に取り組んでください。いいかえれば、「ガンガン前へ進む」ということです。
「少しでも早い時期に詳細を明らかにしていこう」という考え方でプロジェクトを引っ張っている人がいない場合、過去見てきたプロジェクトすべてが成功していません。
丁寧に行わなければならない実装（コーディング・テストなどの実際のシステムの作り込み）に用意された時間が必要な期間の半分や3分の1ならまだよい方で、ひどいと実装の開始時点で、元々の納期を過ぎているといった場合もあります。このような場合は、どうしても品質の低いシステムとなってしまい、稼働が遅れたあげくにユーザからの評価も低いものとなってしまいます。
そもそも、利用（運用）していくシステムを実装して作り上げるためにプロジェクトが立ち上げられています。きちんとユーザが使用できる設計となったシステムを、実際にきちんと作り上げられるようにシステム開発を進めていかなければなりません。
開発者にとって本当に深刻な問題
システム開発を進めていく中で様々な問題にぶつかることと思いますが、システム開発の関係者が多少の時間を取って話し合い、方向を決めさえすれば済むことがほとんどだと思います。また、そのような問題は深刻な問題ではありません。
開発側にとって本当に深刻な問題は、いったん実装すると決めてしまったことが、現実には実装できないような場合です。要求定義レベルはもちろんのこと、ささいなことでもプロジェクトに様々な問題を引き起こします。
実装できないということは、技術的に実装できないということだけではなく、プロジェクトが赤字になる、スケジュールが間に合わないということも同じです。
実際にはできないことが、一度は実装すると決まってしまうという事は、そもそも決定プロセスに問題があるということです。「様々な問題を引き起こす」という意味がおわかりいただけると思います。
実際にユーザ側の詳細まで調べ上げて、真のニーズを引き出し、それを最適の実装形態で実現するにはそれ相応の時間がかかります。これは、だれでもわかることのはずです。しかし、問題を多く抱えるプロジェクトや常に問題プロジェクトを抱える組織では、本来必要とされる適切な時間や労働力と実際に提供する時間や人員などの資源にアンバランスが生じている場合がほとんどだと思います。
これは、戦場での恐怖感に耐えきれず、敵をしっかりとひきつける前に、攻撃をはじめてしまい、結局は全滅になるパターンとよく似ていると思います。恐怖感と安心感とのバランスの問題です。
多くのプロジェクトで、承認者やマネジメントを行う人が、ある種のパニックや思考停止におちいってしまうことが失敗へ向かう原因となっていると筆者は感じています。「決定」が仕事であると考えてしまいがちになり、時として、内容が確実とはいえないままに決定事項を作って安心しようとしてしまいます。
「最終的に実現すること」が一番大事なことなので、実現できるかどうかを確認なしに決めるということは、そもそも考え方としてずれています。これもパニック、思考停止の一種だと思います。
このような状況に向かわないために、行うべきことは沢山ありますが、まずは役割分担も含め、以下を考慮する必要があります。
実作業者（開発側・ユーザ側双方）は、少しでも早く詳細までつかむこと。そしてその実現方法を考える（実作業者としては、ひきつける事を少しでも早める）。
承認側やマネジメントを行う人（開発側・ユーザ側双方）は、成功を本当に実現したいのであれば、恐怖をこらえて、正確に状況を読み取ること、本来必要とされる適切な時間などのリソースの提供をいかに実現するかをじっくり考える事に意識を集中する（実作業者を信頼する。信頼できるために必要な資源をどうやって提供するかを考える）。
適切なリソースやプロジェクトの進め方を見極めるに当たっては、実作業者に分析や熟慮の為の時間を与え、その判断を尊重する。
表1：承認者やマネジメントを行う人がある種のパニックや思考停止におちいらないために必要なこと
開発側のプロジェクトマネジャーとしては、自分自身がパニックにおちいらないようにするにはどうすべきかを考えます。これは自分の配下の実作業者や上位マネジャー、そしてユーザ側の承認者や上位マネジャーがどうすれば不安（パニック）にならないかを考えることになります。プロジェクトマネジャーや仕様策定者は常にユーザ側と開発側の橋渡し役として、双方を気にかけなければなりません。
プロジェクトマネジャーとして、まずはユーザ側承認者や上位マネジャー、次に自分の上位マネジャーに安心してもらうことが大事です。
自分の言動でできる限り安心感を持ってもらった上で、実作業者に適切な時間と精神的な余裕を与えられる作業環境をいかに実現するかを考えなければなりません。
本来必要な環境を作り上げ、少しでも早く不確定要素の情報を見極めて確定要素に変えられれば、事前に様々な対応策を講じるための時間やコストといった余裕を設けることができます。さらに思いも寄らない事象が発生してしまったとしても、作り出した余裕から何ら問題とならない可能性が非常に高くなってきます。
そして、パニック状態によってユーザ側も含めた開発関係者全体の思考停止状態におちいって、せっかくの皆の知恵や力を無駄にしてしまい、実作業者のみで問題に対処するような窮地をなくしていくことができます。
開発側とユーザ側の視点のズレ
システム開発において、立場の違いによるシステム開発への目線の違いを軽視している場合が多く、管理者の側から大丈夫だと思っていることも、実作業者からすればとんでもないという場合が多くあります。
システム設計が終わったとしても、現場のプログラマにとっては担当するコーディングがとても与えられた期間ではできないという場合があります。こういったことは開発側のマネジャーや仕様策定者の慢心あるいは怠慢が引き起こしたといえ、結果として果たすべき仕事をしていないことになります。もっとも、受注した時点ですでに問題があったかもしれませんが、いずれにしてもそのしわ寄せはもっとも弱い立場の者へ向かうだけです。
では、このような状況におちいらないためにはどうすればよいのでしょうか。まずは、少しでも早く実現したい機能を明確にして、設計を終わらせて実装をする者に試行錯誤の時間を提供するということが1つの答えだと思います。
このような考え方は立場によってどうしてもズレが起こってきます。「それほど今の時点で焦らなくても」と感じる方もいらっしゃるかもしれませんが、こういったことに対してこそ、開発側のマネジャーや仕様策定者が特に上手く話をまとめていかなければなりませんし、なによりも行動で関係者全体を引っ張っていかなければなりません。
開発側のマネジャーと仕様策定者もプロジェクトに対して切実感を持ち、経験の豊富な実装担当者を1人は必ずプロジェクトの最初から投入するといった様々な準備を実現できれば、立場によるズレのほとんどを是正できます。また、どうしてもユーザ側の協力が必要となる部分については、明確に根拠を提示した上で対処していくことが必要でしょう。
1
2
3
次のページ
著者プロフィール
株式会社イマジンスパーク 深沢 隆司
株式会社 イマジンスパーク 代表取締役
陸上自衛隊少年工科学校第25期生。対空戦闘指揮装置の修理要員として自衛隊に勤務。退職後に一部上場企業や官庁でのシステム開発等で仕様策定、プロジェクトマネジメントに従事し、独自の手法で成功に導く。著書は『SEの教科書』他。
INDEX
第1回：システム開発のスピードアップをはかる
はじめに
明確にしていくこと
理念を行動に移すには
