この文章は、pyspa Advent Calendar 2023 の17日目です。昨日 16日目は、@lambda_sakuraの「2023年の活動報告」でした。
問題解決が重要だと考えてきた。さまざまな技能、たとえばプレゼンテーション、交渉、ソフトウェア開発にまつわるさまざまな技能は、問題解決の手段だと考えてきたし、今でもそう考えている。そのなかで私はソフトウェア開発における、要件定義、設計、実装にやりがいや楽しみを見出してきた。
問題解決のアプローチや方法論にはいろいろあるんだけれど、ワインバーグの「ライト、ついてますか 問題発見の人間学」にいたく感銘を受けた。とりとめのない創作エッセイ風なんだけど、要約すると「誰にとって何が問題なのかが重要であり、それを特定することは難しいけれど、あきらめるな」ということだ。
すべてが釘に見えているハンマーを持つ人間のように、私はずっと問題解決棒を振り回し続けてきた。
過去に計測器メーカーでカスタマーサポートや、特定業界の go-to person 的な提案担当をしていたことがある。API ベースの SaaS 企業でソリューションアーキテクトやセールスエンジニアみたいなことをやったこともある。まずは顧客が抱えている課題はなんだろうか、を見つけ出し、必要であれば再定義した。そして課題を解決する手段として、製品やら、機能やら、方法論やらを提案してきた。うまくいくこともあるし、うまくいかないこともある。ふりかえりをして、次はうまくやろうとやってきた。
解決策のパターンを知らなければ、課題を見つけられないことだってある。ソフトウェア開発でいえば、リファクタリングのコンセプトやパターンを知らないと、リファクタリングが必要な箇所＝課題を見つけるのは難しいかも知れない。
なので、私はアタリをつけて、適当な仮説設定をして、こうっすかね、と提案したりしていた。なのにうまくいかない。なんというか、課題の検証をされずに「提案いただいたので、これで進めます」みたいになったりする。
あるいは、担当者が事業課題とは別の動機を持っていることもある。ライバルに勝ちたい、業界で目立ちたい、入社間もないので交渉で勝ったという実績が欲しい、など。あるいはとにかく波風を立てたくないという動機だってある。若手のチャレンジ枠としてテレビ番組を作ろう、みたいなプロジェクトに参加したとき「俺はこの仕事で一切リスクをおかすつもりはない」と言い放ったプロデューサーがいた。
事業と個人の課題が合っていないというメタ課題が出てきたりするわけだけれど、それでも課題は明らかになる。面倒ではあるけれど。