エンジニア立ち居振舞い：エンジニアにもコンサルティング的思考を
このようなエントリーがあったので、私も普段気を付けていることについて少しだけ書いてみたい。
イシュー分析ちゃんとやってますか？
何か「こんな機能が欲しい」とクライアントから要望があがった時。仕様を確認したらすぐに開発を始める、という人はさすがにいないと信じたい。
が、なぜその機能が必要なのか？そもそもどんな問題を解決したいのか？この検証プロセスを軽く考えている人が、エンジニアには結構多いように思う。
コンサルティングに近くなるが、イシュー分析することを怠っていると、良いシステムは出来ない。
何のために必要なのですか？程度の質問までは、おそらくエンジニアでも誰しもやっていると思う。でもそこから更に、その変更によって解決されることは、果たして本質なのか？まで追求しているだろうか。
機能の剪定が目的ではない
なるべく作らない、という話にも少し似ているけど、ちょっと違う。機能をふるいにかける事が目的ではない。
表面的に見えている事が必ずしも問題の根本原因とは限らない。顧客の言葉を鵜呑みにしない。こういう機能が欲しいと言われた背景や原因、その原因によって不便を感じている人の数、機能変更によって発生する利用者の日常業務への影響など。イシューをどんどん掘り下げいてき、本当に解決すべきなのは誰のどんな課題なのか、それに対して本当に必要な機能とは何か。しっかり考える。
そんなのエンジニアが考えることじゃないよ、と言う人もいるかもしれない。そういうのはディレクターやUXデザイナーがやる仕事でしょ、という人もいるかもしれない。
しかしこれらを意識して仕事をすると確実に違うのは、一覧表一つ作るにしても、どういうソート順にするべきかが明確に分かることがある。一覧の列名、さらには列の並び順を考える場合にも、適当になることがない。そしてそれらは、残念ながらあまりドキュメント化されることがない。
私は、かつてコンサルティング会社に所属していて、そういった分析を数多くやってきたけど、これは何もコンサルティングだけでなく、エンジニアであってもデザイナーであっても、はたまた営業であっても必要だと思っている。
エンジニアは技術的なことだけを解決すれば良い、と思う人も多いかもしれないけど、私にとっては喜ばれるシステムを作ることがエンジニアの存在意義であり、技術うんぬんはあくまで実現手段の一つに過ぎないと考えている。
