この記事面白かったです！
「出来る」と「実装する」の間には多くの解決すべき問題が含まれているから気をつけろよっていう警鐘を鳴らしている記事なのに、「出来るからやるって単純バカなんだけど」っていう反応が多いのが印象的でした。その理由の９割は、タイトルに「エンジニアはネ申」って書いたせいだと思うけど。
私からは、社内業務システム内製を通じて感じました、創造主であるところのエンジニアとハッピーに仕事をするためにはこういうことを一緒に考えよう、っていう話をしたいと思います。
実装可能と実現可能は別問題
前述の記事も僕の補足も、主題はこれだけ。だいたいそんな感じ。でも、順を追って説明します。
技術的に実装可能なのか否かは、当然一番最初に考える問題です。そこでNoならこの話は終わります。技術的と簡単にまとめますが、エンジニアによって判断基準は全然違うから悩ましいです。そこは差し引いて、単純に求められた機能の実装が可能なのかという点に絞って前提をおきます。
仮にその機能が実装可能とします。政治的制約(大人の事情)を度外視して本筋を述べますと、「可能かどうか」と「やる必要があるか」は全く別の話になります。可能だからあったほうがいいのでやろうってのは、よい結果を生みません。哲学がないからです。本来は「無くてはならないものだから、やろう」という説明が出来る必要があります。
実装可能から実現可能かの議論を生産的に行うためには、ソフトウェア開発においては下記の代表的なポイントを抑える必要があります。
- 既存のプログラムの影響範囲
- 納期が遵守可能かどうか
- 実装コスト(工数)
- その機能があることに生まれる価値
- その機能がないと損失する価値
ほとんど政治的な部分です。作ることの意味を見出すためには、ソフトウェアを使っている人々の様々な立場を吸収して立脚点を作る必要があります。
僕の場合、経営者及び事務方の思いつきによる「これがあるといいなぁ」というぼんやりした実装依頼が結構多いです。それだけでは作る理由にはならないので、「現時点でその機能がないことでどんな損失があるのか」という話を先に詰めます。その詰めを怠ってしまうと、ソフトウェアがどんどんメタボリックになります。作ることで自分の首を絞めて技術的負債が積み上がるなんて、実にバカバカしい。非常に良くないことです。
難易度は別問題として、機能追加するのは簡単です。作ればいい。人間で言えば、食べる量を増やせばいい。でも、減らすには哲学が必要です。ダイエットに適切な方法と適切な食事が必要なように。
・・・っていう背景を前提において考えますと、ソフトウェアのマネジメントをするにあたっては「作らなくてもいいんじゃね、それ」を議論するのが一番早道だなぁと感じることが多いです。何故かと言いますと、
- その機能が無いと解決できない問題は明確なのか
- その問題を解決することでどんなメリットがあるのか
- これだけのコストをかける意味があるのか
- 作る以前に代替手段はないのか
上記４つに明確に回答できる必要があるからです。この４点を利用者・実装者・マネージャーの三者で共有することが、「やらなきゃよかった」という残念な結果を未然に防いでくれます。
なんでここまで議論する必要があるかって言うと、間違った要求が来ることも多いから、だったりします。欲しいって言ってる内容と、実現したことで期待する結果が食い違うのはよくある話ですよね。お前が欲しいから作ったのにこれは違うってなんだよ、みたいな。その乖離を防ぐことはとても重要な事です。腐った仕様を生み出して機能を提供してしまうと、誰も得をしませんから。
この問題については詳しくは下記の過去記事で議論していますので、よろしければご参照下さい。
Happy Coding!
