メイン

2006年06月30日

早速、セミナーの結果を頂きました

Java World Day 2006のセミナーの結果を楽しみにしていますと言っていましたら、IDG社より早速頂きました。

とりあえず「リスクベーステスト」セミナーの評価は悪くないことにほっと一息。そのほか、Ajax人気が高いですね。Java World Dayだから、当然という感じですね。

全体の中でテーマとしては、Java関連、アジャイル開発方法論についての関心が高い一方、テスト/品詞保証についての関心も結構高いんですね。IDG社の方が言っておられたとおりでした。

やっぱり皆さん、困っておられるのでしょうか。今日は、「体系的ソフトウェアテスト・実践コース(2日間)」の2日目。ここしばらくの暑さで、ついうっかり寝冷えしてしまい、微熱状態ですが、今日も頑張って行きましょう。

2006年06月29日

品質に対する関心の高まり

 先日の Java World Day 2006 の「リスクベーステスト」についてのスピーチのお礼を、IDG社の方から頂きました。ご丁寧にありがとうございます。おかげさまで、スピーチは満席御礼でしたので、曰く、品質に対する関心の高まりを実感するとのこと。

 そういえば、今月号のIDG社雑誌"ITアーキテクト"の特集も品質がテーマでした。これは果たして、品質に対する関心が実際に高まっていることを意味しているんでしょうか・・・

 3〜4年前にテストについてのコンサルティングを発表したときも、某金融機関のシステム障害事件で、テストやら品質に対する関心は高かったように思います。

 ただ、もともとグローバルな競争にさらされている組み込みソフトの世界は別格として、特にビジネスシステム系は、実際の取り組みという意味では、重い腰がなかなか上がらなかったという感触がありました。

 もしかすると、今でもマジョリティはそうかもしれません。ただ構造が変わってきている面があるなぁ、とも思うのです。というのは、失敗プロジェクトの失敗コストを、ユーザ側が許容しなくなってきた側面があるように思うのです。

 失敗コストというのはいわばプロジェクトのムダのコスト。バグ除去コストがプロジェクトコストの半分を占めると言われる今、ユーザ側が許容しない以上、そのプロジェクトの最大のムダをITベンダーも黙認できなくなってきた。

 つまり余裕がなくなってきたということでしょうか。

 となれば品質やらテストに対する関心が高まらざるをえない。

 なんだ、やっぱり関心は高まっていると言うことですね。といいますか、もう見過ごすことはできなくなってきたという感じです。

 では品質に対する答えはテストか・・・・・???

 これは今、発送中の「テストに困らないために一番大切なこと」を読まれた方からの感想をお待ちしたいと思います。

2006年06月28日

ほぼ日手帳語録・その

昨日、とある用事があって、某TV局の前を通ったら、岡本太郎さんのイベントが
あるらしく、それでほぼ日手帳にあった岡本太郎さんの言葉を思い出しました。

個人差なんてないの。
人間はやろうと決意するかしないかだよ。
それだけで、差が出てくるんだよ。
            岡本太郎

もうひとつは昨日のオシム語録ではないですが
「最後まであきらめずに走る」
ことができるかどうかということもあるように思います。

2006年06月27日

オシム語録から

 最近、話題のネタに便乗のようですが、手のひらを返したようなマスコミのワールドカップ・バッシングはいかがなものかと思いつつ、素朴になぜもろくも敗れ去ったのかということを思っていましたら、「オシム語録」なるものがあることを、テレビを観ていて知りました。

 のぞいてみると、勝負の世界というのは厳しいものだと思い知らされます。結果がわかりやすいかたちで、すぐにあらわれるだけに。

2003年4月 故障者が続いたチーム状況について岡社長に

肉離れ?ライオンに襲われた野うさぎが逃げ出すときに肉離れしますか?
準備が足りないのです。

2003年2月14日 新加入選手会見後の懇親会で新加入選手のご両親に

あなたは、息子さんを「最後まであきらめずに走る子供」に育てましたか?
もしそうでなければ期待をしない方が良いでしょう。
もしそうなら、私が責任を持って育てます。

2006年06月26日

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

 ところでソフトウェアのエンジニアリングと、製造業の製造は似ていないという議論があります。だからソフトウェアエンジニリングプロセスは、コントロール不可能だというロジックなのでしょう。

 たしかにソフトウェアはヒトがつくります。ですから、知識労働と言って良いでしょう。一方、自動車の車体を型に合わせて打ち抜く例えが、この「アジャイルソフトウェアマネジメントを考える」エッセーのきっかけになっている書籍「アジャイルソフトウェアマネジメント」にあります。

 いわく、100個の車体を打ち抜くためにかかる時間は、ひとつの車体を打ち抜くためにかかる時間のほぼ正確に100倍だ、つまり線形である・・・

 一方、知識労働は予測もできないし線形でもないから、製造管理と同じやり方では管理できないという意見がある・・・

 残念ながら、現実的に、ソフトウェアプロジェクトは、まずめったに計画通りに行かないし、ほとんど見積もりは黒魔術だ、見積り結果は、完全なフィクションになってきたということです。

 しかしアジャイルソフトウェアマネジメントは、ソフトウェアエンジニアリングがコントロール可能であることを示しています。

 そしてその成功の秘訣は、ソフトウエアエンジニアリングが、製造業の生産よりも、より大きな不確実性を抱えていることを認識すること。そのことが、製造業を革新してきたパラダイムシフトの、ソフトウェアエンジニアリングへの適用を阻むものではないことを認識することでしょう。

 たとえば、TOC(制約条件理論)が教えるのは、どのようにして不確実性をバッファリングするかです。ソフトウェアエンジニアリングにおいて、不確実性が大きいからと言って、TOCを適用できない理由は何もないということです。

 となれば、製造業を革新してきたパラダイムシフトを、ソフトウェアエンジニアリングの領域でも起こすことが可能だということですし、一部の領域では既に起きているということです。

