壁を打ち破れ！ - アジャイル開発とスクラムを読んで -

良書と呼ばれるものには、メッセージ性の強いもの、入門でありながら深いところまでかたるもの、網羅性の高いもの、色々な読み方ができるもの、など色々なパターンがあると思います。

この本は、「おわりに」にある様に「実践知リーダーシップ」というメッセージを中心に書かれていますが、基本から実践までが語られていて、色々な読み方ができます。著者らの思いとは少しずれているかもしれませんが、感じたままに感想を書かせていただきたいと思います。

私が感じたのは「実践知リーダーシップ」に必要な共同化を実現する「壁を打ち破る」ことが大切だと言う事です。この本を読み出したとき、「そもそもアジャイルとは何か」「スクラムでないとできない事は何か」など、ついつい曖昧になりがちな言葉の定義ではなく、そこで大切にされているものを知りたいと思いました。

オリジナルスクラムと壁

この本はアジャイルスクラム開発の本と言うよりは、事例やオリジナルのスクラムを通してアジャイルスクラムを見直している本だと思います。野中さんがオリジナルのスクラムの解説とそのアジャイルスクラムのマッピングをされていますが、所々、気になるところが出ています。

もちろん、アジャイルスクラムを応援されていますが、それよりも大切なものがオリジナルのスクラムにある様に思いました。それが、壁を打ち破り、知識を共同化し、 実践知リーダーシップ を発揮する事だと思います。

最初に「壁」が出てきたのはセールスフォース・ドット・コムの事例です。アジャイル開発の説明でありながら、この事例は組織の壁(p.24)を取り除いたのでうまくいったと思います。また、リクルートの事例でも組織の壁について語られています。

この壁と言うものは、ソフトウェア開発の最大の敵です。タスクカードを貼って情報を共有する場合には、壁はとても魅力的です。しかし、ステークホルダーの間に立ちはだかった場合には、プロジェクトの透明性が失われ、コミュニケーションが阻害され、対立構造が生まれてしまいます。

壁の経験

この本を読んで、壁の経験を思い出しました。

私は若い頃から複数のメーカーさんの仕事を何度かさせていただいています。そこでは、ハードとソフト、最近ではインテリジェントな周辺機器とメインの機器など複数のソフトウェアが並行に開発されています。

そのような場合、スクラム・オブ・スクラムというか、軽量化された五月雨ウォーターフォール開発・オブ・スクラム、とでも言うようなリーダーミーティングが行われています。これは、リーダーが実践知を持って互いにコミュニケーションをはかり、各チームに深く入り込んでいればうまくいきます。

特にある程度こなれた環境の場合は、スタブやシミュレータがあって、インターフェースのトラブルも限定されたものになります。しかし、新規にインタフェースを作る時には、よほど注意深く開発を進めないとうまくいきません。

以前、どうもあやしいと感じるプロジェクトがありました。その時はあるチームの責任を持つ立場でしたが、リーダーミーティング的な集まりはお客様の担当者が出られていました。出てくる資料や話からは詰めの甘いところが感じられました。

そこで、担当者の方に「このままでは無理です」と宣言しました（後から聞くと同僚は強気な発言に驚いた様です）。通常なら、Q&Aなどを通じて詳細を詰めていくのでしょうが、期間や内容を考えるとリスクが高過ぎました。そこで、お客様とお話しして他のチームとの合同のミーティングをしていただきました。壁を打ち破った瞬間でした。

オブジェクト指向だけでは堅すぎる

この本を読んでいると、アジャイルスクラムはオブジェクト指向開発をする上で、従来のやり方では難しいのでオブジェクト指向的な組織構造を作った(P.221)というジェフ・サザーランドさんのお話が載っています。

チームをカプセル化し、スクラムマスターがプロダクトオーナーとのメッセージを受け取る仕組みです。大規模化する際にはスクラムマスター同士が集まるチームを構成し、スクラム・オブ・スクラムを実現します。

しかし、オブジェクト指向がやりにくい場合に、アスペクトやミックスインをしたくなる様に、チームがうまく守られれば守られるほど、やりにくくなる可能性があります。

富士通の事例(P.173)では、朝会と夕会のそれぞれをチーム毎と全体の２回ずつ行っていますし、野中さんも「チームの外部への知識の伝達については未だ多くが語られていない」(P.217)とされています。

要求開発のコタツモデルのようにチームを越えて知識を共同化するには、「壁を打ち破る」事が必要なのだと思いました。

チケット駆動開発の壁

著者の平鍋さんはアナログ大好きな方の様です。この本の中でも遠隔地とは最初は同じ場所で始める、skypeを常につないでおく、といったお話が出てきます。とても参考になります。

チケット駆動開発は作業の中心にITSなどのチケットシステムを置いて、それに依存して常に見る様にする事で、アナログのタスクボードのような効果が得られます。

この時に注意しないと行けないのは、それだけではうまくいかない事を認識する事です。本に書かれた方法や、必要に応じて通信方法を選択する事も大切です。

RxTstudyなどの勉強会で議論していて良く出るのは

• 議論が長引いて面倒な時は電話などで直接話をしてまとめをチケットに残す

と言う方法です。ありがちな説明では「手段が目的化」しないようにという説明になりますが、これもチケット駆動開発という方法の壁を打ち破ってコミュニケーションをすることと言えると思います。

この本で壁を打ち破ろう

アジャイルスクラムはオリジナルスクラムに比べで、ソフトウェアに最適化した非常に良くできたパッケージだと思います。しかし、チームの壁を超えた組織的な活動はこれからです。

これがあれば万全と言う銀の弾丸は未だにありません。ソフトウェア開発を担う私たちは、現実の問題に合わせてどのようにプロデュースし、どのようにパッケージングするか、常に求められています。この本はその時のヒントになる良書だと思います。