「これできますか？」とエンジニアに訊いてはいけない

どうも、エンジニアのgamiです。

「これできますか？」

先日、新しく中途入社したビジネス系のメンバーに開発案件の相談の中でこう質問されました。本人としては、顧客から聞いた要望を実現できるかどうか確認するための何気ない一言だったと思います。

「これできますか？」という質問を聞くと、エンジニアとしては少しモヤッとしてしまいます。多くのエンジニアが、Twitterやブログで同種のモヤッと感を表明しているのを目にします。

「これできますか？」という質問には意味がない

「これできますか？」という質問にエンジニアがモヤッとするのは、その質問はあまり意味がないからです。

業務の中で思いつくような要件の中で、「エンジニアがどう頑張ってもできないこと」というのはほとんど存在しません。プログラミング経験の無い人が想像する以上に、プログラムを書いて実現できることの自由度は高い。

もちろん、実現可能性を事前に検証するというのはとても重要です。必要なデータが無いとか、WebやOSやデバイスの仕様上できないとか、そういったケースもあります。しかし、他の誰かがすでに実現しているようなものは、大抵は自社でも頑張れば実現できます。

できるかできないかで問われれば、ほとんど「できる」という答えになる。答えがわかっている質問をあえて問われると、人はそこに皮肉や挑発のニュアンスを想像して不機嫌になることがあります。あるいは、依頼者と前提知識を共有できていないことに失望したりします。「これできますか？」のモヤっと感の正体はここにあります。

「技術的には可能です」

もちろん、エンジニアが少しモヤッとしたところで、すぐに実現できる簡単な内容であればあまり問題にはなりません。しかし、実現が大変な場合には、深刻な問題を引き起こすことがあります。

エンジニアとしては、どんなに難しい内容であっても「できる/できない」で問われたら「できる」と言わざるを得ません。技術的観点からそれを実現する方法に道筋が見えているなら、「できない」と答えるのは嘘になってしまうからです。ときには、「できない」と答えることが自身のプライドに反することもあるでしょう。

こういう状況でエンジニアは、「技術的には可能です」という言葉をよく使います。この「技術的には」という表現には大抵、「たくさんの工数やコストがかかりますが」というニュアンスが込められています。しかし多くの場合、依頼者にはこのニュアンスが理解されません。結果、「じゃあすぐにやってください」という話になり、期待値のズレからプロジェクトの炎上につながるケースもあります。

「技術的には可能です」という言葉は、誤解を生みがちなエンジニアの口癖として、もはやインターネット・ミーム化しています。

「技術的には可能です」というのは、「普通はやらないし、やろうとしたら非常に困難を伴うので諦めてください」という意味なのだが、「技術的に可能ならやってください。保証もしてください」となってしまう。もっと誰にでもわかる表現を考えないといけない。

— uni1000yama1000 (@uni1000yama1000) August 11, 2018

技術的には可能ですとは (イヤゲンジツテキニハムリダカラとは) [単語記事] - ニコニコ大百科

ソフトウェア開発における制約

「技術的には可能です」という言葉の裏には、「様々な制約が問題にならないなら可能です」というニュアンスが込められています。ソフトウェア開発で問題になる制約とは、どんなものがあるでしょうか？

ソフトウェア開発では、「QCD」の3つの要素に対する配慮が必要であるとよくいわれます。QCDとは、Quality、Cost、Deliveryです。それぞれについて、「技術的には可能です」を言い換えてみると、たとえば次のようになります。

●品質（Quality）
- 「見た目はボロボロだけど、同じ機能を実現することはできます」

●コスト（Cost）
- 「毎月100万円の運用コストがかかりますが、できます」
- 「エンジニア5人が1ヶ月間それだけを開発すれば、できます」

●納期（Delivery）
- 「今から着手すれば1年後には、できます」

