受託開発での提供価値は、このワークショップで大幅に変わる気がする

はじめに

FusicPMOチームでPM（プロジェクトマネージャー）をしている船越です。

この記事では、業務システムの受託開発にて、初期フェーズに大事にしたいことを考察し、
そのための方法の一つであるワークショップ例をご紹介します。

過去に実践したプロジェクトでは、お客様より「体感として1/10の作業量になったといって過言ではない」との評価をいただくことに繋がり、PMチームとしては手応えを感じている方法の一つです。

PMについてざっくり

PMの仕事は、色々と幅広ではありますが、プロジェクトマネジメントを「独自の目標を設定し、期限までにそれを達成できるように、一連の活動全体を管理・統制すること」と、仮に定義します。

すなわち、「独自の目標を設定すること」でプロジェクトはスタートでき、「決まった期限」の中で、進捗を管理したり、内容を取捨選択したり、ときにはメンバーを増減させたり…と、色々と調整しながら「目標の達成」を実現させていくことがPMの仕事です。

今回のフォーカス

PMをイメージすると、「期限までにそれを達成できるように、一連の活動全体を管理・統制すること」の部分にフォーカスされやすいのですが、今回フォーカスしたいのは、受託開発における「独自の目標設定」についてです。

誤解を恐れずに言うと、Fusicは、「独自の目標設定」をずれなく決められたプロジェクトにおいては、その目標達成のために進行すること（システム構築をすること）はとても強い会社です。
一方で、「独自の目標設定」ということをしっかりできているかについては、まだまだ改善の余地があるのではないかと考えています。この部分が強化されることにより、より満足度の高いプロジェクト（＝システム納品）ができるのではないかというのが今回の主題です。

受託開発における「独自の目標設定」の課題

一般的に受託開発では、発注者から作りたいシステムの目的や課題をヒアリングすることで開発が開始します。

発注者側メイン担当者を中心にヒアリングするケースが多いです。

この場合、「発注者側メイン担当者」が、目的・課題を認識していること、つまりは「プロジェクトで実現する独自の目標」を決められる前提としてヒアリングを行います。

「発注者側メイン担当者」次第によって、プロジェクトの成功が左右されてしまう危険性があると考えることができます。

---

実際に、しっかりとヒアリングし、抽出した課題を解決できるはずのシステムを作った場合でも、思った程の効果を得られない結果になることがあります。（開発側として都度都度反省するところですが、起こり得るのです…。）

ここで、忘れてしまいそうなことを上げると、実は発注者の立場であっても、必ずしも真に作るべきものが何なのかわかっているわけではないということです。

例えばクライアントの業務を改善できるシステムとします。担当者に深く聞いても以下のような課題が発生しえます

• そもそも担当者がすべての業務を把握しているわけではない。（業務フローには異なる部署の仕事も含む）
• 過去にA部門、今B部門という人がいた場合も、その人が知っているA部門の仕事が今のA部門の仕事というわけではない。
• A部門のトップの人でも、A部門の作業者の細かい仕事まで知っているというわけではない。
• 担当者が、他部門の課題をヒアリングしてはいるが、粒感などがまちまちであり、重要度、影響度がよくわからない

などです。

開発者の立場として、解像度が低い情報が多い場合は、特定の部門の担当者からヒアリングなどを行いますが、「主担当者」と「部門の担当者」など、ステークホルダの中でも目線が異なり、正常に優先度の設定ができないなどの問題が発生してしまったりもします。

---

さらには、その会社特有の人間関係みたいなものが存在することも忘れてはいけません。
他部署がいるところでは発言がしづらい、上司の前ではアイデアを言いづらいなどです。
このような状況では、「業務フローで改善したいクリティカルな部分（＝独自の目標設定）」を抽出するのは、
実はすごく難しいのです。

前置きがすごく長くなってしまいましたが、このような課題を解決するための方法として、
関係者を集め、素早く課題を引き出す方法をここでは共有してみようと思います。

業務フローを分析して、真に解決したい課題を抽出するワークショップ

