« 2006年06月 | メイン

2006年07月31日

アジャイルソフトウェアマネジメントを考える - その

ですから、ここまでの結論をまとめますと、

アジャイルソフトウェア開発方法論は、

.愁侫肇ΕД∪源佐浜の経験的(エンピリカル)なアプローチである。

経験的(エンピリカル)アプローチは、必ずしも無秩序というわけではなく
 計画し、見積りをすることができる。

(説明を省略していますが)創発という特性と適応性のある振る舞いを
 示す複雑適応系である。

そして、アジャイルソフトウェア生産システムによる、望ましい適応性のある
振る舞いとは、”顧客にとって価値がある正常に機能するコード
で示されるのです。

2006年07月30日

アジャイルソフトウェアマネジメントを考える - その

さらに先に進めることにしたいと思います。

ここまでの主張は、ソフトウェア開発は不確実性が大きいがコントロールできない
ものではないということでした。

つまりソフトウェアは発散せず、計画し、コントロールすることができるということです。

書籍「アジャイルソフトウェアマネジメント」は、”成長するあり塚”の
例をあげています。

例えば、ありの巣からあり塚が構築されることは予測可能である。

あり塚とあり塚がカバーする領域の大きさは、ありの種類とその規模に
ついての知識に基づいて、ある確実性をもって予測が可能である。

予測することができないものは、正確な形、正確な完成時t期、あるいは
必要なリソースのレベルである。

しかしあり塚の成長が天候の予測に似ているとすれば、それはある程度の
正確さで予測可能なことである。

つまりそれは無秩序ではないのである。

2006年07月29日

アジャイルソフトウェアマネジメントを考える - その

ソフトウェア開発の生産性と品質の革新をどのように達成することが可能であるのか?

書籍「アジャイルソフトウェアマネジメント」から、その実践プラクティスのヒントを探ろう
というこのコーナー。

お久しぶりです。前回の記事は七夕の7月7日でしたから、三週間+αぶりですね。

もう随分以前の記事ですから、なにを主張していたのか、古い記憶を呼びさましてみると

製造業の科学をソフトウェア開発に適用することによって、不確実性が極めて大きい
ソフトウェア開発においても、結果を予測し、効果を測定することができるようになること。

そのスタートポイントとして、ソフトウェア開発というものは、人のアイディアを
ソフトウェアというプロダクトに変換するプロセスであるととらえ、この人の
アイディア、すなわちソフトウェアに対する要求を、ソフトウェア生産システムの、
ソフトウェアというプロダクトに変換すべき”インベントリ(在庫)”として扱うということを
述べました。

とすれば「ソフトウェア開発というビジネスの収益性を、インベントリの削減
によって改善することを予測できるようになる
」ということになります。

そこで既存の組織をこの実験のベースラインを決定するために測定し、アジャイル
方法論を選択し導入した結果を測定するのです。

そこでインベントリの削減と生産速度の向上を観察することができれば、これは
アジャイル方法論がソフトウェアビジネスのためにも、実際に最も優れたものである
科学的証明になるということです。

2006年07月28日

「自動化テストセミナー」第一回開催

”体系的自動化テスト”セミナー(1日コース)第1回を開催しました。

受講者の皆様方、大変お疲れ様でした。

欧米と違って、日本では、自動化テストツールを活用するための
手順やノウハウを解説するセミナーが、皆無に等しいという状況ですので
いわば”日本初”という位置づけで企画したものです。

といいますのは、ツールベンダーさんのトレーニングは、ツールそのものの
使い方が中心で、では自分たちのどのようなテストの課題が、自動化テスト
でどのように解決されるのか、その具体的な手順はなにかというセミナーが
ほとんど存在していないんですね。

その分、テキスト開発は大変でした。

弊社セミナーは、すべてエス・キュー・イー・ジャパン株式会社で
運営していますが、このセミナー・テキストは、他のコースと異なり
サイクスでいちからつくったものなんですね。

その分、受講者の方々の反応も心配していましたが、ふたをあけて
みると、役に立った、あるいは自動化テストツールでできることと
できないことを知ることができたというご意見をいただくことができました。

大変好評だったということで、ホットしております。
受講者の皆様方、大変ありがとうございました。

ちなみにアンケート結果ですが:

内容:      平均4.1点
インストラクタ: 平均4.3点
テキスト:    平均3.9点

ということで、とりあえず、インストラクタ(私です)は、”オー人事”
しないで良さそうです(笑)しかしテキストは改善が必要そうです。

受講者の方々のさらなる関心ごととして、以下のようなものがありました。

★自動化にとらわれず、テストの一般的な講義があれば受けたい。

 はい、こちらは私どものメインメニューで、「体系的ソフトウェアテスト」
 シリーズがあります。サイクスまたはエス・キュー・イー・ジャパン
 ホームページをご参照ください。

★自動化テストシステム導入に関する要求分析のこと。

 この入門コースでは、基本的なポイントだけ解説した部分ですね。
 自動化テスト導入にあたっては、テストプロセスの課題分析(AS-IS分析)、
 どの課題を自動化で解決するかの目的の明確化と目標設定(TO-BE設定)
 このギャップをどのように埋めるかのシステム設計が重要です。

 この部分は、どちらかというと、「体系的ソフトウェアテスト」セミナーで
 扱っているような、テストプロセス改善のトピックスになってきます。

 なににせよ、テストプロセス改善の結果の一部としての、自動化テストの
 活用、そのような視点が必要になるところかと思います。

