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

2013年7月

2013/07/31

ソフトウェア再利用の概念

ソフトウェア再利用の概念について整理してみた。

【参考】
ソフトウェア工学 第13回 保守と再利用

再利用の罠

SOAのための再利用エンジニアリング

【0】ソフトウェア再利用の動機

ソフトウェア開発では、過去のソフト資産や新しいフレームワークなどを流用することで、開発コストをどれだけ削減できるか、再利用することでどの程度までの品質を担保できるか、の見極めが設計工程で重要になる。

再利用できるライブラリ、部品、アーキテクチャがあれば、それらを流用することで、開発工数をカットできる。
しかも、既に本番運用されていれば、稼働実績もあるから、品質も担保されている。
開発中に発生するリスクも、稼働実績から得られたノウハウを流用して対処することもできる。

だが、そのままソフトウェア再利用できるとは限らない。
むしろ、再利用したい新しい技術を取り入れた開発案件では、技術にメンバーが慣れるリスク、技術そのものの適用範囲や実現可能性のリスクがとても大きい。
やってみないと分からないのだ。

だから、アーキテクチャ設計、方式設計では、ソフトウェア再利用のために、事前にプロトタイプを作って機能の実現可能性や性能について事前検証する時が多い。

ソフトウェア開発の案件は、今までと同じような技術を使う時はあまりない。
毎年のようにハードウェアの性能が上がって、以前とは違う環境になるし、次から次へと新しいバズワードと共に新しい技術が現れる。
それらをどこまで自分のものとして取り入れられるか?

【1】ホワイトボックス再利用、ブラックボックス再利用

ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。
よくある例は、GUIコンポーネントや数値演算ライブラリなど。
利点は、変更の必要がないので、公開されたインターフェイス(API)をうまく使えば、開発の効率化に大きく貢献できる。
.NET FrameworkやEJBもその事例に入るだろう。
.NETライブラリは、C#だけでなく、VBでもそのAPIを参照することができる。
つまり、特定の言語に依存しない場合もある。

ホワイトボックス再利用とは、再利用資産を要求に合わせて部分的に変更して使用する。
よくある例は、オブジェクト指向設計によるフレームワークなど。
フレームワークは、コンポーネントやライブラリと同様に、はっきり定義されたAPIを持ち、実装の詳細は隠蔽している特徴を持つ。
しかし、コンポーネントやライブラリでは、呼び出し側のプログラムがライブラリの制御構造を修正できないのに対し、フレームワークは、呼び出し側のプログラム側で機能を継承して追加したり変更できたりする。
つまり、フレームワークは制御の反転構造を持つ。
古くはStruts、今ならRailsがその事例に当たるだろう。

但し、フレームワークは特定の言語に依存するのが普通。
新しい言語ほど、便利な機能が多いのが普通。

【2】再利用する対象の概念はおおまかに3つある。
コンポーネント、フレームワーク、プロダクトラインの3つ。

コンポーネント指向開発では、ソフトウェアを機能単位にコンポーネントとして分解し、それらを組み合わせてソフトウェアを構築する。
プロダクトライン開発では、ドメイン単位に再利用する部品(コア資産)を作る開発とそれら部品を組み合わせた開発から成る。
イメージ的には、コンポーネントの方がドメインよりも粒度は小さい。
ドメインは、ビジネスオブジェクトないし組込みシステムの機能単位の部品に近い。

コンポーネント指向開発やプロダクトライン開発は、再利用する部品を作るのが大変だ。
コンポーネントのように、汎用的なライブラリを作るレベルならば、仕様の詳細を決めれば作るだけ。
でも、プロダクトライン開発のように、再利用できるビジネスオブジェクトないし機能の部品を作るには、かなりの手間がかかる。
コア資産を開発している間に、ビジネス状況が急変したり、開発の基盤を支えるプログラミング言語やライブラリがVerUpして追いつけなくなったりする。

フレームワーク開発は、アプリケーションの土台となる機能(DBアクセス、画面遷移、Webセッション管理など)はフレームワークが担当し、機能は一から実装するスタイル。
多分、普通の開発案件はこのパターンが多い。

フレームワークを使う場合は、技術リスクの把握が一番大事。
プロトタイプを作ってアーキテクチャや性能を事前検証したり、開発者のためにコーディングルールを決めたり、フレームワークを使うための開発環境を整備したり、色々手間がかかる。

SI独自のフレームワークを使っているなら、開発ノウハウは新規加入した開発者に展開できないから、習得コストもかかる。
最初のうちは、コードレビューして、開発者の習熟度をチェックすることも必要だ。

【3】開発コストの観点は2つある。

一つは、再利用するための開発コストの観点。
再利用できるような部品を作るには、開発者が理解しやすく、使用する状況で便利だと思えるAPIを用意しなければならない。
部品の粒度が大きいほど、実装するソースも大きくなるから、開発コストも大きくなる。

プロダクトライン>フレームワーク>コンポーネント>ソースコードの順に開発コストが小さくなる。

2つ目は、再利用ライブラリを流用して開発するコストの観点。
再利用できるライブラリや部品があれば、それらを組み合わせるだけですぐに製品が作れる。
一から作らなくていいから、プロダクトライン<フレームワーク<コンポーネント<ソースコードの順に開発コストが大きくなる。

この2つの開発コストのバランスから、再利用できる部品を作るべきか、計画するのが重要になってくる。

【4】でも、ソフトウェア再利用は元が取れるのか?

SI独自のフレームワークで開発する案件はどこも大変だった記憶がある。
時代の流れに沿っていけないのだ。

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

プロダクトライン開発は、その理想が実際の現場と合っていない時が多い。
再利用できる移植性という品質を重視しながら、運用後の機能追加や修正のしやすさも保証するという保守性の品質を両立するのはとても難しい。

ソフトウェア部品化の幻想: プログラマの思索

他にもSOAのようなサービス単位に流用できる部品を作るという開発スタイルも提唱されていたが、結局の所、うまくいっていないのが実情だろう。
部品の粒度が大きくなるほど、保守の工数は増大する。
粒度の大きい部品、例えば、ビジネスオブジェクトやドメインごとの部品は、成功例があまりないと言えるだろう。

むしろ、粒度の小さい部品、例えば、コンポーネントやフレームワークのレベルでは、再利用できる部品作りにさほど工数がかからないし、品質もそこそこ保証しやすい。
初めて使う開発者も、APIの使い方さえ覚えるだけなので、習得コストも小さい。
フレームワークでは、CoCのようにプログラミングの書き方そのものを開発者に強制して、その設計思想に染めることもできる。

しかし、その再利用できるコンポーネントやフレームワークさえも、その寿命は短い。
業務システムがユーザ企業が生きている限り使われるスパンに比べて、再利用できるアーキテクチャそのものが不安定なのだ。
再利用の幻想には囚われ過ぎない方がいいと思う。

| | コメント (0)

2013/07/28

実践反復型ソフトウェア開発を読む part3~再現可能なビルド管理

実践 反復型ソフトウェア開発」は何度読み直しても参考になる。
今まで暗黙的に行なってきた作業に、きちんとした名前が付与されることで、その作業の意味を捉え直すことができるからだ。
多分、ソフトウェア工学の中でも開発プロセスに興味がある人にとっては必須の本だろうと思う。

実践 反復型ソフトウェア開発」の内容は、構成管理・ビルド管理・障害管理・テスト管理の4つの分野に大きく分けることができる。
第4章「構成管理とブランチの戦略」の部分は以前まとめたので、今回は、ビルド管理についてメモ書き。

【参考】
実践反復型ソフトウェア開発を読む part1~ブランチの戦略: プログラマの思索

実践反復型ソフトウェア開発を読む part2~マージの戦略: プログラマの思索

【1】ビルドの再現可能性

ビルドの重要な性質は、再現性または再現可能性、反復可能性。
つまり、いつ誰がビルドしても、同じようなモジュールを作れること。

WF型開発では、プロセスという工程の品質を再現させることに注力する。
そのために、属人化を廃し、作業手順を標準化する方向に走って、ソフトウェア開発からクリエイティビティをなくした。

でも、ソフトウェア開発における再現性の対象は、ビルド管理であるべき。
プログラミングや設計ではなく、ソースがあれば、いつ誰でも同じモジュールを作れることの方が大切だ。

【2】ビルドの種類

ビルドには幾つかの種類がある。
まずは、ビルドタイミングや品質に関する観点。

(1)CIビルド、継続的な統合ビルド
 必要に応じて、1日に数回ビルドして、自動テスト(オートメーション)も走らせる。
 ビルドエラーが発生すれば、すぐに障害票を起票して、即修正する。

(2)デイリービルド、日次ビルド
 1日1回、普通は夜間にビルドする。
 すべてのオートメーションを実行する。

(3)ウイークリービルド、週次ビルド
 週1回ビルドする。
 テストチームにリリース可能な製品を渡す。
 開発チームは、Testableな品質を保証するのが前提。
 品質OKなら、テストチームは受入テストを実施する。

 ビルドをテストチームにリリースする前に、テストチームによるテストが実施できる品質かどうか判定するテスト、つまり、スモークテスト(またはBVT)を実施するのが普通。
 スモークテストは主要な受入テストケースによるテストが多いだろう。

(4)マイルストーンビルド
 ユーザにリリース可能な製品を渡す。

次は、ビルドの手順に関する観点。

(1)フルビルド、完全ビルド
 全ソースをビルドする。
 普通は、各種コンポーネントを組み合わせて最終モジュールをビルドするので、全てのコンポーネントもビルドするとなると、ビルド時間がとてもかかるのが普通。

(2)インクリメンタルビルド、部分ビルド
 前回のビルド時から修正されたソースとそれに依存するファイルのみをビルドする。
 ビルド時間を短縮できる。
 但し、ビルドブレークが多発して、ビルドの再現性が落ちる場合、フルビルドに戻す。

(3)クリーンビルド、リビルド
 前回のビルドで生成された中間ファイルを全て削除して、ビルドする。
 ant cleanなどの処理に相当する。
 クリーン後にインクリメンタルビルドするなら、フルビルドと同じ。

 リビルドは、ビルドを再実行すること。
 VisualStudioの機能では、ビルドのメニューを選択するとインクリメンタルビルド、リビルドのメニューを使うとフルビルドのように使い分けることができるようだ。

ビルドの準備と管理

Visual Studio でのプロジェクトとソリューションのビルドおよびクリーン

(4)並行ビルド、分散ビルド
 マルチスレッド化したビルド処理が並行ビルド。
 複数のマシンで複数のビルドを並行して走らせるのが分散ビルド。
 いずれも、ビルド時間を劇的に短縮できるのが利点。

 並行ビルドは、AntならばParallelタスクを使うと良いらしい。

 Jenkinsでは、分散ビルドをマスター・スレーブ方式で実現している。
 
第3回 Hudsonによるチーム間の連携:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

Jenkinsによる継続的インテグレーションのススメ(3) ~Jenkinsで分散ビルド~

【3】ビルドブレークとソフトウェアあんどん、XFD

ビルドブレークとは、不衛生なソースがコミットされてビルドが壊れる事象。
ビルドブレークが起きるということは、出荷可能な最終成果物が作れなくなったと言う意味であり、早急に直さなくてはならない。
でも、いつもすぐに分かればよいが、すぐに検知できない時もある。

トヨタ生産方式のように、自動車の製造ラインが止まった時に使われるパトランプ(あんどん)を光らせて、すぐに検知できるような仕組みが良い。
ソフトウェア開発に適用した場合、ソフトウェアあんどんやXFDの例がある。
実際にXFDを使うと、結構目立ってしまい、他の開発者の作業を中断させてしまうので、全員で直すだけでなく、再現しないように気を付けるようになるようだ。

第4回 プラグインを使う:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

あるいは、ビルドエラーを検知したら、メールで全員に配信するだけでなく、JenkinsからRedmineへ検知メールを発行して、チケット自動登録する仕組みを作っても良いだろう。

メールでRedmineチケットを登録する機能の可能性: プログラマの思索

【4】ビルド手順

ビルドには、複数の構成があり、構成ごとにビルド手順が違う。
例えば、JavaのWebシステムであっても、JDKのバージョンやRDBのバージョン、アプリケーションWebサーバのバージョンという構成内容によって、ビルド方法は微妙に変わる。
だから、複数のバージョンの組合せによるビルドモジュールを作り、それらの回帰テストが必要になってくる。
Windowsアプリならば、OSのバージョンやVisualStudioのバージョンによって、複数の組み合わせによるビルドが発生するため、ビルドや回帰テストがより一層大変になるはずだ。

Jenkinsでは、マルチ構成プロジェクトという機能を使えば、JDKやOSのバージョンの組み合わせの設定を作れば、同じビルド手順でビルドしてテストできる。
この方法を使えば、特定のOSやJDKのバージョンに依存するバグを見つけ出すこともできる。

第5回 高度なプロジェクトタイプ:Hudsonを使ったアジャイルな開発入門|gihyo.jp … 技術評論社

【5】継続的インテグレーション(CI)の種類

継続的インテグレーションの意義とその効果については以前書いた。

継続的インテグレーションを再考: プログラマの思索

継続的インテグレーションにも幾つかの種類がある。

(1)コミットビルド、軽量ビルド
 継続的にビルドする。
 普通はコミットするたびにビルドする。

(2)2次ビルド、重量ビルド
 時間がかかるビルド。
 フルビルドないしインクリメンタルビルド。

(3)段階的ビルド
 コミットビルドが通過したら2次ビルドを実行する。

2012/07/29 Jenkins ユーザ・カンファレンス 2012 東京 satta-4 : 複雑な多段階ビルドに対処する: 事例紹介 #juc2012 #juc2012_satta - Togetter

CIでは、ビルドの頻度があまりにも多いので、ビルド時間を短縮するために、並行ビルドや分散ビルドの仕掛けが必須だろう。
Jenkinsの分散ビルドの機能を使いこなすのは、CIの運用で必須になってくるだろう。

また、並行ビルドや分散ビルドの仕組みは、ビルド処理がバッチのジョブ処理に似ている性質を意味している。
つまり、複数のビルド処理を時系列につなげることで、ジョブフロー図として扱うことができる。

Jenkinsをジョブ管理ツールとして使うアイデア: プログラマの思索

Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

Jenkinsの場合、Build Pipeline Pluginを使うと良いだろう。

Build Pipeline Plugin - Jenkins - Jenkins Wiki

kakakikikekeのブログ: 【Jenkins】Build Pipeline Pluginを使ってみた

Jenkinsでビルド・パイプラインを構築する - プログラマになりたい

この発想は、ビルドの時刻表を列車の時刻表に見立てて、ビルドを定期的かつ定刻にリリースする運用につながる。
これを「実践 反復型ソフトウェア開発」では、リリーストレインという概念で説明している。
つまり、ジョブフロー図の運用と同じだ。

