無料ブログはココログ

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

モデリングを考える - 第19回 関西IT勉強宴会 -

第19回 関西IT勉強宴会に参加しました。
このスケジュール登録に少し気が引ける名称の集まりは、元々お酒を飲みながらデータモデリングを主体とした上流設計を議論する勉強会だそうです。なお、今は会場の関係で基本的な議論と居酒屋での本番の議論に分かれています。

今回のテーマは「『チケット駆動開発』とデータモデリング」。前半はあきぴーさんチケット駆動開発の話で、後半はウォーターマーク・アプリケーションズの杉本啓さんのサロゲートキーとデータモデルのお話でした。

サロゲートキーは代替キーとも呼ばれ、プライマリーキーに自動採番のIDを用いる場合などがそれにあたります。サロゲートキーは、ユニークな項目がない場合やナチュラルキーを将来変更する可能性がある場合に有効なほか、分析の早い段階から利用できるなどのメリットがあります。

その反面、本来プライマリーキーとなるべきものが明確でなくなる、実装の都合で導入するのでユーザに説明しにくい、などのデメリットがあります。

そこで、サロゲートキーで表現するのではなく、“[foo]”のように実体名(概念)で表現するという方法が提案されました。ユーザーに説明しやすいほか、実装時はサロゲートキーに置き換えが可能です。

私の場合は、物理モデルで顧客ともやり取りする場合も多く、サロゲートキーのことをあまり気にしていなかったのですが、確かにユーザに説明が容易な概念モデルでありながら、実装をすすめながらもメンテナンスが容易な方法だと思いました。

このようなお話を聞いて、サロゲートキーを真剣に考えるなら、それが非正規化である事も意識すべきだと思いました。本来プライベートキーとなるべき属性がある場合、その属性とサロゲートキーは1対1または他対1の推移従属です。きちんと正規化するなら、別テーブルになるはずです。

モデリングとは、ある視点で物事を単純化することです。概念モデルはユーザと共有すべきデータの有り様を示し、物理モデルはDBの有り様を示します。しかし、サロゲートキーのある物理モデルは技術者同士であってもわかりにくく、必要な制約が漏れる事もあるでしょう。

一旦、サロゲートキーを別のテーブルに表現しておき、その情報をデータベースに与えれば良きに計らってくれるような仕組みはできないものかなどと妄想しました(うまくやらないとサロゲートキーのありがたみがなくなるかもしれませんが)。

今回は飲み会では時間切れで詳しいお話はできませんでしたが、XEAD Driver の渡辺幸三さんから、ナチュラルキーに対してサロゲートキーを人工キーと呼ぶ事もあるが、不変キーという考え方もあるとうかがいました。

モデルは最終的な物理モデルを示すだけでなく、コミュニケーションや考えるための道具でもあります。実装のために人間が合わせるのではなく、分析者の意図を表現したものが自動的に実装される事が好ましいのではないかなどと、門外漢ながら考えた次第です。

近頃、甘口の勉強会が増えていますが、久しぶりに濃い口の勉強会に参加して、刺激を受ける事ができました。機会があれば、また参加させていただきたいと思いました。

なぜ日本ではチケット駆動開発が注目されるのか?

このたび、障害管理ツールJIRAなどで有名なアトラシアン様のブログにゲスト記事を投稿させていただきました。この記事は書籍「チケット駆動開発 」の共著者である小川さんの記事とあわせて翻訳され、海外でも紹介される予定です。

私の記事では、外国の方に「なぜ日本ではチケット駆動開発が注目されるのか?」という背景を説明しました。多くの方に読んでいただきたいので、このブログでも掲載しておきます。


なぜ日本ではチケット駆動開発が注目されるのか?

Makoto Sakai / SRA(Software Research Associates,Inc.)

近年、日本では書籍が 発売されるなど「チケット駆動開発」が注目を集めています。「チケット駆動開発」が注目されているのは、短期間に大規模開発が行われる日本独特のソフト ウェア開発の事情によるものです。しかしその利用方法を見ていると、チケット駆動開発によって、分散開発が可能な電子カンバン、チケットを中心としたコ ミュニケーション、ツール連携と情報の管理、ワークフローによるプロセスの自動化、などソフトウェア開発における制約を取り除く事を目的としているので、 日本に限らず広く応用が可能であることがわかります。この記事では、日本でチケット駆動開発が注目される理由と、どのように利用されているかについて説明 します。