★構成管理

  自動化テストスクリプトの保守性を考える上でも、構成管理は重要です。

  構成管理のセミナーは計画していませんが、9/1(予定)で、
  「(仮)実践!ソフトウェア構成管理パターン」の翻訳出版が計画されて
  いますので、ご参考にしていただければと思います。

★自動スクリプトの運用方法

  アドバンスなトピックスとして入門コースでは扱いませんでしたが、
  再利用性を考慮した自動スクリプトの運用方法の取得は、自動化テスト
  の本格導入にあたっては、欠かすことができません。

  このセミナーも計画がありませんが、技術レポートの発行などを計画
  しても良いかもしれません。ご要望があるようであれば、ご連絡ください。

★現場の人間の説得方法

  セミナーで強調したポイントですね。

  表面的にどのように見えても、すべては人の問題である。

  ファシリテーションあるいはコーチングの課題とみることもできます。
  ここらへんは優れた書籍も多くありますので、ご関心あれば書店を
  のぞいてみると良いかもしれません。

改めて、ご受講ありがとうございます。

2006年07月27日

生きてるだけで丸儲け

有名なお話ですが、明石家さんまさんの娘さんの名前は”いまる”さんだとか。

そしてこのお名前は、”生きてるだけで丸儲け”から命名したものだとか。

すばらしい言葉です。

人間、丸裸で生まれたんだから、服を着てるというだけで、丸儲けなんだとか。

考えてみると、この豊かな日本で生まれたということ自身が、丸儲けかもしれません。

なにをやったって、食べていけないということはないんですから。

でも人は、なぜ時には絶望するのでしょう。

生まれたときは丸裸なのに、生きていく中で、愛とかお金とか

失うことができないと思うものがどんどんできていくからなのでしょう。

そして、実際に失ってしまって、絶望するのでしょう。

そうやって思うと、人というは罪深い存在なのかもしれません。

人生、生きてるだけで丸儲け。

このように解き放たれることができれば、人はほんとうに幸せなのかも

しれませんね。

2006年07月26日

マーキュリーをHPが買収

とある方から届いたメール。

なんとテストツールベンダーの”マーキュリー(インタラクティブ)”を
HPが買収。

いやぁ、IBMがRationalを買収したような感じですねぇ、と感想を
漏らしましたら、”柳の下のドジョウ狙いでしょう”とのお言葉。

Rationalにしてもそうですが、ツールベンダーにITベンダー色が
つくと、なにかとやりにくい気がするのですが、さてこの買収の
行方やいかん!?

しかし米国のマーキュリーはキャッシュリッチの優良企業ですから
HP社による財務政策の観点からの株主対策だったりして・・・

というのはうがった見方かもしれません(笑)

ちょっとライブドア事件に毒されているかもしれませんね。

2006年07月25日

今度は"2007年問題をぶっとばせ”なんですね

昨日、日経BP社の”2007年問題を再考する”に意見をとりあげて
いただいたという日記を書きましたが、日経コンピュータ2006.7.24号の
特集は"2007年問題をぶっとばせ”なんですね。

なんとトヨタの経営の基幹といっても過言ではないであろう
”部品表データベース(いわゆるBOMですよね)”を再構築
するという革新的なプロジェクト。

トヨタは「難易度の高いシステム構築プロジェクトは、次世代を担う
IT人材の育成に格好の場」とおっしゃっておられます。

そのとおりですね。

2006年07月24日

2007年問題を再考する

日経BP社の谷島さまが、長年取り組んでおられるテーマですが、
日経BP社のWEBサイト「経営とIT新潮流」で、改めてピックアップ
されるとのこと。

その第一回目の記事として、不詳、わたくしの意見を取り上げていただきました。
私はこう考える:第1回:若手にゆだねるべきプロジェクト

谷島さまの手にかかると、まるで私ではない誰かが言っているような
立派な意見に仕上がるものですね。

しかしこの記事で述べているように、真水投資を阻害する不良資産化
したITを活性化しなければ、世界競争に取り残されるばかりか、
存続の危機すらも招く時代になったと私は真剣に思うわけです。

そして2007年問題によるベテランの大量引退は、その問題に拍車を
かけることはあれ、手をこまねいていては、状況の好転を望むことは
決してできないと断定すべきでしょう。

この問題を、経営の観点から眺めれば、経営品質に関わる問題と
考えることもできるわけです。

つまり、「勝ち残る・オンリーワンになる」ための経営戦略・ビジネス
モデルからみて、その重要基盤としての情報戦略をどう確立するかと
いう、勝つための”経営品質”という観点。

もうひとつは、不良品質を持つIT資産のバグを削除する、つまり
活性化するための、守るための”経営品質”という観点。

この記事は、守るためのIT資産の品質を改革するという観点を
中心に意見を述べていますが、とどのつまりは、「ひとは石垣、
ひとは城」にしかほかなりません。

ITの開発運用も人しだい、企業というシステムの開発運用も人しだい、
2007年問題で引退するベテランの穴を埋める人材の育成を
どのように達成するのか。

とどのつまり、そこに焦点を当てたいと願っての記事です。

表向きにはどのように見えても、それはすべて人の問題なのだ。

2006年07月23日

もしも女性が歴史をつくったら

本書を読んでいるわけでもないのに、書評だけをみて紹介するのは
大変失礼な気がしますが、なんと織田信長が女性だったという設定
の『女信長』という小説があるんですね!

いまどき、小説はすべてのことをやりつくしたと言われているようですが
人間の創造力は無限ですね。