2006年06月25日

もしも心が折れそうになったら

心が折れそうになることが、もしかしたらあなたにもあるかもしれません。

本屋さんでふと手に取った「折れない心」というわかりやすいタイトルの書籍。
この書籍は、中村天風さんという方の語録集です。
中をのぞいてみると、脳天気なくらい、シンプルな語録なので、つい笑いが
こぼれてきました。(良い意味で・・・)

さあ今日から、努めてわらうことにしましょうや。
特に悲しいことや辛いことがあったら、いつにもまして笑ってごらん。
悲しいこと、辛いことのほうから逃げていくから・・・・・。
                          中村天風

もうひとつ・・・

どうにもしようがないと思ったとき
ひょいと自分の心の持ち方を考えてみなさい。
「自分の心の持ち方が消極的だったためなんだな」
とわかると
「そうか、積極的な心に振り替えればできるんだ」
ということに気づく。
                   中村天風

こちらは解釈がちょっと難しいですね。

ここでいう積極的とは、どんなことに対しても強気一点張りで向かっていく
というのではなく、一切の対立から離脱した心の状態こそが積極心なのだとか。

つまり「積極」は「消極」の反対語として考えられているために、「消極心」を
否定することに過剰に反応してしまい、目の前に現れるすべてのことに対して
それと張り合おうという気分になってしまうのだそうです。

もちろん、すべて打ち克つことができればよいが、連戦連勝いつまでも克ち続ける
ことなどできないのが世の常だとあります。

つまりひとの心はそれほど強くないということでしょうか。

過剰に頑張り続けているときに、不幸にして打ち克つことができなかったなにかが
あらわれれば、それまで積極心と思い込んでとたんに崩壊してしまうことにも
なりかねない・・・

すると心はもはや積極的ではいられなくなる。

だから心が事柄の条件しだいでその態度が変化するようなことがない
一切の対立から離脱した心の状態にあること。

それが積極心なのだ・・・

2006年06月24日

「体系的ソフトウェアテスト・イントロダクションセミナー」受講のお礼

昨日(6/23)、「体系的ソフトウェアテスト・イントロダクションセミナー」を開催しました。

リニューアル後の1回目、そしてコース編成替えのため、最終回というコースでした。
いつもはEメールで行うセミナーフォローですが、せっかくのブログですので
この場を借りて、受講者の方々へのお礼とアンケートへのお答えをさせていただこうと思います。

SSTI-1.gif

まず皆様からいただいたコース内容の評価です。

内容は 4.6点/5.0満点でした。
アンケートをみると、気付きが得られて良かった、内容の方向性に
賛同すると言う、前向きなご意見がほとんどで、とても嬉しく思います。

インストラクタへの評価は、4.9点/5.0満点でした。
私の祈りが通じたのでしょうか(笑)大変ありがとうございます。

SSTI-2.gif

頂いたコメントにランダムにお答えします。

■テストを実施してリスクの傾向をつかんだら、それをテストケースの
 実施優先度に反映させるという考え方が参考になりました。

        はい。公式テストの計画は常に見直す対象です。
        その見直しのためにも、リスク評価は有用です。

■今回は時間が短かったため、もう少し詳しいセミナーに参加してみたいと思います。

        サイクスのホームページをご覧ください。

■事前に雑誌やWebで収集した情報をベースに、より具体的で現実的なお話を聞くことが
  できました。また休憩時間の雑誌等を通じて、新しい発見を得ることができました。

        新しい発見があったというお言葉はとても嬉しいものです。
        また”雑談”の中には、"独り言”もあったかと思いますが(笑)
        公にはできない話もできるのが、FACE-TO-FACEでやるセミナーの
        良いところですね。

■とりあえず「体系的ソフトウェア」の本を買おうと思いました。
 本講習には是非、他の開発の人間にも聞かせたいと思います。
 それだけに今回で終了というのは残念です。

        ありがとうございます。感激です。
        編成変えのため、コースがなくなりまして申し訳ありません。
        現在、「体系的ソフトウェアテスト実践コース(2日間)」の
        1日版「体系的ソフトウェアテスト入門コース」を開催する計画です。

■実際にやったこともあれば、初めて聴いた内容もあり、体系的に学ぶと言う
  ことが有用であったと思います。

         はい、ひとつの有用な「テスト戦略」パターンを提案させて
         いただいたつもりです。実は「プロジェクトマネジメント戦略」
         パターンなのですが。
         是非、初めて聴いた内容をひとつでも実践に移されることを
         お奨めします。

■テストツール適用を考えて参加しましたが、要求のバグ削除のコスト比率が
  82%というのが印象に残りました。

         はい、そのとおりだと思います。
         考えてみると、驚くべき数値ですね。

■インベントリを作成してみようかと考えています。

         是非、一度やってみてください。
         実践の中で様々な気付きが得られることと思います。

