ボクのお仕事 10 ヵ条

(1)アウトプットを最小に、アウトカムを最大に

  • 利用者にとって重要なのは「そのプロダクトで自分の問題を解決できるか?」であり、どんなテクノロジーで実現されているかは重要ではない
  • コードは書けば書くほどメンテコストが上がる(テスト項目増、ライブラリのバージョンアップ時の足かせ、etc...)
  • ステークホルダーの求める通りではなく、利用者を知り、理解し、最小限の実装で最大限の価値を生める方法を模索する

(2)リードタイムにフォーカスする

  • 利用者に機能を届けるスピード技術的負債トレードオフを考える
  • 利用者に届くのが 1 日後と 1 週間後で大きく違いを感じてもらえるのか?
  • 感じてもらえるのであれば、技術的負債を抱えてでも 1 日後のリリースを目指すべき
  • 感じてもらえないのであれば、技術的負債を抱えない状態で 1 週間後のリリースを目指すべき(自分の経験上では、こちらであることが多い)

(3)急がない

  • 実装/テスト/仕様決め/人とのコミュニケーション/etc... すべて急がない
  • 50 % のスピードでこなすイメージ
  • 100 % に近いスピードでこなそうとすると抜け漏れが発生しやすくなるし、対人だとその人にプレッシャーをかけてしまう
  • その状態が続くと相手と信頼関係を築くのが難しくなってしまう
  • 代わりに、極端に言えば 50 % のスピードでも他の人の 100 % のスピードと同じくらいになるように知識/知見/技術力を高めておき、いろんなことを早く決断できるようにしておく

(4)視野を広く、視座を行き来する

  • 誰に届けたい機能なのか、誰が届けたい機能なのか、自分たちにできること/できないこと、など視座を行き来する(基本的に誰がの部分は仕様設計者、デザイナー、CSなど、複数名いることが多い)
  • 利用者として、何が期待値となり、どういう操作に誘導され、何を体験するのか、という視野を広く持つ
  • サービス提供者として、どうやって利用者の期待値をつくり、どういう操作に誘導し、どのように価値を感じてもらうのか、という視野を広く持つ

(5)モチベーションを切り離す  

  • モチベーションは付加価値というスタンス
  • モチベーションがゼロ:いい仕事ができる
  • モチベーションが MAX:めちゃくちゃいい仕事ができる

(6)レガシーコードを受け入れる

  • 別チーム/別会社の実装を引き継いで開発を進めたり、プロジェクトに途中から参画することはよくある
  • そのときに「実装がレガシー」「参照している gem が古い」ということもよくある
  • セキュリティ FIX とかは別だけど、そういう場合に無理にキレイなコードに書き換えようとしない、かつ機能追加時もなるべく既存のコードと足並みを揃える
  • コードの書き換え(リファクタ)で効果を上げるためには量が大事だと思っていて、たとえば全体の 5 % を書き換えただけでは逆にメンテコストが上がる(複数の書きっぷりを把握する必要が出てくる)ので、全体の 80 % 以上に手を入れられるリソースと覚悟を持てた時に初めて手を入れる
  • 来たるチャンスのために自分だったらこうするという観点を持ち続けておく(どこかにメモしておければ良し)

 

(7)レビューにはより一層時間をかける

  • レビューは要件や実装、アウトカムを深堀りするチャンス!
  • しっかり時間をかけて自分の学びの場とする
  • レビュー観点
    • 期待通りのもの(利用者への価値)が実装できているか?・・・(1)アウトプットを最小に、アウトカムを最大に、(4)視野を広く、視座を行き来する
    • アウトプットは最小化できているか?・・・(1)アウトプットを最小に、アウトカムを最大に
    • 既存コードとの足並みは揃っているか?・・・(6)レガシーコードを受け入れる
    • 綺麗なコード/無理のない実装となっているか?・・・(4)視野を広く、視座を行き来する、(6)レガシーコードを受け入れる
    • 他の機能との統一感はあるか?・・・(4)視野を広く、視座を行き来する
    • 既存機能をスポイルしてないか?・・・(4)視野を広く、視座を行き来する
    • 1 週間後の自分、1 ヶ月後の自分が理解できるか?

(8)失敗から学ぶのではなく、成功から学ぶ

  • 失敗から学べるのは次から失敗しない方法であり、成功する方法ではない
  • 成功する方法は成功からしか学べない(自転車に乗る方法は自転車に乗れてからじゃないと分からない、と似てる)
  • 「成功とは?」から考え、絶対に成功する方法を模索する

 

(9)未来の自分に向けてドキュメントを書く

  • どんなプロジェクトも複雑性を持っているし、それをすべて把握するのは大変なこと
  • かつ、人は忘れゆくものでもあるので、未来の自分へのメッセージとして経緯や判断基準、調査したことなどをドキュメントとして残しておく
  • コードも変わりゆくものなので、必要以上に信じて「コードを読めば分かる」で片付けない(その当時は「コード読めばわかるだろう」と思っていても、周辺に実装が追加されて 1 年後にはよく分からなくなってしまった、というのはよくある話)

(10)あっても無くてもいいものは無い方がいい

  • 「あっても無くてもいいよ」という機能が必要になることはほとんどなく、「とりあえず実装しておくか」としておくとデッドコードとなってしまうケースが多い
  • 安易に実装せず、周辺を深堀りして本当に必要があるのか否かを確認、必要がなければ実装しないようにする
  • YAGNI、KISS、ジャストインタイム、つくりすぎのムダ

さいごに

エンジニアという仕事柄、新しい言語とかフレームワークとか変わりゆくものばかりに目がいってしまいがちですが、たまには変わらないものを見つめてみるのも良いかもしれません