無料ブログはココログ

« 2010年9月 | トップページ | 2010年11月 »

アジャイルの定義 #agileto2010

アジャイルとかウォータフォールの議論をしていて、混乱する理由の一つが「言葉の定義」だと思っています。そんなことからアジャイルの定義を探していたのですが、Agile Tour Osaka 2010の牛尾さんの講演で明快に定義されていました。

方法論者がみんなで集まって共有できたのがアジャイル開発宣言で、それぐらいしか合意できなかった。これを実現すればなんでもアジャイルというものです。

なるほどと思って読み直すと、これまで私がアジャイルのつもりで行っていた開発だけでなく、お客さんがウォータフォールでと言っていた仕事の何割かは、まさにアジャイルでした。本来リリースは1回での依頼でしたが、無理な要望にこたえるためにリリース回数を分けさせていただきましたし、実行環境やアーキテクチャが不安なので、ものづくりを優先することもしばしばだからです(苦労してます)。

さて気になったのは、12の原則の一つ

「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」

というものです。「ビジネス側」という表現が微妙ですが、これからすると世の中のアジャイルプロジェクトと言われているものの何割かはアジャイルでなくなるのではないでしょうか?

結局、アジャイルは4つの価値にある「あたり前のマインド」で、ウォータフォールがロイス氏の論文などの議論(名古屋アジャイル勉強会)にあるように、単純なままでは「問題のあるとされているモデル」だからいつも議論がおかしくなるのでしょうね。

そうそう、牛尾さんの講演でもっとも印象的だった言葉は「ファイアーウォール」です。リーダはプロジェクトを混乱させない重要な責任を担っていると言うことだ再認識しました。

