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

2010年12月

2010/12/30

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart9 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ1】
Twitter / Yugui (Yuki Sonoda): 『Redmineによるタスクマネジメント実践技法』は特定の製品の使い方を教えるようなしょうもない本ではなくて、もしあざといタイトルを付けるとしたら『カリスママネージャーが教えるチケット駆動プロジェクトマネジメントの極意』とかそんな内容の本。TiDDの説明もだけど、実践知が為になる

Twitter / yuya_takeyama: 『Redmineによるタスクマネジメント実践技法』、まさにそういうしょうもな本だと思ってたけど実はスゴ本だったのか

ありがとうございます。
yuguiさんのTwitterを後から探してみると、ちょっとだけのつぶやきなのに、はっとさせられる発言があって参考になります。

【元ネタ2】
これはおもしろいな - 思考のスキマ

(引用開始)
この本にはかなり期待している。今からどきどきしている。
ソフトウェアの品質保証や管理手法の分野の知力というのは残念ながら転職活動における自分のカタログスペックには現れないけど、もはや言語だけを知っているプログラマーはただの無能であり、それらの知識・技術はいまや一般のプログラマーであっても英語力などと並んで、絶対に必須のものであるとおれは強く信じる。
システムエンジニアやプロジェクトリーダーに至っては、この分野を押さえていない者はもはやただの害悪だから、今すぐ辞表を書いて別業種に転生して頂くか、すぐに自分で勉強を始めた方がいい。
客には無駄に習得難易度が高い高度にカスタマイズされたシステムを納品しておきながら、自分たちはExcelでなにもかも管理するなんて原始的なことをしていてはいけない。
普及しているツールや管理手法というものは過去の数多のプロジェクトから教訓を集めた知の結晶であって、賢い人はその道を選んで進む。
愚か者はそこに道があることにすら気づかずに、自分で道を造ろうとするだろう。
プロジェクトを救うのは努力ではない。知力だ。学んだ者だけが高みに至るんだ。
(引用終り)

「プログラマもソフトウェアの品質管理やプロジェクトマネジメントの技法を知っていないといけない」という激しい意見のように思えますが、逆に言えば、現代の開発者もその気になって、チケット駆動開発とITSをセットで運用すれば、品質管理やプロジェクト管理の技法も学習できる環境が揃っているのだ、という事実を示しているのだと思います。

実際の現場でいきなりプロジェクト管理できる立場につくのは難しいでしょうが、RedmineやTracでチケット駆動開発を運用しながら、プロジェクト管理や品質管理、アジャイル開発の本に書かれていることを実践して、シミュレーション体験をすることは可能なのです。
自分なりのプロジェクト管理のノウハウをあらかじめ作っておけば、プロジェクト管理できる立場に初めてついた時、スムーズにプロジェクトを運営することができるでしょう。
丁度、年に1回の大学受験や資格試験を受ける前に、模擬試験を何度も受験して、場慣れするのと同じ理屈だと思います。

他にもあったら探してみる。

| | コメント (0) | トラックバック (0)

エンピリカルソフトウェア工学をチケット駆動開発がサポートする

エンピリカルソフトウェア工学(実証的ソフトウェア工学)に関する記事を見つけたのでメモ。

【元ネタ】
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 - Publickey

少人数のチームの方がソフトウェアの品質は高い - 思考のスキマ

【参考】
ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

Web2.0時代のプロジェクト管理: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産: プログラマの思索

エンピリカルソフトウェア工学は、ソフトウェア工学を科学実験のように実証的に確かめていく分野の学問。
「データ指向のソフトウェア工学」の特徴を持つ。
普通は、BTSにある障害報告票やSCMにあるソース履歴から、開発組織の構造(プロセスも含む)がソフトウェアにどう影響するのか、を探る学問。
僕のイメージでは、エンピリカルソフトウェア工学は社会科学のように、ソフトウェア開発に従事する組織や人を分析する学問であり、コンピュータサイエンスや物理学、数学のような科学ではないと思っている。

ソフトウェア工学の中では、ブルックスの人月の神話が最も知られている経験則の一つ。
「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 - Publickeyが面白いと思ったのは、「少人数のチームの方がソフトウェアの品質は高い」「組織構造の縦方向が短い方がソフトウェア品質がいい」という指摘をしたこと。

ソフトウェアをチームで開発する経験を持った人なら、その事実は当たり前に思うだろう。
大規模プロジェクトになり、開発チームが複数になるほど、コミュニケーションコストが大きくなる。
それ以上にマネジメントコストやアーキテクチャの整合性を取るためのコスト、システム全体の品質を確保するコストが指数関数的に肥大化していく。

「結果、エンジニア同士の距離がどれくらい離れると、どれくらいバグが増えるかは、ビルが異なると2.6%増加、カフェテリアが異なると3.9%増加、キャンパスが異なると6.3%増加、地域が異なると8.3%増加、大陸が異なると -3.9%となった。」という事実はとても興味深い。

だがその経験則に逆らうようなソフトウェア開発が増えているのが事実。
典型的な例がオフショア開発。
日本のSIなら、中国などの人月が安い外国へ下流工程の開発を委託するビジネスになる。

大規模プロジェクトを自社開発で内製化していても、開発メンバーが部屋やビルで隔離されていれば、心理的にはオフショア開発と変わらない。
分散開発は本来コミュニケーションコストが大きい。

そういう経験則に逆らってソフトウェア開発を成功させるには、顔を見ながらのミーティングが出来る環境作り、ブリッジSEだけでなく委託先の開発者もプロジェクトの最初は一緒に仕事するなど、心理的な距離を縮める努力が必要、とのこと。

個人的には、プロジェクトファシリテーションが分散開発におけるコミュニケーションについて、もっと役立つプラクティスを提供してくれるといいのに、と思っている。

又、チケット駆動開発がエンピリカルソフトウェア工学をサポートする可能性を秘めていると思っている。
チケット駆動開発は本来BTSというツールを使うことから始まったし、進捗や品質に関するメトリクスをいくらでも好きなように加工して出力できる。
ガントチャートやカレンダー、ロードマップ、バグ収束曲線などは、開発の現状に合わせてリアルタイムに最新化する仕組みをツールでサポートすればいいだけ。

何よりも、開発者が「チケットファースト」「No Ticket, No Commit」の運用ルールを守ってくれれば、バックグラウンドでメトリクスの元ネタを収集してくれるので、メトリクス採取のコストは劇的に下がる。
この手法は、Mixiの足跡機能やGoogleのPageRank、Amazonのレコメンドエンジンのように、クローラーのような機能で緩やかにログを採取して、価値ある情報を加工して出力する機能が簡単に実装できるようになったからこそ生まれた。
つまり、いわゆるBI(ビジネスインテリジェンス)をプロジェクト運営の意思決定に役立てることができるはず。

そして、BIで得られた情報を実際に運用してみて役立ったならば、一つのノウハウとしてチームが学習する。
この際に、KPTによるふりかえりは特に有効だ。
学習したノウハウはKeepとして貯められて、チームの資産になる。
Keepとして貯められた独自のノウハウが多いチームや組織ほど、自分たちで開発現場を改善する能力を拡張していける。
これがいわゆる、アジャイル開発で言う自己組織化ではないか、と直感している。

| | コメント (0) | トラックバック (0)

アジャイル開発の考え方を仕事や勉強法へ応用する

平鍋さんの記事を読んで、アジャイル開発の考え方を仕事や勉強法へ応用するアイデアをメモ。
ラフなメモ書き。

【元ネタ】
書籍『ポモドーロテクニック入門』日本語でました!(渋川さんおめでとう):An Agile Way:ITmedia オルタナティブ・ブログ

アジャイル部屋掃除プロジェクト - aikeの日記

アジャイル開発の基本的アイデアは小規模リリース。
更に基本的な概念は、タイムボックス、イテレーション、バックログ。

アジャイルな時間管理術 ポモドーロテクニック入門』の本は読んでないけど、タイムボックス、イテレーション、バックログを仕事術に応用した話なのだろう。
何となくGTDに似ている気がする。

年末になれば、大掃除がどこの家庭でもある。
大掃除も、まずは掃除する対象をバックログに入れておき、掃除の順番をイテレーション計画として立てて、10分~1時間のようなタイムボックスで小刻みに掃除していくやり方もあるだろう。

ポケットスタディ データベーススペシャリスト (情報処理技術者試験)」をAmazonで眺めたら、「アジャイル的学習方法」なるものが書かれていた。

いわく、過去問が大事だからといって、難易度の高い午後問題(記述式や論文)をいきなり解くのは無理がある。
逆に、知識を習得してから問題を順番に解いていく方針も時間と労力がかかりすぎる。
だから、ポケットスタディを少し読んでは、該当する過去問を解いて、理解を深めるサイクルを短いサイクルで何度も繰り返すのが大事、と。

「ポケットスタディを少し読んでは」という点が引っかかるけど、確かに内容は理解できる。
特に勉強は、腰をすえて知識を習得してから問題を解くというやり方は、時間と労力がかかりすぎて挫折してしまいがち。
かと言って、いきなり過去問を解いても知識がないから、理解が深まらない。
サブシステム単位に機能分割して小規模リリースしていくアジャイル開発のように、単元を分けて、少しずつ勉強していくサイクルを短い期間で何度も繰り返す方が、自分が成長しているのも自覚できるからモチベーションも落ちない。
あるいは、システム全体を広く薄く設計して品質を作り込む反復型開発のように、まずは教科書を一通り軽く読んだ後に、過去問を何度も解いては理解する勉強方法もあるだろう。

こういうアジャイル的学習方法は、10代のようなもっと早い時期に習えば良かったと思う(笑)

アジャイル開発のアイデアは、時間に余裕がない現代人の生活スタイルに非常にマッチしているのかもしれない。

| | コメント (0) | トラックバック (0)

2010/12/29

忘れ去られた日本のIT技術~プロジェクト管理

曖昧性とのたたかい―体験的プロジェクトマネジメント論」「はじめての上流工程をやり抜くための本 (エンジニア道場)」の本を読んで思ったことをメモ。
ラフなメモ書き。

【1】「曖昧性とのたたかい―体験的プロジェクトマネジメント論」は大規模な業務システムを構築する時のプロジェクト管理に関する経験談とそのノウハウを書いた本。
読み物だけど、読んでみて色々と参考になった。
但し、WF型開発を想定しているので注意は必要。

「確率の低い事象は必ず起きる」という文言はまさにその通り。
実際の業務システムは、とても稀な障害は頻繁に多発する。特に初回の本番稼動直後は特にそうだろう。

「プログラム修正に副作用あり」「触らぬ神(ロジック)に祟り(デグレード)なし」は信頼性を重視する業務システムでは特にそうだろう。
バグ修正や仕様変更が多いほど、デグレードが発生しやすいし、予期しなかったロジックが現れてバグの温床になる。
テスト駆動開発+継続的インテグレーションでカバーできると思いがちだが、ハードウェアも含めたシステム全体の観点では、それだけでは足りない。
しかし、この観点が行き過ぎると、保守性が悪くなり、その後の機能追加に工数がかかってしまうと言う技術的負債の事象も発生する。

「窓拭きは真ん中ではなく四隅から」とは、異常ケースのテストをきちんとやれば自ずから正常ケースも綺麗になるというたとえ。
確かに、ソフトウェアのロジックの8割は異常処理と言われるので、そういうロジックがたとえ稀でも徹底的に潰す方針を取れば、開発者もテスターも仕様をより深く理解するようになる利点もある。

「進捗報告をリーダー自ら作ること」は、リーダークラスになるとメンバーに作業を任せがちだが、自分で書いてみて問題点を把握することが重要という話。
いくら手間を省いて合理化しても、実質的なマネジメントができなけば何の役にも立たない、という指摘はまさにその通り。

他にも色々な話は参考になるが、体系化されていないように思う。
曖昧性とのたたかい―体験的プロジェクトマネジメント論」だけでなく、以前読んだ本「プロフェッショナルマネジャーになる50の技法―「前進」「機能化」「立案」「解決」の4つの技法で『プロマネ』のツボを攻略する (アスカビジネス)」「SEのためのプロジェクト管理心得ノート」もいい本だけど、プラクティスやパターンへ抽象化されてないので、まとまっていない印象を持った。
むしろ「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」の方がより深みがある気がする。
PMBOKの方が抽象的すぎるけど、PMBOKの言葉に色んな人の体験談が抽象化されていて、誰でも共有できる利点がある。

【2】また、「はじめての上流工程をやり抜くための本 (エンジニア道場)」は、システム化提案や要件定義に関するノウハウを書いている本。
特にシステム化提案のような超上流工程のモデリング技法は参考になった。
但し、WF型開発を想定しているので注意は必要。

「システム」の定義がSLCP-JCFでは98年度版から2007年度版では後退しているという指摘は鋭い。
つまり、(業務)システムとは、コンピュータシステムとそれを利用する人達の活動(業務)も含めたはずなのに、2007年度版では、システムがコンピュータシステムに限定されてしまって、手運用でフォロー出来る業務の設計が外れている点はおかしいと指摘している。
確かに、実際の業務システムの設計では、何でもかんでもIT化する必要はない。
開発コストやユーザがシステムを運用するコスト、システム化によって業務が変わってユーザが慣れるまでのコストなどを考慮して、故意に手運用するフローも考慮すべきだからだ。
つまり、BPRの視点が漏れている点はおかしいわけだ。

