技術全体を見るCTOの視点、ビジネス全体を見るプロジェクトマネージャーの視点、その両方で世の中のトレンド、ニュースを見る

ゆめみのプロジェクトマネージャーってなんだろう

»

前回は、ゆめみのCTOという役職の役割や立場について説明をいたしました。今回は私がCTOになる前までやっていました、プロジェクトマネージャーという仕事について、ゆめみではこんな風にやっているんですよ、というのをお伝えしたいと思います。私は「ゆめみらしさ」の源泉はプロジェクトマネジメントにあると思っております。

ところで、このブログのタイトル「CTOとプロマネの立体視」は、CTOとプロジェクトマネージャーの2つの視点で物事を見よう、という意味でつけたものです。ざっくりと言うと、CTOは未来を描く仕事、プロジェクトマネージャーは今を進める仕事です。今後も色々なネタについて、「未来」「現在」の切り口で書いていこうと思いますが、そのベースとなっている視座を前回と今回の2回でご説明する形となります。最後に、CTOとプロジェクトマネージャーの関係について触れたいと思います。

1. ゆめみにおける「プロジェクト」とは

そもそも「プロジェクト」とは、「何らかの目的を達成するための計画」を指します。(Wikipediaを参考に引こうと思ったら「なんでロシア語の説明がそんなに詳しいんだよ」という本題に関係ないツッコミが止まらなかったのでリンクのみ置きます。)

まずは、「何らかの目的」というところを明確化する必要があります。ゆめみでは、基本的にはシステムの受託開発のプロジェクトが多いので、お客様の要望ややりたいことを聞いて、どのようなものを作るかを決めます。ゆめみでは、言われたものを言われたとおりに作るだけという開発プロジェクトは少なく、企画や提案の部分も含むことが多いです。

この段階はコンサルティングと言っていいと思います。お客様の問題意識を掘り下げ、本当に困っていること、本当にやりたいことを見極めて、必要なら調査なども実施した上で、企画・提案を作成します。

そうすると、進め方としては「プロジェクト」そのものを2段重ねにする形になります。

  • 「目的を決める」ことが目的のプロジェクト
  • 「決めた目的を実現する」ことが目的のプロジェクト

この進め方は、ゆめみのやり方、ゆめみらしさの一つだと思います。いわゆるITコンサルタントは、前者に特化して、その実現については責任を負いません。いわゆるシステムベンダーは、後者に特化して、作るものが本当の目的に沿っているかは考えません。ゆめみは、この両方を責任を持って実行する、そこに意味や価値があると考えています。

しかし、ただプロジェクトを2段重ねにすると、その分開発の時間がかかってしまう事になります。そこで、ゆめみではスローガンとして「Quality and Agility」を掲げ、機動的に動くことを全体の意識として持つようにしています。

2. プロジェクトマネージャーのお仕事

プロジェクトマネージャーの仕事は、一言で言うと「プロジェクトを遂行する」ことです。プロジェクトの遂行というのは、大きく3つのフェーズがありまして、「プロジェクトを開始する」「プロジェクトを推進する」「プロジェクトを終了する」という3段階です。

一般的なプロジェクトの進め方はいくらでも記事や標準(PMBOKなど)があるので、ゆめみの進め方として、私が特に意識していることを書いていきたいと思います。

プロジェクトを開始する

プロジェクトの目的を達成するにあたって、「確かに目的を達成したね」と認定する人・組織を決めることが重要です。それが特定の人であれば、その人はプロジェクトオーナーと呼ばれます。プロジェクトの最も大事なステップは、このプロジェクトオーナーを決めることです。

受託開発ではプロジェクトオーナーは基本的にはお客様側の責任者です。プロジェクトオーナーに求められるものは、プロジェクトを何があっても成功させたいという強い思いです。「上から言われて」や「下から担ぎあげられて」というのは、うまくいかないプロジェクトの典型です。

正直なところ、プロジェクトにはトラブルがつきものです。計画通りに進むことなど稀です。ただし、計画から外れたからといって、即プロジェクトの失敗ではありません。

そういった時に、成功させたいという思いを強く持っていることが大事なのです。本当の目的に立ち返って、プロジェクトの進め方やゴールを見直し、最終的にいい物を作ろうという前向きな思いでリスタートする。プロジェクトを成功に導くにはこれしかありません。これは、強い思いがなければ出来ません。

自分の意思がない場合、「怒られないためには」という極めてネガティブなリスタートになります。責任にこだわること、それ自体は非常に大事です。ただ、「誰かが責任を取る」ことがプロジェクトの目的ではありません。

これを、受託する側である我々が言うと責任逃れのようにみえるかもしれません。もちろん、そういうことが言いたいのではありません。プロジェクトにおいて計画から外れることの責任は第一義的にはプロジェクトマネージャーにあります。