おもしろいなと思ったのは、戦の論理が女性の論理で動いたら・・・と
いう仮説のもとにこの小説が展開されている点です。

本書を読んでませんから、書評を受け売りすると、

たとえば桶狭間。

出撃を命じる信長に重臣達は
”我らにとっては一族郎党。妻子の命運がかかっております。”
と言う。

そして女信長は自問自答する。
男は退路を断たれて心を圧迫され続ければ、積極果敢に生きられない。
女は自由だ。
誰かを守らなければならないという心の枷がないからだと。

え、そうだったんですか?という感じです。

そうやって考えると、男性は精神的に脆い生き物ですね。
かといって、守るものがなくても強く生きられない。
男性の方が、なんのために頑張るのかという理由を必要としている
気がします。
そしてその理由を失ってしまえば・・・

それにしても、こんなことにやっと気付くなんて、私は小説家には
なれそうもありません。

2006年07月22日

今日はオフです

なぜならば私の誕生日だからです(笑)
だからほんとのほんとにきょうは日記です(再・笑)

かといって、この歳になって誰かがお祝いしてくれるわけでもないので、
好きだったCDでもかけて、楽しかったことでも思い出すことにしましょう。

ということで、古いCDをあさっていたら出てきました”今井美樹"

"A PLACE IN THE SUN"

何年頃でしょう。このCDの代表曲が"Miss You"ですね。

作詞が岩里祐穂さん、作曲が、そうです、あの布袋です。
う〜ん、マスコミを騒がしていたころだなぁ。

でも今井美樹は、この作詞家と組んだ頃から大ブレークした記憶があります。

綺麗な詩を書く人ですね。

でも"Pride"もそうかな、っておもったら、なんと作詞・作曲 布袋なんですね。
ちょっとびっくりです。

ともあれ・・・

Miss You
作詞:岩里祐穂

夢のような気持ちになる
愛しさの中で私を包むあなたの瞳

帰れなくて星の夜に二人で何度も
遠回りした いつもの坂道を

I Miss You
思い出は輝く
失った季節の中で

I Miss You
あなたこそ 心の
眩しさのすべてだった

どうして終わらせたのだろう
あんなに愛して確かめ合った二人の日々を

これほど苦しい時間が待っている事も
私はきっと全部わかっていた

I Miss You
もう二度と会えない
たとえ何が起きようとも

I Miss You
ここに来て もう一度
あの日のように抱きしめてよ

2006年07月21日

どっぷりリスクベーステスト

いやぁ、二日間どっぷりとリスクベーステストにつかりました。

といいますか、よくしゃべりました。
終日、二日間にわたってリスクベーステストについて、しゃべりつづけました。

機会をくださったTH企画セミナーセンターさま、SRCさま、
大変ありがとうございました。

インベントリと呼ばれるテクニックを使って、テスト対象の全体を俯瞰しながら
詳細項目をリスト化して、それに対してリスク評価を導入することで、厳しい
テストリソースの制約と戦いながら、重大なバグの漏れを防ぐという考え方は
幸いにもみなさまのご賛同を頂いたようです。

なんでも最近にない高評価のセミナーだったとか。

いつも思いますが、お役に立ててなによりです。

少しでも現場の苦悩の解消に貢献できればと思います。

2006年07月20日

ユーザ主導の要件定義

情報システム開発における要件定義はITベンダーがやるもの。
なぜならばユーザにITはわからないから。

※ここで言うユーザは、IT部門の人のことではなく、エンドユーザさんのことです。

これってどれくらいの人が常識だと思っていて、どれくらいの人が
非常識だと思っているのでしょうか。

だれかアンケートをとった人はいないのでしょうか。

逆の言い方をすると・・・

情報システム開発における要件定義はユーザがやるもの。
なぜならばITベンダーはユーザほどには業務を理解していない(ことが多い)から。

どちらが健康な意見だと思いますか?

なにはともあれ、自分が満足できる情報システムを手にするためには
自分の要求はなにかを定義できなければならない。
自分の要求は誰よりも自分が一番良く知っている。
あるいは自分がまずは明確化する責務を負っている。

わたしはこのように、とてもシンプルに考えるのですが、もしも非常識に
聞こえるような方がいらっしゃったら、是非ご意見いただけないでしょうか。

私のメールアドレスはこちら

2006年07月19日

リスクベーステスト

明日からSRCさまとTH企画センターさまで、「リスクベーステスト」を
テーマとしたセミナーの講師をそれぞれ1日ずつつとめます。

そういえば、同じテーマで、別のセミナー運営会社さまからも
講師依頼を受けました。

先日のJavaWorldでの講演もやはり「リスクベーステスト」をテーマとした
ものでしたし、もしかするとちょっとしたプチ・ブームかもしれません。

といいますか、2004年10月に監訳した書籍「体系的ソフトウェアテスト入門」の
原題は "Systematic Software Testing"ですが、副題は "Risk Based Test"
アプローチなんですよね。

さらに遡ると、弊社が最初に導入した ISTQB 社のテストプロセス TMAPも、
Rex Blackのテストプロセスも、み〜んな Risk Based Testアプローチなんですよ。

つまり、テストというのはそもそも Risk Based Testアプローチ。なぜならば
最近のテストの定義は、テスト対象システムの品質リスクを測定すること、
だからなんですよね。

でも何故今になってわざわざ”リスクベーステスト”を取り上げるのか。

それは品質保証やテストの取り組みが予防的になってきたからなんですね。