【6】バディビルドの自動化

CIでビルドエラーのフィードバックが早く検知できるのは良いことだが、本来は、コミット前に教えてほしいものだ。
そのために、コミット前にサンドボックス上で事前にビルドするバディビルドが必要になる。
丁度、バディビルドがコミットビルドに相当するだろう。

最近はGitのような優れたバージョン管理が普及したので、サブブランチ上で事前にバディビルドするのがトレンドだろう。
つまり、ホットフィックスブランチやフィーチャブランチ、トピックブランチ上で修正してビルドが通過するまで開発者が責任を持つように開発プロセスを回す。

実際のビルド処理の流れとしては、ビルドマシンが下記を自動実行するイメージ。
下記のフローの利点は、マージ作業そのものも全てが自動化されるので、大変楽になること。

開発者がサブブランチへコミット
→ビルドマシンがコミットを検知して、バディビルドと自動テストを実施
→ビルドもテストもOKなら、ビルドマシンがサブブランチから親ブランチへポートしてコミットする

JiraとBamboo、Bitbucketを持つAttlasian製品では、ブランチ上に開発者がコミットしたら、後はビルドマシンが自動実行してくれるようだ。

GreenHopper を使用した Bamboo と Bitbucket の自動化

Atlassian製品による「No Ticket, No fork!」: プログラマの思索

Jenkinsで上記の処理を実現したい場合、コミットフック処理のスクリプト内で、サブブランチのバディビルドと自動テストを実施し、結果OKなら親ブランチへポートする処理を書けばよいだろう。

この発想は、チケット単位にトピックブランチを作って作業し、最終コミット時にtrunkへマージしてチケットをCloseする運用につながる。
つまり、チケット駆動開発ならば「No Ticket, No Fork」の運用ルールに相当するだろう。

チケット無しでフォークやプルリクエストは許さないというチケット駆動の新しい運用方法: プログラマの思索

GitHubならば、全てが自動化されているわけではないが、PullRequestという処理が上記の処理に似ている。

PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み: プログラマの思索

【7】ビルドの品質

ビルドモジュールを区別するために、MD5チェックサムを計算する運用もある。
Jenkinsならば、ファイル指紋の機能に相当するだろう。

第3回 Hudsonによるチーム間の連携:Hudsonを使ったアジャイルな開発入門~ファイル指紋|gihyo.jp … 技術評論社

Fingerprint - 日本語 - Jenkins Wiki

ファイル指紋を使う状況は例えば、ビルドモジュールを手作業で本番環境にデプロイする場合、持参したモジュールが本当に正しいモジュールなのかチェックする時に使える。

CIビルドは頻繁に実施するので、どのビルドがテストに耐えうるのか、分かりづらい。
そこで、CIビルドの中でより多くのテストにパスしたビルドを昇進させて色付けするやり方が、ビルドのプロモーション。
つまり、テストチームが受入テストを実施できる品質のビルドにラベルを付ける。
Jenkinsならば、Promoted Builds Pluginを使って、上流ビルド・下流ビルドを作る運用があるだろう。

第4回 プラグインを使う:Hudsonを使ったアジャイルな開発入門~ビルドプロモーション|gihyo.jp … 技術評論社

Promoted Builds Plugin - Jenkins - Jenkins Wiki

Promoted Builds Plugin - おこらない日記

| | コメント (0)

2013/07/25

RedmineでOpenID連携

RedmineでOAuthやSAMLとID連携する機能についてメモ。

【発端となる問題点】
中小企業のユーザ管理 | Posox

Redmine・Gitlab・Jenkins のログインパスワードの管理が大変になったので OAuth 化した - すえひろがりっっっっ!

複数のWebシステムを使っていると、IDとパスワードの管理が大変になってくる。
OAuthプロパイダまたはSAMLプロバイダの認証サーバーを作り、一つのIDで複数のWebシステムにログインできるようになると、開発者にとっては楽だ。

とは言え、社外に認証プロバイダを作るのはセキュリティ上危険なので、社内の中で作る方法もあるだろう。
Redmineでは、下記のプラグインや作成方法が既に試されている。

【OAuth】
suer/redmine_oauth_provider ・ GitHub

mallowlabs/redmine-oauth-plugin ・ GitHub

Virtualmaster/redmine-oauth-provider ・ GitHub

twinslash/redmine_omniauth_google ・ GitHub

【SAML】
SAML Authentication - Plugins - Redmine

cvaldemar/redmine_saml_auth ・ GitHub

OAuthの場合は、認証プロバイダ経由でログインするかどうか、確認処理を踏むのでワンクッションある。
SAMLの場合は、一度ログインして、認証情報をひもづければ、ログイン認証を気にしなくていい。

この辺りのノウハウもまとめていく。

| | コメント (0)

2013/07/21

社会人の勉強方法にもWF型開発や適応型開発のアナロジーを活かせるか

社会人の勉強について、考えたことをメモ書き。

【1】社会人になると仕事中心の生活になるが、勉強が必要になる場合もある。
よくある例は、資格を取らないと管理職になれない、とか、資格を取得しないと担当した業務(例:証券などの金融)で仕事できない、とか、担当された業務で専門知識が必要なために自主的に勉強せざるを得ない、など。
社会人の勉強方法は学生の勉強方法とは全く違うと最近分かってきた。

【2】仕事はチームプレー、勉強は個人プレー

普通の社会人は、営業マンであれ事務員であれプログラマであれ、チームで仕事する。
チームで仕事するからには、不得意な分野は他の専門家に任せる。
得意な分野で自分の能力を活かして、チームのアウトプットに役立てる。

だから、顔の広い人が仕事が出来る人になる。
顔の広い人は、仕事を得意な人に任せるのが上手いから。
仕事が進まない人には、ヘルプできる人をつけるように依頼して、チームでカバーする。

でも勉強は個人プレー。
勉強のアウトプットが大学受験だったり、資格試験だったりするので、試験会場では自分一人だけで勝負しなければならない。
苦手分野でも自分一人でやらなければならない。
勉強の出来る人は、苦手分野があまりないか、あったとしても致命的でないように、広い知識を持っている。
不得意分野を他人に振ることができにないのだ。

でも、勉強だけに向いている人は、チームプレーが苦手な人もいるように思える。
だから、勉強だけできる個人プレーだけの人はビジネスには向かないかもしれない。
実際、学校の成績が良くなくても、チームで仕事すると生き生きする人は世の中にとても多い。

自分の専門能力をアピールして働くのか、ファシリテーションやマネジメントの能力をアピールして働くのか。

【3】竹中さんによる「竹中式マトリクス勉強法」における勉強マトリクスの4象限

竹中平蔵さんによる「竹中式マトリクス勉強法」には、勉強マトリクスの4象限の解説がある。
1つの軸は、天井のある勉強と、天井のない勉強。
天井のある勉強は、大学受験や資格試験など、合格すればそれで終わり。
天井のない勉強は、経営能力を身につける、とか、新しいプログラミング言語を毎年勉強する、とか、際限のない勉強。

もう一つの軸は、人生を戦うための武器としての勉強、とか、人間力を鍛えるための勉強。
ITや金融知識などの専門知識を身に付けて、世界やライバルに打ち勝つための勉強。
あるいは、古典や音楽、芸術などの教養を身につける勉強。

すると、縦:武器としての勉強+人間力を鍛える勉強、横:天井がある勉強+天井がない勉強でマトリクス形式にすると、

A:記憶勉強、
B:仕事勉強、
C:趣味勉強、
D:人生勉強
の4象限になる。

学生の勉強は、A:記憶勉強が全て。
でも、社会人の勉強は、Aだけではない。
働きながら、大学院に入り直してMBAを取得したり、資格勉強にチャレンジする社会人は、B:仕事勉強が多い。
つまり、ある程度ビジネス経験を積んだ後に、もう一度知識を身に付けるべく勉強し始める。
例えば、MBAで勉強することで、再現性や恒常性の高い成果を出すために過去の経営メソッドを身に付けることもできる。
各種の資格を取得することで、経験で得られた内容に、専門知識を追加して幅広く理解することもできる。

特に、社会人の勉強は、業務経験がなければ取得できない資格も多い。
PMPや技術士は経験年数を必要とするし、高度情報処理技術者試験(SA・PM・ST・AU)はだれでも受験できるがそれなりのITシステムの設計や提案の経験がなければ、そう簡単に取得できないだろう。

だが、業界で10年以上の経験があるからと言って、例えば資格に簡単に受かるわけではない。
仕事の経験知は特有の業務に特化しているために、得られた知識はとても狭い。
むしろ、資格勉強によって、周辺の専門知識をかなり暗記しなければ身につかない。

【4】学生と社会人の勉強方法で違うのは、勉強に費やせる工数が大きく違うこと。
学生ならば、1週間のうち5日、先生から指導を受けて、言われた通り勉強するのが普通。
勉強方法は、予習→講義→復習という受け身の勉強スタイル。
1ヶ月のうち20人日は勉強に費やせるから、1ヶ月のうち約70%の工数を勉強にアサインできる。

しかし、社会人になれば、平日は仕事があり、休日は疲れているだろうから、1ヶ月のうち1日分、専門講師による講義を直接受けれるぐらいがせいぜいだろう。
独学でも、1ヶ月で勉強できる工数はおそらく50時間も満たないだろう。
つまり、1ヶ月に1日~1週間ぐらいの工数しか勉強に費やせない。
しかも、ほとんどの勉強時間が独学になるので、自力で勉強していく能力も必要になる。

逆に言えば、社会人になると、専門講師による指導回数を増やしても、さほど身につかない。
独学で勉強する工数の方が多いから、自力で勉強するメソッドを自分なりに開発しなければならない。

だから、社会人の勉強スタイルは、ソフトウェア開発における適応型開発に近くなる。
自分に合った勉強方法を身につけるために、1週間または1ヶ月のスプリント単位に試して、その結果を評価して、そのノウハウを身に付けて(適応して)、次のスプリントに生かしていく。

【5】現在の日本における資格勉強はWF型開発っぽい手法が有効な場面が多い

自分で体験してみて、現在の日本における資格勉強はWF型開発っぽい手法が有効な場面が多いのかな、と思う。
と言うのも、ほとんどの試験は、紙と鉛筆による筆記試験が多い。
つまり、アナログの勉強スタイルのため、一度書いた答案を書き直すのは時間が掛かるし、面倒だ。
特に、記述試験や論文試験では、100~3000文字も記述しなければならないので、一度書き始めたら、途中で書き直すのは非常に困難だ。

だから、例えば、論文試験では、事前に目次を作るだけでなく、ストーリー展開やレイアウト設定まで事前に決めた後に、書き始めるのが普通。
途中で目次を入れ替えるには、一度書いた文章を全部消してしまう必要があり、工数がかかりすぎるからだ。

もし、エディタやWordが使えるならば、とりあえず書き始めなら、途中で目次を入れ替えたりして、いくらでも書き直しができる。
IT技術を使えるならば、試行錯誤しながら記述できるのに、ほとんどの資格試験がアナログ形式のために、WF型開発のように事前の計画作りを必要以上に重視せざるを得ない。

しかも、今の社会人は業務がほとんどIT化されてしまっているので、シャーペンやボールペンを使った仕事は殆ど無いはず。
だから、意識的に、シャーペンで大量に書く練習や、電卓を叩く練習など、アナログ形式の勉強に慣れる必要がある。

教育の現場がいまだにチョークと黒板によるアナログの講義形式が主流である理由の一つは、大学受験などの試験がアナログ形式のために、事前の準備を重視せざるを得ないからではないか。
IT技術がもっと教育現場に普及すれば、何度でもやり直しが効く勉強方法も生まれるだろうから、アジャイル開発のような勉強方法も生まれるのではないか。

とは言え、ITツールが効果的に使える場面もある。
例えば、英語の勉強はウォーターフォール型開発よりも適応型開発が向いている: プログラマの思索に書いたように、英語学習はもっと経験重視の適応型開発っぽい勉強方法が向いている。
英語学習では、iPodやiPhoneからヒヤリングで聞いたり、ボイスメモで音読した内容を録音して再度ヒヤリングするなどのやり方がとても有効だ。

牛尾さんが提唱される「サウンドファーストの原則」「ダイレクト理解の原則」「コンテキスト理解の原則」などを実践してみると、経験重視の典型的な適応型開発に思える。

論文試験でも、3000文字超の文章を音読してボイスメモで録音して、いつでもヒアリングできるようにしておくと効果があるらしい。
目による脳へのインプットと、耳からの脳へのインプットは違うので有効みたい。

【6】とは言え、単純に暗記だけすれば勉強は終わりではない。
社交場で教養が必要になるとか、色んな理由で、C:趣味勉強やD:人生勉強も必要になってくる。

コミュニティ活動してきて勉強になったことは、プレゼンの技術だ。
日本の学校では、プレゼンの場がほとんどないので、人前で自分の考えや意見を話す練習をしたことがない。
パワポを作って話す練習は、社会人と言えども、顧客相手に話す場合くらいしか使わないのではないか?

でも、コミュニティでは、自分から率先して講演することができる。
たとえ失敗しても、有志が集まるコミュニティでは、色んな人からフィードバックがもらえる。

PowerPointを使った古い人の講演よりも、KeyNoteを使ってジョブズのプレゼンのように話すタイプも多くなってきた。
プレゼンテーションZen」のような優れた本もあるし、周囲の発表を見れば、自然にプレゼンの技術も参考になる。
プレゼンは場数が必要かなあと思ったりする。

自分の知的好奇心を冷まさずに、色々勉強していくために、勉強方法を今後もまとめてみる。

| | コメント (0)

英語の勉強はウォーターフォール型開発よりも適応型開発が向いている

先日、牛尾さんの講演「ITエンジニアの ゼロから始める英語勉強法(ペラペラ実践編)」を聞いてきた。
勉強方法について考えたことをメモ。

アジャイルの流儀で英語に挑戦! - 第3回 英語が身につく五つの原則:ITpro

関西IT勉強宴会のブログです: 2013-07-01(月)第24回関西IT勉強宴会

理にかなったアジャイル王子の華麗なるペラペラ英会話メソッド - 第24回 関西IT勉強宴会 -: ソフトウェアさかば

【1】牛尾さんは「ITエンジニアの ゼロから始める英語勉強法 英語落ちこぼれでもペラペラになれる!」を出版された。
英語に疎いITエンジニアも、英語がペラペラになれる勉強方法について説明している、とのこと。
講演内容しか知らないけれど、分かりやすかった。

【2】英語の勉強方法の基本原則は、下記の5つがあるらしい。