チケット駆動開発

チケット駆動開発はBTS/ITSのチ ケット(issue)を用いてソフトウェア開発のタスクを管理する方法です。その基本的なルールは “No Ticket, No Commit!” と呼ばれ、BTS/ITSのチケットと構成管理を関連づけます。このルールの下で、チケットを中心にプロジェクトを運営する事で、以下のような効果が得ら れます。

  1. ツール連携と情報の管理
    • チケットの履歴と構成管理の関連付けによってメンテナンス性が向上する
    • 様々なツールの連携によって、情報を一元管理できる
  2. チケットを中心としたコミュニケーション
    • 不要なコミュニケーションが減るので、リズムが生まれて作業に集中できる
    • 内気なメンバーとコミュニケーションが容易になる
  3. 分散開発が可能な電子カンバン
    • 遠隔地であってもスムーズな情報共有が可能なので、変化に柔軟に対応できる
    • チームや個人の視点で報告を集計できるので、プロジェクト管理や自己管理が容易になる
  4. ワークフローによるプロセスの自動化
    • ワークフローによって、確認プロセスを自動化できる
    • 作業漏れ、確認漏れが防止できる

日本のソフトウェア開発の特徴

日 本においても、Webソフトウェアやゲームソフトウェアの開発ではアジャイル開発が多く行われています。しかし、開発上の制約によって、ウォーターフォー ルをベースとしたソフトウェア開発も多く行われています。これは、以下のような複雑なシステム、請負契約、開発標準、設計法が背景にあるからでと考えられ ます。

  • System of systemと呼ばれるような、複雑で大規模なソフトウェアが開発されている。
  • 複数組織で短期間に開発できる様に、仕様を確定した上で請負契約される(もちろん、仕様の変更も行われる)
  • 80年代よりウォーターフォールを基にした開発の標準化が進んでいる
  • DBMSを用いたデータ中心指向が重視されたので、オブジェクト指向の普及が遅れた

上記のような背景から、日本ではアジャイル開発に対するモチベーションの低い分野が存在していました。

なぜチケット駆動開発が注目されるか?

しかし、日本においても以下のような理由で、状況が変わりつつあるようです。

  • コストダウン圧力が高まり、事前の仕様決定に対するリスク予算が確保できなくなった
  • ビジネスニーズの変化に対して、自律的で機敏な組織の実現が求められている
  • ソフトウェアの多様化により、管理情報(ソフトウェアメトリクス)を統計的に扱う事が難しくなった
  • Rubyのような動的言語の普及により、逐次開発が必須になってきた

このようにアジャイル開発の導入が必要な状況になってきています。しかし、以下のような理由からアナログのアジャイル開発への移行ではなく、チケット駆動開発が注目されています。

  • 作業スペースが狭く、タスクボードやミーティングスペースの確保が紺案であること
  • ノウハウ不足による大規模開発屁への不安
  • 決裁権者や関連チームが別拠点に存在するなど体制上の問題
  • 管理情報の継続性を失う事への不安

チケット駆動開発の利用シーン

チケット駆動開発には以下のような特徴的な利用法があります。

1) 電子化・自動化されたアジャイル開発

制約が少なく、効率化されたアジャイル開発としてチケット駆動開発が行われています。テスト的にチケット駆動開発を用いてアジャイル開発の実績を示して、BTS/ITSを障害管理に利用しながらアナログなタスクカードに移行する場合も存在します。

2) 変更に機敏に対応できるアダプタブル・ウォーターフォール開発

仕様変更に関連するコミュニケーションや開発作業の効率化を目的としてチケット駆動開発が用いられます。プロセスが軽量化されることで、変更に機敏に対応できます。また、BTS/ITSのマイルストーンを用いて複数リリースに対応し、適応容易なプロセスを実現します。

3) 複数拠点での分散開発

分散開発での作業指示としてのチケット利用もチケット駆動開発と呼ばれる事があります。この場合は、必ずしも構成管理とチケットを連携ません。

4) ワークフローとファイルの関連付けを利用した業務システムへの応用

