[#TiDD] チケット駆動開発で困難を乗り切ろう！ #47redmine

ソフトウェアの開発対象は色々あります

1) 大規模で大変な開発
2) 時間がかかっても安く仕上げないといけない仕事
3) 短期開発が必要な小規模開発あるいはその組み合わせ

このうち、1)はゼネコン的な会社の従来型の開発によってそれなりに安定してきているでしょうし、2)はオフショア開発が実践されるのでしょうね。そのように考えると、中小のSIerが受注できるのは3)の短期開発プロジェクトなってしまいます。

そこでは、競争が過熱し易いので、期間が短いだけでなく、コストの厳しいものになりがちです。それなりに仕事がいきわたっている間は良いのですが、景気が冷え込みだすと無理をする会社が現れます。社員を遊ばせるよりはマシだからと、利益が出せないような金額で受注する会社が出てきます。

そのように無理な金額で受注した際に取れる方法は以下の3つです。

1) 赤字覚悟で普通に開発する
2) 手を抜く
3) 効率化する

無理な受注が1回だけなら1の方法も可能です。しかし、企業である限りは利益が必要なので、安易に2番の方法が取られがちです。手を抜くと言っても機能が実現できなければ納品できないので、どうしても品質確保に必要な作業を端折ろうとしてしまいます。しかし、これが最悪の選択であるのは皆さんご存知でしょう。ひとまず納品できても、バグの対応で大変な作業が発生して、利益が開くなってしまうからです。

そこで、唯一の方策が3)の効率化です。以下のような方法が考えられるでしょう。

・全体の作業を明示して、やる気を維持する
・知恵を出し合える環境を用意する
・作業の優先順位付けと計画・担当の見直し
・コミュニケーションを効率化し、遅延を減らす
・作業漏れが発生しないようなワークフローを実現する
・管理作業を電子化して効率化する
・トレーサビリティを高め、障害発生時の対策を容易にする

これらは、すべてチケット駆動開発で実現できることです。困難な時だからこそ求められる、効率化への果敢な挑戦です。それは良さそうだからと博打を打つのではなく、明確なビジョンを持って、論理的に導入して効率化を図るべきものです。

第2回品川Redmineが開催されました。充実居た内容に興味深くUstreamで見させていただきました。ブログを書くまでが勉強会とのことですが、今回はLTしたかった内容を書かせていただきました。

[iPhone4] 失った写真の復活

iPhone4のiOSを5.0にバージョンアップをしたところiPhoneでとった写真やビデオが見れなくなりました。試行錯誤でわかったのは、

「今までなかったアルバム(写真の同期元のフォルダ名)が見えていたら、フォルダ名を変更して同期させるとなおるかも」

という結論です。

症状：

iOS5.0にバージョンアップしたところ、アルバムが増えていました。フォトライブラリと見慣れないアルバムのファイル数が同じで、サムネイル(一覧)をみたところ以前の写真が入っていました。何かおかしくなったとは思いましたが、サムネイルが見えていたので気にしていなかったのですが、最近になって写真を見ようとすると別の内容が表示され、動画を見ようとすると

「要求されたURLはこのサーバー上に見つかりません。」

等と出て内容を見ることができませんでした。

やったこと：

ネットワークを検索すると以下のページが見つかりました。

Apple サポートコミュニティ：ミュージックビデオURL 見つからない
https://discussionsjapan.apple.com/thread/10099470?start=0&tstart=0

どうも同期関係の問題のようなので、上記を参考に写真の共有をOFF⇒ONに変えながら、何度か同期を試みました。しかし、なにも変化せず。

試しに同期元のフォルダにあるキャッシュを消すと、再構築するものの変化なし。

そこで、「ビデオ含める」だけをOFF⇒ONに変えながら、同期を試みました。すると、ビデオだけが復活しました。

解決策：

最後に試したのは写真の共有元に指定していたフォルダを変更したことです。私の場合、見慣れないアルバムは「iPhone4]となっていて気付かなかったのですが、実は共有元のフォルダ名だったのです。そこで、もしやと思って試したところうまくいきました。

上の「やったこと」に書いている作業を始める際に写真フォルダのコピーを作っていたので、それを指定しました。キャッシュのフォルダもそのままに、このフォルダを共有元に指定するとすべての写真とビデオが同期され直して、ようやく復活しました。

ただ、新しいフォルダ名と同じアルバムに、フォトライブラリと同じ写真が表示されるのはそのままです。大切な写真が復活したのでヨシとしています。

以上の結果から、フォルダ指定をされていたためにうまくいかなかった方は、フォルダ名を変更して同期しなおすとなおると思います。ただ、念のため、共有元のファイルのバックアップを取っておかれた方が良いと思います。

