プロダクトを成功に導くための発注者の責務
今日はプロダクト開発における発注者について私の考えをまとめていこうと思います。
発注者って誰？
まず、この記事で指す"発注者"と言う言葉について定義しておきます。
一番意図している人としては"プロダクト開発におけるステークホルダー(組織)の現場担当者"といったところでしょうか。 つまり、下記のような人ではありません。
- 発注作業の事務的な手続きを行う担当者
- お財布を握っているステークホルダー(組織)の偉い人
- 依頼があり、開発を行うチームとそのPM
また、発注という言葉も定義しておきます。
プロダクト開発の手段として「社内開発」「外注開発」と二つあると思います。 もちろん細かく分けると「SESで自社に来て貰う」とか「パートナー企業と協業で」などありますが、大別すると上記2種類かなと思ってます。
この記事で指す"発注"とは上記どちらにおいても発生していると思っています。
具体的には
「"新しいサービスを立ち上げたい人"が"開発を担当する人(チーム)"に開発を依頼(一緒に行う場合も含む)を行う行為」
と定義したいと思います。
この記事を書く理由
というわけで内容に入っていこうと思いますが、 そもそも、"なぜこの記事を書くのか"についてお話ししておこうと思います。
私はサービス会社のエンジニア組織に所属しています。
私の所属する企業では"現場"と呼ばれるオペレーションを担当している部署や"営業"と呼ばれるセールスとマーケティングを行なっている部署があらゆるドメイン知識を持って日々のBtoBサービスの提供を行なっています。
そこに"技術"と呼ばれる区分の3つに大別され、"技術"という区分には"メンテナンス"、"基幹のインフラやIT整備"、"社内外向けサービス開発"の3種類の部署が存在します。
私が所属するのは"社内外向けサービス開発"を担当する部署で10名超が属しています。 主な業務としてはプロダクトの要件定義、開発、運用保守を行なっており、現在は40程度のプロダクトがアクティブな状態です。
これらの開発はリソースやサービスの性質、スケジュールに応じて"内製"と"外注"を選択しています。
私のポジションは主にプロダクトマネージメント、プロジェクトマネージメント、インフラ、セールスエンジニアを各プロダクトで担当しています。
内製の場合は複数人の開発者でチームを組成します。
一方で、外注の場合は開発の部署としてはほぼ一人で動きます。
エンジニア1名 + ドメイン知識を持つ非エンジニア(現場や営業)複数名 でプロジェクトを組成し、プロジェクトを開始します。
その過程の中で成功するプロジェクトと失敗するプロジェクトに、ある一定の"発注者が押さえないといけないステップ"が見えて来ました。 もちろん、弊社だけの理由であったり、私の考えが甘いことも多くあるのでお手柔らかに読んで欲しいものですが、自分の備忘録と一つの仮説という意味でまとめます。
また、その背景にあるものとして、"いくら優秀なエンジニアやPMがいても発注者次第でプロジェクトは失敗する"とも感じています。
プロジェクトの始めにやるべきこと
まずはプロジェクトの立ち上げに関してです。
プロジェクト立ち上げのきっかけは「自らの企画が通る」パターンや「指名を受けてプロジェクトメンバーになる」といった方法があると思います。 そして、自分以外のプロジェクトメンバーに関しても「自ら指名する」「すでに決まっている」というパターンがあると思います。
どちらにしろ、発注サイドのプロジェクトメンバーは少なくともこのような条件が必要だと思っています。
- 現状のフローを熟知している
- 解決したい課題を認識している
- プロジェクトに当てる時間を捻出できる
これら全ての条件を備えている人がいれば、申し分ないと思いますが、プロジェクトのスタート時は"個々人がどれか1つ以上の要素を満たしている"という状況で良いと思っています。そして、"プロジェクトメンバー全員が集まると上記3要素を満たしている"という状態になっていれば、プロジェクトメンバーの選定は成功だと私は思います。
よく
- プロジェクトに前向きで、やる気がある人
- コミュニケーション能力に長けている人
といった条件がマストと言われていたりもしますが、私はそうは思いません。
というか、全員がこれを満たすのは無理な場合がほとんどだと思います。
そもそも、ドメイン知識が豊富な人は忙しいものです。そんな状態でよくわからないプロジェクトにアサインされたら、最初はやる気が起きないのも当然だと思います。 さらに、現状の課題が「属人化、ブラックボックス化」というのもよく聞きます。 正直、積極的でコミュニケーション能力が高い人だったら、プロジェクト化する前にそんな状態を解決していることもあるのでは？と思ってしまいます。
一方で、「全然参加できない、コミュニケーションが取れない人とプロジェクトを進めてもうまくいくわけないじゃないか」と思うかもしれません。
その通りです。 あくまで、"プロジェクト開始時は"この状態で良いと思っています。
つまり、プロジェクトを進めていく中でこのような状態を変えていくことが必要です。
なので私は始めに「チームビルディング」と「プロジェクトの方向性を整える」ということをやります。
ただの人の群れをチームにする
チームビルディングでは「どんな価値観を持っているのか」「メンバーに対してどんな期待をしているのか」を可視化することにフォーカスします。
具体的には 「価値観ババ抜き」でチームメンバーの価値観を可視化します。
※ 価値観ババ抜きについては過去記事にて。 passionate-po.hatenablog.com
それぞれがどんな価値観を持っているかが見えてくると初めて一緒に仕事をする相手でも"目の前に座っている人がどんな人なのか"が少し見えてきます。
その後は「ドラッガー風エクササイズ」を行います。
※ ドラッガー風エクササイズについてはギルドワークス中村洋さんの記事を引用させていただきます。
チームメンバーの期待をあわせる「ドラッカー風エクササイズ」 | DevTab - 成長しつづけるデベロッパーのための情報タブロイド
これでプロジェクトにおけるお互いの期待をすり合わせます。 この2つのワークについては必ずどんな手を使ってでもチームメンバー全員に参加してもらいます。
ここに参加しないひとが出ると文化祭や体育祭に欠席した学生のように共通の経験がなくなり、その後のプロジェクトに大きな悪影響を及ぼします。
不思議なもので、上記2つのワークはしばらく経っても随所でプロジェクトメンバーの話題に上がります。そのため、それについていけないと仲間外れ感からプロジェクトに対するモチベーションが落ちるだけでなく、周りのメンバーもその人が何を考えているのかさっぱりわからなくなってしまい、孤立していきます。
そのプロジェクトは何者かを考える
次にプロジェクトそのものを紐解きます。というより、この段階では「なんとなくこれがあった方がいいからプロジェクト化したよ」みたいな状態の場合もあるので、プロジェクトの存在意義をチームで固めていきます。
これももちろん全員で行います。
具体的には「インセプションデッキ」を作ります。
※ インセプションデッキについては過去記事にて
インセプションデッキの中では特に
- 我々はなぜここにいるのか
- エレベーターピッチ
- やらないことリスト
- 夜も眠れない問題
を重視します。 プロジェクトメンバーとして集まった個々人がプロジェクトへのアサインを受けた時点で少なくとも自分なりの方向性やあるべき姿を考えます。 ただそれは必ずと言っていいほどズレています。
にも関わらず「みんな同じことを思っているはずだ」と考えていることが多いです。 そのため、方向性を揃えるためにも必ずこれをやることをお勧めします。騙されたと思ってやってみてください。
そのあとはエンジニアと非エンジニアでタスクを分けることが多いです。
非エンジニアチームには現状のフローをフローチャートにまとめてもらいます。 この時の基準は「(ドメイン知識のない)新入社員がこの仕事を理解するために必要なレベルで」というイメージです。 これが後の開発チームの業務理解につながる重要な資料になります。
そしてエンジニア(主に私一人ですが)はRFPを書きます。 機能要件については足繁く現場に通い、キーパーソンに聞きながら書きます。 そして一番重要なのが"その作業を実際に見せてもらう"ことです。
これがかなり重要です。
というのも、実際のオペレーターは当たり前になってしまっている作業もフラットな目線で見ると「なぜ？」という点が多くあります。 そこをとにかく拾い、質問をし、そうしなくてはいけない理由を明確にします。
これにより、現状のフローの課題の解決手段とフロー改善における制約をリストアップできます。
これをもとに機能要件をまとめます。 機能要件がまとまったらチームでレビューをします。
ここは時間がかかります。なぜなら、現場のオペレーターはフローがガラッと変わることに対する想像力が必要になるからです。 そのため、確認フェーズでは図や表を使ってあらゆる手段でイメージを伝えます。
そして並行して非機能要件(性能要件含む)、セキュリティー要件、運用保守要件、プロジェクト管理要件など残りの部分をまとめます。
これらはどちらかというと技術的な側面を中心に進めるので、スラスラと書けると思います。
例えば、開発言語やフレームワークの指定やセキュリティー要件は組織のルールや自分なりの閾値があるのでスラスラ書けます。 プロジェクトの進め方、会議体、ツールの指定なども同様でしょう。
とにかく細かく書きます。そしてその要件がどのくらいマストなのかも書きます。 よく使う言葉としては
- 〇〇とすること。
- 〇〇だと望ましい。
- 〇〇について提案を求む。
などを使ったりしています。
RFPが完成したあとは、いよいよ開発チーム候補の選定です。
まずは内製か外注かですが、これは
- リソース状況
- スケジュール
- スキル
などの状況で判断します。内製となればあとは開発チームを組成し、実際の開発に入っていきますが、この部分は多く語られているので、今回は割愛します。
外注の選定基準についても上記と同様ですが、それに加え、
- 自身が一緒に仕事をしたい人、会社
- 開発手法や技術レベル
という側面でいくつか知り合いの方々に当たったり、周りの人に聞いて紹介してもらったりしてます。
だいたい3~4社くらいに絞り、お声がけさせていただきます。
プロジェクトのビジョンを伝える
さて、お声がけさせていただいた開発チーム候補には
を行います。
RFPのみを配って説明をするパターンが多いと思いますが、私はそれだけでは不十分だと思います。 そもそも「外注先なので、細かいビジネスについて共有する必要はない。下請けだ！」と思っている方がいたら、私は全力で反対します。
なぜなら、自社のビジネスを一緒に作るパートナーとなってもらうチームです。 そのため、「どういうビジネスなのか。サービスなのか」、「どういう業界なのか」を理解した上で開発を進めていく必要があります。
そして、開発パートナーとなるチームにも期待したいこととして、
- ビジネスやサービスの成長を意識した提案
- 時にはこちらからの機能要件にも疑問をぶつけてもらう
といったことをお願いします。そして、それができることも選定の基準とさせてもらっています。
開発チームの選定
いよいよもって、提案をいただく流れになります。 提案については公平を期すため、提出期限、提案時間は同じにしています。
そして、選定方法は定量的な方法で行なっています。
具体的には比較表を作ります。 比較表では
- RFPに記載した各項目を1行ごとに記載
- 各項目に重みをつける
- 各社の提案に対しての評価を行う(3点：要望を超える提案、2点：要件通りの提案、1点：要件を一部実現する提案、0点：要件を全く満たしていない提案)
- 各評価に重みを掛け合わせる
- 総合点で比較
という手順で評価を行います。 これをもって開発パートナーとなるチームを選定します。
偉い人に納得してお財布を開いてもらうための責務
さて、プロジェクトチームで一緒に働きたい開発パートナーを選定したら、お財布や稟議のお話です。 お財布を握る偉いひとは「このプロジェクトがうまくいくのか」を心配しています。
その心配を安心に変えることもプロジェクトメンバーの責務です。 実は、そのための材料はこの時点で揃っているのです。
私はここまでに用意したアウトプットとして
を提出します。
そして、そのサマリーの説明をすることで、発注根拠を説明します。 こうして、公平な基準で根拠をもって選定したことを理解してもらい、気持ちよく発注をしてもらいます。
これにて、開発プロジェクトはスタートラインに立ちました。 いよいよスタートです。
開発のキックオフ
さて、開発パートナーも決まり、開発プロジェクトのスタートです。 まずはキックオフですが、私はここで主に下記を行います。
- 発注側のメンバーと役割の紹介
- 開発側のメンバーと役割の紹介
- プロジェクトビジョンの確認
- スケジュールと進め方の擦り合わせ
表向きはこんな感じです。 そして、できればこのキックオフを夕方めに設定します。 その理由は御察しの通り、そのまま懇親会に突入させるためです。
これが実はかなり重要です。
初めて一緒に仕事をする相手に対してこれからお互いがオブラートに包まず、本心を言い合わなくてはなりません。 そのためには心理的な距離感を縮めることが必要です。
これは現時点の私の解なので最適解が他にあるかもしれませんが、 まずは全員で飲みに行きます。
そして、雑談をし、お互いのバックボーンを知り、距離感を縮めつつ、尊敬の念を持てるようにします。
とにかくフランクに、とにかく仲良くなることを重視します。 お互い楽しく仕事をし、良いプロダクトを作るために"チームとプロダクトに愛着と期待"を感じてもらいます。
開発サイクルの管理
さて、無事にキックオフができたら、いよいよ開発です。 開発中の具体的なプラクティスや方法論はたくさん出回っており、かつもっと詳しい方も多いので、今回は割愛したいと思います。 いずれ私の考えも記事にしていこうと思います。
ただ、私の立ち居振る舞いとしては
- 開発PMと同じレベルで仕様を理解する
- 要件定義に思いっきり口出しをする。時にアドバイスをする
- 全てのやりとりを把握する
といったことを徹底します。
「あくまで発注者だから開発チームに全部任せないと内政を変わらない。外注する意味がないじゃないか。」という声があるかもしれません。
ただ、やはり自分たちのサービス、プロダクトへの責任を持つということ、また緊急時の対応判断を即座にできることを考えると私はこのスタイルが必要だと考えています。
プロジェクトの終了
プロジェクトも終盤、クロージングについてです。 そのタイミングでは運用開始を想定する必要があります。
具体的には
- ユーザー教育
- 拡販
- 広報
- 運用保守
などを検討する必要があります。 この時にプロジェクトメンバーにお願いすることがあります。 それは
「プロジェクトメンバー以外のユーザーがプロダクトにポジティブな印象を持つように接すること」
です。プロジェクトメンバー以外のユーザーは「新しいやり方だ自分の仕事の仕方を変えようとしている。めんどくさい。」 という印象から始まることが多いです。
そんなユーザーをプロダクトのファンにするのもプロジェクトメンバーの仕事です。 そのため、いかにポジティブな印象を持ってもらい、利用を促進するかがポイントになります。
次のフェーズに向けての準備
そしてプロジェクトが終了。チームも解散になります。 その前には必ず、「ふりかえり」をすることにしています。
これは、「プロダクトの今後の成長」「プロジェクトメンバーの成長」の2つの側面で非常に重要です。
プロダクトについては、次のフェーズに進むために一歩立ち止まって、改めてプロジェクトを俯瞰してみることで学びを得ることを目的にします。
プロジェクトメンバーについては、このプロジェクトにおける進め方、自分の立ち居振る舞いからの学びや次のプロジェクト、働き方についての気づきを持ってもらえると成功だと考えます。 そしてそれらをできるだけポジティブな形で終えること。それが開発プロジェクトに不慣れな現場や営業のプロジェクトメンバーの自信とプロダクトへの愛情へと変わります。
と、ここまでで「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」が揃っていることが私なりのプロジェクトの成功だと感じています。
まとめ
というわけで少々長くなってしまいましたが、私の思う発注者の責務を書いてきました。 改めてまとめると
- プロジェクトメンバーがお互いの価値観と自分への期待を知り、チームとなること
- プロジェクトの方向性、ビジョンを全員が共有すること
- 開発パートナーは下請けではない。未来を共に創るチームの一員と理解すること
- 細かいところまで定義する。ビジョンやビジネスも共有する
- 心理的距離を縮める。本音を言い合える仲になる
- プロジェクトメンバー以外にも自信を持ってプロダクトを伝える
- 「みんなの期待に応えるプロダクト」と「プロジェクトから学びを得て成長したメンバー」をゴールとする
といった点を私は重視しています。
「いやいや、この要素が足りないだろ」「これは違うだろ」という声もあると思います。 ぜひ、私もより一層学んでいきたいと思っていますので、是非ともコメントやSNSなどでご意見やご感想をいただければと思います。