■自動化ツールを購入する前に受講したかった気がしてきました。
  要求品質など自分にとってためになる話が聞けました。

         テスト戦略・プロセス改善⇒自動化テスト戦略・自動化ツール
         という道筋は有効です。
         要求品質に注意を払って、自動化の戦略を考えると
         良いと思いますよ。
         弊社では「体系的自動化テスト」のコースもご用意して
         いますので、よければご検討ください。

■要求定義、プロジェクトの最初の方をおさえることが重要というのが
  よくわかりました。トリアージはよく考えて使っていこうと思います。

         戦略とは「正しいことを行う」こと。
         望ましい戦略とは「最初に正しいことをやる」こと。
         かと思います。
         トリアージも使ってみてくださいね。

受講者の皆様方、大変ありがとうございます。

                               宗 雅彦

2006年06月23日

Java World Day 2006 でスピーチをさせていただいて・・・

昨日、IDG社の Java World Day 2006でスピーチをさせていただきました。

多数の方にご出席いただきまして、ありがとうございます。
IDG社の方によると、このセッションは比較的早く満席になったとのこと。
高い関心をもって、スピーチをお聴きいただいたような気がします。

JavaWorldDay.gif

スピーチの主テーマは”リスクベーステスト”ですが、リスクベーステストを
運用するにあたっては、前提条件となるテストのアプローチや、テクニックが
あるというお話もさせていただきました。さらには”一番大切なことがある”
とのお話もさせていただきました。

JavaWorldDay.2.gif

みなさまのご感想がいかがだったのか、IDG社より頂けるとのこと。
楽しみに待ちたいと思います。

JavaWorldDayMI3.gif

 ↑ 会場の六本木ヒルズでみつけた"M:i:""の予告 !! 
    能天気なハリウッド・アクション大好きな私にはたまりません。
    楽しみですね。
    7/8 公開ですよ。

2006年06月22日

日経コンピュータさまへのお詫びとレポート感想文のお願い

 独り言のような日記コーナーにしますと言って始めたブログですので、本当に日記のつもりで自由気ままに随筆しておりました。しかし考えてみればあたりまえのことですが、意外と読んでいただいている方がいらっしゃるのです。たしかにブログはインターネットで全世界の方が読者になりうるメディアなんですね。もちろん”なりうる”であって全世界の方が読者になるわけではありませんが(笑)。でも、考えてみればすごいことです。

 といいますのも、先日の「日経コンピュータ 2006.06.12号」特集でインタビューを受けたお話をしまして、記事にあった「予防テスト」を「予防的テスト」と説明したつもりだったという日記を数日前に書きました。

 そうしましたら、なんと!当の日経コンピュータ編集員の方から、私が監訳した「体系的ソフトウェアテスト入門」に「予防テスト」とありましたよ、とのご指摘が・・・

 お恥ずかしい限りです!! 井上編集員、どうもすみませんでした!!私の見落としです。 これに懲りずに今後ともよろしくお願いします。

 ところでこの記事をきっかけにした、レポート「テストに困らないために一番大切なこと」贈呈企画・・・予想を超える申し込みを多くいただきまして、嬉しい反面、困っていらっしゃる方が数多くおられるということをあらわしているということでもありで、喜んでいいやら、憂うべきやら・・・というところです。

 しかしいよいよ来週26日(月)から発送開始です。お申し込みいただいた方々、もうしばらくお待ちくださいね。

 ところでこのレポート、思わぬ反響を頂きましたが、はてさてお読みになった方々のご感想や、いかに。ということで是非、読者の方々には率直なご感想をいただきたいと思っております。多様な声を頂き、また役に立ったというお声が多ければ、頂いたご意見を反映して、ちょっとした冊子にまとめてみても良いかなと思っております。

 ということで、是非読後の感想をお待ちします。感想の送付はお手間がかからないように、Eメールで受け付けたいと思います。あとはWebフォームでも簡単にご感想いただけるようにもしようかな、とも考えております。

 テストあるいはプロジェクトの課題にお悩みの方は、かくもたくさんいらっしゃると再認識しました。アカデミックな技術論も必要ですが、重要なのは、意外と、小さな一歩を踏み出すための”実用的で役に立つ”ヒントかな、とも思うこの頃です。

 ただ”実用的で役に立つ”ためには、それをささえるしっかりしたコンセプト(戦略)の裏づけがなくてはならないという側面もあります。そういった意味では、なにやらエッセーのようなタイトルをつけましたが、実は本当に一番大切なテスト戦略・プロジェクトマネジメント戦略とそれを実施するためのアプローチを書いたつもりです。

2006年06月21日

ITを過信すると・・・

2〜3日前の日経新聞1面連載記事「ネットと文明」を読んでいましたら・・・
書籍「日本のもの造り哲学」などで素晴らしい見識を示しておられる
東大大学院教授の藤本隆宏先生がおっしゃっておられました。

「IT(情報技術)を過信して思考停止に陥り、組織の能力を上げる
鍛錬を怠れば失敗する・・・

にわたまのお話かとも思いますが、あえて、昔、おばあちゃんが
言っていたことを一言付け加えると・・・
※ここでの"おばあちゃん"とは、最近ちょっとマイブームになっているのですが
 "知恵袋"のような意味だと思ってください。

「組織の能力を上げる鍛錬を怠る組織は、ITを使いこなしたくても
 使いこなしようがない・・・」

ちょっと言いすぎですか?

