『So What』 といえば、1959 年にマイルスがモーダルなアプローチを完成させた金字塔。初めて譜面を見たメンバーから「コードが書いてないじゃないですか」と問われたマイルスは、「So What （だからどうした）？」と答えたという。
・・・という話ではなくて、プラグマティズムの話。藤井聡著『プラグマティズムの作法』から。
「So What ?」というシンプルな問いによって、ある仕事の意義と限界を測るというもの。この問いに対して口ごもっって答えにつまるようでは、その仕事が本当に価値があるか怪しいという事になる。
これは、ソフトウェア開発の現場でも有用だと思う。
あるツールやフレームワークやプラクティスなどをプロジェクトに取り入れようとしたとき、それは何のためなのか？ それによって、何がどうなるか？ 誰にとって何が嬉しいのか？
答えられるのが当たり前。そう思いたいけど、意外と現場ではそうじゃなかったりする。単なる流行りとか、スノビズムとか、権威主義とか、個人的趣味とか、自己顕示欲とか、そういった事でプロジェクトに何かが持ち込まれたり何かが決められたりする事がある。（技術が好きで勉強熱心なエンジニアもそういう病気にかかったりしがちだから面倒くさい。）
こうした良く考えてみると大した意味のない仕事に労力を使うことを、「So What ?」と問うてみる習慣によってかなり回避できるのではと思う。
また逆に、本来は非常に価値のある仕事を、「So What ?」に答えられないレベルの理解で始めてしまって、結局まともな効果が上がる前に、中途半端で打ちきる破目になる事もある。（で、自分たちの未熟さを棚に上げて、「やっぱあれはダメだった」的な薄っぺらい「経験談」が語られ始めるよくあるパターン。）
これらについても、まず最初から「So What ?」を意識することで、ブレずに方向性とモチベーションを維持できるようになると思う。
あと、プロジェクトで採用することになった物事についての「So what?」には、自分だけじゃなくプロジェクトのメンバにも答えられるようになってもらった方が良い。PMから各チームリーダ、技術的キーパーソンの辺りには、特に。
たまにプロジェクト外部の権力者から横槍が入ったりする事があるけど（「ディベロッパーテストはコスパが良くわからんから中止しようや？」等）、何を何のためにやろうとしていて、顧客や会社にとって何が嬉しいのか説明できるようにしてもらう必要がある（自身が PM なら言われる間でもなく必須）。説明に関しては、後述の Grandmother テストも関連する。
つうわけで、自分の仕事について「So what?」と自問する事、その答えをプロジェクトとして共有する事によって、いつの間にかプロジェクトが変な方向に迷走したり、いくら頑張っても不毛感に苛まれるといった事を避けられるんじゃないか、というのが So What テスト。
著者によると、学会で「So What ？」を放った場合、専門用語をだらだら羅列しただけの、答えになっていない応答を威圧的な態度で返される事があるという。
こういった「不誠実な」態度は別にして、専門分野に浸っているうちに、ついつい高次の目的とどう繋がっているか見失いう事もままある。これについても、ソフトウェア開発の現場で散見されると思う。
それを防ぐための思考の道具が Grandmother テスト。お婆ちゃんでも分かるように、簡単で実感の伴った説明ができるかどうかを試すというもの。本当に有意義なアイデア／仕事ならば、専門家じゃなくても一般常識と生活感覚で理解できるはずだという考え方。
これを心がけることで、例えば、一見、技術的に高度でクールだけど、良く考えると何が嬉しいのか分からなくなってくるような状況にはまるのを予防できる。
自分も若い頃は、スキルを見せたいってのが半分以上の動機であんな事とか …
0 件のコメント:
コメントを投稿