デッドライン(締切)を味方につけて、積読を消化する読書会:デッドライン読書会。第17回の課題図書は「More Effective Agile ~“ソフトウェアリーダー”になるための28の道標」の後半戦でした。
デッドライン読書会ってなに?は下記の投稿をご参照ください。
課題図書
課題図書は、「More Effective Agile ~“ソフトウェアリーダー”になるための28の道標」です。
第16回で前半を読みました。今回は後半の「第13章 より効果的なアジャイル:要求の作成~最後」が範囲になります。
感想文
今回はいつもと違い、いっぺんにまとめて書きます。
全体+詳細
前半は実際の作業にフォーカスされていましたが、後半は、リーダーシップ、組織論、プロセス全体の改善など、より広い範囲の解説でした。特に、21章と23章の内容が新鮮でした。
第21章:より効果的なアジャイル:規制産業
医療、金融、政府機関などの規制産業において、アジャイル開発の良さをどう取り入れるかを実践的に説明しています。規制産業の開発プロセスに対する要件を
要約すると「やろうとしていることを文書化し、予定したとおりのことをやり、それをやり遂げたことを文書で証明する」(中略)「すべてやり遂げたことを精細に証明するための広範な追跡を可能にする」
P.244 21.1 アジャイルは規制産業での作業をどのように支援するか
と整理しています。この章では医療機器向けソフトウェアの規制であるIEC 62304を具体例に挙げて、義務付けられている文書や活動を、アジャイルの境界を設けて、スクラムにうまく対応付ける方法を考察しています。一部作業を「シーケンシャル型」にし、スクラムを利用することで効果がでるところを「アジャイル型」にするといったミックスした開発手法です。ミックスしているなんて、スクラマーフォール・スクラムバットだと見えてしまいますが、重要なことは「アジャイル開発」であることではなく、ビジネスを最も効果的に支援することだと説明しています。
また注意しなくてはいけないのは、組織にある「規制上の要件」が本当に法規に起因するかということです。実は過去の内部監査や、失敗からどんどん積み重なってしまった経験に基づく、オリジナルの規制かもしれない。本当にその規制は効果があるのか、守るべきものなのかは、組織内で議論すべきだと思います。
本章は前述の通り、規制産業(医療、金融、政府機関など)が対象です。ただ、内容としては、重たい標準開発プロセス(ウォーターフォール型、シーケンシャル型、等の)を有している企業にも参考になる内容だと思いました。現実のプロセスとの融和、それが本当に効果的か検討するマインド、どちらも参考になるはずです。
第23章:より効果的なアジャイル:導入
前述の内容に近いですが、この章では、組織へのアジャイル導入そのものを扱っています。よくあるアジャイル導入のアプローチとして、
- パイロットチームから始める
- アジャイルプラクティスを別の1つ以上のチームに伝搬する
- アジャイルプラクティスを組織全体にロールアウトする
つまり、1つのチームで成功(パイロット)させ、次に2~3のプロジェクトで成功(汎用化)させ、そして、全社展開!といったハッピーストーリの進め方です。
ここで気づかされたのは、こういったパイロット→汎用化→全社展開といった考え方をするときに、キャズム理論の「イノベーター」、「アーリーアダプター」、「アーリマジョリティ」を念頭に置くという発想でした。さきほどの全社展開の進め方をマッピングしてみると、
- イノベータ―
- (言われなくてもすでにアジャイル開発をしている人たち)
- アーリーアダプター
- パイロットチームに選ばれた人たち
- アーリーマジョリティー
- 次の2~3のプロジェクトに選ばれた人たち
- 全社展開の人たち
- レイトマジョリティー
- 全社展開の人たち
- ラガード
- (たぶんやらない人たち)
こういった形になるでしょうか。キャズム自体はマーケティングの話ですが、「会社の施策(会社で割り当てた人)」にも同じ状況がもたらされるわけです。ということは、イノベータやアーリアダプターは「やってみて!」とさえ言えば自分たちでいろいろ開拓して成功を納めることができる。これ良しと、同様に「アーリーマジョリティ」の層にアプローチしてみると、おかしいな、うまくいかないといったことになる。層を認識して、よりリスクを減らす手立てや、サポートが厚いといった姿勢を組織側が見せなくてはいけないってことです。
これは組織内ではアジャイル開発の導入に限ったことではなく、「有志で募って(もしくは少数で)始めた活動」をいかに全体に普及していくかの難しさと同じです。本書ではこれに対して「ドミノ変革モデル」というチェンジマネジメント手法を示しています。さまざまな浸透手法はあると思うので、単にパイロット→汎用化→全社展開だけを考えるのではなく、組織にあった進め方を十分厚く検討するといったことが必要になります。
Part.5 おわりに 28の基本原則のまとめ
本書の基本原則(ソフトウェアリーダになるための28の道標)が最後にまとめてあります。これは行動指針にもなるし、チェックリストとしても、自己研鑽のテーマとしても使えそうです。1つずつが良い意味で十分に重たい内容なので研究熱心な人は、これをキーワードに修行するのがお勧めです。(私も頑張る)
読み終わった後に…
書籍が良書かどうかの基準の一つに、参考文献リストが充実しているかがあります。
本書はかなり参考文献がしっかりしおり、書籍以外にも、Webページ、ホワイトペーパー、動画などのコンテンツもあふれています。原著→邦訳書のリンクが少々弱いのが残念ですが、そこは監訳者の長沢さんが全力でフォローしてくれているので完璧です!
こちらの「参考文献(邦訳版のみ)」です。
(クルーシャル・カンバセーション、とか読んでみたいなぁ)
次回
- #18
- モダン・ソフトウェアエンジニアリング
- 前後半に分ける予定。範囲は検討中
- デッドライン
- #17の感想交換1Week(8/17〜23)
- インターバル(8/24~30)
- #18の読書する時間2Week(8/31~9/12)
- #18のブログポスト期限(9/13)
コメント