MSOL社員ブログ

皆さんこんにちは。9月の連休はいかがお過ごしでしょうか？平日を挟んで最大で9連休ということで、どこか旅行に行かれた方も多いのではないでしょうか。

通常どのような仕事でも、休暇予定は他のメンバーと調整して決定し、自分が担当している作業の引継ぎを十分に行ってから休暇に入ると思いますが、大きなプロジェクト等でメンバーが多い場合は、チーム内では調整できてもチーム間やプロジェクト全体で予定を調整するのは困難です。

そのため、例えばプロジェクトで重要な会議があったのに必須のメンバーが休暇で出席できずに作業が進まなかったという事態を引き起こす可能性もあるかもしれません。

以前いたあるプロジェクトでは、そのような事態を避けるために、夏季休暇などの長いお休み用にプロジェクト用の休暇一覧を作成し、事前にプロジェクトメンバーに休暇予定を記入してもらっていました。
PMOにて全員の休暇状況を把握し、特定のメンバーが休みの場合は他にどのメンバーが対応できるのか等を確認していたため、作業が滞るような大きな問題が起こることはありませんでした。

休暇中に電話で呼び出される・・・とまではいかないかもしれませんがお休みを十分に満喫するためにも事前の調整と十分な引継ぎは重要ですね。

ちなみに次に9月に大型連休が出現するのは、2015年らしいです。
毎年毎年あるよりも、たまにある長いお休みだからこそ楽しみも増えるかもしれませんね。

プロジェクトを進めていく上で進捗管理や課題管理、リスク管理は行うのは必須であり、当然ながら、それらを管理する為のツールも必須になります。しかし、実際に利用するプロジェクトメンバーが管理ツールの存在意義を理解していなかったという経験をしたことがあります。

あるプロジェクトで管理ツールを更新しないチームリーダに更新しない理由を聞いたところ、過去に管理ツールが導入された際に利用方法の説明が無かったから、利用していなかったという回答が返ってきました。

説明が無いから利用しないという理屈は間違っていますが、ツールの利用方法等を説明できていなかったのも問題だったので、このチームリーダに活用方法や分析方法を説明したところ、それ以降はしっかり管理ツールを使いこなせるようになりました。

プロジェクトでチームリーダやチームメンバが状況を更新してくれないと嘆くプロジェクトマネージャを見かけることがありますが、ただツールを使えではなく、管理ツールを利用した際の活用方法を説明したか、一度振り返ってみるといいかもしれません。

　PMOとしていくつかのプロジェクトに参画していますが、ここ数年、システム開発方法論構築・活用（各種ツール、標準ドキュメント類等）に力を入れているシステム部門、システム会社が多くなってきたと感じています。実際、弊社は外部PMOとしてプロジェクトに参画しますが、あらかじめ開発方法論であったり、プロジェクト管理ツールや各種指標が用意されていることが多いです。品質向上、効率化、再利用、コスト削減、オフショア開発、マルチベンダー開発などを考えれば、各種方法論であったり標準化の必要性は自ずと導き出されます。また、標準化を推進する部門としてPMOが設置されていることも多いです。

　さて、各社が力を入れいている標準化の効果が出ているかというと、私が見ている限りでは厳しい状況かと思います。原因のひとつとしては、方法論が新規開発（スクラッチ）プロジェクトをモデルとして作成されていたり、自社または国内で設計～開発・テストまで一貫して実施する想定で作成されていることが挙げられます。実際のプロジェクトは、既存システムのエンハンスだったりリプレイスが多かったり、またコスト削減要請から、既存システムをなるべく流用するという方針があり、その中で設計書を流用するケースもあります。既存の設計書を流用するとなると、最新の方法論で定義された成果物とは当てはまらないケースがありますし、QCDや目的を考えると（プロジェクトの優先度がコスト（C）である場合など）、あるべき方法論にあわせることが必ずしも正解とはいえません。また、品質管理指標なども新規開発については充実していますが、既存システム流用などについては用意されていない場合が多いです。あったとしても、既存流用はケースバイケースであるのでなかなかマッチするものはないです。
また、オフショアでの開発やテストを想定していないため、きめ細かなフォローがない状況でもあります。たとえばプロジェクトマネジメント計画書を流用しようとしても、構成管理などオフショアと国内の連携などは定義できていなかったりします（たとえば、オフショアで開発した物件を、日本でどのように管理し、また改修が必要となった場合の受け渡しのやり様など）。また、グローバル企業では、ある拠点で開発したシステムを全世界の拠点へ横展開するなどあります。設計時に考慮するポイントがいくつかありますが、さすがにこの点まで方法論はカバーしていません。

　では、どうすればこのような状況を解決できるかですが、ひとつの考え方としては、方法論のバリエーションを広げるというやり方があるでしょう。ただ、既存システムのエンハンスやリプレイスとなると、置かれている状況も様々ですし、定型化は難しいです。この部分の労力とその効果を考えると現実的ではないといえるでしょう。投資対効果という面では、開発プロセスが新規開発（スクラッチ）とは異なり、導入頻度も高い、パッケージ開発までがバリエーションの対象となるでしょう。

