対応案件は依頼者の想像以上のものが出来ても回らないという不都合な真実。

最近、表題で結論を書いてしまうのだけど、そう思ったのは以下のツイートをみた感想で思ったことを残したことが背景にある。そのツイートに対して、第三者のコメント的には「エンジニアが不憫」とか「そもそも手段と目的を履き違えてる」という声が多いが本当にそうなんだろうか。

エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。

これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。

— ABC予想 (@tmkwsn) September 10, 2022

裏で見ていると一番反応があったのが以下。作る側としての視座に立つと、その気持は痛いほどわかる。というのも必要なのは問題解決なのであって、手段は過程であるからだ。

馬車をより高速にしたいから馬の頭数を増やしたいという顧客に対して自動車を薦めたエンジニアは顧客を不機嫌にしてしまう。世の中難しい。

引用コメント

とはいえ、この歳になって気づくことがある。

作成者は作ったツールを使って実際に運用しない
ツールを使う人は、依頼者やその関係者

ということ。そういう意味では背景を聞くのであれば、依頼背景と同時に運用想定までヒアリングする必要があるということだ（そこ。苦い顔していますね。そうです。いいたことはわかります。けど、それが事実）。

このお姉さんのように、自分が頼んでいる手段以上のものが来た段階で、いかに良い提案であったとしても想像力の斜め上にきた「面倒な話」という解釈でとられるし、その面倒な話を他者に自分の説明する時点で自分の言葉で語れないものは引き継げない。だから、言うわけだ「頼んだものをよこせ」と。

エンジニアは、こういうときにマニュアルがとか手順書がとか言うだろうけど、ポイントなのはそういうドキュメントではなく、手段の勘所が伝わっていないと腹落ちしない。だから、上記のような双方の乖離が発生する。

一方でエンジニア目線からみてこれらの話を問題としていうのは、要望通りのものを収めても、現状課題が解決できるとは限らないから指摘するわけだ。

そもそもこれは課題解決のための案件か、単純な委託業務か。前者の場合の場合、前向きなエンジニアは良かれと思い「解決のための別手段」を提案するわけだし、作業前に発注者と受注者で膝を交えて語る事項となる。

とはいえ。もし、結果を出すための代替提案について発注者側が「自分が腹落ちして説明できね」なら却下した上で、別業者に頼むべき事項だし、本来そのキャスティングボードはパトロンである発注者が握っているわけだ。

気をつけないといけないのは、頼む側が問題解決のために丸投げしてるのか、企画検討は自部門であくまで作業代行をお願いしているのかを「頼む側」が理解しておく必要がある。（そして発注者がそのことを案外理解していないケースも多い）

危ないなと思うのは、このあたりの線引が周りを見ると、最近ほわっとしているケースが散見されるなと。スモールスタートやアジャイルなどのキーワードを「なんとなくほわっとした感じですぐにできるもの」と解釈して進めている人が多い気がしていている。

そのほわっとさが、作る前段階の要件定義や責任分界点の曖昧さになり、その最初のボタンの掛け違いが、双方を不幸にする初手となっている。そういう不条理な事項が世の中、そこかしこに展開している。その割に、どちらもこちらも「僕は悪くない」という子供の駄々っ子が蔓延している。こういう「謝ったら負け」とか「僕じゃない他の人が馬鹿だ」という議論は、そろいそろ終わらせたいよね。

間違ったときには素直にごめんなさいだし、その謝罪にいちいち揚げ足を取る時間あれば問題解決のために、１分でも時間を費やすべきだと思うよ。