システム化提案では、いきなり設計ではなく、顧客の業務をモデル化して、どこをIT化して効率化するか、とか、他の業務とつなげるか、などいろんな観点で考えれるようにモデルを作る。
実際は、AsIsモデル(現状業務)とToBeモデル(IT化後の業務)を対比させて、BPRを具体化していく。
その時に使うモデルは、業務機能関連図が多いだろう。
業務機能関連図は、組織・プロセス・データを一体化したポンチ図であり、PowerPointで描く時が多いだろう。

業務機能関連図はDFDに似ているが、DFDは図面としての表現力は弱いと指摘してる。
つまり、プロセスの順序や配置で業務の意味が変わるのに、DFDは一昔前のモデリング技法ゆえに力不足だと言う。
エリクソン・ペンカーのプロセス図やIDEF0のように、矢印の向き先だけで供給プロセスだったり、制御プロセスだったりする意味をDFDでは描ききれない弱点があるわけだ。

普通は業務機能関連図を書くときは、ストア(データ)を書かずにプロセスだけを書くのが多い。
ファイルやDBを書くとシステム設計に近づきすぎて業務分析にならないし、モデルが煩雑になるだけ。
ストアを書くのはデータとプロセスを分離したDOAが登場する以前の技法であることを示しているという指摘は鋭い。
実際の業務分析では、プロセスを中心に描いて、組織やデータ、お金の流れを顧客が理解できるレベルにしておくのが普通だろう。

業務機能関連図の描き方で参考になったのは、組織の枠を入れると論理モデルから物理モデルに変わるという指摘。
AsIsモデルからToBeモデルへデータモデリングする場合、「現物理モデル→現論理モデル→新論理モデル→新物理モデル」の流れで設計するのが普通だろうが、業務フローに組織の枠を入れてモデル化することは「新論理モデル→新物理モデル」に相当する。
つまり、ToBeモデルにある業務を誰が担当するのか、という観点を入れれば、現場の業務フローにより近づける。

はじめての上流工程をやり抜くための本 (エンジニア道場)」を読んで業務機能関連図の描き方は参考になったけど、ノウハウが体系化されておらず、プラクティスまで昇華されてない。
BaBOKが今、システム化提案という超上流工程をBOK化しようとしている最中であり、じきにこの本の内容も含まれるだろうと推測する。

【3】以上の本を読んで思ったのは、日本人技術者が大規模な業務システム開発を長年行っている間に、プロジェクト管理や業務設計で色んなノウハウを持っているにも関わらず、共有されていないことだ。
忘れ去られた日本のIT技術~DOAと品質管理: プログラマの思索でも思ったけれど、DOAや品質管理などの技術は世界的に見て優れているにも関わらず、現在のIT技術者は殆ど関知していない。

今アジャイル開発がソフトウェア開発で注目を浴びているけれど、実は日本発のアイデアや日本人が提唱した論文や製造モデルが元ネタだったりする。
PMBOKを取得している日本人マネージャは結構いるだろうが、取得できる人が多いのはプロジェクト管理を経験できる開発案件が実際に多く、試行錯誤しながらプロジェクト管理の本質を理解していったからだろう。

日本の歴史を紐とけば、中国から文化を輸入した後、平仮名や和歌のような独自の日本文化を生み出した。
明治時代に西洋から文化を輸入した時も、簿記や製造技術、学問などをそのまま取り入れるだけでなく、日本人に合う形で咀嚼して、今の製造業がある。
アジャイル開発でも、平鍋さんは初期の頃はXP行脚など活動された後に、プロジェクトファシリテーションという日本人らしいアジャイル精神のプラクティスを提唱された。
チケット駆動開発もまちゅさんが提唱されたアイデアだが、コミュニティやネットの中で議論して、以前よりも体系化されたものになりつつある。

同様に、日本人技術者が保持しているプロジェクト管理の技法も日本流にアレンジして、もっと共有出来る形へ体系化されるべきものだと思う。

| | コメント (0) | トラックバック (0)

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart8 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ1】
紹介 -- Redmineによるタスクマネジメント実践技法 @ アールケー開発

(引用開始)
誤解を恐れずに簡単にいってしまえば、BTSとWikiを組み合わせ、プロジェクト管理をできるようにしたWebアプリケーションです。Redmineで私が気に入っている点は、チケットに期限を設定して、それをもとにガントチャートが生成できる点。
従来のWBSでの作業項目をチケットして登録し、有効期限を設定して、その子チケットに、タスクを登録すれば、プロジェクト管理もできます。また、生成されたガントチャートやロードマップで表示される進捗率など、肌で感じている感触と現実との差を実感でき、何となく大丈夫と思っていたものが、本当なのかを知ることができます。
このようなチケットをベースに開発をしていくという方法をチケット駆動開発と呼ぶそうです。
Redmineによるタスクマネジメント実践技法」は、そのチケット駆動開発を実践していく中で、Redmineをどう運用していくかということを解説しています。また、TestLinkについても運用例を紹介しています。
現場の視点から見ても、いきなりRedmineやTestLinkを導入することはできなくとも、「no Ticket! no Commit !」というチケット駆動開発は導入しやすいのではと思います。
Mantisなど他のBTSを導入している場合にも本書での手法は応用できると思います。
(引用終わり)

ありがとうございます。
チケット駆動開発の最大の利点は、情報の共有と見える化だと思ってます。
チケットの進捗がチームメンバー全員に公開されているので誰が今何をやっているのか分かりますし、ガントチャートやロードマップなどのチケット集計機能によって、チームの進捗も分かります。
泥沼に陥ったプロジェクトを立て直すには、普通はチーム内にある共有されてない課題を全て吐き出して、一つずつタスクを潰していくしかありません。
まずは、チケットでタスクを見える化する所から始めたら、やりやすいでしょう。

【元ネタ2】
目から鱗の語学学習法から、ネットワーク科学、技術書まで―― はてなブックマーク 新刊ピックアップ - 速報:@niftyニュース

(引用開始)
2007年頃から堅調に注目を集めているオープンソースのプロジェクト管理システム「Redmine」。
その解説書が翔泳社から出版されました。これまで、主に障害管理に利用されてきた「チケット」を、作業管理にも利用する「チケット駆動開発」が提案されています。現場で役立つように豊富な実例を交えて解説しているとのこと。
(引用終わり)

【元ネタ3】
Japanese Ruby books in 2010 - 思っているよりもずっとずっと人生は短い。

(引用開始)
It's not how-to book of Redmine, but how-to book of task management with Redmine.
Many IT engineers in Japan love Excel. They use it for task managements and documentations. It's very bad thing I guess. So we need the books like it.
The book introduced a task management method called "Ticket-driven development". They called "TiDD". TiDD is an interesting idea.
(引用終わり)

Ruby本の1冊として紹介されているようです。
意訳するとこんな感じでしょうか?

「この本はRedmineのハウツー本ではなく、Redmineによるタスク管理のハウツー本です。
日本の多くのIT技術者はExcelを好んでいて、タスク管理やドキュメント作成に使っています。
でもそれはとても悪いことだと推測します。
そんな状況でこの本を必要としているのです。
この本はチケット駆動開発(TiDD)と呼ばれるタスク管理の手法を紹介しています。
TiDDはとても興味深いアイデアなのです。」

【元ネタ4】
「Redmineによるタスクマネジメント実践技法」を買った: アクアマンの『ずくなし』ブログ

(引用開始)
感想:
チケット駆動開発について詳しく書かれていました。
チケットの運用方法などのノウハウがぎっしり。
TestLinkとの連携について丁寧に説明もありかなり参考になります。
おすすめポイント:
チケット駆動開発についてかなり丁寧に説明されています。
また、TestLinkに関する書籍が少ないですが、
この本でTestLinkの基礎も学べてかなりおススメです。
(引用終わり)

どうもありがとうございます。
確かにギッシリとノウハウを詰め込んだつもりです。

他にもあったら探してみる。

| | コメント (0) | トラックバック (0)

2010/12/25

TestLink plugin for Redmine

SundayWalkerさんがRedmineの画面上にTestLinkの画面を表示できるプラグインを公開されていたのでメモ。

【元ネタ】
チケット #23961: TestLink plugin for Redmine - TestLink日本語化 - SourceForge.JP

Twitter / なかむら かおる: [redmine][TestLink]RedmineからTestLinkの機能を利用するプラグイン。TestLinkの画面そのまま、すごい! / チケット #23961: TestLink plugin for Redmine

TestLink plugin for Redmineのイメージは、Readme-01.pngを見ればすぐに分かるだろう。

(引用開始)
こんにちは、SundayWalkerです。
TestLink1.9が公開されて、不具合の対応もかなり進んでいるようです。
以前からTestLinkとRedmineは、非常に良いツールと思っており、2つのツールの連携がより強化できると良いと考えておりました。
両者の連携強化の第1弾として、先に公開したTestLink1.9beta6用のCASのパッチは、TestLink1.9でも利用できると思います。
<注釈:TestLink1.9beta6用のCASのパッチとは、TestLink1.9b6 CAS (SSO) パッチ (Testlinkjp-users) - TestLink日本語化 - SourceForge.JPを指していると思われる>
両者の連携強化の第2弾として、RedmineでTestLinkの機能を利用するためのプラグインを作成してみました。 RubyとJavaScriptの初心者が作成しましたので、あまりできは良くありませんが何かの参考になれば幸いです。
以下に概要を示します。以下の内容はプラグインの中のReadme-jp.htmlファイルとほぼ同じです。
【TestLink plugin for Redmine】
1. はじめに
これは、RedmineでTestLinkの機能を利用するためのプラグインです。
2. 前提条件
本プラグインを使用するには、Redmineと同じWebサーバ (もしくはJavaScriptのAjax通信が可能なサーバ)に TestLinkを事前にインストールしておく必要があります。 また、Redmineのプロジェクト名と同一のTestLinkのプロジェクトをあらかじめ 作成しておく必要があります。
RedmineとTestLink共にCAS対応に設定しておくことを推奨します。 CASを使用しない場合は事前にTestLinkにログインしておく必要があります。
3. インストール
以下の手順でプラグインをインストールします。
* 本プラグインをRedmineの'vendor/plugins'フォルダにコピーします。
* Redmineを再起動します。
* Redmineの'Administration'の'Plugins'の画面にて、 'TestLink plugin for Redmine'の'Configure'を選択し、 'TestLink base path'に適切な値を設定します。
* Redmineの'Administration'の'Roles and permissions'の画面にて、 'Testlink'の機能を利用するRoleを選択し、 'TestLink'にチェックを付けます。
* Redmineの各プロジェクトの'Settings'のModulesにて'Testlink'にチェックを付けます。
4. ライセンス
GPL v2
5. 作者のテスト環境
* Redmine 1.0.3 + Apache + Mongrel + CASプラグイン
* TestLink 1.9 + CASパッチ
* Windows XP SP3
注意:RedmineのCASプラグインはMongreでは動作しますが、FastCGIでは動作しないようです。
6. 機能
6.1 TestLinkタブ
Redmineのプロジェクト名と同一のTestLinkのプロジェクトの画面を表示します。
[Plugin Load Denied: embed]
6.2 WiKi - linkto_testlinkマクロ
TestLinkタブの画面へのリンクを設定するマクロです。
6.3 WiKi - include_testlinkマクロ
TestLinkの画面をインラインフレームとして表示するマクロです。
TestLinkの'workframe'(右下のフレーム)を指定した場合は'workframe'を、 そのほかの場合は'mainframe'(下のフレーム)の画面を表示します。
'height'を指定しない場合は、表示内容に高さを合わせます。
6.4 WiKi - iframe_testlinkマクロ
TestLinkの画面をインラインフレームとして表示するマクロです。
TestLinkの'mainframe'の画面を表示します。 'workframe'がある場合は、'treeframe'(左下のフレーム)と'workframe'(右下のフレーム)を表示します。
7. 既知の問題点等
* 本プラグインの問題ではなく、CASプラグインとCASパッチの問題として、 RedmineにCASを使用してログインした場合、 CASセッションがタイムアウトすると TestLinkが Redmineより先に検知し、ログアウトの状態になることがある。 この場合、一旦Redmineにてログアウトし、 Redmineにてログインを実施する必要がある。 Single Sign Outなどに対応すると良いのではないかと思われるが、 具体的な変更方法がわかっていない。
* TestLinkを直接使用する場合に比べ、本プラグインでTestLinkの画面を表示する場合、 TestLinkの3つのフレームがコンカレントではなくシリアルに読み込まれるため、 表示が完了するまでに時間がかかる。
(引用終り)

上記のプラグインは、Redmineに入れたプラグイン一覧: プログラマの思索や「Redmineによるタスクマネジメント実践技法」にも書いたr-labs - Hudson - RedmineというHudsonプラグインに似ている。
Redmineの機能の一部にビルド管理Hudsonやテスト管理TestLinkが含まれていれば、開発者はRedmineを意識するだけで、欲しい情報を自分で検索するようになるので、無駄な質問が減って、コミュニケーションの質も向上する。

SundayWalkerさんはRedmineとTestLink連携を色々試されているようで、下記のようなTipsも公開されている。

TestLinkとRedmineでシングルサインオン認証の連携: プログラマの思索

TestLinkはRedmineやTracに比べるとUIが使いづらく、テスト管理という機能に特化しているため理解しづらいが、使いこなせれば、テスト管理や品質管理に大きく貢献するだろう。

Hudson、TestLink、Redmineの間を相互にリンクするプラグインは、最近になって日本人の有志が下記のようにたくさん作ってくれている。
以前に比べるとプロジェクト管理やビルド管理、テスト管理が格段にスムーズになってきている。

HudsonのTestLink Plugin: プログラマの思索
RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索

