2021-01-31

実装速度を向上させるためのセルフリファインメント

実装速度を向上させる目的で最近個人的にやっている「セルフリファインメント」について紹介。

セルフリファインメントとは

「セルフリファインメント」というのは自分が勝手にそう呼んでいるだけの言葉で明確な定義は無いが、これから実装しようとしているタスクの詳細化を1人でやるということ。

スクラム開発に親しんでいる人ならば、スプリント計画の前にプロダクトバックログアイテムのリファインメント作業をしていることと思うが、それをより深いレベルで詳細化するという作業を、1人で、実装作業に入る前にやるというもの。

なぜセルフリファインメントなのか?

実装速度に影響する要因として、

  • 要件の理解度
  • 要件をコードに変換するスキル

の2つが大きくあると考えており、セルフリファインメントではこのうち前者の「要件の理解度」を高めることで実装速度をあげようと試みている。

ベテランエンジニアと呼ばれるような方々は「要件をコードに変換するスキル」に優れている。なので実現したいことが定まってさえいればそれをコード化するということが素早くできる(そしてその要求が曖昧であってもいい感じにコード化してくれたりする)。一方で、ベテランエンジニアであってもそもそも要件が曖昧な状態では、それを正確にコード化することは不可能である。

ある程度、実装作業の数をこなすと自然と「要件をコードに変換するスキル」は上がってくるし、またググることで解決策の断片を手に入れることもしやすい。これから実装しようとしている案件に、自分にとって全く新しい技術要件が無いような場合には要件の理解度を上げることのほうが効果的であると考えている。

どうやるか

箇条書きになってしまうが、以下に書いたようなことをやる。

  • コードを書き始める前にやる。セルフリファインメントが終わるまではコードは1行も書いてはいけない。

    • エディタを開いてコードを見始めると様々なことが気になってきてしまうため
  • 基本的には1人でやる

    • なぜなら気になる部分や不安に思う部分は自分しか判断できないから。自分が納得して理解している状態にするのが大事
    • メンター的な人にサポートしてもらうのはいいかもしれない(自分はやったことはない)
  • 基本は自然言語で詳細化を行うと良いだろう。もしコードで表現したほうがいい場合はそれでも良い。

    • 大事なのは自分が正確に理解できる表現になっていること
  • コードを書き始めたら、立ち止まることなくそこに書いた要件をコード化できると感じるレベルにまで詳細化する

    • どのくらい詳細化すればいいかは、自身の「要件をコードに変換するスキル」に準じる
    • メソッドやクラスの入出力インターフェース決め、テストケースの洗い出しは最低限やったほうがいいだろうと思う
    • 仕様が複雑な場合は、デシジョンテーブルなどを使って考えうるパターンを表現しておくと良い
  • もし馴染みのないライブラリや機能を使う必要がある場合は、事前にサンプルコードを書いて検証しておく

    • Railsアプリケーションを開発しているならば rails console を使うと効率的に検証できるだろう
  • もし未定義の仕様や考慮されていない事項を見つけた場合はチームメンバーやプロダクトオーナー的存在の人に相談して方針を決定する

    • 要件の確認作業がコードを書き始めてから起こるようなことは回避する
    • ここで方針を握っておくことでコードレビューで不要な指摘事項をもらうことも回避できる

具体例

例として、書籍管理アプリケーションを開発しているものとして「システム管理者が書籍をフォームから新規登録できるようにする」というような実装案件があったとする。

自分の場合は、次のような成果物ができれば十分だろうと思う。

- URL 
  - `GET /books/new` で登録フォームを表示する
  - `POST /books` で登録処理を受け付ける
- フォームのパラメータ
  - 書籍名、ISBN、著者名(複数)、発行年月日
- フォームの応答
  - 成功時は書籍の詳細画面にリダイレクトする。フラッシュメッセージは `書籍登録に成功しました` とする。
  - エラー時は `/books/new` に戻し、エラーの詳細を表示する。このとき、フォーム項目ごとに細かいエラー表示は不要である。フォームの上部に箇条書きでエラーをまとめて表示すればいい。
    - HTMLとしてはulタグとliタグで出力する。エラー表示用のHTMLクラスはすでにある `errors` を使おう。
- 権限チェック
  - システム管理者以外はアクセスできないようにする。URLで直接アクセスした場合は403エラーを返す。
  - システム管理者であるとは、...を見ればわかる
- テストケース
  - パラメータが正常な場合、書籍データを作って詳細画面にリダイレクトされること
  - パラメータが不足している場合、書籍データは作らず、新規作成画面に戻すこと
  - ログインユーザの権限が不足している場合は、403でエラーを返すこと

※ その他、例えば次のような活動があるかもしれない
- 入力値のバリデーションの実装の仕方が不安だ。 → 既存コードを見つつ、rails consoleで試そう。
- ISBNって未指定の場合でもいいのかな。→ プロダクトオーナーや先輩エンジニアに相談して方針を決めよう

前述の通り、どこまで詳細な成果物になるかは自分自身のスキルや知識の度合いによって変わる。

最後に

万人におすすめできるやり方ではないとは思っているが、実装速度について課題感を感じている人は一度試してみてもいいかも。 一見遠回りに見えるかもしれないが、実装要件を自分の中で明確化できていれば、その後の実装作業にはそこまで時間はかからないことが多いと思う。