検索
  • 木下史彦

アリスター・コーバーン再考



この記事は「ESM Advent Calendar 2021」の6日目の記事です。


Agile Studio プロデューサーの木下です。


今年(2021年)の11月に開催された Agile Japan のテーマは「The Heart of Agile」でした。アジャイルマニフェストの執筆者のひとりであるアリスター・コーバーンを迎え、アリスターが提唱する Heart of Agile について、主に4つの価値(Collaborate、Deliver、Reflect、Improve)を中心に講演がありました。


21年前に出版されたアリスターの著書『アジャイルソフトウェア開発』を私はあらためてこの機会に読み直してみました。ここから新たな気づきが得られたので紹介します。



その1. KPT

(出典:『アジャイルソフトウェア開発』)


ふりかえりの手法であるKPT(けぷと)は「ふりかえり=KPT」と連想されるくらい有名ですが、実は『アジャイルソフトウェア開発』で紹介されたのが一番最初です。


ここでは次のように書かれています。


反省会 (中略) この会議の結果は、1枚のカードに、次のインクリメントで試したいアイデア、作業中に念頭に置いておきたい事柄として書き出される。 このカードを3箇所に分割しよう。 左側に、成功していて、次のインクリメントでも維持したいことを書く。 右側に、重点的に行いたい新しい事柄を書く。 成功していることのリストの方が短いと仮定して、今戦っている大きな問題を左側の下の部分に書く(図 5-1 参照)。

ここで私は「あれ??」と思いました。


現状、ほとんどのKPTを紹介は、その名前のとおり K(Keep)→ P(Problem)→ T(Try)の順番にカードを出していくと説明されています。しかし、アリスターの解説は K(Keep)→ T(Try)→ P(Problem)の順番で、しかも Problem はかなり付加的な位置づけであったことに気づきました。


KPT(けぷと)じゃなくて KTP(けとぷ)だった説


Agile Japan の基調講演の中でアリスターは「デルタ・デルタ・テクニック」の紹介をしていました。まさにこれは自分たちがうまくやれていることに注目ししてそれを伸ばしていくやり方です。



上記の引用は次のように続きます。


成功していることから始めよう。成功していて、次のインクリメントでも行いたいことはあるだろうか。

そうなのです。「世界は解決すべき問題の集合」ではないのだ、ということ再認識しました。


その2. 守破離


『アジャイルソフトウェア開発』では学習の3レベルとして守破離が登場します。この守破離のさらに先に心があるというのがアリスターの Heart of Agile のコンセプトです。


守破離に関連して、映画『ベスト・キッド』の「Wax on, Wax off」のエピソードや映画『二郎は鮨の夢を見る』のたまご焼きを何度も焼き直す話をアリスターは自身の講演の中で好んで紹介しています。


『アジャイルソフトウェア開発』にはソフトウェア設計における守破離のエピソードが出てきます。


CRCカードにおけるレベルの混同 (中略) 3人はそれぞれ少しずつ違う方法で設計を行ってしまった。そのことがメンタリングの受講者たちを憤慨させた。彼らはオブジェクト指向設計の初心者だった。「あなたがたはいつも違う方法を行っています。どちらが正しいのですか。どうして正しい方に合わせないのですか」と受講者は言った。 「どちらでもよいのです。どちらでも成功します」と言おうとしたが止めた。混乱している初心者にそんなことを言っても何の役にも立たない。 (中略) 私達はどの方法でも設計セッションが成功することを知っていたが、初心者はまだレベル1の段階で、いつでも適用できる1つの決まった手順を必要としていたのだ。

これを読んでハッとなりました。


「心当たりがある」


守破離というと教わる側の心構えのように考えられがちですが、もうひとつの側面があるのではないか。


守破離は教える側への教訓だった説


アジャイルコーチや研修のトレーナーをやっていると上の引用のCRCカードの事例と似たような場面に遭遇することがよくあります。思い返してみると、守のレベルの人に対して「どちらもでよいです」といった回答や複数のオプションを示してしまっていることがあり、あらためて自分の発言や行動を見直すきっかけになりました。


その3. 創作とコミュニケーションの協調ゲーム


『アジャイルソフトウェア開発』という書籍のタイトルには2つの要素が入っています。「アジャイル」と「ソフトウェア開発」です。アリスターはこのうち「ソフトウェア開発」について相当な紙面を割いて考察しています。その視点は深く鋭いです。


アリスターはこのように書いています。


ソフトウェア開発は創作とコミュニケーションの協調ゲームである。このゲームには、人のアイデアと、そのアイデアを同僚やコンピュータに伝えるコミュニケーション以外は存在しない。

そして、このゲームの2大要素のひとつであるコミュニケーションに関して、完全なコミュニケーションは不可能というスタンスを貫いています。完全なコミュニケーションをとることを目指すのではなく、不完全なコミュニケーションを管理することに重きを置くべきだと主張しているのです。


これは私がよく引き合いに出して説明する「仕様が決まっている問題」です。



顧客は「仕様は決まっています」「要求が固まっています」と言っています。一方、開発者は「そんなんじゃ何も決まっていなくて作れない」と言います。


私は何度もこのようなすれ違いの場面に遭遇しました。このような現象がまさにソフトウェア開発が創作とコミュニケーションの協調ゲームであることを証明しているのではないでしょうか。


顧客・開発者双方の専門性があり、使っている言葉(用語)、知識、経験、業界の慣習、企業文化といったさまざまなものが異なります。こういった中でコミュニケーションを行おうとすればそれは不完全にならざるを得ないのではないでしょうか。


私は「仕様が決まっているならウォーターフォールでいいんでしょ」というような意見に違和感を感じていました。反対に「要求が変化しやすいから」「VUCAの時代だから」アジャイルが求めれているといった意見もあります。本当でしょうか?


もちろんそういったこともあるかも知れませんが本質はそこではないような気がしています。


アジャイル開発が求められる理由は要求が変化しやすいといった外的要因ではなく、ソフトウェア開発(というゲーム)そのものが内在しているコミュニケーションの不完全性のためである説


冒頭にも紹介しましたように『アジャイルソフトウェア開発』は21年も前の書籍です。昨今、アジャイル開発のハウツーや外部環境の変化といったことが注目されることが多いですが、そもそもソフトウェア開発の本質とはいったい何なのか? あらためて問われているような気になりました。


[追記]

Agile Japan 2021アドカレ! Advent Calendar 2021 にも加えていただきました。

あやなるさんはじめ Agile Japan 実行委員のみなさま。今年も素晴らしい Agile Japan をありがとうございました。




(タイトル画像:Photo by Efe Yağız Soysal on Unsplash )


閲覧数:556回0件のコメント

最新記事

すべて表示