(1)サウンドファーストの原則
 英語は耳から覚える。
 学校で教わったように、文法を覚えて、英単語を覚えて書いて暗記する方法では駄目。

 牛尾さんの話で面白かった点は、日本語は音域が狭いために、日本語の音域外の英語の発音は雑音として聞いてしまって、理解不能になってしまうこと。
 だから、英語の発音を大量に聞いて、雑音ではなく英語なのだ、と耳と脳みそに植えつけることが大事だ、と。
 日本人が学校で18年間も英語を勉強しながらほとんど使えない理由の一つは、音域が違うから、という科学的根拠があるわけだ。

(2)ダイレクト理解の原則
 日本語を使わず、英語で直接理解する英語脳にする。
 駄目な勉強方法は、せっかく聞いた英語音を日本語に変換して理解しようとすること。
 英語の意味と翻訳した日本語の意味は、ニュアンスがどうしても微妙に異なるので、理解の妨げになる。
 スライド資料には「消毒」という言葉があるが、それは、英語で聞いた言葉を日本語で理解した後、もう一度英語だけで理解するように変換すること。
 「消毒」という概念から、いかに英語脳で考えることが重要なのか、という主張が見え隠れする。

(3)スピーキング中心原則
 英語脳を鍛えるには、音読がおすすめ。
 日本人は完璧な英語をしゃべろうとして、なかなかしゃべろうとしないから上達しない。
 日本人は恥ずかしがり屋。
 韓国人や中国人、他の外国人は、間違っていても、とにかくしゃべろうとするから、上達していく。
 
 牛尾さんの話で面白かった点は、日本語の発音は子音よりも母音が強い特徴があるが、英語や他の言語では、子音と母音は同じくらいのバランスで発音する特徴がある、とのこと。
 実際、日本語で「か」~「わ」までの発音は母音の方が強い。
 英語では「K」「F」「R」などの子音だけで発音できる。
 だから、意識的に子音だけで話すように訓練すると良い、とのこと。

 アンチパターンは、英語のサウンド能力が低いのに、いきなり英語学校に行ってしまうこと。
 英語の発音練習だけに特化したCDやDVDもあるらしいので、サウンド能力やスピーキング能力が低い人はそこから勉強するのが確実、とのこと。
 
 最近なら、iPhoneやiPod touchのボイスメモを使って、音読した自分の発音を録音しておき、後から聞いて、発音をチェックするとよい、とのこと。
 日本人は最初は恥ずかしがって音読を記録しないけれど、一度慣れると、ボイスメモは英語勉強にとても効果的だ、と話されていた。
 ここ最近の英語の勉強では、iPhoneのようなスマフォやITツールを駆使することが重要であるように思える。

(4)コンテキスト理解の原則
 英語の聞き取りや音読に慣れてきたら、たくさんの英語に触れること。
 多読がおすすめ。
 アメリカでは、移民してきた外国人に、英語能力に合わせて、英単語の数(500語とか1000語)を絞った絵本やCDを貸し出しているらしい。
 自分の能力に合わせて、英単語の数を絞った本やCDで慣れた後に、映画やニュースなどの触れると良い、とのこと。

(5)選択と集中の原則
 社会人の場合、学生と違って時間がないので、勉強の工数をあまりかけずに英語脳を身につけたい。
 そのためには、英語脳の習得レベルがあると考えて、レベルに合わせた勉強方法を身につけると良い。
 
 例えば、英語が雑音として聞こえてしまうレベルでは、いきなり英会話学校に行っても習得しない。
 まずは英語の音域に慣れたり、子音だけで発音できるように、赤ちゃん英語から勉強する。
 
 でも、ある特定のレベルに向いた方法だけでは、すぐに壁にぶつかり、それ以上のレベルアップが出来ない。
 そう感じたら、次のレベルに合わせた英語の勉強方法に変える。
 例えば、音読してボイスメモに録音したり、1000語くらいの英語の絵本を読んだり、ステップアップさせる。
 
 そして何よりも、英語脳になるために、たくさんの英語の音をシャワーのように浴びるようにする。
 毎日15分は少な過ぎで、毎日2時間ぐらい聞いたほうが良い、とのこと。

 この辺りの話は、ソフトウェア開発における適応型開発を思い出させる。
 Scrumの検査と適応プロセスと同じだ。
 まずは自分で英語を聞き、発音練習してみて、自分の能力を評価して、自分の体になじませたら(英語脳に適応したら)、次のスプリントでは、別の勉強方法に変えて試す。
 自分自身に英語脳を適応させることで、少しずつ英語力が身についていく。

 学校の英語勉強法法は、今思い出すと、典型的なウォーターフォール型開発だ。
 なぜならば、SVOCのような文法や「too 形容詞 to 同士」のような英文法を覚えて、漢文をレ点を付けて日本語で覚えるように、ひたすら日本語脳で理解しようと計画的に勉強させられていたから。
 もっと経験重視の勉強方法が英語脳には向いている。

 牛尾さんの英語勉強方法は、コンサルタントらしく5つの原則というメソッドでうまくその概念を抽象化しており、そのメソッドを他人にも説明しやすい。
 僕も英語脳を鍛える時は、上記の方法を使おうと思う。

| | コメント (0)

2013/07/20

Redmineに入れたプラグイン一覧part4

Redmine 2.3.xに入れたプラグインについてメモ。

【元ネタ】
Redmine 2.3.0でのプラグイン動作メモ - torutkの日記

Redmineに入れたプラグイン一覧part3: プログラマの思索

Redmineに入れたプラグイン一覧part2: プログラマの思索

Redmineに入れたプラグイン一覧: プログラマの思索

Redmineはバージョンアップが激しいため、プラグインが最新版に対応しているか、チェックが必要。
Ver2.3.xで使えそうなプラグインを試してみた。

いずれも、システム管理者の設定>ロールと権限 でプラグイン機能をチェックしておく。

【1】suer/redmine_absolute_dates ・ GitHub

チケット画面の更新日時を絶対日付で表示してくれる。
動作OK。
DBマイグレーション不要。

【2】bshaffer/redmine-assets-plugin ・ GitHub

ファイルを添付したWikiやチケットをリストアップするプラグイン。
エビデンスや過去の調査ファイルを探す時に便利。
動作OK。
DBマイグレーション不要。

【3】peclik/clipboard_image_paste ・ GitHub

クリップボードにコピーされている画像を添付ファイルとしてチケットやWikiに貼るプラグイン・。
エビデンスを貼る時や、Wikiにリリース手順などを書く時に便利。
動作OK。
DBマイグレーション不要。

【4】zh/redmine_importer ・ GitHub

CSVでチケットを一括インポートするプラグイン。
GitHubの最新版のソースならば、新規登録も更新もOKのようだ。
また、チケットにカスタムフィールドを追加した場合にも対応しているようだ。
動作OK。
DBマイグレーション必要。

WBSから作業を一括登録したい時のように、マネージャにとっては必須のプラグイン。
インストール手順は下記の通り。

gem install fastercsv

rake redmine:plugins:migrate RAILS_ENV=production

【5】haru_iida / redmine_logs / Commits ? Bitbucket

Logs - Plugins - Redmine

Logs - r-labs

@haru_iidaさん作成プラグイン。
Redmineのlogをシステム管理者の管理画面から参照できる。
ログをちょっと見たい時に便利。
Bitbucketの最新版のソースならば、動作OK。
DBマイグレーション不要。

【6】daipresents/redmine_parking_lot_chart ・ GitHub

@daipresentsさんが作成したパーキングロットチャートの機能を追加するプラグイン。
対象バージョンをフィーチャ(リリースする機能)に対応付けた場合の進捗管理に有効。
動作OK。
DBマイグレーション必要。

但し、以前使っていた下記のプラグインがVer2.3.0では使えなくなっている。
誰かパッチを当ててくれないかな?

daipresents/redmine_version_burndown_charts ・ GitHub

daipresents/redmine_task_board ・ GitHub

daipresents/redmine_roadmaps ・ GitHub

【7】two-pack/redmine_xls_export ・ GitHub

チケット一覧からExcel出力するプラグイン。
Redmineから課題一覧、障害一覧の元ネタを出力するために必須のプラグイン。
@two_packさんがVer2.3.xにも対応してくれた。

但し、インストール手順に注意。

まず、Plugin views revisions - Plugins - Redmineをインストール

gem install spreadsheet

rake redmine:plugins:migrate RAILS_ENV=production
(DBマイグレーションは実行しなくてもよいみたい)

bundle exec rake redmine:plugins:process_version_change RAILS_ENV=production

最後のbundle exec rake~を実行しないと、チケット一覧画面のExcel出力のオプションリンクを押すとエラーになってしまう。

【8】Redmine インフォメーション プラグイン - Redmine Information - r-labs

@yoshidaさんが作成したRedmineのワークフローなどの情報を出力するプラグイン。
動作OK。
DBマイグレーション不要。
但し、ワークフローを表示するためにgraphvizのdotコマンドが必要なため、下記を実行しておく。

yum install -y graphviz graphviz-gd

トラッカー単位のワークフロー、管理者・開発者などのロールごとのワークフローを表示してくれるのは便利。
Redmineをソフトウェア開発のタスク管理へ拡張する場合、自分たちのプロジェクトでそもそもどれだけのワークフローが必要なのか、を考えておく必要があるから、このプラグインでチェックすると良いだろう。

左上の「情報」リンクから辿ると、ワークフロー表示画面が現れる。

Information_workflow_2

Information_role_report_2

Information_edit_2

【9】akiko_pusu / redmine_issue_templates / Commits ? Bitbucket

Issue Template - Plugins - Redmine

About en - Issue Template - r-labs

@akiko_pusuさん作成のチケットテンプレート・プラグイン。
動作OK。
DBマイグレーション必要。

gem install simplecov
gem install simplecov-rcov

rake redmine:plugins:migrate RAILS_ENV=production

チケットの書き方を標準化して統一したい時に役立つ。
障害、課題、議事録などをチケットに起票する場合、テンプレート化しておくと、若手メンバーもすぐに慣れてくれる。
ツールが分かりやすいチケットをサポートしてくれる。

使い方はちょっとコツがいる。

システム管理者が設定>「テンプレート」、ロールと権限>「チケットテンプレート」欄の項目にチェック。

各プロジェクト>設定>テンプレート で、プロジェクト毎にテンプレートに関するヘルプ情報を書いておく。

チケット一覧画面の右サイドバーにある「チケットテンプレート」から、「新規作成」リンク押下。

トラッカーごとにテンプレートを作成する。

「新しいチケット」リンク押下後、チケットテンプレートのプルダウンを選択すると、チケットの詳細にテンプレートが表示される。
「テンプレートについて」のリンクを押下すると、各プロジェクトの設定画面のテンプレートタブに書いた内容が表示される。


Issue_template_create_template_2

Issue_template_list_2

Issue_template_ticket_list_2

Issue_template_add_ticket_2

【10】WorkTime - Work Time - r-labs

kusu / redmine_work_time-0.2.13.zip Bitbucket

@tkusukawaさん作成の工数設定プラグイン。
動作OK。
DBマイグレーション必要。

WorkTimeプラグインを一度運用すると、特に現場リーダーにとって必要な機能になるようだ。
RedmineがVerUpしても、今後も使いたいプラグインの一つみたいだ。
理由は、工数設定が楽になるだけでなく、プロジェクト単位やメンバー単位、チケット単位の実績工数が見えやすいから。

Worktime_display_2

Worktime_monthly_2

【11】日本語環境で読みやすいRedmine用テーマ「farend basic」公開 | Redmine.JP Blog

@g_maedaさん作成のRedmineカスタムテーマ。
チケット一覧画面で、優先度ごとに赤色の濃淡で表示したり、期日が遅延したチケットはオレンジ色で表示してくれる機能を持つ。
チケット一覧画面でフィルタリングする時に、優先度の高いチケットや期限が遅れたチケットは要注目したいので、ありがたい。
配置するだけで、Redmine再起動も不要。

farend/redmine_theme_farend_fancy ・ GitHub

farend/redmine_theme_farend_basic ・ GitHub

【12】ameya86/redmine_maintenance ・ GitHub

Redmineでメンテナンス画面を表示するプラグインをインストール | けんさんのIT知識

Redmineに「メンテナンス中です」を表示して、システム管理者以外ログインできなくするプラグイン。
動作OK。
DBマイグレーション不要。

使い道としては、日中にRedmineにプラグインを入れたり、動作検証したりする時に、メンテナンスモードを表示して、メンバーに通知する場合があるだろう。
システム管理者ならば、配置しておきたいプラグインの一つ。

Maintenance_display_2

Maintenance_edit_2

【13】alexmonteiro/Redmine-Monitoring-Controlling ・ GitHub

Redmineでプロジェクトの活動をグラフなどを使って表現するプラグインをインストール | けんさんのIT知識

Redmineでプロジェクトの活動をグラフなどを使って表現するプラグイン。
動作OK。
DBマイグレーションはしないが、rakeコマンド実行は必要。

rake redmine:plugins:migrate RAILS_ENV=production

Chartsプラグインは2013/7現在、Ver2.3に対応していなかったので、このプラグインで代用できる。

Redmine_monitoring_controlling_3

Redmine_monitoring_controlling_time

Redmine_monitoring_controlling_huma

| | コメント (0)

2013/07/17

RedmineはPC・サーバ資産管理に適用できるか?

Redmineのチケット管理をPC・サーバ資産管理に適用するためのアイデアをメモ書き。

【事例1】
Twitter / akipii: 運用ルールが聞きたい RT @jun090309: PCのリース期限切れが近いものがあるので、誰が使ってるのか調べてください、みたいなメール来てた。新人にやらせてよ、というのもなんなので、前からやりたかったRedmineでの資源管理を個人的に導入。

Twitter / jun090309:@akipii 1/2: PC到着(リース会社の資産番号=A)→自社資産管理用番号を採番(=p)、Excelに記入。このExcelブックは、資産管理者しか持ってない、かつ、更新できない。
基本的にリース資産と人は1:1。席移動の際も、人と一緒に資産の場所も移動。

Twitter / jun090309:@akipii 2/2: 外注さんがいなくなると使用者不在となる。このとき連絡を忘れると、番号A、pが分かっていても、置き場所が分からなくなる。
また、任意の資産のリース期限は、資産管理者へ問い合わせないと分からない。

Twitter / akipii: @jun090309 (1)PC資産管理をチケット管理に置き換えた場合、ステータスはどのように割り当てていますか?PCのステータスが知りたいです。(2)PCが移動中で担当者が未決定の場合はどのように運用していますか? 移動中倉庫のようなイメージです。