しかしここからはうろおぼえのお話で恐縮ですが、本当かどうかはさておいて、
日本のIT活用力は一般的に米国に大きく劣るとされてますね。
※多分、本当でしょう・・・

その理由は・・・

米国のIT投資水準は、日本の2倍だとか・・・

それが理由でしょうか・・・

どうも違うらしいのです。適性な投資水準はIT活用成功の必要条件のひとつ。
統計的にみると、投資水準がどれだけであれ、それを使いこなす
組織の成熟度が不足していれば、どぶに金を捨てることになるらしいんですね。

これは直感的に同意です。
私の住むIT業界の内部でも、日々経験しています。

どうして組織の能力を上げる鍛錬をさしおいて、ツールの導入に走るのでしょうか?
少なくとも、鍛錬とツール導入は同時並行でなくてはいけない。

つまりITの問題ではないんですね。

私たちの住む社会がヒトで構成されているかぎり、
表面的にはどのようにみえても、それは「ヒトの問題」だということですね。

トヨタの強さは、粘着質とも思える、小さな改善の積み重ねから来る。
これを「千日鍛錬」と呼ぶ、とおっしゃったのも、藤本先生だったような気がします。
※すみません、うろ覚えです。

2006年06月20日

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

 「業界で最も優れた企業には、競合他社に比べて、
      はるかに優れた業績達成を可能にする
          プロセスを構築している。」
----- Louis V. Gerstner


 前回、”銀の弾丸”をあてにしないで、2倍、4倍、10倍、20倍の生産性向上を成し遂げた事例が相次いでいる。果たしてそれは、どのように達成することができるのだろうかという問題提起をしました。そしてガースナー氏の言葉は、その答えのひとつを提示しているように思います。

 昨日、唐突に、ジョアン・マグレッタの言葉を、書籍「なぜマネジメントなのか」から引用しました。そして、「マネジメントの本質」とは「複雑なこと、専門的なことを、実践に移すためのものである」ことを示しました。

 ソフトウェア開発プロジェクトは、間違いなく「複雑」で「専門的」です。そして、ソフトウェアの開発に多大な投資をするビジネスの経営者・マネージャは、少しでも効率的に、そして競争優位に立つために、本質的なマネジメントを実践する立場にあります。

 一方、これは経営者・マネージャだけの課題なのでしょうかトム デマルコは、氏の著書「ゆとりの法則」で、「世界のディルバートたちは責任を放棄した。彼等には、上司を非難することが似合っている。ディルバートたちは、上司をより有能にするのが、彼の義務であることが分からなかった」と言っています。

 いずれにせよ、「業界で最も優れた業績を達成したい」企業は、それを可能にするマネジメントシステム、つまりソフトウェアビジネスを営む企業であれば、エンジニアリングの領域では、優れたソフトウェア生産システムの構築への挑戦を求められているということでもあります。

 となれば、業界リーダーを目指すソフトウェア開発組織が実践すべきマネジメントシステム、生産システムの骨格は何か、今、生産性を2倍、4倍、10倍、20倍にするパラダイムシフトが起きているのではないかという問いにつながっていきます。

                                               つづく

2006年06月19日

マネジメントの本質

ジョアン・マグレッタの書籍「なぜマネジメントなのか」からの引用・・・

実際、たいていの人にとって、ニューエコノノミーで何が一番プラスかというと、マネジメントや因習的な組織を完全に駆逐できるという希望なのだ。ニューエコノミーの使者は、テクノロジーとバーチャルな組織が、マネジャーとマネジメント自体をも消滅させると高らかに謳い上げる。・・・・・(略)

現実に、このシナリオを魅力的に見せるだけの事実は存在する。しかし、これは本質的に願望に基づいた考え方であるだけでなく、この説の基盤となっているマネジメントの概念自体が根本的に間違っている。

管理監督は姿を消すかもしれないが、そもそもマネジメントは他者を管理するためのものではない。ヒエラルキー的傾向の強い企業構造は平らになるかもしれない。しかし、本来マネジメントは、命令系統の中で優位な地位を占めることを意味するものではない。

マネジメントの本質は、複雑なこと、専門的なことを、実践に移すためのものである。

2006年06月18日

