アジャイルはソフトウェア開発の手法や原則に留まらず、ソフトスキルの一種と言えると思います。
ウォーターフォールを計画主義またはプロセス原理主義とするなら、アジャイルは探索主義とでも言えるでしょう。計画やプロセスといった「仕事のための仕事」にとらわれず、さっさと探索して学びを得ることを優先します。
※もちろん探索だけではすべての仕事をカバーできません。探索して「見えてきた」後は、しっかりと遂行するフェーズに移る必要があります。このフェーズは探索では難しいです。
エンジニアの皆様は、おそらく日頃からアジャイルに取り組まれているでしょう。「私は身に付けているはずだ」と思うはずです。
本当にそうでしょうか？
ここで言っているのは、ソフトスキルとしてのアジャイル です。開発におけるそれではありません。仮に開発者としてアジャイル開発をしていたとしても、ソフトスキルとしてのアジャイルはできていない可能性があります。できているかどうかの確認（※一つの目安です）は、以下本編をご覧ください。
このアジャイルというソフトスキルを言語化するのは容易ではありません。もちろん、私達エンジニアが使っているものをそのまま伝えたところで、専門的すぎますし特化も強くて汎用的ではない。
そこでソフトスキル・エンジニアリングの出番です。現役のエンジニアであり、この概念の提唱者でもある私自ら言語化をしてみました。
アジャイルらしく、さっさと言語してみたものです。
カジュアル・アジャイル とは、ソフトスキルとしてのアジャイルを整備したもので、その名のとおりカジュアルにアジャイルを実践するための TIPS です。
今のところ、私が整備したものを 5 つ挙げていますが、他にもありえます。というより、エンジニアの皆様で集めていくといいのではないかと思います。awesome list じゃないですが、オープンソースでリストにしてみたいですね。もちろん、チームや組織の中で整備するのもアリです。組織ごとのカラーが出るでしょう。
では、挙げていきます。
アジャイルの流れは 3R に当てはめられます。
Rough Plan では、ラフな計画をつくります。「大体こんなことをする」くらいのラフさでいいです。Excel やスプレッドシートは登場せず、テキストで済むはずです。シートが登場した場合は黄信号です。
次に、Rough Plan を参考に、実際に進めていきます。考えを洗い出したり、議論したり、ドキュメントを書いてみたり、もちろん実装もあります。ひょっとすると知識が足りないからと書籍の読解、関係者へのヒアリング、その他リサーチをするかもしれません。とにかく思いついたことは何でもやります。主体性を発揮します。Rough Plan はあくまで参考なので、別にこの通りにできなくてもいいです。
最後に Retrospective です。Run を終えた後に振り返りをして、次はどうするかを考えます。これを 3R サイクル と呼びます。
3R サイクルは、一言で言えば「大体何するかを決めて、きりのいいところまで動いてみて、その結果どうだったかを振り返る。これを繰り返す」です。
生成 AI もわかりやすいと思います。おそらくラフにプロンプトを投げて、それをベースにあれこれ試行錯誤して、きりがいいところまで進んだらいったん振り返ると思います。同じようなものです。
メッセージや資料を見てもらうときの話ですが、従来は人間がしっかりつくっていたり（パワポ）、雑につくったりしていました（プレーンテキストやノートの1ページ）。そうではなく、生成 AI につくらせたもの、特にチャットのセッションをそのまま見せることもできます。
これを Mechanical Style と呼んでいます。
アジャイルは探索的なものなので、案外 Formal や Rough でなくても良かったりします。AI のチャットセッションを見てもらうだけでも学びはありますし、微細なニュアンスも伝えられます。そもそも チャットセッションを見ることすらできないほど受動的な人に、アジャイルは務まりません。
これはアジャイルという探索行動ができるかどうかを測る目安にもなります。
エフェクチュエーションというアジャイルな理論があります。これは 5 つの原則を提示しており、その一つに 許容可能な損失（Affordable Loss） があります。リソースに対して「ここまでなら最悪ドブに捨ててもいい」というラインを設定した上で、この分を一気に与えるのです。つまり 使い放題 ですね。
このシンプルな考え方は、アジャイルと相性がいいです。使い放題なので管理が発生しません。Affordable Loss 分のリソースを与えたということは、その時点でもうそのリソースは捨てたようなものなのです。リソースの管理者としてはやりづらいかもしれませんが、アジャイルに動く側としてはこれほど嬉しいことはありません。探索に必要なのは自由だからです。管理は邪魔です。
ティール組織に 助言プロセス の概念があります。
これは以下の二つから成ります。
従来だと助言者≒上位者であり、助言という名の命令になりがちでした。そうではなく、助言プロセスでは 助言者に意思決定権はありません。つまり、助言を受ける担当者が自ら意思決定できるのです。たとえば、助言が微妙だと思ったら無視してもいい。
しかし、担当者の独断専行を防ぐという意味でもガードレールは敷きます――つまり助言自体は必ず請いましょう、との原則をつくります。これは思っているよりも重要で、ティール組織ではしばしば「助言を意図的に請わない姿勢を続ける者は解雇の対象となる」とのルールをつくるくらいに根幹です。
開発者体験の重要性は認識されています。また私はBeyond Productivity: Embracing Experiencityという記事を書きました。ウォーターフォールが時代遅れとなったように、管理もまたそうなりつつあります。
この感覚を端的に表現するのが、この 管理よりもモニタリング です。
モニタリングとは以下を二つとも満たします。
自動計測については、人間が記入したりヒアリングしたりするのではなく、勝手に計測されるという意味です。なぜ自動にしたいかというと、人間が手で日々記入するのは面倒かつ不正確だからです。形骸化しやすいのです。といっても、常に自動化できるとは限りません。
たとえば Engineering Effectiveness の一環で「割り込まれた回数」をモニタリングしたい場合、これを自動で記録するのは難しいでしょう。たぶんシンプルなボタンなどを用意してカウントすることになるはず。
次に因子ベースについては、計測指標をノルマにしない ということです。ログと言っても良いでしょう。あとで振り返るときに見て参考にする「因子」でしかありません。KPI のように目標にして、それを満たすために死に物狂いで頑張りましょうといったことはしません。
ソフトスキルとしてのアジャイルとして、カジュアル・アジャイルを紹介しました。
特に私が整備した 5 つの TIPS をお届けしました。アジャイルの本質を何となく理解できるのではないでしょうか。皆さんもぜひ自分なりの、組織なりのアジャイルを開拓してみてください！それではまた。