無料ブログはココログ

« 2010年12月 | トップページ | 2011年2月 »

[#TiDD] yaXP:もう一つのXP@XP祭り関西2011LT

XP祭り関西に参加しました。今回も盛りだくさんで楽しめました。今回はライトニングトークスにも初挑戦しました。XP祭り関西はあくまでも「お祭り」楽しむことが一番ということで、真面目な内容を織り込みながらもネタに徹しました。iPhoneの表示が遅いということを考慮に入れなかった、観客につられた笑ってしまった、という未熟さにより時間が足りませんでした。

ということで、すこし恥ずかしいですが、ここに公開します。お楽しみください。

[#TiDD] 第43回 SEA関西プロセス分科会「チケット駆動開発による 現場力の向上」

第43回 SEA関西プロセス分科会で講演しました。ご参加いただいた皆様、ありがとうございました。

あきぴーさんのTestLinkのお話やてふかんの皆さんの「ふりかえり」のお話もあり、充実した内容で楽しめました。

下記のスライドには、45分間でお話しできなかったおまけスライドも入れておきました。いつか、きちんとまとめてお話ししてみたいと思います。

[#TiDD] チケット駆動開発はプロセスを軽量化する

かつてアジャイルと言えばXPだったころ、従来法とアジャイルの比較として

「ヘビーウェイトプロセスとライトウェイトプロセス」

という表現が用いられることがありました。ヘビーというのは機敏でないという意味もあると思いますが、管理プロセスが肥大したという意味合いもあったと思います。

1.なぜ管理プロセスは肥大しやすいか

従来法の重さは、肥大化した管理プロセスにあります。メトリクスに関してもバシリ先生のGQMでは計測はトップダウンで行われるべきであり、

計測のの目標があって、その目標を遂行するために尺度が定義され、計測が行われなければならない
* 楠本 真二, “ソフトウェアメトリクスの研究動向,” 第4回エンピリカルソフトウェア工学研究会, 2004. (PDF)

とされています。不要なメトリクスを集めるべきではありませんし、不要な管理ルールも冗長なだけです。しかし、「アジャイルと規律」でベーム先生が

「熟練していない人たちは、安全策をとってすべてを取り入れ」(P.189)

と書かれているように、検討されたメトリクスや品質プロセスの多くは、取り入れられることはあっても、削られることはなくプロセスが肥大化してしまいます。もちろん、大切なノウハウは実践されるべきですが、存在しないリスクの確認を手間暇かけることに多くの労力を割くことはないでしょう。

2.肥大化した管理プロセスの問題

このように管理プロセスの肥大化により、以下の3つの問題が生じます。

a) 管理作業の集中によるプロジェクトが鈍重になる

TSPガイドブック:リーダー編にアイアコッカの「ボスのスピードがチームのスピード」(p9)という言葉が出ていますが、管理作業が増えるとリーダーがボトルネックになり、プロジェクトの機敏さがなくなります。

b) 管理データの増加

プロセスが肥大化すると、管理のためのドキュメントも増えます。同じようなデータが、ミーティングや報告経路の種類によって様々な観点で利用されます。これらのドキュメントを作成するには、データ収集、集計、報告作業が大変です。

c) 情報の遅延

肥大化した管理プロセスの多くは、紙のコピーやExcelファイルのメール送信で配られます。データの収集、集計、さらにそれをもとにした報告書をリーダーが作成するまで報告されません。また、報告は組織構造を下から上に順次行われることから、時間的にずれ他データが報告されます。そこで、

  • 新しい問題が報告されていない
  • 最新の状況が確認できない
  • 解決した問題の確認や検討をしてしまう

といった問題が生じてしまいます。もちろん報告にはスナップショットという面もあるのですが、最新の状況が確認できるに越したことはありません。

3.チケット駆動開発はプロセスを軽量化する

チケット駆動開発は以下のようにプロセスを軽量化します。

a) 管理作業の分散

進捗管理や障害管理では、口頭あるいはメールでのデータ収集、エクセルによる集計・グラフ化、ファイルの共有あるいはメールによる報告といった管理作業が必要です。BTSを用いるチケット駆動開発では、データ収集は担当者がチケットを更新し、自動でガントチャートが更新され、マイルストーンやサブタスクの進捗を自動で集計します。つまり、管理作業は純粋に管理することだけになるのです(チケット更新の作業のうち一部を管理者だけの権限にしておくことも可能です)。

