読者です 読者をやめる 読者になる 読者になる

AllIsHackedOff

Just a memo, just a progress

エレガントに削る / エレガントに実装するということ

BtoBにしろCtoCにしろBtoCにしろ、プロダクトを開発するエンジニアに求められるエレガントさについてふと思うことがあったので書いておく。

言われた仕様や要件をそのまま作ってしまうエンジニアはどんなにコードを書く速度が早かったり難しい実装ができたり、 難しいアルゴリズムを考案することができたとしてもプロダクト開発には向かないと思う。 前提としてリスペクトがあることには留意しておくが、 単純に尖ったエンジニアリングがしたい / その能力が高いならばOSSへコミットしたり言語を作ったり、 研究をやっていたほうが人類を前に進められると思う (どのみち、それらの分野においても要求を「そのまま作る」ことしかできなければ役に立たないと思うが…)

エンジニアに求められるのはある種のエレガントさだ。 ここでのエレガントさは

  1. エレガントに要求を削れること=問題を適切にハンドルできること.
     ・必要なもの/解決すべき問題に対して適切に技術を用いることができること.
  2. エレガントに実装できること.
     ・解決すべき問題を別の問題を誘発せずに解決することができること.
      ・負債を生まない.
      ・運用上の手間を増やさない.
        ・手作業.
        ・コミュニケーション

の2つに大別されると思う。 A.に関しては、下手に要求を削ってしまうと骨抜きになってしまうし、要求を課題解釈して問題に適切に対処できないと巨大な城を建築することになってしまう。どちらの場合も、リソースを使ってゴミを生生していることにほかならない。チームのスループットを確実に低下させる。 ゴミを作らないためにはAのエレガントさが必要だ。Aのエレガントさを高めるためには、技術的な勘所とビジネスドメイン特有のお作法(何をするとユーザに喜ばれるか)の両方を体得していなければいけない。技術的な勘所は削る判断をするために必要なコストパフォーマンスについての示唆をもたらしてくれる。ビジネスドメインの知見に関しては要求が本質的かどうかを見極めるのに使うことができる。
これらの感覚は意識して磨くことができると思う。磨くための方法論に関しては僕も整理がしきれていない(故に記載はしない)。

B.が何故必要かに関しては、大抵の場合は本番でフルスクラッチでコードを書くことなく、エレガントな実装ができなければリリースまでに必要な時間が膨らむし、変なコードを既存コードに混ぜ込んでしまうことで負債を生んだり、別の問題を生んだりしてしあうことがその理由と言える。

AとBどちらに関しても、ユーザ / チームとのコミュニケーションに長けていることは必要条件だと思う。
エンジニアはコミュ障でもいいみたいな意見もあると思うのですが、実際問題無理ゲーだと思う。

このエレガントはプランナーが別に居て企画を立てる場合でもそうでない場合も成り立つかなと。