昔のテストの定義は、障害をみつけるつもりでプログラムを実行する過程。
つまりバグをみつけたら除去するというデバッグに近い行為。
処置のパラダイムといっても良いでしょう。

でも今のテストの定義は、予防的な品質の測定というアクティビティ。

なぜならば、予防的に品質の測定をして、手間がかからないうちに欠陥を
除去するというプロセスに変えていかないと、ただでさえ複雑になった
ソフトウェアのテストも間に合わない、ひいては品質管理もうまくいかないと
いうことなんですね。

ですから予防的にテスト対象をリスク評価して、評価値が高いものに
テストのフォーカスを当てるリスクベーステスト。

テストの工数や期間の制約が極めて厳しい現在、テストひとつをとっても
重要なものにフォーカスを当てたい。

重要なものが何であるかがわかることが最も重要なのだ。
                      スティーブ・コビー

2006年07月18日

ほぼ日手帳語録・その

なんとなく心に留まった”ほぼ日手帳”語録から:

何かのかたちで区切りをつけないと
いつまで別れを惜しんでいればいいのかわからないから、
花を飾ったり、香を焚いたり、服装を変えたり、歌を歌ったり、
特別な言葉を唱えたりして、
「ここまでにしておきましょう」とするわけだ、たぶん。
区切りとか儀式とかって、実は大事なんです。
               <「今日のダーリン」より>

それはわかっているんだけど、どうしても区切りを
つけられないものってありますよね。

それは区切りをつけられないんじゃなくて、どうしても
つけたくないんですよね。

そういうものに対する儀式って何が良いのでしょう。

こんなとき、マイ・ドラエモンが居てくれればと思いますが
これって甘えでしょうか(笑)

※そういえばドラエモンの声が変わっていてびっくりしました。

2006年07月17日

このごろのマイブーム

すでに締め切りを過ぎてしまったテキスト原稿を2冊も抱えながら、
ということはお怒りに近いお二人の大切なパートナーの方々の
顔が思い浮かびながら、でも三連休の合い間だということで、
フィットネスセンターに行ってきました。

手元の”ほぼ日手帳”の記録を見ると、4/1には体重が78.0Kg,
体脂肪率22.9%(うわぁ)、BMI24.3(うわぁ)、ウェストは85cmを
ゆうに超えてましたから、メタボリックシンドロームの疑い濃厚!
といいますか、成人病まっしぐらですよね。

したがってダイエットとなるのですが、ダイエットというのは
やってみると結構難しいものなのですね。

私の1日当たりの適正消費カロリーは通常2,300Kcal。
脂肪1gが燃えるのに9Kcalですから、脂肪1Kgを減らすのに
9,000Kcalをなんらかの手段で減らすことが必要。

ですから1日あたりの摂取カロリーを300Kcal, つまり
1日あたり2,000Kcalに抑えれば、ほぼ1か月で脂肪1Kg
くらい減る計算になるのですが、そうは問屋がおろさじ!!

なぜならば私はおいしいものを食べるものが好き。
生きがいと言ってもいいでしょう。
よって朝食しっかり食べる。
お昼も食べる。
夜ももちろん食べる。
そしてお酒も大好き。

ですから摂取カロリーを記録しはじめてびっくり。
朝食をしっかり食べてお昼にとんかつ定食など食べた
日には、昼までに2,000Kcal超ではないですか!

ちなみに私は平均して3,000Kcal超を摂取していたのですよ。
つまり1か月あたり、700Kcal×30日 / 9Kcal = 2.3Kg超の
脂肪をムダに蓄えている!!

食事はやめられない。
でもやせたい。
そもそもこのまま放置しておいたら、命にかかわる。

そうです。ですからフィットネスセンターです。

でもフィットネスをはじめてからさらにわかったことは、
単純に運動をしていれば痩せるわけでもないってことです。

そもそも食事制限でダイエットという戦略は最悪の選択
らしいのですね。言い訳ではなく。

というのは、やせる対象は、脂肪と筋肉。
そして脂肪は筋肉よりも減りにくい。
したがって食事制限をしたら、筋肉から減っていく。
脂肪ではなく。
そのうえ、リバウンドがきた日には、脂肪だけが増えていく。

この理屈は運動でも同じで、下手に運動すると、筋肉だけが
消費されていくことにもなりかねないんですね。

やせるためには
\歇茱ロリーを適正量に抑える。でも必要なものはちゃんととる。
筋肉を増やして基礎代謝量を上げる。
M酸素運動(エアロビクス)で、脂肪を効率的に燃やす。
ということがわかったのですが、この3つのバランスをとることが
難しい、難しい・・・

結果、筋肉量の低下を抑えることはできなかったのですが、
2か月で体重が71.5Kg、体脂肪率 18%弱まで落としたのですね。
あ〜、大変だった。

で現在は・・・

しっかり体重74Kgです(笑)

考えてみるとこのラインに居ることが多いんですね。

人間というのは、コンフォトゾーンというのがあって
体重にしてもなんにしても、その範囲に居ると安心できる
領域というのがあるらしいですよ。

でも有酸素運動は変わらずマイブームです。
1日に1度は汗を流すと仕事の調子もいいんですよね。

ということで、どうも原稿を待たせている方々、失礼しました。
能率があがったので、ようやく書きあがりました!!

2006年07月16日

戦略の本質

野中郁次朗氏等による書籍「失敗の本質(日本軍の組織論的研究)」と
くれば、その続編とでも言うべき「戦略の本質」ということになるでしょうか。

