時間は、機能ではなく設計に使おう

エンジニアの時間は、どこへ使うべきだろう

前回の記事では、

「車輪は、もう発明しなくていい」

というお話をしました。

世の中には、すでに磨き続けられている共通機能があります。

それらを活用することで、自分たちは本当に価値を生み出す部分へ時間を使えるようになります。

では、その時間はどこへ使えばよいのでしょうか。

私は、その答えは 設計 だと思っています。

コードを書く前から、設計は始まっている

設計とは、画面を描くことでも、データベースを決めることでもありません。

もっと前の段階があります。

「このサービスを使う人は、どんな人だろう。」

「どこで迷うだろう。」

「失敗したら、どうすれば安心できるだろう。」

「もし認証できなかったら？」

「もし通信できなかったら？」

そんな「もし」を、一つひとつ 想像する こと。

それが設計の始まりです。

想像力が、ユーザー体験をつくる

良い設計には、想像力があります。

利用者になって考える。

困っている人になって考える。

初めて使う人になって考える。

高齢の方ならどうだろう。

忙しい現場ならどうだろう。

通信環境が悪い場所ならどうだろう。

そうした想像力が、

• わかりやすい画面
• 迷わない操作
• 自然な業務フロー
• 安心できるバックアップ

を生み出します。

コードは、その設計を形にするための手段です。

技術選定も、大切な設計

もちろん、

• どのAPIを使うか
• どのデータベースを選ぶか
• どのクラウドを利用するか

そうした技術選定も重要です。

しかし、その前に考えたいことがあります。

「どんな体験を届けたいのか。」

そこが決まれば、

必要な技術も、

必要なコードも、

自然と見えてきます。

設計とは、思いやりを形にすること

日本には、「思いやり（Omoiyari）」という言葉があります。

相手が困る前に考える。

言われる前に準備しておく。

その姿勢は、システム設計にもよく似ています。

利用者が安心して使えるように。

迷わず目的を達成できるように。

障害が起きても慌てなくて済むように。

設計とは、

技術力だけではありません。

想像力と思いやりを、システムという形にする仕事です。

---

Engineering Time

エンジニアの時間は、限られています。

だからこそ、

コードを書くことだけではなく、

考えることに時間を使いたい。

その想像力が、

サービスの価値を決めていきます。

次回は、

「コードを書くことが、仕事じゃない」

について考えてみます。