[#TiDD] チケット駆動開発の議論

Redmineによるタスクマネジメント実践技法 」が発売されて10日、Twitterでは色々な議論があるようです。オープンな議論が広がることを、著者の一人としてとてもうれしく思います。だいたいこのような議論があるようです(これまで発表してきた際意の議論を踏まえて再構成しています)。

チケット駆動開発の定義

  • BTSとSCMの連携
  • プラクティス
  • アジャイル開発法

実践法

  • オープン型はうまくいくか
  • チケットの棚卸し
  • チケット駆動でなくてもできるのでは

どのようにBTSを導入するか

  • 現場でさわぐ
  • トップダウンでないと難しい
  • Redmineか、Tracか

タスクマネジメント

  • WBSとの関係
  • タスク(チケット)の分け方

みなさんは、どのように思われますか?

これらに対する私の意見は、「Redmineによるタスクマネジメント実践技法 」やこのブログで書いているつもりです。しかし、それが唯一の答えではありません。言葉の定義や意見は、時代や環境で異なるのがあたり前だからです。それらをオープンに議論することで、より良い「チケット駆動開発」が生まれるのだと思います。ぜひ、皆さんのご意見をお聞かせください。ハッシュタグは「#TiDD」です(本に関しては「#redmine_taskmng_practic」)。

[Trac] csvでインポート、添付ファイルの一括ダウンロード、定番本

ここのところ久しぶりのTracでTiDDしております。Redmineと比べるなら

  「ほぅ」のRedmine、「なるほど」のTrac

と言う感じでしょうか。開発体制の違いが機能に現れているようです。

Tracのちょっと便利なプラグインを2つ紹介します(対象バージョンに注意してください)。

1.tracにCSVでチケットをimport「TicketImportPlugin」

プロジェクト立ち上げ時の一括入力、マイルストーンでの一括修正などが容易になると思います。

日本語解説

本家

日本語版

なお、インポート機能を使うユーザには、IMPORT_EXECUTE のパーミッションが必要です。

csvでは、うまく登録できない場合もあったので、きちんとライブラリを入れてExcelでインポートしたほうが良いかもしれません(並べ替えるとうまくいったり、一度入れてから更新するとできたりしました)。更新前に確認できるのが便利でした。なお、変更時には更新履歴が残ります。

2.Tracの添付ファイルを一括ダウンロード

Tracで添付ファイルの一括ダウンロード

プラグインを有効にした場合に、PACKAGE_DOWNLOAD権限が追加されます。この権限が割り当てられると、添付ファイルが登録されている場合には「ファイルを添付する」のボタンの横に「一括ダウンロード」ボタンが追加されます。

何度も使わないかもしれませんが、いざと言うときにとても便利です。

3.定番本

Trecといえば「Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」が定番本と言えるでしょう。

この本は入門書なので説明が優しいですが、時々深い事が書いています。このような本は読み直すと新しい発見があります。バージョンが古いのが少し残念ですが、定番本としてお勧めするならこの本ですね。

[#TiDD] 増えつつある感想・紹介「Redmineによるタスクマネジメント実践技法」

徐々に感想や紹介が増えています。皆さんありがとうございます。

wkoichiのバインダー
著者がブログで主張してきたことが良くまとめられていた。適度な図表も追加されているし、単発の記事が中心となるブログと違って構成も考えられているので、吸収しやすくなっている。
うちのチームは、ふりかえりによるプロセス改善とテスト戦略が弱みなので、参考にして改善していきたい。

目から鱗の語学学習法から、ネットワーク科学、技術書まで―― はてなブックマーク 新刊ピックアップ
2007年頃から堅調に注目を集めているオープンソースのプロジェクト管理システム「Redmine」。
(中略)
その解説書が翔泳社から出版されました。これまで、主に障害管理に利用されてきた「チケット」を、作業管理にも利用する「チケット駆動開発」が提案されています。現場で役立つように豊富な実例を交えて解説しているとのこと。

チケット駆動開発のススメ~No ticket! No commit
昔ながらのプロジェクトの場合、多くはExcelを使っているかもしれません。しかし、それでは片手落ちです。チケット駆動開発の本当の良さを発揮することができません。チケットを誰でもすぐに見える形で共有するからこそ価値があるのです。

チケット管理システムをつかってみよう!
もしあなたが複数人のプロジェクトに参加していて、まだチケット管理システムを使っていないとしたら、それはもったいない!本書をきっかけに、チケット管理システムを使ってみることをお勧めします。すぐにツールの恩恵を受けることができます。

書籍「Redmineによるタスクマネジメント実践技法」10月13日発売
Redmineそのものの使い方を解説した「入門Redmine 第2版 Linux/Windows対応」等とは異なり、中堅技術者向けにRedmineを使ってどのように開発プロジェクトを運用するのかを解説しているとのことです。

「Redmineによるタスクマネジメント実践技法」を読んだ
それにしても、「ツールでサポートすれば行動が変わる。行動が変われば考え方が変わる」というのはいい言葉ですな。うちのインフラやってるチームにも本書を薦めてみようっと。

Twitterにも多くの感想、つぶやきが流れています。Redmine、TiDDなどで検索してみると、色々な捉え方があって、感心しています。

@two_pack
オープン型の権限ポリシーだと、勝手に始まり勝手に終わるから管理側から見ると危険な気がしたが、そうすることでチケット発行が習慣にできるような気もした。

@kohsei
「Redmineによるタスクマネジメント実践技法」、先週のオールジュンク堂でなんと堂々2位でした!ちなみに、一位は「iPod touchパーフェクトガイド 2011」

@muryoimpl
Redmineによるタスクマネジメント実践技法 小川 明彦 amazon.co.jp/gp/product/479… これ今読んでる。うちの上位層も読め。頼むから

@junya
Redmineのプロジェクト管理本が出てたので少し読んでみたら、結構幅広く実践的に書かれてました。

#違う書籍の感想が混じっていたら、ごめんなさい。


#生めよ、ふえよ、地に満ちよ、
#(日本聖書協会 口語訳 創1・28)

[#TiDD] 出版裏話7:trac, mantis,すべてのBTSをお使いの方に

Redmineによるタスクマネジメント実践技法」をすでにお読みの方はお気づきだと思いますが、本書のターゲットはRedmineのユーザだけではありません(もちろん、タイトルにRedmineと入っているように、インストールの説明がないことを除けば、Redmineの基本的な使い方や、プラグインについてもしっかり載っていますので、Redmineの本としても満足していただけると思います)。

このブログで出版の案内をしたとき、

 史上初の「チケット駆動開発」の本が出版に

とタイトルにつけました。これには裏話があるのです。

この本の企画を検討していたとき、タイトルにRedmineを入れるかどうかの議論がありました。チケット駆動開発の環境として、ワークフローの設定やサブタスキングなど、Redmineはとても良い環境です。しかし、チケット駆動開発そのものはツールに依存するものではありませんし、そもそも提唱者のまちゅさんはtracを使われていました

しかし、タイトルにチケット駆動開発が入らないという大人の事情がありましたので、もう一つの売りであるRedmineがタイトルに入りました。

タイトルにあわせて、内容もRedmineの本として満足していただけるように構成しました。しかし、純粋なRedmineに依存しないチケット駆動開発の説明も入れたいということで、第1部に関しては、Redmineとは独立して一般的なチケット駆動開発関連の説明を書いています。

このほか、詳細目次を見ていただければ分かりますが、本の後半もすべてのBTSを使われている方にも参考にしていただける内容になっています。

Redmineじゃないからと思っておられたなら、ぜひ一度手にとってみてください。

#『行きなさい。わたしが、あなたを遠く
# 異邦の民へつかわすのだ』
#(日本聖書協会 口語訳 使徒22・21)

[#TiDD] チケット駆動開発はプロジェクト成功の3C(Commitment、Communication、Collaboration)を実現する

かつて、研究開発を目的として小さなチームのリーダをしていたときのことです。ちょうど、アジャイル開発の第1次ブームの頃でした。イテレーティブな開発をはじめとして、いくつかのプラクティスを取り入れました。しかし、それなりに開発は進むものの「すごい」とか「これだ!」と言う感じはありませんでした。

その理由を考えると、明確な顧客がいなかったなど、他の理由もあると思いますが、一番大きかったのは、

  • エクセルシートをタスクボードとして使った

ことだと思っています。

タスクボードと言うのは、カード化されたプロジェクトのタスク(タスクカード)を貼っておくボードです。残念ながらそのボードを置く場所がなかったので、最初の列にタスク、残りの列に、予定、実施中、完了のステータスを示したものでした。

見た目の機能的にはタスクボードと変わらないのですが、これが大きな間違いでした。今から思えば、このような状況でした。

  • シートを更新するのはリーダの作業になってしまった
  • メンバーがシートを見るのは、週次のミーティングだけだった
  • タスクの粒度が大きかったので、作業に緊張感がなかった
  • 開発者はプロジェクトの状況を把握していなかった
  • 担当作業以外に興味を持たず、他のメンバーに協力しようとしなかった

もちろん、すべてのメンバーがこのような状況ではなかったのですが、なんとなくサラリーマン的で、どうもうまくいきませんでした。

プロジェクトと言うのは「みんなで攻めている」という感じが大切だと思います。みんなで、「いけるぞ、やったるぞ、まかせとけ」、といった雰囲気があれば、大変なプロジェクトでも最高のパフォーマンスを出すことができると思います。

もちろん、精神論でどんなプロジェクトでも何とかなるわけではありません。しかし、みんなが後ろ向きになっているプロジェクトがうまくいくはずがありません。与えられたリソースで、最高のパフォーマンスを出すのがリーダの仕事ですから、メンバーのやる気を引き出すことが大切です。今から思えば、その観点が不足していたのだと思います。

チケット駆動開発はプロジェクト成功の3C(Commitment、Communication、Collaboration)を実現します。チケットはタスクカード、BTSはタスクボードです。BTSのチケットをタスクマネージメントに用いれば、プロジェクトの状況をみんなで共有することで、以下のことが可能になります。

  • 担当作業に責任を持って実施する(Commitment)
  • プロジェクトの状況を把握する(Communication)
  • お互いに協力する(Collaboration)

チケット駆動開発の良い点は、難しくないことです。容易に導入し、これらのことを簡単に実現できます。それは、アジャイルでも従来型の開発でもかまいません。

# I will put my instructions deep within them,
# and I will write them on their hearts.
# Jeremiah 31:33 (New Living Translation)

[#TiDD] 好評「Redmineによるタスクマネジメント実践技法」お早めに!(追記+)

おかげさまで、あきぴーさんとの共著の「Redmineによるタスクマネジメント実践技法」が好評です。アマゾンでは書籍全体のランキングで342位まで上がりました。みなさま、ありがとうございます。

Amazon_342

地元京都の書店を何軒か見てきました。

  • ブックファースト(四条河原町) 1冊
  • ジュンク堂(BALビル)      3冊
  • ジュンク堂(四条烏丸)      0冊

不思議に思って、四条烏丸のジュンク堂で検索したところ、15日には2冊あったようですので、売り切れていたようです。

「Redmineによるタスクマネジメント実践技法」の初刷部数はそれほど多くないので、書店で確認される方は、早めにしていただいた方が良いかもしれません。

10/17追記

京都駅周辺では以下の様子でした。

  • 大垣書店京都駅前店(イオンモール):3冊
  • アバンティ京都:3冊(面陳列:表紙が見えるようにおいてありました)

10/20追記:

大阪梅田周辺では比較的潤沢にあるようでした。

  • ジュンク堂(堂島店):11冊(面陳列)
  • 紀伊国屋(阪急梅田下):6冊(平棚)
  • ヨドバシ梅田:不明(見つけられませんでした)

[#TiDD] チケット駆動開発で「紺屋の白袴」から脱却する

「紺屋の白袴」とは白い生地を紺色に染めることを生業にしている紺屋が、自分のことには手が回らずに白いままの袴(はかま)をはいている様子です。ソフトウェアの開発と言う仕事は、ソフトウェアによってお客様の業務を改善することが仕事ですが、ソフトウェア開発の業務はあまり改善できていないのではないでしょうか?

紙の時代

かつて計算機が高価だった頃、ソフトウェア開発に計算機を利用できるのはコンパイルだけでした。若い方には信じられないかもしれませんが、コーディングでさえもコーディングシートと言われる紙にプログラムを書く工程で、その入力さえも「パンチ屋さん」に依頼するという徹底振りでした。幸か不幸か私は頼んだことはありませんが、同期入社の知り合いはパンチ屋さんから受け取った磁気テープから大切そうにプログラムをローディングしていました。

そのようなコーディング工程を効率化するには、書き直しを少なくすることが重要で、上流できちんと設計してレビューすることが重要でした。ちなみに当時の詳細設計はフローチャートやHIPO、PAD、HCPチャートなどでした。紙に書かれた処理フローをレビューし、レビューシートという紙で管理する時代でした。もちろん障害(バグ)の管理も、紙の表でした。

当時は計算機のCPUタイムが高かったので、それが合理的でした。当時は、汎用機に比べて安価な(と言っても1億円ぐらいの)、MIPS原器と言われたVAXというミニコンでさえも何十人もが同時コンパイルすると、8ビットのPCの方が早いぐらいでした。より高価な汎用機では、紙を中心に開発を進める事も仕方のないことだったのでしょうね。

電子化の現代

時は流れ、1人月のコストで何台ものPCが買える時代になりました。サーバPCでもそう高価ではない時代です。しかし、管理は紙あるいは類似の形態のままのところが未だに多いでしょう。エクセルファイルの共有は行われるようになりましたが、既存の紙がそのまま電子化されただけです。

われわれソフトウェア技術者の仕事を考えると、これだけでは「紺屋の白袴」ではないでしょうか?お客様の仕事を電子化するだけが仕事なら、それで満足しても良いでしょう。しかし、電子化して、問題をなくす、業務を効率化する、未来につなげる、というのがわれわれの仕事であるなら、ソフトウェア開発もそのように改善できるのではないでしょうか。

チケットの現代

さて、今となってはコンパイルだけでは、余りあるCPUパワーをどう使えばよいのでしょうか?もちろん、個人の環境を支援するためにEclipse環境を整える、生産性を高めるためにフレームワークを導入するなど、色々あると思います。ここでは、組織の業務か依然としてチケット駆動開発で考えられるいくつかのパターンを、過去の記事から引用します。

一つは問題を改善するという考え方です

面倒なことを任せる

個々人の能力を伸ばす

このように、チケット駆動開発には、コンピュータを利用して業務を改善する力があります、特に最後の能力を伸ばすと言うのは、チケット駆動開発の特徴的ナ効果だと思います。一人ではできないことも、みんなで協力すればうまくいく。これが困難なソフトウェア開発において、「紺屋の白袴」から脱却する方法だと思います。

#おおよそ、持っている人は与えられて、いよいよ豊かになるが、
#持っていない人は、持っているものまでも取り上げられるであろう。
#(日本聖書協会 口語訳 マタイ25・29)

[#TiDD] 出版裏話6:「Redmineによるタスクマネジメント実践技法」 販促チラシ

「Redmineによるタスクマネジメント実践技法」の販促チラシ(PDF)ができました。ぜひ、お知り合いにもご紹介ください。

近頃は、書籍のチラシを見ることも少なくなりましたが、出版社のご好意で作っていただけました。ありがとうございました。

# Go into all the world and
# preach the Good News to everyone.
# Mark 16:15 (New Living Translation)

[iPhone] メールdeプリント(AirPrint)対応 HP Photosmart Wireless B110a

11/23追記:AirPrintの利用記事はこちらの記事 をごらんください。

最近、iPhone/iPad/iPodで印刷をサポートするAirPrintの発表がありました。この発表によると

ePrintに対応する、HPの現行ならびに今後発売されるプリンターが、iOSデバイスからのダイレクト印刷をサポートする最初の製品になります。

とのこと。新製品のプリンタでなく、現行ということで調べてみると「メールdeプリント」という機能がその機能のようです。このB110aは1万円を切る値段でありながらも、「メールdeプリント」をサポートしているようです(今年の10月下旬と11月中旬に新機種が出ます)。しかも、無線LANまでサポートしています。

今まで使っていたPSC2310が、たまに異音がしていたところにインクが切れたので、思い切って買いました。結果はまずまずです。

良かったところ

  • 無線LANなので、広いところで設定や確認をしておいて、設置場所に運べる。電源のあるところならどこでも良いのは新鮮でした。
  • メールdeプリントは便利。画像のほか、テキスト、PDF、Office文書も出力できます。画像はプレミアムフォト用紙ならばっちり、普通紙もそこそこ。それ以外の印刷も若干品質が落ちているようにも思えますが、特に問題ありません。
  • HP社のサーバに一度ためるのですが、無料で、しかもスプールしてくれます。接続が切れていなければ、すぐに印刷されます。
  • 対象のメールアドレスが登録できる。いたずらプリントの心配がありません。
  • なぜか、カバンが付いてきます。ケーブルを入れる小物入れもあり、運んで使うことを考えているようです。合宿やシンポジウム等には役に立つかもしれませんね。
  • ピカピカしていて、高級感があります。前の機種はちょっとダサすぎでした。
  • 動作音もそれほどでもない軽い音で、以前より気にならないように思います。

イマイチなところ

  • ソフトがまだこなれていない感じがします。たまに設定ボタンが聞かないことがあり、インストール中や設定時に再起動をすることがありました。再起動すると直るので、メモリ関係でしょうか。
  • メールdeプリントでは、拡大縮小、ページ指定、配布資料印刷など、細かな設定ができません。写真のL版印刷ならばっちりですが、A4でも小さく印刷されました。これは、AirPrintアプリに期待しています。
  • 結果がメールで来る。印刷を依頼したところでなく、登録したメールアドレスに来ます。便利なような不便なような、、、
  • 電源を切ると接続までに時間がかかる。スリープ中ならメール後に1分もしない(30秒程度)で、印刷が始まります。設定後に電源を抜いたままにしていたら、なかなか印刷できませんでした(めったにしないので気にしていません)。
  • 最初の黒インクが小さい。値段が値段なので仕方ありませんが、、、

トータルではお買い得、買って良かったと思っています。写真はすぺてメールdeプリントです。写真の写真ですし、補正もていますので、実際の方がきれいです。

B110a

[#TiDD] ソフトウェアプロセスも複雑なソフトウェアである

マイルストーン重要

プログラマの思索に掲載された「バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠」に、ショックを受けました。記事内容がどうとかではなく、記事に出てくる「彼」と,
Twitterで賛同の声があったことです。

「マイルストーン」を適切に定めるなどということは、かなり昔から、少なくとも80年代半ばまでには言われていました。いつまでに何をやるかという短期目標(一里塚)をはっきりしなければ、プロジェクトは糸の切れた「たこ」のようになってしまいます。

プログラムで言うなら、クラスや関数に分割されない一本のプログラムのようなものです。少しでもややこしいことをするならスパゲティプログラミングになってしまいます。

ソフトウェアプロセスもソフトウェアである

このように考えて、あることに気付きました。それは、オスターワイルの

「ソフトウェアプロセスもソフトウェアである」

という言葉があまり知られていないことです。SRAの記事によると1987年のICSEの基調講演で述べられた(実際はプロセスに関する国際ワークショップであるIWSPでの発表が元だと思います)。この発表は、その後のプロセスプログラミングとプロセス改善に大きな影響を与えたとして、1997年の第19回ICSEで表彰されました。

この“Software process are software too”という言葉は、多くの人のイマジネーションを刺激しました。特にプロセスのモデリング(プロセスプログラミング)の分野では、どのようにプロセス記述言語が必要であるかが議論されました。プロセスのモデリングは、本来コミュニケーションや伝達、検証、支援、自動実行などがを目的としていました。しかし、人間の実行するプロセスは、実行途中で中止、変更、分割などが生じるので、その記述言語は、どんどん複雑なものになっていきました。

プロセスの観点でソフトウェア開発を支援するはずが、開発するソフトウェアよりもプロセスの記述が複雑になっては使い物になりません。複雑な記述が可能な記述言語が発表された後、いつしかプロセスプログラミングは、話題にならなくなりました。

ソフトウェアプロセスも複雑なソフトウェアである

このような歴史を振り返ると分かることがあります。

「ソフトウェアプロセスをソフトウェアとするなら、それは複雑なソフトウェアである」

ということです。

その観点で最初の議論の戻ると、多くのことが見えてきます。最初に書いたように、全体を一つにまとめてしまうのは言語道断です。複雑なプログラムなら、細かな単位に分割して、開発が容易な形で開発しないでしょうか?同じことがプロセスにも言えます。上述のマイルストーンやWBSはそのためのものです。

さた、あなたが複雑なプログラミングをするなら、どうするでしょうか?

  1. 機能的で明確な処理ならトップダウンに分割して一気に開発する
  2. 技術的に不明な点があるので、段階的に開発する
  3. 独立した複数のアプリケーションに分けるなど、アーキテクチャを工夫する
  4. 完成したものを一つずつ確実に確認する
  5. カプセル化して独立した開発を行い、うまく連携させる

それぞれ、1は外科医チームやウォータフォール、2はスパイラルモデルやアジャイル開発、3はシステム・オブ・システム、アジャイル・リリース・トレイン、スクラム・オブ・スクラムなどになるでしょう。また、チケット駆動開発なら、4はワークフロー型、5はオープン型の運用にあてはまるでしょう。

チケット駆動開発は、チケットによるプロセスのモデル化でもあります。チケット駆動開発には様々なプラクティスがありますが、プロセスプログラミングという観点で考えてみると、新しい発見があるかもしれません。

#Clear the road for him!
#Matthew 3:3 (New Living Translation)

[#TiDD] チケット駆動開発の開始タイミング - 良いプロダクトはふさわしいプロセスが生む -

かつてCMMがブームの頃「良いプロダクトは良いプロセスが生む」といわれていました。いわゆるステージドモデルの高いレベルが良いとされていましたが、その後、SPICEのマトリックスモデルを取り入れて、組織にあったプロセス改善がより容易にできるようになりました。このことからも分かるように、プロセスは開発組織のものであり、開発対象、開発メンバー、文化等によってふさわしい「良いプロセス」は異なり、「ふさわしいプロセス」と考えた方が良いと思います。

CMMの憂鬱

CMM/CMMIはそれまでのソフトウェア工学を体系化して、体系化した人たちの基準で良いプロセスを実現することをまとめたものです。その基準はDoD(米国国防総省)によって設立されたSEIの視点です。つまり、信頼性の求められる大規模開発で、どのような開発が行われたかが確認できることです。そして、CMMの本として知られる「ソフトウェアプロセス成熟度の改善」の序文には“「ソフトウェア危機」は死んだ”とまで書かれています。

この言葉はある意味正しく、ある意味で不正確です。この本の書かれた当時(英語版が89年、日本語版が91年)は、「ソフトウェア危機」(リンク先はWikipedia)は「人月の神話」に示された大規模開発システムの対策が中心だったからです。

しかし、リンク先のWikipediaを見てもらえれば分かるように、「ソフトウェア危機」中小規模開発においても生じうる問題です。すべてのプラクティスの実施にこだわらなければ、小規模プロジェクトでも有効です。亡くなられた坂本さんは、CMMのレベル到達でなく、現場の問題を解決するプラクティスをCMMから探し出して、プロセスを改善されていました。また、この改善の仕方を当時のCMMのアセッサに確認されたところ、それはCMMによる改善法として正しいとのコメントを得られたそうです。

つまり、プロセス改善とは「プロセスの問題を改善すること」で、CMMでもそれを否定していなかった。しかし、ステージドモデルが分かりやすく、レベルの達成がプロセス改善と多くの人が誤解した。あるいは、レベル達成を営業的に利用したことで、話しがややこしくなったのだと思います。

ハードなプロセス、ソフトなプロセス

ソフトウェア開発の歴史を振り返ると、ソフトウェアはハードウェアの開発にあこがれていたと思います。各社が「ソフトウェア工場」を作り、ソフトウェア開発の工業化を目指していました。

工業化における品質とは主に信頼性です。計画された仕様が満たされたかどうか、設計どおりに実現されているか、それが求められます。当初定められた計画通りにできることを重視する、それをここではハードなプロセスと呼びます。

しかし、近年のソフトウェアに求められるものは、そのようなハードなプロセスでは実現が難しい柔軟な対応です。作ってみないとわからない仕様や、日々変化する実行環境とビジネスに対応できるソフトウェアです。

アジャイルソフトウェア開発は、そのような変化に対応できる開発法です。ここでは、ソフトなプロセスと呼んでみましょう。XP(eXtream Programming)の最初の本である「XPエクストリーム・プログラミング入門」のタイトルには「ソフトウェア開発の究極の手法」とされています。あたかも、このソフトなプロセスによれば、すべてのソフトウェア開発がうまくいくようにも読めます。

しかし、ソフトなプロセスはそんなに簡単ではありません。「アジャイルと規律」の5つの重要要因にあるように、人、文化、対象による判断が必要ですし、「リーンソフトウェア開発」の決定をできるだけ遅らせるというプラクティスで分かるように、イテレーションをどのように構成するか、単純な優先順位だけではうまくいかないのです。

ふさわしいプロセス

様々な要因を考慮するなら、純粋主義者の解釈のような二元論にはなりません。CMM/CMMIをベースにすることも、アジャイルのプラクティスを徐々に導入することもあるでしょう。いずれにしろ、すべての要素を考えてプロジェクトにふさわしいプロセスを実現しないといけないのです。

チケット駆動開発は、このいずれにも有効です。細かなタスクの管理、見える化やコミュニケーションの支援、をするとともにアジリティを高めるからです。詳しくは「Redmineによるタスクマネジメント実践技法」に書いていますが、その元になった記事と補足を紹介しておきます。

チケット駆動開発を開始するタイミング

プロセスの変更は危険なものです。安易にプロセスを変更すると、予期しない問題が生じる場合が多く、注意深く変更すべきです。本来なら余裕のあるプロジェクトで、試行してから実施すべきです。上の「元気が出るチケット駆動開発」の元となったプロジェクトでも、当初はチケット駆動開発を導入しない予定でした。しかし、細かな問題が発生し、このままではうまく行かない状況になって導入を決意しました。BTSの利用にはすでに慣れていましたので、副作用もあまりなくメリットの方が大きいと判断しました。

このように「確信をもてたとき」が導入するタイミングだと思います。ソフトウェア開発は個人のものではありません。顧客、開発会社、開発者のすべてがWin-Win-Winになる事が目標です。正しく理解し、ルールを守り、慎重に、そして的確に導入してください。

#こんなごく小さな事さえできないのに、
#なぜ、ほかの事まで思い悩むのか。
#(日本聖書協会新共同訳 ルカ12・26)   

[#TiDD] 出版裏話5:「Redmineによるタスクマネジメント実践技法」 詳細目次

どこまで公開してよいものかと思っていたのですが、翔泳社オンラインショップで詳細な目次が公開されていたので、ここでも公開します。本当はもっと内容があったのですが、あまりにもページが増えたので何節かを削除しています。今回は、そのときのことを書こうと思います。

この本の特徴は、共著者のあきぴーさんの人脈でたくさんのレビュアをお願いしたことです。チケット駆動開発の提唱者であるまちゅさんをはじめ、「JUDEで学ぶシステムデザイン」の著者で出版のきっかけを作ってくださった細谷さん、オープンソース開発にRedmineを使われている黒田さん、TEF関西でおなじみの仲さん、そして、説明不要の平鍋さんと倉貫さんにはレビュアのほか「まえがき」まで書いていただきました。

書いている本人は、熱くなっているのですばらしい本になったと勝手に思っているのですが、やはり色々な方にレビューしていただくと多くの指摘をいただきました。おかげさまで、かなり改善することができました。(どうもありがとうございました。>レビュアの皆様)

泣く泣く削除する際も、削除の候補のうちどうしても残した方が良いもの、逆に消したほうが良いもがあれば教えてください、と質問をさせていただきました。結局、削除候補以外の削除した方が良い節はなく、逆に削除候補からは「残してほしい」とレビュアの方からのお言葉をいただいて復活した節があります。この件で、少しは自信を持つことができました。

出版が近づいて、まえがきを書いていただいたお二人にはTwitterやブログで紹介していただけたました(重ねて感謝します)。なんとか人に紹介していただけるレベルになったのかとほっとしています。特に平鍋さんの「チケット管理システムをつかってみよう!」は感動的な紹介ですので、ぜひお読みください。

----- 目次 -----
はじめに
まえがき -平鍋健児-
まえがき -倉貫義人-

プロローグ -開発現場で試行錯誤した経験談-
   Redmine導入前の問題点
  Tracは使いこなせなかった
  Tracによるチケット駆動開発
  Redmineによるチケット駆動開発で運用を工夫した点
  Redmine導入後
  Redmineによるチケット駆動開発でさらに気付いたこと
  Redmineによるチケット駆動開発の可能性
  まとめ

第1部 チケット駆動開発技法 -BTSによる作業管理-
 第1章 障害管理ツール(BTS)
  1.1節 ソフトウェア開発の難しさ
  1.2節 BTSの歴史
  1.3節 オープンソースBTSが選ばれる理由
  1.4節 障害管理の目的
  1.5節 障害管理からチケット管理
 第2章 BTSとツールの連携
  2.1節 構成管理ツール
  2.2節 構成管理ツールの歴史
  2.3節 ブランチとメインラインモデル
  2.4節 他の支援ツール
 第3章 チケット駆動開発 -チケットによるタスク管理-
  3.1節 チケット駆動開発が生まれた背景
  3.2節 チケット駆動開発の誕生と発展
  3.3節 チケット駆動開発とは
  3.4節 TiDDのチケット
  3.5節 BTSのチケットの特性
  3.6節 チケット駆動開発とソフトウェア工学
  3.7節 Redmineの構造とWBS
  3.8節 チケットの候補
  3.9節 コミュニケーションと見える化
  3.10節 日々のプロセス
  3.11節 マネジメントとトレーサビリティ
  3.12節 見えるものは制御できる
 第4章 チケット駆動開発(TiDD)のはじめかた
  4.1節 チケット駆動開発の運用方式
  4.2節 チケット駆動開発の権限ポリシー
  4.3節 [事例]下流工程でのチケット駆動開発
  4.4節 [事例]XPのプロセス改善
  4.5節 TiDDはプロジェクトのアジリティを高める

第2部 Redmineによるタスク管理
 第5章 Redmineの運用方法
  5.1節 Redmineの特徴
  5.2節 Redmineのインストール
  5.3節 チケット駆動開発の運用サイクル
  5.4節 Redmineチケットの概念モデル
  5.5節 Redmineチケットの状態遷移
  5.6節 Redmine運用フロー
  5.7節 有用なRedmineのプラグイン
  5.8節 バージョン0.9の新機能
  5.9節【速報】最新バージョン1.0.1
 第6章 Redmineの高度な使い方
  6.1節 チケット
  6.2節 バージョン
  6.3節 プロジェクト
  6.4節 ワークフロー
  6.5節 レポート出力
 第7章 チケット駆動開発の実践的な運用方法
  7.1節 アジャイル開発と組み合わせて運用する方法
  7.2節 並行開発と組み合わせて運用する方法
  7.3節 チケット駆動開発のプラクティス
 第8章 チケット駆動開発を発展させるアイデア
  8.1節 PMBOKのEVM
  8.2節 測定できれば制御できる
  8.3節 Redmineと外部ツールを連携
    8.4節 ITILと組み合わせて運用する方法
    8.5節 大規模プロジェクトで運用する時の注意点

第3部 RedmineとTestLinkの連携
 第9章 TestLinkの運用方法
  9.1節 TestLinkの概要
  9.2節 TestLink運用前のテスト工程における問題点
  9.3節 TestLinkの概要モデルと運用サイクル
  9.4節 TestLinkの運用例
  9.5節 TestLinkの運用後
  9.6節 TestLink運用のまとめ
  9.7節 TestLinkのプラクティス

エピローグ -チケット駆動開発の魅力-
参考文献
参考資料
索引

#とか書いていると、あきぴーさんに先を越されました
#(Redmine.jpの紹介記事まで書いてるし、、)。orz


# Because God's kingdom is already among you.
# Luke 17:20-21 (The Message)

ブルーレイDIGAの使いやすさに学ぶ

以前紹介した機能を絞ったかんたんリモコン「シンプルリモコンDY-RM10」がグッドデザイン賞を受賞したそうです。これだけのユーザインタフェースを作りこむのは、中の人も大変だったと思いますが、良いものはきちんと評価されるのですね。おめでとうございました。

ソフトウェアの研究ではノーベル賞が認められることはなく、チューリング賞が最高の賞だと言われています。そのようにソフトウェアが恵まれない中で、今回のソフトウェアも含めての受賞は、ソフトウェアに関わる多くの人にも勇気を与えると思います。

シンプルリモコンは、ビデオテープをイメージするシンプルなユーザインタフェース(UI)だけでなく、ソフトはあらかじめ機器に入れて出荷しておき、別売のリモコン(BR-590は同梱)を買うと専用インタフェースが使えるようになるというアイデアもなかなか面白いと思います。

今日紹介するのは、シンプルリモコン以外のDIGAの使いやすさです。DIGAのUIは、多くの属性を持つユーザビリティとかユースフルネスという言葉ではなく、「使いやすさ」がふさわしい表現だと思います。

1.メリハリ

使いやすいからと言って、機能が少ないわけではありません。マニアックなことには限界がありますが、一通りの機能がそろっています。なので標準のリモコンのボタンも、それなりの数があります。そのような中で使いやすくするには、メリハリです。主に使うのは「番組表」と「録画一覧」、「スタート」です。このうち、番組表が強調されていて、操作の中心であることが分かります。

この番組表が良くできていて、予約済みが分かるだけでなく、番組表から予約変更ができます。録画一覧は、毎週などの予約単位でグループ化されて表示されます。スタートは全体のメニューをツリー表示します。

このようにまとめると、WebのUIと似ていることに気付きます。かつて視線追跡装置を使って、Webのユーザビリティテスティングをしたことがあります。そのときに、2つの発見をしました。

a) メニューが二つあると混乱する

Webで良くある使いにくいページは、左に大きなメニューがあって、さらに上にも大きなメニューがあるパターンでした。慣れていないユーザは、どちらのメニューに探しているページがあるか分からないので、混乱しているようでした。一方がメインであることを示して、そのメニューが良くできていると使いやすいのですね。

b) サイトマップは予想外に検索が早い

予想外に速く目的のページを探すユーザがいました。このユーザは、常にサイトマップを参照して、目的のページを探していました。シーケンシャルアクセスよりもランダムアクセスの方が早いのはあたり前ですね。

DIGAには「予約確認」などという気の利いたボタンもありますが、分からないことは「スタート」ボタンから探すと良いのかもしれませんね。

2.デフォルトがおまかせ

録画予約をする際には、多くの設定が可能です。しかし、それは必要なときだけであって、普段は簡単に録画したい、それが実現されています。メニュー階層の上のほうで、それが分かれていて、簡単に録画するメニューの方にはほとんど設定項目がない様にできています。

少し残念なのは、DIGAの特徴である更新予約です。更新予約すると、毎週あるいは毎日の予約が上書きされます。この設定をすることで、録画した番組を消さなくて良くなるので、お気に入りの設定です。しかし、この更新予約は多くの設定である「詳細設定」に入っていて、簡単には設定できません。

この詳細設定が状態を持つので、操作数が増えてしまうのです。一通り詳細設定した後にパソコンだとOK/キャンセルとなるところが、設定を保存するメニューになっていて一般にも分かりやすい様にはできています。しかし、ここは常に更新しておいて、キャンセルボタンだけ用意してほしいところです。まあ、メニューの組み合わせや操作間違いへの対応など、現状のメリットもあるでしょうから仕方のないところなのでしょうね。

3.オブジェクト指向

やっぱりボタンは機能やデータの名前でないといけません。カタログスペックでは目立たないかもしれませんが、「番組表」と「録画一覧」は分かりやすいです。

また、番組表から予約の変更ができるのは、とても使いやすいです。内部的にオブジェクトがどう実装されているのか興味があるところですが、ユーザにとっては予約済みという予約の情報が見えているのですから、そこから変更できるというのは普通、つまり、オブジェクト指向ということなのでしょう。

(注:かつてSEA関西でオブジェクト指向の講演があったとき、とある障がい者をPCで支援する団体のNねぇから「オブジェクト指向って、普通に作るって事なんやね」との名言が発せられました。上記の文章はそのような言葉を踏まえています)

4.マニュアルを見たのは2回

UIが良くできているので、マニュアルを見たのはこの1週間でたった2回です。一度目は、シンプルリモコンを使う前に見たシンプルリモコンの操作説明書で、家族にも使えることを確認したときです。これは今から考えれば、必要ありませんでした。

もう1回は、録画モードを確認したときです。見慣れたモードもあったので予想は付いたのですが、高品質で録画できることを確認しました。

以前に使っていたのレコーダだと、2つのチューナーそれぞれに可能なことが異なり、マニュアルを良く見ていました。DIGAは機種固有の知識はほとんど要りません。とっても快適です。

追記:

ユーザビリティ(リンク先はWikipedia)というと学習容易性を含みます。本来は対照的なメニューや一貫性のあるメニューの方が理解が容易なはずで、学習容易性が太古とになります。それを捨てて使いやすさを求めているブルーレイDIGAの作りこみはすごいと思います。

[#TiDD] チケット駆動開発は小規模プロジェクトの憂鬱をきっとなくしてくれる。

ソフトウェア工学では、古くから大規模ソフトウェアが研究対象とされてきました。しかし、実は80年代から小規模であっても困難なソフトウェア開発は存在していました。当時から規模が小さいプロジェクトでは、大規模開発と同じように開発環境や、各種管理、体制作り、による支援を行おうにも、小規模開発の予算では負担が大きく実施できなかったので、混乱した小規模開発プロジェクトは一時しのぎの対応が行われるだけで、放置されてきました。

その問題はいまだに解決されないまま、小規模で多機能なソフトウェア開発は増え続けています。私は、その解決法の一つとして、私はチケット駆動開発に期待しています。その理由を過去をふりかえりながら説明したいと思います。

80年代では、10人程度以下であれば1年ぐらいかかる開発規模であっても、小規模といわれていました。当時の定義で小規模開発であっても、やはり難しい開発は存在しました。私の最初に経験したプロジェクトは、未完成のOS上で動作する、TeXのような複雑なソフトで、しかも使用上の不具合を含む前バージョンと同じ動作を求められたプロジェクトでした。未だにこのプロジェクトを超える混乱はありません。しかし、そのような状況でたとえ開発期間が延びたとしても、当時の大規模システムの開発の問題に比べれば経営への影響は小さく、あまり問題にされませんでした。

90年代になると、オープンシステムやインターネットが普及し、小規模開発が徐々に増えてきました。このころは、VisualBasicに代表されるようなコンポーネントをベースとしたソフトウェア開発によって、多機能なソフトウェアが増えました。また、データベースも一般に利用されるようになり、多くの業務システムが開発されました。このような環境の変化はダウンサイジングと呼ばれ、これまでは汎用機で行われていた大規模システムが切り出されて、たくさんの小規模開発が行われました。

当時の問題を95年のソフトウェアシンポジウムで最初に発表しました。当時のスライドの変換が面倒だったので、同じ研究内容を含んでいる博士論文のスライドを公開しました。

この論文では、開発中に起きる様々な問題はプロセスの変更に現れること、その内容は作業報告書に記載されていること、それを集めれば有効なノウハウが得られ、標準プロセスに組み込むことでフロントローディングできることを書いています。

2000年代になっても、環境、実現方法、ドメイン知識という基本的な問題のパターンは変わっていないと思います。しかし、フレームワークをはじめとする開発環境の整備によって、小規模開発であっても多機能で複雑なシステムが開発できるようになり、開発の規模は徐々に小さくなりました。

もちろん、90年代にも数人月の開発はありましたが、オフコンと呼ばれる主に特定業務向けのシステムや、スプレッドシートのマクロなどが中心のもので、自由度は限られたものでした。現代なら、数人月もあればちょっとしたWebシステム、しかもDBを含む立派なシステムが可能です。そして、インターネットの裾野の広がりと共に、多くの小規模システムが開発されるようになりました。

80年代から大規模システムと同様の支援は困難でしたが、今のように小規模になってはほとんど不可能でしょう。そのような中で可能なのは、コンピュータによる支援だと思います。ソフトウェア業界は、紺屋の白袴で、ソフトウェア開発のためにあまりコンピュータを使ってきませんでした。しかし、今となってはもうコンピュータの支援を使わざるを得なくなったと思います。

実はコンピュータによってソフトウェアを効率よく開発する試みはCASE(Computer Aided Software Engineering)と呼ばれ、80年代からありました。しかし、当時は1億円以上のミニコンや、2千万円ほどするワークステーション上のものか、はるかに高価な汎用機上のものでした。大規模開発でも中々困難な開発環境を今の小規模プロジェクトに導入できるわけがありません。

そこで、期待しているのがチケット駆動開発(TiDD)です。チケット駆動開発で用いるBTSには、WBSのようなソフトウェア工学的な要素や、構成管理、テスト管理などのツールとの連携が可能です。そして何より、備忘録としてちょっと使い始めるなどという軽い使い方からはじめ、見える化やコミュニケーションの道具として用いる、というようにスモールスタートが可能で、スケーラブルです。それぞれのプロジェクトの状況にあわせて実施できることは、小規模プロジェクトに向いていると思います。

チケット駆動開発によって、いつか小規模プロジェクトの憂鬱がなくなることを期待しています。

# A man takes a mustard seed and plants it in his field.
# The plant grows and becomes a tree,
# and the birds make their nests in its branches.
# Luke 13.19(TEV)

« 2010年9月 | トップページ | 2010年11月 »