本書によると、実は第二次大戦時の日本軍は、緒戦で予想以上の
大戦果をあげているんですね。

それは日本軍が「優れた兵器を開発していた」からであり、「周到な
計画と訓練を積み重ねた日本海軍の作戦遂行能力のレベルが
高かったから
」であるということなんですね。

しかしなぜ差をつけられたまま、逆転することができずに、敗戦を迎えたのでしょう。

例えば、日本海軍の潜水艦は技術的に優れたいたが、日本軍では艦隊決戦の
補助兵力とされていたために、それ以外の目的にあまり運用されなかったようです。

一方、アメリカ海軍の潜水艦は技術的には不備が目立ったが、やがて通商破壊戦に
用いられるに及んで、巨大な戦果を挙げたとのことです。

それに対して、日本海軍はそうした戦い方の重大性になかなか思い至らなかった
ために、海上護衛戦の立ち遅れが、もともと資源・生産力の差を、さらに拡大する
結果となったということでしょうか。

結果、野中氏等は、「日本海軍は自ら描いたシナリオどおりに敵が動くものと
考えていたのではないだろうか。」
としています。

戦略とは、不確実性が高く、不安定かつ流動的な状況であっても、
目的に照らし合わせて、最大の成果を得るための全体的な仕組みと
でも定義できるでしょうか。

したがって、当然目には見えないわけですし、そこには戦略の本質を追求した
思考のプロセスの結果がうめこまれているわけです。

やはり現代の不確実性が極めて高いソフトウェア開発においてこそ
重要な教訓が秘められているように思います。もっといえば、ビジネスに
勝ち抜くための情報戦略のシナリオを描くうえにおいて、さらに貴重な
教訓となりうるということでしょうか。

自ら描いたシナリオどおりにものごとが動いた時代は良かったわけです。
モノをつくれば売れた時代。サービスを提供すれば売れた時代。

はてさて、戦略の本質を追求することが極めて重要な時代に私たちは
居る、そのように思うのですが、いかがでしょうか。

2006年07月15日

失敗の本質

最近、PMBOKのようないわゆる欧米流のマネジメント論が
日本のソフトウェア開発の現場に適合するかどうかについて
いくつかの視点からお話する機会がありました。

そこでふと思い出したのが、野中郁次朗氏等による書籍
「失敗の本質(日本軍の組織論的研究)」です。

いわく、

軍隊とは、近代的組織、すなわち合理的・階層的官僚組織の
最も代表的なものである。
・・・・・
(しかし)日本軍には本来の合理的組織となじまない特性が
あり、それが組織的欠陥となって、大東亜戦争ですの失敗を
導いたとみることができる。
・・・・・
平時において、不確実性が相対的に低く、安定した状況の
もとでは、日本軍の組織はほぼ有効に機能していたと
みなされよう。
・・・・・
しかし問題は危機において、どうであったか、ということである。
危機、すなわち不確実性が高く不安定かつ流動的な状況で
日本軍は有効に機能しえず、さまざまな組織的欠陥を露呈
した。

私はソフトウェア開発組織と、軍隊を直接比較することには
心理的な抵抗が強いと思いながらも、しかしいずれも合理性を
求められる組織という意味においては、共通していると思うの
ですね。

さらに現在のソフトウェア開発組織は、極めて不確実性が高く
不安定かつ流動的な状況におかれているし、その複雑な状況
のマネジメントに積極的にとりくんでいないという感覚があります。

またこの書籍はさらに続けます。

戦闘は錯誤の連続であり、より少なく誤りをおかしたほうに
より好ましい帰結をもたらすといわれる。

作戦計画の立案とその達成過程において、どちらがより錯誤が
少ないかと言うことがポイントなのです。

2006年07月14日

速報です!!第一回「はじめて学ぶ要件定義入門コース」

本日はSQE Japan主催のセミナー「よくわかる要件定義入門コース(1日)」第一回です。

講師はあの匠システムアーキテクツ前田さん。

米国ProcessImpact社Karl Wiegers氏のコンテンツをベースに、前田さんに大幅拡張いただいたテキストを使って、前田さん自ら講師を・・・

さすがです。前田さん。

相変わらずの前田節ですね。

直前までテキスト作成までお願いしておられたのは大変恐縮でしたが、大変有用なコースでした。

それにしてもうっかり見逃していましたが、Karl Wiegers氏も言っているんですね。

要求を適正に獲得できなければ、プロジェクトの後半をいかにうまくやるかはどうでも良い。

どうでも良いということは決してありませんが、要はそういうことだろうと思うこのごろです。

2006年07月13日

実況中継です

とあるツールベンダーさんの勉強会の現場からの実況中継です。

デバッグ工学で著名な松尾谷先生が、今日はテストの先生ではなくて
モチベーション教育の講義・演習を進めておられます。

おもしろいですね。

PMBOKのようなトップダウンのプロジェクトマネジメントが
日本の文化に合わないということは以前から感じておりましたし
一方でシステム開発にはトップダウンの要素も融合しないと
そろそろうまくいかないという壁にぶつかっているような気が
しますので、ボトムアップの良さを生かしながら、どうやって
トップダウンのマネジメントを統合するかという点に関して、
課題意識を持っておりました。

しかし日本のシステム開発の現場は、土方の親方が
すりっぱで頭をはたきながら、この親方のためにはいっちょ
がんばろうという気にどうさせるのかなのだから、その中で
チームビルディングをどうやって成立させるのかという課題と
とらえるというのは、すごい割り切りでおもしろいですね。

