最近、開発方法論や組織論に関心をもっています。2020年改訂スクラムガイド を読んだり、実際に業務でもスクラムを実践している開発チームで働いています。しかし、まだスクラム開発者として働き始めて2ヶ月なので新人です。これまで私はスクラムを実践している開発チームで働いたことがなく、いま初めてスクラムチームで開発者として実践しています。とはいえ、チケット駆動開発 + イテレーション開発 は10年以上実践してきており、厳密な定義では正しくないかもしれませんが、広義ではアジャイル開発という枠組みで開発を実践してきたと私の中では捉えています。そして、私の周りでうまくまわっていないスクラム開発をみかける度にチケット駆動 + イテレーション開発でうまくいくのになぜスクラムのような効率の悪い開発をしているのか？とすら内心では思っていました。
本書を読み終えて、結論から言うと、これまでの私の考えは誤っていたことが分かりました。スクラム開発が悪いわけではなく、スクラムをうまく実践できていない開発チームの諸問題を、スクラムがよくないかのように私が誤解していたと補正できたことが、本書を読み終えて私が得た最も大きな収穫と言えます。
(2020年改訂版の) スクラムガイドでは意図的に抽象的な表現を用い、役割と会議体のルールを定めた軽量な開発方法論のフレームワークを提供しています。そもそもスクラムとは、それ単体でうまく機能するような方法論ではないと考えるのが正しいようです。組織の文化、顧客、開発対象・規模など、様々な状況において柔軟にカスタマイズできるようなフレームワークです。そのため、一口にスクラム開発というカテゴリに括ることはできても、それは組織や開発チームによって千差万別であると言えるでしょう。
したがって、開発方法論がスクラムであるかどうかはあまり重要ではなく、スクラムをベースにしてもしなくてもいいが、開発がうまくいくように創意工夫や改善をし続けることが重要であり、スクラムはそのための下地としてのフレームワークを提供するにすぎないということが本書を読み進めていくうちに理解できました。
このことは第3章で木下文彦氏が書かれた「2020スクラムガイド改訂とスクラムの3つの罠」というコラムからも伺えます。私がスクラム開発を誤解していたように、スクラムを適切に実践できていない開発チームの特徴を3つの罠として述べられています。これまで私はこの3つの罠に陥っているようなスクラムチームを傍からみていて違和感を抱いていたと言えるでしょう。
3つの罠から1番目の例を取り上げると、デイリースクラムが形式的に情報を報告するだけになっているチームがあるとコラムの中では指摘されています。本来のデイリースクラムの目的は状況に合わせた再計画であり、形式的な報告はその副次的なものです。こういった目的を理解せずにただガイドに書いてあるからと状況報告するだけのチームも増えたのだろうと推測します。
余談: デイリースクラムのトレードオフ
私はデイリースクラムが現代の開発方法論において開発の生産性とトレードオフになっていると考えています。
まずデメリットから述べます。スクラムガイドではデイリースクラムを15分のイベントと定義しています。毎日15分会議してなぜ生産性が落ちるのか？と思う人もいるかもしれません。私が課題意識をもっているのは時間の長さではなく、チーム全員を毎日同じ時間に集めるという同期的イベントの発生そのものに懸念を抱いています。同期的イベントのデメリットとして次のようなことが考えられます。
- 集中して作業をしていても強制的に中断させられる
- 同期的イベントの前後30分ぐらいは集中力を要する作業がやりにくくなる
- 様々な理由でチーム全員集まらないことがままある
まずデイリースクラムを何時に開催するか？という大きな課題があります。朝10時にしているところも多いのではないかと推測します。私は朝型なので平均して8時ぐらいから始業しています。そうすると、集中して作業をしていても必ず10時に作業の手を止めなくてはいけません。そして夜型の人にとっては10時に参加することが難しいメンバーもいます。そういう人は遅刻したり午前半休することが常態化してしまうこともありました。13時にすればよいのでないか？となると、急ぎの報告をしたいときに13時では遅いため、デイリースクラムの前に打ち合わせをしてしまい、デイリースクラムを必要としなくなってしまう状況も起こりがちになります。こういう指摘をすると、朝会と夕会をやろうと言い出すマネージャーが現れたりして、さらに会議を増やすのかと私のような開発者はうんざりするわけです。とくに実務をやらないマネージャーほど、会議を増やすことに抵抗がなく安易にそういった提案をする傾向があるように思います。
またデイリースクラムという1日1回しかないイベントでしか進捗を報告しないメンバーの問題もあげられます。チケット駆動開発に慣れた開発者からみると、これでは報告が遅過ぎるように感じるのです。問題や懸念が発生した時点でチケットにその状況を記載し、それをマネージャーやメンターがみていれば、その時すぐにアドバイスや対策を検討できます。しかし、デイリースクラムでしか進捗報告をしないメンバーがいると、1日1回しかアドバイスや対策を議論できなくなってしまう懸念があります。それはメンバーの問題でしょうと思う方もいるかもしれません。しかし、私は知人からもこういった話しをたまに聞くため、特殊なケースではないと考えています。とくにメンバーのスキルが未熟なために誤った考え方や作業方針で進めてしまっている場合、1日1回の進捗報告では訂正がやりにくい状況というのがあります。スキル不足が原因の場合、メンバーは誤っているという気付きがないために報告できないのです。チケット駆動開発であれば、発生時に状況を伺う内容がコメントとして記載されるため、マネージャーやメンターがより迅速に状況を把握して訂正していくことができるのです。
ここからはデイリースクラムのメリットを述べます。スクラムを支持している方も安心してください。当然デメリットがある一方でメリットもあります。繰り返しますが、本来のデイリースクラムの目的は状況にあわせた再計画にあります。
想定外の状況が発生したため、スプリントのタスクを見直したり、ゴールを変更したりすることを比較的早いタイミングでメンバー全員で確認・合意できるところにあります。また先ほど、私がチケット駆動開発ならば書き込まれたコメントから状況を把握できると言いましたが、これをすべてのメンバーができるとは限りません。自分がやっていることを文章として書き表せるというスキルは、私が思っていたよりも習熟を必要とするスキルであり、開発者であっても全員ができるというわけではないことが経験則から分かってきました。書くスキルに加え、自ら情報発信するのが苦手なメンバーもいます。そういったメンバーは書くよりも話すことで情報共有できるデイリースクラムという場が唯一の救いであり (一方で義務でもあり)、聞かない限り状況を伝えるのが苦手なメンバーでも協働しやすいプラクティスと言えます。
さらに本書を読み進めることで著者の野中氏がナレッジマネジメントの古典となっている考え方として SECI モデルを説明しています。そして、SECI モデルの 共同化 (Sociallizatoin) がプロジェクトの起点であり、個人の暗黙知を他人や組織の暗黙知に伝えていくことの意義や重要性を説いています。起点が暗黙知であるならば、それはチケット駆動開発のようなコメントや文章として書くことはできないのです。
スクラムのイベントが多いのは個人の暗黙知を他人や組織の暗黙知に伝えていくための装置でもあるように私は受け取りました。そして、デイリースクラムもその暗黙知を伝えるための役割の一端を担っているはずです。だからこそ、儀式的に進捗を報告するだけのイベントには意味がなく、個人の暗黙知を伝える共同化という活動を促す必要があるのだと私は理解しました。
つまり、デイリースクラムは直接的には状況にあわせた再計画という目的をもちながら、中長期的には共同化という知識創造につながるプロセスも組み込まれているのです。単純に開発の生産性だけを理由にデイリースクラムは非効率だと断じるのは適切ではないと、本書を読み終えて私は考えています。
前置きが長くなりました。ここからは本書を読んで私が関心をもったところを抜き出して紹介します。
スクラムの起源と知識創造と組織
ソフトウェア開発方法論としてのスクラムはジェフ・サザーランド氏らによって定義され、スクラムガイドによってまとめられています。一方でそのオリジナルと言えるコンセプトは、野中氏と竹内氏が1986年にハーバード・ビジネス・レビューに掲載した The New New Product Development Game という論文になります。この論文はスクラムの直接の参考文献であり、スクラムの理論的基礎にもなっているそうです。
本書の「第10章 竹内・野中のスクラム論文再考」には野中氏と竹内氏のオリジナルの論文とソフトウェア開発方法論としてのスクラムの対比や考察が行われています。1986年という、日本の製造業が強かった時代に書かれた論文なので、いまとは全く時代背景が異なります。その時代背景も考慮しながら現代のスクラムとの共通点を見い出すことは、普遍的価値や概念を推し量る上でとても意義のあることだと私は思いました。さらに歴史を振り返ることでその是非を検証することもできるかもしれません。いま考えたことややっていることが正しいかどうか、本当の意味では、時間が経ってから歴史を振り返ることでしか検証できません。そして、オリジナルの論文とスクラムの間には多くの共通点があり、その意図している目的や概念を理解することでスクラムが意図する目的の理解もより進みます。
野中氏は2010年までこの論文のコンセプトがソフトウェア開発方法論として使われていることを知らなかったそうです。野中氏は組織や組織的知識創造理論の研究者であり、氏の理論が実際のソフトウェア開発の中でどのように発展してきたか、どのように要項が取り入れられているかなど、氏の研究にも意図せぬ相乗効果を生み出しているように私は読めました。そのため、スクラムの今後の発展形や拡張を推し量る上で野中氏の理論を学ぶことにも大きな意味があるように私は考えています。
また Scrum Inc. CEO であるジェフ・サザーランド氏のインタビューも本書の中で紹介されています。ジェフ氏はオリジナルの論文を1993年の終わりに作られた開発チームに取り入れたそうです。チームリーダーをスクラムマスターと呼び、機能横断チームを採用しましたが、最初はそれだけでは大きな変化をもたらさなかったように答えています。そして、第2スプリントでデイリースクラムを取り入れたらすごくうまくいき、第3スプリントでは生産性が最初の2回のスプリントと比べて400%にアップし、1ヶ月の仕事を1週間でやり終えたことが語られています。そして、そもそもジェフ氏がスクラムを体系化しようと考えた動機にも触れており、それは後半の実践知リーダーシップとはどういうものかにも係ってきます。
本書の前半では、ソフトウェア開発プロジェクトの背景や難しさ、スクラムの方法論やアジャイル開発における様々なプラクティス、大規模スクラムの話題などが書かれています。そして、中盤に事例紹介があり、後半は知識創造の背景や方法論について述べられています。とくに 実践知 という概念について説明されているところに私は関心をもちました。
実践知とは、アリストテレスが フロネシス と呼んだ概念であり、暗黙知と形式知との両方で構成されるものであると説明されています。そして、そこに身体性を伴っていないと実践知とは呼ばないというやり取りも野中氏のインタビューで話されています。「第12章 スクラムと実践知リーダー」を読んだだけでは曖昧だった実践知という概念が、その後のコラムやインタビューでのやり取りから、私はより理解できました。実践知は、考えることと行動することがセットになっており、自分の頭の中で考えているだけでは得られないものであることが明言されています。昔は 知行合一 と呼ばれていたものですが、90年代以降の日本は分析過多、計画過多、コンプライアンス過多になってしまい、そのことを忘れてしまっているという件には納得感がありました。
野中氏は日本的経営の強みとしてミドル層、中間管理職の存在をあげています。過去の日本においてはトップと現場に間の独特のポジションが政治力や知識の共有に影響力をもっていたと言います。そして、日本からイノベーションを起こしていくためにミドル層の役割が重要だとも話されています。しかし、この点だけは私は同意できませんでした。1980年代の日本においては中間管理職が大きな役割を担っていたかもしれませんが、私の経験からは中間管理職を不要とする組織を目指すべきではないかと考えています。中間管理職の大きな役割の1つにトップの考えや方針を現場に伝えることがあります。これは口頭で議論できる人数という物理的制約を伴うコミュニケーションパスの問題から組織階層が生まれたのではないかと思います。そして階層型の組織には情報の非対称性というとても厄介な問題があります。情報の非対称性は組織の理不尽を増大させてしまいます。だからこそ中間管理職が重要だという主張も理解はできますが、ICT 技術が発達した現代では別の解決策があるのではないかということを追求したいと私は考えます。その答えがティール組織やホラクラシーであるかどうかはまだわかりません。
合宿をしなさいという解決方法
「おわりに」という最後の結びに野中氏のこんなエピソードが紹介されています。2011年にジェフ氏とガブリエル氏がスクラムのトレーニングを日本で開催し、その際に平鍋氏と野中氏が飛び入りで参加したそうです。そして、参加者からの質問に対して野中氏が次のように回答したやり取りが紹介されています。
「プロジェクトには、営業部門、マーケティング部門、サポート部門など、いくつかの部門のステークホルダーがいるのです。そして、どの機能を優先すべきかについて意見が分かれているのです。意見を1つにまとめるには、どのようにしたらよいのでしょうか」
「合宿をしなさい」
「形式的な会議で決めることはできない。いろんな背景をもった人の集合において、形式知で語れること、理解し合えることはごく一部だ。合宿をし、一緒に飯を食い、泊まって徹底的に話しをする。そうすると、形式知は脱ぎ捨てられ、自分の主観で話すようになる。そこで、なぜこのプロジェクトに自分が参加しているのか、という根源的な問いにまでたどり着けるだろう。そこから初めて、1つの共通理解が生み出される。この過程をみんなで踏みなさい。」
この回答がどのような組織や状況においても正しいとは私には思えません。しかし、この回答は決して私が自分の言葉では語れない類のものであり、野中氏の唱える実践知リーダーシップがどういうものかを物語る一例として、私は衝撃を受けました。平鍋氏はこのことを伝えたいというのが本書を執筆した動機と書いており、その衝撃も理解できます。
一般論としてはなにかしら定量的な論理や多数決などで決めがちな難しい問題を、形式知では決められないと早々に認め、全く非論理的な解決方法を簡潔に提示しています。データサイエンティストが読んだらぶっ飛んでしまうのではないでしょうか。このような決め方に反発する人もいると思います。私もどちらかと言えばそちら側の方です。
おそらくこの手法の成否はリーダーとメンバーの関係性に依るのではないかと私は思います。最終的には論理ではなく、このリーダーに任せようという主観的な判断がメンバーに広がっていって結論を見いだせるように私は受け取りました。したがって、合宿そのものはその装置の1つであって、最終的には人間関係が決め手であり、チームまたはプロジェクトがよりよい関係を築くには実践知といった概念が不可欠になってくるのでしょう。
実践知の話題は心理的安全性や認知心理学の知見ともいくつか合致するところがあるように思います。合宿という手段を用いなくても、スクラムの中でそれに近い状態を再現できるようにしていくことが今後のスクラムを発展させていくということにもつながるのではないかと私は思いました。
