ある日、家でこんな会話があった。
家族が友人(社内エンジニア)とのやりとりを話してくれた。
「こんなの5分でできるよね？」と言われた友人が、
『5分だけど、5分じゃない』
と返したらしい。
それを聞いた家族が私に尋ねた。
「それってどういうこと？」
確かに不思議な表現だ。
できるのか、できないのか。どっちなのか。
「簡単な修正なんだからすぐできる───」
私にも身に覚えがある出来事に、胃がきゅっとなる。
そこで私はその友人のメンツのためにも、架空の家計アプリを例に説明をしてみた。
その時の実際の手書きメモ。煩雑なのはご容赦頂きたい。
入力画面にメモ欄を追加するだけの話
例えば、家計アプリに「メモ欄を追加して欲しい」と言われたとする。
見た目だけなら、入力欄をひとつ追加するだけ。
実装作業だけを切り取るなら、数分でできるかもしれない。
だから「5分でできる」という感覚は間違っていない。
けれど、エンジニアの頭の中では同時に別の問いが立ち上がる。
・どこに保存するのか
・既存のデータ構造に影響はないか
・将来複数持つ可能性はあるか
・検索対象に含めるか
・レポート出力はどうするか
・データ量が増えた時の影響は
etc…
これは”考えすぎ”ではない。
今は小さく見える変更が、後から大きな影響を持たないかを確認しているだけだ。
思考の奥行きではなく、役割の違い
依頼する側は、「いま必要なこと」「ビジネスとしての価値」を考える役割を担っている。
エンジニアは、「それが将来どう影響するか」「安全に運用できるか」を考える役割を担っている。
視点が違うのは、思考の奥行きや優劣ではなく責任範囲の違いだ。
だからこそ、「5分」の感覚にズレが生まれる。
エンジニアの仕事は”未来を守ること”
実装だけなら5分で終わるかもしれない。
でも、その変更が数ヶ月後も問題なく使えるかと考える時間は5分では足りない。
エンジニアの仕事はただコードを書くことではない。
将来のトラブルを未然に防ぐこと。
変更しやすい構造を保つこと。
後から困らない形に整えること。
少し臭い表現になるかもしれないが、言い換えれば「未来を守る」ことだと思っている。
小さな判断の積み重ねが、組織の信頼になる
システムは、小さな判断の積み重ねで出来ている。
メモ欄一つの追加も、その場しのぎで作るのか、将来を見越して整えるのかで数年後の保守性や安定性が変わる。
私個人としては、こうした小さな設計判断を丁寧に重ねることが結果的に組織の信頼に繋がるのではないかと思っている。
派手ではないが、確実に効いてくる部分だ。
「5分だけど、5分じゃない」の意味
5分で”動くもの”は作ることができる。
でも5分で”安心して使い続けられるもの”は作れない。
スピードも大切だ。
品質も大切だ。
そのバランスをどう取るかを考えるのが、エンジニアという役割なのだと思う。
だから今日も、「5分でできるか？」ではなく、「どうすれば安心して使い続けられるか？」を考えながら私はPCに向かっている。