そういった意味では、製造業の規範が成り立ちにくい世界だと
いうことになりますが、一方で欧米でもソフトウェア開発の世界に
製造業の規範が導入されてきたのは最近のことだと感じて
いますので、あるところでは世界共通の課題かもしれないなぁ、
それでもソフトウェア開発の世界に、製造業の規範を導入すべき
ではないのかなぁ、と考えているところです。

では製造業の規範をどうやって導入すべきか。
プロセスの改善というよりかは、工程ごとの成果物、プロダクトの
定義を明確にして、その定義した成果物にむかって集中していく、
それにつきるのではないだろうかと思います。

ソフトウェアは目にみえない、でもそれが成果物の定義ができない
ということにはつながらない・・・

最近の成功事例はそれを実証していると思うのですね。

2006年07月12日

JUAS主催「テスト」セミナー開催!!

昨日、7/11(火)にJUAS主催の
「情報システムユーザによるテスト改革へのガイド」
で講演しました。

60名の受講者の方のご出席ということで、大盛況!!

私もおもわず力が入ります。

060711 juas_photo2.jpg

アジェンダは以下のとおりでした。
-------------------------------------------------------------
■品質向上のためにテストを要件定義段階から意識した方法・取り組み事例

丸文情報通信株式会社 吉田専務取締役さまによる、テスト業務改革の歴史と
成果についてのご講演。

事前打合せをしたわけでもないのに、主張の文脈が私の受け持ちパートと
ぴったり一致。すごいですね。感銘を受けました。やはり行き着くところは
同じところ。

テスト改革は要求品質改革から!!
これなしに、テストの実行工程を語ることはできません。
これにつきますね。
------------------------------------------------------------
■ベンダーと成功させる重大なバグを予防し漏れがないテスト工程

私の受け持ちパートです(笑)。
いつもながら、みなさまのご感想は気になります。
とりあえず体裁は整えたというところでしょうか。

あとでJUASさまにお聞きしましたら、好評だったとのこと。
お役に立ててなによりです。
--------------------------------------------------------
■カットオーバーの日、定時に帰る具体的方法

JUAS細川専務理事さまによるご講演。

ユーザ観点からの業務アプリケーションの生産性・品質メトリクスに
ついては、JUASさまのメトリクスデータに限りますね。

もしかして、日本のCapers Jonesかもしれません。

私もいつも活用させていただいてます。
----------------------------------------------------

ユーザ企業:ITベンダー = 2:1 という感じのセミナーでした。
ユーザ企業にも、品質に関する問題意識盛り上がりの気運が・・・
というよりかは、どうにもほっておけなくなってきたという気運が・・・

ますますお仕事に励んでいこうという気になったセミナーでした。
JUASさま、いろいろ勉強させていただきました。
貴重な機会、ありがとうございます。

2006年07月11日

新ラインアップ・ラッシュです

さっき、この日記を書いたばかりのような気がしますし、
しかもまったく同じ格好をしているのは何故?と思いますが、
もう翌日になってしまったので、日記を書くことにしましょう。

ところでサイクスが提供しているセミナーはすべてをSQE Japanに
運営委託ということですが、ここにきてそのセミナーの新ラインアップが
相次いでいます。

もともとテスト関連は、米国SQE社のコンテンツをデリバリして
いましたが、セミナー運営のフィードバックから、カスタマイズ
してかなりオリジナル色がでてきたものや、完全オリジナル
コンテンツまでラインアップが増加しています。

さらに要求エンジニアリングに力を入れるということで、米国
Karl Wiegers氏との提携、さらに匠システムアーキテクツ前田さんの、
ソフトウェア・プロダクトライン/ソフトウェア・ジャストインタイムまで、
なかなかの充実ぶりです。

これはちゃんと中味のよさをお伝えせねばということで、サイクス/
SQE Japanとも、ホームページ、カタログの改訂に力を入れて
行きますので、ご関心ある方は資料請求してくださいね。

2006年07月10日

レポート「テストに困らないために一番大切なこと」フォローアップ

大急ぎで作成しなければならない資料があって、日記を
書くのがこんな時間になってしまいました。

大体、朝一番に書くことにしているのですが、ずっと机に
座りきりになっているので、朝一番がいつなのか、よく
わかりません。

そもそも今日は何曜日だったかなぁ、火曜日だったかなぁ、と
思ったら、月曜日じゃありませんか。

「折れない心」の中村天風さんじゃありませんが、「人生これで
いいのか」じゃなくて「なんて人生充実しているんだ」と思う
ことにしましょう。

さて先日発送のレポート「テストに困らないために一番大切なこと」
は、ある意図を持って書いたレポートですが、かなりエッセー風に
書きましたので、なんとなくもやっと受け止められた感じがあります。

しかし、「では具体的なソリューションは?」と質問いただいた方が
何名かいらっしゃいまして、「私の期待どおりにレスポンスいただいて
感謝です」ということなのですが、肝心の具体的なソリューションに
ついてもう少し踏み込んだレポートが期待されているという感じです。

セミナーを聞きに来てくださいね、と言いたいところですが、やはり
もう少し拡張して、冊子にした方が良いかなぁ、と思っています。

ところで、いつ冊子をつくりましょう。それがとりあえず、私が
困っている一番大切なこと・・・かな。

2006年07月09日

IT業界の「品格」

昨日に引き続いて、IT業界の「品格」についての考察。