BTS、CI、SCM、テスト管理、品質管理の各種ツールをプラグインで連携するやり方は、最終的にはプロジェクト管理サーバーを目指している点に落ち着くと思う。
つまり、現場リーダーや開発者の意思決定をサポートするソフトウェア開発のインフラを整えて、もっとAgileに開発できるスタイルに進化していくはずだと思っている。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索
プロジェクト管理サーバーとは: プログラマの思索

プロジェクト管理サーバーという概念からPMBOKのPMISにつながるアイデアは「Redmineによるタスクマネジメント実践技法」の8.3節「Redmineと外部ツールを連携」で詳しく書いたので是非読んでみて、色々試して欲しいと思う。

| | コメント (0) | トラックバック (0)

2010/12/24

工業簿記と製造業のデータモデリング

簿記2級に含まれている工業簿記を勉強して、渡辺幸三さんのデータモデリングの本「生産管理・原価管理システムのためのデータモデリング」「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」の奥深さがようやく理解出来るようになってきた。
製造業の生産管理、業務システムはとても奥深いし、面白い。
気付いたことをメモ。
#思いつきで書いていて、論理的な文章でないし、理解が誤っている箇所もあるかもしれないので注意。

【参考】
工業簿記

The Textbook of Cost Accounting 原価計算の解法

勘定連絡図: 雑兵とマジョリティ

28日目 標準原価計算 『シュラッター図』は、恐ろしいほど万能: 矮弱の“士”たりといえども・・・

シュラッター図: 税理士試験メモ

工業簿記・製造間接費の差異分析に使われるシュラッター図 - かーねる Cyber Diary

工業簿記の予算差異 とは何を意味するものですか? 名前どうりなのかもしれませ... - Yahoo!知恵袋

3分法(シュラッター図)の線について教えてください。 | OKWave

【1】工業簿記の骨格は、勘定連絡図と製造間接費差異分析のシュラッター図。
この2つを覚えておけば、後は公式を流用して複雑な計算をしているに過ぎない。

勘定連絡図は、仕入れた材料、労働者の労務費、光熱費などの経費から、直接費・間接費・加工費・仕掛品(未完成品)・製造間接費・製品(完成品)・売上原価・売上までの勘定科目の流れを表した図。
この図に必要な数値を収集して、最終的には、製造原価報告書(C/R)、損益計算書(P/L)を作るわけだ。

シュラッター図は、製造間接費の予定費用と実費用の差異分析に使う。
PMBOKのEVMに発想は似ている。
PVが予算差異、CVが操業度差異に近い。

工業簿記では製品の原価管理をひたすら計算しているが、その理由は、正しい製造原価を求めないと、本来の販売単価が分からず、出荷後に大赤字になってしまうからだ。
だから、原価差異分析はPDCAサイクルで回すやり方みたい。

【2】工業簿記では、簿記3級の時とは理解する観点が全く異なる。
簿記3級では、「消耗品費//現金」「売掛金//売上」などのように、取引を直接、仕訳に起こす。
それら日々の取引の仕訳は、仕訳帳にストックされて、月末の締に総勘定元帳に勘定科目単位に残高が集計される。
総勘定元帳はいわゆるT字形勘定で借方・貸方で記載されている。

工業簿記では逆に、T字形勘定から仕訳を起こす手法が多い。
実際は、勘定連絡図にある仕掛品、製造間接費、製品のT字形勘定へ収集した残高を入れた後、仕訳を作る。
だから、総勘定元帳にあるT字形勘定から、どんな取引が発生したのか、を機械的に理解するのが重要。
データモデリング上では、T字形勘定の集計テーブルから日々の仕訳というトランザクションへ遡ることが出来るか、という点になるだろう。

普通の人は、T字形勘定→仕訳という発想がないため、工業簿記が難しく感じられるのだろう。

【3】工業簿記とデータモデリングの関係としては、製造指図書が非常に重要。
製造指図書とは、生産計画に基づいた製品の製造の命令書。
材料や工程について細かい指示が載っていて、工場労働者は製造指図書に従って製品を作り、製造後に製造報告書に原価実績を書く。

普通は、倉庫にある材料を出庫する時に庫出票を作り、庫出票に製造指図書Noが書かれる。
製造指図書には必ず製造指図書Noという一意な番号が振られていて、製造指図書に書かれている材料は直接材料費となるから注意。
つまり、出庫されたら、材料が消費されたという意味になり、材料勘定から仕掛品勘定へ直接材料費へ移る。
データモデリングでは、倉庫の入出庫の話が非常に多いけれど、単に在庫の引当という意味合いだけでなく、バックグラウンドでは、材料→仕掛品という仕訳が発生するのが重要。

渡辺さんの「生産管理・原価管理システムのためのデータモデリング」によれば、製造指図書が重要なのは、製造指図書が
「登録→在庫の引当→発行→実作業→報告」
という複雑な処理が動くからだ。
製造指図書には、生産計画から指示された材料を在庫から引き当てて、決められた工程でどんな材料をどれだけ使うのか、が細かく決められている。
製造指図書があるからこそ、製造原価の追跡が可能になり、原価管理のPDCAサイクルが回るようになる。

この話を聞いていると、まるでチケット駆動開発におけるチケットは製造指図書みたいだな、と思った。
実際のソフトウェア開発の作業も、チケットに成果物というアウトプットの内容、作業の開始・終了の予定・実績日、進捗率、予定・実績工数などが書かれていて、リリース後に集計すれば、予定実績の進捗分析に使えるからだ。

製造業では、製造指図書でガチガチに担当者を命令するのではなく、現場担当者の裁量を生かせるように工夫しているところもあるらしい。
チケットも製造指図書も、材料(インプット)や工程(プロセス)の情報が含まれた作業指示書。
チケットを担当者がどのように扱って作業するかという工夫は、チケット駆動開発でも改善の余地があるだろう。

【4】普通のSIでもIT原価システムを多分運用しているだろう。
どのSIでも、社員の勤務時間のうち、どのプロジェクトにどれだけの作業時間が消費されているか、を毎日報告させるようにうるさくなってきている。
それが何をしているのか、も何となく想像がつく。
個別受注生産したプロジェクトで、労務費という製造原価をきちんと把握して、原価管理を徹底して将来の利益計画へつなげたいからだろう。
要は経営者の発想だ。IT技術者の発想ではない。

しかも、昨今は、製造原価のうち直接費の割合が小さくなっていて、人件費の割合が高くなっているから、製造間接費の按分によって、製造原価が平準化されてしまって、本来の製造原価が分からなくなっている。
だから、活動基準原価計算(ABC)やバランス・スコアカード(BSC)などを使って、どれだけの資源をどの活動に消費してどれだけの成果が出たのか、を追跡して評価する仕組みが必要になってきたのだろう。

SIの部課長は、自分の部の月次の損益計算書を作るために、Excelで受注管理、売掛金管理、経費の管理を四苦八苦しながらやっている。
毎月の報告で経営層から、計画と実績の差を問い詰められるわけだから、精神的プレッシャーも大きい。
なのに、彼らの仕事は正直IT化されておらず、意思決定の材料が揃っていない。
SIに限らず、普通の企業では、部課長クラスがしっかりしていないと売上も利益も増えないのに、彼らのサポートがそれほど手厚くないような気がしている。

SIの部課長の仕事を隣で見ていると、もはやIT技術者の仕事ではない。
彼らはプログラミングを書く時間すら与えられていない。
むしろ、経営者のように、組織の活動で発生する営業活動の売上・費用に責任を負うているのだ。

【5】工場が仕入れる材料の入庫、工場から製品の出荷をする場合、独特な業務用語がある。
前者は「送り状」、後者は「直送」。
渡辺幸三さんの本「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」「生産管理・原価管理システムのためのデータモデリング」にもこの二つの用語を詳しく説明してくれている。

工業簿記の観点では、送り状とは仕入先からの納品書を指す。
仕訳としては「材料//買掛金」が発生して、仕入先から材料が倉庫に入庫される。

納品書と言わずにわざわざ「送り状」と呼ぶ理由は、納品書に材料の単価が書かれておらず、合計金額のみ書かれていることにある。
つまり、仕入れ先の観点では、リベート(利益)がどれだけ発生しているかを顧客にわざわざ知らせる必要はないので、送り状と言う形式の帳票を手渡している。
どの業界でも、リベートは5~10%は付けているだろうから、そのリベート額を顧客が知れば、仕入れ先を変えたり、仕入価格を値下げするよう圧力をかけてくるだろう。
多分、日本独特の業務形態だと思う。

また、工業簿記の観点では、直送とは工場や仕入先から直接、得意先へ製品を出荷することを指す。
普通は、工場で作られた製品は倉庫に入庫されて、倉庫から得意先へ出荷する。
その場合の仕訳は「製品//売上」になる。

わざわざ工場や仕入れ先から直接、出荷する利点は、在庫を持つリスクがなく、倉庫代などの保管料も削減出来るからだ。
工場から直送する場合の仕訳は「仕掛品//売上」になる。

仕入先から直送する場合、自分の工場や倉庫から出荷するわけではないので、仕入先のリベート料金も取られるので、更に利益は目減りする。
なのにわざわざ仕入先から直送する理由は、仕入先が在庫管理を肩代わりしてくれているので、バッファ(緩衝材)になってくれるからだ。
例えば、在庫がない場合で緊急の需要が発生した場合や、高価な材料の割には在庫管理が大変な商品が相当するだろう。

販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」では、仕入先からの直送のデータモデリングの例が面白い。
自社の倉庫は経由しないのに、在庫評価基準を適用する必要があるため、あたかも自社の倉庫にあるかのように、在庫数量や在庫単価が変化する。

【6】製造業のデータモデリングは最終的には、MRP(所要量計画)とABC(活動基準原価計算)をマスターすれば、他の概念はスラスラと入ってくるような気がしている。
MRP(所要量計画)は再帰SQLをおそらく使うはず。

再帰SQL: プログラマの思索

再帰SQL part2: プログラマの思索

この辺りの理解した内容は後でまとめる。

| | コメント (0) | トラックバック (0)

タブレット革命を読んで

タブレット革命 〜iPad登場でわかった“板型PC”の破壊力」を立ち読みして思ったことをメモ。

タブレット革命 - 新刊・近刊:ITpro

タブレット革命 〜iPad登場でわかった“板型PC”の破壊力」はiPhone/iPadのようなスマートフォンやタブレットPCがどんな時代的な意味を持つのか、を知る上では良い本だ。
「iPadで初めてWebを読めるようになった」「Push型、Pull型のコミュニケーションがTell型に変わりつつある時代にマッチしている」「教育も今後タブレットPCの利用面が増えるだろう」という主張はとても興味深かった。

「iPadで初めてWebを読めるようになった」とは、ノートPCや携帯電話とは違うWebブラウジングの生活スタイルを象徴している。
ジョブズがソファに座ってiPadを使うデモを行ったように、リラックスした雰囲気でWebを楽しめる。

机の上にかしこまって使うPCの場合、2人がペアプロする場合、お互いがPCを見ながらコードを書くために、お互いの顔の表情を見るわけではない。このコミュニケーションを90度の角度と呼んでいる。
逆に、iPadでは、テーブルの上にあるiPadを二人が見ながら、お互いの表情を確認してコミュニケーションできる。このコミュニケーションを180度の角度と呼んでいる。
つまり、iPadとPCでは、コミュニケーションスタイルが全く異なるため、使い方も当然大きく異なってくるわけだ。

また、「コミュニケーションがPush型、Pull型からTell型に変わりつつある」とは、マスコミやGoogle検索からSNSへコミュニケーションの重要度が移りつつあること。
昔は大手マスメディアが新聞やテレビから一方的にニュースを垂れ流して、受動的に見るというPush型しか選択肢はなかった。
だが、PCとインターネットが普及して、自分が欲しい情報をGoogleで検索したり、RSSで最新ニュースを受信するスタイルに変わり、Pull型になった。
そして、FacebookのようなSNSやTwitterが急激に広がって、ある特定の場に質問や言葉を投げれば、見知らぬ人からたくさんの返答が戻ってくるコミュニケーション形式に変わりつつある、と。
確かに、ここ最近のTwitterの影響力はすさまじい。

更に、MITなどアメリカの大学がYouTubeやiTunesなどで無料で授業を公開していることから、教育にも大きな影響が発生しているとのこと。
確かに、英語ができる人ならば、世界最先端の知識がネットから得られる利点はとても大きい。
最近よく売られている「これからの「正義」の話をしよう――いまを生き延びるための哲学」や「20歳のときに知っておきたかったこと スタンフォード大学集中講義」の本が典型的な例かもしれない。

だが、教育にタブレットPCなどのIT化がどれだけ普及するのか、個人的には疑問に思う点もある。
実際の現場の授業は黒板でマス形式だし、生徒も紙の教科書や問題集を読んで、ノートに書く。
それら全てがIT化された場合、果たして生徒の能力は向上するのか?

教科書がKindleに変わって、教科書の持ち運びはなくなり、検索もやりやすくなったが、余白の書き込みや自分が気になる部分に線を引くことができなくて不便だ、という話を聞いたことがある。

今も昔も大学入試や殆どの資格試験は、紙の問題と解答用紙に鉛筆で制限時間内に書きまくる。
特に記述式や論文の場合は、普段はPCばかりの作業で鉛筆を握ることも無い人にとっては、とてもハードルが高い。普通の論文形式なら、1000字~3000字を書くのはざらだ。

つまり、試験がアナログである限り、教育が完全にIT化されるのは難しいだろうと思う。
今も昔も勉強はアナログでやるのが正統派なのかもしれない。