開発から保守に至るまでの課題(issue)をチケットで管理するDevOps的な利用のほか、IT全般統制や一般業務への利用が広がっています。

まとめ

「チ ケット駆動開発」のブームは日本固有の事情から生まれました。しかし、その利用シーンは特に日本に限ったものではなく、一般的なソフトウェア/システム開 発でも利用可能なものです。多くの事例によって効果的な利用方法が整理されれば、より広く使われる様になると考えています。

新技術に踊るなかれ!

熊とワルツを踊ってしまうエンジニアたちは、新しい技術に出会うと小躍りして喜んでしまいがちです。

アジャイルフィーバーによる死

この記事は面白いですが、これはアジャイルだけの話ではないと思います。

記事中にもUMLが出てきますが、同じようなことは、開発標準、メトリクス、CMMなどのブームにもありました。ソフトウェアの新技術が登場して、新しいブームが起きると、こんな人たちが現れ出します。

・知ったかぶり
 やったことがないのに、評論家気取り

・妄信
 これこそ、待ち望んでいたものだ。これしかない

・これさえやれば(銀の弾丸)
 今までとは違うんだ。過去の技術は捨てるんだ

・標準化
 みんなやりなさい。ルールだからと押し付ける

・教条主義
 本に書いてあるじゃないか、手抜きをするな

・守破離と言いながら
 まず守らなければ良さはわからないと、守らせ続ける

・とにかくやれ
 反論は許しません。俺に従え!

・まだ不十分だ
 効果が出ないのはきちんとやってないからだ

・ごまかし(データの改ざん)
 この結果はおかしい。こんな報告はできない

人間はついつい過ちを犯してしまうのです。プロセスを変更する際は、問題を見極めてそれにふさわしい技術を導入しないといけません。

しかし、危険なのはこのようなブームに踊るのが、技術者だけではないことです。技術者と同じ様に仕事を発注する側の人たちも、間違いを犯すことがあります。新しい技術なら、より安く、より良いものができるに違いないと思ってしまうのです。

こうなると、発注する際の条件や優遇のポイントにしてしまいます。開発側も、仕事が請けられるなら、会社としてはそれなりに利益が出ることから、会社の方針として新しい技術を持ち上げたり、表面的に実施するようになります。やがて、向き不向きに関係なくブームがブームを呼び、わけもわからず、社会現象になってしまいます。

ソフトウェア開発をする上で、長期的な視点で新しい技術への試みは必須です。しかし、流行りだからと導入するのでは、うまくいくはずがありません。正しく理解した上で、その技術を取り込む必要があるかどうか、冷静に判断する必要があるでしょう。

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


[#TiDD] チケット駆動開発に含まれるアジャイル要素

 チケット駆動開発はアジャイル開発と親和性が高く、電子化によってアジャイル開発を効率化できるほか、従来法にアジャイル要素を加えることも可能です。ここでは、チケット駆動開発にどのようなアジャイル要素が含まれているかをご説明します。

1. プラクティス

 チケット駆動開発にはアジャイル開発のプラクティスそのものが含まれています。

1-1) 電子カンバン
 チケットやその一覧であるレポートやグラフなどは、電子化されたカンバン(もしくはタスクボード)です。アナログな方法は俯瞰が容易ですが、電子化することで分散開発が可能になるほか、担当者や需要度など特定条件での表示や検索が容易になります。

1-2) イテレーション管理
 マイルストーンやバージョンを用いると、各イテレーションのチケットを管理できるほか、複数のイテレーションのロードマップを管理できます。

1-3) ストーリーカードとタスクカード
 チケットはストーリーカードやタスクカードとして利用できます。これらに親子関係をつけることできます(Redmine backlogsのように便利なプラグインもあります)。また、過去のカードの検索や再利用も容易です。

2. 価値

 また、チケット駆動開発は以下のようなアジャイル開発で語られる価値を生み出します。

2-1) コミュニケーション
 チケットやその通知(メールやRSSなど)を利用して、コミュニケーションが活発になります。

2-2) リズム
 チームと個人、イテレーションと日次という2重構造で、チケットに対する確認-計画-実施-更新と一連の作業が行われます。この周期がプロジェクトのリズムを生みます。