TOC(制約条件理論)で有名な、ゴールドラット氏は言いました。

「あなたがどのように私を測定するかを私に教えてください。
 そうすれば、私はどのように振舞うかをあなたに伝えます。」

昔、一晩にして雪印ブランドが消滅した事件にしても、
あのJR西日本の事件にしても、事例には事欠きませんが、
表面に出てくるのは、いつも現場の責任者やら、運転士さん。

たしかにモラルに欠いたことは事実ですし、それを認めることは
できないのでしょうが、事の本質は、その方々がどのように
測定されていたかということですね。

企業文化は一朝一夕にはならず。
トップの継続したメッセージこそが重要なはずと思う私です。

2006年07月08日

問われるIT業界の「品格」

日経コンピュータの2006.7.10号の特集のタイトルです。

内部統制やアカウンタビリティが喧伝されている一方で
かたや開発の手抜き、テストの手抜き、言い訳、ごまかし。

私も経験があります。

プロジェクト監査の役割を担って、現場の調査へ。

結合テストの段階ですので、実際はここが最後の砦。
なぜならば、システムテストでできることは限られている。

機能テストも十分ではないし、性能問題がどうみても危うい。
しかも対処に本質的な設計の見直しが必要なにおいがぷんぷん。

「この性能問題の本質的な根本原因分析と対策を
 今、やっておかないと、納期に重大な影響を及ぼす
 懸念があります。」
と私。

「実装が遅れているから手が回らないんだ。
 私たちはこんなに頑張っているのに、私たちの努力を認めないのか、
 あなたは。」
と逆切れ。

ほんとにある話です。といいますか、もしかすると良くある話かもしれません。

結果は・・・推してはかるべし。

2006年07月07日

アジャイルソフトウェアマネジメントを考える - その

◆ソフトウェア開発は科学のどの段階にあるのか?◆

現在、ウィークリーマガジン”Quality Software Weekly"で、ソフトウェア
パターンのトピックスを扱っています。

ところで、書籍”アジャイルソフトウェアマネジメント”にソフトウェア開発は
「科学としてどの段階にあるのか?」というトピックスが紹介されており、
ソフトウェアパターンは、ソフトウェア開発が科学の中間段階にあることを
示しているとあります。

いわく、Goldratt氏の主張として、科学には3つの進化段階がある。

フェーズ1:分類

命名法が討議され、次に合意されるフェーズ。

対象分野に何が構成要素として含まれているかを正確に討議する。
そして、要素や原則の名称について合意する。

たとえばXP,SCRUM,FDDの一部には内部命名法があるが、
統一された命名法に関するアジャイル方法論の合意は
まだなされていない。

つまりアジャイル方法論はまだ分類段階だということですね。

フェーズ2:相関関係

これは任意の方法が実際にうまくいくことを示す裏づけとなる
証拠がある場合のフェーズに対して命名したもので、パターン
認識のフェーズだ。

例えば、オブジェクト指向分析は、UMLによる命名法についての
合意で分類段階を終え、1990年代はじめのパターンの出現に
より、相関関係がはじまっているとみることができるという例示が
あります。

フェーズ3:因果関係

この段階では、理論を仮定し、結果を測定し、理論の正当性が
証明されていることを意味します。

例えば、ニュートンはなぜりんごがまっすぐに落下するのかを
証明したといったようなことです。

また製造業では過去30年にわたって多くの因果関係を解明
することによって科学の最終段階に進化してきた。

ここでも製造業の科学をソフトウェア開発に適用することに
よって、結果を予測し、効果を測定することができるように
なり、ソフトウェア開発も科学の最終段階に進化することが
できるとの示唆があります。

そして因果関係に進化させるための手段は・・・

スタートポイントとして、まずはそのソフトウェアに関する
アイディア、つまり顧客の要求を、ソフトウェア生産システムの
在庫、すなわちインベントリとして扱うという考え方から
始まるのです。

さすれば製造業の因果関係の科学を適用して、インベントリ
の削減によって収益性を全面的に改善することを
予測することが可能になる・・・

ではインベントリをどうやって構成するのか・・・

これもQuality Software Weeklyで扱っている話題です。

2006年07月06日

フラット化する世界を歓迎します

昨日はいかにも梅雨の1日で雨にたたられましたが、日本海方面では
大型ミサイルが降っていたようで、どうにも不快な1日でしたね。

最近、読み始めた本で、と言っても読んでは休み、読んでは休みでなかなか
進みませんが、「フラット化する世界」は素晴らしくおもしろいですね。

実はグローバリゼーションは、バージョン3.0の段階に入っており、
丸いと思われていた地球を平らにしてしまっていたというのですね。

今、私が使っているBLOGも含めて、パソコン、光ファイバー、インターネット、
デジタル・コンテンツの共同開発(例えばソフトウェアの開発)を可能にする
ワークフロー・ソフトウェアの発達が、個人がグローバル化する絶対的な
力を持たせたというのですね。

しかも欧米主導だった過去に較べて、バージョン3.0の時代は、あらゆる
肌の色をもった人々が活躍をしている。

そして地球上の知識中枢をすべて接続して、ひとつの全地球的な
ネットワークにまとめ、企業・コミュニティ・個人による繁栄・革新・
共同作業の素晴らしい時代の到来を招くかもしれないと論じている
のです。

素晴らしいですね。

ただし政治やテロリズムに邪魔されなければ・・・

とりあえず私がやっておくべきことは・・・英語の勉強でもしておくことにします。

2006年07月05日