ファシリテーションで絶対的に信頼している会社であるCGFM様にご協力いただきながら、
ワークショップの一つの形をつくりました。
複数部門の担当者が参加し、課題を抽出していくことを行うためのものです。
ポイントは、クライアント自らが課題を認識し、優先度をつけ、注力するべきポイントを見つけられるというところです。

0.前準備

• 改善したい一連の業務に関わるメンバーを、できる限りバランスよく集める。
• 会話のしやすさの観点から、3の倍数で集められるのがベター。3人2チーム=6名程度いると、偏った意見も少なくなる。
• 発言力が強すぎる人は、場合によっては参加を控えてもらう。
• アイスブレイクなどを行い、全員が発言することに抵抗感がなくなる環境を作ることを忘れてはいけない。
• アイデア出しや意見は、付箋などの紙に残すことを基本ルールとする。

1.目的の共有

• 人数が多い会議では話がバラバラと飛びがちです。しっかりと目的を共有します。

• ここでは、以下のような目的をイメージする。

  • 参加メンバー全体で、業務フローの共通認識を持つこと
  • 業務フローの中にある課題を抽出できること
  • 課題の中から優先度の高いものを抽出できること

この時点では**「システムで何を作るか」というところから頭を離します**。
機能的なものは、真の課題が見つかってから深ぼっていきましょう。

2. 業務フローの洗い出し

• 参加者にしっかりと出しきってもらうことを意識します。
• 決まった時間で区切り、「１つの付箋に１つ」の業務をだしてもらい抽出していきます。
• 時間内で抽出した業務の付箋は、時系列順などに並べます。
• 複数人がそれぞれ抽出した「業務」と捉えている粒感が異なることがわかるはずです。
• 照らし合わせて、粒感を揃えつつ、全体の認識をあわせながら業務フローをつくっていきましょう。

あくまでも発注者側が業務フローを完成させていくことに意味があると考えます。
（我々はシステム開発社であっても、クライアントの業務のスペシャリストではないことを理解しておかないといけません。）

3. フローの中にある困りごとを洗い出す

• 業務フローが具体的に見えてくると、各メンバーが業務の「どこで」「どんなこと」に困っているかを考えやすくなります。
• 「１つの付箋に１つ」を基本として決まった時間で一斉に「困りごと」の抽出を行います。
• 出された困りごとの付箋は、フローのどの部分に関連するものなのか一度整理してみるとよいでしょう。
• ↓業務は水色／困りごとはオレンジ／会話ででてきた重要なポイントをピンクなど、予めルールを決めておくと後から認識しやすくなります。

4. 困りごとを２軸でマッピングする

• 3で抽出した「困りごと」を、今度は、なんらかの2軸で分類します。これは、優先度を設定するための準備です。
• 例えば、縦軸を影響度や頻度／横軸を対応のしやすさやコストなどといったイメージです。

5. 本当に解決するべき課題と対応内容を検討する

• マッピングすることで、より優先度の高い困りごとがみえてきます。
• 影響度が大きく、対応しやすいものなどは、優先度の高いものだ！といった具合です。
• マッピングした付箋を元に、本当に解決したい困りごとを抽出します。
• 抽出の際には、参加者で投票を行うなども有効です。（投票は、付箋にシールを貼るなどでできます。）
• 最終的には議論などで決めていく形になりますが、取り組みたい課題がはっきりすればOKです！

おわりに

当たり前のようにも感じられる内容のものですが、多くの人を巻き込み、本当に優先して解決するべき課題が何かを見つけるのを実践していくのは、案外難しいことです。

「システムを考えたい」クライアントにとっては、遠回りのように感じられることもあるかもしれません。

一方で、このステップを終えた後には、「新しい発見があった」「○○さんがこんなに考えているとは思わなかった」「すぐに減らせる無駄が見えた」など、喜ばれることも多いのです。

開発の初期フェーズにおいて、システム要件を定める一歩手前に、このようなことを実践してみるのはいかがでしょうか？

より満足度の高いプロジェクトを実現していきたいものです。