「ソフトウェア開発ファシリテーション」アドベントカレンダー7日目の記事です。
ソフトウェア開発は、あるソフトウェアを作りたい人と、ソフトウェアを作る能力を持っている人がタッグになって物作りをしていく、という構造が通常です。
これが人ではなく会社対会社だとしても、要素が違うだけで構造は一緒ですよね。
この構造にあるとき、タッグを組んだ両者がどのような関係性に立つかで、その後作られていくものの姿は大きく変わります。
個人的にはこれを、相手の理想を追求すればするほど理想とベツモノになる問題と呼んでいます。
「正解がある」パラダイム（あなた vs わたし）
ソフトウェアの受託開発の現場でよくあるのが「正解がある」パラダイムです。
このパラダイムにあるとき、開発者は「相手が自身の作りたいモノを正確に把握できている」ことを期待しています。
「相手は自信の作りたいモノを正確に把握しており、それを忠実に再現することが私の仕事である」という認識に立っているため、いかに正確にヒアリングするかが重要です。
前提として「相手が答えを持っている」という立場に立っているため、「あなた vs わたし」の構造になります。
正確に再現することが仕事なのだとすれば、正確に再現した後の結果については相手の責任であると考えられます。
だとして、ソフトウェア開発のお仕事をお願いする方としては、いかに考え尽くした内容を提示するかがキモになってくるのですが・・・これはとっても難しいことだと思います。
第一に相談する側にとっては、これからやろうとしていることについて、ITの世界でどれだけの選択肢があるかが分かりません。
選択肢もさることながら、それぞれのコスト感も不明です。簡単にできることなのか、非常に難しいことなのか。何らかのサービスを活用すれば実現できるような問題なのか、1からコードを書かないと解決できない問題なのか。
理想は確かにあるものの、現実的な手段に対する解像度は低いため、何となく「こっちの方が簡単かな」「これは難しいかも知れないな」という想定で設計をしてみて、「これってどのぐらいで作れる？」と相談するような状況になります。
本心は「他にも手段はないのかな」「このまま作るのは正直不安だな」と思っているのにも関わらず、それを相談できる関係性でもなく、開発者は正確に作ることが仕事だというスタンスをとっている・・・。
そんな関係性のまま進んだときに現れるのが相手の理想を追求すればするほど理想とベツモノになる問題です。
厄介なのは、頼まれた側からすれば正確にヒアリングして正しく作り上げたはずなのに、頼んだ側からすれば「コレジャナイもの」ができあがってしまうという点です。お互いがプロフェッショナルとして力を尽くしたのにも関わらず、不幸な結末を迎えてしまうパラダイムです。
それではどんなパラダイムに立つべきなのか。
「正解がない」パラダイム（問題 vs わたしたち）
そもそも「誰かが答えを持っている」という前提が誤りだとすれば、その先にあるのは「正解がない」パラダイムです。
そもそも正解がないのであれば、まずは「何が問題なのか？」を理解する立場を取るしかありません。
「そもそも、何が問題なのか？」ということが問われるわけです。
「正解がある」パラダイムでは、いかにHowやWhatを正確にヒアリングするかが重要でしたが、「正解がない」パラダイムではWhyを見える化することが重要になります。
シンプルに言語化できることもあれば、言語化が難しいケースもあります。テクニックとしては図を描きながら整理したり、または画像検索でインスピレーションを喚起させるような画像を引っ張ってきたりと、場の状況に応じて様々な手段はとれますが、重要なのは問題への共通認識を持つということです。
共通認識を持った上で、取れる手段を一緒に検討していくわけです。
「絶対にこれが正しいという選択肢はない」前提に立っているため、それぞれの選択肢に対するメリット・デメリットを共有した上で、コストのかかる決断に対しては事前にインタビューやプロトタイピングなどを通して確からしさを調査するという手段を取ったりもします。
注力すべきは、お互いが持ちうる情報を全て共有するということです。判断をしていくにあたっての、入力情報を合わせるということです。
「実はあのとき、こんな手段があったんですよね」
「共有していなかったんですが、実は同時にこんな問題もありまして」
なんて後から言われたら、物凄く嫌な気持ちになると思いませんか？
入力情報を合わせることで、個々の問題に対するアプローチをロジカルにハラオチしながら行うことができます。アプローチに対する学びを得るという観点からも、ロジカルであるということは重要なことだと思います。
「実のところ相手が何を考えているのか分からない」
「これ、本当に作っていて意味があるのかな？」
「無茶なことを言っていると思うんだけど、本当に分かっているのかな」
これから生み出そうとしているモノが複雑であればあるほど、誰かに正解を求めるということに割が合わなくなってきます。問題に立ち向かっていけるチームを作り出すこと。これがソフトウェア開発のファシリテーションに求められる役割だと思います。