とはいえ、Moodleを使って、授業をサポートするWebツールを駆使するやり方もある。
電子書籍や電子教科書などの動向も含めて、教育のIT化は時代に大きく翻弄されていく可能性が大きいだろう。

eラーニングシステム Moodle: プログラマの思索

営業支援ツールSugarCRMとeラーニング支援ツールMoodleのリンク: プログラマの思索

iPadの使い道: プログラマの思索

| | コメント (0) | トラックバック (0)

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart7 #tidd

日経ITProの新刊・近刊で、「Redmineによるタスクマネジメント実践技法」の書評が公開されたようです。

Redmineによるタスクマネジメント実践技法 - 新刊・近刊:ITpro

(引用)
バグの発生から除去までを管理する手法を、プロジェクトマネジメントのタスク管理にまで広げて使う新手法を著した一冊。バグの管理票をチケットと呼ぶことにちなんで「チケット駆動開発(TiDD)」と名付けている。前半はTiDDの概要やメリットを、後半はバグ管理ツールの「Redmine」を使った実践手法を詳解。主にアジャイル開発での適用を解説する。

TiDDの発端がBTSからITSへの拡張にあること、さらにAgile開発に適用可能である点を端的に説明してくれてます。
ただ、テスト管理ツールTestLinkの説明がなかったのが残念。

| | コメント (0) | トラックバック (0)

2010/12/23

段階リリースとアジャイルリリーストレイン

チケット駆動開発の肝の一つは、リリース予定バージョンとイテレーションを同一視する点にある。
イテレーションの扱い方がチケット駆動開発の重要な運用ノウハウの一つ。
大規模プロジェクトではイテレーションの扱い方に更に一工夫がいる。
考えたことをメモ。

【元ネタ】
開発プロセスの最適化手法

システムを小さく作って段階的にリリースすることが重要な理由 - 極北データモデリング

【1】小規模プロジェクトでチケット駆動開発を運用している場合、リリース予定バージョンがリリースモジュールのバージョンあるいは納品モジュールのバージョンに一致し、更にAgile開発のイテレーションと同一視できる。
だから、小刻みにリリースしながら機能も品質も拡張していく戦略が取りやすい。
小規模リリースを実際に運用するのはとても楽しい。

しかしながら、大規模プロジェクトになると、小規模リリースを実現するのが難しくなってくる。
理由は、複数チームのイテレーションを同期させるのが難しいからだ。

大規模プロジェクトでは、複数チームの成果物が揃って初めて一つの製品がリリースできる。
一つのコンポーネントができたとしても、それを他のコンポーネントと一緒に結合して初めて製品ができあがる。
その時に、他チームのコンポーネントが出来上がっていなければ、いくら自分のチームが頑張っても、全体としてリリースは遅れてしまう。
進捗が速くても伝播しにくいが、進捗の遅延はすぐに他チームに伝播する。
この辺りはTOCの制約の話に似ている。

だから、「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」によれば、複数チームのイテレーションを同期させるプラクティスであるアジャイルリリーストレインの重要性を述べている。
複数チーム間のイテレーションを全て歩調を合わせることによって、複数チームの成果物を結合してビルドするタイミングを一致させる。
これによって、製品のリリースタイミングがイテレーションの単位となる。

しかし、実際の開発では、アジャイルリリーストレインの運用は一筋縄ではいかない。

例えば、全チームの開発のイテレーションを合わせたとしても、ビルドした時に障害が判明したとする。
でも、次のイテレーションでは他のチームも自分のチームも新機能を追加するストーリーになっている場合、自分のチームだけが新機能の開発を取り止めて、バグ修正に専念することはできない時は多い。
自分のチームが作る新機能のライブラリを他チームが必要としている時があるから、新機能の開発を取りやめると他チームの進捗を遅らせてしまう。

あるいは、組込製品開発でハードウェア(HW)の開発チームとソフトウェア(SW)の開発チームが協調してAgileに開発していたとしよう
この時、HWのチームとSWのチームのイテレーションを同期させた場合、確かにイテレーション終了時にハードとソフトを結合できるタイミングが一致するが、一発で動作させるのは難しい時が多いだろう。
実際は、ハードウェアの事情、ソフトウェアの事情をお互いに融通を効かせながら、ちょっとずつ動かしては修正する試行錯誤の繰り返しでしか、開発は進まない。
イテレーションを同期させたとしても、WF型開発のビッグバン結合と何ら変わらない。

あるいは、RedmineやMantisの複数プロジェクト機能を使って、設計工程・開発/単体テスト工程・結合/総合テスト工程・運用保守工程などのように、工程別にプロジェクトを作っていたとしよう。
このような運用は、特に大規模プロジェクトでWF型開発に即して運用している時が多いだろう。

もちろん、プロジェクト(工程)単位にリリース予定バージョンが定められて、その単位でリリース可能になる。
しかし、各プロジェクト(工程)間のリリース予定バージョンが異なっていた場合、ビルドモジュールのバージョンと対応づけるのが難しくなる。
ビルドしてモジュールを作ってリリースした場合、当然、設計工程の仕様変更のチケットも含まれるし、開発工程の新規開発のチケットも含まれるし、結合テストの障害修正のチケットも含まれるだろう。
それらチケットが1個のビルドモジュールに含まれていることを示すために、バージョンを細かく作り、更に他プロジェクト(工程)間のバージョンと手作業で合わせるのは結構面倒だ。

【2】上記の問題点は、二つのことを示唆している。
一つは、複数チーム間のイテレーションを同期させたとしても、一発で全てのコンポーネントをビルドして製品を作るのは難しいこと。
もう一つは、RedmineやMantisの複数プロジェクト機能を使っている場合、現状の機能ではイテレーションを同期させるのが難しいことだ。

【2-1】前者の解決方法としては、段階リリース、イテレーションの階層化、反復型開発などの手法があると思う。
段階リリースとは、古くからのWF型開発で言われている小規模リリースの一つ。
フェーズ1、フェーズ2などのようにシステムをリリース可能なサブシステムへ分割し、段階的に開発してテストしてはリリースしていく手法を取る。
段階リリースでは、1回のリリースが完全な本番運用となるのは稀で、最初から数回のリリースはお試しシステムみたいなもの。
数回のリリースで機能を揃えてから、ようやく本番稼動する。
つまり、段階リリースとは、複数回の内部リリース(ベータバージョン)を経た後に最終リリースする開発スタイル。
この手法の利点は、WF型開発の一発リリースのリスクを許容可能なサイズに小さく出来ること。
XPの小規模リリースとの違いは、XPの場合はリリースは顧客価値のあるシステムを必ず届けることと呼ぶように、必ず本番リリースになる点に対し、段階リリースは内部リリースを含む点にあるだろう。
但し、XPの小規模リリースの場合、1個のイテレーションで設計・開発・テストを並行作業するのに対し、段階リリースでは1個のイテレーションで設計・開発・テストが直列作業に進むので、テストで火を噴くことが多い。

イテレーションの階層化は、XPJUG関西の細谷さんから教わった。
例えば、組込製品開発では、HWチームのイテレーション1個に対し、SWチームは3回のイテレーションを内部で繰り返す。
SWチームは内部リリースする度にHWチームにソフトウェアを届けて実機で試してもらい、SWチームへ障害などをフィードバックしてもらう。
そして、HWチームのイテレーションの最後で、SWチームは最終的なソフトウェアを届けて、最終リリースする戦略。
つまり、HWチームの親イテレーション1個に対し、SWチームは子イテレーションを複数個持つので、イテレーションが1対他の関係になる。

この手法の特徴は、身軽に動きやすく変化が激しい子チームのイテレーションを故意に分割して、複数回の内部リリースの成果物を親チームに届けやすくし、親チームのフィードバックを子チームが受け入れるように出来ること。
これによって、最終リリースのリスクを許容可能なサイズにできるだけでなく、実際にHWチームで実機を動かした内容のフィードバックを受けることで、変化を受け入れながら、品質も機能も拡張できる。

反復型開発(イテレーティブ・エボリューション)とは、漸進型開発とは違い、システム全体を薄く作りこんでいく開発スタイル。
この発想もXPJUG関西の細谷さんから教わった。

複数チームの数回のイテレーションは同期させながら機能拡張していくが、4~5回のイテレーションの後、特別な1回のイテレーションを作り、今までの結合作業で不具合が発生したバグを直す期間を設けること。
実際の開発では、全てのイテレーションで機能拡張だけやればいいわけではない。
時には障害修正に専念せねばならない時もある。
特に複数チームの成果物を結合した場合、一発でリリースできる品質にはならない時が多いから、わざとテストだけのイテレーションを作り、リファクタリングしたり、アーキテクチャを見直したり、品質をアップしたりする作業に専念する。

いずれの手法にしても、複数チームの成果物をイテレーション単位のビルド作業で結合させるのが難しい弱点をうまく補強している現実的な手法だと思う。

【2-2】後者の解決方法としては、Redmineのバージョンの継承機能とイテレーションの階層化を組み合わせて運用する方法があると思う。
複数プロジェクト機能を使う場合、Redmineのバージョン継承機能を使って、最上階のプロジェクトで本番リリースすべきイテレーションを定めて、子階層の全てのプロジェクトへ強制的にイテレーションを継承させればいい。
各プロジェクトでは、親プロジェクトのイテレーション1個に対し、イテレーションの階層化の手法を使って、複数回のイテレーションを作っておく。
そして、各プロジェクトで内部リリースしながら、品質も機能も拡張していく。

Redmineのバージョン継承機能はアジャイルリリーストレインを簡単に実現してくれる強力な機能の一つ。
実際の運用で上手に使えば、アジャイル開発のスケールアップを強力にサポートしてくれると思う。

| | コメント (0) | トラックバック (0)

2010/12/21

Redmine 用語集プラグイン

Redmineに用語集の機能を追加するプラグインがあったのでメモ。

【元ネタ】
Redmine 用語集プラグイン Wiki - SourceForge.JP

プラグイン使用方法 - Redmine 用語集プラグイン Wiki - SourceForge.JP

Redmine(プロジェクト管理システム)に用語集の機能を追加するプラグインです。以下のような用途に使えます。
* 業務分析工程での専門用語の管理、社内辞書
* 対訳表
* 用語とデータ型(クラス名)との変換辞書
* コーディング時の略名の付け方の方針管理

とのこと。
似たようなWebシステムはMediaWikiがあると思うが、Redmineの一機能になるのが面白い。

業務システムの要件定義やDB設計では特に、用語集を作るのは重要な作業の一つ。
独特な業務の用語は、その言い回しや意味をまとめておけば、後で参照できるし、新規メンバーに逐一説明する必要もない。
RedmineのWikiでも代用できるが、用語集にしておけばWeb上で検索しやすいはず。
特にDB設計では、同音異義語や異音同義語をきちんと区別しないと、似たような意味なのに名前がぜんぜん違うカラムができたりして、後の運用保守で痛い目にあうから。

Redmineの似たような機能としては、蔵書プラグインやFAQプラグインもある。

Redmine 1.0.xをCentOS 5.5にインストールするメモ

Redmine - PluginEzlibrarian - Redmine

Redmine - PluginEzfaq - Redmine

日々の問合せで蓄積されたナレッジ(ノウハウ)は、FAQとしてまとめて、公開できるようにしておくと良い。
「パスワードを忘れました!」などの問い合わせが多いならば、FAQに解決方法を書いておき、そのFAQを公開して、顧客が自ら解決できるような仕組みを作っておく。
そうすれば、引っ切り無しにかかってくる電話対応から開発者も開放されて、本来の作業に専念できるようになる。

RedmineはRailsなので、アイデアさえあればプラグインで機能追加しやすい。
色々試してみたらいいと思う。

| | コメント (0) | トラックバック (0)

2010/12/19

電卓の使い方

電卓の使い方についてメモ。

【元ネタ】
電卓の【GT】【M+】キーって使ってますか? 触れずのキー?で素早く計算![一般事務で働く・転職する]All About

簿記の学習(22) 電卓の使い方 - itouhiroメモ

メモリーキー - キーをフル活用しよう! - 電卓基礎知識 - 電卓 - メモリーキー CASIO

経理の女性は毎日の請求書、注文書、納品書、仕訳帳などで電卓を叩きまくる。
大企業の部課長も自分の部の損益計算書を作るために、Excelに書き込みながら電卓を使っている。

簿記の勉強では電卓が必須。
簿記2級の工業簿記や商業簿記では、電卓をすばやく使いこなさないと、せっかく流れが分かっていても計算で間違ってしまう。
工業簿記の勘定連絡図による仕訳、商業簿記における本支店会計では特にそうだ。

日商簿記検定2級 第120回総評【簿記検定ナビ】

電卓の使い方にはいくつかの奥義があると初めて知った。

[CE]・・・計算途中でまちがいを訂正
[GT]・・・Grand Total。[=]キーを押したとき表示される数値を全て加算。sum()と同じ。

[M+]・・・メモリーに入っている数値に現在表示している値を足す。画面に「M」が出る。クリップボードへコピーと同じ。
[M-]・・・メモリーに入っている数値に現在表示している値を引く。画面に「M」が出る。

[RM]・・・Recall Memory。メモリに入っている数値を表示する。クリップボードからペーストと同じ。
[CM]・・・メモリクリア。クリップボードのクリアと同じ。
[.]・・・少数になる。「0.95」の場合、「.95」を入力するのと同じ。
[▲]・・・桁下げ。一桁消せる。バックスペースと同じ。