Twitter / jun090309: @akipii とりあえずのものなのであまりきちんと使えていません。 ステータスは、使用中、使用者不在でも進行中、リース終了で完了です。 使用者不在の場合はadminを割り当てて、使用中の場合はその人を割り当て。 こうすれば仮にメール送信をしたくなった場合に困らないと思ったので。.

Twitter / akipii: @jun090309 突然の質問に丁寧なご回答ありがとうございました。使用者不在の場合はadminを割り当てる方法は参考になります。サーバ資産管理は@tkusukawaさんの運用例があります。チケット管理の適用方法はCRMや工数収集以外にもまとめたいと思ってます。

【事例2】

Excelのサーバ台帳をRedmineのチケット管理へ置き換えた運用事例:

(引用開始)
・1サーバ(ノード)=1チケットに起票
・資産情報から経緯や注意点等、雑多な情報を チケット本文や添付ファイルに書いて共有できる
・IPアドレス等おきまり情報はカスタムフィールド
 → カスタムクエリで一覧化できる
・サーバのステータスを明確化
 → 構築中、開発環境、本番稼働、停止中、廃棄(終了)
(引用終了)

【事例3】

redmineでナレッジを蓄積していく方法: プログラマの思索

(引用開始)
蔵書プラグイン:
Redmine - PluginEzlibrarian - Redmine

zouchaoqun/ezlibrarian - GitHub

CentOS 5.xにRedmineをインストールする

「書籍や物品管理機能を追加します。貸し出し管理、書籍(物品)レビュー記載が行えます。」とのこと。
@mkinside82さんによれば、ネットワーク機器などの資産管理や現物照合に、蔵書プラグインを利用するアイデアもあるようだ。

Twitter / @mkinside82: @akipii 実運用にまではいたっていませんが、デバイスの貸し借りを管理できる事に目を輝かせていました。色々な機器を持っている人なので、誰にいつ貸したのか分からなくなるそうです。全ての機器を登録しておけば、誰にいつ貸したのか管理できるはずです。

Twitter / @akipii: @mkinside82 なるほど。本の管理の場合、ISBN番号という唯一の識別子がありますが、機器の管理の場合、マウスとキーボードとモニタを合わせて一つの識別子にするなどやや複雑になります。資産管理(現物照合)にredmineを使うアイデアは面白いですね。
(引用終了)

但し、上記の蔵書プラグインは保守されていないため、最新のRedmineで動作するか未検証。

【事例4】
@sakaba37さんの社内業務におけるPC資産管理の事例もある。

(要約開始)
これまでの資産管理(AsIs):
・資産台帳から担当別にスプレッドシートを分割してメールで配布する
・分割して担当者にメール 返信を確認、無ければ督促メール
・返ってきたメールを資産台帳へマージ

チケットシステムの導入~Redmineを用いて業務改善:
・資産データは一括インポート
・必要な資産データはチケット一覧から出力して、確認する
・確認未完了のチケットは、緊急度を変更して督促メールを出す
(要約終了)

【1】PC・サーバ資産管理の問題点

PC資産管理やサーバ資産管理で面倒なのは、資産を管理する担当者がいなくなって、今どんなステータスなのかが分からなくなること。
貸し出したPCやライセンス管理はExcelの管理台帳で管理しているが、共有しにくかったり、過去の履歴が探しにくい。
SIならば協力会社の開発者の出入りが激しいため、PC資産管理は結構面倒。

サーバ資産管理では、サーバーの設定の履歴を追跡しにくい。
過去の障害のためにどんどんサーバーの設定ファイルが複雑になったり、証明書の有効期限など近い将来に必要なタスクは発生しているのに、忘れがちなこと、とか。
社内LANの変更やサーバーをデータセンターへ移動するなどの理由で、IPアドレスが変わったり、ネットワーク機器が変わったりすると、Excelの管理台帳だけでは結構不安になる。

また、PCやサーバーの担当者に、現在の状態を確認するために通知して、その結果を収集して集計する手間も大きい。
最近は情報セキュリティがうるさいために、定期的にPCやサーバーのセキュリティ設定を確認する必要があるが、それらの通知と収集・集計作業を社員全員に展開するのは、正直かなり面倒だ。

【2】Redmineのチケット管理による解決方法

PC資産やサーバ資産をチケット管理に置き換えることで、上記の問題点をいくつか解決することはできる。

一つ目は、PC or サーバ=1チケットと見なすこと。
チケットのタイトルに資産管理番号やサーバー名を書いたり、チケットの説明に詳細な内容を書けば良い。
IPアドレスや問合せベンダ名、サーバーの証明書の有効期限は、チケットのカスタムフィールドを使えばいい。
特に、PCの座席位置、サーバーが置かれている棚の場所などの情報は、チケットの属性に必ずセットしておく。

そうすれば、クエリを作って、チケットの属性でフィルタリングすれば、必要な情報をいくらでも集計して出力できる。
稼働中のPC台数やサーバ台数は、チケット集計機能でいつでも最新情報を取得できるので、減価償却の費用も計算しやすくなる。
また、コメントに作業履歴を残せば、過去の作業内容を検索できるので、障害対応もやりやすくなる。

2つ目は、PCやサーバーの状態をチケットのステータスに対応付けて、ワークフロー管理すること。
PC資産が使用中、サーバを新規構築中、PCやサーバを廃棄した、PCやサーバは倉庫で保管している、などの状態はチケットのステータスで保持すればいい。
チケットのステータスでフィルタリングすれば、例えば、未使用のPCやサーバの一覧を出力できる。

3つ目は、PCの使用者やサーバーの管理者をチケットの担当者に対応付けること。
定期的なセキュリティのチェックを行いたい時は、@sakaba37さんの運用事例のように、優先度を故意に下げてメールで通知する方法もある。
つまり、チケット変更によって担当者へメール通知する機能をうまく使っている。

4つ目は、サーバーの設定情報はSubversionなどの構成管理の配下に置き、RedmineのSCM連携を有効に使うこと。
httpd.confなどのサーバーの設定情報は、サーバー上でhttpd.conf.yyyyMMddなどのように日付指定のファイルとして残すやり方が多いが、その方法の弱点はどれが正しいファイルなのか、分かりにくくなることだ。
だから、SCMでそれらの設定ファイルも履歴管理すれば、チケットの画面に変更リビジョン一覧が残るので、後の運用保守で非常に役立つ。

あるいは、@tkusukawaさんのYggdrasilというRubyのツールを使って、サーバーの設定ファイルをより楽に管理する方法もある。

【3】Redmineを使った場合の今後の課題

PCやサーバ資産管理では、特有の問題もいくつかある。

一つ目は、PCやサーバーの場所を移動中の場合は、どのようなステータスや属性をチケットにセットするか?
あるいは、PCやサーバーが倉庫に保管されて、担当者が未決定の場合の運用はどうするか?

例えば、サーバーを社内からデータセンターへ持ち運んで移動する時に数日かかる場合、場所や担当者が未確定なので、中途半端な状態になる。

物流業務に例えると、倉庫からトラックや船や飛行機などに積み込んだ商品を別の倉庫へ数日かけて運送する場合、移動中倉庫という論理的な倉庫を格納する倉庫インスタンスを作る必要があると思う。
その場合、移動中倉庫では、普通は倉庫番号は9999のような雑コードないし一時的なコードを付与し、倉庫に入庫されたら新規コードを振り直すという運用を行うのが普通だ。

だから、@jun090309さんの話のように、保管中ないし移動中のPCやサーバの担当者は特別な管理者(例:admin)をアサインしておき、チケット集計機能を使っていつでもチェックできるようにしておく方が良いだろうと思う。

2つ目は、PCやサーバーの資産に枝番を付けて管理したい場合、どのように運用するか?

例えば、デスクトップPCには、マウスやキーボード、ディスプレイなどの資産も付属しており、それらも枝番を付けて資産管理しておきたい。
サーバーにも、ブリッジやルータ、UPS電源などの細かな付属機器も資産管理しておきたい。

しかし、チケット1個で管理しようとすると、チケット集計しにくかったり、更新履歴が分かりにくくなる。
できれば、付属品もチケットにしてしまいたい。

厳密に管理したいならば、子チケットないし関連チケットにPC付属品やサーバー付属機器を1つずつ登録して管理する方法もあるだろう。
あるいは、付属品というラベルで判断できるように、チケットのトラッカーないしチケットの属性に「付属品」の情報を設定する方法もあるだろう。
だが、チケットが増えすぎて逆に管理しにくくなる場合もあるかもしれない。

3つ目は、資産管理とタスク管理をチケットで管理しようとすると、混乱してしまいがちなこと。
セキュリティチェックや突発的な設置作業のようなタスクもチケットに登録して運用したいと思うのは普通だろう。
しかし、資産チケットのライフサイクルは基本は1年以上と長いけれど、タスクチケットの寿命は数日がせいぜいであり、そもそも資産チケットとタスクチケットは観点が異なる。

だから、資産チケットとタスクチケットはトラッカーや親子プロジェクトで区別するなどの運用が必要になるだろう。

【4】まとめ

実は、ITILの構成管理における構成アイテムは、まさにPCやサーバーの資産管理に相当する。
Redmineによるタスクマネジメント実践技法」でITILの運用もRedmineのチケット管理でカバーできると書いたように、PCやサーバーの資産管理もチケット管理で代用できるだろう。
資産管理にもチケット管理が有効ならば、PCやサーバーだけでなく、蔵書もそうだし、顧客情報という資産(つまりCRM)にも適用できるだろう。
色々考えてみる。

| | コメント (0)

2013/07/15

レガシーマイグレーションという名のシステム移行はデスマーチになりやすい

2005年の古い記事だが、レガシーマイグレーションという名のシステム移行に関して、概念が良くまとまっているのでメモ。

【元ネタ】
ITレポート(動向/解説) - 失敗しないレガシー・マイグレーション(1):ITpro

ITレポート(動向/解説) - 失敗しないレガシー・マイグレーション(2):ITpro

【1】レガシー・マイグレーションとは一言で言えば、旧式(レガシー)のシステムを新しいシステムに移行すること。
メインフレーム上のCobolシステムをオープン系のWebシステムに変えたい、VBとSQLServerのクラサバをJavaやPHPのWebシステムに変えたい、とか。
レガシーマイグレーションを実施したい理由は、いくつかあるだろう。
保守費用が高い割には、業務ロジックのカスタマイズが追いつかず、既存の業務に影響を与えていること。
あるいは、長年の手パッチによる修正によって、保守性や移植性の品質が劣化してしまい、機能追加や障害修正に手間取っていること。
あるいは、Cobol開発者が減ってしまい、システムを修正する要員を確保しにくくなっていること。

だから、一気にシステムを変えようとする。
いわゆるシステムリプレース案件は、受託システム開発では結構多い。
そして、たいていの案件はデスマーチになりやすい。
その理由は、下記に書いた。

システムのリプレース案件が最も危険な理由: プログラマの思索

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

ERPの落とし穴part5~システム移行という名のデスマーチ: プログラマの思索

【2】レガシーマイグレーションの手法は上記の記事によれば4つある。

(1)リビルド
ビジネスロジックのレベルからシステムを見直し、根本的にシステムを作り変える方式。
別名は、リエンジニアリング。
つまり、一からのシステム再構築と同じ。
よくある例は、ERPパッケージの新規導入。

利点は、新技術を使えるので、最適なシステムを構築できること。
弱点は、現行のシステムをスクラップ&ビルドするための時間やコストがかなりかかること。
デスマーチプロジェクトの典型的なパターン。

ERPの落とし穴part4~システム移行という名のデスマーチ: プログラマの思索

(2)リライト
ビジネスロジックはそのまま維持し、プログラムコードだけをJavaやC言語など新しい言語で書き直す方式。
いわゆるリプレース案件で結構多いパターン。

利点は、プログラム設計やデータ設計が明確になるので、機能追加・修正の効率化や品質向上を期待できる。
弱点は、新しいプログラミング言語で書き直すための時間やコストが結局かかること。

また、ユーザもバグありのシステムで業務を運用していたので、安易にバグを修正してしまうと、今までの業務フローが変わってしまうために、マニュアル修正やユーザ教育などの手間がかかる。
普通は、純粋なリライトはあまりなく、部分的に機能を追加したり、機能を修正したりするから、ユーザと要件を事前に詰めておかないと、リリース後に痛い目にあう。

システムのリプレース案件が最も危険な理由: プログラマの思索

(3)ラッピング
メインフレームなどの旧システムをオブジェクトと見なして外部システムからアクセスできるように、外部接続やWebサービス等のミドルウェアを用いてメインフレームを「ラップ」する方式。
いわゆるシステム間連携、外部接続を使って、旧システムと新システムとの間でデータのやり取りを実現する方式。

利点は、メインフレーム本体やメインフレーム上のアプリケーション、データベースがそのまま残るので、今までの資産(アプリケーション、データ)を流用できること。
弱点は、旧システムは残したままなので、運用コストの削減にはつながらないこと。

よくある例は、旧システムからの外部接続方式で、オンライン連携にするか、バッチ処理による非同期連携にするか、で大きく変わる。
RPCによるオンライン連携ならば、SOAPやRESTを使う。
バッチ連携なら、EDI方式が多いだろう。
例えば、FTPによるファイル連携、あるいは、HULFTによるファイル連携などの実現方法がある。

もし潤沢な予算があるならば、EAIツールのようなミドルウェアを使って、スクラッチ開発を回避する手法もある。

ERPの落とし穴part3~外部システム連携がプロジェクトのボトルネック: プログラマの思索

HULFTって何?: プログラマの思索

外部接続による実現方式は、実装コストも少なく、既存のシステムを連携するためにリビルドやリライトの方式に比べてリスクは少ないゆえに、予算が限られているプロジェクトではよく使われる。
しかし、外部接続に関するテストの工数は意外に増えやすいし、方式設計(アーキテクチャ設計)で漏れがあったり間違いがあると後で痛い目に合う。
だから、事前にアーキテクチャ設計の段階で、SOAP・EDI・EAIの各方式の利点と弱点を把握しておき、新旧システムと業務のフィットギャップ分析を十分にやっておくのが重要。

(4)リホスト
ハードウェアのみ移行して既存の業務アプリケーションを仮想的に動作させる方式。
例えば、Cobol資産はそのままでハードウェアのみ性能アップしたサーバーへ交換する、とか、JDK1.4のプログラムとOracle8iのデータベースは同じだが、性能が良いサーバーへ移行するときに、JDK7とOracle11gで動かすようにする、とか。