2-3) 集中
 日々の担当作業が明確になるほか、イテレーションやデイリーミーティングなど、割り込み作業を受け入れるタイミングができるので、混乱を防ぎ、作業に集中できます。

3. モチベーション

 チケット駆動開発はアジャイル開発に求められるモチベーション(動機)を満足させます。

3-1) ライトウェイトプロセス
 オンラインのホウ・レン・ソウ(報告・連絡・相談)により、管理業務を軽量化します。また、確認や承認のワークフローを自動化します。

3-2) ツールによる自動化
 タスクの管理と構成管理の関連付けや、CIツール実行時のエラーチケット発行など、ツールによる自動化を推進できます。

3-3) 管理チームから現場への大政奉還
 より良い製品を効率よく生み出すには、保証すべき品質は実装後に確保するのではなく、開発の初期から作り込まないといけません。これは、管理チームから現場への大政奉還です。

 品質保証に限らず多くの管理作業を現場で実施することで、自律的な組織ができます。組織的な改善活動だけでなく、プロジェクトに合わせた現場からの改善が可能になります。やらされ感をなくしてチームの最大限の能力を発揮できるでしょう。

4. まとめ

 このようにチケット駆動開発はアジャイル要素を多く含んでいます。チケット駆動開発によってアジャイル開発を実践すれば、効率化できる可能性があります。また、従来のソフトウェア開発に適用すれば、アジャイル要素を取り込むことが可能です。このほか、一度にアジャイル開発に移行できない場合に、アジャイル開発へのファースト・ステップとして利用することも可能です。

 対象のプロジェクトをどのように改善すべきか、ポイントを絞って始めれば、大きな効果が得られるでしょう。