他にもTipsがある。
在庫の商品単価を求めた後、移動平均法で各商品の金額を計算する場合、普通は下記のように単価を逐一入力して求める。

在庫の商品単価:5000円÷100個=@50円/個
A商品:@50×200個=1000円
B商品:@50×300個=1500円

電卓で省エネする場合、商品単価@50円/個を求めた後、下記のようにすれば、商品単価を入力せずに各商品を計算できる。

在庫の商品単価:5000円÷100個=@50円/個
A商品:××200個=1000円
B商品:××300個=1500円

さらに、[M+][RM]を使えば、合計値を求めることができる。

在庫の商品単価:5000円÷100個=@50円/個
A商品:××200個[M+]1000円
B商品:××300個[M+]1500円
[RM]2500円

[GT]を使えば、さらに電卓を押す回数も減る。

在庫の商品単価:5000円÷100個=@50円/個
A商品:××200個=1000円
B商品:××300個=1500円
[GT]2500円

電卓にも資格試験があるらしい。
その存在を知ってびっくりした。

電卓技能検定試験 | 一般財団法人 日本電卓技能検定協会 |

| | コメント (0) | トラックバック (0)

チケットがプロジェクトを駆動する #tidd

さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。
以下メモ書き。

【元ネタ】
[#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば

[#TiDD] チケット駆動開発がもたらすプロセス その2: ソフトウェアさかば

僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。
つまり、イテレーションありきでプロジェクトが開始すると思っていた。
その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。

さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。
多分、その話の方が流れはスムーズだし、現場でも実践しやすいと思う。

まずは、やらなくてはならない作業を全てチケットにまず書き出してみる。
そして、それらチケットを一つずつこなしていく。

すると、毎日の進捗がチケットの集計結果から、いつでも誰でも見えるようになる。
開発者の観点では、自分が担当のチケットの予定が見通せるので、作業しやすくなる。
チームの観点では、いつまでに何を作るべきか、というゴールがはっきりしてくるので、マイルストーンを立てやすくなる。
この点が、メンバーとプロジェクトの2階層のプロセスという意味。

そして、各メンバーの作業量が見える化されるので、たくさんのチケットに優先順位をつけたり、作業順序を替えたり、アサインを変えたりする。つまり、自然にスコープをコントロールするようになる。
ある程度まとまった単位のチケットが終了すれば、一つの機能が動作できるわけだから、リリースして顧客に受け入れてもらえばいい。
リリース時期を遅らせるほど、本来発覚すべきリスクが先延ばしにされるので、リスクが大きくなる。だから、定期的に小さくリリースすることで、チームが許容可能なリスクは受け入れて、大きなリスクにならないように調整するわけだ。

そして、朝会やふりかえりミーティングで、チームのゴールや各人の役割や作業を確認するようにすれば、チームの中で自然な役割分担と運用ルールが生まれる。
メンバーの能力に見合った運用ルールでしか結局作業できないから、現場中心のプロセス改善になる。

定期的なリリースが怖くなくなれば、リリースするサイクル(イテレーション)を短くしながら頻繁にリリースしていけばいい。
チームの許容可能なリスクが以前よりも大きく取れるなら、故意に早めにリリースして顧客のフィードバックを早めにもらって、修正していく手法も取ることができる。
つまり、チームが許容可能なリスクのサイズとイテレーションの期間は反比例する。

頻繁にリリースするようになれば、いつ何をリリースするのか、というリリース計画が重要になってくる。
顧客から届いた仕様変更をどのタイミングでリリースすべきか、システムとの整合性やメンバーの作業負荷を考慮しながら、リリース計画を頻繁に修正して、現実に見合った内容に変えていく。

さかばさんの話では、チケット駆動開発はまさに「チケットがプロジェクト内部の作業を生成して、メンバーもチームもチケットを共有して、リスクベースでリリースしていく」開発スタイルになる。
確かにこの話の方が、「チケットファースト」からチケット駆動開発のプラクティスやチケット駆動開発の特徴を説明できるからいいかもしれない。

| | コメント (0) | トラックバック (0)

2010/12/18

電子書籍の最新動向と成功の鍵

電子書籍の最新動向と成功の鍵という記事を見つけたのでメモ。

【元ネタ】
電子書籍~最新動向と成功の鍵~ | 雑誌デザイナーの視点からみる電子書籍

日本経済新聞、電子版を3月創刊。購読料は月額1000円から -INTERNET Watch

電子書籍~最新動向と成功の鍵~ | 雑誌デザイナーの視点からみる電子書籍の記事はとても分かりやすい。
電子書籍の特徴やビジネスモデルの本質がよく分かる。

電子書籍ビジネスの将来は、AppleのiTunesのように、SaaS形式で有料コンテンツを購入してもらえるような環境を整えることにある。
その環境も早く作らなければ、YouTubeやニコニコ動画の普及で動画コンテンツを有料で販売するビジネスが存在できなくなったように、遅かれ早かれそうなる。
そうなれば、新聞やマスコミ、出版と言う業界も右肩下がりになるだろう。

新聞業界で唯一光るのは、日経新聞の電子版ビジネスの成功だろう。
日経新聞という優良コンテンツがあるからこそ、電子版ビジネスが可能になった。
そもそも新聞は過去100年以上の歴史があるのだから、100年分の記事を検索できるような仕組みがあってもいいはず。
今は最新記事が出ても1週間後にはリンク切れもあったりする。
リンクが貼れないWebコンテンツは、後から参照できないので無意味だ。
かと言って、記事を全て無料でWeb化してしまえば、いつでもWebで検索できるのだから、わざわざ品質の悪い紙の新聞を買う必要もない。
紙の新聞は1日後には必ずゴミ箱行きになり、無駄に資源を浪費しているように思える。

しかし、単純に印刷物を電子化しただけでは結局売れない。
その理由が下記に書かれている。

どうして今の電子雑誌は読みづらいのか ―前編― | 雑誌デザイナーの視点からみる電子書籍

どうして今の電子雑誌は読みづらいのか ―後編― | 雑誌デザイナーの視点からみる電子書籍

iPhoneやiPadで読むことを想定すれば、文字フォントの大きさやレイアウトはすごく重要。
そして、ゲームやソフトと電子書籍がコンテンツや値段で比較されるのだから、電子書籍ならではの特徴を生かさねばビジネスとして成り立たないだろう。

電子書籍のうちepubの本質は、単なる書籍の電子化だけでなく、他のファイル形式よりもたくさんのデータを持っているからだ、という指摘は鋭い。
epubは、本文や画像、レイアウト(CSS)だけでなく、目次やリンクや索引などのアクセシビリティ、動画や音声へ変換したり文字を拡張したりできるユーザビリティがとても優れている。
しかも、所詮はXHTML+CSSをZip化しただけだから、テキスト変換ツールを使えば他ファイルへの中間形式としても使える。
HTMLがこれだけ普及した今、コンテンツをepub化するのは正直たやすいだろう。

epubの動向に今後も注目していく。

| | コメント (0) | トラックバック (0)

2010/12/17

アジャイル開発のインフラを支える三種の神器

「開発インフラの三種の神器といえばSCM, BTS, CI」という言葉から、チケット駆動開発とアジャイル開発、更にはソフトウェア開発の関係についてもう一度考え直してみる。
ラフなメモ書き。

【元ネタ】
金曜日は分散バージョン管理勉強会。大物スピーカーも来るよ! - watawata日記

【1】アジャイル開発は多分ソフトウェア開発をやっている人なら自然に理解できる概念だと思う。
イメージ的には、コーディング、コンパイル、実行を繰り返すプログラミングスタイルを開発プロセスへ抽象化すればいいだけだからだ。

でも、ソフトウェア開発は、プログラミング以外の雑多な作業が結構多い。
開発抽象化レイヤーを担う人: プログラマの思索にも書いたけれど、プログラマがプログラミングに専念してアジャイルに開発するには、雑多な作業を意識しなくても良い開発環境を必要とする。
その開発インフラはBTS、SCM、CIでほぼカバーできると直感している。

アジャイル開発の最大の特徴は小規模リリースだと思っている。
短期間に頻繁にリリースしながら品質を改善し機能を拡張していく開発スタイル。
でも、従来の開発プロセスやプロジェクト管理手法では、短期間に次々にリリースしていくのがとても難しい。
タスク管理、進捗管理、変更管理がその開発速度に追いつけていないからだ。

そして、アジャイル開発を実際に運用出来ていないチームの特徴としては、イテレーションという概念を自分たちで実装できていないことがあるだろう。
つまり、定期的にリリースしていく単位をうまく運用できず、従来のWF型開発のように、ただ1回のビッグバンリリースをやった後にデスマーチに陥る時が多いだろう。
リリースして初めて、ビルドエラーに気付いたり、顧客の要望と違っていた事実が判明するからだ。

更に、アジャイル開発が難しい原因として、繰り返し型開発は並行開発でもある事実を認識出来ていないこともあると思う。
小規模リリースを運用すると、リリースしたモジュールは本番環境で稼働中だが、その裏では開発チームが別のコードラインでガンガン機能追加していく開発スタイルになる。
そして、次のイテレーションでリリースする時、1個前のバージョンのモジュールは廃止されて新しいモジュールに入れ替わり、また裏では最新のコードラインが次のイテレーションに向けて開発されていく。

つまり、アジャイル開発はtrunkとリリースブランチという2本のコードラインを常時保守する並行開発になる。
だが、システムやが大規模になるほど、製品ファミリーが多いほど、並行開発を制御するのは難しい。

アジャイル開発を実現するにはそれなりの開発環境が必要になってくる。

【2】最近はソフトウェア開発をサポートするツールのうち、オープンソースのツールがとても優秀で使い易くなってきた印象がある。
バージョン管理(SCM)はCVSの頃から、SVN、そしてMercurialやGitのように進化している。
SCMがとても使い易くなった理由の一つは、TortoiseSVNのようにSCMクライアントが高機能になって、ユーザへの敷居が低くなったからだろう。
高機能なSCMのおかげで、構成管理パターンが普及して、並行開発を従来よりも楽に運用できるようになっている。

また、XPが提唱した継続的インテグレーション(CI)は、Hudsonという優れたツールが普及している。
Hudsonはビルド結果のレポート出力が充実している。
またプラグインを追加していけば、BTSやSCM、更には他ツールとも連携できる利点がある。
CIのおかげでコードラインは常時リリース可能な品質が保たれる。

そして、BTS自体もITSへ進化して、最近はRedmineやTracのようにアジャイル開発のプロジェクト管理に使う発想が生まれている。
チケット駆動開発はTracのチケット管理から生まれた。(まちゅさんが最初に提唱された)
そのアイデアをアジャイル開発のプロジェクト管理に応用できると気づいた人達が、いろんなアイデアを試している。

チケット駆動開発の発想は、チケットをXPのタスクカードのように扱うこと。
そこから、リアルタイムな進捗管理、成果物とチケットの連携が可能になる。
これによって、変化に強いタスク管理が可能になり、成果物のトレーサビリティも楽になる。

そして、BTSのワークフロー管理を使えば、チケットを通じて厳格な変更管理を透明に行うことが可能になる。
このおかげで、開発者は作業だけに専念すれば、自然に厳格なワークフローに即して作業できるようになる。

【3】チケット駆動開発で改めて理解した概念は「バージョン」だ。
リリース予定バージョンをイテレーションに紐づければ、自然に小規模リリースを実現できる。
更に、イテレーションをリリースモジュールのバージョンに紐づければ、CIツールと自然に連携できる。
これによって、どのモジュールにどんな修正が含まれているか、を簡単に追跡できるようになる。

バージョンを大規模プロジェクトに拡張すれば、アジャイルリリーストレインという概念にもつながる。
つまり、複数チームのイテレーションを同期させることによって、複数のチームの成果物の同期がスムーズになり、開発の遅延の伝播がなくなる。

又、バージョンをイテレーションに同一視すれば、そこから開発のリズムが生まれる。
チームのゴールがイテレーション終了時のリリースだとメンバー全員に通知できるから、メンバーのベクトルが一つに向く。
チームのゴールが分かるからこそ、チームは何をすべきか、自分の役割は何か、が自然に気づくようになる。

そしてリリース後に、BTSに貯められたリリース履歴を見ながらKPTでふりかえりをやると、とても効果的。
Keepとしてあげられた内容は、開発チームの運用ルールやプラクティスとして、次のイテレーションで使える。
Keepはまさにプロセス資産。

Problemとしてあげられた問題は、Tryに是正対策としてまとめられて、次のイテレーションで実験したり試行錯誤するきっかけになる。
その結果が次のイテレーションのふりかえりで評価されて、開発チームの運用ノウハウが溜まっていく。

KPTによるふりかえりは、開発チームの成長のために必要不可欠なプラクティス。
プロジェクトファシリテーションとチケット駆動開発の強い関連性はもっと研究されてもいいと思う。

【4】XPは元々、ソースの共同所有や継続的インテグレーションなどのアイデアで、SCMやCIの重要性は主張していたが、それだけでは物足りない気がしていた。
でも、高機能なBTSを基盤としてチケット駆動開発を運用する手法によって、アジャイル開発の最後のピースが埋まったような気がする。

RedmineやTracによるチケット駆動開発の上で、Scrumなどのアジャイル開発のプロジェクト管理のアイデアは全て実現できるはずと直感している。

【補足】
ITS・SCM・CIを3種の神器と命名した人は、@haru_iidaさんだそうです。

Twitter / @かぬ: TracLightning/Kanon使うと3分で導入できますね(^^ RT @changeworlds: ITSとCIと構成管理システムで解決しますよ。これ三種の神器と言います。命名は@haru_iidaさんです。 #aj11 #aj11toy

| | コメント (0) | トラックバック (0)

2010/12/15

【告知】SEA関西プロセス分科会で「TestLinkのベストプラクティス」を講演します

第43回 SEA関西プロセス分科会のご案内

--------------------------------------------------------
~~ 第43回 SEA関西プロセス分科会のご案内 ~~

テーマ1:チケット駆動開発による現場力の向上
講師  :阪井 誠 氏(株式会社SRA)
(「Redmineによるタスクマネジメント実践技法」著者)

テーマ2:TestLinkのベストプラクティス
講師  :小川 明彦 氏(XPJUG関西)
(「Redmineによるタスクマネジメント実践技法」著者)

テーマ3:なぜなぜ分析は、なんでうまくいかへんねん
講師   てふかん(テスト技術者交流会 関西勉強会)
角口 勝隆 氏
新美 崇宏 氏
渡辺 亮 氏


主催 :ソフトウェア技術者協会 関西支部 プロセス分科会

日時 :2011年01月15日(土) 13:00~17:00

会場 :大阪市立大学文化交流センター
〒530-0001 大阪市北区梅田1-2-2-600
大阪駅前第2ビル6階 ホール
Tel 06-6344-5425 / Fax 06-6344-5524
大阪市立大学 - 文化交流センター
周辺略地図
大阪市立大学 - 文化交流センター

内容 :

前回の第42回「セーフウェア」から久々の開催となる今回は、土曜日の午後いっぱいを使っての、テーマ3本立てとなります。
前半は、先ごろ出版された書籍「Redmineによるタスクマネジメント実践技法」の著者お二人による、Redmineによるチケット駆動開発とTestLinkによるテスト改善に関する実践体験に基づいた講演です。
後半は、今年の ETWestコミュニティセッションに登場して好評を博したTEF(テスト技術者交流会)関西勉強会のみなさんによる「なぜなぜ分析は、なんでうまくいかへんねん」の続編として、さらに発展したセッションをお届けします。
様々な手法に関する情報が飛び交う中で、地に足のついた現場での実践に向けての貴重な情報共有と意見交換の場となることを期待しています。

13:00 ~ 13:10
開会挨拶と講演者紹介

13:10 ~ 13:55 講演1
チケット駆動開発による現場力の向上
講演者:阪井誠氏(SRA)

ソフトウェア環境が進化するにつれて高機能なシステムを短期間に構築することが可能になりました。その反面、その開発作業はより複雑で大変なものになり、気合、根性、規律が必要な場面が増えてきました。
チケット駆動開発では、
(1) 障害管理ツールのチケットでタスク管理する
(2) 構成管理ツールなどのツール連携によって自動化と履歴管理をする
(3)ワークフローで手順もれをなくす
ことが可能です。
今回は、このようなチケット駆動開発の概要と、チケット駆動開発の導入によって、プロジェクトが混乱を脱して、元気になった事例を報告します。

14:05 ~ 14:50 講演2
TestLinkのベストプラクティス
講演者:小川明彦氏(XPJUG関西)

昨今のソフトウェア開発では、設計やプログラミングなどの上流工程の技術革新が著しい一方、テスト管理や品質管理が軽視されている傾向が見受けられます。
この状況に対し、XPを代表とするアジャイル開発手法は単体テスト工程にテスト駆動開発や継続的インテグレーションという新しい概念を導入しましたが、結合テスト以降のテスト工程には適用しづらく、品質保証に不十分な面があります。
本講演ではこれらの問題に対し、アジャイル開発とテスト管理ツールTestLinkを組み合わせて効果的に運用した経験を踏まえて、テスト管理に関するベストプラクティスについて解説します。

15:00 ~ 16:20 講演3
ウワサの3人が登場!
なぜなぜ分析は、なんでうまくいかへんねん? リターンズ
講演者:TEF関西 角口勝隆氏、新美崇宏氏、渡辺亮氏

ソフトウェア開発の現場では、些細なミスがきっかけで大きな損失を被ることもある。
失敗を繰り返さないために、「なぜ?」を5回繰り返して原因分析をすれば良いと言われるが、案外簡単なようで、時にはとんでもない分析結果を導き出すこともあり、実際に行ってみると難しいものである。
当セッションは、「なぜなぜ分析」のアンチパターンから学ぶ、最低限失敗をしないためのポイント解説と、失敗分析理論について考察をする。
Part1:アンチパターン
Part2:分析理論

16:30 - 17:00 質疑応答・ディスカッション

※講演者の都合により、講演の順序が変更となる場合があります。
ご了承ください。

参加費用:
(参加費のみ)
SEA正会員:1,500円,SEA賛助会員:1,500円,
学生:1,000円,一般:3,000円
(書籍付:申し込みは1月8日まで)
SEA正会員:4,000円,SEA賛助会員:4,000円,
学生:3,500円,一般:5,500円

定員 :120名

申込方法:
以下のペ‐ジからお申し込みの受付を行っております.
Application - Kikuno Laboratory
### 01/13(木)までにお申し込みください(書籍付は1/8まで) ###

今回は書籍「Redmineによるタスクマネジメント実践技法」付きのセット価格を用意しました(定価3,444円)。
セット価格をご希望の方は、申込みフォームの最後の「分科会のテーマに関するご要望などをご自由にどうぞ」の欄に「Redmine書籍セット希望」とご記入下さい.
★注意★
出版社との手続きの都合上、書籍セットでの参加申込みは1/8(土)までにお願い致します。
また、欠席で当日お渡しできなかった場合は後日発送させていただきますが、送料はご負担願います。

ご注意)
・受付は先着順で,定員になり次第〆切とさせていただきます.
申込受付後のキャンセルは原則としてお断りします.
・メール,FAXなどWebページ以外からの申し込みは受け付けておりません.
・お申し込みの受付け後,確認メールが自動的に返送されます.
確認メールを印刷し,当日受付時に持参ください.
・申し込み手続きについて不明点などございましたら下記までご連絡ください.
seakansai-req@sea.jp
・参加費は当日会場受付にて現金でお支払いください
領収書が必要な方は,申し込み時に「領収書要」にチェックしてください.

-------

【談】
Redmineによるタスクマネジメント実践技法」はRedmineとチケット駆動開発に関するお話がメインではありますが、実はTestLinkによるテスト管理も1/3の頁数を費やして書いてます。
意外にも(?)、テスト管理や品質管理の技法は日本のSIの現場の一部ではよく知られていて、ノウハウが結構たまっています。

僕自身、TestLinkを運用してみて、テスト管理や品質管理の奥深さを随分経験することができました。
今回は、チケット駆動開発のお話はさかばさんにお任せして、TestLinkを過去2年以上運用して経験したこと、理解したこと、思索したことについて語ってみます。

| | コメント (0) | トラックバック (0)

2010/12/13

品質管理ツールSonarの記事

@ITにおかもとさんが品質管理ツールSonarの記事を書いておられたのでメモ。

【元ネタ】
コード探知機「Sonar」でプロジェクトの深海を探れ! (1/4) - @IT

Sonarでソースの品質をチェックする: プログラマの思索

メトリクスでソフトウェア品質を見える化する: プログラマの思索

複雑度と単体テストケース数の相関関係: プログラマの思索

Sonarはインストール出来ていたものの、使いこなせてなかったので、とても参考になる。
Sonarで一番知りたいメトリクスは複雑度だ。
複雑度と単体テストケース数の相関関係: プログラマの思索でも書いたけれど、複雑度と単体テストケース数は密接に絡んでいる。

ソフトウェア複雑度(McCabeのサイクロマチック数)
≒分岐網羅(C1)のテストケース数
≒単体テストケース数
という関係があるから、複雑度が大きいほど単体テストケース数が膨らむ。
たとえJUnitで単体テストを自動化していても、複雑度が大きすぎるプログラムはどこかにバグが潜んでいる。

IF文やFor文がたくさんネストしているプログラムは、それだけで簡単に複雑度は30以上は超える。
おそらくどんなシステムでも、複雑度が30を超えるプログラムは10個ぐらいはあるように思う。
特に本番稼働後、たくさんのパッチを当てる度に複雑度は増していく。

他の会社では、複雑度が15以上のプログラムはコードレビューを必須として、30を超えたら書き直すかどうか方針を下すという話を聞いたことがある。

個人的には、複雑度が30以上のプログラムは、リファクタリングして書き直した方が、その後の結合テストでも修正しやすいし、リリース後の運用保守でも機能追加しやすくなると思う。
こみいったプログラムの保守ほど嫌な作業はない。
プログラムに手を入れて変更するだけで、新たなバグを作ってしまう可能性が高いからだ。

SonarやStatSVNなどのメトリクス出力ツールを使って、いつでも開発者が自分たちのシステムの品質を見るようにすれば、自然に綺麗なプログラムを書こうという意識が生まれるだろう。
品質の見える化は開発者のプログラミング作法を自然に変えてくれるはずだ。

| | コメント (0) | トラックバック (0)

2010/12/12

プロジェクト管理ツールを使いこなせないのはITリテラシーが低いから

何故、Excelによるプロジェクト管理に限界があると分かっているのに、プロジェクト管理ツールを使わないプロマネが多いのは何故か?
実は、従来のプロマネはITリテラシーが低いのではないか、という原因で考えてみた。

【元ネタ】
情報リテラシー - @IT情報マネジメント用語事典

ITリテラシーとは本来、情報やデータを扱う時にコンピュータを操作できることを指す。
そこから、コンピュータを使って情報を収集したり加工したり発信する能力まで指すようになった。
上記の用語辞典によれば、情報システムを企画し、業務をIT化して変革していく能力まで対象にする時もあるらしい。

(前略)
 リテラシーとは本来「識字力=文字を読み書きする能力」のことで、情報リテラシーとは情報・情報機器活用能力がナレッジワーカーにとって“基礎的能力” であることを示す言葉だが、企業などにおける情報活用が高度化するに伴って、情報システムを企画し、業務のやり方を主体的に変えていく能力なども情報リテラシーの対象にする場合もあるようだ。

その発想でいけば、従来のExcelによるプロジェクト管理では、アジャイル開発のような頻繁にリリースする開発スタイルは実現できないことは明らか。
その開発速度に追いつけないからだ。
度重なるタスクの変更や突発的なバグ修正、顧客からの仕様変更をExcelで随時反映して、追跡していくのは正直難しい。

しかし、Excelにしがみついてしまう理由は、プロジェクト管理ツールの使い方に慣れて、開発チームで運用する方法が分かっていないからだろう。

SIが顧客の業務をIT化して業務を改善していくソリューションビジネスが主なビジネスモデルなのに、実は自分たち自身の業務分析ができておらず、業務をIT化できてない。
障害報告票をExcelや紙で管理しているチームはいないだろうか?
モジュールのリリースをExcelの管理台帳で管理していて、必ず紙で印刷してマネージャの判子で承認してもらうフローで運用しているチームはいないだろうか?

つまり、広義の意味で、プロジェクト管理ツールを使いこなせないのはITリテラシーが低いと言えるのではなかろうか?

| | コメント (0) | トラックバック (0)

BTSを制する者がソフトウェア開発を制する

Redmine、Trac、Mantisを使ってみて、ソフトウェア開発はバグ管理が最も基本のプロセスだと改めて感じた。
「BTSを制する者がソフトウェア開発を制する」という気がする。
以下、BTSについて経験したこと、考えたことをロジカルでないメモ書き。

ウォーターフォール型開発でよくあるパターンは、要件定義、設計、開発、単体テストまで順調に進むが、結合テストでたくさんのバグが噴出して、初めて問題が現れる時が多い。
その時、障害管理のためにBTSを使って、見つけたバグを一つずつ潰していく。
アジャイル開発であろうとも、イテレーション期間中に見つけたバグは、BTSで管理しているだろう。

ソフトウェア開発では、障害管理のプロセスが重要な気がしている。
いくら設計しても、単体テストをやっても、ユーザの観点で動かさなければ、開発者も自分が作ったシステムの全貌を知ることはできない。
1回のリリースは100回の設計に勝る点がある。
リリースしてみて、当初の動きと異なった点は障害管理票として起票して、一つずつバグを潰していく。
ソフトウェア開発の殆どの作業は、この作業に尽きる。

障害管理のプロセスや方法については、従来から色々知られている。
でも、まとまった良い本がない気がする。
障害管理のプロセスをきちんと理論として理解して、現場で実践している所は意外と少ないのではないか?
つまり、障害管理を場当たり的にやってはいないだろうか?

普通は、BTS(バグ管理システム)で障害管理を行うのが普通だろう。
BTSとしては、Bugzilla、Mantis、Trac、Redmineなどがあげられるだろう。
BTSについてどれだけノウハウを持っているだろうか?

BTSの使い方について、下記の観点で洗い出してみる。

【チケットの属性】
BTSの障害報告票はチケットとも呼ばれる。
チケットの基本的な属性は、起票者、担当者、ステータス、起票日、完了日、内容があげられるだろう。
プロジェクトマネージャの観点では、チケットの属性はもっと増やしていきたい。
例えば、作業予定完了日を追加して、いつ頃終わるのかを把握したい。
あるいは、予定工数や実績工数を追加して、予定・実績の工数比較を行って、スケジュール管理をしたい。
開発環境アップ日、受入環境アップ日、本番リリース日などを入れて、障害修正が今どの環境にあるのかを把握したい、など。
だから、プロマネは属性を増やして、必須項目にさせる運用をしてしまいがち。

だが、チケットの属性を増やすほど、障害管理のプロセスは重くなり、障害報告票を起票するだけで1時間以上かかってしまう時もある。
そうすると、バグが多発した時に起票プロセスがボトルネックになる。
だからチケットの属性をどこまでに絞るか、という観点は、開発の速度に直結すると思う。

個人的には、Redmineの複数プロジェクト機能を使って、開発時の障害管理と本番運用時の障害管理を分けて、チケットの属性も分けた方がいいのではないかと思う。
少なくとも、本番運用時に発覚した障害管理は厳格に管理しないと、同類バグ調査や影響調査で手抜きを行ったり、デグレが発生したりする。
すると、顧客の信用を失うので、複雑なワークフローになりがち。

バランスが重要だと思う。

【重要度と優先度】
障害報告票には普通、重要度と優先度という属性が付属している。
その内容については既に書いた。

障害管理における重要度と優先度の使い分け: プログラマの思索

バグの優先度は意思決定プロセスの結果: プログラマの思索

一言で言えば、重要度はストーリーカード(顧客の観点)、優先度はタスクカード(開発チームの観点)で使い分けるべき。
開発チームにとって、優先度は作業の優先順位に直結する。

アート・オブ・プロジェクトマネジメント: プログラマの思索にも書いたけれど、プロジェクトマネージャは優先順位付けマシンそのもの。
だから、彼の第一の仕事は、たくさんあがってきた障害報告票に対し、重要度と優先度を付けて、どの障害を優先してリリースするのか、を決めることだ。

すなわち、優先度とチケットの取捨選択、更にはイテレーション計画やリリース計画は密接に絡んでいると思う。

【ステータスと解決状況】
ステータスと解決状況の違いに付いては下記に書いた。

BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索

一言で言えば、解決状況は障害修正の終了条件の属性の一つだ。
解決状況を集計して、テストプロセスやシステムの品質を推測するのに使いたいために、この属性を使うのが普通だろう。
但し、MantisやJiraでは、解決状況がシステム上特別な意味を持っているので、注意した方がいい。

【ステータスとワークフロー】
障害管理票で重要な属性は、ステータス(作業状態)だ。
そして、ステータスを制御するのがワークフロー。
BTSでは、ワークフローが普通はほぼ1つに決まっている。
何故なら、バグ修正とバグ検証の組み合わせがソフトウェア開発の最も基本的なプロセスだからだ。

このプロセスを「アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」ではコーディングパイプラインと呼んでいる。
つまり、開発者とテスター(又は設計者)がペアになって、成果物をお互いにチェックし合う作業がソフトウェア開発の基本的なワークフローになっていることを意味している。
コーディングパイプラインが開発チームでスムーズに運用できていれば、バグ修正だけでなく、仕様変更にも同様に対応できるから、プロジェクト後半になるほど重要なプロセスになる。

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

アート・オブ・プロジェクトマネジメント: プログラマの思索

だが、ソフトウェア開発のワークフローはバグ修正だけではない。
RedmineやTrac、Mantisでは問合せや課題の管理がやりにくい、とよく言われるが、その原因は、問合せとバグ修正は全く違うワークフローなのに、バグ修正のワークフローで運用しようとしているからだ。
詳しくは下記に書いた。

Tracのワークフロー: プログラマの思索

RedmineとTracの機能比較: プログラマの思索

ワークフロー管理はプロジェクト管理で最も重要な概念の一つ。
プロマネがワークフローを何種類持っていて、状況に応じてどのように使い分けているのか、を見れば、プロマネの能力は一目で分かるだろう。

【バグ収束曲線・メトリクス】
BTSの利点の一つは、過去の障害データが一括管理されているので、そこから各種のメトリクスを出力できることだ。
よく使われるのは、信頼度成長曲線(SRGM)、別名はバグ収束曲線だろう。
実際のテスト工程では、テスト消化曲線とバグ発生曲線を一つのグラフでまとめると、テストプロセスの品質が一目で分かる。
詳細は下記に書いた。

テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索

メトリクスでソフトウェア品質を見える化する: プログラマの思索

信頼度成長曲線(SRGM)は既に理論としては既に枯れているアイデアだが、そこからMTBFやMTTRを理論的に計算できる点が興味深い。
SRATSというフリーのExcelマクロを使えば、システムのMTBFを計算することも可能。

SRATSの使い方: プログラマの思索

個人的には、MTTRの方が重要な気がしている。
何故なら、平均修復時間(MTTR)はチケットの平均作業完了時間とほぼ同じ概念だからだ。
Mantisでは、チケットの平均作業完了日数がデフォルトで表示されているので便利。

Mantisのチケット集計機能にある最大放置日数と平均完了日数: プログラマの思索

MTTRが重要な理由の一つは、MTTRとイテレーションが密接に関係するからだ。
アジャイル開発では、MTBFを長くするよりも、MTTRを短くすることによって、稼働率を高めようとする方向が見受けられる。

アジャイル開発と品質管理の関係: プログラマの思索

XPやScrumのイテレーションは普通は1ヶ月だが、もちろんもっと短くすることも可能。
だが、理論上はMTTRよりもイテレーションを短くすることはできない。

【同類バグ・残存バグ・ブロッキングバグ・みなしバグ】
障害管理では単にバグ修正だけでなく、バグの原因分析や同類バグ(同種バグ)の調査の方が重要だ。
何故なら、バグの周囲には似たようなバグがたくさん潜んでいるからだ。
バグの原因には、特定の開発者が仕様を誤って理解しているがために、彼が開発したソース全てに影響がある時もある。
あるいは、バグの原因がとても繊細なため、そのバグが治っても、他の機能に影響があるために、他の修正方法を選択せざるを得ない時もある。
バグはマインスイーパーのように、同種バグがたくさんあるのが普通のため、修正工数よりも原因分析や影響調査の方に工数がかかる時が多い。

バグはマインスイーパーみたいだ: プログラマの思索

同類バグに似たような概念として、残存バグがある。
残存バグとは、テスト工程でバグを完全に潰しきれずに、残したまま本番リリースしてしまい、リリース後に発見したバグを指す。
残存バグが多いほど、そのシステムの品質は低い。
テスト技術や品質管理では、いかに残存バグを洗い出して、信頼性を高めていくか、を重視する。

バグの概念としては、ブロッキングバグやみなしバグなどがある。
普通は、一つのバグが発覚したら、そのバグのせいで、失敗したテストケースに依存するテストケースがブロック状態になる。
ブロッキングバグは文字通り、テストだけでなくプロジェクト全体をブロックしてしまう重大なバグを指す。
ブロッキングバグのせいで、実施しないテストケースも失敗になると分かっていたら、テストケースをみなしNGとして、そのバグはみなしバグと見なす。

テスト管理では、ブロッキングバグをいかに早く見つけて潰し、テストの進捗を妨げないように進めるか、が重要だ。
だから、TestLinkのブロックは、テスト管理で最も重要な技術の一つ。

TestLinkを運用して気付いたことpart8~みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索

TestLinkを運用して気付いたことpart5~TestLinkのテストケースの概念: プログラマの思索

バグ修正で怖いのは、バグ修正時に他のバグを入れ込んでしまう可能性があること。
「欠陥フィードバック率(FFR:Fault Feedback Ratio)」とは、バグ修正によって引き起こされるリグレッション率を指す。
アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)」では、「10回バグ修正したら、1~3回もデグレ又は別のバグが発生する」と紹介されている。
おそらく普通のプロジェクトでも同じようなメトリクスになると思われるから、バグ修正した時は、バグの検証だけでなくコードレビューやデザインレビューで、デグレが起きてないことを確認したり、修正の影響がないことを見極めることが重要になってくる。
そうしなければ、デグレが起きてしまい、開発チームやテストチームのモチベーションを下げてしまう。

アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する: プログラマの思索

障害管理で嫌なのは、バグがもぐら叩きのようにでてくることだ。
TestLinkのアンチパターン: プログラマの思索でも書いたけれど、ブロックを使わないテストチームは、みなしバグがあると分かっているテストを行って、無駄にテスト工数を浪費してしまい、納期までに間に合わなくなる。
あるいは、ブロッキングバグの影響調査に工数をあまりかけずに安易に修正してOKとしてしまって、新たなバグを作ってしまう時もある。

バグの原因分析やデグレを起こさない回帰テストがテスト工程では重要な技術の一つ。

【ITSへ拡張】
障害管理はソフトウェア開発で最も基本的なワークフローであるがために、このワークフローを仕様変更や新規開発、課題管理などへ拡張して使おうという発想が生まれた。
この発想がIssue Trackingと呼ばれる概念になる。
チケット駆動開発は元々まちゅさんがTracのチケット管理として公開したアイデアだが、BTSをIssue Tracking Systemとして扱うだけでなく、高機能化したBTSをアジャイル開発のプロジェクト管理に使う流れにつながる。

チケット駆動開発については又改めて書く。

| | コメント (0) | トラックバック (0)

2010/12/08

チケット駆動開発が進むべき道part2~プロジェクト管理サーバーは開発チームの資産

プロジェクト管理の歴史が書かれた記事から、チケット駆動開発に至っている現在を連想した。
又、「プロジェクト・マネジメントは組織としての能力である」という記事から、チケット駆動開発が進むべき道について考えたことをメモ。
ラフなメモ書き。

【元ネタ】
ECナビ エンジニアブログ : ECナビにおける案件管理の歴史 ~Excel/MS ProjectからRedmineまで~

プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である

ECナビ エンジニアブログ : ECナビにおける案件管理の歴史 ~Excel/MS ProjectからRedmineまで~を読むと、Excel・MS Project→自作ツール→Trac・Redmineに至る流れの背景がよく分かる。

10年前まではオープンソースのプロジェクト管理ツールは存在せず、紙やExcelで障害報告してタスク管理してワークフロー管理していたのだ。
だが、今のように短期間にアウトプットを出さなくてはならない状況が多いと、もはやそのような作業をのんびりすることはできなくなっている。

特に、運用ルールの徹底が難しい。
何故なら、新規加入のメンバーや新人が運用ルールに慣れるために、大量のドキュメントを読まざるを得ないが、実際に実行してみると、プロセスを飛ばしていたり、ドキュメントに書かれていない運用ルールがあったりするからだ。
プロジェクトリーダーの仕事の一つは、運用ルールを作ることにあるが、チームに馴染まない運用ルールを提案して、メンバーに強制しても逆に混乱するだけだ。

チケット駆動開発の利点はいくつかある。
一つ目は、RedmineやTrac、Subversion、Hudson、Gitのようなツールに慣れれば、自然にソフトウェア開発のベストプラクティスが身に付くこと。

作業を開始する時はToDo代わりにチケットを自分で登録して、作業履歴を自ら残す習慣が身に付けば、自分自身で作業を振り返るきっかけになるし、メンバーと情報共有できる場にもなる。
コミットログにチケットNoを書く習慣を身に付ければ、コミットする目的を必ず自覚するようになるし、不用意なコミットもなくなる。
また、コミットログに残されたチケットNoから、過去の修正理由を探すことも楽になる。
あるいは、GitやMercurialのバージョン管理でブランチを状況によって使い分ける手法を身に付ければ、機能追加していくコードラインと品質重視のコードラインを別々に維持しやすくなるし、突然の仕様変更があったとしても、緊急リリースに対応出来るインフラもある。

特に、オープンソースのツールは世界中のたくさんの開発者が試してきて、良いと思われた機能を実装しているのだから、その機能に慣れた方がプログラミングの良い習慣が身に付く。

二つ目は、開発者や管理者の作業を透過的にサポートするインフラがあること。
ソフトウェア開発はバージョンアップが激しいため、元々変化しやすい。
そんなソフトウェア開発のプロセスで重要なのは、多種多様なバージョンアップ作業を変更管理プロセスで制御すること。
しかし、大量のドキュメントや申請・承認が厳格すぎる運用ルールは、開発の機動力を落とし、メンバーを無気力にさせる。
チケット駆動開発なら、チケットの種類をワークフローに紐づけることによって、メンバーにワークフローを意識させずに、一つの成果物を複数人でチェックすることが自然にできる。
また、チケットに予定・実績工数・ステータスなどを入力する運用ルールを徹底できれば、開発者は進捗報告を気にせずに作業に専念できるし、管理者はRedmineやTracのような優れたチケット集計機能によって、リアルタイムに進捗や品質をモニタリングできる。

以上の二つは、プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうち、「プロジェクト遂行手順・WBS体系などの標準」に相当するだろう。

三つ目は、チケット駆動開発を運用するインフラが開発チームの資産になること。
チケット駆動開発を運用するインフラとしては、タスク管理(Redmine・Trac)、構成管理(SVN・Git)、ビルド管理(Hudson)、テスト管理(TestLink)、メトリクス出力(StatSVN)などがあげられる。
それらのツールからなるインフラは、開発チームのプロジェクト管理をサポートするプロジェクト管理サーバーそのものになる。
つまり、プロジェクト管理サーバーはPMBOKの言うPMIS(プロジェクトマネジメント・ソフトウェア)そのものになるはずだ。

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

プロジェクト管理サーバーとは: プログラマの思索

そのプロジェクト管理サーバーがあれば、日々の開発チームの活動のログが貯められる。
そのログはサーバー上で一括管理できるので、進捗や品質をいろんな観点で分析することによって、プロジェクトの現状を報告したり、プロジェクトの将来を予測することが可能になる。
いわゆるソフトウェア・リポジトリ・マイニングと同じ。
つまり、プロジェクト管理サーバーに溜まった過去の実績データは、開発チームの資産そのものだ。
過去の実績データがあるからこそ、開発や運用ノウハウが貯められるし、Web上にあるからこそ、メンバーは簡単に全文検索して探すこともできる。
更に、メンバー全員でKPTによるふりかえりを行えば、より有効な知見を見出すことができるだろう。

プロジェクト管理サーバーのメトリクスは教科書みたいだ: プログラマの思索

ソフトウェア・リポジトリ・マイニング~Web2.0をソフトウェア工学に応用する: プログラマの思索

BTSをBusiness Intelligenceとして使う: プログラマの思索

これは、プロジェクトマネジメント ワンポイント講義~プロジェクト・マネジメントは組織としての能力である の記事にあるプロジェクト・マネジメント能の中層構造のうちの「過去の実績データ」、あるいは「プロセス資産」に相当するだろう。

プロジェクト管理サーバーがプロセス資産であるという意味は重要だと思う。
ツールを使いこなすほど、作業の効率は増すし、運用ノウハウがたまり、更に開発チームに見合った運用ルールが生まれる。
プロセス改善で得られたノウハウは、まさに開発チームの資産だからだ。

チケット駆動開発によって、ソフトウェア開発のプロジェクト管理のハードルが下がって、もっとクリエイティブに開発できる。
そんな環境が誰でも容易に手に入る時代になったのだな、と思う。

| | コメント (0) | トラックバック (0)

2010/12/07

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart6 #tidd

Redmineによるタスクマネジメント実践技法」の感想を見つけたのでメモ。

【元ネタ1】
Redmineによるタスクマネジメント実践技法 - プログラマーな日々

(引用開始)
ブログ(プログラマの思索)で日々質の高いエントリを投稿しているあきぴーさんの執筆ということで心待ちにしていたが、期待を裏切らない内容だった。やはり実践を伴った主張には説得力がある。
チケット駆動開発の効用は、何といってもトレーサビリティ(追跡可能性)の確保だろう。
ソースの変更と変更理由の結束の保証。一度でも開発を経験した人なら、これがどれだけ大きな価値をもつか説明は不要だろう。顧客の「いつどんな理由でこの変更をしたのですか?」という問い合わせにマネージャは即答でき、開発者はコメントが書かれていることを祈りながら過去のソースコードを追う必要がなくなるわけだから。
問題は導入コストだろう。この書籍で実現されていることには憧憬すら覚えたが、アプリケーションは無償でも学習コストは非常に高いと感じた。
段階的導入は可能だろうか?まずはタスクのワークフローとして使ってみるとか。導入コストは非常に大きな問題だ。どうにかしてメンバーが前向きに取り組めるようにしないと、やらされていると感じているうちは導入は遅々として進まないだろう。
結論。開発者はもちろん、マネージャにこそ読んでほしい本だ。
(引用終り)

ありがとうございます。
トレーサビリティの運用ルールはまちゅさんが「No Ticket, No Commit!」と呼んでいますが、このルールに一度慣れてしまうと、チケットNoがコミットログに書かれていないソースは触るのが怖くなります。
意味不明なパッチにも実は過去の障害修正を引き継いでいる、といった裏話はソフトウェア業界では当たり前ですから。
確かにプロジェクトリーダーやプロジェクトマネージャと呼ばれる人達にこそ、Excelではなくプロジェクト管理ツールによってプロジェクト運営の効率が高まることを実感して欲しいと思います。

【元ネタ2】
Redmineによるタスクマネジメント実践技法:ハードな日々:So-netブログ

(前略)
各所にアジャイル、XP(eXtreme Programming)、Scrumというワードが出てきます。おそらくソフトウェア開発者にとっては常識になっている言葉だろうと思いますが、私のような純粋なハードウェア開発しかしたことがない者は全く知りません。「XPのイテレーション計画」、「Scrumのバックログ」と比較してどうかという解説が多く見られますが、どういうことなのか理解できませんでした。
また、本書で解説されているRedmineのバージョンは0.8ベースで、0.9については新機能が簡単にまとめられています。また最新バージョンとして1.0.1がリリースされたということが載っている程度です。
TestLinkのバージョンは1.7.4と2世代古いバージョンとなっています。
これらのツールのバージョンは頻繁にバージョンが上がっていますので、今後最新バージョンに対応して改版をしていかないと、あっという間に使えない本になってしまいそうです。
最後に、本書はRedmine、TestLinkを使った解説をしていますが、チケット駆動開発とテスト工程管理についての専門的な知識を得るのにも良い本だと思います。
(後略)

対象読者はソフトウェア業界の開発者や現場リーダーを想定していたので、ハードウェア技術者や製薬業界の人が呼んでいるとは思ってもみませんでした。
参考になります。
確かに、RedmineやTestLinkのバージョンアップの速度は速いので、次回出版する時は最新バージョンを説明できればと思います。

他にもあったら探してみる。

| | コメント (0) | トラックバック (0)

2010/12/05

電子書籍をポッドキャストで流す方法

電子書籍をポッドキャストで流す方法を書いた記事があったのでメモ。

【元ネタ】
EPUBのPodcast配信/RSSによる更新情報の配信の持つ可能性 ? CHINESE E-CHUBAN BLOG

ポッドキャストメーカー - Mac ソフト、Windows ソフトのことなら act2.com

[ポ] 簡単にePubをPodcastする方法 - ...My cup of tea...

Macのポッドキャストメーカーというソフトを使えば、iTunesでPodcastによるEPUB受信ができるらしい。
iTunesというクライアントソフトのおかげで、iPod/iPhone/iPad上で電子書籍を簡単に共有できるから、いつでもどこでも本を読むことができる。
この方法にはたくさんの可能性を秘めている。

例えば、書籍や写真集を電子書籍そのものとして流せば、本屋を経由せずに直接ユーザに販売できる。
あるいは、電子書籍を電子カタログの代わりに使えば、カタログ販売になる。

iTunesの本質はSaaSのクライアントソフトにある。
アップルが見出した音楽配信というインフラは、映画やニュースやソフトだけでなく、書籍でも何でも配信できる。
そのビジネスはとても大きなインパクトがある。

音楽は1曲4Mもファイルサイズがあるのに、1曲150円で売られている。
電子書籍は300ページでもepubなら1Mもないのに、今でも500円~3000円ぐらいで売られている。
ファイルサイズが小さいほど通信コストは安くなるから、電子書籍の方が楽曲よりもはるかに利益が大きいだろう。
その事実を皆が知ったら、書籍も価格破壊が起きるかもしれない。

| | コメント (0) | トラックバック (0)

2010/12/04

A successful Git branching model

Gitの使い方について良い記事があったのでメモ。

【元ネタ】
見えないチカラ: A successful Git branching model を翻訳しました

少人数開発に役立つ5つのまとめ

構成管理について良い本は、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」と「入門Git」の2冊。
これらの本を読んで理解した立場から書いてみる。

GitやMercurialのような分散バージョン管理では、ブランチをたくさん作るのが普通。
ブランチの目的を意識して、ブランチを管理するのが重要。

上記の記事では、メインブランチ、フィーチャーブランチ、リリースブランチ、ホットフィックスブランチの4種類が紹介されている。
僕の理解では、記事に書かれているメインブランチはtrunk、フィーチャーブランチはトピックブランチ、リリースブランチはまさにリリースブランチ、ホットフィックスブランチはタスクブランチに相当すると思う。

メインブランチは、全てのブランチの本流。
継続的インテグレーションで常時ビルドされていて、安定して最新の機能が常時リリース可能なコードライン。
パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」ではメインラインモデルと呼ばれている。
この手法の利点は、trunkが全てのブランチの派生元なため、ブランチを新たに作ることが容易になること。

逆に駄目な構成管理は、trunkを次々に乗り換えていくパターン。
どのコードラインを参照してブランチを派生させればいいか、開発者が混乱してしまうから。

フィーチャーブランチは、特定の目的だけのためにハックしたり、バグ修正のパッチを当てたりするためのブランチ。
入門Git」ではトピックブランチと呼ばれている。
トピックブランチでは、一つのトピックのためにブランチを派生させて、パッチを育てていく感覚。
トピックブランチへtrunkから最新のソースを取り込む時は、pullではなくrebaseが推奨されている。
rebaseなら、パッチを育ててきた履歴が残るから、後から修正理由を追跡しやすくなる。

上記の記事のリリースブランチは、リリース時期が決まりバージョン名が決まったら、派生させるブランチ。
メインライン(trunk)は最新の機能をどんどん拡張していくコードライン、リリースブランチは本番運用を前提としてバグ修正だけを行い、品質を重視するコードラインとして使い分ける。
つまり、機能拡張と本番運用の品質を重視する目的を分けたコードラインを保持することで、裏では機能拡張しながら安定した本番運用を行うことが可能になる。

ホットフィックスブランチは、「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)」ではタスクブランチと呼ばれている。
特定目的のためのブランチだが、トピックブランチとは違って、緊急性を持ったブランチの場合が多いだろう。
よくある例は、Ver1.0をリリース後、Ver2.0に向けて開発中のプロジェクトで、突然降ってきた顧客の要望を受入ざるを得ない場合、Ver1.1というバージョンを新たに作り、緊急リリースに対応する手法。
成功する要求仕様 失敗する要求仕様」では、上記のような例に対する選択肢の中で、ベターな選択肢の一つがタスクブランチで緊急リリースする方法としてあげられていた。

