9/17に、「DevLOVE関西2011CONNECT」とかいうアジャイル関連のイベントが府内であったので、行ってきた。
【聴いたセッション】- オープニング
遅れて入ったのであまり聴けず。
Hanger Flightの話（初期の飛行士は、その体験を格納庫で話し合って共有することによって、飛行機の操縦という人類にとって新種の問題に取り組んだという話）とかしてた。
１エンジニアの生涯工数は高々300人月くらいしかないから、１人で解決できることは知れてるとかなんとか。 - 「アジャイル開発事例と15分で作るRailsアプリ」（川端さん）
XPの話、Javaで開発した事例紹介、Ruby on herokuの実演
後述 - 「ゴール・リズム・愛って、プロジェクトの処方箋！？」
プロジェクトファシリテーションとか
後述 - 「障害管理からチケット駆動開発へ～BTSから始まる進化の歴史」
Mantis最高、Mantis万能みたいな話
後述 - PicoDialog
「あなたはどんな時に能力を発揮していますか？」とか「どんな時に萎えますか？」とかのWebのアンケート５問を、１問ずつリアルタイムに集計しながら、各人の選択について参加者同士で話してみるというもの。
４択だったのだが、いずれの質問においても、筆者に当てはまる選択肢が無く、すっきりしなかった。
【川端さんの話】
・XPの話
XPのテーマとして、Kent Beckの「白本」に始まり、それ以降のどの本でも言われていることは、コミュニケーション、フィードバック、シンプル、尊重、勇気の５つ。尊重と勇気がXPの特色だと思う。勇気とは、できる人がやったコードでも直す勇気のこと。
XPは、具体的なプラクティスが示されていることが良い。
XPが目指す成功とは、プロジェクトの成功というより、開発者満足＋顧客満足だと思う。
開発者満足は従業員満足とはちょっと違う。従業員満足というと、給料が上がることとか休暇が取れることとかになるが、そういうことではなく、開発者が能力を発揮して成功できる、子供に憧れられる、尊敬される、自分が興味のある好きなことがができるようなこと。
「白本」のサブタイトルにもなってる"Embrace Change"（変化を抱擁する ）という言葉が好き。レストランで魚料理を注文した客が、後になって肉料理に変更したいと言い出したら、もし料理ができ上がってても、もう作ってしまったので、と断るのでなく、もしもう作っている途中であってもそれを見せることなく、注文の変更を受け入れること、また注文の変更がしやすいように思わせること、が目指す理想だということ。
・Javaでの開発事例
COBOLだった金融システムをJavaに置き換えるためのフレームワークの開発を担当した時、発注者がアジャイルに理解があったので、やり方を全て自分達で決めてそれも都度変更していくアジャイル流で行った。
オブジェクト指向の知識も無かったが、リッツ・カールトンの「クレド」の話を知って、それを参考にしたり、進め方を自分達で決めてマインドマップにまとめるということをやって目的意識と自主性を高め、2週間のイテレーションを毎回確実にやり切り、20回のイテレーションだったが、最後まで週40時間のペースで終わらせることができた。
その過程で何を工夫したか、どんなトラブルがあってどう解決したかの話も色々あったが、筆者がポイントを掴めなかった為、カットする。
・Ruby on herokuのデモ
Rails, heroku等のインストールからscaffoldを使ったWebアプリの作成、herokuとgitを使ったインターネットへの公開まで、15分くらいで実演された。色々なConfigファイルの類を書き換えてたのが数ヶ所、アプリコードを書き換えてたのが1〜2行くらいで、ほとんどの時間はRubyのコンソールを操作してインストールしたりmakeしたりしていた感じだった。
打ち合わせの最中にも動くものが作れてしまう、動く仕様書なので意思伝達の齟齬も無い、とかいうアピールもされた。
（感想）
このイベントのWebページのこのセッションの表題の所に「バグがないプログラムのつくり方 JavaとEclipseで学ぶTDDテスト駆動開発」と書いてあって、実はこれに興味を持ったから参加したのだが、これは今回のセッションのテーマではなく、川端さんの著書のタイトルだったようだ。何と紛らわしい。かなり当てが外れたが、終始興味深い話で、Ruby on Railsの実演はなかなか鮮烈だったので、満足だった。
まあしかし、ある物を単に組み合わせるだけで作れる範囲なら短時間で作れるというのはよくある話であって、その範囲を少しはみ出ると途端に大変になるというのもよくある話である。特にお仕着せのオートマチックなフレームワークであるほどありがちである。まあ面白かったなということだろう。
筆者にはどうもRubyは遊びに見えてしまう。"Rails", "scaffold", "rake"といった名前の付け方からしてもそれは思う。新しいこと、面白いことを好むRubyな人達にとっては、実用的、実践的な名前の付け方は「つまらない」のだろう。
【ゴール・リズム・愛って、プロジェクトの処方箋！？】
アジャイルを10年やって、やはりソフトウェアは人が作るものだということを意識している。
メンバーのパワーを何％出せてるか、を考える。やり方がまずくて30%しか出せてないとか、100%を出しているがやらされ感があってクタクタとかいうことがある。
しかし、例えば運動会では100%以上の力を出せてると思う。それの実現を目的とするのがプロジェクトファシリテーションである。
プロジェクトマネジメントは計画達成型のマネジメント、
プロジェクトファシリテーションは参加者の協調の場作り。
運動会で100%以上の力が出せるのは、目的が明確で、かつ、メンバー間で一致しているから。
ゴールが明確でなかったりメンバー間で共有できていなかったりすると、チームとして100%の力を発揮するのは不可能である。また、ゴールが漠然としていると、その漠然としたレベルではチームで共有できていても、具体的なゴールの認識にはずれがあるもので、それもパフォーマンスの低下に繋がる。課題とはゴールと現実とのギャップでしかなく、ゴールがずれていれば課題は解決しない。
アジャイルのイテレーションが有効な理由は、遠いゴールを目指すのでないこと。長期的なゴールがメンバー間で一致していても、短期的なゴールにはずれが生じるものである。
WBSがなぜ階層化して分割するかというと、目の前のゴールがはっきりしていると走りやすいからである。
ソフト開発はメンバー間でリズムが一致していると良いと思う。例えば、毎日決まった時間にミーティングするとか。しかし、経験上、そのミーティングを夕方以降にすると「今日も大変だったね」だけになりがちなので、朝にするのが良いと思う。朝やると目標の確認になる。
朝会では、何か笑顔になることをやってみるといい。ハイタッチとかのつまらないことでも、自然に笑顔になる効果がある。すぐ飽きるが、飽きたら次のネタを考えればいい。それでファシリテーションになる。
愛とは、結局、欲望だと思う。人それぞれ欲望は異なる。異なっても、それにより違うtryが行われるので良いのである。
ピーターパンは、"Let's fly"とは言わず、"You can fly"と言う。相手によってその結果はまちまちだが、それで最終的に"We can fly"になる。
（感想）
宗教的な香りが漂うアジャイルの中で、しかも人間相手で掴み所がなく、極めて答えが少ないテーマに関わらず、相当にわかりやすく実践的な話だと感じた。ファシリテーションやコーチングに答えは無い。あるのは目的だけだ。テーマが広すぎて迷子になるよりは、このように具体的なヒントがある話にする方が幾分かマシであろう。
ただ、目の前のゴールの認識にもメンバー間でずれがあるもの（それがチームのパフォーマンス低下の一因）という話は、比較的難しい問題が置き去りにされていると感じた。メンバー間の認識にはずれがあるものだということを理解して話を聞けば、自ずと道は開ける、だろうか。マネージャーの本分は道を見つけること、リーダーの本分は道を示すこと、そのどちらもメンバーの知識や理解力に偏りがあるほど、衝突するものである。運動会のように競争本能によって労せず目的を一致できるものではないし、メンバー全員がゴールを共有できるとは限らないものである。
個人的にはむしろ、メンバー全員がゴールを共有しない限りは団結できないと考える方が危ういのではないか、と思ったりもする。
【障害管理からチケット駆動開発へ】
本来のTiDDとは何なのか？
BugzillaでTiDD以前のことをやってた時は、軽量さと規律の両立の妙、をあまり理解してもらえなかった。
Excelによる障害管理には課題があった。バグ情報が散在して混乱しやすい、作業履歴がExcelやメールに散らばる、集計や報告書作りに手間がかかる、バグ修正と検証のワークフローが複雑で、たらい回しにされることもある、管理台帳でリリースとの関連を管理する必要があるなど、リリース管理が大変、リリース履歴からバグを探しにくい、等々。
MantisはPHPで作られているOSSのBTSで、バグ管理に特化している、Web I/Fを持つシステム。障害はチケットで一元管理し、チケットのステータス遷移でワークフロー制御でき、検索や集計が楽で、終了チケットをリリース履歴として残すことができる、等々。
Redmineと同じく、No ticket, no commitのプラクティスが実践できる。
平均完了日数がわかる。これでチケットの粒度がわかる。イテレーションのサイクルに関係してると思う。
あるプロジェクトで、MTBFを求めてみたら、 １ヶ月持たずにバグが出ることがわかった。
BTSを仕様変更や課題管理にも使いたい。バグ修正のワークフローはSW開発の基本フローである。BTSからITS(Issue Tracking)へ。
BTSのチケットはXPのタスクカード、アジャイルのストーリーカード。BTSはアジャイルと対応付けができ、アジャイルそのもの。
Mantisは柔軟なワークフロー管理ができ、並行開発やブランチもサポートできる。
TiDDは組織全体（全ての業務）へ展開可能。TiDDはBTSのベストプラクティスを引き継いでいる。TiDDはメンバーの自発性が出てくる。TiDDはXPと同じくプログラマ復権運動。
（感想）
TiDDがBTSから派生したものだというのはそうだが、それを言うならMantisとRedmineの比較がされるべきだった。Mantisだけを取って何々ができる、というのは本質的ではないし、厳しく言うと、Excelを比較対象としているが、BTSに必要な機能として、MantisでできてExcelでできないことは何一つ説明されなかった。基本的に、Mantisと同じ入力フォームやデータ管理はExcelで実現可能である。Excelで障害管理する上での課題として挙げられたことは全て、障害管理そのものが理解されずにExcelが使われた結果であり、障害管理のノウハウはMantisを使う上でも必要なのであり、Mantisを有効に使うスキルがあればExcelで管理しても挙げられたような課題は起こらないのである。
Webのシステムだから使いやすい、というのはナンセンスである。Webのシステム（ネットワークシステム）であることとWebブラウザをI/Fとして使うシステムであることは違うし、HTMLに制限されたUIを持つシステムが一般に不便であることは常識であり、むしろExcelからのインポート、Excelへのエクスポート機能が求められることが多いものである。WebブラウザをI/Fとして使う利点はplatform independentであることだけであり、Webのシステムの利点はinteroperability、つまり他のWebベースのシステムとの連携が容易（である可能性が高い）ということである。どちらにしても、MantisやRedmineの長所となるものではない。
筆者の経験上、実務的にBTSに最も求められる機能は、検索／集計と、バックトラッキング（トレーサビリティ）である。それはMantis/Redmineは構成管理ツールと連携して実現しているが、その他の障害管理システムでも何らかの形で実現しているものである。ソースコードのリリースとバグ票番号の対応が取れない構成管理システムはあり得ない。問題はできるかどうかではなく、やり易いかどうかである。MantisやRedmineでも、チケットとコミットとの関連付けを、人の手でチケット番号やタグの入力によって行うのであれば、Excelでも同じことをすればコミットからのバックトラッキングができるのである。
TiDDはあらゆる業務に使えるというのは根本的におかしい。No ticket, no commit(or no work)というのはトレーサビリティの話であり、本来は要件番号や要求仕様書との関連や業務指示書のIDを明確にすることによってMantisやRedmineを使わなくてもトレース可能な情報を残すべき話である。「チケット」だからどうという話ではないのであり、「チケット」でも単位作業の粒度が問題になる話であり、「チケット」ベースだから確実という話でもないのである。何もかも「チケット」ベースにすることが可能であることと、何もかも「チケット」ベースにする方がやり易いことは全く異なる。手段が目的になってしまっている話であり、道具に使われてしまっている話である。そのような発想では、チケットの海に沈むことになり、Excelでやってた頃と同じ状況に逆戻りしてしまうであろう。
MTBFを求めてみたという話があったが、ソフトウェアのバグが確率的にしか起こらないのであれば意味があるかも知れないが、再現手順が明確になったバグはMTBFと関係なく起こせるのであり、1つのバグのTBFは1回しかないので、本当の意味のMTBFではない。
例えばもし、修正すべき不具合は平均的に1ヶ月に1件起こるというデータが出るのであれば、毎月1件分の修正コストを見込んでおけばいいなどの使い方ができるので意味があると思うが、平均を求めたら1ヶ月に1件だった、というのと、平均的に1ヶ月に1件起こるのとは違うのである。
ソフトウェアは、初めの頃に不具が合多く発見され、次第に安定して発見される不具合が少なくなるものである。従って、平均を取る期間を長くすればするほど平均値が減るものであり、そういう平均値は意味が無いのである。推定量の一致性がないというやつだ。また、ばらつきの有無も問題である。平均が1件／月でも、3件の月が1回で0件の月が2回であれば、平均値に意味が無いのである。
そこまで考慮して、実測したら意味のあるMTBFを取れたという話なら有益だったが、今回の話はそういうものではなかった。やはりソフトウェアの不具合にMTBFを持ち出すのはナンセンスであろう。これも本質を捉えずに拡大解釈したことにより無意味に混乱した話だと思った。