無料ブログはココログ

« 2012年6月 | トップページ | 2012年8月 »

[#TiDD] 問題の見極めがチケット駆動の成功の秘訣 #RxTstudy

チケット駆動開発の失敗で一番多いのは、ツールの導入が目的になってしまうことでしょう。それは、プロセスを変更するということはプロセス改善でなくてはうまくいかず、問題点を的確に押さえておく必要があるからです。

先日の第5回 RxTstudy(Redmineやタスク管理を考える勉強会@大阪)で@akahane92 (赤羽根) さんが発表された「情報システム部門のタスク管理とIT全般統制 〜 Excel管理からの脱却 〜」株式会社 島津ビジネスシステムズ 導入事例は、チケット駆動で内部統制(IT全般統制)に適用された成功事例です。

この事例が成功されたポイントは、問題点を見極めてその対策を考えられた点です。問題を明確にされたからこそ、成功されたのでしょう。

このような成功事例を蓄積していければ、きっとチケット駆動開発が多くの人の役に立つと思います。

「チケット駆動開発」は成功への秘訣の書

このたび、小川さんさんとの共著で「チケット駆動開発」という本を出版することになりました。

このチケット駆動開発というのは、TracやRedmineのような障害管理ツールのチケットと呼ばれる障害票にあたるものをタスクの管理に用いる方法です。このチケットは構成管理と連携し、ソースコードやドキュメントの更新がどのような理由で更新されたかを記録することができます。これは"No ticket, No commit"と呼ばれる基本ルールです。チケット駆動開発の特徴はこのルールによって生まれます。

まず、チケットはコミュニケーションの中心です。チケットの更新はメールやRSSリーダーによってリアルタイムに通知されます。チケットを介して開発に関する議論が行われ記録されます。

その記録は開発に役立ちます。チケットの議論によってソースコードの更新理由の詳細を知ることができ、ソースコードの解析に役立ちます。同時にコミットしたファイルだけでなく、チケットへの関連づけによって、関連ファイルを明確に示すことができます。

また、チケットはプロセスを自動化します。チケットにはステータスがあり、プロジェクトのワークフローに従って更新されます。権限のあるユーザだけがステータスを更新できますので、必要な確認作業がもれなく実施されます。

さらにツールによる自動化も進めます。CIツールやテストツールなど、チケットと関連づけることで、プロジェクトの自動化を推進します。

このような特徴を持つチケット駆動開発は、プロジェクトの負担を減らして成功に導きます。それは、単にツールを導入することではありませんし、ツールを思いつきで組み合わせるだけでもありません。

かつて、UNIXはツールボックスと言われました。パイプやリダイレクトによって様々なツールを組み合わせることができたからです。UNIXは自由度が高く、コマンドを組み合わせて様々な用途に利用可能です。プログラマのアイデアを生かして高い生産性を実現する反面、基本的な使いこなしができないとうまく活かせないこともありました。

そこで、基本的な使い方は「UNIXプログラミング環境 (海外ブックス)」や「プロフェショナルUNIX (Ascii software science―Operating system)」を参考に、UNIXマガジンに連載された高野豊さんの「root(ルート)から/(ルート)へのメッセージ―スーパーユーザーが見たひととコンピュータ」に載っているシステム管理者に必要な使いこなしの秘訣を参考にしました。多くの方もこれらの書籍を参考にされたと思います。

チケット駆動開発に用いるツールも自由度が高く、いろいろな利用法が可能です。しかし、使いこなすにはいくつかの秘訣があります。書籍「チケット駆動開発」には、プロジェクトを成功させるための秘訣を書き記しました。成功するプロセスにはどのような秘訣があるか、プロセスプログラミングを提唱したオスターワイル氏に習い料理をメタファに説明します。

プロの料理は単純ではない
料理はソフトウェア開発と同じように、自由度の高い作業です。作業には「さしすせ」(リンク先はWikipedia)のように、基本的なルールが存在しますし、多くの段階があって、ほどほどの水準に達することはできても、安定した味付け、短時間の調理、困難な条件下での調理、新しい料理の開発など、プロのレベルに至るには多くの知識と経験が必要になります。

基本的な知識
料理には基本があります。基本的な包丁の使い方だけでなく、材料や調味料の名称、分量や火の強さなど基本ができなければ、始まりません。

本質の理解
安定した味付けを行うには、火の通り具合や温度の見極めなど、強火で5分というような単純なメトリクス(尺度)で表現できない、音の変化や「しなっとするまで」といった材料の状態を見極めることが必要であることを知ります。

作業の効率化
レシピ集を読めば、それなりに調理ができるかもしれませんが、作業の段取りを最適化することは難しいでしょう。下ごしらえから仕上げに至るまでの依存関係を知っておく必要があるでしょう。そこには「さしすせそ」のような基本ルールのほか、ゆでた材料を余熱で仕上げるなど、多くの工夫が必要になります。

状況に合わせた工夫
また、食材の状態やその日の気温、湿度にあわせて調理方法を工夫します。痛んでいるところを取り除くだけでなく、火の強さや調理時間などの調整によって、その食材のもつ可能性を引き出していきます。

能力の発揮
さらには、入手可能な食材にあわせて、新しい料理を生み出す必要があるかもしれません。それは、一人ではできないかもしれません。仲間の協力を得てアイデアを出し合い、よりよい料理に仕上げないといけません。上司と部下でなく、協力し合える関係を築かなければ、うまくいきません。

このように考えると、「料理は奥が深い」ということに気づきます。定番のレシピだけでなく、様々な料理のレシピを知り、その背景にある本質や依存関係、ルールを理解するほか、よりよいチームを構築することで、作業を効率化し、状況にあわせた対応ができ、アイデアを出し合って工夫することができるのです。

書籍「チケット駆動開発」には、定番レシピに相当する基本的な障害管理の基本や、構成管理の秘訣のほか、チケット開発のノウハウを詰め込みました。また、従来法の問題点から読者のプロジェクトの問題点を見極めてチケット駆動開発をカスタマイズできるように、テーラリングガイドをつけました。また、基本は押さえていますが、入門書にするには濃い内容が多いので、用語集をつけることで説明を補うようにしました。

「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説書第2弾「チケット駆動開発」をぜひご覧ください。

今回、多くの方のレビューにご協力いただきました。とても感謝しております。また、レビュアーの方だけでなく、平鍋さんと倉貫さんにとても素敵な推薦文をいただきました。もし書店で見かけられましたら、推薦文だけでもお読みください(ついつい買ってしまわれることを期待しています)。

[#TiDD] 第5回 RxTstudyでチケット駆動開発の新刊書を告知してきました。 #RxTstudy

今回も盛りだくさんだったRxTstudy。

色々と書きたいこともあるのですが、ひとまず告知タイムでの私の発表をご報告します。

東京の大手書店では8月20日、アマゾンでは8月24日に入手できるようになるそうです。


[#TiDD] 第5回 RxTstudyでチケット駆動開発の新刊書を告知してきました。 #RxTstudy

今回も盛りだくさんだったRxTstudy。

色々と書きたいこともあるのですが、ひとまず告知タイムでの私の発表をご報告します。

東京の大手書店では8月20日、アマゾンでは8月24日に入手できるようになるそうです。

リスクを考慮した段取りで成功に導く

入社して初めてのリーダから「成功するかどうかは、段取りで8割は決まる」と教わりました。いかにもウォーターフォール時代の言葉だと思われるかもしれませんが、この言葉にはプロジェクトやビジネスの秘訣が含まれています。物事の順序を変えることで結果が変わるからです。

また、ある先輩からは「『そうなってしまった』ではなく『そうしてしまった』のだ!」という言葉を教わりました。自分の努力にも関わらずプロジェクトが「そうなってしまった」と感じることがありますが、プロジェクトが勝手にそのような結果になるのではありません。プロジェクトの関係者がプロジェクトに関わった結果としてそのようにしてしまったのです。

この二つの言葉はリスクの特性をよく表しています。リスクとは特定の発生確率と発生した際の特定の影響度をもつ事象です。この確率と影響度は、事象の発生する時期によって大きく変わります。

例えば、実現すべきものや実現方法が良くわからない場合、すべての仕様を決定してしまうことは、作業の遅延や手戻りの発生リスクになります。プロトタイピングや早めのイテレーションでの実現によって、アジャイル開発で言われている「早めに小さく失敗」すれば、実現すべきものや実現方法、さらにその問題点などが明確になります。作業の遅延や手戻りの発生確率は下がり、影響度も小さくなるでしょう。

また、仕様変更の可能性のあるものの採用や、情報の不足しているものの採用は、大きな手戻りの発生というリスクになります。このような場合は、可能な範囲で「決定を遅らせる」ことで、リスクの事象が発生するかどうか明確になって他の選択肢を採用することも可能になり、大きな手戻りは発生しにくくなるでしょう。

このように段取りを考えることでリスクを小さくすることができます。プロジェクトのリスクを小さく出来たなら、その分の工数をいざという時の余裕に回すことができます。もし認識できていなかったリスクの事象が発生しても、対応できる可能性が高くなります。

さらに、コミュニケーションの良いチームであれば、認識できていないリスクをより早く見つけることが出来るでしょう。より自由で自律的なコミュニケーションを実現していれば、気付いたことが言い易くなり、関係者全員の能力を最大限に活かすことができるでしょう。

成功するかどうかは、段取りで8割は決まります。段取りを考えないと、プロジェクトを失敗させてしまうのです。ここで述べたように、リスクを考慮して作業順序やコミュニケーション環境の段取りを考えたなら、プロジェクトをよりリスクの小さいプロジェクトにすることが可能になります。恐ろしい狼男の退治は大変ですが、狼男がチワワになったなら、首輪を付けて飼い慣らすことも容易になるでしょう。

このエントリーをはてなブックマークに追加

« 2012年6月 | トップページ | 2012年8月 »