CVS、SVN、GitやMercurialに至るバージョン管理の歴史をたどると、構成管理パターンを見出す歴史と重なる。
こういうノウハウがもっと広がれば、もっとプログラミングしやすくなるだろうと思う。

| | コメント (0) | トラックバック (0)

2010/12/02

アジルマニュファクチャリングからアジャイルソフトウェア開発へ

アジャイルソフトウェア開発の発端は製造業におけるアジルマニュファクチャリングにあるというつぶやきを見つけたのでメモ。

【元ネタ】
Twitter / Ken Nishimura / 西村賢: うへ、アジャイルもリーンもソフト開発じゃなくて、1990年代米国製造業の流行語だったんですね、不勉強でした → アジルマニュファクチャリング - @IT情報マネジメント用語事典 http://bit.ly/ejlSyA

アジルマニュファクチャリング - @IT情報マネジメント用語事典

(前略)
この報告書では湾岸戦争における事例を採り上げている。1990年末、開戦必至の情勢を前に米国陸軍は砂漠戦に必要となる新たな敵味方識別装置の発注を急きょ行うことになった。しかし、仕様の決定や発注先の選定などに手間取り、実際に発注されたのは開戦の1カ月後だった(この間は空爆が主体で、陸軍部隊はまだイラク周辺で準備中だった)。装置製造企業は受注から5日後にプロトタイプを納入、その1週間後には数百台が前線に届けられた。発注から投入まで2週間のスピード生産であった。
 アジルマニュファクチャリングで用いられる技法は、リーン生産やコンカレント・エンジニアリング、BPR、系列などの日本的経営に由来する経営手法の影響を受けている。ただし、日本型のフレキシブル生産は企業の立場から効率化を狙ったものだが、アジルマニュファクチャリングは顧客や消費者に価値を提供するために多品種少量生産を志向するものであって、不連続に変化する市場と対話しながらニーズを探り当て、素早く製品を納品・市場投入することを眼目とする。
 “アジル(アジャイル)”は1990年代の米国産業界で一種の流行語となり、製造業以外にも波及した。(中略)1999年に提唱されたアジャイルソフトウェア開発にも影響を見ることができる。