　そこで結局は方法論では全てをカバーできない、限界があるという結論に落ち着くと思います。普通に考えれば当たり前ですが、意外と見えなくなっているのが現状と思っています。というのも、”今後のプロジェクトは全て方法論に則らないと駄目だ”など全社的な号令がかかっているケースがあったりするからです。また、方法論に沿っていれば文句は言われないというプロジェクト側の打算的？な部分もあるかもしれません。あと、プロジェクトを成功に導く方法論というのがあれば、誰もが頼りたくなるのではないでしょうか。

　たしかに、開発プロセス・タスクや成果物の定義は、プロジェクトのQCDに直結しますし、一番難しい部分です。なので、方法論に頼りたくなる部分もありますが（もちろん頼っていいのですが）、目的や意図を考えずに闇雲に従っては、無駄な工数で膨れ上がり、コスト削減を目的としているのに本末転倒となってしまいます。プロジェクトマネジメントにしても、方法論どおりに指標に基づいて、闇雲に集計、報告するのであれば、報告のための報告にしかなりません。

　繰り返しますが、システム開発方法論といっても、完璧ではないということです。この点をきちんとわきまえておく必要があると思っています。つまりは、足りない部分は自ら考えることが大事です。これが忘れがちで、いざ開発を進める中で、不要なタスク・成果物が見つかったり、また方法論にはないが、プロジェクト状況から作成が必要となる成果物が出てきたりします。

　翻って、今、現場のプロジェクトが求めているのは、方法論から必要な部分を抜く、足りない部分を足すというテーラリングのやり方だと思います。ただ、これがなかなかノウハウとしてありません。上述のPMO組織も方法論の作成および展開まではできていても、実プロジェクトでどう使われたか（テーラリングされたか）という一番欲しい生の情報について整理がされていないことが多いです。なので、テーラリングの要諦、勘所といったものが現在、求められれているのではないでしょうか？

　このようなノウハウを収集、蓄積するためには、PMOはできるだけ多くのプロジェクトに関わるのがいいと思います。薄く広くでいいので、各プロジェクトの状況とそれに合わせた方法論のカスタマイズであったり、やり様を確認し、一緒に検討することが大事です。このミッションを持ったPMO担当者は、一度に３つくらいのプロジェクトを掛け持ちで対応するのもいいかもしれません。ひとつのプロジェクトに従事するPMとは異なるPMOの存在意義のひとつかもしれません。できるだけ多くのプロジェクトの生の情報、勘所を持っていれば、PM支援であったり、プロジェクトの成功へ向けての助けが、よりできるようになると思っています。
（弊社も様々なプロジェクトのノウハウがありますので、この点は伸ばしていきたい分野のひとつと個人的には思っています）

　最後に、プロジェクトは変更が付き物ですので、柔軟性を持って取り組む必要があります。方法論に限らず、過度に信じる、頼る姿勢があると、”自分で考えなくなる”、”応用が利かなくなる”というリスク、デメリットが多いにあります。方法論、ベストプラクティス等は必要ですし、一定の効果は出ますが、プロジェクトはひとつとして同じものないという面からすると、”自ら考える”という意識が必要だと思います。現場ではこの意識が足りないという部分もあり、方法論の不備に目が行きがちで、導入・定着化への反発がうまれやすいです。また方法論を展開する側は、テーラリングのやり方だったり、実際に方法論を使った事例、サンプルなど生の情報がフィードバックできていないので、いまいち効果が出ていないのかと感じています。方法論等への向き合い方については、使える部分を使うという意識でいれば、建設的な行動が取れていくと思っています。（もちろん、有効な範囲で定型化、標準化するという意識・目的も併せ持ったうえで）

現在のところPMOはシステム開発系のプロジェクトでその存在価値を発揮していますが、PMOを必要としている現場は中規模以上の開発案件だけではなく、小規模の保守／運用案件においてもその存在意義が認められています。もちろんシステムが稼動するまでの時期が最も非成功リスクの高いフェーズですが、マネジメント視点で見ると、保守／運用業務における各種ルールの策定や、ナレッジの有効活用を促進したり、アクティビティ分析を行うことによって運用コストを削減するなど、稼動後においてもやらなければならないことは多く残っています。このように、プロジェクトのどのようなフェーズにおいても価値を創造し、マネジメントを1歩上のレベルに引き上げることを組織的かつ実践的に行えているのがマネジメントソリューションズの強みではないでしょうか。

個人レベルで「プロジェクトマネジメントが出来ます」「PMOが出来ます」という人は数多くいるし、個々のスキルを前面に出して「PMOサービスを提供しています」というのはある意味簡単なことです。しかし、これまで人依存だったスキルをいったん人から引き剥がし、組織的に行えるようにするために再構築する作業こそが、実は最も困難なことです。

マネジメントソリューションズはPMO市場と共にまだ成長段階ですが、そんな解答の無い問題にチャレンジできる環境にあることが、大きな楽しみの1つですね。