利点は、比較的短期間でシステムを移行できること。
弱点は、例えば、メインフレーム環境とオープン環境では、開発言語が同じでもソースコードは一般的にそのまま利用できるものではなく、環境に応じた修正が必要になること。
つまり、ソースコードは同じでもリコンパイルは必要になる。
だから、プログラム修正のコストはなくても、既存の機能が依然と同様に動くことを確認する回帰テストの工数はかかる。
この回帰テストを実施してみると、実はミドルウェア(JDK、Oracleなど)のバージョンアップのためにプログラム修正が必要になることが分かったりする。

また、メインフレームのような旧システムのアプリケーション資産をそのまま移行してしまうため、既存資産の悪い部分(スパゲティ状態)が残ってしまうこと。
保守性や移植性が悪いままシステムを引き継ぐため、運用保守のコストは改善されない可能性がある。

【3】レガシーマイグレーションやシステムリプレース、システム移行などの開発案件は、ユーザ企業にとって新しい価値を生み出すようなものではなく、既存の業務を維持するためのものと言える。
ビジネス上は全く価値がないのと同じだ。
だから、失敗しなくて当然と思われているが、実際のプロジェクトではデスマーチになりやすい。

その根本原因は、回帰テストを保証する開発インフラがそろっていないからだと思う。
リビルド・リライト・ラッピング・リホストのいずれの方式にしても、既存の機能がデグレしていないことを保証する回帰テストの工数は結構大きい。

しかし、古いシステムほどドキュメントが欠落したり紛失したりするから、本来の仕様を探ることが難しい。
過去のテスト仕様書すらない場合もある。
だから、バグありの現行システムと移行後の新システムの機能を単純に差分比較してテストする場合が多い。
このような単純なテストは手作業が多く、工数もかかるし、仕様の不明点もたくさん出やすい。

回帰テストを自動化できるインフラがあれば、テスト工数を減らせるだけでなく、テスト結果を何度も再現できるから、システムの品質も良くなる。
開発者もプログラム修正に自信を持って行える。

XPが指摘したTDD+CIのプラクティスは、こういうシステム移行のような詰まらない案件で大きな威力を発揮するのだと思う。

【追記】リビルド・リライト・リホストに関する別の記事を見つけたのでリンクしておく。
説明は分かりやすい。

マイグレーションサービスの内容 | マイグレーション~システム移行の基本

リビルド手法・リライト手法 | マイグレーション~システム移行の基本

リホスト手法 | マイグレーション~システム移行の基本

| | コメント (0)

EVMはアジャイル開発に適用できるか

InfoQの記事で、EVMはアジャイル開発に適用できるか、という課題について書かれた記事があったのでメモ。
ラフなメモ書き。

【元ネタ】
アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるか

AgileEVM: 製品ライフサイクル全体で費用対効果を計測する

アジャイル開発は工事進行基準と相性が良いという仮説: プログラマの思索

RedmineのEVMプラグイン: プログラマの思索

【公開】未発表資料「チケット駆動開発におけるEVMの考え方」 #RxtStudy: プログラマの思索

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

EVMの考え方は、計画と実績の差異を追跡して、変化を抑え込む点にある。
計画通りに進まないのは悪い、計画通りに作業させる、という発想。
つまり、ウォーターフォール型開発と相性が良い。
でも、ソフトウェア開発の場合、WF型開発でうまくいった試しがない。

EVMを繰り返し型開発やアジャイル開発に適用する場合、そもそも計画に合わせて作業するという発想よりも、納期と費用の差異を現状に合わせて是正しながら作業する発想のため、そのままでは適用できない。
当初の計画があっても、その計画はすぐに現実に合わなくなるからだ。

途中でたくさんの仕様変更や仕様追加、障害修正が入って、それらを混ぜ込んで、小刻みにリリースしていくスタイルゆえに、計画をガチガチに守るよりも、スコープを調整する方を重視する。
だから、EVMをアジャイル開発に適用する場合、PV・AC・EVを再定義する必要がある。

アジャイル開発でももちろん見積もり作業はある。
その見積もり(PV)は開発規模(ストーリーポイント)が普通だろうが、EVMの場合は理想日という工数を使えばいい。
実績(AC)は文字通り実績工数。
出来高(EV)は、Doneの定義で評価されたアウトプット。基本は、0または100%のいずれか。
つまり、出来高は、出荷可能な製品の一部であるかどうかで判断できる。
アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるかでは、「EV は資金提供者にとって意味のある単位,すなわち金額で完成予測を行う」ことに使おうとしている。

バーンダウンチャートとEVMの違いは、出来高という概念を残工数でみるか、完成した出来高の累積値として捉えるか、の違いだ。
つまり、バーンダウンチャートは、イテレーション単位にEVMのグラフからPV-EVの数値だけを時系列に抜き出したものと見なすことができる。

この観点の違いは重要だ。
バーンダウンチャートでは、PVは変動する値と見なすのに対し、WF型開発のEVMではPVは固定値と見なす。
そして、EVの考え方も、WF型開発では進捗率で測定するのに対し、アジャイル開発では未完了か完了のどちらかで測定する。
したがって、アジャイル開発の方がEVの定義が厳しいために、担当する作業の粒度を小さくしてどんどん完了していくペースでなければ、プロジェクトの進捗は遅延しているように見えるだろう。
つまり、アジャイル開発では、イテレーションというタイムボックスで管理したり、作業の粒度を小さくするなどの工夫をしなければ、EVMで測定しても変化がほとんどないから意味がない。

EVMをアジャイル開発に適用できると、EVMの公式を使って、プロジェクトの進捗やコストを予測したり評価する手法を使える。
AgileEVM: 製品ライフサイクル全体で費用対効果を計測するでは、SPIを使って進捗度合いをグラフ化して見える化している。
CPIを測定すれば、開発チームの開発ペースが分かるから、総コストも予測できるだろう。

このあたりのアイデアはもう少しまとめてみたい。

| | コメント (0)

2013/07/14

ビジネスモデルキャンパスの感想

ビジネスモデル・ジェネレーション」を読んでみて、ビジネスモデルキャンパスを描いてみた。
感想をラフなメモ書き。

【元ネタ】
【マインドマップ付き】Canvas『ビジネスモデル・ジェネレーション』(アレックス・オスターワルダー/イヴ・ピニュール著): ビジネス書のエッセンス(ビジネス書 書評ブログ)

話題のビジネスモデル・ジェネレーション(設計書)を徹底解説!

ビジネスモデル・キャンバスを使ってビジネスモデルを考える | インバウンドマーケティング/Facebookアプリ Hivelocity ハイベロシティ

ビジネスモデルキャンバスの作り方-ビジネスモデル・ジェネレーション - ウィリアムのいたずらの開発日記

ピクト図解×ビジネスモデルキャンバス勉強会を開催しました。 - Akaponのメモ帳

【1】ビジネスモデルキャンパス(BMC)は、ビジネスモデルを9つの観点で1枚の紙に描いて分析する手法。
普通は新規ビジネスモデルを作るために使うのだろうが、既存ビジネスモデルの理解にも役立つ。

9つの項目のバランスと配置が絶妙。
右半分が売上、左半分が費用に分けてみることもできるし、SWOTで当てはめることもできる。
描き方も直感的でよいし、絵を入れるともっと分かりやすくなる。

ビジネスモデル・ジェネレーション」にはパターン集がついていて、ロングテール・プラットフォーム・フリーミアム(オープンソース)などがパターン内容もその名の通りで分かりやすい。

気軽に描きやすいのも良い。
普通は、ホワイトボードや模造紙にビジネスモデルキャンパスのレイアウトを書き、話しながらPostItでペタペタ貼っていく。
アイデアはスケッチ風。
ブレーンストーミングで出すとアイデアがどんどん出る。

【2】ビジネスモデルキャンパスの使い方にはコツがいくつかあると思う。

一つ目は、モデルの所有者を明確にすること。
「ユーザ企業のB2Cビジネス」のBMCならば、ユーザ企業はBMCに出てこない。
SIやベンダーは、パートナーの項目に現れる。

逆に「SI企業がユーザ企業へ提供するビジネス」ならば、SI企業はBMCに出ず、ユーザ企業が顧客の項目に現れる。
つまり、モデルの所有者は誰か?: プログラマの思索にもあるように、モデルの所有者はモデルに出てこない。

BMCを色々描いてみて、やはり顧客観点で描く方が色んな案が出る。
顧客企業が誰にどんなサービスや商品を提供するのか?
SI企業の観点で描くと、ユーザ企業にどんなシステムを提供するのか、という観点になるために、チャネルが限られてしまい、発想が出にくい。

二つ目は、顧客セグメントや価値が重要なこと。
誰に何を売るのか?が明確でなければ、BMCはあいまいになりやすい。
逆に、顧客と価値(サービス)がはっきりすると、どんな方法で売るのか?、どんな関係を築きたいのか、どのように収入を得るのか、が明確になってくる。

更に、顧客と価値のセットで色んなビジネスモデルの案が出てくる。
顧客といっても、セグメントに分けると、「LINEを使う女子大生」や「自由時間はゲームにはまる若い男子サラリーマン」では、提供するサービスも変わってくる。
BMCを描くうちに、顧客セグメントがはっきりしてくるメリットもある。

三つ目は、顧客との関係(CS)が難しいこと。
チャネル(顧客へ商品やサービスを提供する方法)は限られている。
店舗に来てもらったり、配送業者に納品してもらったり、Webで注文してもらうぐらいしかあまりない。
顧客にサービスを提供することで、何を目標とするのか?

実際にCSを描いてみると、お金や商品を伴わないチャネルになりやすい。
すると、ユーザ企業への信頼、初対面の人と集まる場、友人と絆を深める、など、ふわっとした内容が多くなる。
実際、FacebookやTwitterを使う理由も、お金よりも、色んな人との関係作りが目的のはず。

CSを意識すれば、リピーター顧客が増えて収入が安定するだろうし、集客してファンが増えれば、ファンが商品やサービスを勝手に広めてくれる。
マーケティング方法のAIDMAモデルやAISASモデルを連想させる。
顧客との関係を深めることで、ビジネスモデルは安定する。

インターネットマーケティング(AIDMAからAISAS/AISCEASへ): eビジネス・IT戦略の波間に

(引用開始)
AIDMA = マーケティングで顧客の購買行動を分析する枠組み
 Attention → Interest → Desire → Memory → Action
 (注意)     (関心)   (欲する)  (記憶)   (購入)

AISAS = ネットでの購買行動のモデル
 Attention → Interest → Search → Action → Share
 (注意)     (関心)   (検索)   (購入)   (共有)
(引用終了)

Google、それは強大な広告代理店: プログラマの思索

4つ目は、競争者は出てこないので、フレームワークに向き不向きがあること。
だから、3C(Consumer、Competitor、Company)の観点では描きにくい。
むしろ、4P(Product、Place、Promotion、Price)の方が向いているように思う。
どんなサービスを売るのか、の観点の方がアイデアを出しやすいように思う。

とはいえ、「ビジネスモデル・ジェネレーション」にはSWOTの当てはめ方も説明している。
ファイブフォース(5F)もBMCに使えるだろう。
フレームワークを当てはめれば面白いかもしれない。

| | コメント (0)

2013/07/13

ビッグデータに至るまでの歴史

「データ処理技術の歴史とビッグデータの現在」という記事が面白かったのでメモ。

