名古屋アジャイル移動図書館「アジャイル入門本」ブックトーク会

以下の二冊を読みました。

エクストリームプログラミング

  • 以前の訳とは読み口がかなり変わっている。アジャイルサムライに近い感じか。すんなり読める。
  • あっ、「入門」じゃなくなってる!
  • ざっと流し読み。
  • やはりXPはプログラマー目線のものだなと思った。
    • だからどうこうということではなく。
    • もともと"programming"と言っている。
  • この本に書いてあること"だけ"で、組織的なビジネスとしてソフトウェア開発ができるわけがない。エンジニアリング的にもマネジメント的にも暗黙に求められるものがあると、今なら思える。XPが初めて紹介された頃にはそれが分からなかった。そこから始まった試行錯誤が今実を結んでいるといえる。
  • この本が書かれたのは2004年くらい。2016年に読むと、主にエンジニアリング面で変化していることもある。
    • 例えば「単一のコードベース」とか。
  • XPでは
    • 常に設計する。
    • 常にXXする(XX:要件定義、設計、実装、テスト、ビルド、リリース、等々)。
    • 従来の「区切りをつける=工程を分ける」考え方のままだと混乱する。
    • コントロールできるサイズまで小さくする(ことでコントロール可能にする)。

Guidance on the use of AGILE practices in the development of medical device software(AAMI TIR45)

  • サマリ(PDF)
  • FDA(アメリカ食品医薬品局)のガイドラインに適合したアジャイル開発プロセスの定義は可能だし実践されているのでドキュメントにします、という内容。
    • FDAガイドライン開発プロセスをきちんと決めることと、それをきちんと守ることを求めている。監査もあり、それを通らない場合、そのソフトウェアを使って作った製品をロットごと破棄することになって何億円も捨てることになるとかあるという話をうかがった。
  • FDAガイドラインは、工程がウォーターフォール的に区切られていることまでは求めていない。いわゆる「サシミ」(トヨタ生産方式用語かな?)も定義できる。なので、オーバーラップしたプロセスを定義すればいい。
  • このペーパーがテーマにしている食品や薬品を製造するシステムのソフトウェアは、ゲームやウェブサービスのような、「何を作るべきか」ということそのものを探索するような世界ではないと思う。なにを作るのかはある程度見えている。ただし、不確実性がないわけでなく、もし想定外のことがあると前述のように何億円も損失が出ることすらあるので、本当にうまく行くのか最後の最後まで分からない方法はリスキーであり、アジャイル型を志向する動機はある、という理解。
  • アジャイルというか、ウォーターフォールに対するインクリメンタル・イテレーティブのメリットを得たいという話。だから、RUPとか参考にすればいいのかなと想像。
  • TDD、CIはもちろん使う。
  • 「ラインを止める」の大事、と締めくくられてる。ここにもトヨタ生産方式だ!

以下は、全体を通しての感想です。

  • いろいろなドメインにあった開発・オペレーションのプロセスがある。今はウェブサービスが流行りだから、そういうのを回すのがアジャイルみたいに言いがち考えがちだけど、そんなのいろいろ。レガシー業務保守開発のアジャイルだってあるだろうし、営業まで含めた受託開発のアジャイルだってあるだろう。そういうこと話をする人がいないだけ(ソニックガーデンさんの納品のない受託モデルくらいかな。聞いたことあるのは)。
  • アジャイルにはロールがある。それとは別に、ファシリテーションとかチームマネジメントだとメンバーのキャラクターというものを考える。これマトリクスにしたらなにかでてくるかも。
  • ディシプリンド・アジャイル・デリバリーを、今日のブックトーク会では読めなかったけど、他の参加者の方が読んだ感想を聞いていて、あれ、これはひょっとしてスコット・アンブラーがこれまでに提唱してきたこと全部入りなんじゃない?追々理解していきたい。