しかし、お客様に価値を提供することがゆめみの目標とするところですから、まず第一に提供する価値を最大化することを考えます。責任についてのお話をするのは、その後です。

もし、強い思いを持っている方が責任を持てる立場でないのであれば、強い思いを持っている方をプロジェクトオーナーとし、責任者にその方を支えて頂くという形が、最終的に最も大きな価値を生むと信じています。プロジェクトマネージャーは、このプロジェクトオーナーの思いを実現するためにあらゆることを行います。

プロジェクトを推進する

目的を実現するためにはリソース、いわゆるヒト・モノ・カネが必要になります。これを適切に調達、配置し、動かしていくのがこの段階の仕事です。タスクを小分けにし、作業者や必要な資材を割り当て、予定通りに進んでいるかを確認し、計画とのズレがあれば調整する、というPDCAを回します。

この段階では、実際にモノを作るエンジニアが主役になります。プロジェクトマネージャーとして重要なのは、エンジニアとの信頼関係です。信頼関係が強ければ、情報の共有がより早くなります。

何かトラブルがあった時も、信頼関係がなければ、「こんなことを言うと怒られるかも」と思ってしまい、報告が来るのはどうにもならなくなってからです。ひどい時は報告もなく隠蔽されることだって、あり得ない話ではありません。エンジニアが「この人に相談すればなんとかしてくれる」と思っていれば、どうにもならなくなる前に、さらにはトラブルが起きる前の段階で情報を共有してもらえます。

ゆめみは、プロジェクトマネージャーとエンジニアの間の距離が非常に近い組織です。技術的な部分で相互の能力を信頼出来るのはもちろんのこと、日常的に雑談やジョークを交わし、話をしやすい環境を作ることが非常に重要です。黙々と作業をする時間も必要ですが、わいわいと話をする時間も同じくらい大切だと思っています。これが、最終的には品質を上げることにつながります。

そして、ゆめみのプロジェクトマネージャーには「バッド・ニュース・ファースト」の原則が叩きこまれています。トラブルやその徴候があれば、すぐに報告し、対応をしっかりと検討しよう、というのが基本姿勢となっております。この情報は経営層と全てのプロジェクトマネージャーに共有されます。すぐに情報が集まる信頼関係、情報を共有し相談する体制、これがゆめみの品質を支えています。

プロジェクトを終了する

適切に開始し、適切に推進されたプロジェクトの場合、プロジェクトの終了でやることは「目的を達成したね」という一言をプロジェクトオーナーからもらうのみです。

ただ、これを無事に聞くためには、「何をやったら目的達成といえるのか」「目的は本当に達成されているのか」が客観的に分かる形になっていることが必要です。

そのためには、目的を当初の段階で可能な限り具体的に(客観的に達成・未達成が判断出来る基準で)決める必要があります。これをしっかり決められるかどうかは、プロジェクトマネージャーの手腕によります。明確な目的が決まっていれば、プロジェクトオーナーもお客様の社内での説明がしやすくなり、満足度も高まります。

プロジェクトが終了したら

ゆめみでは、プロジェクトが終了したら振り返り会を行うことを基本ルールとしています。社内、もしくはお客様も含めて、今後の改善のためにお互いに遠慮せずに話をする機会を作ります。最近は「KPT法」で行うことが増えています。「KPT法」とはKeep: 継続して行うべき良かったこと、Problem: 直すべき悪かったこと、Try: 次回から挑戦すること、の3つに分けて意見を出しあう方法です。

まずはみんなで良かった点を出しあい、次に悪かった点を反省する。この順序が重要で、悪かった点を言いやすくするためには、良かった点を言っておくのが非常に重要です。

この振り返り会は、ゆめみとして開発品質を上げていく上で重要な役割を持っています。

3. CTOとプロジェクトマネージャー

CTOは、技術面で競争優位性を確保するための施策を決定する立場です。施策自体を決定するという意味では、プロジェクトオーナーです。CTOはプロジェクトオーナーとして、なんとしてもこれを実現したいんだという強い思いを持って未来を考え、施策を作ります。

実際に施策を推進するプロジェクトマネージャーはプロジェクトオーナーの思いを受け止めつつ、現実的に施策を実行していくことになります。

ゆめみでは「技術推進委員会」という組織体で技術経営を行っていますので、必ずしもCTOがプロジェクトマネージャーでなければいけないということはありません。ただ、今年はプロジェクトマネージャーをしてきた私がCTOをやっている訳で、価値を最大化するために、自ら施策を実現していきたいと思っております。

これで、このブログの前提となる2つの視線についてご説明ができたかと思います。次回からは、未来への思いや、未来的なニュースなど、ざっくばらんにお話が出来ればと思います!

Comment(0)

コメント

コメントを投稿する