ウィークリーマガジンのリニューアル再発行にあたって

 突然ですが、イチローってすごいですね。もちろんシアトルマリナーズのイチローのことです。2004年の、262安打記録は世界が称えた偉業ですが、未だに新鮮な感動として記憶にも新しいところです。

 さらにイチローが本当にすごいと思うのは、その後もパフォーマンスが衰えることなく、継続していることです。5年連続100得点30盗塁は歴代3人目。それほど目立ってはいませんが、デビューから5年連続200本安打という世界初記録も達成しているんですね。

 どうしてイチローはこんなにすごいのでしょう。技術面からみれば、イチロー独特の"振り子打法"が思い浮かびます。王監督といえば、現役時代の"一本足打法"。イチローといえば"振り子打法"。

 では私やあなたが”振り子打法”を使えば、262安打も夢ではないか。これを読んでいるあなたが誰かわかりませんから、無責任なことは言いませんが、少なくとも私には無理でしょう。

 これは私が仕事柄、座りっきりの生活をしていて、体がなまってるとか、おかげでここ2週間で体重が2Kg増えたからとか、そんな私にイチローのマネは無理でしょう・・・ということではないんです。

 負け惜しみみたいですが、”振り子打法”は私のためのものではないんです。それは王監督にとってもまったく同じ。王監督が現役時代に戻ったとしても、”振り子打法”は使いこなせないはずです。(あ、誤解がないように言っておきますと、もちろん王監督は私よりははるかに上手に”振り子打法”を真似ることはされると思います。)

 振り子打法"はイチローのためのもの。イチローはとても体が柔らかいそうですね。暇さえあれば柔軟体操しているそうですよ。体が柔らかいから”振り子打法”がマスターできたわけではないでしょうが、少なくともイチローの柔軟性がなくては”振り子打法”は使いこなせないんでしょうね、きっと。

 ではイチローは最初から達人だったのか。もともと打撃センスには定評があったようですが、オリックスに入団した当初は、一軍に定着することはなく、失意の2軍生活を送る時代があったようです。ちょっとびっくりです。あのイチローがですよ。しかしその2軍時代に河村健一郎2軍打撃コーチと二人三脚で"振り子打法"を考案。後に抑木監督に見出され、今のイチローに至るという訳です。

 この変遷をみると、武道やスポーツの世界でよく言われる"守破離”の典型的なパターンを辿ったと考えることができそうですね。つまりイチローとても、最初の”守”の段階では”基本の型”を徹底的に自分のものにした。

 そして自分ならではの”やり方”を取り入れてみる。その自分ならではの”やり方”には、うまくいくものもいかないものもある。この段階では、せっかく”守”の段階で学んだものを活かして向上したパフォーマンスが、いったん落ちることもあるでしょう。

 しかし、うまくいったものを残して、次の”離”の段階に移行する。ここで自分ならではの”型”を確立することでブレークするんですね。

 ここで大切なのは、どんな天才であろうとも、ましてや私のような凡人であればなおさら、”守”の段階を経ずして”破”はないし、”破”の段階を経ずして”離”もないということですね。そしてどの段階でも、”型”を繰り返し繰り返し何千回、何万回と鍛錬する。そして習得する。DNAに染み渡るまで繰り返すんですね。

 これはどんなものにも当てはまります。例えばお料理ですね。私はお料理をあまりやらないので、突然お料理をする羽目になったらどうするか・・・レシピを開きます。レシピに書いてあるとおりに、材料を揃えて、レシピの手順に沿って調理すれば、ほぼ間違いがないものができる・・・(はず)。

 でもお料理の達人は違うでしょう。まずレシピは見る必要がない。なぜならば、体のDNAにレシピが染み渡っているから。そして達人ならではの、隠し味とか、手順とか、あるいは実はここで2度揚げするのが秘訣なのよ、とかそういった技を持っている。それを横で見ている"守”や”破”の人は、それを真似ながら、中には自分ならではのやり方を体得して”離”に至る人がいる。

 あ、つい、忘れるところでした。この記事は、メールマガジン再発行についての記事でした。”スポーツ”や”お料理”の話題を扱うのではなく、”ソフトウェア”についてのトピックスを扱うのでした。

 そうです、結論から言うと、ソフトウェアの世界では、これら”型”の事を”パターン”と呼びます。特に”型”を、パターンランゲージと呼ばれるランゲージで表記したものを、パターンと呼ぶことが普通です。

 たしかにソフトウェアの世界を見渡すと、さまざまなパターンが溢れていますね。有名なのは、GoFのデザインパターン。同じ設計のためのパターンでも、粒度(抽象度)のレベルごとに、マクロなものからミクロなものまで、アーキテクチャーパターン、いわゆるデザインパターン、イディオムと何種類かあります。

 というと難しそうに聞こえますが、パターンとは、とどのつまりは達人の方々のノウハウをレシピにしたもの・・・

 さらにパターンは、これら分析や設計のためのものだけではありません。要求エンジニアリングのパターンですとか、組織やプロセスのためのパターンの整理の取り組みも行われてきています。

 ところで、私はコンサルタントであり、セミナーのインストラクタです。”守破離”の考え方に当てはめると、この私は一体何をしているのでしょうか。

 基本はイチローにとっての河村コーチだと思います。例えばセミナーでは、”守”の型である、基本パターンおよび基本パターンの組み合わせを知識として提供する。というのは、どんな天才であれ、”守”の段階をスキップすることはできませんから。”守”の基本パターンは、知っておかねばならない”MUST”の知識なのですね。

 しかしこれは基本パターンですから、実践的な適用については、さまざまな問題が起きることがあります。といいますか、問題が起きることの方が普通でしょう。柔道を習い始めたばかりで、受け身の基本型しか練習していない白帯の初心者が試合に出場したら、これは受け身のさらなる練習のために出場するようなものです。ましてや寝技に持ち込まれたひには、何をするために出場したのかわかりません。