b) データの一元管理

同じようなデータがあり、収集、集計、報告が大変というのは、データが正規化されていないからです。"One fact in one place"のルールに従って基本的なデータを一元管理し、推移従属なデータをその都度作成すれば、このような負担はなくなります。BTSは必要な情報は抽出条件を指定して一覧で参照できますし、よく使うレポートはあらかじめ定義しておけば、定型業務の報告として利用できます。

c) リアルタイム

データは報告書と独立して、その時点のデータをリアルタイムに参照できます。報告書が順次送られる場合でも、新しい問題を含めた最新情報が参照できますので、すでに解決したことを知らず状況を確認したり、解決策を検討することもないでしょう。

4.従来法にもアジャイルにも

このようにチケット駆動開発は管理プロセスを軽量化します。これは管理プロセスを削減するのではなく、現状の管理プロセスそのままで、作業の分散、一元化、自動化によって効率化するものです。これはチケット駆動開発の大きな特徴です。

今回は触れませんでしたが、アジャイル開発においてもチケット駆動開発は有効です。アジャイルは人間重視の観点から、タスクカードのようなアナログ情報が用いられています。タスクカードはとても人間的で、進捗の見える化やスコープの変更などに有効です。しかし、電子化されていないことから、タスクカードの保存が困難なほか、構成管理ツールとの連携による履歴の検索も容易でなく、タスクボードという物理的な制約を受けます。チケット駆動開発はタスクカードをチケットに電子化するので、これらの問題を軽減してくれるでしょう。

最近のアジャイル2次ブームで、既存の管理とアジャイル開発を整合させる動きがあるようです。そのようなときにも、管理プロセスを肥大させない方法として、チケット駆動開発はきっと役立つでしょう。

Dynabook N510/06AB 使用感。2週目

やっぱりメモリ8GBは偉大です。ぱっと開いて、ぱっと起動、ぱっと操作という、どこかの待機電力の大きいレコーダの様に快適です:-)。

当初、ギラギラして嫌いだったデザインはどうも滑り止めのようです。電車の中で膝の上(のカバンの上)において、キーボードを操作すると手の甲がギラギラデザインにフィットしてこれまでのパソコンにない安心感を感じます。

WiMAXはgooでの測定値よりも早く感じます。色々なサイトと時間の組み合わせをすると、自宅(アンテナ3本)で6723 Kbps出ていました。以前の測定値の2倍以上です。

そんな感じなので、自宅でもプリンターを使わないかぎりWiMAXのままにしています。WiFiとWiMAXが排他利用なので、ちょっとした操作ですが面倒なのですよね。

自宅で使っているとSSHのセッションが時々切れています。WiMAXはそのようなものなのかもしれません。昔のADSLよりは早いですから、満足しています。

外での利用も快適です。阪急電車はもちろんのこと、大阪モノレールも駅周辺は大丈夫です。大阪モノレールは東西に広がる住宅街を南北にまたがるようなルートなので、住宅の境界では電波が弱くなるようです。速度も遅いのでSSHで繋ぎっ放しにはできないようです。

慣れもあるでしょうけど、総合して買った時よりも満足感が増しています。自分にとって満足できるものがないときは、ここだけは譲れないというものにこだわって買うべきなのでしょうね。私の場合はWiMAXとメモリ8GBだったので、それにこだわってよかったです。

