「ソフトウェア開発ファシリテーション」アドベントカレンダー24日目の記事です。
ちょっとしたユーザー認証でもやたら技術的に難しそうだと思われるのに、Excelみたいなスプレッドシート機能はなぜか簡単そうだと思われる、というのが「報われない」象限の立ち位置です。
思い返すと、プログラマじゃない人が「この機能は簡単ですよね？」などと嘯いているプロジェクトは大抵問題が起きがちな気がしています。難易度の話はプログラマが判断することであって、お願いする側が難易度の想定までし出すと、勝手に仕事の期待値が下がっていってしまうからです。「このぐらいできて当たり前でしょ」みたいに。「できて当たり前」の仕事をいくら積み重ねても信頼貯金は貯まらないので、結果ちょっとした失敗で信頼がマイナスになって問題になる、という感じです。
というわけで報われない仕事をいくらやっていてもやっぱり報われないので、報われるようにできることと言えば下の図のような工夫です。
情報の非対称性をなくした上で、提供価値は変えずに仕事の中身を工夫するということですね。
ただ、これだと一つ観点が抜けています。そもそもそれが今重要なことなのか、今すぐには必要ないものか、という重要度の観点です。
本質は「重要なことをすぐできるようにアレンジできる」ということ。このアレンジ能力には見た目と現実のマトリクスと共通項がある気がしています。
「重要だけど時間がかかること」をそのまま正直にやっていたのではなかなか高まりません。提供価値も踏まえながら、できるだけ右上象限に持って行けるよう、お互いに工夫し合えるのがベストです。
「これはさすがに難しいですよ」「いやいや、なんとかしろよ」を超えて行けるかどうかは、ファシリテーションの腕の見せ所ですね。