ですから、それを現場から得た経験則として、みなさまと分かち合う。そして時には、演習問題を通して、”パターン”を体に覚えこませる。頭の中に知識としてある状態と、実際にそれを体を動かして実践する状態には、大きなギャップがあります。それを埋めるためには、”型”の繰り返しによる鍛錬しかないのです。その鍛錬をするにあたって、それを少しでも効果的に行うことができるように、お手伝いをするのが、インストラクタであり、コンサルタントなのです。あるいはコーチと言った方が適切かもしれません。

 しかしおもしろいのは、どう見ても”離”の状態に至っていると思われる方が、支援依頼をされることがあるんですね。ちょっと考えてみれば、そんな方にとって、コンサルタントは不要だと思うのですが、意外とあるのです。

 こういう方はいわば”好奇心”の固まりのようにお見受けします。どうも自分のパターンとは違うパターンを学びたいとか、そういう感じなのです。でももしかすると、あるパターンがいつでもどんなときでも通用できるわけではないことも知っているので、危機対応のために別のパターンを学んでおきたいとか、そういうことかもしれません。

 ともあれ、”守”の”基本の型”としての”パターン”は、知識としては”MUST”のものとして身に着けて”おかねばならない”ものだと考えています。そして、それは実践の中で、繰り返し、繰り返し、体に覚えこませるもの・・・

 セミナーやコンサルティングの現場ではこういった実践が膝を突き合わせてやりやすいのですが、こういった文字の情報としては、この体を動かした実践に至ることはなかなか難しいことかと思います。しかし”基本パターン”は、知っているだけでもヒントになるという側面もあります。

 以前発行していて、事実上休眠していたメールマガジン”Quality Software 119"は、知識としての基本パターンの解説に限界を感じてお休みをしていました。もうひとつには、実践事例の蓄積を優先する時期だとの判断から、現場に深く潜っていたということもあります。

 しかし弊社自身が実践事例を蓄積していく過程で、基本パターンがさまざまなバリエーションをみせていくことを経験してきたのです。その経験の中で、実は改めて基本パターンを整理・確認していくことも重要なんだなぁ、と再認識しているのです。

 という観点から、メールマガジンを"クオリティソフトウェア・ウィークリー”としてリニューアル発行を行うにあたって、そこで扱うテーマのひとつとして、この”基本パターン”を、いわば”クオリティソフトウェアのレシピ”として、カタログ的に紹介していくことを考えています。どのようなタイプのパターンがあるのか。そのタイプのパターンには、どのような例があるのか。

 繰り返しますが、パターンというものは、これさえあれば全ての問題が解決するという「銀の弾丸」ではありません。しかしみなさまのヒントになることは間違いないでしょう。

 そしてもっと大切なことは・・・。それは「実践」です!!知識は使わなければ知識のままで終ります。そして使わない知識は、あなたの頭の中から消えていきます。

 使えるところでは使いましょう。それがどんなに「小さい」ものに見えたとしても。まずは「小さな一歩を踏み出す」ことが、どんなことよりも優先します。そのために、先達のプラクティスであるパターンをうまく使いましょう。

 さぁ、それでは始めましょう。THEORY AND PRACTICE です。

 ということで、リニューアルするメールマガジンに、”クオリティソフトウェアのレシピ”を連載します。興味がある方は、サイクスのホームページから、申し込んでくださいね。

2006年06月17日