[#TiDD] ２つのアダプタブル・ウォーターフォール開発

従来型の開発をチケット駆動開発によって補完するアダプタブル・ウォーターフォールには、大きく分けて２つのパターンがあります。

１）全工程2重管理型

これは上流工程から下流工程までチケット駆動開発するものです。すべてのタスクをチケットで管理しますが、既存のプロジェクト管理と併用します。既存のプロジェクト管理では、ベースラインごとに計画が定められてそれを基準にプロジェクトの予実が管理されます。チケットに登録されるタスクはベースラインで定められたタスク、あるいは、より詳細化したタスクから始めますが、必要に応じて計画が変更されます。

この方法はすべての管理をチケットを中心に実施する完全型チケット駆動開発に似ています。チケットは階層構造を持っていますので、WBSをそのまま表現することができます。BTS/ITSのガントチャートによる進捗報告が許されるなら、管理を一元化できますので、多くのメリットが生まれるでしょう。

気を付けないといけないのは、完全型を目標にすると失敗する危険があることです。チケット駆動開発における成功とは活用されることです。現場における想定外の問題や忘れてしまいそうな作業をチケットにしておくことで、混乱状態からプロジェクトを救います。しかし、チケットの計画を柔軟に変更するとプロジェクト全体の予実管理が困難になることから、開発者による計画の変更が制約される可能性が出てきます。工事進行基準が適用される場合など柔軟に計画を変更できない場合には、あえて2重管理した方が良いでしょう。チケットは動的な管理、エクセルはスナップショットの管理に向いていますので、うまく使い分けてください。

なお、上流工程からチケット駆動開発すると、チケットが膨大になりがちです。計画変更時に各チケットを修正するのは大変です。そんな場合は、エクセルと連携して修正後にインポートする方が効率的でしょう。MS-Projectのような日程調整ができるようにマクロを書かれている方もあるようです。

最近は、チケットの修正が大変だからと日程を入れない方も多いようです。この場合はRedmineのBacklogsなどアジャイル用のプラググインが使われる場合が多いようです。標準の環境でも、マイルストーン(バージョン)を定義しておき、ロードマップなどの一覧で見ることによって、日程を入れないで管理することができます。これは、比較的短い期間にやらないといけない作業が順序を決めずに置かれている状態です。ガントチャートでいうならば、マイルストーンまでの期間に平行に複数のタスクの線を引いているのと同じです。

作業の順序を決めておくことが作業計画に役立つのであれば日程を入れればよいですし、それよりも計画の柔軟性が重要であれば、マイルストーンによる管理が有効でしょう。

２）下流集中管理型

名前のとおり、テスト工程以降(下流)においてタスクを集中管理するチケット駆動開発です。

テスト工程では、準備とテスト種目毎の計画が立てられて、それぞれの消化項目数で管理されることが一般的だと思います。しかし、実際には準備期間はもちろんのこと、テストごとにも細かな準備があり、作業の実施順序や作業漏れの有無によって効率が大きく変わります。

そこで、テスト実施に必要となる作業をチケットとして登録しておきます。これらは、元の計画にない作業ですのでチケットが元の計画を補完していることになります。開発者はチケットによって作業を計画し、日々、全貌をチケッでを確認しながら作業を進めることができます。

この事例は、先日、RxTstudyで発表しましたので、よろしければそちらの記事をご覧ください。

[#TiDD] チケット駆動開発で自律的な組織を目指す

自律的な組織とはリーンソフトウェア開発で「海兵隊」で示されたような、自己決定のための裁量権を持っていて、課題や問題を自らの判断で解決できる組織です。集中体制は変化に弱く、想定外の事象によって独裁国家の様に一気に崩壊する危険性をはらんでいます。これに対して自律的組織は、オブジェクト指向のメタファに用いられる多くの細胞の組み合わせからなる生命体のような構造です。各細胞に対する攻撃は、各細胞やその近隣の細胞で解決されますので、想定外の事象にも比較的強い構造といえます。

自律的組織を実現するには自己決定権を実現するための見積もり技術が不可欠ですが、ここでは単に裁量権の観点で議論してみます。

１．アジャイル開発における自律的な組織

アジャイル開発においては、開発組織とユーザとの間で、優先順位したがって各イテレーションのスコープが決定され、開発組織の裁量で開発作業のタスクが実施されていきます。タスクはタスクボードで可視化され、状況と課題が共有され、開発者たちの決定をコミットすることで開発が実施されます。

注目すべきは、アジャイル開発のプロセスとして決められているルールの中に自己決定のための裁量権が明示されていることで、自律的な組織を実現している事です。

２．従来法における自律的な大規模組織

アジャイル開発によって実現される自律的組織ですが、従来型、いわゆるウォーターフォール開発においても自律的な組織が構成されることがあります。それは開発対象が複数のサブシステムに分割されて、それぞれのチームに裁量権が与えられている場合です。各チームにおいて、課題や問題を自らの判断で解決することができます。

しかし、従来型の開発においてはその裁量権の多くをリーダーが独占しています。他のチームに対してのみ自律的であり、開発者はチーム内の状況をリアルタイムに知ることができず、問題や課題の解決を検討することすらできません。

３．自律的な小規模チーム

小規模なチームの場合は、従来法による開発であっても、ある程度は自律的な開発を行うことができます。大規模開発において、自律的な開発の最も大きな障害は、最新の状況をリアルタイムに知ることができないことです。状況を知らなければ、その解決ができないからです。

小機御組織においては、全員の状況を互いに知ることが可能です。日々の打ち合わせにおいて、(1)コミュニケーションを活発にして状況を共有する、(2)その解決策をチームで検討する、(3)協力して解決する、という状況を作り出せれば、チームは自律的な開発を行えるようになるでしょう。

しかし、その状況を作り出すには、リーダがあまり口を出さないこと、開発者の技術力とコミュニケーション能力の高いことが求められます。また、会議は口頭で行われますので、時間がかかること、声の大きい人が勝ってしまう危険性のあること、に注意が必要です。

４．チケット駆動開発による自律的な開発

チケット駆動開発においては、2種類の自律性があります。タスクはチケット化され、個人の作業管理に役立つ粒度にまで分割され、開発者によって担当チケットが自律的に管理されています。また、チームの課題や問題もチケットを介して共有されますので、アジャイル開発はもちろんのこと、従来法においてもリーダの運営次第でより自律的な組織運営が可能です。

チケット駆動開発で得られる自律性は、リーダの権限を委譲して開発者に裁量権を与えていることに注意する必要があります。開発者は、リーダの指示に従うだけではなく、同じゴールに向かって協力し合う必要があります。

自律的な組織では「アジャイルと規律」で言われてるように、開発者には高度な技術者が求められます。少なくとも状況を把握して判断できる能力が必要であるからです。また、互いに協力して作業するには、ある特定の技術ができる専門工ではなく、一通りの作業のできる多能工であるほうが、作業を柔軟に割り当てられるので有利です。

５．まとめ

このように自律的な組織を実現するには、ルールの中に自律的に計画変更する要素が含まれるアジャイル開発がが有利です。しかし、小規模な開発であれば自律的な開発を進めることもある程度可能ですし、チケット駆動開発においてはより有利になります。もし可能であるならアジャイル開発を、そうでなければチケット駆動開発を検討してみる価値があると思います。

自律的なチームを構築できたなら、開発者の能力を最大限に引き出せる可能性があります。チケット駆動開発は自律的な組織に必要となるリアルタイムの情報共有を可能にし、プロジェクトを支援します。その適用可能な分野は広く、様々なプロジェクトがあるでしょう。

ソフトウェア開発を成功させる秘訣は、そのプロジェクトにふさわしいプロセスを実現することです。チケット駆動開発には多くのバリエーションがありますので、多くのプロジェクトに役立つ可能性があります。今後、どのようなテーラリング(カスタマイズ)が可能であるか、整理していきたいと思います。

レビューを考える - SEA関西プロセス分科会 - #seakansai

森崎先生のレビューの講演に参加しました。
個人的には＠ITの記事のようなことを期待していたのですが、そのような記事ではわからない議論をすることができてとても有用な講演でした。

議論を通じて感じたことは以下の点です。

(a) 開発者は項目の抜けに敏感

　実践していなくても頭の中がWモデルになっているのかもしれません。テスト項目の源泉を仕様書に求めるので、どうしても項目の抜けが気になるのでしょう。

(b) レビューに優先順位をつける

　優先順位というとリスクベーステストを思い浮かべてしまい、全てをしないでどうするのかと思われるかもしえません。しかし、極限までレビューすることは困難で、時間の制約や体力の限界で終わってしまうので、優先順にレビューのフォーカスを変えていくことが有効だと思いました。

(c) レビュー道の極意は、レビューをせずにバグをとる

　私が勝手にN先生のフロントローディングの話をまねました。すべてをレビューできなければ、その対象を減らすために、ドキュメントのひな型を用意する、ワープロの文章チェック機能を使う、エディタの自動整形機能を使う、静的解析ツールを利用するなど、効率化や自動化は有効でしょう。

(d) レビュー技術の研鑽には経験を積むことも重要

　ドメイン知識がソースコードになっていることから、コードを良く知っているというのも、抽象化できる人なら高度な技術者なのだろうと思います。理由もなく、これまでそうしていたからというのは統一性には役立ちますが、将来役に立たなくなるでしょう。

(e) レビューの特性を生かせ

　テストで見つかると工数がかかるからということがレビューのモチベーションになっていますが、それだとどれだけ時間をかけても良いことになってしまいます。しかし、欠陥の種類によってはテストの方が早く見つかるものも少なくないでしょう。懇親会ではテストは積み上げという議論があり、それからするとレビューの特徴はトップダウンです。レビューに向いているトップダウンでしかわからない所を攻めるべきでしょう。ボトムの細かなところは、なるべくほかの手段で済ませたいですね(それには(c)が有効でしょう)。

つらつらと書きましたが、このようなことを考える良いきっかけになりました。

[#TiDD] デジタル化の効果をファシリテーションに利用する

第2回RxTstudyの講演ではお話しできませんでしたが、コーチングについて少し触れたいと思います。
コーチングに関しては、以前「チケット駆動開発とコーチング」でも少し触れていますが、コーチングは性格を変えるものではなく、それぞれのタイプにあった対応をするそうです。たとえば、スライド中の性格の分類で一番気の弱いアナライザなら、直接お話しするよりもメールでやり取りをするようです。

このことは、デジタル化の特長を利用したものだと思います。デジタルはアナログと違って1か0です。同じ文章であるなら積極的な人も消極的な人も受け取る人の印象は同じになうからです。また、口に出しては言えなくても、文章でなら言いやすいというのもあるでしょう。

掲示板やTwitterなどで強気の発言や毒のある発言をする人に、実際に会っってみると意外と優しい感じの人だったという経験をされた方も多いと思います。それは、このようなデジタル化の効果だと思います。

さて、プロジェクトファシリテーションの目的は、メンバーの能力を最大限に発揮させることです。ファシリテーションの能力が求められる立場の人は、口頭でモチベーションを高めたり、説明する機会も多いでしょう。そこで、ファシリテーションを勉強すると、自分には出来そうもないことも中にはあると思います。それは本当にできる様にならないといけないかというと、必ずしもそうでないと思っています。

「メンバーの能力を最大限に発揮させる」といった時、そのメンバーは誰なのかと考えると、そこにはリーダーも含んで良いと思います。もちろん、最低限のことはできなければいけないとは思いますが、自分の個性を知って、できないところは、デジタル化の力や他の人(メンバーや上司など)の力をうまく使えば良いと思います。

もちろん、メンバーの中にはリーダーはこうあるべきというイメージで評価する人もいるでしょう。プロジェクトを成功させるには、その様な人の能力、リーダー本人の能力、全て含めて最大の能力が発揮できるようにすることが大切なのだと思います。

そして、そのような考慮は、プロジェクトの特性やメンバー構成を考慮して配員する際にも有効だと思います。

[#TiDD] アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～ #RxTstudy

第2回 RxTstudy(Redmineやタスク管理を考える勉強会＠大阪)で講演をしてきました。

これまで、補完型チケット駆動開発と呼んでいたもののうち、従来型の開発に提要したものをアダプタブル・ウォーターフォール開発と呼んでいます。今回はその事例を紹介します。

講演で少ししかお話しできなかったコーチングのお話は、別の記事に書きました。

アダプタブル・ウォーターフォール開発の事例 ～想定外の作業はチケットで補完せよ!～

View more presentations from Makoto SAKAI

要求開発はアジャイルのフロントローディング #redajp

要求開発アライアンス 西日本の10月勉強会に参加しました。

これまで、XPJUG関西のMLなどで名前は知っていたもののよく理解していませんでした。今回はチュートリアル編と言うことでお勉強のために参加しました。

まずは稲田さんの概要説明です。感想を交えながら主要なキーワードを説明されました。後半は「要求開発~価値ある要求を導き出すプロセスとモデリング」の共著者の萩本が、要求開発への思いを要求開発、そして匠メソッドに至った経緯を含めて説明されました。

１．全体の感想

最も印象的だったのは

「開発時にモデリングしていては遅すぎる」

と言う言葉でした。アジャイル開発では、顧客に価値を提供するために優先度の高い仕様から実現しますが、要求開発はバックログとして仕様を具体化する前にも、IT技術者が関わって価値の高い者を提供しようというものです。いわば、アジャイル開発のフロントローディングです。

このことが実現できるなら、仕様をあらかじめ決めざるを得ない、アジャイル開発の効果が少ない場面でも有効だと思いました。スコープが変更できない場面でアジャイルは、段階的に開発することで、技術的に未知な部分やUXのリスクを低減できるものの、価値を想像するという感覚は生まれません。そのような開発においても、IT技術者が要件定義の最初から関与することで、戦力的な価値を提供可能な要求を開発することができると思います。

２．要求開発が提供するもの

要求開発は、必要な事と、選択して整備する仕組みを提供します。

その基本は、こたつモデルと呼ばれるもので、戦略的(将来の価値)、業務問題解決(現在の価値)、技術活用の視点、この3つでこたつを囲むように進めていきます。価値、戦略、業務、IT活用、IT実現、に分けて、それらをつなげて、同時並行に回します。早くつなげて価値を創造するのです。戦略と実現の線上にしか価値は存在しないのです。

これらはWHATとHOWの関係です。実装(HOW)に対する要求(WHAT)のように、要求(HOW)に対する業務(WHAT)、業務(HOW)に対する戦略(WHAT)という関係です。これらを、トップダウンに決めるというよりは、HOWを手さぐりしながら開発していきます。そこでは、ものを作る力ではなく、描く力(価値・要求を手さぐりでデザインする)が重要です。要求開発で用いる「プロジェクトシート」は将来の価値と短期的視野で表します。

要求開発で実施することは、フェーズ(準備、立案、デザイン、シフト)とPDCAのマトリックスで表され、「プロセスキャビネット」と呼ばれます。これらは選択的に実施されるのですが、プロセスセルという枠組みがあり、必要と思われるものを組み合わせてプロセスフローを実現します。稲田さんは、この仕組みを「詳細に走らないように用いています」とのことでした。

３．要求開発への思い

要求開発は、萩本さんをはじめとする、今世紀の初めの頃の豆蔵の方達が提唱されました(豆蔵は、オブジェクト指向、RUP、アジャイル開発などで有名な会社です)。ビジネスの開発方法論の必要性から、BDA(ビジネス・ドリブン・アーキテクチャ)、そして要求開発の方法論に発展したそうです。要求開発はカスタマイズ可能で、目的と手段を連鎖させ、プロセスセルはPDCAの慣習化として実現され、無駄なものを作らない方法です。そこには、分析モデルを開発で作るのはおかしい、という思いがあったようです。

要求開発では価値のあるものをつくります。要求開発の4象限はRUPと同じで、HOWはWHATに、つまり価値の高いものを作るためにITエンジニアが手さぐりの協力をします。システム開発以降でIT技術者が協力してももう遅いのです。業務を変えないといけないので、開発はビジネスのところでします。ビジネスの中でアジャイルするのです。

ビジネス戦略を決める際に予想することはは難しいです。やっていないとわからないところがあるので、それをアジャイルでやってみます。そのために、「こたつモデル」は重要で、知識のカスケードをするためにこたつを実現します。ただ、立場の違う人が集まるだけでは空中戦になりがちで、声の大きいものが勝ってします。そこで、ファシリテーションとマネジメントが重要になってきます。

このような萩本さんのお話を聞いて、なぜXPJUG関西の人たちが注目しているかがわかったような気がしました。

４．まとめ

ソフトウェア開発は、単純なウォーターフォールモデルで実現できるような簡単なものではなく、自分たちの能力とその限界を知った上で最高のパフォーマンスを実現しなければうまくいきません。そのための一つの答えがアジャイル開発であったのです。しかし、システム開発を最初からアジャイル開発だけで実現できないので、従来のV字モデル(あるいはW字モデル)の実装部分だけを、アジャイル開発に置き換えている会社も多いでしょう。でも、それではだめだったのです。

価値の高いソフトウェアを開発するには、要求は定義するだけではだめで、開発しないといけないということなのです。要求開発は、いわば「アジャイル開発のフロントローディング」だったのです。

(聞きかじりを個人的な思いでまとめました。間違い等ありましたらご指摘ください)

アジャイルを考える - Agile Tour Osaka 2011 -

去年は自宅で見ていたAgile Tour Osaka 2011ですが、今年はLTに出番がいただけたので朝から参加しました。講演を聞く中で、多くの刺激をいただくことができました。

１．インパクトのあった言葉

アジャイルを標榜しながらもチケット駆動開発で現場を改善しようとしている私にとって、最もインパクトのあった言葉は、

・アジャイル開発ができない理由として「制約」と言われるものは「解決すべき妨害事項」

・「守破離」と言われるが、「守」をせずに「破」をしてしまう

という@ryuzeeさんのお話でした。@ryuzeeさんのほか@smorisaki先生のお話にあったように、何かをするには説明責任が伴いますし、何かをせずにおくことも

・変化しなければ緩やかに滅びる、という背任！(@ryuzeeさん)

であるなら、安易にプロジェクトを進めるのではなく、解決すべき妨害事項が現時点においては制約であることを説明する必要があると思いました。

２．アジャイル開発導入への妨害リスト

私から見えている「妨害リスト」は以下のようなものだと思います。

契約
まずはこれでしょう。準委任でなく一括請負になる場合には、減価償却したいという場合があって、ちょっと厄介です。また、藤井さんの講演にあったように、信頼関係を築かないと始まりません。

多能工を増やせない
複雑で先進的なシステムの場合、すべてを把握・実現できる多能工ではなく、専門工になりがちです。いずれは多能工化したくとも、新しい技術を順次取り入れたり、新しい人が入るような状況だと、実現が困難になります。

システムの並行開発
連携する複数システムを並行して開発する場合など、あらかじめインタフェースを決めて開発します。インタフェース汎用的でない場合などは仕様が限定されてしまい、段階的にリリースする場合も、スコープの変更ではなくリスク低減が目的とされます。

危機感の共有
実は、組織やチーム内の合意形成が最も困難ではないかと思っています。様々なステークホルダーのいる中で、プロジェクトの目標は、価値、利益、信頼性、QOLなど様々ありますので、プロジェクトの問題点が共有でき、解決法としての合意が必要になります。

それぞれ程度の問題で、簡単な問題や長期的に効果が見込める問題であれば解決すべきでしょう。

しかし、現実を見ると目の前にはプロジェクトがありそこで求められていることは、アジャイルを実践することだけではありません。すぐに求められていることは、アジャイルを実践した先にあることなのだと思います。

２．アジャイル開発導入をあきらめてみる

アジャイルを一旦あきらめて、すぐに解決したい問題の観点で、各講演を見直すと、以下のような項目があがります。

任せること(設楽さん)
そのために細分化、見える化、自動化する。見える化は変化を検出可能にすること。チケットをうまく使えばできそうです。

説明すること(森崎先生)
事例とシミュレーションを組み合わせて説明する(Exsample scenario)。全てを実績で説明することが困難な場合、過去の実績と未来の予測を組み合わせて利用する方法です。メトリクスサーバをうまく利用できそうです。

見積もりと計画(藤井さん)
処理されるデータを中心に見積もるCOSMIC法は興味深いと思いました。ファンクションポイント法も表面的な機能だけでなく、内部のデータも見積もりに加える事例もあるようですので、分野によっては効果的だと思います。また、ベーム先生のアンカー留めスパイラルモデル(1994)は、マイルストーンをしっかり決めて守る事なのだと思います。この他にも、アジャイルＵＰ、ＡＭＤＤ、southernSCOPEといったキーワードは参考になると思います。

自己組織化(吉羽さん)
トップダウンの外科医チームのような組織は、構造化プログラミングされた巨大なプログラムだと思いました。頑張れば何とかなるかもしれませんが、外乱に強い安定した組織にするには、オブジェクトの能力が発揮できる自律分散型の組織が必要だと思いました。

これらは、成功したアジャイルにより得られるものではありますが、危機感の共有と工夫によってある程度実現できるのではないかと思っています。そして効率化していけば、その先にアジャイル開発に近いものが見えてくるのではないかと思っています。

謝辞

このように多くの刺激をいただけたAgile Tour Osaka 2011のスタッフのみなさま、発表者の皆様に感謝いたします。

[#TiDD] チケット駆動開発によるアダプタブル・ウォータフォール開発 #agileto2011

Agile Tour Osaka 2011でライトニイングトークをさせていただきました。当日になって修正したり、説明を追加してしまい。３分の２ほどしかお話しできませんでした。せっかくスライドを作りましたので公開します。

チケット駆動開発によるアダプタブル・ウォータフォール開発

View more presentations from Makoto SAKAI.

「チケット駆動開発によるアダプタブル・ウォータフォール開発」というタイトルで、ウォータフォール開発には難しいことがあるけど、チケット駆動開発を導入するとアジャイルの良さを取り入れることができるというお話です。アダプタブルというのは、アジャイル開発の名称の候補であった(参考アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか＜kawaguti の日記＞)アダプティブを参考に、これまで従来型開発における補完型チケット駆動開発と呼んでいたものに命名しましたです。当初、アダプティブにしようかとも思ったのですが、あらかじめ変更のための仕組みを入れておくのではなく、必要に応じて変更の仕組みを入れることが可能であることから、アダプタブルとしました。

まだまだ整理しないといけないこともありますので、これから徐々にやっていこうと思います。

Jenkinsの特長 - メトリクス収集サーバの視点から -

第1回大阪Jenkins勉強会に参加してきました。これまでXP祭り関西でHudsnの運用のお話を聞いたことがありましたが、直接動作を見ながらの説明で良くわかりました。以下、自分なりのまとめと、メトリクス収集サーバの観点からの感想です。

Jenkinsまとめ

JenkinsはHudsonをルーツとするCI(継続的統合)ツールです。ソフトウェア開発を進める中で、以外とはまりやすいのがソフトウェアの結合です。インタフェースを決めて開発をしていたのに動かない、この前まで動いていたのに動かなくなった、担当者がいないとビルドできない、といったことは、笑い話になるほどありがちです。

CIツールを用いると、ソフトウェアのビルド、デプロイ、テストを常に実行する環境を構築できます。ここでいう「常に」というのは

・必要なときに画面あるいはコマンドラインから
・リポジトリにコミットしたとき
・定期的にリポジトリをポーリング(チェック)して更新があったとき

です。Subversionを用いたJavaの開発で使われることが多いようですが、勉強会の時点で427(どこかの薬局のCMを思い出しますね)ものプラグインによって、様々な言語や環境と連携することができます。もちろん、シェルスクリブト等を介して外部のコマンドと連携することもできます。

上述の起動タイミングのうち、ポーリングによる方式だと、頻繁に更新されるリポジトリでの実行負荷を下げることができますし、さらに複数のJenkinsで連携することもできるそうなので、大規模な開発にも対応できるようです。

そしてJenkinsで忘れてならないのはインストールが容易なことです。コマンドラインでたった1行実行するだけで、インストールができます。プラグインの設定やプロジェクトの設定もインストール時に構築されるWebの画面から簡単にできます。勉強会のLTではHudsonからJenkinsへのアップグレードも非常に容易であることが、開発者の川口さん自身による動画で紹介されました。

メトリクス収集サーバの視点から

ソフトウェア工学の世界では、当初からメトリクスの重要性が語られ、多くのメトリクスが提唱され、実証されてきました。それぞれのメトリクスには有用な場面があるものの、その収集のための負担の大きいことから、コード行数以外はあまり活用されてきませんでした。

そこで、開発者に負担を与えないように、リポジトリからこっそりとメトリクスを収集する方法がとられるようになりました。私もEPM(PDF)というメトリクス収集環境の開発にかかわりました。しかし、その開発は、とても大変でした。

メトリクス収集環境で最も大変なのは、サーバの構築とツールのインストールです。1日1回メトリクスを収集するには、ツールのインストールはもちろんのこと、関連ライブラリWebサーバやコンテナのインストール、アカウントやcronの設定が必要です。このあたりになるとインストールできる人が限られてきますので、簡易なインストーラの開発や、OSの仮想イメージでの提供までしていました。

しかし、Jenkinsを用いたならツールの開発だけで済みますし、基本的なメトリクスならプラグインもあるでしょう。開発者に負担を与えることなくメトリクスを収集できるので、めったに役に立たないメトリクスであっても、あらかじめ収集しておくといったことも可能になるでしょう。

勉強会でもメトリクス収集の話がありました。メトリクスの収集だけであれば品質保向上にはなりませんが、作業やプロダクトの状況確認や、異常の早期発見には大いに役立つでしょう。

このように、Jenkinsのソフトウェア工学への活用には、大いに期待しています。

iPod/iPhone用 FMラジオ付目覚ましスピーカー PSP-BQB

これまで自宅でiPhoneの音楽を聴くときはBOSE Companion2というPCsぴーかで聞いていました。これがPC用と思えないくらい低音が効いていて良い音が出るので、特に不満もなかったのですが他に流用したくなったのでPhone用のスピーカを探すことにしました。コストパフォーマンスで言うとBOSE Companion2しかないのですが、予算の問題と最近目覚まし時計が壊れたこともあって、目覚まし兼用の小型スピーカーを探しました。

たまたま近くの電気店でセール押していたので、いろいろ検討していたのですが、最近はかつてのように簡単に聞き比べができないのですね。スピーカーの切り替えスイッチはあるものの、音源がつながっていないのです。仕様だけを比較して買おうかとも思いましたが、安いスピーカで良い音が出ることの方が珍しいので、やはり視聴して買いたい

。そこで、店員さんに視聴できないか聞いてみると「どちらですか？」「オーディオプレーヤーはお持ちですか？」とか言われます。どうも客の音源をつなぎなおしながら視聴させる仕組みのようです。「色々聞きたいのですが」というと「それぞれ繋ぎなおすので面倒なんですよね」とスピーカ切り替えスイッチの配線が信用できないようなそぶり。「一応、客なんだけど」と思いつつ、まあ、5,000円ぐらいのものに「手間もかけられないよな」と思い直し、勝手につなげてよいか聞いてみました。

Win-Winの関係が成り立ったようで、すんなりOKとのこと。許可が出ればこっちのものです。接点が汚れないか気にしつつ、iPhoneを準につないでみました。BOSE の高級機が良い音なのはもちろんのこと、BOSE Companion2はやはりコストパフォーマンスが優れています。そして残念ですが、やっぱり安い機種は音に厚みがなくカサカサ言うような感じです。低音が出ないだけでなく、iPhoneそのままので十分とおもえるほど安っぽいバランスの悪い音でした。

そのような中で、低音は出ないもののそれなりにバランスよく聞こえたのが

プリンストンテクノロジー iPod/iPhone用 FMラジオ搭載 目覚まし機能付きスピーカー(ブラック) PSP-BQB

でした。実際に17インチのブラウン管テレビと比べるとAMラジオとFMラジオぐらいの差を感じました。スピーカーは小さいけれども割と音の良いラジカセのような感じと言えば良いでしょうか。

機能的には

スヌーズ機能付きの目覚まし
「ピッ、ピッ」ではなく「ボッ、ボッ」という感じの音、聞きなれませんが、目は覚めます。FMラジオやiPhone/iPad、外部入力も設定できます。 月～金だけ鳴らす設定が便利です。

FMラジオ
スキャンやプリセットできます。アンテナ線を束ねたまま使っていますが、良く入っています。

iPhone/iPad
騎手は各種サポートしています。コネクタのカバーがたくさんついていて、完全な蓋のほか新旧のiPhone/iPad用の形状に合わせたカバーがありますので、安定した取り付けが可能です。「Made for iPhone」の認定済みですので、接続時に注意を促すダイアログが出ることもありません(聞き比べた機種によっては接続するたびに注意が表示されるものがありました)。

外部入力
ステレオミニプラグというのでしょうか、イヤフォンと同じ形状のコネクタでライン入力できます。上述のように、DVDの音声を出力すると17インチのブラウン管TVよりも良い音で聴くことができました。

残念な点は、電源が抜けると設定が消えてしまうこと、ボタン(スイッチ)のつくりがあまりよくなく、カチカチいったり、ボタンごとに感触が異なるところです。

若干の難点があるものの、総合的には「4千円程度でこれだけ使えれば十分」と思っています。詳しくはメーカーページを見てください。

[#TiDD] DevLOVE関西LT「チケット駆動開発によるプロジェクト改善の仕組み」 #devlove0917

DevLOVE関西でライトニングトークをしてきました。DevLOVEは開発を愛する人が、コミュニティで得たことを実践する活力を得るため場です。エンジニア人生は高々300人月分の経験しかできないので、みんなの経験を持ち寄って情報交換し技術向上をめざすHanger Flightをソフトウェアで実現しようと言う集まりです。

さて、LTで私が発表したのは、「(アジャイルだけじゃない)チケット駆動開発によるプロジェクト改善の仕組み」です。プロジェクトの混乱をチケット駆動開発がどのように改善するかを説明しました。

チケット駆動開発によるプロジェクト改善の仕組み

View more presentations from Makoto SAKAI

次回は10月22日のRxTstudyで補完型チケット駆動開発の経験をお話しするつもりです。通常の講演なので、今回のDevLOVEで学んだプロジェクトファシリテーションに関係するないようにも触れるつもりです。その次はAgileTourOsakaのLTで「チケット駆動開発で気付いたアジャイルの仕組み」をお話しする予定です。

[#SNSD] 少女時代 「The 1st ASIA TOUR "Into the new world"」 (2DVD + フォトブック)(韓国盤)

このDVDは同名の2CDアルバムのDVD版です。曲が良かったので、買ってみました(韓国の出品者catchopcdからの購入(￥3,163)で、入手に5日かかりましたが、日本語で対応してもらえて好印象でした)。

1) 日本語しかわからなくても楽しめる

DVDを再生すると韓国語、日本語、中国語のメニューが表れます。日本語を選ぶと歌詞やMCの日本語字幕が表れます。フォトブックも写真中心でスタッフのの名前にまで英語が併記されています。アジア全体で売ろうという意欲が表れていますね。日本語には期待していなかったので驚きました。字幕を見ていると、アイドル的なデビュー曲と思っていたInto the new worldの歌詞がけっこうきわどかったり、新しい発見もありました。

2) 韓国デビューから日本デビューのころまでの音楽

最近はセクシー＆かっこいい系曲が多いですが、このDVDでは、韓国デビュー時ののかわいいい感じの曲から、日本でのデビューの頃の美脚を強調した曲までが歌われています。ソロの曲も色々入っていて、なかなか楽しめます。同名のCDとほぼ同じ構成ですがボーナス曲が2曲入っています。

3) ライブ感もばっちり

ライブなので途中のMC(語り)やメーキングのほか、曲間で流れていた映像が楽しめます。この映像はステージの後部にある巨大スクリーンに映されていたもので、メンバーの紹介や少女時代らしいコントなどなかなか楽しめます(ハローベイビーのノリです)。

4) 意外とパクパクが少ない

CD版をiTunesで購入して聞いたときは、ほとんどパクパクだと思っていました。これは、日本のMnetが一度放送をやめる前(2000-2001年)の頃のK-POPは、ライブでもパクパクが普通で、昔の日本のアイドルの様にお世辞にも歌唱力があるとは言えないものでした。しかし、最近のK-POPの歌唱力はなあなかですね。特にジェシカとテヨンはDVDのPCM音声でないと生歌とわからないくらいでした(もちろん、歌が苦手なユナは除きます)。

5) 残念な点

やはり少女時代はハイビジョン向けです。全員だけならまだしもステージ背後のスクリーンも映されるとディテールが見えませんし、CMの映像らしきものなどは目の周りにノイズがのっていました。あと、引いた画像の角度が斜め上からで、お気に入りの「少女時代」という曲は、正面からを意識した振付がちょっと残念な感じでした。

これでブルーレイだったら完ぺきでしたが、3000円程度でこれだけ楽しめれば大満足です。

[#TiDD] チケット駆動開発で気付いたアジャイル開発の仕組み

アジャイル開発とはなにか？それは聞く人によって大きく変わります。このため、本に書かれたそのままに実施したつもりでもうまくいかないこともあるでしょうし、開発チームの制約に合わせて実施する場合には危険が伴います。恥ずかしなが失敗したからこそ気づいた「チケット駆動開発に隠れたアジャイル開発の特徴」を説明します。

１．ライトウェイトプロセスだけではない！

2000年から始まったアジャイル1次ブームでは、1990年代半ばからブームであったCMMとの比較で語られることが多かったように思います。

よく言われたのは、無駄を排除した「ライトウェイトプロセス」という特徴です。ドキュメントは必要最低限にして、コード中心にプロジェクトを運営する。進捗管理もタスクボードで、計画済み、実行中、完了と3つのステータスのみで管理される。当時、とてもショッキングなプロセスでした。

ケントベックさんの白本(最初のXPの本)が(私には)わかりにくく、スクラム・ブートキャンプも無い時代とはいえ、ライトウェイトプロセスと言う特徴に、私は強く興味を持ってしまいました。

２．恥ずかしい失敗事例

XPがブームになったころ、たまたま研究開発プロジェクトを担当することになり、真似事をしてみることにしました。当然のことながらタスクボードを用意しなければいけないのですが、会議用のホワイトボードはあるものの占有もできず、空いている壁もありませんでした。

そこで考えたのが、機能的に同等のものを用意することです。機能を考えてみました。

・タスクボードの情報はみんなで共有できる
・タスクは3つのステータスで管理される

思い浮かんだのは、たったこれだけです。そこで、ファイル共有サーバを用意して、左にタスク、右にステータスを示す3つの欄を持つエクセルシートを置きました。タスクの一覧の作成後は、みんなでレビューしました。

タスク名	ToDo	Doing	Done
XXの開発		〇
YYの開発	〇

結果は最悪でした。

・タスクが荒くて進捗が見えない
・めったに更新しないので、誰も参照しない
・リスクが高く、だらだらした開発

当時はアジャイルの親切な本もなく、アジャイルの良さとしてタイムボックス管理によるスコープの変更がようやく知られるようになった頃でしたので、なぜ失敗したかも良くわかりませんでした。

その後、@agilekawabataさんと出会い、XPのプラクティスに関する論文を書いたり、XP祭り関西の2006のスタッフなどをして理解を深めましたが、それぞれのプラクティスと繰り返し開発のメリットは感じたものの、過去の失敗の原因としてピンとくるものはありませんでした。さらにしばらくして@akipiiさんと出会い、聞きかじったチケット駆動開発を実践することで、ようやくアジャイル開発の仕組みに気付いたのです。

３．チケット駆動開発で気付いたアジャイル開発の仕組み

チケット駆動開発を簡単にいうと、タスクボートとタスクカードを、障害管理ツールの一覧とチケットで実現したものです。通常の障害管理ではチケットを障害(バグ)票として使いますが、チケット駆動開発では細かな作業も備忘録のようにチケットに記述していきます。他人の作業も登録できますので、時には作業指示書にもなるものです。

実践してわかったのは、以下の様なメリットです。

コミュニケーション
タスクカードであるチケットがコミュニケーションの中心となっていました。チケットは備忘録、作業指示であると共に、作業に関するコメントの書かれた掲示板でした。チケットとソースコードを関連づけることで、ソースの修正理由をチケットの履歴によって知ることができましたので、問題が発生した際にソース解析の参考になりました。

集中
開発中に発生した仕様変更や、問題の発生によって増えた作業も、直接指示されるのではなく、チケットを介して指示が行われるようになりました。担当者は都合の良い時に自分の担当するチケットや自分が報告したチケットを確認すれば良いので、作業に集中できるようになりました。

リズム
チケットがプロジェクトの中心になると、日々の朝会の前後には担当のチケットを確認するようになりました。チケットを確認しながらその日の計画を立て、1日の作業の後に司直を更新する。そんな日々のリズムに慣れると、作業が快適に感じるようになりました。

これらは、以前失敗した際には気付かなかったアジャイル開発の仕組みによって実現できました。それは、以下のような仕組みです。

・情報が一元化されるとチケットに依存する
・チケットの粒度が細かいと、日々の確認が必要になる
・チケット確認を中心とした開発のリズムが生まれる

これらは仕組みというほどでもないかもしれませんが、あまり説明されていないのではないでしょうか？アジャイルは実践重視ですので、これらは経験の中で習得されていくのかもしれません。このような仕組みを理解しないまま、タスクボードを機能的にとらえてしまったので、恥ずかしい失敗をしてしまったのだと思います。

４．チケット駆動開発はアナログを超えるか？

これはプロジェクトによると思います。アナログは情報量が多く、一目で多くのことを知ることができます。かつて私が失敗したのは、エクセルで一目でわかる範囲にタスク分割したからで、もっと画面が広ければ進捗がわかる程度にタスクを分割したかもしれません。

チケット駆動開発は、情報量の少なさをデジタルの特徴で補います。様々な条件でチケットの一覧やグラフを見ることで、担当チケットやガントチャートなど状況に応じた情報を一目で見ることができます。また、ワークフローや構成管理ツールとの連携といった、デジタルならではの特徴によって欠点を補っています。ステータス変更の際に何らかのチェックの必要な場合や、派生開発など過去の履歴を参照するようなプロジェクトには有効でしょう。

５．まとめ
アジャイル開発は一部だけを導入しようとしてもうまくいかないと言われることがあります。それは、ここで述べたような仕組みが隠れているからではないでしょうか？チケット駆動開発は、アジャイル開発の一部をデジタル化するだけでなく、さらに強化したものです(強化したものの一つに“No ticket, No comit!”のようにチケット駆動開発独自のルールもあります)。チケット駆動開発にあるアジャイル開発と類似の方法に関しては、アジャイル開発が参考になりますし、私のようにアジャイル開発がピンとこなかった人にはアジャイル開発の仕組みを考えさせるきっかけにもなるでしょう。

アジャイル開発にあこがれながらも何らかの事情によってできないのなら、チケット駆動開発を検討されてはいかがでしょう。

[#TiDD] ツールでできること

チケット駆動開発を検討されてる方にお話をした際に、あまりにも積極的な方に

「チケット駆動開発で解決できる問題がない場合や、イメージできない場合は失敗するのでやめてください。まずは障害管理から始めてください。」

とお話をしたことがあります。チケット駆動開発は、単に「BTSを入れれば開発が楽になる」といった類のものではありません。BTSを導入した上で、その機能を生かしてチケット駆動開発を実践し、プロジェクトの問題を解決しなければ、効果は得られません。

もちろんチケット駆動開発で解決できる問題が、存在していなければ効果はありませんし、よくわからないままプロジェクトに導入しても、改善できたかどうか、たぶんわからないでしょう。幸いなことに、もし障害管理ツールを初めて導入されるなら、それだけでも情報の一元化や情報共有、履歴の保存、構成管理ツールとの連携など、様々なメリットがあります。まずは障害管理ツールの導入から初めて障害管理ツールに慣れていただければ、チケット駆動開発の良さをきっと理解していただけると思います。

さて、先日のRyuzeeさんの記事「[Agile]アジャイル開発でツールを導入する5つのステップ」の最後にこう書かれていました。

「チームがアナログで出来ないことはデジタルで出来るわけがない」

この言葉は、私が上で述べたことにつながるもので、おおむね賛成できます。デジタルでできるものであれば、規模の制約や検索能力を除くとアナログでもできるからです。そして、本質的な問題の把握したうえで解決しなければ、プロジェクトの改善はできないからです。しかし、この言葉が表面的にとらえられて一人歩きするとチケット駆動開発に可能性を見出している私としては、困ったことになりますので、問題を整理しておきたいと思います。

私の思うに「アナログで出来ないことはデジタルで出来るわけがない」と言うのは、どちらにしろできない理由があるのだと思います。

どっちにしろできない理由
・問題意識がない
・問題が分かっていない
・解決法を知らない
・そもそも概念や目指しているもの、理論がわかっていない

このような状況では、何をやってもうまくいくはずがありません。試してみる以前の状況で、ごっこ遊びをしているだけです。明確な目的なしにプロセスを無理やり変えても、現場が大変なだけです。

これ以外にもツールから始めることで、失敗してしまう可能性もあります。具体的には以下のような場合です。

ツール(デジタル)から始めるとできなくなる理由
・ツールの利用が目的となり、目的と手段が入れ替わる
・規模の制約がないので、バランスが取れなくなる

アナログの良いところは、人に近い道具であることです。ツールを学ぶ負担も少ないので、ツールを学ぶだけで力尽きることもありません。ツールの先にある方法論に力を割くことができます。また、タスクボードやタスクカードのように制約があることによって、人間の管理できる範囲に情報がまとめられるという良さもあります。

その反面、アナログならではの難しい問題もあります。

アナログでは難しい問題
・規模の制約
・検索能力の問題

これは、BTSというツールが必須であるチケット駆動開発にはない問題です。アナログですと、まずはタスクボードが必要ですし、置き場所にも困る場合があるでしょう。さらに、大きさにも限界があって、管理できるタスクカードには限界があります。カードが増えてくると検索したくなりますが、配置や色などを工夫して探しやすくするぐらいが限界で、そこで表現できる情報にも限界があります。

この制約は、上にも述べたようにアナログの良さでもありますので「だからデジタルが良いのだ」などと言う訳では必ずしもありません。しかし、チケット駆動開発に限るならば、実践しなければ感じにくい良さもあります。

使ってみてわかること
・情報の一元化は重要
・チケットの抽出・並べ替えや検索は良く使う
・集中とリズム

情報関係の方なら、データベースの設計に正規化が必要なことはご存知でしょう。でも、社内文書になると、報告先や打ち合わせに合わせて似て非なる資料を作ることが多いでしょう。面倒とは思っても、情報の遅延という問題には必要悪だと思われていないでしょうか？チケット駆動開発を実践すると、すべてがチケットを中心に回ります。一覧やガントチャートなど、表現方法は色々あっても、そのデータは一つです。誰もが最新の情報を遅延なしに知ることができるのです。

また、チケット駆動開発は忘れずきちんとやる仕組みです。忘れてしまいそうな出来事が多いほど効果的です。そこで、何かあるたびにチケットを抽出して並べ替えたり、検索します。これをアナログの付箋で実現することは困難でしょう。

そして集中とリズム。これはやってみないとわかりにくいと思います。口頭での情報共有は朝会が中心で、それ以外はチケットで作業指示やQ&Aが行われます。朝会後にチケットを参照して予定を立て、作業が終わればチケットを更新する。その様な日々の作業の中で都合の良い時にチケットを確認する。そのようなリズムの中で、作業に集中できます。

これらのうち「抽出・並べ替えや検索」を除けば、アナログでも実感できるものです。これらはこだわるべきものではありますが、明確な問題として認識されていなければ、それを理由に新しい方法論を導入することは難しいかもしれませんが、チケット駆動開発ならほかの理由で導入して実感することができるのです。

結局、大事なことはデジタルとかアナログとかそういう問題ではなく、今、プロジェクトでどのような問題が起きているか、どのようにすれば解決できるかということです。効果が見込めないのに、ツールや方法論を導入しても無駄です。

チケット駆動開発には多くのメリットがあります。もし、チケット駆動開発で解決可能な問題がプロジェクトで発生しているなら、ぜひチケット駆動開発の導入を検討してください。チームのメンバーで問題意識を持って取り組めばきっと効果が出るでしょう。そうすれば、気づかなかった問題点やチケット駆動開発の良さに、気づかれるかもしれません。

[#TiDD] チケット駆動でAdaptable Waterfall開発！

前に書いたようにチケット駆動揮発の特徴はプロジェクト改善です。そのプロセスはアジャイル的で、アジャイル開発においても効果的であるほか、従来型の開発においても管理上の問題を補完して効果を発揮するものです。これらはそれぞれ、完全型、補完型のチケット駆動開発と呼ばれています。ここでは、補完型のチケット駆動開発をAdaptable Waterfall 開発として再定義したいと思います。

１．Extreme Waterfallの限界

品質管理を強化した日本的な従来型開発をExtreme Waterfallと呼ばれています。実装に至るまでの課題をあらかじめ検討しておいて、定量的な数値(メトリクス)を用いて管理することで安定した開発を行うというものです。

このような従来型の開発において混乱の原因となるのが、仕様変更や予想外の不具合、実行環境の変化です。これらは、昔からある混乱原因です。それぞれ変更管理、障害管理、課題管理として帳票で管理され、それらの具体的な作業計画と実施が行われることで、一定の成果を上げていました。

しかしオブジェクト指向技術の発展、フレームワークなど開発環境による生産性の向上、ハードウェアの性能向上によって、対象業務の多様化、実現する機能数の増大、想定外の事象の多発という事態が恒常化しています。そして開発スピードの向上も伴うことで、帳票による管理は限界に達しています。

そこで、チケット駆動開発によって従来型開発の適応力を向上させます。仕様変更や不具合、想定外の事象をチケットで管理するのです。帳票による管理では難しいこれらの作業を、チケットに一元化し、リアルタイムな情報の共有と管理を可能にします。

従来型の開発では仕様変更や追加の作業を厳密に管理することで、プロセスの安定化を図っていましたが、その管理をBTSのチケットで効率化してAdaptable Waterfall開発を実現するのです。

２．なぜ、アジャイル開発できないのか

繰り返し開発やアジャイル開発では、仕様変更を受け付けるタイミングを明確にすることで、仕様変更を制御しています。開発を混乱させないために、それぞれのイテレーションには、変更の取り入れ、変化する作業の管理、リソースの配分、リリース、という一連のプロセスが必要です。

しかし、それは時として困難な場合があります。たとえば以下のような場合です。

(１) 作業を開始するには一括承認が必要
開発チームとシステムを企画・予算化する部門が異なるなど、予算を決済する権限が開発チームから遠い存在の場合、開発中のソフトウェアの仕様(スコープ)を随時変更することが困難になります。

(２) 他のシステムとの連携や必要なデータの入手が開発終盤になる：
連携する複数のシステムが並行開発される場合や、別チームで画面デザインが行われるなど、実装を優先することが困難な場合があります。特にハードウェアとの並行開発では仕様変更が難しい場合があり、仕様段階での検証に多くの時間が取られます。

(３) 機能の実装に必要なタスク集合の粒度が大きい：
タスクの分解が可能であってもタスク間に順序性があり、一つの機能の実装期間が長期になる場合、どうしても段階的な開発になってしまいます。仮に見かけ上だけ繰り返し開発を行ったとしても、その機能の取捨選択は初期のイテレーションでのみ可能です。

このように適度な粒度の実行可能なタスクの集合でない場合、アジャイル開発は困難です。

３．Adaptable Waterfall

そこで、現状の問題を解決してくれるのが補完型チケット駆動開発です。補完型チケット駆動開発では、計画外の作業をチケットで管理することで、従来型の開発を補完してAdaptable Waterfallを実現します。

チケットで仕様変更や障害を管理できるほか、それらを具体化したタスクや想定外のタスクを管理することができます。チケットの更新は関係者に通知され、リアルタイムな情報が共有されます。チケットは実現可能な期限と担当者が記録され、プロジェクト全体や担当者ごとの一覧、ガントチャートなどの形で可視化されます。チケットは、進捗率だけでなくその状態でも管理されます。チケットの種類によって状態を変更可能な権限が決められていますので、レビューの徹底や他のチームとの連携といったことも容易になります。

チケットは情報の中心であり、開発を助けます。チケットには、上記の情報のほか、関連する議論やチケットの詳細を表す様々な属性が記録されます。これらのの変更や、関連するソースコードの変更などもチケットに記録され、プロジェクト改善につながる現状分析のほか、障害発生時の参考情報になります。

Waterfall開発をAdaptableにする上で重要なものにリリース計画があります。原理主義的なWaterfall開発では開発の最後に一度だけリリースが計画されますが、必ずしも現実的ではありません。仕様書に表しきれない挙動を確認するには、なるべく早くユーザに操作してもらうことが効果的です。また、複数システムで連携する場合には、現物による早めのすり合わせは欠かせません。このような外部組織へのリリースなど、目標となるタイミングをマイルストーン(あるいはバージョン)として定めます。

プロジェクト全体を繰り返し開発にできない場合でも、段階的なリリースをマイルストーンと定めることは重要です。チケットはマイルストーンごとに一覧や集計ができますので作業の遅延が見える化されるほか、開発者のモチベーションに大きくかかわります。「今のうちに早く帰ろう」という発想は遅延が顕在化しないからできるのです。制約に合わせて作業を適切に配分し、見える化することが大切です。

４．まとめ

このようにアジャイル開発でなくても、あらかじめ計画が困難な、仕様変更、障害、想定外の作業をチケットで管理して、適切なリリース計画を立てれば、従来型の開発を改善することができます。それは、組織プロセスとしてだけでなく、進行中のプロジェクトの改善としても可能なものです。今のプロジェクトではアジャイル開発を実践できないから、とあきらめるのではなく、問題を見極めた上でチケット駆動開発を導入すれば、きっとより良い開発が実現できると思います。

今のところ唯一のチケット駆動開発の本です。

[#TiDD] チケット駆動開発でプロジェクト改善！

１．従来のプロセス改善

組織の能力を高めるにはプロセス改善が有効であると思います。しかし、現場で開発しているとプロセス改善に協力しようという気持ちよりも、何とかチェックがア厳しくならないようにしようとか、面倒くさいとか鬱陶しいなど後ろ向きな気持ちを抱いてしまいます。このことを考えると、プロセス改善と称して行われていることに以下の特徴を感じています。

義務的：
作業の抜けが問題であると考えており、ルールとそのトレーニングにより解決しようとする

大変なプロジェクトほど負担が大きくなる：
管理に用いられるメトリクスが既定の範囲であることが求められる。範囲を超えると手戻り的な作業の追加や、管理の強化が行われる

プロジェクトへの即効性がない：
プロセス改善で改善されるのはプロダクトの品質と組織のプロセスである。進行中のプロジェクトの効率化が図られない

一定のテーラリング(プロジェクトごとの微調整)は認められるものの、管理の効率化などの工夫はなかなか認められないと思います。標準プロセスは強化され続けますので、時折効率化が図られる以外は、基本的にヘビーウェイトになって現場の負担は増え続けます。

２．チケット駆動開発の特徴

チケット駆動開発はBTSによるタスク管理で現場の負担を減らすものです。たとえば、このようなことがあります。

作業漏れ防止：
忘れてしまいそうな作業をチケットとして管理し、備忘録として使う

ワークフローによる管理：
承認の必要な作業などで、ユーザの権限によって更新の権限を変えることができる

トレーサビリティの向上：
構成管理ツールと連携してソースの更新情報を残すので、過去の修正理由の解析が容易になる

コミュニケーションの向上：
プロジェクト全体や各担当者のの残作業や進捗が共有でき、作業の融通ができる

チケット駆動開発は、現場の負担を減らす目的で

• ・組織の標準として採用することもできる

だけでなく、上記項目のリスクが増大しているようであれば、

• 進行中のプロジェクトに導入して現場の負担を減らす

こともできます。後者を私は「プロジェクト改善」と呼ぼうと思います。

私はこのような「プロジェクト改善」と呼べるような技術を、現場は待ち望んでいたのだと思っています。そして「チケット駆動開発」がもっと広く知られるようになればと思っています。

今のところ唯一のチケット駆動開発の本です。

[#Redmine] 我、なぜRedmine贔屓となりしや

どのBTSを選ぶかという議論になると、ついつい機能比較になりがちです。しかし、Redmineには機能では比較できない特徴があります。それは「後発」であることです。後発ということは「後出しジャンケン」ならではの有利点があり、後発が追いつく際の「ベロシティ」(速さ)が維持されていることです。

Redmineはその設計にTracの影響を受けていると言われています。このため、類似点も多く、プラグインを含めて議論すると、あまり違いはなくなってしまいます。

しかし、Redmineには後発のメリットを生かした(Tracにない)以下のような特徴があります。

・後出しジャンケン
　- 標準機能の充実
　- トラッカー

・ベロシティ
　- さらなる機能追加
　- Ruby on Rails

１．後出しジャンケン

後発の有利点は何と言っても後だしジャンケンです。先発のソフトウェアでは、すでに広く使われるようになり変更が難しくなった点があるのに対して、それらを含めて新たな設計ができるからです。

1.1 標準機能の充実

たとえばTracは豊富なプラグインが特徴である反面、プラグインがなければ利用できるのは基本的な機能に限られます。一方のRedmineは、プラグインも多くあるものの、TracではPluginが必要な機能が、標準機能となっています。ガントチャートもそのような標準機能の一例です。

標準機能が充実していることは、オールインワンパッケージのリリースを早くする効果ももたらしています。プラグインを含めたオールインワンパッケージでは利便性が向上する反面、プラグイン同志が競合することもあって動作確認に一定の時間が必要になり、バージョンアップに機敏に対応することが難しくなるはずです。

Redmineにも最近日本語化されたBITNAMI(http://bitnami.org/stack/redmine)をはじめとするオールインワンパッケージが存在すますが、それらはRedmineの基本パッケージが中心です。同梱されるのは、疎な結合を持つバージョン管理システムSubversionなどとの組み合わせですので、Redmineのバージョンアップ後の比較的早い時期にオールインワンパッケージがリリースされています。

1.2 トラッカー

Redmineはトラッカーごとにワークフローを簡単に変更することができます。一般にチケットの種類(トラッカー)はチケットの一属性にすぎませんが、Redmineではトラッカーを特別な扱いにすることで、各トラッカーのワークフローとして、ユーザのロールごとに現在のチケットの状態から遷移可能な状態を設定することができます。このワークフローの特徴によって、障害管理とタスクの管理のワークフローを別々に設定するなど、業務に合わせた柔軟な管理が可能になります。このワークフローはとても柔軟ですので、ソフトウェア開発以外の業務においてもRedmineが使われています。

２．ベロシティ

Tracはとても手になじむツールです。Versionというたった一つの属性であっても、コミュニティの意見をうまくまとめながら仕様変更が行われています。一方のRedmineは最近のChiliProjectの騒動に見られるように、全員の合意よりもさらなる機能向上を求めているような雰囲気があります。これは、後発プロジェクトの勢いそのままに、追いつけ追い越せと言った感じで、現在も素早い機能アップが続いています。それは、基盤にRuby on Railsを用いていることも影響しているのでしょう。

2.1 さらなる機能追加

Redmineは独自機能も充実しています。特徴的な標準機能だけでもサブタスキング、PDF出力、プラベートチケット、などがあります。サブタスキングとはチケットの階層化のことで、大規模プロジェクトのタスクをWBSのように階層化してチケットで管理できるようにします。階層化されたチケットはガントチャートで表示できるだけでなく、さらにPDFで出力することも可能です。プライベートチケットは最新バージョンの1.2.0からサポートされた非公開のチケットです。セキュリティの更新などRedmineプロジェクトのタスク管理に必要なことから生まれたようですが、チケット数が膨大になる大規模なプロジェクトでも効果的に使うことができるでしょう。

2.2 Ruby on Rails

Redmineの実行環境は、基盤であるRuby on Railsの思想を受け継いで柔軟に選択できます。特にバージョン管理システムの対応に関しては充実していて、CVS、Subversion(リモートも可能)、Git、Mercurialなど6種類以上の環境に対応しています。もちろん、データベースもMySQL、PostgreSQL、SQLiteといったものに対応しています。

このような感じで、仕事上ではあまり使っていないRedmineですが、贔屓(ひいき)の障害管理ツールになっています。

[#TiDD] 記録する - ソフトウェア開発で重要なこと その３ -

ソフトウェア開発で重要なことの一つに「記録する」があります。ソフトウェアはたとえ同じ仕様・同じメンバーであっても、2度と同じように開発できません。なぜなら、人は学習するからです。

そこで、ソフトウェア工学の実験はとても複雑なものになります。たとえば2つの方法を比較する場合でも、2グループで順序を変えてそれぞれ2回実行するなどして、学習効果の影響を受けないようにしなければなりません(そのほかにも、メンバ構成などいろいろ考えないといけません)。

実際の開発現場では一つのプロジェクトは1度きりです。2階も開発することはできませんので、その貴重な情報を失わないように、記録することがとても重要になります。それはプロジェクトのためであるのはもちろんですが、自分自身を知り、身を守るためのものでもあります。

記録の利用方法
開発時の情報を記録したなら、以下のように利用できるでしょう。

　- 作業のエビデンス・報告
- トレーサビリティを高める(状況・経緯を開発・保守に利用)
- やり方を再実行可能にする

メトリクス(定量的なデータ)を集める
さらに記録する対象が定量的なデータであったなら、以下のようにも利用できるでしょう。

　- 傾向(生産性・品質)を知る
- 経験値を参考に状況を知る・伝える
- 類似のものを探す
　- 見積もり・未来の予想
- 予実管理

このような、記録やメトリクスの特徴は、そのままチケット駆動開発のチケットの特徴にも当てはまります。先日のRxTstudy(Facebook)で、あきぴーさんが「タスクカードを電子化したくなる」といわれたのも、このような特徴があるからでしょう。