またソフトウェア開発には、エンジニアのスキル差によってアウトプットに大きな違いが生じるという特徴があります。現実的に開発にアサインできるエンジニアが誰なのか、についても考えなければいけません。

●エンジニアのスキル
- 「他のエンジニアには難しいですが、僕がやればできます」
- 「優秀なエンジニアを採用すれば、できます」

これらの制約を考えると、「理論上はできるが現実的にはできない」という状況はしばしば発生します。普通は、そんなにお金も時間もかけていられないし、優秀なエンジニアのリソースは別の重要な仕事に奪われ確保できません。

依頼者とエンジニアでこうした要素に対する期待がズレているほど、問題は大きくなります。

「これできますか？」と「技術的には可能です」が覆い隠す、期待値のズレ

期待値のズレは、実際に作業に着手したり成果物が出てきたりすると、顕在化します。たとえば次の通りです。

- 「こんなにお金がかかると思ってなかった」
- 「1週間くらいでできると思っていたのに、3ヶ月経っても進捗が無い」
- 「GoogleやAppleのアプリみたいなUIを期待していたけど、思ってたのと違う」

こうした期待値のズレは、問題を「できる/できない」に単純化してしまうことに起因します。言い換えれば、「できる/できない」の判断と「やる/やらない」の判断の間には、大きな差があります。この差を意識して議論を進める必要があります。

何か1つを実現するにも、考えるべき制約は想像以上にたくさんあります。また「できる」ことをすべて「やる」ようでは、時間やお金がいくらあっても足りません。全体としてなるべく多くの成果を短期間であげるためには、次のように仕事を進めます。

・実現可能性を検証する
・必要な工数やコストを見積もる
・他の多くの「できる」こととの間で、優先順位を付ける
・個々の要件に対して、最終的に「やる/やらない」の判断をしていく

実現可能性の検証や工数見積もりは、大抵は技術に明るいエンジニアにしかできません。一方で、優先順位や「やる/やらない」の判断には事業や顧客に関する観点が求められます。それぞれ得意なメンバーが、具体的な部分まで踏み込んだコミュニケーションを取りながら、協力して意思決定をする必要があります。

依頼者は、「これできますか？」の代わりに次のような質問を投げかけることで、「やる/やらない」の判断材料を集めることができます。

- 「やるとしたら、どのくらいの工数かかります？」
- 「やるとしたら、他の作業との兼ね合いもある中で、いつまでにできそうです？」
- 「やるとしたら、システム的なランニングコストって結構かかります？」

依頼をする側としても、「これは大変そう」とか「これはインフラコストかかりそう」といった見当をざっくり付けられるようになると、質問の精度も上がっていきます。ここに、システムやデジタルに関するリテラシーの価値があります。

また依頼を受けるエンジニアとしても、「技術的には可能です」の代わりに次のような返答をすることで、無駄な作業を減らすことができます。

- 「42万円くらいの予算が付くならできますけど、やります？」
- 「機能は実現できますが、このクオリティまで期待されると、僕一人では厳しいですね」
- 「技術的にはできますが、エンジニアのリソースが逼迫してるので、優先順位上げるならマネージャーに相談してもらえます？」

重要なのは、アウトプットのイメージと概算見積もりを依頼者に示して、共通認識を作ることです。大変な作業だと、エンジニア側で「どうせやらないだろう」と早合点してしまうこともあります。しかし、「このくらいの予算が取れればやってもいいです」と高い見積もりを出しても、予想以上に期待が大きく、「それでもやりたい」という判断になるケースもあります。よりよい意思決定のためには、共通認識を作った上で一緒に決めていく、という態度が大切です。

雑で曖昧なコミュニケーションは、潜在的な期待値のズレを覆い隠してしまいます。実際に「やる」となってから問題が顕在化すると、様々な調整が必要になり、想像以上の痛手につながることもあります。日常の些細なコミュニケーション改善から、こうした不幸の可能性を事前に減らしていきましょう。