【元ネタ】
佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(1/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(2/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(3/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(4/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(5/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(6/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

佐藤一郎氏が語る「データ処理技術の歴史とビッグデータの現在」(7/7):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ)

インメモリデータベース(IMDB)と列指向データベース(CODB)の歴史<データベースの歴史<歴史<木暮仁

19世紀後半、アメリカの国勢調査で収集したデータを集計するのに数年もかかっていた。
その問題に対し、パンチカードを導入して、集計作業を短縮化し、IBMの基礎を作った。
ビッグデータがコンピュータを生んだ。

トランザクションの原理ACIDがRDBの根本思想を貫いている。
原子性(atomicity)、一貫性(consistency)、独立性(isolation)、永続性(durability)。
それらの性質を満たすように、RDBMSは実装されている。

RDBは2種類ある。
IBMのSystemRの流れを汲むOralce、DB2。
UCBのIngressの流れを汲むPostgres、Sybase、そしてSQLServer。
Ingressの後継者という意味で、Post+Gress。

IBMは自社製のIMSを持っていたので、RDBの開発に乗り遅れた。
イノベーションのジレンマ。
IBMのコッド博士の継承者はOracleなのか?

DBの今後の動向。
列指向DBは、HadoopのHBaseに関連している。

インメモリDBが普及すれば、RDBMSのアーキテクチャが根本的に変わる。
RDBのボトルネックは、HDDへ書き込んで永続化(Durability)する箇所にある。
PostgresやMySQLのソースの大半は、メモリ上のデータをトランザクション処理を考えながら、いかに効率よくHDDに書き込むか、という工夫に費やされている。
メモリにデータを書き込んだ時点で永続化できれば、ソースが短縮化されて、すごく簡単になる。

NoSQLの今後。
大量データの収集と集計処理に強い。
但し、特定のアプリやサービスに特化しているため、そのままでは使えない。
分散システムを前提としているので、アーキテクチャに合わせた使い方が重要。

Hadoopのジレンマ。
RDBに比べて完成度が低く、RDBよりも未熟。
Hadoopの強みは、集計処理(Reduce)とデータの前処理(Map)だけ。
使いこなすには相当のノウハウが必要。

CAPの定理。
一貫性、可用性、ネットワークの耐性のうち、2つしか満たすことができないという経験則。
しかし、実際の現場では、3つの条件を全て満たせなくても、3つの条件は最低限クリアするように、ネットワークを冗長化したり、システムを冗長化したりして使っている。

今後面白いのは、90年代にRDB競争が激しかった頃のDB関連の特許が切れ始めるので、特許切れの内容をOSS製品が取り込んで実装されること。
今後、イノベーションが起きる可能性がある。

| | コメント (0)

2013/07/12

KPIで経営を見える化する

グロービスMBAアカウンティング」は内容が難しいけれど、「MBAアカウンティング教室」の方は内容は浅いけれど幅広く書かれていて、初心者としては読みやすかった。
MBAアカウンティング教室」を読んだ感想をメモ。
ラフなメモ書き。

【1】アカウンティングには財務会計と管理会計の2種類がある。
財務会計はPL・BS・CSなどの会計帳票があり、株主や会計士など社外の人の為に作る。
管理会計は、会社内部向けのKPI(メトリクス)を出力するためにある。
使う人は社員だ。

【2】「MBAアカウンティング教室」では最初に、米国のプロ野球の話がある。
いつも負けていた球団に対し、OPS(出塁率+長打率)やアウト寄与率など独自のKPIを導入して、従来の野球で使われていた打率・本塁打数・防御率などの数値(KPI)に頼らず、勝つために選手の能力を的確に評価するようにした。
その手法(サイバーメトリクス)によって、お金のない弱小チームを一躍し優勝候補に育て上げた。
この話は映画「マネーボール」、メジャーリーグのアスレチックスが発端。

元々、野球は数字と相性が良い。
選手に対して、管理会計によるKPI(メトリクス)を上手に使って、野球チームを変えたということ。
この手法を応用すると、KPIを経営に使えば、どうなるか?

【3】管理会計の運用サイクルは下記になる。

・戦略に合わせて測定する指標(KPI)を定める。
・出てきた数字を共有し、見る化する
・数字を元に経営や現場での意思決定に活かす
・PDCAを回して、常に業績向上を目指す

つまり、管理会計は、KPIというメトリクスを使って現場の担当者のモチベーションを喚起し、業績向上に結びつける手法と言える。
MBAアカウンティング教室」では、KPIを使った具体例が紹介されていて面白い。

例えば、星野リゾートでは、顧客満足度のアンケートを収集し、顧客満足度と関連性のある項目を徹底的に分析して、リピート率や客単価を増やしている。

京セラではアメーバ経営という独自のKPIが有名。
アメーバ経営では、アメーバという小集団に損益責任を持たせる。
KPIとしては、人件費を引かない利益を指す差引売上、差し引き売上を従業員の総労働時間で割った時間当たりの差し引き売上を増やすことを目指す。
通常は、利益は、売上から人件費を差し引くものだが、そのようなKPIにすると、優秀な人は人件費が高いから不要だ、と人件費カットへ歪んだ方向に行きやすい。
だから、人件費は気にしなくていいから、それを差し引く前の利益を最大化するように、というメッセージを社員に送っている。

すると、だらだら時間をかけて売上を上げても時間当たりの差し引き売上は上がらないから、生産性を上げる方向に社員は動く。
例えば、営業マンはしっかり準備し、見込み客を見極めて、極力短時間で商談をまとめあげるようになる。

ノードストロムというアメリカの百貨店では、時間当たりの売上を重視する。
従業員は、丁寧な接客を心がけて、リピート購入を目指そうとする。
普通、百貨店では、面積単位の売上や利益が重視されるが、別のKPIで従業員の方向性を決めている。

3Mは、総売上に占める新製品の比率を重要なKPIに定めている。
このKPIによって、新しい独自製品を生み出そうとする姿勢を従業員に求めている。
Googleの20%自由労働と同じような効果を求めているわけだ。

【4】KPIの長所は見える化。
経営や現場の状況をある観点で数値化した指標を用いることで、経営者や担当者に気づかせる。
KPIによって、現場の担当者の行動を変化させる。
しかし、KPIというメトリクスにも短所はある。

一つは、KPIを収集して集計するコストが大きいことだ。
現場の担当者の作業中に数値を採取し、その数値を集計する手間がかかる。
だから、収集や集計にあまりコストをかけず、ややアバウトでも運用できる方がいい。

2つ目は、測定方法はあまり変えないこと。
KPIの数値がコロコロ変わるようでは、誰も信用しなくなるし、分析した結果から得られる結果が少なくなる。

3つ目はKPIの鮮度とタイミングを重視すること。
せいぜい日次で収集して集計して、すぐに現場で使える方が良い。
そうでなければ、KPIは現場では使われないだろう。

そんなKPIの話を聞くと、ソフトウェア開発のメトリクスにとても似ている。
テスト密度、バグ密度などのメトリクス、信頼度成長曲線、管理図などの品質管理技法は、管理会計の手法とその目的にとても良く似ている。
ソフトウェアメトリクスによって、ソフトウェアの品質が分かる。
だが、ソフトウェアメトリクスは、収集や集計のコストがとてもかかる。
実際、開発者にExcelシートへ記入させて、それをExcelマクロで集計するやり方が従来はとても多かった。

そして、管理会計のKPIとソフトウェアメトリクスの大きな違いは、KPIは従業員を鼓舞する面が大きいのに対し、ソフトウェアメトリクスは開発者のモチベーションを下げるような性質の項目が多いこと。
バグ数やテスト密度、LOCなど、開発者をもっとイノベーティブに行動させようとする動機に欠けている。
むしろ、開発者を萎縮させたり、その数値を改ざんさせたいと思わせたりする方が強い。

ソフトウェアメトリクスは、開発者の動機を高めるような方向へ作り変えるべきではないか?

【5】「MBAアカウンティング教室」で興味深いのは、TOCのスループット会計の説明があったこと。
従来の会計の問題点は、在庫のムダが多くなりがちなこと。
仕入から製造まで、原材料や仕掛品は資産として計上される(原材料//買掛金など)。
そして、販売した時点で、製品は売上に変わる。(売上原価//売上)

つまり、従来の会計手法では、製品が売上計上されるまで、在庫は資産として計上されてしまうため、在庫をたくさん作るほど利益が出るように見えてしまうことだ。
工業簿記で出てくる全部原価計算では、特にそうなりがち。
在庫を増やして1個あたりの製品原価が小さくなるように見えて、逆にたくさんの負債を抱えてしまうわけだ。

MBAアカウンティング教室」では、80年代に隆盛を誇った日本の半導体産業が90年代以降落ちてしまった理由の一つは、全部原価計算に固執したコスト計算で在庫を積み上げてしまったのに対し、アメリカではEVA・BSC・ABCなどの手法を用いてコスト計算を根本的に変えて徹底的にコストを下げた点にあるのではないか、と指摘している。

TOCのスループット会計では、その問題点に対し、スピードを重視した会計基準を考える。
つまり、製品1個あたりの売上よりも単位時間あたりの売上を重視する。
より多くの売上を上げるには、生産性を挙げることが重要であり、TOCでは、制約となるボトルネックの生産性に依存している。
TOCによれば、ボトルネックとなる工程の生産性を上げて稼働率を高める方が、時間当たりの利益が増える。

すると、ボトルネックでない工程や機械の生産性がいかに高くても、ボトルネックとなる工程の生産性が低ければ、それら生産性の高い工程や機械は遊休資産になっている。
遊休資産は資産と言えども、機械であればリース代もかかっているし、ボトルネックのせいで稼働率の低い工場も水道代や電気代などの費用がかかっている。
つまり、機械や工場のように利益を生み出していない遊休資産にも実はコストがかかっている事実を示唆しているのだ。

MBAアカウンティング教室」ではスループット会計を活用しやすい分野として、人の質が効率に大きく依存するIT業やサービス業で有効であると述べている。
確かに、開発者の生産性は人によって10倍以上の差があるわけだから、ボトルネックは特定の人に偏りがちだ。
だからこそ、時間当たりの売上や利益を増やすために、ボトルネックとなる部分に注力するやり方が有効なのだろう。

【6】他にも活動基準原価計算(ABC)や損益分岐点分析(CVP分析)などの話も興味深かった。
管理職や経営者の立場になると、こういう知識は知っていて当然になるので、「MBAアカウンティング教室」のような読みやすい本で浅く広く知っておくのは有益だと思う。

| | コメント (0)

2013/07/10

TestLinkとEnterprise Architectを連携する

TestLinkとEnterprise ArchitectやRaQuestを連携するスクリプトが公開されていたのでメモ。

【元ネタ】
日々精進 - スパークスシステムズ ジャパン代表のBlog:TestLinkとEA/RaQuestとの連携 - livedoor Blog(ブログ)

スパークスシステムズジャパン フォーラム - ニュース

TestLinkの要件管理機能: プログラマの思索

jenkins-testlink-plugin: プログラマの思索

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

Enterprise Architectでモデルを書いて、そのモデルから要求を紐づけている時、その内容をTestLinkの要件管理機能にインポートできるスクリプトを公開している。
目的としては、モデルに書かれた仕様と本来の要求が関連している関係をTestLinkのテストケースと関連付けて、要求から仕様を経てテストケースに至るまでのトレーサビリティを実現したいことだ。

特にテストケース作成時に、要求や仕様を全て網羅しているか、という観点で、テストケースに対する要件カバレッジを取ると、結構網羅できていない時が多い。
つまり、テストケースの作成段階で、テストされない要求が結構出てくる。
だから、テストケース作成の作業は細心の注意を払う時が多い。

そして、TestLinkのテストカバレッジ機能を使えば、実際にテストできたテストケースから、逆に要求をどこまでテストで検証できたのか、という要件カバレッジを見ることもできる。
実際のテストでは、1サイクルのテストで全ての要求を網羅するのは不可能だ。
実際は、複数のサイクルで要求を網羅できるのが普通だから、アジャイル開発のように、テストケースやテスト対象の要求を分割して、サイクルないしイテレーション単位にテストして、要件カバレッジを100%にする戦略が必要となってくる。

TestLinkを使ってみると、実際のテスト管理や要求管理の奥深さを知ることができて面白かった。

個人的には、TestLinkのテストケースや要件管理とastahの要求図や概念モデルを連携できれば面白いだろうと思う。
特に、要求図はゴール指向分析という要求工学から発生した技術なので、よく考えられているのではないかと想像している。

astah* professional 6.1の要求図: プログラマの思索

Astahプラグインの資料のリンク: プログラマの思索

色々試してみる。

| | コメント (0)

2013/07/09

リーダーに聞くな、チケット管理システムに聞け

Redmineは使い込むほど面白い機能がふんだんにある。
ラフなメモ書き。

【元ネタ】
期日が間近のRedmineチケットをメールで通知する: プログラマの思索

期日が間近のチケットをメールで通知する(リマインダ機能) ? Redmine.JP

Class: Mailer ? Documentation by YARD 0.8.6.1

チケットが更新されずに放置されると、リーダー一人で修正するのは結構大変だ。
むしろ、放置されたチケットを毎朝通知して、担当者が棚卸しすべきだろう。
普通は、毎朝、誰かがクエリでフィルタリングして、棚卸しすべきチケットを一覧にしてメールで通知する運用になるだろう。

だが、そのような運用は、Redmine自らが通知すればいいはずだ。
リーダーに聞かずとも、Redmineに全ての作業情報があるのだから、チケット管理システム自身に聞けばいいだけのことだ。

現在のRedmineには、期日が間近になったチケットを通知する機能がある。
できれば、この機能をさらにカスタマイズすればいい。

30 6 * * * root cd /path/to/redmine ; rake redmine:send_reminders days=3 RAILS_ENV=production

Sends reminders to issue assignees Available options:

:days => how many days in the future to remind about (defaults to 7)
:tracker => id of tracker for filtering issues (defaults to all trackers)
:project => id or identifier of project to process (defaults to all projects)
:users => array of user/group ids who should be reminded

Class: Mailer ? Documentation by YARD 0.8.6.1のソースを見ると、上記のオプションが使える。
更に、ステータス、開始日、カテゴリ、担当者などを検索条件に入れて、メール本文にチケットの属性をもっと増やして通知すればいいだろう。

チケット管理システム自身が通知する機能は、最終的には、ベースラインごとのメトリクス情報を出力する機能に発展できるだろう。
つまり、リリース日やマイルストーンのようなベースラインごとに、その時点のチケット集計情報から得られる進捗や品質、工数の情報を一括集計して出力する機能になってくる。
上記の機能は、メールで出力するわけだが、用途によっては、PDFなり紙の帳票で出力してもいい。

そのような機能は最終的には、チケット管理システムがソフトウェア開発のERPとなり、ベースラインごとの情報を出力して、リーダーやPM、経営者が分析する情報の元ネタになるだろう。

色々考えてみる。

| | コメント (0)

2013/07/06

チケット駆動開発の運用例part5

チケット駆動開発を適用した論文や事例を見つけたのでメモ。

【1】ソフトウェア開発 PBL へのチケット駆動開発の適用による共同作業の改善

細粒度プロジェクトモニタリングのためのDaaSを利用したソフトウェア開発PBL支援環境の提案

大学のPBL(Project-Based Learning/Problem-Based Learning)型の教育において、学生と教員が中心になってRedmineによるチケット駆動開発を実践した運用例が紹介されている。
2010~2011年度に試されているので、かなり早い時期に注目していたと思われる。

興味深いのは「Redmineによるタスクマネジメント実践技法」を参照して、EVM作成にもチケット管理を適用しようと考えている所だ。
やはりPMにとって、EVM作成のコストはプロジェクトが破綻するぐらい大きすぎるらしい。

(引用開始)
Redmine を利用することで表 4 の値は,データベースに格納されているため,今後のコストやスケジュールを簡単に計算できシュミレーションすることができる.
2010 年度の活動では,PM たちが進捗報告時に EVM で進捗状況を報告するために多くの時間(コスト)を割いていた.
Redmineを利用することにより,EVM 作成の手間を軽減できると考える.
(引用終了)

【2】運用ドキュメントの共有と変更管理 運用ドキュメント2011 ~手軽にスピーディに継続的に保守するためのツール入門~ Part-3

ドキュメントの変更管理にチケット駆動開発を適用すると以下の利点がある。

(引用開始)
No ticket, No commit 「チケットの無い作業はしてはいけない」
・作業全てをチケットで管理する。(チケットシステム中心の業務)

運用作業やドキュメント管理も本質的には同じ。
・チケットの無い「闇作業」や「闇変更」は百害あって一利も無い。
・時間とともにその経緯が誰にもわからなくなってしまう。
・ドキュメント管理については、下準備をチケット上でやることにより、執筆/レビュー前に関係者からコメントが得られる可能性がある。
 また、後日類似の検討があった場合に、ゼロからの検討が必要なくなり短期化できる可能性も出てくる。
(引用終了)

(引用開始)
チケットにすることで、やることが明確になる、頭から忘れてもかまわないという安心感がでてくるため、作業に集中しやすい。
・チケットにまとめておくことで、過去のやりとりメールをあさらなくて良い
・親子チケットにより、大きいタスクを細分化することで、目先何をやればいいのかが見えてくるため、進めやすくなる。
・質の良いチケットは経緯を残しているため、ドキュメント本体に残りにくいWhy(なぜそうしたのか?)が残りやすい。
・チケットにしておけば、気付いた人が進めてくれる可能性が出てくる。
・優先順位を付けやすくなる。(期限 vs. 優先度)
・工数を都度入れておけば、実測に基づく実績として有効なデータとなる。
・作業にリズムが出てくる。
・蓄積により、チケット全体が一次ナレッジデータベースの価値を持つようになる。
(引用終了)

上記のPDFでは、ドキュメント管理では、Sphinx+Mercurial+Redmineがお勧めらしい。

基本的には、タスク管理と名の付く業務には、チケット管理は有効だと思う。

| | コメント (0)

RedmineはCRMソフトとして使えるか?Part2~RedmineをCRMソフトとして使うためのプラグイン

RedmineをCRMソフトとして使うプラグインを調べてみたら、実はかなりたくさんあった。
そのうち、いくつかのプラグインについてラフなメモ書き。

【1】顧客情報を保持するプラグイン

PluginCustomer - Redmine

edavis10/redmine-customer-plugin

Redmineの初期の頃に、RedmineコミッタだったEricが作った顧客プラグインがある。
単に顧客情報を登録して保持するだけのプラグインなので、何の役に立つのだろう、と思ったときがあった。
今振り返ると、CRMソフトのように、顧客情報をRedmineユーザとは違うエンティティで保持してチケットと紐づけたい動機があったのではないか、と推測する。

【2】Redmineにアウトバウンドメール機能を追加してヘルプデスク機能を持たせたプラグイン

Help Desk - Plugins - Redmine

コンタクト - コンタクト - Redmine CRM plugin demo - RedmineCRM demo

Redmineをヘルプデスクの問い合わせ管理に使いたい場合、問い合わせメールを受信してチケットに自動登録できるインバウンドメール機能はあるが、顧客へ返信したり通知するアウトバウンドメール機能はない。
Help Deskプラグインを使うと、アウトバウンドメール機能をRedmine上で操作できるようになる。

デモ画面で触ってみると、インバウンドメールを受信した内容はチケットに起票されるだけでなく、FromアドレスやTo・CCアドレスもチケットの上部に表示される。
メールによるRedmineのチケット登録機能には、From・To・Ccがチケットに表示されないので、この機能はありがたい。

【3】RedmineにCRM機能を追加したプラグイン

CRM - Plugins - Redmine

コンタクト - コンタクト - Redmine CRM plugin demo - RedmineCRM demo

RedmineCRM - Premium Redmine plugins, CRM, Helpdesk, Invoices - Redmine plugins

もっと本格的に、RedmineにCRM機能をプラグインとして売り出しているサイトもある。
上記のCRMプラグインは無償でも提供されていて、crm | Posoxの記事によれば、十分に使えるらしい。

(引用開始)
Redmineで顧客管理と案件管理を容易に実現できるPluginを紹介する。
プラグインは公式サイトからダウンロードできる。※Pro版もあるが、無償版でも十分に有用
このプラグインの優れているところは、顧客管理はさることながら、顧客に紐づいた案件管理が実現できることである。
通常案件は会社又は特定の担当者からの受注になる。このプラグインでは、会社からの引き合い、会社の担当者からの引き合いとステータスをそれぞれ管理できるので、より実態に即した案件管理が実現できる。
また、引き合い、受注など任意のステータスを定義し、ステータスごとの合計金額をリアルタイム表示できるので、案件状況のダッシュボードとしても利用できる。
さらに、案件状況をメール、電話、会議などの状況に応じてノートとして追記できるので、案件状態が即座に共有できることも利点の一つである。
(引用終了)

実際に設定画面を見ると、取引カテゴリや取引ステータスを設定できるので、顧客ごとの案件や商談をチケット管理したときに、それらの属性を追加することができる。
したがって、どの案件が受注見込み(受注に至っていないが確度の高い案件)なのか、を追跡することもできる。

RedmineCRMプラグインで顧客ごとの案件情報を一括管理し、裏では受注・売上・請求情報を会計システムと連動すれば、十分に使える可能性はある。

【4】RedmineがCRMソフトになりきれない理由はどこにあるか?

CRMの基本は、顧客管理と営業支援であり、潜在顧客からいかに見込み顧客を抽出して、実際に契約に結びつけるか、という営業を支援することにある。
その一環で、契約後の顧客問い合わせ管理(いわゆるヘルプデスク)やビッグデータによる顧客行動分析があるが、付随的機能だろう。

すると、顧客ごとの案件を管理したくなる。
並行して2つの案件を受注しようとする場合もあるだろう。

また、顧客がユーザ企業であれば、窓口は情報システム部門だけでなく、各部門に分かれていたり、更に窓口担当者も複数人いたりする。
当然、窓口担当者の中でキーマンの人は別格だ。
顧客は単なる「ユーザ」ではないのだ。

RedmineがCRMソフトになりきれない理由は、「顧客」というエンティティをRedmineにマッピングしづらいからだと思う。
CRMで重要なエンティティは、顧客と案件(商談)だ。
その関係は、顧客◇--案件で構造化できる。

案件はチケットに対応付けるのは自然な発想だ。
案件ステータスはチケットのステータスに対応付けられ、案件とチケットのライフサイクルを同一視できる。
不足した情報は、チケットのカスタムフィールドに案件特有の属性を追加すればいい。

しかし、顧客はRedmineユーザなのか、チケットのトラッカーで区別すべきなのか?

Redmineユーザはチケットを扱う担当者を意味していて、顧客ではない。
顧客特有の属性とチケット担当者の属性は当然違うので、Redmineユーザのカスタムフィールドを追加する手法もありうる。
しかし、Redmineユーザとして同様に扱うのは、最終的には無理があるだろう。
Redmineユーザ△--顧客、チケット担当者という継承関係で構造化できるからだ。

顧客の数が少ない場合、顧客をチケットのトラッカーに対応させて、トラッカーで区別するのは良いやり方だと思う。
Redmineの「トラッカー」は単なるワークフローだけではなく、チケットの種類を一意に識別する識別子でもある。
だから、トラッカーに顧客に必要な属性(住所、電話番号、重要顧客区分など)を追加すると良いだろう。
トラッカー単位にチケットをグループ化しやすいし、顧客ごとの傾向も判別しやすい。
しかし、顧客の数が数千規模になるなら、トラッカーを使うのは現実的ではない。

他によくやる方法は、顧客をRedmineプロジェクトにマッピングする方法だ。
例えば、たくさんの顧客のシステムを細々と長年従事している運用保守では、顧客のシステムをRedmineプロジェクトに対応付けて、タスクをチケット管理する。
Redmineプロジェクトは階層構造を持たせることができるので、粒度に応じて階層化すればいい。
しかし、Redmineプロジェクトが多すぎると、逆にチケット管理しづらくなる場合もある。

現実的には、Redmineのユーザグループを取引先企業、Redmineユーザを担当者にマッピングするのがBetterだろうと思う。
そうすれば、取引先企業の情報は、ユーザグループの属性情報として表現できるし、担当者の情報と明確に区別できる。
取引先企業が大企業で、部署ごとに管理する必要があるならば、Redmineユーザグループを取引先業の部署にマッピングすればいい。

結局の所、Redmineのデフォルト機能では、顧客というエンティティをマッピングしづらいのだと思う。
その理由は、Redmineは本来、CRMソフトとして作られたわけではないからだ。
だから所詮は無理がある。

でも、Redmineには、他の業務にもチケット管理を適用してみたいと思わせる雰囲気がある。
もしCRMとしてRedmineを使いたいならば、顧客情報を保持するテーブルを別途作ればいいだけのことだ。
足りない機能は新規テーブルを作りプラグイン化すればいい。
つまり、Railsを操る技術力さえあれば、CRMのうち欲しい機能を実装するのはそう難しいことではない。

今の僕の興味は、チケット管理が適用できる業務はどの範囲まであるのか、もしチケット管理が向いていない業務へ適用する場合はどんな機能を追加すれば実現できてどんなメリットがあるのか、にある。
色々考えてみる。

【追記】
RedmineCRMプラグインのデモサイトの画面キャプチャをリンクしておく。
画面から雰囲気が分かるだろう。

Contact_1_ivanov_ivan_redmine_helpd

Contacts_contacts_redmine_crm_plugi

Contacts_contacts_redmine_helpdesk_

Invoices_redminecrm_demo

Redmine_helpdesk_plugin_demo_redmin

Support_574_questions_about_commerc

Redminecrm_demo

_redminecrm_demo

Redmine_crm_plugin_demo_redminecrm_

Redminecrm_demo_2

Finance_redminecrm_demo

Helpdesk_redminecrm_demo

Invoices_redminecrm_demo1

Invoices_redminecrm_demo2

People_redminecrm_demo

Redmine_crm_plugin_demo_redminecr_2

Redminecrm_demo1

Redminecrm_demo2

| | コメント (0)

2013/07/05

テスト駆動開発に必要なノウハウ~ドライバとスタブ

テスト駆動開発は誰もが重要と考えているのに、現場ではあまり普及していない。
その原因の一つは、テストプログラムを書く技術として、ドライバやスタブという概念が普及していないことと、ドライバやスタブを実際に利用する方法のノウハウが不足しているからではないかと思っている。
考えたことをラフなメモ書き。

【元ネタ】
スタブとは 【stub】 - 意味/解説/説明/定義 : IT用語辞典

ドライバとは 【driver】 〔ドライバー〕 - 意味/解説/説明/定義 : IT用語辞典

トップダウンテストとは 【top down test】 - 意味/解説/説明/定義 : IT用語辞典

ボトムアップテストとは 【bottom up test】 - 意味/解説/説明/定義 : IT用語辞典

ビッグバンテストとは 【big bang test】 - 意味/解説/説明/定義 : IT用語辞典

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

テスト駆動開発による組み込みプログラミングも良い本です: プログラマの思索

【1】テスト駆動開発の最大の利点は、テスト自動化と回帰テストの組み合わせで、機能がデグレードしない保証を取りやすいこと。
第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索で、@marutosijpさんの話を聞いて改めて思ったのは、RedmineがRailsやRubyのVerUpやJQueryへライブラリを移行できたのは、テストプログラムをきちんと書いて、CIツールで回帰テストしていたから。
Redmineから派生した他プロジェクト(Chiliprojectなど)は全て、RailsのVerUpに追いつけずに破綻している。

最近なら、WindowsXPやIE6が終了モードになり、Windows8やIE10へ移行する流れにあるが、OSやブラウザのVerUpで正常動作しなくなる業務アプリやWebアプリは非常に多い。
ユーザの観点では、OSやアプリ、ミドルウェアのVerUpがあっても正常動作すべきだが、開発者の観点では、機能がデグレードしない保証を取るためにかなりの工数をかける。

だから、ユーザの観点では、OSやミドルウェアのVerUpは何の価値もないから、SIとしてはデグレしない費用を取りにくい。
システムは変わらないのに、OSやブラウザなどの環境が変化してしまうことで、システムが正常動作しなくなるという矛盾。

だからこそ、テスト駆動開発の重要性は、最近のように環境が変わりやすい状況では非常に高まっていると思う。
しかし、実際の現場ではテスト駆動開発の重要性を知っているにもかかわらず、あまり実践されていない。
その理由は何故か?

最近思うのは、テスト駆動開発には、従来のプログラミング技術とは違う別のノウハウを必要とするのに、それを知らないからではないか、と思っている。
そのノウハウは、ドライバとスタブというテスト特有の技術だ。

【2】テスト駆動でプログラムを書くと、スタブを書く時が非常に多い。
つまり、トップダウンテストでプログラムを書く場合が多い。

スタブとは 【stub】 - 意味/解説/説明/定義 : IT用語辞典
トップダウンテストとは 【top down test】 - 意味/解説/説明/定義 : IT用語辞典

理由は、小さな部品を作るよりも、仕様がほぼ確定した上位モジュールをまず作り、詳細なロジックは外出しのプログラムとしてスタブ化してテストしておき、後からスタブ化したプログラムを実装していくパターンになりやすいから。

トップダウンテストでは、テスト対象プログラム◇---スタブとして構造化し、詳細なロジックはスタブとして外出ししてテストする。
Red→実装→Greenというテスト駆動の流れは、まずスタブを空実装してから詳細なロジックを一つずつ作っていくやり方が多いだろう。
オブジェクト指向設計ならば、責務中心のクラス設計になりやすいので、長くなりそうな処理は外部クラスでスタブ化しながら詳細化していけばよい。

スタブを使うトップダウンテストの利点は、仕様の振る舞いを決定する上位モジュールを早めにテストできることがある。
つまり、仕様漏れ、認識間違いを早期に検知できる利点がある。
しかし、欠点は、数の多い下位モジュール(スタブ)の検証が遅れるので、プログラミング力が劣る開発者は工数がかかってしまうこと。
そして、スタブとして使われるモックオブジェクトには特有の開発ノウハウが必要だから。

RSpec でテストを作るのに役立つ「モック/スタブ」のシンプルな説明 - 酒と泪とRubyとRailsとに書いているように、モックとは「「オブジェクトのメソッドがどう呼ばれて何を返すか」というインタフェースも含めたテストのために使う」ものであり、スタブとは「テストをスムーズに行うために「あるオブジェクトのメソッドが呼ばれたら、ある戻り値を返す」ために使う」ものであるという定義は分かりやすい。

多分、テスト駆動開発でつまずいてしまう理由の一つは、モックオブジェクトの利用ノウハウが整理されていないからだと思う。
実は、モックオブジェクトの実装方法は、Ruby・Java・C#などの各言語で全く違う。
JavaならjMockが有名だろう。
だから、使い方に慣れない人が多いのではないかと想像する。

RSpec でテストを作るのに役立つ「モック/スタブ」のシンプルな説明 - 酒と泪とRubyとRailsと

スタブとモック

モックとスタブの違い ? [lib]

JMockのインストールとEclipseでの使い方まとめ | Futurismo

【3】スタブの概念は、単体テストだけでなく、外部接続テストでも有効だ。
例えば、Webの注文システムをテストする時に、最後にクレジットカード払いの注文プロセスで、クレジットカード会社へクレジットカード番号の認証とオーソリ認証、与信チェックを依頼する処理があったとしよう。
すると、カード払いの注文テストを行うには、外部接続のテストサーバーを準備しなければ、ユーザの業務を想定したテストにならない。

そこで普通は、カード決済用のテストサーバーとテストプログラムを準備しておく。
処理としては、注文システムからカード番号などの情報をカード決済テストサーバーへリクエストで送り、テストサーバーでリクエスト情報をチェックした結果を注文システムへレスポンスで返す。
チェックした結果がOKならば、注文システムからテストサーバーへリダイレクトして、テストサーバー上でカード決済処理を実施して、最終結果を注文システムへレスポンスとして返す、というフローになるだろう。

すると、テストサーバーの役割は、ある特定のカード番号と個人情報は正常データとして受け取り、それ以外はオーソリ認証エラーなどでエラー返却する処理を持つモックオブジェクトのような仕組みを担当することになる。

カード決済を提供するカード会社では普通は上記のようなテストサーバーを提供してくれるので、自前で作る必要はほとんどない。
しかし、仕入先と発注データをやり取りするなど外部接続のシステム連携がある場合、モックオブジェクトの役割を持つテストサーバーを自前で作るしかない時もある。
その場合の開発工数はそれなりに大きいものだ。
だから、経験あるマネージャは、外部接続テストで必要な工数を別途大目に確保したり、開発工程とは別にテスト準備を事前に並行開発して進めたりする。
そうすることで、モックオブジェクトの役割を持つテストのリスクをカバーしているわけだ。

【4】事前に小さな部品を作って、それら部品を結合しながら開発していく場合、ドライバを使う時が多い。
いわゆるボトムアップテストでは、ドライバ◇---テスト対象プログラム(部品) という構造になり、ドライバを使って部品をテストする。
普通は、ドライバにたくさんのデータパターンを投入して部品の詳細ロジックを網羅するようにテストするから、DBUnitを使う時が多い。

ドライバとは 【driver】 〔ドライバー〕 - 意味/解説/説明/定義 : IT用語辞典

ボトムアップテストとは 【bottom up test】 - 意味/解説/説明/定義 : IT用語辞典

ボトムアップテストの利点は、数が多い独立性の高い下位モジュール(部品)を順にテストできるので、並行開発して納期を短縮しやすいこと。
例えば、組み込み製品のプログラム開発では、たくさんの部品をあらかじめ作ってから、ドライバを使って多くの部品を結合してテストするパターンが多いだろう。

逆にボトムアップテストの弱点は、振る舞いを決定する上位モジュールで不具合が見つかると、テスト完了した下位モジュールに手戻りが発生することだ。
だから、手間はかかるが、部品を1個ずつ作るたびにドライバを作ってはテストする方が安全だ。

ボトムアップテストを更に突き進めると、ウォーターフォール型開発で主流の結合テストであるビッグバンテストになる。
ビッグバンテストとは、単体テストが終了したモジュールを全て一度に結合してテストするやり方だ。
ビッグバンテストは、ドライバやスタブを用意する必要がないので準備工数が少ない利点はあるが、最大の弱点は、一度に全ての障害が発生するため、障害の原因特定が難しくなることだ。
WF型開発の結合テスト、システムテストでデスマーチになりやすい理由は、そこにある。

情報システム用語事典:ビッグバンテスト(びっくばんてすと) - ITmedia エンタープライズ

昔の業務系Webシステム開発でも、DB層、コントローラ層、ビュー層で開発担当を分けて、大量のプログラマが並行開発するパターンが多かった。
このパターンが失敗しやすい理由は、ビッグバンテストになるまで、誰も自分が作ったプログラムがまともに動くのを見たことがないから、リスクがずっと残されたままになることだろう。

最近は、Railsのような優れたWebフレームワークのおかげで、機能単位や画面単位に一気通貫で開発するので、トップダウンテストの方が多くなっている。

でも、ドライバを使ったテストで多いのは、受入テストだろう。
例えば、Web画面からのテストを自動化する場合、Seleniumを使う時が多いが、Seleniumはまさにドライバの役割を担っている。
同様に、FITのように、Wiki画面でデシジョンテーブルを作り、そのテストケースでテストする方法も、ドライバの役割に相当している。

コード品質を追求する: FITで解決する

Selenium IDEを使って、ChromeやIE上でテストスクリプトを実行する方法 | 品質向上ブログ

受入テストの自動化が重要と誰もが分かっているのに、なかなかテスト駆動が浸透しない理由の一つは、ドライバとなるテストプログラムの作成が現在のライブラリでは非常に難しいからだろうと思う。
ドライバを一から作るのは、スタブを作るよりももっと難しい。

更に、ドライバを作ったとしても、FITのようにたくさんのデータパターンを用意する必要があるので、テストケース作成の技法も必要とする。
Seleniumでも、ブラックボックステストで機能を網羅するにはどんなテストケースが必要なのか、というテスト作成技法を必要としている。
テスト技法である境界値分析、同値分析などの手法も必要としているのだ。

スタブやモックはだいぶノウハウが公開されてきているけれど、ドライバに関するノウハウはまだまだ足りないと思う。

【5】「ドメイン特化言語」を読んでいて気づいたことは、テスト駆動を支えるライブラリはDSLで実装されている場合が多いことだ。
ドメイン特化言語」では、FITやjMockがDSLの一例として紹介されている。

すなわち、テスト駆動で書いたテストプログラムは、ドメイン専門家でも理解できるような内容の方が良いことを意味している。
例えば、FITのようにWiki上でデシジョンテーブルの受入テストを作る作業は、プログラマでなくとも、受入テストを担当するユーザでも良い。
また、jMockの利用プログラムは、流れるようなインターフェイス、いわゆるメソッドチェーンで実装されているらしい。

テスト駆動ライブラリがDSLで実装されている場合が多いという事実は、ドライバやスタブ(モック)を使うための技術としてDSLが必須であることを示唆していると思う。
つまり、テスト駆動開発が未だに普及せず、テスト駆動開発に必須なスタブやドライバの技術が未熟な理由の一つは、DSLを駆使してテスト駆動の敷居を下げる手法が未完成なのだろう。

逆に言えば、テスト駆動開発に必要なドライバやスタブのライブラリ開発は、DSLという最近注目されている技術を使ってチャレンジしていくべき意義のある領域なのだろうと思う。
今後もその辺りを考えてみる。

| | コメント (0)

2013/07/02

メールからRedmineのチケットを自動登録する時の注意点

メールからRedmineのチケットを自動登録する時の注意点をメモ書き。

【1】第8回RxTStudy勉強会で、@g_maedaさんは、顧客からの問合せメールをRedmineのチケットに自動登録する機能によって、ヘルプデスク管理をチケット管理に置き換える事例を紹介している。

第8回勉強会の感想~RedmineはCRMや情報系システムにも適用できる #RxTStudy: プログラマの思索

メール対応に付随する苦労の多いヘルプデスク管理をRedmineのチケット管理に置き換えたことによって、チケット管理の恩恵が得られる利点を強調されていた。
その反面、下記の課題がまだ残っていると話されていた。

(1)返信時のSubjectのチケットNoが間違っている場合、別チケットのコメントに追加されてしまう。
(2)メールソフトとRedmineを行ったり来たりして面倒。
 メール対応という一つの目的で2つのツールを使っている。
(3)古いメールに新たな問合せを返信メールで送る顧客もいる。
 古いチケットNoがSubjectに入っている場合が多い。
(4)サポート担当者からメールを発信する場合、SubjectにチケットNoがないので、チケットが登録されない。
 顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを、一つのチケットでまとめたい場合がある。
(5)ステータス変更し忘れる。
 忘れた頃に、終了チケットへ返信メールが追加されるが誰も気づかない。
(6)発信元アドレスがチケットに記録されない。
 メールによるRedmineチケット登録機能では、匿名ユーザとしてチケット登録されるため、メール送信者(顧客)の情報がチケットに残らない。

上記の課題のうち、手運用でカバーせざるをえないのは、(1)(3)(5)だろう。
(2)は、Redmine画面上で返信メールを送信できる機能をプラグインで作るべきかもしれない。

そのうち、(4)と(6)の解決策について、考えてみた。

【2】サポートデスクからの送信メールと顧客からの受信メールで、同一のチケット番号を振るようにするプラグインを@yusuke_kokuboさんが公開されている。

Redmine Mail Intergration plugin - こくぼ@Everything is the experience.

(引用開始)
◆背景
Redmineにはチケットが更新されたときなどにメールで通知してくれる機能があります。さらにその通知メールに返信することで注記を書けたりします。
さらには、Redmineのメールアドレスを宛先に含めておくだけでRedmineがメールを受信してチケットにできる機能もあります。
いろいろ便利な機能がそろっているのですが、うちの会社の使い方ではちょっと痒いところに手が届きません。

◆なにに困ってるの
マネージャ「お客さんからこんなこと頼まれたんだけど、Aさんこの作業お願い!」
とお客さんからの依頼をAさんのメールアドレス宛にRedmineのメールアドレスをCCに入れて転送しました。*1
Redmineはメールを受信してチケットに起こして通知メールを投げます(投げったっけ?)。

◆Aさんが受け取ったメール
この時点でAさんはマネージャからのメールとRedmineからの通知メールを受け取っています。
AさんがRedmineからの通知メールに返信すればRedmineは注記として処理できます。しかし元々のマネージャからのメールに返信すると、Redmineは返信元のチケットを特定できないので、新たにチケットを作成してしまうのです。注記にできないどころか無駄なチケットが作られてしまいます。困りました。

◆そこで作ったプラグイン
Redmineがメール受信したときにメールのMessageIDと処理したチケットNoを覚えておくプラグインを作りました。
この場合でいうと、最初にマネージャが投げたメールを処理したときにMessageIDとチケットNoをDBに保存します。
そしてAさんからの返信を受信したときに、メールのin-reply-toからMessageIDを検索して処理元のチケットを特定します。

◆まとめ
これでRedmineを意識できない人でもとりあえず宛先にRedmineのメールアドレスを含めておいてもらえば、チケットに履歴が残っていってハッピーになれるかもしれません。
(引用終了)

つまり、(4)顧客発信のメールによるチケットとサポート担当者が発信したメールによるチケットを一つのチケット番号でまとめる機能は、上記のプラグインで実現されている。

但し、MessageIDとチケットNo、ユーザ名を保持する新規テーブルが1個増えるので注意。
また、GitHubのemail.rakeを見ると最新版よりも古いので、パッチを当てるなどの動作検証が必要と思う。
だから、すぐに上記のプラグインですぐに解決できるとは限らないのが残念だ。

YusukeKokubo/redmine_mail_intergration

redmine_mail_intergration/lib/tasks/email.rake at master ・ YusukeKokubo/redmine_mail_intergration

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

上記のプラグインの機能をRedmine本家に取り込んでもらえないのだろうか?

【3】(6)発信元アドレスがチケットに記録されない課題については、RedmineはCRMソフトとして使えるか?: プログラマの思索にも書いたけれども、顧客問合せメールからRedmineチケット登録時に、顧客を新規ユーザとして登録する機能を使う方法もある。

メールからチケット登録する場合のRedmineのオプションはRedmine本家のWikiに書かれている。

RedmineReceivingEmails - Redmine

Redmineのソースemail.rakeを読むと、下記のオプションがある。

svn.redmine.org/redmine/trunk/lib/tasks/email.rake

(引用開始)
General options:
unknown_user=ACTION how to handle emails from an unknown user
ACTION can be one of the following values:
ignore: email is ignored (default)
accept: accept as anonymous user
create: create a user account
no_permission_check=1 disable permission checking when receiving
the email
no_account_notice=1 disable new user account notification
default_group=foo,bar adds created user to foo and bar groups
(引用終了)

つまり、「unknown_user=create」オプションを追加すれば、Redmineのユーザーが作成されるのでメールアドレスを保持できる。
さらに、「default_group」オプションを追加すれば、作成されたRedmineユーザのユーザグループまで設定が可能だ。

従って、あらかじめ顧客ユーザだけを含むユーザグループ「顧客」を作っておき、顧客問合せメールからRedmineチケット登録時に、顧客をRedmineユーザとして新規登録するだけでなく、新規Redmineユーザとして「顧客」ユーザグループに属するようにオプションを使えばいい。

つまり、Redmineのユーザグループ=取引先企業、ユーザ=企業の担当者としてマッピングすれば、「企業◇--担当者」の関係を実現することができる。

例えば、外部サーバーからメールサーバーへIMAPで問合せメールを検知する場合、下記のようなrakeコマンドになるだろう。

#supportプロジェクトにbugトラッカーでチケット登録し、ユーザは顧客のメールアドレスで新規登録する。
#さらに、新規ユーザは、fooユーザグループに属する。

rake redmine:email:receive_imap RAILS_ENV="production" \\
host=imap.foo.bar username=redmine@somenet.foo password=xxx ssl=1 \\
project=support \\
tracker=bug \\
unknown_user=create \\
no_permission_check=1 \\
default_group=foo \\
allow_override=tracker,priority

但し、TO・Ccアドレス、Subjectの情報はチケットに登録してくれない問題はまだ残る。
Redmine本家に対する今後の改善要望となるだろう。

【3】「メールからRedmineのチケットを自動登録する」機能に注目する理由は、メール駆動の業務をチケット管理へ置換できる可能性を感じるからだ。
普通の社会人ならば、毎日数十~数百通のメールを受け取って、その返信に追われていないだろうか?
実際の仕事は、顧客からの問い合わせメールやシステムの障害検知メールなどが起点となって始まる場合が多い。
すると、メールの履歴を追いかけながら仕事せざるを得ず、メールという古い機能に縛られた流れでしか仕事できない。

メール駆動の仕事の弱点は下記に書いた。
メール駆動はExcel駆動と同様に、何らかの解決策が必要ではないだろうか?

メール駆動開発は時代遅れではないか: プログラマの思索

管理のためのExcelをチケット管理が駆逐しているように、外部とのやり取りはメールというインターフェイスで行っていたとしても、社内ではチケット管理で回せる仕組みが作れないか?
今後も考えてみる。

【追記】@sakaba37さんが、(1)(3)(5)の問題点に対し、返信メールを受け取る時に「ステータス=New(新規)」でチケット更新すればよいのではないか、と提案されている。
新規ステータスならば、問合せタスクが終了していないので、必ず対応状況のチェックで引っかかるから、現実的な解決策になると思う。
rakeコマンドにstatus=newをセットすればいいので実装は問題ない。

但し、rakeコマンドではデータをロードできないため、結局はシェルスクリプトでメールのヘッダ情報を取得する処理を作りこむしか無い。
From・To・Ccアドレスをrakeコマンドだけでチケットに表示できない課題はまだ残る。

[#Redmine] Redmineによるメール対応管理 - 第8回 #RxTstudy -: ソフトウェアさかば

(引用開始)
さて、前田さんの発表で課題とされていたものに、チケット番号が間違っているものや、クローズしたものの場合がありましたが、これは、関連チケットのステータスをnewか適当なものにすれば良いと思います。
ステータスを変える方法には色々あると思いますが、メールハンドラーを修正しなくてもメールの最後に「Status: New」という行を追加するフィルタのスクリプトを、メールハンドラの前にかませれば良いと思います。
こうすると、クローズされていないメールを管理するだけで、番号違いなども拾う事ができるでしょう。
(引用終了)

svn.redmine.org/redmine/trunk/lib/tasks/email.rakeを読むと、statusのオプションがあるので、実現可能だ。

(引用開始)
Issue attributes control options:
project=PROJECT identifier of the target project
status=STATUS name of the target status
tracker=TRACKER name of the target tracker
category=CATEGORY name of the target category
priority=PRIORITY name of the target priority
allow_override=ATTRS allow email content to override attributes
specified by previous options
ATTRS is a comma separated list of attributes
(引用終了)

【追記2】
@sakaba37さんが上記の課題に対して、幾つかの方法を試されている。

[#Redmine] Redmineによるメール対応管理(その2) - 検証編 -: ソフトウェアさかば

| | コメント (0)

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