パッケージソフトウェアの功罪

今朝、某新聞を読んでいましたら、非常に有名なERPパッケージの
導入サービスの広告が出ていました。

珍しくお値段が○○○円〜と書いてありましたので、つい目を止めて
しまいました。ずいぶんお安くなったものです。とは言っても、弊社で
導入できるお値段ではありませんが・・・(笑)

ところでこの類のパッケージソフトウェアの導入成功事例は少ないと
言われているようです。

なぜでしょうか?

ひとつにはパッケージソフトウェアは、カスタマイズをするようにできていない。
つまり自社の業務にパッケージを合わせるのではなく、パッケージに自社の
業務を合わせるようにできているということです。

しかし日本のお客様は必ずおおきなカスタマイズを要求するし、実際に
カスタマイズせざるをえない。しかし内部構造がそうなっていないので
見積りをはるかに超える工数がかかるし、予期しないバグがぼろぼろ
出てくる。その結果、プロジェクトが破綻するということですね。

○○億円かけた導入プロジェクトが中断なんて話も耳にしたりします。

しかし導入の目的を間違えていると、最初から失敗しているなんてことも
あるのかなぁ、と思ったりします。

何を言いたいのかといいますと、パッケージソフトウェアとは、いろんな
会社の業務のプラクティスの最大公約数。パッケージソフトウェア導入
に成功するためには、自社の業務をパッケージに合わせる、つまり
いろんな会社の業務のプラクティスの最大公約数に、自社の業務を
合わせる。ということは、いろんな会社と同じになるということですね。

他社と同じことをしていれば儲かった時代は既に終わり、他社と違う
ことをしなければ生き残れない時代になった今。

自社のコアの業務を他社に合わせてしまったら果たして・・・

教訓は、コアの業務をパッケージソフトには任せないこと、という
ことになるでしょうか。

2006年07月04日

JUASセミナーの資料をようやく書き上げました

JUASセミナーの資料をようやく書き上げました。

ふ〜、です。

先週末の作業の予定が、珍しくダウンしてしまって遅れてしまったのですが、
自己管理がなってないというお話以前に、もっと早くやっとけってことですね(笑)

やっぱりなにごとも”予防的に・・・”ですね。

ところで今回のセミナーのタイトルは、”ベンダーと協力して成功させる漏れがないテスト工程”。

珍しく”ユーザさん”の立場にたってセミナーします。

J-SOXやら内部統制やらで、"ユーザさん"も品質に関心をあて”ねばらない”
状況になってきたということでしょうか?それとも、品質問題には、とても
困っておられるということでしょうか。

セミナー会場で皆様に聞いてみたいと思います。

2006年07月03日

アジャイルソフトウェアマネジメントを考える - その

このようにソフトウェア開発においても、製造業のマネジメントの理論が適用できない理由はないし、実際に適用することで成果を獲得しているのが、アジャイルソフトウェアマネジメントです。

このソフトウェア開発にも適用できる理論とは何かと言いますと、TOC(制約条件理論)、JIT(ジャストインタイム)/TPS(トヨタプロダクションシステム)、TQM, QA, シックスシグマ、リーン生産など、聞いたことがある理論ばかりです。

ポイントはこれら知見をどのようにソフトウェア開発に適用するかということです。

ただアジャイルソフトウェアマネジメントが、既に大きな成果を獲得しているという以上は、既にこれら理論の適用のプラクティスが具体化されているということですが、現時点で実績のあるプラクティスということで言えば、私個人の判断としては、FDD(フィーチャー駆動型開発)のアプローチが最も優れた成果を獲得しているように思えます。

                                              つづく

2006年07月02日

心が折れそうになったら---その

中村天風さんの語録集「折れない心」より

たとえ力と勇気と信念をもって事物にあたっても、
不完全な成果しか得られないときがある。
それは調和を無視した結果である。

生活もそうですが、だいたい、私の仕事がうまくいかないときの
理由はこれだなぁ、と思い当たります。

コンサルタントもひと。
クライアントもひと。
パートナーもひと。

自分の提案やシナリオに思い入れやこだわりがありすぎたりと
いうときは、調和を無視することになってしまうことがあります。

思い入れやこだわりはあっても良いのですが、なにごとも
過ぎたるはなお及ばざるが如し。

2006年07月01日

メタボリックシンドロームには気をつけましょう

久しぶりに寝込んでしまいました。

どうみてもメタボリックシンドロームの兆候あり(つまりウェスト85cm以上です(笑))
だなぁということで、フィットネスに励みだして以来、久しく体調を崩すことはなかった
のですが、梅雨ばてでしょうか。

ちなみにフィットネスの先生が言うには、体重を落とすんだったら、湿度が
高い梅雨の時期がチャンスだそうですよ。

夏になって体重を落とすと、体力が落ちるからNGだそうです。さらに秋に
リバウンドが来やすいとか・・・

ところでメタボリックシンドロームって怖いですね。実は肥満症や高血圧、
高脂血症、糖尿病などの生活習慣病が、それぞれが独立した病気では
なくて、りんご型と言われる内臓脂肪型肥満が原因であるとか。

男性であれば、ウェスト85cm以上、女性であれば90cm以上であれば
疑いありということで、診断を受けた方が良いみたいですね。

IT業界は生活が不規則になりがちですし、座りきりにもなりがちですから
業界としてのメタボリックシンドローム度は高い・・・かも。

ちなみに私は、現在、82cm。ちょっとでも油断すると微妙なウェストラインですね。