(後略)

アジルマニュファクチャリングはマーケット重視の多品種少量生産のスタイル。
1990年代のアメリカの製造業で生まれたらしい。
その生産スタイルは、日本の製造業が編み出したリーン生産やコンカレント・エンジニアリング、BPR、系列などから生まれているらしい。

平鍋さんが最近話題にしているリーンソフトウェア開発も、トヨタ式生産スタイルに影響を受けている。
日本の製造業が編み出したフレキシブルな生産手法が何故、日本のソフトウェア産業へ影響を与えられなかったのか、不思議だ。

| | コメント (0) | トラックバック (0)

Oracleの周辺に漂うきなぐさい雰囲気

OracleがSunを買収したことに伴い、オープンソースとの摩擦が立て続けに起きている。
記事をまとめてみた。

【元ネタ】
オラクル対オープンソース: 今度はHudson - karasuyamatenguの日記

Life is beautiful: Oracleの「Android訴訟」についてひと言

OracleがGoogleを訴えた理由、「AndroidはJavaと競合する」はどういう意味だろうか - Publickey

OracleからOpenOffice.orgが独立し、「The Document Foundation」を設立 - ITmedia News

MySQLを手に入れたOracle――IBMとMicrosoftに与える影響は? - ITmedia News

JRuby開発者Charles NutterがOracleの対Google訴訟を考察、「心配するな。特許は大した内容じゃないし、OracleにはAndroidを潰す動機はない」: ITジャーナリスト星暁雄の"情報論"ノート

OracleがAndroidを巡り、Googleに訴訟を仕掛けたのはつい最近のこと。
HudsonでもOracleは異議申し立てしているらしい。
又、OpenOfficeもOracleから独立しているらしい。

他にもOracleと関係するオープンソースのツール群であるMySQLやJRubyも、Oracleの動向に神経質にならざるを得ないだろう。
オープンソースと著作権に関する内容は、ソフトウェア技術者にとって、自身の成果物をどのようにコミュニティの人達と共有しながら、自身の立場を保護していくか、という問題を孕んでいる。

この動向も注目していく。

| | コメント (0) | トラックバック (0)

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