
あの「Code Complete」のマコネルさんの、アジャイル指南・・・というよりも2010年代を通過してソフトウェア開発の手法はどのように進化してきていて、マコネルさんのコンサル会社がどのようなケースを見聞きして、その結果として彼が考える「現代のソフトウェア開発のベストプラクティス」とは何かということを語った本です。
2000年代には、それまで軽量プロセスとかイテレーショナル開発とかいろいろな呼ばれ方をしていた知見を「アジャイル」という言葉の元に束ねて、アジャイルとはいかなるものかの試行錯誤が行われました。その頃には、従来の手法とは別にアジャイルという新しい手法が生まれた様に見えていましたし、案件の性質によって使い分けようというような動きもありました。しかし、2010年代には従来のソフトウェア開発の手法の問題を克服するために生まれた次の手法がアジャイルだということがはっきり示され、それ以外の手法で使うための新たなメソッドやツールを生み出す動きが潰えました。つまり、「ソフトウェア開発のベストプラクティス」とは、イコールとしてアジャイル開発のことであり、結果としてこの本はアジャイルの本といって過言ではないです。タイトルに偽りなし。
ただし、この本が「アジャイルという新しい考え方を説明し、普及する」という視点ではなく、あくまで2010年を通過して今あるソフトウェア開発の手法のベストについて語るという本であることは重要で、つまりはアジャイルが正道となった世界で、我々はどうしていくのかという本です。
もちろん、私たちみんながアジャイル開発をやっているわけじゃないし、「正しい」アジャイル開発を出来ているわけでもありません。それは20世紀に誰しもが「正しい」ウォーターフォール開発を出来ていなかったのと同じです。どちらにしろ、開発手法を理解し、そこで起きうる問題を把握し、対処し、その手法の目指すところを体現できているかどうかというのは、ものすごーくムツカシイことです。
というわけで、なんか新しいことが書いてあるわけでもなんでもないですが、短いページ数(日本語版でも300ページ未満です)にエッセンスがぎちっと詰まっていて、取り上げたい知見や、引用したい名言に満ちた本です。すべからく読むべき。特に、アジャイル開発におけるリーダーの役割についての言及が素晴らしい。まあ、書いていることがソフトウェア開発手法で、それはつまり「管理手法」なんだから当然なんですが、もう、耳が痛いことがびっちり書いてあります。知識の整理にはぴったりだし、アジャイルを開始するとっかかりとしても良い本。私も「ちゃんとしたスクラムができた」と感じたプロジェクトはまだ出来てないんで、ちゃんとしたいですね。なかなか状況が許しませんが。
というわけで、以下は読み終わった本のページをめくりながら、面白いなと思ったところをピックアップしておきます。
Cynefin
3章。聞いたことがない概念がでてきて、意外とこの本の最後まで使われます。IBMにいた人が作ったフレームワークで、「クネビン」と読むそうです。

