ソフトウェア開発（自分の場合は Flutter アプリ開発）をしていると、「動けばいい」という考え方に遭遇することがあります。遭遇するというよりは、自分も割とそういう判断をすることがよくあります。
これは「エンジニアではないエンドユーザーにとって、最終的に動くかどうかだけが重要だから、動いている以上コードの細かい部分にこだわる必要はない」として、ソフトウェアの挙動（場合によっては正常系の挙動のみ）さえよければリリースしてしまうということだと思います。
しかし、いろいろな人の「動けばいい」を聞くと、どうも大きく分けて 2 パターンのニュアンスの違いがありそうだなと考えましたので、ここにまとめてみたいと思います。
パターン 1: 「動けばいい」から「細部にこだわるのは無駄」という考え
1 つ目のパターンは「動けばいい」、だから「コードの細部をこだわるのは無駄」、という考え方です。おそらく「動けばいい」という意見を聞いた時、こちらのニュアンスで受け取ることが多いのではないかなと思います。
最終的に動けばなんでも良いので、アーキテクチャを細かく規定するのも無駄だし、クラス名ひとつひとつを時間かけて考える必要もないし、フレームワークの詳細な仕様なんて学ぶ必要もないし、なんなら生成AIが出力したコードをそのまま使えばそれで良い、という考え方です。
自分はこの意見には反対です。理由はパターン 2 を書きながら説明したいと思います。
パターン 2: 「今は動くものを触ってもらうことが最優先」だから「動けばいい」という考え
2 つ目のパターンは「動けばいい」という最終的な判断はパターン 1 と同じものの、そこには「今は動くものをリリースして触ってもらうことが最優先である」という理由がある点が異なります。
特にビジネスにおいて、スピード、コスト、品質の全てを 100 点満点の状態でリリースすることは不可能であることが少なくありません。1
その場合、優先事項を判断して開発を進めることになるのですが、そこで「動くものをユーザーが触れること最優先」と結論づけた結果出てくる言葉が「動けばいい」となるわけです。
2 つのパターンの違い
パターン 1 との決定的な違いとして、「場合によっては細部にこだわる選択肢も持っているし、そのための学習も惜しまない」という点が挙げられます。
パターン 1 の場合はそもそも「動くこと」以外に興味関心がないので、フレームワークやパッケージの詳細な作りや使い方に興味を持つこともなければ、アーキテクチャを策定して守ることに対して「面倒くさいこと」以外の感想を持たなかったりしていそうです。
パターン 2 の場合、「動くこと」以外にも大事な要素があることを理解しているので、優先順位が変わった時に対応できるよう、常により良い開発の進め方やコードの書き方を考えます。いずれ優先順位の比重が品質や開発者体験といった別のものに傾いた時のことも想定して、「動けばいい」ための工数を増やさない範囲で後々のことを考えた作り方を模索します。
「動けばいい」というのはあくまで「その時は動くものを出すことを最優先とする」と判断しただけであり、状況が変われば優先度も変わります。
最終的には「お客さんのため」だったとしても、その「お客さんのため」のプロダクトを作るために必要なことが「品質を上げること」だったり「開発しやすい体制を整えること」だったり「関係者に仕様が分かりやすいシステムにすること」だったり、時と場合と事業の体制によって力の入れ具合とその実現方法は変わります。
「動くものが作れればそれで良い」というスタンスは、いずれ生成AIに仕事を奪われるかもしれません。ステークホルダーと会話して状況を整理し、優先度を整理し、その優先度に従って最適な開発の進め方を判断できる能力こそ生身のエンジニアに必要なことなのではないかと思います。2
また「動けばいい」という意見を聞いた時、その人がどちらのパターンで発言しているのかを考えると、もしかしたら余計な衝突を避けられるかもしれないなとも思います。発言する側も明示的に言葉を補足すると良いでしょう。
と、考えたりしました。以上です。
中條 剛 [Tsuyoshi Chujo] 