なぜプログラマーが人の内面を学ぶのか

わたしは共感力が高い方ではないのですが、人の内面について学ぶのがとても好きなのです。ユング派の心理学だったりプロセス指向心理学だったりインテグラル理論というものをどっぷり勉強していたりします。

そんな感じで「実は結構、人の内面についてライフワークのように学んでいるんだよね」という話をすると「プログラマーなのに何でそういうことに興味があるの？」という話になります。

プログラマーというと、パソコンの前に張り付いてただただコードを書きまくる、いざ話をしようとしても専門用語ばかりまくしたててくる自然言語の通じない奴というイメージがあるようです。

（まぁ、そういう人もいるけど）

個人的にはこの「言葉が通じない奴」という前提が厄介で、まず「言葉が通じる人なんだ」と思っていただくところから始めなくてはいけないことに常日頃から心を砕かざるを得ないことを考えると、酷い風評被害だなぁと感じております。

なぜこれが風評被害になり得るのかというと、職業プログラマーの仕事は人の話を聴くことに尽きるからです。

職業としてプログラマーをしている以上は自分で好き勝手に仕様を考えることは稀で、基本的には誰かのニーズを聴きながら仕様を一緒に検討しながら開発を進めることになります。受託開発であればニーズを提供してくれる方はお客さまになりますし、自社サービスの開発であればプロダクトオーナーだとかプロダクトマネージャと呼ばれる人と一緒に仕様を検討することになります。仕様を練った上でこれを実現する設計を検討し、それをコードという形で「動くソフトウェア」に反映することで、ソフトウェアを利用するユーザーに価値を提供し続けることがプログラマーの仕事になります。

このようにプログラマーの仕事は常に誰かとコミュニケーションをしながら仕様を作り、その仕様を実現する設計を考えてコードを書いていくことだと考えると、その仕事の基本はまさに人の話を聴くことにあるのだ、ということに同意してもらえると思います。

そこで人の内面という話に繋がります。

上図は「顧客が本当に必要だったもの」という有名な図ですが、「ソフトウェア開発において顧客の要望を捉えることがいかに困難であるか」ということを端的にあらわしています。

この困難さはそもそも顧客自身も本当に必要なものの形が分からないことにあり、あれやこれやと議論を重ねるうちにどんどんと本質から遠ざかってしまうこともあれば、やれアジャイル開発だと行き当たりばったりで物を作り始めて「いや、これだとしっくりこないな」としっくりくるまでトライアンドエラーを繰り返し続けることで時間を金を浪費し続けるといった悲劇が各所で生まれている所以となっています。

わたし自身も他人事ではなくこのような悲劇の当事者になったことから、問題に対して筋の良い解決方法を考えるより先に、どうしてそれが問題だと認識されるようになったのか、その問題が解決した先に見ている未来（ビジョン）は何なのかということにまず目を向けるべきだという考え方に変化していきました。例えば業務システムであれば、業務上の問題を解決するためにはどうすれば良いのかを考えるというよりは、業務システムが改善した先にどのような働き方の変化が生まれるのか、その変化は従業員にとって望ましい未来なのかということをまず考える方にシフトしていきました。

しかしその立場に立つのも一筋縄ではいきません。前述の「プログラマーは話の通じない奴だと思われている問題」から、そもそも「これを言ってもどうせ聞き入れてくれないだろうな」「こんなことはどうせできないって言われるんだろうな」「とにかく事細やかに要求だけ伝えよう」といったスタンスから話がスタートすることが多く、まずこの関係性からでは何も生まれないことをご理解いただくことが重要になってくるのです。

望んでいるのは、心からお互いを信頼しあうことができ、共創的に問題課題に向き合っていける関係性を作り出すことにあります。この関係性があってこそ、思いも寄らぬ創造的な解決方法を生み出す土壌が生まれるのだと考えています。

それでは、この関係性を作り出すためにはどうすれば良いのか？

この問いがプログラマーとしてのわたしにとって最大の関心事であり、人の内面への興味を掻き立てている理由なのでした。