図の通り、5つのドメイン(系)があって、問題はどこかに分類されると。で、分類された位置によって異なるアプローチがされるべき、とCynefinでは言ってます。詳しくはWikipediaでも。
で、はしょりますが、ソフトウェア開発で相手にすべきなのは図の上の2つ。「複雑(Complex)」と「煩雑(Complicated)」だと。カオスはソフトウェアで解決しようとすんなと(笑)。では、上の2つに対してどうアプローチすべきかというと、
複雑:調査(probe)-把握(sense)-対処(respond)
煩雑:把握(sense)-分析(analyze)-対処(respond)
はい、ピンときましたね。アジャイルにおいて最も重要なことはリリース間隔が短いことなわけですが(「LeanとDevOpsの科学-Accelarate」を読んでね)、それはつまり複雑なドメインに対するアプローチだからです。短い間隔でリリースして、フィードバックを得る。そしてそれに対して次のリリースで対応する。「調査-把握-対処」ですね。
それに対して従来のソフトウェア開発手法、この本ではシーケンシャル開発と呼んでますが、それでは、様々な要求をかき集めてきて、それを分析して、モデリングして、アーキテクチャリングして、ソリューションを作り上げている。つまり、煩雑系に対してアプローチしているわけです。
で、ソフトウェアで解決しようとしている問題があって、その多くは複雑なのか煩雑なのか。複雑だと思ってたら煩雑だったことがわかった場合、「とりあえず、やってみようぜ」とトライして行った調査・実験はムダだったということになります。ちょっとショック。しかし、煩雑だと思ってたら複雑だった場合、プロジェクト終盤に「あれ、やろうとしてたこと間違ってね?」となる。これは致命的なショック。なので、ソフトウェア開発は、まずは対象を複雑系だと考えてアジャイルに取り組み、煩雑系だとわかったらそれに対処する(その部分に対しては、きっちり問題を分析して組み立てるシーケンシャルな開発へシフトする)方がよい。だから、アジャイルなんだよーと言ってます。なるほどね。
スクラムから始める
アジャイルやりてーなと思ったら、とりあえず、スクラムをやれ。アジャイルうまくいかねーなと思ったら、とりあえず、きっちりスクラムをやれ。スクラムから取捨選択をするな。なぜなら、アジャイルには膨大なプラクティスが存在するが、そこから最小限のプロセスを使って作られたフレームワークがスクラムだから。これ以上省くことは許さぬぞ、とマコネル先生の教えです。ワカル。
スクラムがダメっていう奴はだいたいちゃんとやってない奴なんだよねーということで、4章ではスクラムの様々な失敗モードが紹介されてます。「無能なプロダクトオーナー」とかいう節があって、読むと心が痛い。ちなみに、今までみたダメスクラム傑作例は
「スクラムを検討してみたが、そのプラクティスのほとんどは私たちの組織ではうまくいかないようだった。私たちはスクラムを実践しているが、主に導入しているのはデイリースタンドアップで、毎週金曜日に行っている」
だそうです。ウケル。
チーム文化
6章はチーム文化に関する章です。文化の問題はものすごく大事で、これこそがチームの生産性の要なんだけど、わかってないリーダーが多すぎ。マコネル先生曰く「企業は事実上、人々の脳内のスペースを借り上げ、企業が従業員に考えさせたいことを考えて貰うために賃金を支払う。外的モチベーションがうまくいかないのは、何かについて考えることを人に強制させるのは無理だからだ。あなたに出来るのは、企業の問題について自主的に考えたくなるような状況を整えることくらいである。」
まったくその通りなんだけど、やって欲しいことが「考えること」ではなくて「作業」だと思ってるクズリーダーが多すぎる。そのくせ、「作業」の結果上がってきたアプトプットの品質が低いと怒るわけですが、やってることがソフトウェア開発なんだからそこに「考えること」が含まれてなければ品質が低いのは当たり前なわけです。では、「考えること」のために何をやっているかというと、モチベーションを削ぐことしかやってない・・・みたいなね。
では、内的モチベーションの向上には・・・ということについては、当たり前だけど大事なことが本に書いてあるので是非読んで下さい。
分散チーム
はい、リモートワークの話です。で、おわかりの通り、チームのロケーションを分散させることはダメだよと書いてあります。まあ、その通りですな。ここで面白かったのは、以下の部分
ここで重要になるのは、定期的に直接会ってコミュニケーションを取ることである。あるグローバル企業の最高幹部は、「信頼の半減期は6週間だ」と言っていた。ミスが増えてきたと感じたら、メンバーを飛行機に乗せ、一緒にゲームをさせ、一緒に食事をさせることで、信頼関係が築かれるようにしよう。
6週間かー。つまり、緊急事態宣言でリモートワークになって本当にうまくいく仕組みが作れているかどうか、勝負は6週間経ったあとって事です。確かにねー。
個人および対話
アジャイルはこれまでプロセスの話に注力しすぎて、個人の能力開発にはあまり取り組んできてません。これは従来の開発プロセスでも同様で、個人が仕事を通じて成長することを求められているのはどこの組織でも同じだと思いますが、それが個人を受け入れるプロジェクト側では基本的に何も考慮されておらず、必要な知識やスキルを身につけられるかどうかは個人の(プロジェクト外での)努力と運に左右されているというのが現状です。しかし、アジャイルが必要とする「自律したチーム」は個人の能力に大きく影響を受けるんですから、個人の能力開発に注力するのは当然。8章はこのことに大きく記述が割かれてます。
ま、とにかく個人の成長に対して組織はもっと投資をしないといけないって事です。こんなインターネットミームが引用されてます。
CFO: メンバーに投資して、彼らが辞めてしまったらどうするんだ。
CEO: メンバーに投資せずにいて、彼らがいつまでも辞めなかったらどうするんだ。
ウケル。でも、これは自社の社員に対してはその通りでしょうが、現状、我々は外部の人員を含めてプロジェクトをしていて、これが社外の人間(つまり、長くてもプロジェクト終了時点でいなくなる人)に対しても同じように対応するべきなのかは疑問。ここは大きくやり方を変える必要があるところです。
また、開発者に求められる対話の能力やチーム内の対話の重要性にも触れられてます。これは自分がどうかというよりも、リーダーとしてメンバーをどう向上させるかという観点に立つとより重要です。ここをケアしているリーダーはまれですが、とにかく重要なんですよねぇ。
バーンアウトの回避
リリース間隔を短く保ち、スプリントを繰り返して成果を出すアジャイル開発のリズムは基本的にはいいものだけども、「締め切り前に頑張って、締め切りが過ぎたらリラックスする」という起伏がないことによって、かえってバーンアウトを誘発することがあるといいます。なるほど。確かにぱつぱつのスクラムしんどい。
そこで著者は6×2+1パターンなど、一定じゃないリズムを使うことも提案してます。2週間スプリントを6回やったら、1週のスプリントを1度はさみ、そこでは技術的負債の返済やツールの見直し、研修、チームビルディング、ハッカソン、日々の改善などをやると。これ良いですね。
要求の改善
シーケンシャルな開発手法では、最初に要件定義をしてしまい、その要件定義の品質が後々まで影響します。要求管理は非常に大事。ただ、私の感覚としてはシーケンシャルな開発においては、失敗の原因を要件定義フェーズの品質に求めすぎている気がしますけどね。要件定義が不明確だったが為に、後続のフェーズで時間がかかったり、手戻りが発生したとして、ではそれを要件定義もっとリソースをかけて回避すべきだったかどうかは疑問です。だって、後続のフェーズで必要となったリソースを前のフェーズで使ったとして、それはリソースの総量の削減になっているかどうかはわからないから。ただし、要件定義フェーズでのアウトプットを元に後続フェーズで必要となるリソース総量を見積もって、それが間違っていてエラいことになったということはあるかもしれないですが、それは単に契約形態の問題で、プロジェクト全体から見たら本質的な問題じゃないからね。
アジャイルの最も重要な点は、リリースサイクルを小さくして、一度に必要とする要求の量も小さくして、コントロールしやすくできることにあります。ただし、プロジェクト全体のリスクとしてはそれで改善されているけども、1つ1つのフィーチャーについて要求の品質が高いか低いかが出来上がるフィーチャーそのものの品質に直結することはシーケンシャル開発だろうがアジャイル開発だろうが同じ事です。ここまでユルユルでいいと誤解してアジャイルを捉えている人が実に多い。それは間違いです。
で、要求について、アジャイルだからシーケンシャルだからというのは無くて、むしろ、アジャイルは要求管理の改善の1手法であるわけです。従来の要求管理の手法には改善が必要なことは誰しもわかっているわけで、その連続的な改善の取り組みの1つがアジャイルであり、バックログ管理のようなアジャイルのプラクティスだと。
で、この分野は大変ホットなので、この20年で様々な取り組みがなされてきてて、下のリストに上がってる単語を聞いて「何それ」と思ったら勉強不足だから補えよとマコネル先生は仰ってます。はーい。
- 受入テスト駆動開発(ATDD)
- ビヘイビア駆動開発
- チェックリスト
- コンテキスト図
- エレベーターピッチ
- エクストリームキャラクター
- 5つのなぜ(five whys)
- ハッスルマップ
- インパクトマッピング
- インタビュー
- ラダリング法による質問
- リーンキャンバス
- MVP
- ペルソナ
- Planguage 言語
- プレスリリース
- プロダクトビジョン
- プロトタイプ
- シナリオ
- ストーリーマッピング
- ユーザーストーリー
ふぅ、いっぱいあんね。
リーダーシップ
16章ではリーダーシップについて。この本を通じて何度も出てくる原則は「スクラムチームをブラックボックスとして扱う」ということ。マイクロマネージメントを避け、インプットとアウトプットだけを管理しないと自律したチームは作れません。リーダーに出来るのは仕事の仕方をあれこれ指図することじゃなくて、せいぜいメンバーのモチベーションを上げることぐらいなわけです。辛い。「チームの生産性をどうやって上げれば良いか決めるのもチームなので、メンバーの1人が1日休めばチームの生産性が最も良くなる可能性があるとしたら、チームがその決定を下すのは自由である」とも書いてあり、リーダーはせいぜいその可能性を指摘したり、チームの決定を尊重したりとかしか出来んわけです。
もうひとつ、リーダーが大事なこととして「司令官の意図」を伝えること。これはアメリカ軍の概念で、司令部と部隊の間の連絡や協議の機会を失った状態で、部隊が意思決定を出来るようにしておかないといけないっちゅうことですね。「人にやり方を教えてはいけない。何をするのかを伝え、その結果であなたを驚かせるように仕向けるのだ」というジョージ・S・パットンの言葉が引用されてます。しみるね。まあ、この本はリーダー向けの本なので、16章は短いながら重要なことがたくさん書いてあります。
間違いを犯す
アジャイルの短いリリース間隔に期待することは素早いフィードバックであって、それはつまり、やってたことが間違ってたということが早くわかると言うこと。必然的に間違いを許す組織文化が必要になります。で、せっかく間違いによって得られた知見なので活かさないといけない。というわけで、以下の様なことが重要
- 直すのが大変にならないうちに正す
- エスカレーションを許す
- 心理的安全性を高めておく
- 知見を共有するプラクティスコミュニティ(例えば、スクラムマスターのコミュニティなど)を確立する
心理的安全性は一種のバズワードのようになりましたが、これは全てのリーダーが考えねばならぬこと。文化大事ですよ。ほんとに。
生産性の向上
このことがあんまりプロジェクトで真面目に考えられているところを見たことがないけれども、チームの生産性向上はとても大事。だいたいは、「今週は進捗よくないです。でも、作業に慣れてきたので、今後は大丈夫だと思います」的なところでいい加減に語られてしまいがちだけれども、まあ、それはそもそも生産性を測定していないんだからしょうがない。まずは測定が大事です。チームのベロシティはちゃんと測りましょう。
その上で、プロセスの改善をする。ツールを変えたり、バックログリファインメントの精度を上げたり、必要なメンバーを追加したり・・・それをちゃんとスプリントごとに改善することが大事です。
面白かったのは、「チームの生産性が向上すると何が可能になるか」という項目。引用します。
短いスプリントは、プロセスを実験的に変更し、それらの変更の結果を追跡し、うまくいく変更を足がかりにする機会を頻繁に提供する。このようにして改善がどんどん蓄積されていく。私たちはこれまで、チームの生産性が2倍かそれ以上になるのを実際に見てきた。
このことには思いもよらない意味合いもある。というのも、パフォーマンスが悪いことを理由に「問題のあるチームメンバーを多数決で締めだそう」とする場面を何度か目撃したことがあるからだ。どの場合も、事の顛末はだいたい同じである。「あのメンバーを異動させたら同じベロシティを保つことを確約できるか」とマネージャーが尋ねると、チームはこう答える。「あの人が足を引っ張っていた分、ベロシティがよくなることを確約しますよ」
もう1つの例は、チームが2つの拠点(サイト)に分散しているデジタルコンテンツ会社と仕事をしていたときのことである。1つ目のチームは15人のメンバーで構成され、2つ目のチームは45人のメンバーで構成されていた。ベロシティを厳格に追跡し、作業の進捗を監視し、その待ち状態を分析したところ、1つ目のチームが2つ目のチームとの連携に費やしていた時間と作業量だけで、2つ目のチームの作業量を超えているという結論が下された。そこで、2つ目のチームを別プロジェクトに回したところ、1つ目のたった15人のチームだけで元のプロジェクトの総生産量が増加した。1つ目のチームはアジャイルの生産性の指標をきちんと使用することで、生産性を実質的に4倍に増やした。
ツラい。でも、わかるなー。1つ目の話も、2つ目の話も、なんとなく実感があります。うーむ。
予測可能性
20章は見積の話。アジャイルは見積が出来ないと考えている人がたまにいるんですが、全然そんなことはなくて、プロジェクトの開始前でもシーケンシャル開発と同程度の「不確かな見積」は可能です。つまり、どちらの手法もある程度の仮定、つまり不確かさを認めてしまうなら、その不確かさを含んだ予測はできるわけです。だって、タスクを見積もって積み上げるだけならどっちだって出来ますよ、そりゃ。
アジャイルでそれがあまり重視されないのは、いくらかのスプリントを経ればその不確かさをすぐに小さくできるから。であれば、その不確かな見積になんか意味あるの?となると。で、通常はもの凄く意味はあって、不確かな見積が無ければプロジェクトはスタートしないんで、プロジェクト開始後に得られるより正確な見積に意味なんかないわけです(笑)。
マコネル先生はプラクティカルな人なので、もっと予測可能性が求められるときにはどーしたらいいのかという議論をきっちりやってます。見積の不確かさの管理方法はもちろん、
- エピックを予算として扱う
- 予測可能な範囲を考慮してアジャイルの境界を移動させる
など、言われてみればもっともだし、部分的にはやってるようなことをきっちり手法にしてあるので、エラいですね。
また、プロジェクトのスケジュールの管理のためにはポートフォリオの管理が凄い重要で、WSJF(Weighted Shortest Job First)の手法が紹介されてます。これ、有名らしいけど、知らなかった。フィーチャーそれぞれについて、それがないと発生するコストを見積もって、その合計が最小になるようにフィーチャーの優先順位を管理する方法です。これはそのまま自分たちで使えるかどうかはわからないけど(例えば、発注機能のこのフィーチャーがないとユーザーはどのぐらい時間を損するんですかって聞いて回っても、すぐに有効な数字が貰えるわけではないだろうし)、でも重要な視点だな。




Recent Comments