Zenn
🦥

YAGNIから受け取ったメッセージ

2023/12/09に公開
YAGNI
idea

はじめに

本記事は Uzabase Advent Calendar 2023 の 9 日目の記事です。

https://qiita.com/advent-calendar/2023/uzabase

本記事では、実際にエクストリーム・プログラミングを一年ちょっと取り組み、改めて YAGNI について考えたことを整理しようと思います。
YAGNI は様々な書籍やブログなどで述べられますが、私はアート・オブ・アジャイル デベロップメントの説明が好きです。

どうせ要らないって（YAGNI: You Aren't Gonna Need It）
この簡潔な XP のことわざは、シンプルな設計の重要な側面をまとめたものだ。
推測に基づいてコーディングするのを避けよう。設計に何かを追加しようとしているときにはいつも、それは今まさに実現しようとしているストーリーや機能をサポートするものか考えてみよう。もしそうでなければ、それは要らない。設計は変化するだろう。顧客の気も変わるだろう。
-- アート・オブ・アジャイル デベロップメント

YAGNI は XP の世界でまさにことわざのように、様々な場面で適用できる教訓です。
記事の最後にいくつか YAGNI について述べているモノのリンクを置いていますので、興味があれば見ていただきたいです。
また、他にもあればコメントとかで教えていただけると嬉しいです。

結論: YAGNI から受け取ったメッセージ

"今必要なことだけをやれ、必要なことを見極めろ"

YAGNI から受け取ったメッセージは以上!なんですが、これだとふんわりしているので、より詳しく説明していきます。
この考え方はあらゆるものに適用される哲学に近しいものだと感じています。

必要なことってなんだろうか？

必要なことをやれと言われても、当たり前じゃんと思うかもしれません。
少なくとも YAGNI という言葉を知ったばかりの私は当たり前じゃんと思っていました。
必要だから今の仕事をやっているんだと。
同じように感じた人はぜひ、今現在やっていることを注意深く見つめ直してみてほしいです。

あらゆるものの 90%はクズである

SF の 90%はクズである。ただし、あらゆるものの 90%はクズである　
-- UNIX という考え方

これはUNIX という考え方のsmall is beautifulの章で出てくる一文です。
注意深く見てみると、最も重要なことは実はほんの僅かなことだと気づくと思います。

重要なことは 10%しかないの？ほんとに？？

いくつかのスコープで考えてみましょう。

  1. touch コマンドについて考えてみる
  2. ユーザーストーリーについて考えてみる

touch コマンドについて考えてみる

UNIX という考え方ではcpコマンドについて触れられていますが、ここではtouchコマンドについて考えてみましょう。
touchが行いたいことは ファイルのタイムスタンプを現在時刻を更新すること という定義で考えていきます。
(touch コマンドのもともとの意味はこっちらしいです)

以下は ChatGPT に touch コマンドの処理を分解してもらった結果です。

1. コマンドライン引数の解析
   - 入力された引数（ファイル名、オプションなど）の解析。
   - `-t`, `-r` などのオプションに基づく処理方法の決定。
2. ファイルの存在確認
   - 指定されたファイル名に対する存在チェック。
3. ファイルの作成またはタイムスタンプの更新
   - ファイルが存在しない場合、新しい空のファイルを作成。
   - ファイルが存在する場合、タイムスタンプ（最終アクセス時間と最終変更時間）を更新。
   - 特定のオプションが指定されている場合、指定された日時や他のファイルのタイムスタンプに基づく更新。
4. エラー処理
   - ファイルへの書き込み権限がない場合のエラー報告。
   - ファイルシステムの問題やその他のエラーの処理。
5. 処理の完了
   - すべてのステップが正常に完了した場合、成功として処理終了。

ステップに分解したとき、touchが行いたいことはどこに当たるでしょうか？

ファイルが存在する場合、タイムスタンプ（最終アクセス時間と最終変更時間）を更新の特に後半の タイムスタンプ（最終アクセス時間と最終変更時間）を更新だけではないでしょうか？

この一つのコマンドを見ても、本当に届けたい価値はほんの一部分であることが分かります。

ユーザーストーリーについて考えてみる

次はユーザーストーリーについて考えてみましょう。
たとえば、Todo アプリで、ユーザーが Todo を画面で確認できるストーリーを考えてみましょう。
パッと思いつくのは、ユーザーはTodo詳細モーダルでTodoの詳細を見ることができるのような切り方でしょうか。