[#TiDD] 「チケット駆動開発」を分解する

言葉は分解することで、その理解がより深まるはずです。「チケット駆動開発」を分解してみました。

チケット

  • 必ずしも完成していない
  • 期限・優先順位つき
  • 分解された作業群
  • 構成管理と連携
  • 履歴

駆動

  • 個人&チームの2階層プロセス
  • 日次、イテレーション、リリースのリズム
  • ツールによる自動化
  • ワークフロー

開発

  • 見える化
  • 優先順位とマイルストーンによるスコープ変更
  • コミュニケーション
  • 抜けのない作業の実施

このような結果に加えているなら、

  • 管理の視点からではなく、開発だけでもなく、開発・管理・コミュニケーションの基盤でもある

と思いました。いかがでしょう?

[#TiDD] リスクベースでリリースする

リスクベースに考える際のリリース順序を考えます。私はこんな風に考えているというだけで、必ずしもこれだけではないと思います。もっと良い観点があれば、お教えください。

基本的には、問題が発生しても取り返しのつくような構造となるように、つまり後になって問題が発覚してプロジェクトが爆発することがないように考えます。後続の作業があるということは、残業などによって作業する余地(バッファ)があるということになるからです。また、早めにリリースすると、他のテストの実施によって信頼性が向上することも考慮します。具体的には、下記のように分類しています。

リリースの順序
リリースを早める後回しにする
必須機能 低重要度(中止可能な)機能
基盤 周辺
基本機能 拡張機能
外部システムと結合 独立機能
初めて利用する環境関係 実績のある環境関係
更新系 参照系
お金・個人情報 サマリ

もちろん、システムの実装やテストの都合もありますし、メンバーの能力を見定めたり、メンバーの負荷の平準化なども考慮すべきでしょう。

また、ここに挙げた順序を避けるために、外部との独立性を高められるようにアーキテクチャを考えるというのもあるでしょう。プロジェクトの計画は、色々なことを考えて戦略を練る作業なのです。

 

以上、ご参考まで

[#TiDD] 従来法の限界とアジャイルの利点、そしてチケット駆動開発

ウォーターフォール(WF)とアジャイルの議論はいつもかみ合いません。それは、モデルで考えるなら、1回だけか複数回かで複数回の方が変化に強いに決まっているものの、WFは決められた仕様どおりのものを作ることが目的で、アジャイルは変化に対応しながら顧客の要求に合ったものを作ることが目的だからです。目指すものが違うので、それを比較しても、どちらが良いということはありません(もちろん、あるプロジェクトにとって、どちらが向いているかはあります)。

ここでは、WFではなく「従来法」と呼ぶプロセスを考えてみます。具体的には、開発標準として、上流から下流までの段階的な工程に分かれ、各工程での作業、成果物、品質向上策のほか、メトリクスの基準が決められている。初めての技術に関しては、プロトタイピングが実施されて技術的な検証がされる。また、上流では少人数で、下流工程では増員されるようなプロセスを考えます。

このようなプロセスをWFであるとして、感情的な批判がされていることもあるようです。ここでは、感情的な議論ではなく、従来法の限界からアジャイルの利点を述べます。

「限界」としているのは、従来法がこれまではうまくいったが、近年増えつつある開発には向いていないと考えているからです。だからと言って、アジャイルが銀の弾丸とも考えていません。アジャイルが素晴らしいのは、従来法の限界を超えることができる要素を含んでいる点であり、その利点がアジャイルそのものではないからです。

そして最後に、ここで述べるアジャイルの利点について、チケット駆動開発がどのように支援するかを説明します。

1.統計・標準の限界

 従来型開発においては、多くの企業でプロジェクトのメトリクス(数値データ)が収集され、プロジェクトの管理に用いられています。また、大手の成果を参考に基準を決めている企業もあるでしょう。どこも同じような開発をしている場合には、これは非常に有効な方法でした。

1.1 母集団の変化

  しかし、近年のように多種多様な業務で、開発・運用環境の変化が激しく、実装の自由度も高くなってきた今日では、統計に基づくが故に生じる問題もあります。

  • 母集団が異なると参考にならない
  • 一定の比率(危険率)で、想定外にうまくいくプロジェクトが存在するはずだが、その芽をつぶす

 統計では一定の想定外が前提となっています。従来のように対象となる母集団が大きいならば、それほど問題ではありませんでした。しかし、最近のように開発対象が多岐にわたる場合は、そのプロジェクトが同じ母集団のものか、想定外のパターンになるかどうかが大きな問題となります。

1.2 技術の周回遅れ

 統計情報や経験に基づく開発標準は落ちついた技術でないと、利用できません。これは、数値基準だけでなく、チェックリストなども同じです。

  • 経験のない新しい開発には標準がなく、絶対値で管理するには一定のデータが必要
  • プロジェクト終了までは、その成否の結果が得られない
  • 収集したデータの利用は、早くても周回遅れ(次のプロジェクトから)になる

 このように、統計を利用した開発標準による管理そのものにも、変化に対応ができないという問題があります。

  陳腐化した技術でなく、新しい技術を取り入れて言うには、データを収集したプロジェクトの中で、ノウハウを蓄積し、改善していく仕組みが必要になります。

2.リスク

 リスクは古くから「発生確率×影響」とされています。近年、開発環境が整備されることで、工数に対して多くの機能が実装されるようになりました。しかし、環境リスクはその影響は大きい場合が多くこれまでと異なるアプローチが必要です。

2.1 リスクの変化

  かつてのソフトウェア開発では、ある言語の標準ライブラリさえ熟知していればプロでした。UNIXアプリなら8分冊のマニュアルのうち、ライブラリの3章1冊で十分、システムコールの2章を知っていれば専門家です。シェルスクリプトが少し書ければ重宝されていました。そのころは外部で作られたソフトウェアが少なかったので、発生する問題の多くは、開発したプログラムに原因がありました。「発生確率×影響」で考えるとほどほどの大きさがありましたが、テスト工数にそのリスク分を上乗せしておけば、システムが動かないということはありませんでした。

  しかし、最近のソフトウェア開発、たとえばオープン系のソフトウェアなら、言語はもちろん、DB、ORマッパー、フレームワーク、などの足回りのほか、HTML、JavaScript、さらにはブラウザ固有の問題とハッキング方法まで知る必要があり、それぞれのバージョン固有の問題まで知っておく必要があります。そこで発生する問題は、開発したプログラムのほか、外部のソフトウェアの組み合わせやバージョン固有の問題などもあります。

 このように外部のソフトウェアで発生する問題は、発生頻度は低いですが影響範囲が広いので、影響度の大きいリスクです。「発生確率×影響」で考えるとそれほど大きくないリスクですので、あらかじめ担保しておける工数も少なくなります。しかし、このリスクが現実の問題となると、システムのアーキテクチャから見直す必要が生じることもあり、システムの実現そのものが危ぶまれる可能性のあるリスクです。

2.2 プロトタイプの限界

 以上のようにリスクの傾向が変化してきている中で、従来法では対応が困難になってきました。プロジェクトの後半になってから、システムの根幹を揺るがす問題が起きてしまうと、とりかえしがつかないからです。

 従来はこのような問題を解決するには、プロトタイピングが有効でした。単純な問題であれば、プロトタイプで発見することが可能ですが、特殊な組み合わせによる問題などでは、簡単なプロトタイプによる技術検証ではフォローしきれないこともあり、早くから本格的な開発を行うことが、重要になります。

3.配員・体制

  従来法のプロジェクトでは、上流でしっかりと文書化とその検証を行い、実装時に単価の安いプログラマで一気に作ってしまうという方法がとられてきました。この方法は、経験者の多くいる環境上で、文書化が比較的容易なシステムの場合には有効でした。

  しかし、経験者の少ない新しい環境や、上流で詳細な仕様を決定・凍結できない場合には多くの問題が出てきます。このような場合、メンバーは言われたことだけでなく、関連する技術や仕様を理解して、お互いに協力する必要があるからです。

  このように横のコミュニケーションが必要な場合、段階的に増員することは知識の習得やコミュニケーションに悪影響を当てます。段階的に増員すると、先に入った人が教える側になり、後から入った人が教わる側になりがちだからです。

3.1 知識の取得

  後から入った人は先に入った人に追いつくために、教育を受け、学習しなければなりません。人から教えられながら学ぶと、自分の担当の機能が中心になり、周辺の機能に関しては教わるだけで、あまり考えなくなりがちです。ドキュメントをもう少し広く読むだけでわかることなのに、問題が起きると「そんなの聞いていません」といった言葉が出てくるのは、プロジェクトの一員として問題を解決していく意識よりも、担当の作業をこなす意識の方が強いからでしょう。

3.2 コミュニケーション

 また、コミュニケーションにも上下関係が発生して、教える人と教わる人の関係では問題の発見が遅れてしまうことがあります。遠慮を知らない新人の方が問題を鋭く指摘したり、中堅メンバーが後になって「おかしいと思っていました」などと発言するのは、横同士のコミュニケーションがうまくいっていないからでしょう。

3.3 ドキュメント

 さらに、ドキュメントや設計が冗長になりがちです。経験の少ないメンバーにもわかるような言葉の定義は必須ですし、定義フィルを見るか変換をすれば十分な情報に関しても、後から参加するメンバーに説明するためにだけに書かれることもあるでしょう。場合よってはプログラムを書いた方が早いだろうというほど詳細なドキュメントが書かれることもあるでしょう。もちろん、ドキュメント化によってレビューが容易になるという良さはあるのですが、修正が入った際に変更しなければいけないドキュメントが増えてしまい、保守されないドキュメントを増やす一因になります。

 また、詳細化を考慮したきれいな設計を心がけるので、冗長な設計になることもあるでしょう。後から機能を増やすと契約上も問題になるので、詳細設計で十分に検討すれば不要かもしれないと思いつつも、ひとまず入れておいて詳細は下流工程で決定するということは、段階的詳細化に起因して発生しうる話です。

4.アジャイルの隠された利点

 これまで見てきた従来法の問題は、従来法の枠組みを超えてアジャイル開発の要素を加えることで解決できます。具体的には以下の点です。

4.1 繰り返しによるプロジェクト内の改善

アジャイル開発の特徴である繰り返し開発では、イテレーションという単位で開発が繰り返されます。1つのプロジェクトの中に複数のミニプロジェクトが含まれていることになり、イテレーションごとに振り返りを行うことで、プロセスが改善します。

この改善はプロジェクト固有の改善です。前のイテレーションで計測したメトリクスがあったとしても、それを参考にするだけで、以降のイテレーションの標準となる数値を定めることは少ないでしょう(大規模組織においての基準策定は、プロジェクトとは別の活動としてあり得ます)。

反面、プロジェクト内の改善活動として、メトリクスの相対的な利用が可能です。たとえば複雑度の高い部分や不具合の多い部分に対して、レビューやテストを強化することで、より信頼性を高めることができるでしょう。

4.2 実装優先+優先順位によるリスク低減

 古くからプロトタイプにはいくつかの危険があると言われていました。それは、特定の機能の実現可能性や性能の確認を目的としたプロトタイプであったはずが、すでに完成したかのように錯覚してしまうからです。もちろん開発者はわかっていたはずなのですが、まず管理者が錯覚し、それに引きずられるように開発者までもが安易な計画を立ててしまうと言われていました。上述のようにプロトタイプによる検証をしたはずが、後工程になって問題が発覚することにも、このような錯覚が影響しているでしょう。

アジャイルにおいては、常に本物の実装です。このような錯覚や、後工程での問題発覚の可能性も減らせます。ただし、それにはふさわしい優先順位の決定が必要です。リスクの基本式である「発生確率×影響」は、

「発生確率×影響(t)」

となっていて、影響は時刻tによって変化するものです(より正確に言うと実装の順番によって変化する) 。より影響が小さくなるように実装の順番、すなわち、イテレーションを構成するならば、プロジェクト全体のリスクを低減することが可能です。

4.3 同一体制での開発+見える化による情報共有

アジャイル開発においても、突発的なメンバーの増減はあり得るでしょう。しかし、YAGNIの原則がありますので、プロジェクトの途中での増員を前提としてドキュメントや設計を行うことはあまりないでしょう。

同じメンバーが継続して作業することは、教育やコミュニケーションに有効です。もちろんそれまでの経験によって、環境や業務の知識は異なります。しかし、同時期に参加することによって、その関係を上下でなく、「仲間」にします。上下関係のある学習では、教える側が考慮しない限り、教えられる側はプロジェクト全体を考えるようはなかなかできません。しかし、仲間であれば、お互いに助け合い、ふと疑問に思うことも情報交換するようになるでしょう。

また、「タスクボード」や「かんばん」と呼ばれる仕組みもプロジェクト全体に目を向けさせます。これらはプロジェクト全体の作業状況を示しますので、自分の作業だけでなくプロジェクト全体に目を向けるようになり、コミュニケーションのベースとなります。

ここに挙げたアジャイルの要素を従来開発に加えた開発をアジャイルと呼ぶべきか、呼ばないべきかは意見の分かれるところかもしれません。個人的にはどちらでもよいと思っています。プロジェクトの目標は、問題なくシステムが開発されることであり、それがなんと呼ばれようと関係ありません。

5.チケット駆動開発のソリューション

チケット駆動開発は、(1)BTSのチケットでタスクを管理する、(2)チケットのにコミットは許さない、(3)ツールと連携する、といった中心となるルールだけではアジャイル開発といえません。しかし、上述した従来法の問題を解決するには効果的です。

5.1 繰り返し+データ蓄積

チケット駆動開発で利用するBTSには、「マイルストーン」あるいは「バージョン」という作業の期限を示す機能があり、各イテレーションの期限として設定・参照できます。また、チケット一覧の抽出条件としても利用できます。プロジェクトの全貌を示し、今注目すべきチケットを示すことで、繰り返し開発を支援します。

また、チケットはプロジェクトのデータの宝庫です。チケットに示されたタスクの内容だけでなく、実施に当たっての議論も蓄積されますので、イテレーションごとにプロジェクトを振り返る際の情報として活用できます。

5.2 チケットの優先順位

リスクを考慮した実装順序をチケットの実施時期や優先順位として示すことができます。時系列に示されるガントチャートで参照可能なほか、優先順位をチケット一覧のソートキーとして用いることで、計画や作業の優先順位を容易に確認できます。

5.3 コミュニケーション+履歴

チケットはタスクボードであり、かんばんです。チケットの一覧やガントチャートによってプロジェクトの全貌を知り、コミュニケーションをとることができます。また、ソースの更新はチケットと関連付けられ、チケットに関する議論は、コメントとして履歴が残りますので、過去の作業に対しての情報共有もはかれます。

チケットの更新は、メールやRSS、eclipseのプラグインで知ることができます。日々の作用としてBTSで検索するまでもなく、瞬時にプロジェクトの状況を共有することができます。

5.4 チケット駆動開発に含まれないもの

チケット駆動開発の基本には、アジャイル開発にあった実装優先や同一体制は入っていません。しかし、従来法の問題を解決するならば、これらを取り入れた開発をする必要があります。

6.まとめ

従来法による開発で問題が生じるようなプロジェクトが、年々増えています。これはWFに問題があるのでありません。過去には大勢を占めていたプロジェクトを実践する目的で、WFをベースに発展させたものが従来法であり、近年のプロジェクトに対応できていないからです。

プロジェクトによっては従来法がふさわしい場合もあるでしょうし、ふさわしくない場合もあるでしょう。開発プロセスはプロジェクトに合わせて決めなければなりません。それには、プロジェクトの課題を知り、その解決法を考えなければなりません。

ここでの議論は、従来法かアジャイルの「どちらか」ではなく、従来法とアジャイルを参考に近年増えてきたプロジェクトを「どのように」実践するかという議論です。ソフトウェア開発に銀の弾丸はないと言われますが、それはアジャイル開発においても同じです。ソフトウェアをうまく開発する唯一の方法は「考える」ことです。ここに書いた内容が、みなさんの「考える」ことに少しでも役立てていただければ幸いです。

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


[#TiDD] SEA関西プロセス分科会でチケット駆動開発の講演をします

きたる1月15日(土)にSEA関西プロセス分科会でチケット駆動開発の講演をします。

今回の分科会では、「Redmineによるタスクマネジメント実践技法」共著者である小川さん、てふかんの角口さん、新美さん、渡辺さんも講演されますので、ぜひお越しください。

なお、参加費には書籍「Redmineによるタスクマネジメント実践技法」付のセット価格も用意されていますので、まだお買い上げいただいていない方は、この機会に是非お求めください。

(書籍付の申し込みは1月8日までですので、お早めにお申し込みください)

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

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

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

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

主催:ソフトウェア技術者協会 関西支部 プロセス分科会
   http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/

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

会場:大阪市立大学文化交流センター
   〒530-0001 大阪市北区梅田1-2-2-600
   大阪駅前第2ビル6階 ホール
   Tel 06-6344-5425 / Fax 06-6344-5524
   http://www.osaka-cu.ac.jp/faculties/bunko/index.html
   周辺略地図
   http://www.osaka-cu.ac.jp/faculties/bunko/access.html

内容:
 前回の第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名

申込方法:
   以下のペ‐ジからお申し込みの受付を行っております
http://www-ise4.ist.osaka-u.ac.jp/K-SPIN/application.html
 ### 01/13(木)までにお申し込みください(書籍付は1/8まで) ###

   今回は書籍「Redmineによるタスクマネジメント実践技法」
   付きのセット価格を用意しました(定価3,444円)。
   セット価格をご希望の方は、申込みフォームの最後の「分科
   会のテーマに関するご要望などをご自由にどうぞ」の欄に
   「Redmine書籍セット希望」とご記入下さい

 ★注意★
   出版社との手続きの都合上、書籍セットでの参加申込みは
   1/8(土)までにお願い致します。
   また、欠席で当日お渡しできなかった場合は後日発送させて
   いただきますが、送料はご負担願います。

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

---------------------
世話人:(株)SRA関西事業部 小林 修

阪急京都線でWiMAXする

阪急京都線で移動しながらWiMAXしました。使用したのは先日買ったdynabook N510/06AB です。

WiMAXは通常、登録と契約が分かれているのですが、月末まで日数がなかったので自宅のプロバイダーである@niftyの1日払いにしました。

テストしたのは阪急京都線の桂~梅田間です。アンテナでいうと大体3本(強い)~5本(非常に)で2.1~4.7Mbps(住宅の少ないところが遅く大きな駅周辺が速いようでした)。総じて3Mbpsは出ているようで、時々0本まで瞬間的に下がっていました。自宅がアンテナ3本(強い)で2.95Mbpsですから、日中に走っている電車の中でこれぐらい出ていれば優秀でしょう(測定はgooスピードテス。具体的な数値はTwitter参照)。

SSHのセッションが切れるかも試してみましたが、片道で数回切れました。主に以下のような傾向があるようです。

  • 住宅のまばらなところで電波が弱くなる
  • 速度が低下すると電波のない時間が長くなって切れる
  • アンテナが0本でもある程度速度が出ているとうまくハンドオーバーできる

アンテナの本数が減るのは住宅がまばらなところですが、淀川の鉄橋の南側などではスピードが出ていて、セッションが維持されました。淡路の先の浄水場のところなどは、梅田行きはスピードが出ていて切れませんでしたが、帰りの河原町行きは夕方でスピードが出ていないためか、ハンドオーバーしている間に切れているようでした。

SSHのセッションの切れやすいところを並べると、

必ず切れる

  • 大山崎の京都寄り(天王山)
  • 長岡天神の大阪寄り(円明寺の手前)

スピード次第

  • 淡路の大阪寄り(浄水場)
  • 正雀の車庫
  • 南茨木の大阪寄り
  • 富田駅(通過時)
  • 高槻市の大阪寄り
  • 高槻市の京都寄り(京大農場)

このうち、不思議なのは長岡京市の大阪寄りです。住宅もそれなりにあるのですが、アンテナの位置の問題か、管理上の問題か、IPアドレスの再取得までしていました(それ以外は単純にセッションが切れるだけですぐに復旧しました)。

このテストのようにSSHを移動中に使うのがそもそも変で、Webの参照なら失敗しても再読み込みをすれば良いだけです。40分程度に再読み込みがせいぜい数回程度の再読み込みです。これだけ使えれば十分でしょう。これまで、アステル、DDI、b-mobile、WILCOM、イーモバイル、au、とPCで使ってきましたが、速度を考慮すると一番使えるように思います。

ところで、WiMAXはそのスピードよりもPCに内蔵できる点に注目しています。これまでだと、通信装置+ケーブル、直刺し、無線などいろいろありましたが、PC以外にも持ち歩かなければならず、直刺し以外では充電も必要でした。WiMAX内蔵のPCだったら、座って開いてすぐ使えます。ようやく、こんな時代が来たのですね。

予想以上に優秀だったので、1日契約ではなく年間契約を検討しています。私の場合は@niftyなので月額3500円程度、月に6回以上使えば元が取れるはずです。

Dynabook N510/06AB はこだわりを感じて予想以上にGood!

いまどきMacBook Air(MBA)じゃないのか、と思いつつも、2年近く使ったネットブックIdePad s9eから東芝ネットノートdynabook N510/06ABに乗り換えました。XT互換機のJ-3100SS以来のダイナブックです。値段で我慢した面もあったのですが、久しぶりのdynabookはそれなりにこだわりの感じられる良いノートPCでした。

購入理由

iPhoneのソフト開発にも興味があったのですが、

  • WiMAX搭載
  • メモリー最大8GB
  • 重量1.5kg以下
  • Core i3
  • 通販で8万円ちょっと(大阪ボンバー)、メモリー8GBにしても9万円ちょっと
  • MS Office Personal 2010付(PowerPointは古いものを使っています)
  • 11.6型ワイド液晶(1,366×768ドット)

ということで、重さを我慢すればそれなりに使えそうなので、これにしました。モバイラーとしてはMBAや通販で9万円を切っているLetsnote J9シリーズも魅力的なのですが、通信機器を別に持つのが面倒くさかったり、年齢的にも11インチは必須ということでdynabook N510にしました。

この値段なら、一番良いMBA13インチ+ソフト+アダプタを買ったと思えば、Mac miniあるいはMBAの最小構成も買えますしね。どうしてもiPhoneのソフトを作りたくなったらそうします。

使用感

WiMAX については別記事を書くつもりですが、簡単に書くと、それなりに早く、何かを刺したり、充電しておく必要がないのは快適です。

増設用のメモリーが届くまで2GBで使っていましたが、常に引っかかるような感じがあり、タッチパッドの操作感もいまいちでした。64bit版Windows7をメモリー2GBかつビデオメモリー共有で使うのは厳しいのかもしれませんね。8GBにすると別のマシンのように快適になりました(PC 1'sで買いましたが、送料を考えると同じものの2枚セット W3N1333Q-4Gのほうが安かったようです)。メモリアクセスもデュアルチャネルになり、Windows エクスペリエンス インデックスは3.3ですがメモリは5.1になりました。

Win7score

MBAほどではないですが予想外に薄いです。そのためかずっしりと重く感じますが、電源も小さく通信機器やVGAアダプタが不要なので、それを考えると我慢できる範囲です。

外装のデザインはなかなか渋くてよいのですが、周辺部のつくりがプラモデルっぽいです。また、ピカピカしていて指紋と傷が気になります。個人的にキーボード周りがキラキラしているのは、あまり好みではないですが、1日使って慣れました。

あと、キーボードにはこだわりがない人ですが、キーピッチが広いのはストレスがなくて使いやすいです。ファンもついていますが、Ideapadが「シュー」とうるさかったのに対し、dynabookは「フー」と低い音で、夜でもあまり気にならない程度です。

東芝さんのこだわり

長年ノートPCを作っている東芝さんだけあって、いくつかのこだわりが感じられました。

(1) タッチパッドの下のイボイボ

これは抜群です。普段、電車の中でノートパソコンを操作するときは、左手を液晶と本体のつなぎ目(ヒンジ)、あるいは右手をタッチパッドのあたりに置いて、落とさないようにしながらキー入力したり、タッチパッドを操作しています。このDynabookは本体が薄いですが、タッチパッドの下にイボイボがあり、電車の中でも滑りにくく安心です。

(2) メモリー・HDDのふた

メモリーを増設する際に蓋を開けようとしたのですが、簡単に開きませんでした。これは、バッテリーを取らないといけないようになっていて、通電したまま増設することがないように考えられているんでしょうね。よくできています。

(3) ハードディスク保護(TOSHIBA HDD protection)

いまどき当たり前のような機能ですが、けっこう敏感なようです。デフォルトでダイアログが出てきます。すぐに表示を止めましたが、こたつに膝が当たった程度で反応しているので安心です。(^_^;

(4) アプリケーションの再インストール

さすが日本のメーカーです。いろいろなユーティリティがついてきます。ちょっと鬱陶しいので不要と思われるものから抜いていくつもりです。アプリケーションを個別に再インストールできるツールがついているので、安心して消せます。

トラブル

ウイルスバスターの90日間使用権がついてくるので設定したところ、firefoxで何かするたびに「応答しません」となって困りました。アドオン->拡張機能でMcAfee SiteAdviserを無効化して、まともになりました。

感想

WiMAXとメモリー8GB、タッチパッド下のイボイボは良かったです。また、薄くてふたをした時のデザインも気に入っています。反面、重さとキラキラするデザインがぎりぎりですが、これも慣れでしょう。値段を考えると、十分にお買い得だったと思っています。

« 2010年12月 | トップページ | 2011年2月 »