フィードバックを受ければ受けるほどプロジェクトは面白くなる

こんにちは、GxPの石村です。
この記事は [グロースエクスパートナーズ Advent Calendar 2023](https://qiita.com/advent-calendar/2023/gxp) の25日目 です。

弊社のアドベントカレンダーは今年で4年目になりました！
毎年25日目の枠は決まっているのですが、なんと今年は2つ目のアドベントカレンダーにはみ出す記事数となりました。
おかげで締めくくりの日に私も記事を投稿するという初の体験をしています。

これまでのアドベントカレンダーは以下からご覧になれますので、是非覗いてみてください。
[グロースエクスパートナーズ Advent Calendar 2020](https://qiita.com/advent-calendar/2020/gxp)
[グロースエクスパートナーズ Advent Calendar 2021](https://qiita.com/advent-calendar/2021/gxp)
[グロースエクスパートナーズ Advent Calendar 2022](https://qiita.com/advent-calendar/2022/gxp)

# はじめに

今回は、プロジェクトを推進するうえで、顧客とのコミュニケーションのあり方に真摯に向き合うことが、リスク低減にもなるし、おもしろい開発にもつながるという話をしたいと思います。

前提として弊社では顧客のプロダクトを請負や準委任の契約で開発しています。
顧客と直接議論できる距離感ですが、自社プロダクトを作っているわけではないため、エンドユーザーは顧客の顧客です。
そのためうっかりすると顧客にとってのビジネスというのは少し遠い位置のできごとに感じてしまいがちです。

しかし、システム開発というのは顧客のビジネスや取り組みにとって、なくてはならないものであり、成功のカギを握る位置づけになっていることは少なくありません。

そのため、私たちシステム開発者が一歩踏み込んでコミュニケーションすることで、成功率が上がり、納得のいく結果が生まれやすくなります。
それってとってもおもしろくて、やりがいのある仕事だなと私は思います。

# どうやってフィードバックを受けるか考える

私はアジャイル、スクラムに関連する学習をしており、お手本のようなスクラムでなくともなるべくその精神を取り入れたいと考えています。
その中で最も取り入れたいと思うのが、フィードバックです。

弊社で請け負っている開発の中には、本番リリースまでがどうしても長くなる案件もあります。
これはプロダクトの性質によるので、致し方ありません。
しかし、期間が長くウォーターフォール寄りのプロセスでも、工夫してフィードバックを受け続けることで、本当に欲しいものとギャップを減らしていくことができるはずです。

### 顧客が本当に必要だったもの

「顧客が本当に必要だったもの」で検索すると出てくる、有名な絵がありますよね。
著作権がどうなっているのかわからないので、知らない人は検索してみてください。
フィードバックを受けなくたって認識は合っているはずだ、納得してもらえているはずだ、というのは幻想で、顧客と私たちの間や、私たちチームの中でさえ、認識のギャップは思っているより大きいものです。

### 認識のギャップが不安なところ、リスクの大きいところから形にしていく

プロジェクトの中で、ここって言葉だけでは本当に認識があっているのか不安だな、という部分があると思います。
また、技術的難易度が高かったり、つくり上、根幹にかかわる部分というのもあると思います。
こういったところから、形にしていくことをおすすめします。

あるプロジェクトでは、以下のように進行しています。

* プロジェクトの初期に技術検証・プロトタイプの工程を設けて、一部機能を先行開発する
* 定期的に完成したところまでを触れる場を設ける
* 直接触ってもらうのが難しい場合は開発者環境で動画を撮ったりWeb会議の画面共有で見てもらう

ウォーターフォールではドキュメントレビューを行うことでギャップを埋めようとしますが、ドキュメントよりも動画、動画よりも実際に触れるものがあったほうがギャップは埋まります。
顧客に成果物を見てもらうことを「完璧かどうかを確認してもらうため」ではなく「少しでも認識のギャップを埋めるため」と考えると、できることはいくらでもあります。

### 顧客も完璧ではない

なぜか顧客の中には最初から完璧なイメージがあると思っている人は多いのですが、全くそんなことはありません。

「エンドユーザーが欲しいもの」と顧客が「きっとエンドユーザーが欲しいだろうと思っているもの」の間にもギャップはありますが、その前に顧客の中の「きっとエンドユーザーが欲しいだろうと思っているもの」のイメージも結構ゆらいでいたりするものです。

そのため、顧客の中のイメージをブラッシュアップしながら、私たち開発者とのギャップを埋めていくという意味でも、可能な限り具体的なものを使ってギャップを埋めていく活動は大切です。

### エンドユーザーに問うことに近づけていく

こういった活動を続けていると、顧客の方も「エンドユーザーの意見を問いたい」と考えるようになっていくようです。
イメージを具体化していく中で、エンドユーザーでないとわからないことがたくさんあるのだと認識できるようになるからだろうと思います。

その結果、あるプロジェクトではエンドユーザーに顧客がヒアリングに行ってくれたり、よりエンドユーザーに近い担当者を連れてきてくれたりするようになりました。

# プロジェクトリスクを一番知っているのは顧客ではなく私たちである

ここまではどう外側からフィードバックを得るか？というお話をしてきました。
しかし、プロジェクトを推進する中で、私たち開発サイドの方がよく知っていることも出てきます。
その中で自覚をすると扱い方が変わってくると思うのが、プロジェクトリスクです。

プロジェクトを推進する上で、リスク管理は避けて通れません。
リスクについて顧客と会話するのは、プロジェクト初期に洗い出したリスクを説明するときや、プロジェクトの進行に従ってリスクが顕在化しそうなときでしょう。
このとき、以下を目的に話しがちです。

* リスクを説明して内容を理解してもらう
* リスクが顕在化しそうなことをお知らせする

どちらも間違った行動ではありません。
しかし、もう1歩踏み込むことで、リスクを低減できないでしょうか。
そのリスクは、顧客の行動によって、低減できる可能性がないでしょうか。

特にリスク発生時にコストを支払うのが顧客である場合、優しい言い方や、聞き流されそうなぐらい淡々とした説明をしがちです。
しかし、そのような言い方をすると相手は深刻に捉えられません。
結果として顧客が説明から感じていた以上に顧客は損をすることになります。

「誰が悪いか」という議論になれば、説明されたのにリスクの重さを正しく捉えられなかった顧客が悪いということにはなるでしょう。
しかし、そのリスクを一番理解しているのはプロジェクトを推進している私たちです。
時には甘い顔をせず顧客のお尻を叩いて行動を促すことで、自社にとってだけでなく、顧客にとってもそのプロジェクトがうまくいくようにふるまいたいものです。

# さいごに

私は今期（2023年9月～）にいちユニットマネージャーから執行役員になるという大きな人事がありまして、この数か月はいろんな取り組みを始めています。
それらはまだ語る段階にきていないのですが、その中のひとつとして「自分たちの仕事を自分たちで面白くできる組織を作りたい」という想いがあります。
面白さは人それぞれですが、この記事で私にとっての面白さを私がどうやって作っているのかの一端が伝わると嬉しく思い、この記事を書きました。

しかし、肝心の私がどう面白さを感じているのかが伝わらないと社内レビューで指摘がありましたので、おまけとしてしたためます。

### 私にとっての仕事の面白さとは何か

私が面白いと感じる条件は複数あるのですが、今回記事にしたのは「主体的に関われる仕事が好き」「だんだんいいものになっていくのが嬉しい」ということかなと思います。

私はまずプロジェクトに関わる時には、その仕事の意義がどこにあるのかが感じ取れるぐらいまで知るようにしています。
WhatやHowだけでなく、Whyを知ると分かってくるはずです。
いきなりWhyだけを聞いてもイメージが湧かないので、解像度を上げるためのWhatやHowも大切です。
知った上で、どこにもやりがいを感じないのだとしたら、私ならその仕事は辞退することを考えます。
Whyには共感できるがWhatやHowに違和感を覚える場合は、状況次第ですがそこは変えたらいいんじゃないかと思います。
本当に変えられないことというのは、案外少ないものです。

きっかけとしてのやりがいのかけらはこんなふうに見つけられるものですが、そこから育てるのは自分自身です。
育てるにはみつけたやりがいに向き合い、主体的に関わっていくしかありません。
プロジェクトが成功するために自分にできることをします。
私の場合は顧客と開発チームの間に立つことが多く、少し引いた目でプロジェクトを見つめることができます。
そのため、ここで記事にしたような罠にはまりそうになっていたり、適切なコミュニケーションが取れない関係性になっていると感じたら介入するようにしています。

「介入する」と書くとドライに見えますが、そこで私好みのアレンジをしてより自分のやりがいが大きくなるような提案をすることも多いです。
たとえば私はユーザーが使う姿を想像しながらああでもないこうでもないと議論するのが好きなので、概要設計のイメージをすり合わせる名目でチームも顧客も集めて2日間集中合宿を行ったことがあります。
やったことがなかったので嫌がられるかと思ったのですが、意外と乗ってくれましたし、距離が近くなってお互いに率直な議論がしやすくなったと感じています。

こんな風に取り組んでいると、やりがいは増していき、関係者の間にいいものを一緒に作ろうという空気が伝播していき、面白い仕事になっていくと感じます。

少しでも、「こいつは仕事を楽しんでいるんだな」と感じてもらえれば幸いです。
みなさんも、自分の仕事を自分で楽しくしていきましょう！

メリークリスマス！