Karl Wiegersさんという人

 サイクスという会社は「ソフトウェアテスト」のコンサルティングで知られているようなのですが、「ソフトウェアテスト」自身のパフォーマンスというものは、ペアとなるなにかと組み合わせて、うまく統合して、はじめて発揮されるものだと理解しています。

 そのペアとなるもののひとつが「ソフトウェア要求」「要求エンジニアリング」ということで、ここをテーマとした良質なコンサルタントを探していましたら、出会ったのが Karl Wiegers さんという人でした。

 この方は、書籍「ソフトウェア要求(」「ピアレビュー」「ソフトウェア開発の持つべき文化」「More About Software Requirements: Thorny Issues and Practical Advice」を出しておられますから、日本でもある程度は知られている方ですね。

 結果、Karl Wiegers氏のProcess Impact社と事業提携という運びになった訳ですが、普通、なにかと面倒な提携交渉があっという間に成立。というのも、Karlさんはとても偉い方なのに、とても腰が低い。なにか問い合わせると、すぐにきっちりと応答が・・・だから偉い方ということなんでしょう、きっと。

 Karl Wiegersさんという方は、私も見習うべきとても尊敬できる方です。

2006年06月16日

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

 しかし一方で、ソフトウェアエンジニアリングの世界でも、従来の常識に照らし合わせると、非常識といわれるに違いない生産性向上の事例が相次いでいます。

 David Andersonは、書籍”アジャイルソフトウェアマネジメント”の中で、4倍の改善は容易だ。いや、10倍だって確実に可能だ、と言っています。今の5倍の仕事を、いま要している半分の時間でこなすことを想像してみてほしい、と問いかけているのです。

 これも刺激的な問いかけだと思いませんか。私は例えば中国へのオフショア開発を行うプロジェクトに関与することがありますが、誤解を恐れずに言うと、「うまくないやり方だ」というのが率直な感想です。

 なにがうまくないかというのはさておき、David Andersonは、「もし、アジャイル方法論が9ヶ月以内に4倍の改善結果をもたらすとしたら、企業は、向こう3年〜4年のコスト削減を約束するインドのITベンダーに対して、アウトソースしたりするだろうか。」とも言っています。オフショア開発が比較的成功していると考えられる米国においても、懐疑的な見方があるんですね。

 ともあれ実際に、欧米における成功事例には、わたしの貧弱なボキャブラリーではめざましいとしか言えない事例がいくつか出てきています。例えば、書籍”ソフトウェア プロダクトライン”によれば、ディーゼルエンジンの制御システムを開発する Cummins社は、工数を250人月から2〜3人月に削減・・・

 250人月から2〜3人月というのは、さすがに経験がありませんが、”最新のテクノロジー”なしに、まったく難しいことをしたわけではないのに、生産性2倍というのは私の身近なところでも起きはじめているんですよ。

 ここでの問いは、どうやったらこのような生産性向上が達成できるかということです。

   つづく

2006年06月15日

レポート贈呈!!ありがとうございます!!

レポート「テストに困らないために一番大切なこと」贈呈企画にお申し込み頂いた方々、ありがとうございます!!昨日、6月14日のお昼にEメールDMでご案内を送信したのですが、なんと昨日1日だけで、予定していた300部がほとんどなくなる勢い!!ちょっと感激ぎみです。

驚いたのが、ご案内を送信しているかたわらで、何名かの方々からばたばたと申し込みをいただいたことです。で、一番のりはF社のUさん、あなたです!!おめでとうございます。面識ある方なので、今度お会いしたらお礼言いますね。ご案内から1分も経っていなかったですね。

ということで、今回、ご用意のものは、本日受け付け分を持っていったん締め切りとさせていただくことになろうかと思います。その後の申し込みは・・・

昨日は、2年ぶりくらいのホームページ大改訂、レポート贈呈の案内、新開発のセミナーの案内と、大忙しでした。実際、ホームページ改訂では、突貫工事のため、弊社スタッフが1名死にかけました。どうもごめんなさい。プロジェクト成功のためには、プランはつくって当然でしょ、とコンサルしている割には、無計画にサイト再構築に突入しまして、紺屋の白袴と反省してます。

ホームページメンテナンスの運用を楽にするために、本サイトも BLOG システムの MovableType を採用したのですが、なかなか良い感じです。MovableType がまだ知られていなかった頃、3年くらい前だったでしょうか、お遊びで使ったことがあるのですが、当時と較べると、格段と機能アップしていますね。すごいです。これからホームページをまめに改訂できるので、嬉しいですね。

2006年06月14日

ほぼ日手帳語録

手帳には凝ります。
といいますか、いろんな目的に応じて最適な手帳があるものですから、凝らざるをえないという感じです。で、ふとかばんの中を見たら、今は3種類の手帳を持ち歩いていることに気が付きました。その中でも今年から使い始めたのが、「ほぼ日手帳(ほぼにちてちょう、と読む)」です。

これは糸井重里さんが企画したらしく、ロフトでj販売しているんですが、なぜか期間限定の部数限定なものですから、好きな色の「ほぼ日」を確保するためには、結構販売日に気をつけていなければならないのがやっかいですね。特にWEBサイトでの販売はおまけが沢山つくので、販売してたら即クリック!なのですが、前回は仕事の関係でサイトをのぞくことができず、機会を逸してしまいました。おかげで今、手元にあるものは、新宿ロフトに電話して在庫確保、わざわざ新宿まで出かけて手に入れたといういわくつきのものです。

ともあれ、この手帳にはいろんな機能があるんですが、一番重宝しているのが、各ページに載っている「今日の一言」ですね。退屈な会議の時はこれをぱらぱらめくっていると、結構退屈しのぎになりますよ。(おすすめ)
くだらない駄洒落もあれば、けっこう重い一言もあったりするんですが、「あ、これ、結構さわやか」風のものもあったりしますね。

ここは「先達の言葉」コーナーなので、このコーナーの趣旨に合っているかどうかは別にして、最近これいいな、というのが:

「ごほうび」を使わないしつけや訓練を犬といっしょに経験したかたが、メールをくださいました。
「犬はほめられるのがうれしいんじゃない。飼い主が喜ぶのがうれしいんです。」
ということで、読んで、とても気持ちがよくなりました。
犬のことが、もっと好きになりました。<『今日のダーリン』より> 6.12(月)

ということで、私も「犬」です。あ、いや、飼い主の時も・・・

2006年06月13日

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

このブログは個人的な日記にします、とは言ってみたものの、考えてみたら1日のほとんどをIT関係の仕事に費やしていることに今更ながら気付いてしまいます。となると日頃考えていることはかなりの部分がITのこと。これで果たして良いのかという人生哲学はさておき、アジャイルソフトウェアマネジメントについて脈絡もなく考えてみたいと思います。

今年の3月31日付で出版された書籍「アジャイルソフトウェアマネジメント」。いつもパワフルなパートナーコンサルタント、匠システムアーキテクツの前田 卓雄さんのお声がけで翻訳させていただきました。翻訳したから言うわけではありませんが、結構目からうろこの書籍です。

アジャイルというと、どうも一般的にXPのイメージが強いようで、「あぁ、あのドキュメントを書かないやつね。」とか「テストファーストでしょ。」となってしまうことが多いように感じるのですが、ここで言うアジャイルソフトウェアマネジメントはちょっと違うんですね。

この書籍は、代表的にはXP,SCRUM、FDDといったアプローチがある、いわゆるアジャイルプロセスに限定せずに、伝統的なウォーターフォールやちょっとヘビーなRUPも対象に含めて、ソフトウェアエンジニアリングのマネジメントを真面目に考えてみよう。そしてソフトウェアエンジニアリングをうまくマネジメントすることが、ソフトウェアビジネスのマネジメントに有効であることを説いた、とても真面目な書籍なのです。
というのも、問題の一番目として、IT業界におけるマネジメント - つまり経営とか工程管理 - は、未だに「直感や経験に頼った判断やおおざっぱな数字によって行われている」というとても刺激的な問題提起から始まっている書籍なんですね。

つまりマネジメント技術について言えば、製造業のような他の産業と比較すると、先進国の競争力と開発途上国の競争力の差、あるいはそれ以上の格差があるというように言っているんですね。
実際、本書でも取り上げられているように、TOC(制約条件理論)、リーン生産、システム思考、複雑適用系、あるいは身近な例ではトヨタプロダクションシステムともよばれるジャストインタイム生産方式は、製造業の競争力を高めるうえで利活用されている一方で、ことIT業界に目を向けてみると、う〜む、とうなってしまう現状があるように思います。
                                          つづく

2006年06月12日

日経コンピュータ 2006.6.12 特集に出ました

日経コンピュータ 2006.6.12号特集 「"テストありき"でソフト品質を確保」に出ました。いきなり冒頭に大きく意見を取り上げていただいてありがとうございます。この特集には、IHIエスキューブ社の方々の取り組みが大きくとりあげられていますが、嬉しいことです。私も一年間、どっぷりと現場に入らせていただいて、良いお仕事をさせていただきました。

ところで余計なおはなしです。特集の中で私の名前が3度くらい出ています。それはありがたいのですが、名前が「宗雅彦」ではなくて「宋雅彦」になっているところがあるんですね。たしかにソフトブレーンの宋社長は有名人ですし、素晴らしい方ですが、私は宗教の宗の方です。実は、はじめてお会いした方にメールを頂くと、8割くらいの方が、宋さんと書いてメールをくださるんですね。毎回、毎回、違いますよーと訂正の返事を出すんですが、言う方も間違ってますよと言うのは言いづらいですし、言われた方も恐縮されるみたいで、いいことはありません。御願いですから、宗の方を使ってくださいね。

私と年齢が近いか上の方には、マラソンの宗兄弟と言えば通じたんですが、最近はちょっとです。話が脱線ついでに、私は長崎生まれなんですが、マラソンの宗兄弟も九州なんですね。この宗という名前はもともと対馬の出らしく、たしかに祖父の時代までは対馬に居たと聞いています。この対馬のお話は長くなるので、また別の機会に譲るとして。

さて特集のお話です。記事の中では、「予防テスト※」と呼んでいるテストのアプローチを、コンサルティングの現場での提案コンセプトのひとつとしています。このアプローチも含めた弊社が提案するプロセスの実践事例が、IHIエスキューブ社の事例のように、いくつか蓄積されてきました。お名前まで出して事例発表というのは、あまりないのですが(IHIエスキューブ社の方々、ありがとうございます)、わたしたちが提案するテストプロセスのポイントや、実践事例から得た経験を反映させて、簡単なレポートにまとめました。

これを興味がある方に贈呈することにしました。題して「テストに困らないために一番大切なこと」。テストやプロジェクトの失敗にお困りの方がたくさんいらっしゃる一方で、やはり成功体験は共有してこそ世の中の発展につながると思うんですね。それと私個人としては、どのような方が興味をお持ちになるのかに興味があるという面も実はあります。まもなく受付開始しますので、関心ある方はお申し込みくださいね。

※現在、「予防テスト」は「予防的テスト」と呼んでいます。

2006年06月11日

もとこちら

motokochira_sonomamazenbu.gif


平井謙次さんの言葉です。この言葉の意味するところについては、平井謙次さんの業績を解説したサイトがあるようですから、私が拙く解説するよりも、そちらをご参照いただいた方が良いと思います。関心があったらのぞいてみてください。

言葉というのは不思議なもので、本当に必要な時に、まるで吸い寄せられるように目の前に現れる気がするときがあります。この言葉は、私がある事柄について、とても思い悩んでいるときに、まるで私の心のうちを見透かしているかのように、飛び込んできました。

だからといって、その悩みが解決されるわけではありません。とどのつまり、平井謙次さんのような悟りの境地に至ることができない完璧な凡人だということなのですが、それでもこの言葉を胸に刻んで、つい安易に流れがちな自分を戒めていくべしと思っています。

このブログは、私の個人的なブログとして、そのような凡人を常日頃、支援してくださっている方々に向けて、感謝の気持ちをお伝えするためのサイトにしたいと思っています。

コンサルティングの現場で、信頼を頂いてお付き合いいただいているクライアントの方々、セミナーに来ていただいている受講者の方々、チームでお仕事をさせていただいているエンジニアやコンサルタント仲間の方々、いつも獅子奮迅の会社のスタッフ、そして将来的にお付き合いさせていただくかもしれない方々。

そして時には厳しいお叱りをいただける方々。ありがとうございます。”もとこちら”です。”そのまま全部”。こうやって、コンサルタントはお客様に鍛えられて成長していきます。そうすることでのみ、信頼を頂いた方々への恩返しができるのだと思います。そうすることでのみ、頂いた信頼以上のものがお返しできるのだと思います。

ただこのブログで書くことは、感じ入った言葉、私の周りで起きていること、それについての感想、私が今、考えていること、取り組んでいることなどを淡々と書いていきます。多分、独り言みたいなページになることでしょう、きっと。間違っても、誰も語らなかったプロジェクト成功の7つの秘訣とか、感動して涙を流すような薀蓄を期待しないでくださいね。本当に日記です。

とここまで読んでいただいたあなた、本当にありがとうございます。なんだか無駄な時間を使ってしまったなと感じられた方、すみません。よかったら時々、のぞいてみてください。

                                                宗 雅彦