プロジェクトマネジメントをはじめる前に大切なこと
大橋力丈氏：『プロジェクトマネジメントをはじめる前に大切なこと』ということで、クラスメソッド株式会社の大橋がお話しいたします。よろしくお願いします。
2月からリモートワークで、家族には、今日は登壇するので静かにしといてねって話したんですけど、1点だけ、どうしてもこのワンコがマネジメントできなくて。もし吠えたらごめんなさいということで、先に謝っておきます。
簡単に自己紹介になります。私、大橋力丈と言います。クラスメソッド株式会社のCX事業本部で部長をしてます。経歴はもともとJavaとかサーバーサイドのエンジニアをやっていて、プロジェクトリーダーも兼任し始めた10年前からクラスメソッドにジョインしました。
クラスメソッドに入ってからはプロジェクトリーダーのほうにシフトしていって、その中でプロジェクトマネージャーや、最近では営業とかプリセールスとか、組織のマネジメントなどいろいろやってます。
趣味はいろいろありまして。今ちょっと非常事態宣言の関係でサウナに行けないのが非常に悲しいんですけれども。サウナが一番好きです。
会社紹介です。クラスメソッドはオープンな発想と高い技術力で、すべての人々の創造活動に貢献し続けるという経営理念でやっています。
基本的にベースはAWSが大きいんですけれども、AWS総合支援のMembersというサービスを提供しています。CX事業本部では、この中でモバイルアプリケーション開発、Webアプリケーション開発、IoTのアプリ、裏側はAWSのサーバーレスを使ったり、DevOps支援をしたりなど、そういったところをAWSを利用し、上物のアプリケーションを使ってお客様にプロダクトを届けることを仕事にしています。
クラスメソッドCX事業本部のビジョン、ミッション、バリューというのを定義しています。ビジョンは、プロダクトを通じて人々をハッピーにする。ミッションは、最高の「顧客体験」を創り上げる。バリューは、プロダクトが提供したい価値を常に考え仕事をする。
そしてチームでやることが多いので、チームメンバーを尊重して仕事しましょうと。事業会社さんとかクライアントさんは僕らに技術の専門性をもって期待してくれているので、その専門性を使って、さらに僕らも提案し続けて、よりよいプロダクトを作っていきましょうということをビジョン、ミッション、バリューにしています。
プロジェクト開始前の流れ
今日の資料の前提なんですけども、全部が全部みなさんに当てはまるわけではないと思ってます。
この資料の中では、プロジェクト開始前の準備段階にけっこう重点をおいている資料になります。あとはクライアントさんと一緒にプロジェクトを進めていて、さらにそのクライアントさんとワンチームとしてやっていることが多かったりもします。
新規事業系の開発ってやっぱり不確実性が高いので、そういう中でどういうふうに進めていくのがいいかとか。あと比較的少人数の開発でやってたりするので、そういった前提があることを知っておいてもらえればなと思っています。
僕はシステム開発の経験が20年くらいあるんですけれども、特定のプロジェクトの話ではなく、経験の中でいろいろ総合して30分にまとめた話です。結果的に銀の弾丸のような、これをやれば絶対成功だ、みたいな話は出てきませんが、実直にやっていくと確実に変わっていくというのもあります。
今日のアジェンダは、プロジェクト開始前とプロジェクト開始後の2つです。受注してから立ち上がるとき、立ち上がってからどうしていくかの2つに絞ってお話しします。
プロジェクト開始前の話ですが、基本的に受注までの流れに、問い合わせがあります。このときに案件概要とかどんな利用技術とかこういうことをやりたいみたいなのが、ある程度情報が来るんですけれども、打ち合わせ前に事前情報をヒアリングしたりすることが多いかなと思っています。
で、実際に打ち合わせをする。このときにプロジェクトの概要を確認して、その中で実現したい世界であるとか、その実現したい世界に足りてない解決したい課題とか、その中で期間とか予算とかっていうのもあったりすると思います。
これらを踏まえて、僕ら開発会社は提案をします。実現方法、具体的にこういう技術を使ってこういう機能を使ってやっていきましょうとか。開発チームはこういう体制で組むのでだいたいこのくらいの予算がかかります、みたいな話をすり合わせていくことが多いかなと思ってます。これは開発とか政策とかいろいろあるとは思うんですけれども、基本的にこの流れというのはあるかなと。
RFPがすべて完璧っていうことはあり得ない
その中でけっこう重要になるのがRFPと言われるものですね。私の持論としてはプロジェクトは開始前が非常に重要だと思っています。この時点でクライアントさんとか、これから作るプロダクトでユーザーに届ける価値に共感できるかは、かなり重要かなと思っております。
まずRFPとは。Request for Proposal、提案依頼書ですね。これはベンダー各社にシステムの導入とか業務委託を提案とか依頼をするために要件とかを明確に記載した書類などが多いです。
RFPで提示される情報というのは、そんなに明確にこれとこれとこれっていう、すべてきれいなフォーマットはありません。だいたいがプロジェクトの目的とか、この背景があってこの目的があるとか、達成したい目標はこういうことですと。あとそれに必要な機能要件とか非機能要件とか、想定予算とかスケジュールというのが書かれているところもあります。
この提案依頼書に則っていかなければならないっていう思い込みがあると思うんですけれども、それはけっこう間違いです。RFPは完璧で要求どおりに提案する必要があるかというと、僕は違うと思ってます。
そもそもこれから不確実性の高いプロジェクトにおいて、RFPがすべて完璧っていうことはあり得ないので。RFPっていうのはあくまで参考情報として考えて、それらを踏まえて自社なりの提案をしていく必要があります。
その中でRFPに書かれているものもありますし、ないものもあったりします。プロジェクトで解決したい課題が必ずあるので、それは何なのか考えて、そこにフォーカスして提案していくことが重要かなと思っています。
できないことは正直に伝え、代替案を考える
As-IsとTo-Beという話なんですけれども。もともときっちり整理されたRFPであるとか、企画書やシステム検討書とかは、ペライチだったりとかもしますし、手書きのイメージのときもあると思います。
必ずその背景には解決したい課題があって、あるべき姿と現状というところで言うと、To-Beのところは資料とか打ち合わせでよく出てきますし、達成したい目的や目標が書いてあったりします。逆にこれをシステムでやらなくてもいいよねっていうのも、実はあります。
現状で言うと、To-Beのみでここが漏れてることが多いんですね。実はこの部分が非常に重要で、現状こういうところで困っているとか、現状ここが課題なのでこうなっていきたいみたいな部分を把握していないと、始まったときや受注時にブレることがあるので、このギャップを埋めていく必要があります。
これらを踏まえてRFPを参考にとか、打ち合わせで参考した情報、既存のシステムの情報とかを総合してしっかり判断して、じゃあこういうかたちで今のものをこうしていきたいとか、新しいものを導入したいといったところを踏まえて提案していきます。
ただ要求に対してすべて答えられるわけではないと思っています。とくにRFPなんかはけっこう全網羅されて書かれているので、それに対してすべて応えられるかと言えば無理だと思うんですね。もちろんできる会社さんもあると思いますけど、得意な領域、不得意な領域とかもあるので。
これはあくまで例ですけども、例えば企画、デザイン、マネジメント、技術、ドキュメント、ビジネスみたいなものを要求の中にいくつか求められているとします。赤いところが要求の点数、青いところは自社として、ここがちょっと要求に対して足りてない、ここは余裕で足りてる、みたいなのを踏まえたときに、必ずギャップが出てきます。
このギャップに対して無理して提案するかと言うと、そうではありません。じゃあどうしていきましょうという話なんですけども。
ここは正直に話をするのが一番の解ですね。取り繕ってもなんにも正解はないので。できること、できないことをしっかり伝えます。無理をしてプロジェクト開始してしまうと後々大変になります。炎上するパターンもあるでしょうし。そこで無理して取ってもしょうがないかなと思ってます。
ただしできないことをそのまま「できません」と伝えても、全然お客さんのためになりません。僕らはできないことの代替案を考えて、それを伝えて、それに対してすり合わせをするというかたちで進めています。
できないことは弱音で伝えるのではなくて本音でしっかり話す
あくまで参考の一部ですが、例えば技術的な話とかで課題のツールとかソースコードはGitHubで管理、課題はBacklogで管理みたいな話を定義して、実はこれが使えないとかあったときは、けっこう生産性が下がったりもするので、こういったところをしっかりすり合わせたりだとか。
一部の機能に関しては技術的に調査が必要なので、見積もりも難しいということを正直に言って、こういうかたちでプロト作りながら、その中で実現可能性を含めて試して開発を進めさせてくださいとか。
成果物で言うと、けっこうRFPとかの場合はごっつく書いてあったりもするんですけども、実は相談するとそんなことはなくて、そのフォーマットとか粒度で本当にドキュメントは必要ですか？ とか。Wikiとかでまず書きやすいかたちにして必要最小限のドキュメントにしませんか？ って言うと意外と「そうですね」というかたちで乗ってくれたりもします。
データの納品はCD-ROMなど、けっこうかっちり書かれてたりするんですけれども、これもデータでいいですか？ みたいな話をすると、けっこう相談に乗ってくれて「大丈夫です」みたいなこともあります。RFPそのものを提案するというよりは、お互いの実際のギャップ、強みと要求に対しての弱みのギャップを見せて、ちゃんとそれぞれ伝えていく必要があります。
例えば体制とかですね。お客さん側、クライアントさん側の体制として、プロジェクトにどのくらい関われるかというのはけっこう重要になってきます。実務が忙しくてほとんどプロジェクトに関われない場合は、なかなか進まなかったりもするので、そのプロジェクトにガッツリ参加してほしいので週何時間確保してくださいとか、フルで参加してくださいみたいなところは必要かなと思ってます。
なので、できないことは弱音で伝えるのではなくて、本音でしっかり話すというところが最初の段階で必要ですね。
こういうときはお断りしていましたという例では、やっぱり自社文化にあったツールを利用できない場合。……まあ似てるものは可能だとして。例えば課題管理でBacklog、システム構成図はCacoo使いますとか。まあほかにもいろいろ使います、みたいなところがあったとして。
ツールだけが文化ではないんですけど、文化とツールってけっこう表裏一体なものがあって、エンジニアの体に合ったツールを使わないと開発スピードがかなり変わります。
ここで開発ツールとして制約があって、やりたいこととかもいろいろ合ってきたんですけど、ちょっとそもそも無理だなっていうときは、過去けっこうお断りしたこともありました。