必要なことを分解してみましょう。

  • Todo 一覧画面から Todo をクリックで Todo 詳細モーダルが開く
  • Todo 詳細モーダルで Todo のタイトルが見れる
  • Todo 詳細モーダルで Todo のメモが見れる
  • Todo 詳細モーダルで Todo の作成日が見れる
  • Todo 詳細モーダルで Todo の更新日が見れる
  • Todo 詳細モーダルで Todo の期限が見れる
  • Todo 詳細モーダルで Todo の作成者が見れる
  • Todo 詳細モーダルで Todo の更新者が見れる
  • Todo 詳細モーダルで Todo の担当者が見れる
  • Todo 詳細モーダルで Todo のステータスが見れる
  • Todo 詳細モーダルの ☓ をクリックでモーダルを閉じる
  • ...etc

考えようと思えばいくらでもでてきそうなのでこの辺にしておきましょう。
では、必要なことは何でしょうか？

  • そもそも Todo の詳細とは何？
  • そもそも Todo の詳細を見るのにモーダルで表示する必要はあるの？
  • 詳細が仮に作成日だとしたときに、ユーザーが本当に見れることで価値は得られるの？
  • すべての情報が見られるようにするのに仮に 2 週間かかるとしたときに、本当にそこまでの工数をかける価値はあるの？

はじめに定義したストーリーが本当に必要なことだけを述べているかを改めて見たときに、必ずしもそうではないことが分かるかと思います。
また、これだけの情報ではなにが今必要なのか判断することは難しいのではないでしょうか？

コンテキストを把握すること、最終的に届けたい価値が何なのかを認識することをしなければ、本当に必要なことを見極めることはできないことが分かってもらえるとうれしいです。

"必要なことを見極める"ために必要なことはなんだろう？

小ささではなく、シンプルさに着目する

大切なのは、必要なことをただ小さく分解するのではなく、シンプルにすることです。
小さいことには価値がありますが、YAGNI においてはシンプルを突き詰めた結果得られる副作用だと捉えています。

アート・オブ・アジャイル デベロップメントの、ケント・ベックの考えるシンプルさを引用します。

  1. 対象となる顧客に適合している：設計がどれだけ見事で洗練されているかは重要ではない。それを使用して作業する必要のある人が理解していなければ、その人にとってシンプルではない。
  2. 伝達性：伝える必要のある各アイデアがシステムで表現されている。語彙に使用されている単語と同じように、システムの要素は将来の読者に意図を伝える必要がある。
  3. 分解済み：ロジックや構造の重複は、コードの理解と修正を困難にする。
  4. 最小限：上記 3 つの制約内で、システムの要素はできる限り少なくすべきである。要素が少ないというのは、テスト、ドキュメント、伝達が少なくなることを意味する。

-- アート・オブ・アジャイル デベロップメント

ここで重要なのは、対象となる顧客に適合しているで記述されている通り、シンプルさとは自分がこう思うというだけで定義できるものではないということです。
顧客だけでなく、チームメンバーなどステークホルダーへの影響など、様々な視点からのトレードオフを認識して導き出していくことが重要です。

シンプルさを保つことで、コードベースが大きくなったり、プロダクトが肥大化したとしても、速度を落とさずに進化させ続けていくことができます。
これがシンプルさに着目する理由です。

まとめ

"今必要なことだけをやれ、必要なことを見極めろ"

これまで説明してきたとおり、"今、必要なこと"は様々なパラメータによって変わります。
パラメータは、外的要因であったり、社内の状況であったり、チームの進捗や技量など常に変化し続けます。
このパラメータには、届けたい価値やユーザーの理解などの自分自身の変化も含まれます。

パラメータが変化し続けるからこそ、"今、必要なこと"を選び取り、それだけに集中することが必要です。そして、それが完了したらまた、"今、必要なこと"を選択していくのです。

こうすることで、次の必要なことに取り組むときはより深い理解のもとに取り組んでいけます。
このループを回し続けることで、より本質的な価値を素早く提供し、より小さくフィードバックを回していくことに繋がります。

以上、YAGNIから受け取ったメッセージについてでした。
YAGNIはとても短い(短すぎる)フレーズですが、そのフレーズ以上に大切な事を伝えてくれていると思います。

この記事が誰かの役にたてば幸いです。
ありがとうございました。

参考

YAGNI について述べられているモノの一部

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams.
Yagni はもともと、"You Aren't Gonna Need It "の頭文字をとったものだ。これは ExtremeProgramming のマントラで、アジャイルソフトウェアチームでは一般的によく使われる。
-- Yagni Martin Fowler

非常に頭のいい人たちが、抽象化は必要になることを予測してはいけないと提唱してきた。これが YAGNI の哲学である
-- Clean Architecture

それはきっと必要にならない
コードは「多分必要になるだろう」「必要になるかもしれない」で書いてはいけません。本当に必要になったとき、必要なものだけ書く、という方針で望みます。
-- プリンシプル オブ プログラミング

Discussion