[#TiDD] チケット駆動開発の落とし穴 - ベカラズとベシ -

BTS/ITSのチケットを利用して、プロジェクトのアジリティを高めることができるチケット駆動開発。チケット駆動開発らしいツールの使い方を理解した上で、プロジェクトの問題を見極めることができたなら、大きな効果が得られるでしょう。

しかし、そんなチケット駆動開発には、ついついはまりがちな落とし穴が存在します。ここでは、落とし穴にはまらない様に、してはいけないこと(ベカラズ)とすべきこと(ベシ)をまとめました。

1. ツールの導入が目的ではいけない

手段の目的化と言いますが、プロジェクトの問題をチケット駆動開発で解決する手段としてツールを導入することが、いつしか目的になってしまいがちです。Redmineやtracを導入しても、運用を考えて使いこなして、プロジェクトの基盤として根付かなければ意味がありません。以下の視点を持ち、チケット駆動開発らしくツールを使いこなしましょう。

ツールを活かして楽をする
よりシンプルな方向性は「ツールを活かして楽をする」ことです。開発現場の負担が減って余裕ができると、より柔軟な発想が可能になり、積極的にプロジェクトに参画できる様になるでしょう。

読み手のための記録
言われたからやるという義務的な記録や、これぐらいわかって当たり前、といった記録は役に立ちません。読み手の期待する者は何か、自分が読み手なら何を書いておいてほしいか、相手をを思い、コミュニケーションすることが、。

情報を活用する
チケットの情報を埋もれさせてはいけません。わからない情報では活用できませんが、チケットが活用されないならわからない情報が記録されてしまいます。思い出せない時や確信が持てない時は積極的にチケットを確認しましょう。チケットを活用すれば、どのような書き方が必要かも自ずとわかるでしょう。

2. 仕組みづくりにはまってはいけない

プロセスプログラミングは楽しいものです。ツールを使って効率化に成功すると、どんどんツール化を進めていけば、どんどんうまくいくような錯覚をしてしまいます。しかし、ツールの導入は新たなルールを生み出します。このため、チケット駆動開発の仕組みづくりをやり過ぎると、作業がおざなりになって、形式的な対応やいい加減な対応がはびこる様になり、やがて破綻するでしょう。自動化したのに仕事が増えるということは許されないでしょう。仕組みづくりの際は、以下のような点に注意してください。

問題を見極めてピンポイントで攻める
ソフトウェア開発の問題は様々です。人の話を聞くと同じような問題があると勘違いして、試してみたくなる者です。しかし、表面的な問題ではなく、最も重大な問題を見極めて、その解決を図りましょう。

完璧を求めると、柔軟性がなくなる
訓練すれば人間はミスをしない。なんてことはありません。人間である限り失敗をします。また、今は完璧だとしても、次のプロジェクトのメンバー、顧客、業務でも大丈夫だとは限りません。基本の仕組みをシンプルに作り上げ、プロジェクトに合わせてプロセスを適切にテーラリングすることが望まれます。

固いプロセスには、義務的、非効率、破綻が待っている
物事にはアソビが必要です。アソビは無駄ではありません。ホッとする瞬間に良いアイデアが浮かびます。仕組みに追いかけられて神経をすり減らしてはいけません。一度に全体を直すのではなく、協力しながら徐々に仕組みを作り上げたなら、より良い仕組みになるでしょう。

3. ツールを過信しない

ソフトウェアを開発するのは人間です。ツールによって様々な自動化が行われても、人間が関与しなければソフトウェアはできないのです。しかし、チケット駆動開発によって多くの情報が可視化されると、うまくコントロールできる様に思いがちです。しかし、基本は何も変わりません。

ツールは道具
チケット駆動開発によるプロセス改善は、問題を解決できる様にプロジェクトの文化を変える事が目的です。ツールはその道具であり、きっかけにすぎません。

できる人だと勘違いしてはいけない
ツールの支援があると、ミスが減り、作業効率が上がります。しかし、それは限定された作業です。ツールで支援されない作業は、今まで通りなのです。

理解が進むことはあるが、強制ギブスではない
ツールによって制約を与えることができますが、人間の失敗や怠惰は防げません。ツールを活かすも殺すも利用者次第なのです。ツールの支援をどのように活かせば良いか、そのことを正しく理解して積極的に取り組める環境づくりが必要です。

4. リーダーだけでは何もできない

チケット駆動開発はこっそりと始めることができますが、プロジェクトのメンバーの協力が必要になります。また、継続して実施する場合や、組織内に広めるには上司のコミットメントが必要になります。メンバーと上司の協力が必要です。

メンバーの能力を最大限に発揮する
メンバーは交換可能な道具ではありません。彼/彼女らはソフトウェア開発の主人公なのです。リーダーが頑張っても大したことはできません。みんなで問題意識を共有して、アイデアを出し合い、力を合わすことができれば、世界が変わります。そのためには、命令や注意をするのではなく、公平な作業分担や情報提供の環境を整えましょう。それは、上に立ち管理するのではなく、快適に働ける様に奉仕することです。

上司のコミットメントを得る
チーム内でチケット駆動開発を導入するにも上司の許可が必要ですが、サーバーを用意して他のチームに展開するには、上司のコミットメントが書かせません。チケット駆動開発がなぜ必要なのか、きちんと説明できないといけません。

5. まとめ

チケット駆動開発の落とし穴の説明をして、どのような視点が必要であるかを説明しました。簡単にまとめると、以下の4点になります。

  • BTS/ITSの活用が基本
  • 規律よりも柔軟性が勝る
  • 的確にツールを使う
  • 協調できる組織作り

このような観点でチケット駆動開発を始めるなら、書籍「チケット駆動開発」がきっとお役に立つでしょう。


[#TiDD] タスクマネージメントとは

タスクマネージメントとは何か、「Redmineによるタスクマネジメント実践技法 」のタイトルに入っているこの言葉は、ソフトウェア工学ではあまり使われていません。これは、アジャイルなチケット駆動開発を実践する場合、チケットをタスクカードの代わりに使うことから、チケット駆動開発という言葉の代わりに使ったからです。

この言葉は予想外に広がりました。「開発」ではなかったことから、いわゆる仕事術で語られる個人のタスク管理共関連づけられ、RxTstudy(Redmineやタスク管理を考える勉強会@大阪)ではタスクマネージメントの幅広い議論が行われています。

そこで(いまさらですが)、タスクマネージメントとは何かを定義してみたいと思います。オブジェクト指向の変数、構造、メソッドのイメージで、まずタスクに関するメトリクスと関係をリストアップし、どのようなマネージメントが実施されるかを示してみたいと思います。

1. タスクのメトリクス
・進捗(それぞれ工数、件数がある)
 - 総数(当初計画、実施中計画)
 - 総数のうち消化した数、実施数、残数
 - 上記組み合わせの比率(消化工数/実施中計画など)
 - ステータス
・優先順位(段階、順序)

2. タスクの関係
・親子(has-a、is-a)
・前後
・同一分類(モジュール、担当、報告者)
・クリティカルパス(全体の順序系列の中で最も時間のかかる系列)

3. タスクマネージメント
共通の操作:
・発見、収集、分類、分解(並列化、直列化)、集約、計画、実施、完了確認、廃棄

グループ管理
・リソース管理
 - 割り当て
 - 担当ごとの管理
・進捗管理

自己管理
・受諾、把握(議論)、見積もり、実施、状態更新、担当変更
・進捗管理

*進捗管理はそれぞれの視点でありますので、両方に入れました。

このように見てみると、グループでの管理と自己管理であまり変わらないのですね。違和感なく議論できるはずです。

もし、これ以外にもお気づきの項目があれば、ぜひコメントをお願いします。

[#TiDD] チケット駆動環境のコンポーネント

チケット駆動開発のようなチケット駆動の環境は、前述のチケット管理システムを中心に構築されます。この記事では、関連ツールを含めて機能の観点で整理します。

チケット駆動環境を三種の神器と言われるチケット管理システム(ITS/BTSなど)、バージョン管理ツール(Subversion, Gitなど)、CI(継続的統合: Jenkinsなど)ツールで構成した場合、以下の4つの機能から構成されていると考えられます。

1. プロセス管理
プロセス管理はチケット管理システムで実現されます。タスク(作業)の計画のほか、コメントやデータの更新履歴の管理、ワークフローなどチケットの状態管理が行われます。また、チケットは内部/外部ツールとの連携の中心になります。

2. 表示
これもチケット管理システムで実現されます。チケットの一覧のほか、特定の条件でチケットを抽出します。また、エクセルなどの外部のツールと連携できる様に、データの変換を行います。

3. データ管理
バージョン管理ツールでデータを管理します。データの保存や、特定バージョンの復元、あるタイミングでのスナップショットの記録、バージョン間の差分抽出のほか、ブランチのデータを統合できます。

4. イベント処理
イベント処理はCIツールで実現されます。一定時間ごとの定時処理のほか、コミットフックなど外部のイベントをきっかけにした処理や手動による処理の実行が可能です。処理は単純なコマンドだけでなく、スクリプトも実行できますので、ビルドや静的解析だけでなく様々な処理が可能です。

このようにチケット駆動環境は三種の神器を利用する事で、汎用的で柔軟な機構を実現できます。ツール間の連携のほか、定時処理、手動処理、スクリプトの実行によって、様々なプロセスを構成する事ができます。また、各ツールはプラグインのほか、APIやコミットフックの仕組みで機能を追加できます。

この記事ではチケット駆動環境の機能を説明しました。ツールを用いる事で柔軟かつパワフルな環境を構築できるだけでなく、外部のツールやプラグイン、スクリプトなどの外部コンポーネントによって、様々な機能を実現できます。

しかし、忘れては行けないのはプロセスを実行するのは「人間」である事です。人間は義務感に縛られると能力を発揮できません。また、一人では色々な間違いを犯してしまいますが、仲間の協力によってより良い方向に向かう事ができます。チケット駆動環境は、そのような人間の負担を減らして、チームの能力を最大限に発揮するために仕組みなのです。

[#TiDD] チケット管理システムはプロセス構築のUNIX

皆さんはUNIXをご存知でしょうか?私はチケット管理システムに、シンプルで柔軟なUNIXのような大きな可能性を感じています。

1. UNIXのフレームワーク

Linuxなら知っている、とか、BSDでしょ、と言われる方もおられるでしょう。UNIXとはMULTICSの反省からAT&Tのベル研究所で生まれたオペレーティングシステム(OS)です。軽量なOSでツールの組み合わせによって様々な作業ができる様になっていて、テキスト文書の処理はもちろん、当時としては高度な技術であった電子製版や言語処理が容易に行われる様になっていました。

その先進性は多くの開発者に評価され、バークレイ大学に引き継がれBSDが生まれ、やがてオープンソースになりました。また、学習用OSとしてMINIX、さらにLinuxが生まれました。

その大きな特徴はテキスト中心のツール群と標準入出力のフレームワークです。ツールは入力テキストを並べ替えるsortや文字列を検索するgrepのように単純なツールから、ストリーム編集するsed、構文解析ツールyacc、さらにはmailに至るまで多くの機能がありました。

これらのコマンドを実行する際のプロセスには標準入力、標準出力、標準エラー出力というファイルディスクリプタを持っていて、パイプという簡単な仕組みで、プロセス間の標準入出力をつなぐ事ができました。MULTICSのような巨大で複雑な仕組みではなく、小さなツールの組み合わせによって柔軟で多様な処理が実現できる様になっていたのです。

2. チケット管理システムのフレームワーク

チケット駆動開発で用いるチケット管理システムは、このUNIXに似ています。BTS/ITSなどのチケット管理システムはそれ自体も障害やタスクを管理するシンプルなツールです。しかし、そこで用いられるチケットがUNIX標準入出力の役割を果たして、多くのツールの連携を可能にするのです。チケット管理システムに内蔵するwikiはもちろんの事、メール、バージョン管理ツール、CIツールなど多くのツールと連携可能です。

ここで、注目すべきはこれらのツールが、ソフトウェア開発プロセスの構成部品である事です。チケット自身はワークフローを実現しますし、Wikiやメールはチケットと共にグループ作業を可能にします。またバージョン管理ツールとCIツールは、構成管理や継続的統合といった作業のプロセスを支援するツールです。

これまで、ソフトウェアプロセスの構築は、プロセス標準をドキュメントに記述して人間が実行することが当たり前に行われてきました。しかし、チケット管理システムを利用する事で、これらがツールの組み合わせによって自動化される様になります。チケット管理システムをフレームワークに、プロセスの部品を追加して目的の自動化プロセスを構築できるのです。

それらは単純な組み合わせだけでなく、コードレビューやエクセル連携をはじめとするプラグインによる拡張や、webAPIによる利用も可能です。これは単なる障害管理ツールではなく、最近の呼び方であるプロジェクト管理ツールの概念すら超えて、プロセス構築環境と言っても良いかもしれません。

チケット駆動開発の特徴は軽量なプロセスです。これまでの管理シートやチェックリスト、手作業によるテストやビルドなど、面倒で複雑なプロセスが自動化されます。それは、決まりきった仕組みではなく、プロジェクトに合わせて柔軟な構築が可能です。そこには、シンプルで柔軟なUNIXが発展したような大きな可能性を感じます。

3. まとめ

UNIXはOS(オペレーティングシステム)です。しかし長い間、本格的な商用データベースが利用できなかったUNIXは、汎用機のユーザーからはソフトウェア開発環境に過ぎないと見られてました。しかし、その後に機能を段階的に加えていき、コンパクトながらも多機能なOSに成長しました。

チケットシステムも長らく障害管理ツールとして認識されてきました。しかし、その機能は徐々に拡大されて、いまやプロセス構築を目的として広く利用されています。多くの利用方法があり、適用範囲もソフトウェア揮発だけでなく業務システムにまで広がっています。もし、チケット管理システムを未だに障害管理ツールとしてだけ使われているのなら、ぜひあなたのプロジェクトのより良いプロセス構築に利用してください。

[#TiDD]本を書く際の注意点(プロセス編) - 「チケット駆動開発」の経験から -

書籍「チケット駆動開発」の発売から2週間。いただいた色々なご意見から、反省点を基に注意点をまとめておきます。もちろん、多くの方にレビューもしていただきましたし、自信を持って出版しました。しかし完璧だと思っても、振り返るといくつかの反省点はあるものです。ここでは、主にプロセスの観点から注意点をまとめてみました。今後は電子出版が容易になる事から、インディーズ的な出版も増えると思います。本を書く際の注意点はこれだけではありませんが、初めて出版される方に少しでもご参考になればと思っています。

1.読者層の見極め
 どの読者層に向けて本を書くか、それによって本の構成や書き方が変わってきます。前作の「Redmineによるタスクマネージメント実践技法」の場合は、初めての方をかなり意識しました。そこで、まず後半を書き出してから前半を書いて、必要な用語の定義ができる様にしました。
 今回は著者らにとって2作目という事で、2つの戦略が考えられました。より入門的な内容にするか、より高度な内容にするかです。議論の結果、前作を踏まえて、説明が不十分だったより上位の内容を書く事にしました。そこで、「用語集」を最後につけることで伝えたい概念的な内容を一気に読めるようにしました。
 しかし、前作はRedmine、今回は方法論としての捉え方が一般的なようで、前作を読まれていない方も多いようです。初めてチケット駆動開発に触れられる方も多く、そのような方には少し読みにくい本となってしまいました。

2.タイトル
 内容を明確に示すタイトルにすべきです。元々は読者層を意識したタイトルを検討していたのですが、どれも座りが悪かったので、シンプルな「チケット駆動開発」としました。このタイトルは分野を表しているだけですので、人によって、「入門」「基礎」「のすべて」など色々な捉え方をされたようです。
 そのような期待に応えるには、チケット駆動開発の基本的な技術を個々に並べて説明する必要があると思います。しかし、チケット駆動開発の視点でBTS/ITSを用いて障害管理を実践すれば、基本的な技術は容易にわかるとの判断から、基本的なBTS/ITS技術の網羅はしていません。シンプルすぎるタイトルが招いた混乱の一つだと思います。
 (9/9追記:今、誤解を受けないタイトルをつけるなら「チケット駆動開発 アンサーブック」だと、思っています)

3.共著の場合は大きな単位で分ける
 著者が変われば文体が違いますし、一章の長さも変わります。文体は相互にチェックする事で、ある程度は修正できますが、一章の長さは調整できません。
 プログラムの保守の場合、変数やメソッドの分割などに癖があっても、同じ担当者の者だけを見ていればそれなりに意図が見えてきます。文章の場合もたぶん同じでしょう。もちろん、絵が少ないなどという基本的な問題もありますが、前作の様に前半と後半などシンプルな分ければ、もう少し読み易かったと思います。
 (全体をチェックする場合も多かったですが、担当分とそれ以外を分けて読む事も多かったです。その時のイメージが、この問題に気づきにくくしているかもしれません。もし本をお持ちなら、担当者ごとに読まれるとイメージが変わるかもしれません。)

4.構造的な問題はレビュアーには積極的に問いかける
 今回の出版に際して多くの方にレビューしていただきました(ありがとうございました)。レビューをしていただく場合、細かなチェックとともにゆっくり読まれる事や、やはり遠慮もある事から、構造的な指摘は出にくいようです。
 「チケット駆動開発」の第2部では、似たような内容を別の視点で複数の章に分けて書いています。冗長との指摘はこのあたりかと思います。この点が私自身も少し気になっていたのですが、特に指摘がなかったのでそのままにしてしまいました。しかし、前作同様に著者の方から質問をしていれば、結果が変わったかもしれません。

5.一貫性とバランスを考えた構造を保つには追加よりも削除
 「チケット駆動開発」ではレビュー後に追記をしています。大きな修正ではないのですが大事な修正です。このような場合、導入部と全体の一貫性や全体のバランスが崩れてしまいがちです。終盤になるとやはりリファクタリングが億劫になりがちですが、もっと勇気をもって全体のバランスのとれた構造を維持すべきでした。
 前作の場合、最後に大胆な削除をしてバランスを保ちました。追加よりも削除の方がバランスを保ち易いと思います。

6.構造的欠陥は指摘され易い
 文章の読み易さは、構造によって大きく変わります。特に一気に読まれる方は、構造上の問題や、それに起因する難解さが気になる様です。もちろん文章テクニックによって読み応えのある本にできるかもしれませんが、やはりアーキテクチャは重要です。

 たった2冊の経験から、執筆プロセスの注意点を書きました。もちろんこれだけではないですし、読み易くするための基本的な技術も重要です。今回は、滅多にない経験ですので、振り返る意味でまとめておきました。どなたかのご参考になれば幸いです。

 次回のRxTstudy(Redmineやタスク管理を考える勉強会@大阪)では、チケット駆動開発をどのように捉え、どのような発展を望んでいるかなど「チケット駆動開発」執筆に至った思いを発表する予定です。ご興味のある方は、ぜひご参加ください。

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