seiei-sogen.dev | アジャイルへの違和感の正体(In Japan)〜時間主義と成果主義〜

結論

結論から言うと、日本は、「時間いくら」という働いた時間で労働を測る。しかし、アジャイルは、「動くソフトウェアが基準」という成果主義であり、裁量労働制寄りの考え方だ。したがって、うまく日本の企業文化とマッチしない場合がある。

以下、説明する。

アジャイル＝お客様ファーストで、動くソフトウェアファーストの思想

アジャイルとは何か。これを説明しだすと、本何冊という話になってしまうだろう。だが、アジャイルの思想的な前提は、「アジャイルソフトウェア開発宣言」を見ると、非常にシンプルである。

つまり、「顧客満足至上主義」だ。そして、顧客満足のために、動く価値のあるソフトウェアを提供するという「顧客満足のための動くソフトウェア至上主義」だ。

「アジャイル宣言の背後にある原則」には、こうある。

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

動くソフトウェアこそが進捗の最も重要な尺度です。 Working software is the primary measure of progress.

さらに、「アジャイルソフトウェア開発宣言」には、こうある。

包括的なドキュメントよりも動くソフトウェアを Working software over comprehensive documentation

つまり、顧客満足こそが、最上級の highest priority なのだ。そして、動く価値のあるソフトウェアこそが、ドキュメントよりも何よりも、顧客満足に資するというのが、アジャイルの基本思想である。上記を読むとそのような結論になる。

一読すると、「ふーん」という感じだが、よく考えると、これは当たり前の思想ではない。

「動く価値のあるソフトウェアこそが、顧客満足に資する」というのは、極端に成果主義的な考え方だ。

日本の労働文化とのギャップ

これは、日本の労働文化とは、違う。それを見積もりを例に見ていく。

見積り

アジャイル開発宣言の原則やスクラムガイドでは、見積り手法を規定しない。（必須の単位はない）しかし、「相対評価」は時間見積もりの罠（疑似精密さ）を避けやすい。だから海外で書かれた多くのアジャイルの入門書が単位のないポイントを使うことを推奨している。具体的には、『アジャイルサムライ』や『アジャイルな見積りと計画づくり』などの本だ。一般に、ストーリーポイントなどと呼ばれるものである。

これも、日本では、2 日とか 5 時間とか実時間で、工数を見積もっている現場が多い。

『アジャイルサムライ』や『アジャイルな見積りと計画づくり』などの本が、「時間」でなく、「ポイント」を尺度にしてるのも、「動くソフトウェアこそが進捗の最も重要な尺度です。」というアジャイルの思想によるものと私は考える。以下、実際にアジャイルの解説書でどのように、書かれているか見てみよう。（強調は引用者）

アジャイル手法ではこうした状況、すなわち見積りの数値を再調整する作業がいつまでも終わらなくなる状況に陥るのを避けるために、見積り結果の数値の単位には意味を持たせず、ただポイントとして表現することを推奨している。 その狙いは、見積りの数値と営業日の日数とを対応させないようにすることだ。『アジャイルサムライ』第 7 章見積り

私たちが注意を払うべき正確さは、仕事の大きさを数値として捉えて、他のストーリーとの相対的なサイズとして表現できているかどうかなんだ。あるいはこう説明してもいいかもしれない。アジャイルな見積りでは、T シャツをサイズごとに振り分けるみたいにストーリーを見積もるんだ。これは S、それは M、あれは L。 『アジャイルサムライ』第 7 章見積り

見積りの単位にポイントを採用することには、次のようなメリットがある。

見積りとは当てずっぽうであることを肝に銘じることができる。

見積りとは純粋に大きさを測るものだと考えることができる（そのほうが見積り結果の賞味期限が長い）。

手早く、気軽に、シンプルに見積もれる。『アジャイルサムライ』第 7 章見積り

ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような、ひとまとまりの仕事に対してポイントを付ける。ポイントの数値そのものはあまり重要ではない。重要なのは、他の作業との相対値だ。2 ポイントを付けられたストーリーは、1 ポイントのストーリーの 2 倍の大きさであり、 3 ポイントのストーリーの 3 分の 2 の大きさとなる。

ストーリーポイントの数値は、ストーリー全体の規模をあらわす。 ストーリーの規模を定義するための数式は存在しない。ストーリーポイントによる見積りが示す値は、フィーチャを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである。『アジャイルな見積りと計画づくり』

「アジャイルな見積りでは、T シャツをサイズごとに振り分けるみたいにストーリーを見積もるんだ。これは S、それは M、あれは L。」 「ストーリーポイントによる見積りが示す値は、フィーチャを実装するのに必要な作業、開発内容の複雑さ、開発に内在するリスクなどが渾然一体となったものである。」

このように、成果（ストーリー、フィーチャー）の必要な作業や開発内容を数値化したものが、ストーリーポイントだ。

だが、日本だと、アジャイルを導入している、スクラムを導入しているという企業でも、成果（ストーリー、フィーチャー）にフォーカスしたポイントではなく、「時間」で作業を見積もることが、多いのではないだろうか。

こうなるのは、日本の企業文化が、「成果主義」ではなく、「何時間働いたか」を重視する「時間基準主義」の文化だからであると私は考える。

この「時間基準主義」はアジャイル思想の「顧客満足のための成果主義」とは根本的に異なる。

ほかにも例えば、リモートワークの議論でも、「勤務中にさぼるのはやめて」VS「さぼっても成果を出せばいい」の対立になることが多い。

これも、日本の「何時間働いたか」を重視する「時間基準主義」から派生しているものと考える。

私の見ている幻想かもしれないが、日本の企業で、アジャイルを導入しても、どうもしっくりこない場合が多いように思う。

そのギャップの根源のひとつとして、アジャイル思想の「成果主義」と日本企業文化の「時間基準主義」とのギャップが考えられるのではないか。そのように思った。

イーロン・マスクの Twitter でのリストラはアジャイル？

イーロン・マスクが、Twitter で、ソフトウェアエンジニアの大リストラを慣行したことがある。あのとき、「書いたコードを提出せよ」「何行コードを書いたか報告せよ」のような通達があって、大パニックになったことがあった。

これはアジャイル的な成果主義なのだろうか？

私はそうは考えない。 Twitter の「行数レビュー」は、「成果っぽい数字」に寄った運用の極端例で、アジャイルの「価値＝動くソフトウェア」原則と一致しない面も大きい。成果主義の危うさを示す反面教師として挙げる。

まとめ

「アジャイル宣言の背後にある原則」

顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

動くソフトウェアこそが進捗の最も重要な尺度です。 Working software is the primary measure of progress.

私は、これがアジャイル思想の出発点だと考えている。つまり、「顧客満足至上主義のための動く価値のあるソフトウェア至上主義」だ。それは、日本の労働の「時間基準主義」的な思考とはギャップがある。だから、日本で、アジャイル開発を取り入れても、どうもしっくりこない場合が多いのではないか、と私は愚考した。

AI（ChatGPT Monday）壁打ち: sizu.me/puremadoka

スクラムおすすめ記事: zenn.dev/shin_semiya

引用元: 「アジャイルソフトウェア開発宣言」「アジャイル宣言の背後にある原則」