2009年12月24日

リーダーが必ず受け入れるべき3つの指針?

「リーダーが必ず受け入れるべき3つの指針」(DIAMOND online) http://diamond.jp/series/sales_manager/10010/

ネットで偶然読んだ記事なんだけど、なんか「納得はできるけど賛成できないな、これ」と思ったので、ネットの片隅で勝手に反論。

【リーダーが受け入れる3つの指針】
 ・部下はリーダーの30%しか仕事ができない
 ・組織はリーダーの器以上に大きくならない
 ・部下に決して弱みを見せてはならない

これ、それぞれ「と思うと、気が楽だ」って文言を入れるとしっくり来るよね。
読んでみて「そうそう、そう感じることはある」というのが納得できた部分。
「でも、それってそう言い切るのが良いことなの?」というのが賛成できない部分。
ということで、反論してみたい。
まあ、技術畑と営業畑とは全く別のものなので、お前が反論するな!という話はあると思うけどね。

ちなみに自分は、開発でリーダーにたった時は「自分はカレッジ型」であるということを最初に公言してしまう。性格的にも「親分・子分型」運営なんてできないし。

「部下はリーダーの30%しか仕事ができない」は「部下は自分の思っていることの30%ぐらいしか汲んでくれない」



仕事柄、営業の人とは付き合いがあるし、「どうして営業と現場とは理解し合えないのだろう」というのをいつも悩んでいる。
で、ある「人売りIT企業」の営業さんの話。

その営業さんは「とにかく人を売って案件数かせぐ」ことが得意で、いつも「営業の中で会議ばかりしてちっとも外回りをしない」人たちがいるのを不満に思っていた。
一方、不満に思われた方といえば、いつも「外回りして数を稼ぐだけで、きちんと技術者と案件とのマッチングをしていない」のを不満に思っていたらしい。
技術者的に頼りたいと思うのは、きっと後者だろうね。そこでその営業さんはずいぶんと悩み込んでいた。そのためにスランプになった。

ある日、その営業さんが社長と酒を飲んで、言われたらしい。「彼らのやり方は、技術者を幸せにさせようと努力している点で、とても正しい。そこは理解して欲しい。ただし、会社としてはそれでは回らないんだ。だからキミのような数を稼げる人も必要なんだ。会社としては両方とも居てもらわなければ、成り立たないんだよ」
身も蓋もなく言ってしまえば「キミは必要悪なんだよ」ってとこだろうけど、それでもこの営業さんはそれを聞いて元気になり、仕事へ前向きになった。

部下がリーダーの想定している(技術的/仕事量的/思想的)範囲と一致するのはマレだよ



そう、人は本当にそれぞれで、同じGoalをかざしても、そこへの立ち向かい方も色々なら、持っているモノも色々だ。まずそこをしっかり抑える必要がある。
技術の話になるともっと色々になる。ある人は設計は得意だけどコーディングで凡ミスをする、とか、ある人は環境設定周りは得意だけどなぜか設計能力はない、とか。
リーダーのやるべき事は、部下を30%しかできない人として扱うのではない。部下を一人ひとり見極めて、たとえ想定と違っていても適材適所に人をはめる事だ。できるなら本人にしっかり選択してもらった方が力になる。
そのために必要なのは、リーダーがGoalをしっかり見極めて全員の共通認識にしていることだ。それさえできていれば、チームはGoalへ向かえる形になる。(たとえイビツな形でも)
あとはもう、チームのハンドル捌きにかかっている。

へびの足。現場の人はもっと営業を頼りにし、営業をこき使うぐらいの勢いでいるべきだよ。

「組織はリーダーの器以上に大きくならない」ことなんてない



うむむ…部下を認めろ、は前の章でやってしまったな。では別の切り口で。

どれほどの現場で「このリーダー、使えねー」があることか。
けっこうこの体験をした人も多いんじゃないかな。自分もある。
そんな時にチームそのものがバラバラになった場合と、チームとしてはまとまってGoalできた場合とでは、いったい何が違うのか。

プロフェッショナルを自覚した部下をどれだけ囲い込めるかが、組織を成功に導くポイントだよ



チームとしてまとまった場合をよく見ると、プロフェッショナルの意識をつよく持つ人がいた、という事に尽きる。
こういう人が一人いると、その人が変わりのリーダー(影の支配者)となって取り仕切るようになる。複数いると、それぞれ協調し出して、なにか勝手に動いているようで全体としてはまとまっている、という面白い運動コラボレーションがおこる。

プロフェッショナルとそれ以外の違いはなんだろうか。
それはGoalを見出す選眼力、そしてGoalに到達するために有効ならどのような手でも手を尽くす貪欲さ、そして自己責任感の強さ、じゃないかと(個人的に)思う。

逆に、組織的に・リーダーの権限でキャップを設定してしまい、こういうプロフェッショナルな人の行動を制限するようになると、チームは勢いを落として減退する。大型開発でひじょうに多いのだが。

「部下に決して弱みを見せてはならない」で封じ込められるリアルな現状分析



叱咤激励で部下がシャキン!目標達成!すばらしい!!
でも違うんじゃね?
まあこれ、営業にありがちな典型的なノリだけどね。

でも、昔読んだ開発系のリーダー養成本でも同じことが書いてあった。
はっきり言おう。楽観主義と根性論で仕事する時代は終わったよ。

部下がリーダーの顔色を見て仕事をするのは、じつは「それ以外にGoalを見据える判断材料がないから」なんだ。

きちんと「見える化」しよう。そのうえで、GoalとVisionを持とう



さっきからGoalを持てと強調しているけれど、Goalを持つのはリーダーとしてではなく、チームとして持たなくてはいけない。
チーム全体が「Goalは何なのか」を見極めて、はじめて「Goalへ向かう以外の余計なもの」も明らかになる。

そして、Visionもチームとして持たなければいけない。ようは「どういうルートでGoalまでドライブする?」という点だ。
ひとつは「余計なもの」を極力・ギリギリまで削る努力をすること。
もうひとつは「有効なもの」をどんな些細なものでも貪欲に取り入れること。
これをやるためには、リーダーが頭で考えていたのでは絶対に間に合わない。自分の知識は限界があることを自覚しよう。
そのために、情報はなんでもチームで共有しよう。そして部下にはどんどん相談し、意見出し合える雰囲気をつくろう。
そう、「相談するのはOK!」なんて、まだぜんぜん生温い。mustなんだ。

Visionをしっかり見るためには、もちろん現状を全員の認識にしておく必要がある。どんな些細なことも隠し立ては無用だ。

そしてここが重要な点だけれど、これらを踏まえて「給水ポイント」を明確化しよう。
Goalまでとても長かったとしても、中継地点とそこへ到達するルートが頭にあると、人はわりと頑張れる。
そこでほっと一息つけると、次の中継地点に向かう大きなバネになる。
切羽詰ったプロジェクトほど忘れやすいことだけれど、大事だ。

時々、情報を独占することと意思決定を独占することで自己の権力増強を図る人がいる。
こういうリーダーの下では、チームは絶対に大成しない。チームメンバーにいるだけでも有害だ。

どうも、この「部下に決して弱みを見せてはならない」の章がいちばん嫌いだな。ありがちな「無理を通せば道理が引っ込む」を強調しているようで。

なんというか



この片山という人はよほど優秀な人なのだろう。
色々部分的にはいい事も言っていたりするのだけれど、全体的に他人を見下している雰囲気がある。

一方で思うのは、こういった論が気持ちにひびいてしまう背景に、日本によくある「プロフェッショナルじゃなくても仕事になってしまう」傾向があるように思う。
たとえば、この記事がおそらく対象としているだろう係長・課長クラスには、たいていの会社ではそれほどたいした人事権がない。
開発プロジェクトのリーダーともなれば尚更で、ほとんどの場合は寄せ集め部隊で出発する。(それが社外/社内関係なく)
そのために、「この人は完全にプロジェクトにミスマッチなのでは」と思っても、使わなければいけないという傾向がある。
一方で、「この人がプロジェクト的に欲しい」と思っても、なかなか融通が利かない傾向もある。
これって、本来は誰にとってもとても不幸なことだと思うんだけどね。

色々読んでいると、この人も各論・実践論ではちょこちょこといい事を言っているので、そこは学んでいいだろう。
でも、この精神論まで模倣するのは、とても危ない気がした。

ここで書いてることは理想論?
うん、そう、自分の中にある理想論さ。
でも、誰かが理想論をきちんと言わなければ、誰がそれを理想論だとわかるんだい?
ラベル:リーダー論
posted by 未知夢 at 18:39| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月23日

はたして、TDDを前提として障害収束曲線が描けるのか?

前のアーティクルで自分で言及してなんだけど、ものすごーく気になったので、思考実験。
規模は数人3ヶ月を想定してみた。

従来の障害収束曲線



障害収束曲線は色々呼び方があって、最も短い呼び方ではバグ曲線とか呼んだり、Wikipediaでは信頼度成長曲線という名前で出ていたりする。
基本は「テストを重ねていけば、自然と障害検出数が低くなっていくよね。」という「現象」を取り扱ったもの。
図としてはこんな感じかな。

image001.gif

図は、製造フェーズ後にテストフェーズが「単体テスト」・「結合テスト」・「受入テスト」と分かれている事を想定している。
(テストフェーズも、現場や企業の慣習によって大きく扱いが違うので、この程度にした)

「恣意的だ」とツッコミが入るだろう部分を先に解説。

  • 件数多くね? … 過去3ヶ月もテストフェーズがある場合、これぐらいじゃなかったかな?という経験則。(件数に厳密な意味などない)
  • ブレがないね … わかりやすくするため。
  • 各テストフェーズを分けるべきだ … 自分が経験した殆どの現場では、テストフェーズ全体で障害収束曲線を測るのが一般的だったので、それに習った。
  • なんで横軸が日付なの? … 自分が経験した(以下略)。


この図で「わかる」のは、単体テストから受入テストまでしだいに曲線がなだらかになっていき、受入テストが完了するころにはほぼフラットになっている(障害検出がされなくなっている)という事だ。

CI結果を障害収束曲線に!



同じようにして、次の条件でグラフを描いてみた。

  • チーム全体がTDDを前提に開発を進めている。
  • 指標に使用したのは、CIでビルド&テストが失敗した場合に、その失敗件数を障害件数と同等として使用した。
  • CIでの自動ビルドは、簡略化のために日に1回とした。


image003.gif

描いてみてわかったこと



この縦軸に出る「件数」って、「障害」の数じゃなくて「メンバの作業ミス」の数だよね



TDDを前提とすると、少なくともCIで実行するテストは常に「すべて通るハズのもの」であり、基本的にはデグレードしないことをチェックしている側面が強くなる。
そのため、ここでなんらかのエラーが起きるのは、たいていは単純な作業ミスに帰結することが多い。だから件数も少ないし、当然、日数とともに作業に慣れてくるので、ミスも少なくなる。
作業ミスとして現れるのは、だいたいこんなところかな。

  • ビルドエラー … マージのさいのコンフリクト解消を失敗する等で、コードが一時的にコンパイル不能な状態に陥る。
  • テストエラー … 原因はいくつかからなる。

    1. テストを実行せずにコミットした。(TDDに慣れない、切羽詰っててそれどころじゃなかった等)
    2. マージのさいのコンフリクト解消を失敗した。
    3. ローカルでのテスト環境とサーバでのテスト環境とに差異があった。




また、テストエラーも、Mockをあまり使わずにテストコードを書いていた場合、共有されやすいクラスを修正するとエラー範囲が爆発的に増える傾向があり、Mockを適度に使用するとそれが収束する傾向がある。

うん、まあ、なんていうか。
障害収束曲線という代物は、TDDを前提とした開発の場合、あまりにも合わない、というところが明らかになった感じかな。

※ もちろん、元請企業が「単体テストによる障害数」を求めているときに、これらの数字を使う/使わないは政治判断だと思う。その場合でも、「この件数とは何なのか」を自分できちんと把握しておくことは大事だ。

ただし



この障害収束曲線も、「カスタマテスト」および「QAテスト」で"(有効な)チケットを切られた数"に対して行う分には、十分計測する意義はある。
その場合、よりウォーターフォールに近いか、Agile/インクリメンタル開発に近いかが、件数の大小に現れてくるだろう。

おまけ:従来型ウォーターフォール開発で本当に障害収束曲線を描くと



最後のヘビの足。

障害収束曲線って、ホントに全テストフェーズを通してこんなキレイな曲線になるの?という点。
結論を言ってしまうと、障害収束曲線があのようにキレイな線になるのは、1つのテストフェーズに閉じた場合だけで、何段階もあるテストフェーズを通してあんなキレイな線になるはずがない。

image002.gif

こんな感じに。


  • テストを律儀に実施した/適当に省いた に関係なく、各テストフェーズ内でテストを繰り返す間は、曲線は次第になだらかになる。
  • だが、次のテストフェーズに以降した段階で、今までのフェーズになかったファクターが"当然"加わるため、また曲線は急勾配を描く。
  • とくにウォーターフォールでは、顧客受入れ時の要件変更のかなりの部分が「障害」として計上されるため、その傾向に拍車がかかる。


この特徴をしっかり理解しておこう。
現場ではよく「前のフェーズでテストしたのに、なぜ今フェーズでまた障害が発生しているのか」が技術者の問題として槍玉に挙げられる。(そして障害票でしっかり「反省」させられる)
だがそれは、テストのスコープも違うし、ファクターも違うのだから、発生するべくして発生した障害でしかないのだ。

ラベル:テスト TDD
posted by 未知夢 at 13:55| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月20日

開発チーム・メンバにおけるパターンとアンチ・パターン

開発現場で出会う人をパターン化してみた。
もちろん、自分の経験の範囲なので、足りない部分も多いかと思う。
たしか、こんなのをまとめた文献があったような…?

人は時として複雑で、複数のパターン兼ね備えている人もいる。良いパターンを複数持っている場合、その人を逃さないようにしよう。
良いパターンとアンチ・パターンを兼ね備えている人は、その人の重要度から判断するしかないだろう。


パターン



ここに上げる人は、ぜひチームに一人は欲しいタイプ(ライト・スタッフ)の人だ。
正直、このような人が集まると、けっこう無茶なプロジェクトでも、なんとか乗りこなしてしまう。(日本の大規模な(WF型の)開発現場は、じつは*恥ずかしがりながら**暗黙的に*この効果に頼り切っている)

■リーダ



別名



指導者、支配者、声の大きな人(※物理的意味ではなく)

特徴



役職としてのリーダと一致するかは、現場による。
ある程度技術に通じており、プロジェクトのゴールを示せる人。
また、チーム・メンバーをうまく誘導できる人。
ある程度はスキルでカバーできる。
これを天性の才能でやってしまえる人を、自分は深く尊敬する。


■サービス・エンジニア



別名



業者、業務スペシャリスト

特徴



技術には少々疎いが、かわりに開発対象とする業務に詳しい/業務をより深く理解している人。
このタイプの人は、過去何度も同種の業務の開発を経験しているか、業務プロセスの掌握が人一倍早い。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、業務用語で会話ができたり、業務プロセスに敏感になり、システム化の境界面を判断できる。
ほぼスキルのみと言ってもいい。


■アーキテクト



別名



グル、導師

特徴



技術に通じているだけではなく、その思想に通じている人。
このタイプの人は、技術を設計思想的側面から掴むのがひじょうに上手く、そのため他のメンバーより素早く習得できるという特技を持つ。
そのため、顧客(エンド・ユーザ)から要件を聞き出すさいに、技術的可能性や代替案をほぼ即答できる。
また、理論が補強されているため、他のメンバーを指導するさいも手際がいい。
ほぼ天性の才能と言ってもいい。


■ファシリテータ



別名



会議の主、教え上手

特徴



じつは教え上手なのではなく、他のメンバーに「気付かせる」ことがとてもうまい人。
抱えている課題、持っている資質に気付いた人は、能動的に動けるようになるもので、そういう意味で貴重な人。
このタイプの人が活躍すると、会議や学習会といったものがとてもスムーズにいく。
そのため、顧客(エンド・ユーザ)から要件を聞き出すのも上手いことが多い。
スキル的に身につけている人もいる。


■アシスタント



別名



サポータ、お母さん

特徴



チームのメンバーのことをよく見ていて、必要なサポートを的確に行える人。
また、会議などで今チームに必要なことを自然に提案したり、実際に実践できる人。
ほぼ天性の才能だと思うが、スキル的に身につけている人もいる。


■スター・プレイヤ



別名



スーパーマン、ギーク(※敬称的意味で)

特徴



技術に通じており、他のメンバーより数倍早く・上手くプログラムを設計していける人。場合によっては、特定の言語などに特化している人も多い。
技術のトレンドにも通じているが、時々通じ過ぎていてスケープ・ゴート化している人もいる。
このタイプの人が一人いるだけで、プロジェクトの進み方がかなり違うし、コードの整理のされ方もかなり違ってくる。
完全に天性の才能なため、とても貴重な人。このタイプの人は絶対にプログラムから離してはいけない。


■ムード・メーカ



別名



チア・リーダ、マスコット、ピエロ

特徴



チームの雰囲気をよい方向に変え、他のメンバーから慕われている存在の人。
このタイプの人がひと言口にするだけで、場の雰囲気がとても和らき、時に前向きに元気にさせる。
完全に天性の才能なため、とても貴重な人。多少プログラム設計能力が劣るからといって、追い出してはいけない。


■プログラマ



別名



コード・メーカ

特徴



スーパー・スター程ではないが、プロジェクトの対象とする技術に通じており、プログラム設計に長けている人。
このタイプとスター・プレイヤーとをチーム/バディにすると、時としてとてつもない相乗効果を発揮する。
反面、自分の持つ技術以外に対しては、意外に興味を持ってなかったりもする。
いわばチームの裏方と言ってもいい。


アンチ・パターン



これから上げるタイプは、はっきり言ってチームに障害をもたらす人だ。
もし人事権を持つならば、早目に解放した方がいい。
人事権がない/じつは立場上は上司といった場合は、ひたすら耐えるしかないのが辛いところ。

■コーダ



別名



人数合わせ、奴隷

特徴



言われた事をただこなすことを得意とする人。残業や徹夜を打診すると、素直に従う。
全体的に、作業時間は突出して多くなる傾向があるが、それに見合った生産性は期待できない。
プログラムを設計できないのもこのタイプで、指示通りに書くことを得意としている。
逆に言うと、指示しないとやらない。
しかたなく使う場合も多いが、進捗がシビアな場合は解放した方が良い結果になる。


■フォリナ



別名



部外者、傍観者

特徴



なぜか達観した態度をとる人。ときに強い皮肉を伴っていることもある。
自分の意見を主張するわけでもないため、位置づけ的にはコーダタイプに近いものがある。
もし他メンバに悪い影響があるときは、解放することも考えよう。


■ローン・ウルフ



別名



一匹狼、人嫌い

特徴



他人に溶け込むのをとことん苦手とする人。
ときにコミュニケーション不全で障害を出してしまうこともある。
ひじょうに疲れるが、このタイプの人と一緒に仕事をするときは、あらゆる手段で意思を伝え、汲み上げる必要が生じる。
もし他メンバに悪い影響があるときは、解放することも考えよう。


■ミスマッチャ



別名



場違い、畑違い、○○畑の人

特徴



開発対象に疎く、技術的にも疎いが、なぜかアサインされてしまった犠牲者。
プログラマタイプの人も多いが、大体において習得するよりも先に進捗の悪さが露呈してしまう。
コーダタイプの人物の場合は要注意となる。
なるべくプロジェクトから解放してあげた方が、お互い幸せになる。


■フォーチュン・テラー



別名



不安屋、諦めた人

特徴



何が原因かはともかく、プロジェクト/チームに対して強い絶望感を持った人。
無茶なチーム運営の犠牲者である場合も多いが、元々の思考的にこうなっている人もいる。
このタイプはそのネガティブな雰囲気を周囲に撒き散らし、巻き込んでしまう。
パターンに上げた人がこちらの側(ダーク・サイド)に転化してしまうと、そのインパクトは大きい。
なるべく早くプロジェクトから解放してあげよう。


■トリックスター



別名



反抗期、天邪鬼

特徴



なぜかチームの方針に事あるごとに楯突く人。
このタイプは、チームやプロジェクトが上手くいっているかよりも、自分の考えていることが反映されているかを最重要視する。
その考えもコロコロと変わる場合、他メンバーを翻弄して疲弊させる。
なるべく早くプロジェクトから解放しよう。


■スタンピード



別名



暴走、暴徒

特徴



プロジェクトやチームに関係なく、自分のやりたい事をやり出してしまう人。
これも無茶なプロジェクトチーム運営による犠牲者の場合も多いが、自分の技術力を誇示したいだけの場合もある。
ローン・ウルフタイプを伴い他メンバから倦厭されたりする。
プロジェクトと関係ない事をやっているだけなら利も害も生まないが、プロジェクトに関係するところをやり出すと被害を出しかねない。
なるべく早くプロジェクトから解放しよう。


posted by 未知夢 at 15:46| 東京 ☀| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月18日

なぜUnitTestは理解されない?

TwitterでこんなTweetが流れた…
エビデンスとしてNUnitのGUIのスクリーンショットと、対応するテストコードが含まれている部分のVSのスクリーンショットを取る作業が終りません・・・

UnitTestのエビデンスって…なに?



一般的にテストのエビデンスというと、次の2点を指す。

  1. テスト手順を明らかにするもの(ex. テスト設計書、テスト仕様書、...)
  2. テスト結果の証拠(ex. 画面ハードコピー、DBスナップショット、...)


UnitTestでは、これはこのように解釈できる。

  1. テスト手順を明らかにするもの = テストコード
  2. テスト結果の証拠 = 今実行すればテストが全てグリーンになること


これがなぜか理解されず、軋轢とストレスと大きな工数追加になっている現場がずいぶんある。
なぜUnitTestはいつまでも理解されないのだろう。

余談。これらのことは、Seleniumなどを使って反復可能なテスト(一応結合テストにあたると思う)を実施する場合にも当てはまるようになる。

微妙に食い違う認識


テスト実施の時期に対する認識



テストを実施する時期…古典テスト方法では、これはいつでも「テストを実施した時点」であった。これがテスト自動化の登場・一般化で覆された。
自動化され反復可能になったテストでは、テストを実施する時期は「いつでも」になった。つまり「今動くこと」が重要になったのだ。
これがパラダイム・シフトになった。

従来の手動駆動テスト手法



  • テストを実施したタイミングでのエビデンスが、必ず残っていた。
  • そのエビデンスは必ずエラーを含み、実施を重ねるごとにエラーが少なくなっていく現象が見えた。
  • テスト・エビデンスを追うことで、時点ごとに(スナップショット)「テストがどういう結果になったか」をチェックできた。
  • 障害収束曲線(ほらこれだ!)を「計測」でき、それによって「テストの充実度」を間接的に観測できた。


反復可能なテスト自動化



  • テストは常に動いているため、今現在のエビデンス(オール・グリーン)以外(要するに過去の結果)は重要ではなくなった。
  • テストは常に動かせるため、コード作成とともにテストするように手軽になった。
  • コード作成とテスト実施を同時に行うため、コードの完成と完璧なテストが同じタイミングで揃うようになった。
  • 障害収束曲線は決定的に意味がなくなった。


コードというものが何かという認識



ここには、古くはクヌース先生等の時代から続く宗教戦争の歴史がある。

従来の、とくにウォータ・フォール型開発においては、コードというものは「最終成果物」であり、それは「製造」の結果でしかないとみなされる。
製造物のクォリティは「テストを通るか(条件を満たしているか)」のみが重視され、コード内部の整合性についてはほとんど重視されないようになった。
この視点で見た場合、UnitTestのような「コードで記述されたもの」は「余計(余分)な成果物」以外の何物でもない。

しかし一方でこれを戒め、「コードは一番詳細で唯一実行可能な設計書である」とする一派が従来からいた。この従来からある主張が、UnitTestの登場で大きく花開いた。
コードの設計書的側面が、テストによって補強される現象がおこった。
TDD/BDDでは、コードはテスト可能なまでに整理されることが前提となり、実施者は誰もが整理されたコードを書くようになった。(よく逆に考える論者(きれいなコードを書ける技術者しかTDD/BDDは実践できない)がいるが、それは違う)
そして、テスト・コードがインタフェースの詳細な仕様を表明するようになった。これがどのようなコメントよりも有言なことが確認されるやいなや、いわゆる詳細設計書を駆逐するのはおろか、コメントさえも駆逐しかけている。

何にバグが潜むのかという認識



ソフトウェア開発で不文律とされているものに「コードにはバグが存在する」というものがある。これには誰も異論がないだろう。

手動駆動テスト手法においては、その反復性の低さから「すべてのコードにはバグが存在する」という認識が強い。
バグが発生した時にそれを修正するとおこる、デグレードという現象もこの認識を補強することになった。
この認識に立っている人物は、UnitTestによるテスト・コードにもバグが潜んでいるのが当然だ、という見方をしている。テスト・コードは信頼できないものにしか見えない。

テスト自動化で反復可能になると、それが肌で感じられるほどに明らかになったことに「テストしていないコード・条件にこそバグが存在する」ということだ。
デグレードはヒューマン・ミス以外にはほぼ発生しなくなった。
この認識に立てると、コードの完全性をテスト・コードに依拠するようになる。そして、ガンガンとコード改善に手を出せるようになる。

テスト・コードにはバグはあるのか



はたしてテスト・コードにバグはあるのか?
以下の視点でみた場合、テスト・コードにしても相変わらず"バグ"はある、と言わざるをえない。

  • テスト内容に抜けが発生する可能性がある。
  • テスト内容に間違いがあり、その間違いを見逃す可能性がある。(偶然に結果が一致する場合に多い)


だが、これらはUnitTestだから起こるという類のものではなく、手動駆動テスト手法においても、十分起こり得るものだ。
そのため、これをもってUnitTestを無効だと主張するのは無理がある。

そして重要なことだが、次の点は完成した状態のUnitTestでは起こらない。

  • テストが動かない。
  • テストが誤動作する。


なぜ起こらないと宣言できるのか。それは、UnitTestにおいてはテスト・コードは100%通るからだ。カバレッジ率100%というのは実コードではなかなか難しい課題だが、テスト・コードにおいては誰でも完璧にその状態にできる。
そしてもうひとつ、テスト・コードは従来にないほど繰り返し実行される。この反復実行がまた、テスト・コードを頑強にする。

開発者は都合の悪いことには目をふさぐ?



よく言われる批判のひとつに、「開発者は都合の悪い部分をテストから無意識に排除する性質がある」というものだ。
だが、これらは原因がはっきりとしている。

  1. そもそも気づいていない。
  2. インタフェースに対する認識の低さから、インタフェースを満たすようなテストを行えてない。
  3. 反復性の低さから、一度通ったテストを省略する衝動に駆られる。


最初の問題はもう、どんなテスト方法をとっても検出はムリだ。
二番目の問題は技術者の一定の訓練・経験を必要とするが、UnitTestの方がダラダラ書きができなくなりインタフェースへの意識が高まるため、UnitTestを行うことでより強力に訓練できる。
三番目の問題は反復性を高め常時実効するUnitTestではおこらない。


どう立ち向かうか



味方にしてしまおう



まず、理解していない人には十分に反復テストを理解してもらう努力をする必要がある。

  • UnitTestの場合は、それが「単体テスト」であり、手でやってもコードでやっても開発者が主体でテストしている事に変わりないことを理解してもらう。
  • Seleniumなど結合テストの自動化の場合は、従来テスト設計書でシナリオを用意してやっていたことを自動化しているにすぎないことを理解してもらう。


そのために、次のように働きかけるのはどうだろうか。

  1. まずテスト・コードを見てもらい、どの部分がどのような事をやっているか概要を説明する。
  2. じっさいにテスト・コードを実行し、テストがすべて成功する瞬間を見てもらう。
  3. 目の前でTDDを実践し、テストが失敗から成功に移り変わる様子を見てもらう。


現場に近い人間ほど、上記を目の前にし「TDDを体験」することで認識を改めてくれる傾向がある。
残念ながら、現場から遠くなるにつれてその人物のアンテナの感度がより重要になってくるようだ。

CIサーバを立てよう



Hudsonのような本格CIサーバでもいいし、スケジューラでバッチを使ってAnt(NAnt)を定期的に実行するようにするのでもいい、またAntを手動起動するのも手だろう。
とにかく、次の手順を自動化してしまう。

  1. ビルドを実施する
  2. テストを実行する
  3. テスト結果をHTML形式で出力する(最近のUnitTestとAntの組み合わせではほとんどのもので可能なはず)


これだけで、テスト毎にエビデンスを残すとか障害収束曲線の判断元がほしいといった要請には対応可能だ。

また、Seleniumなどは画面ごとのスナップショットを保存するような改造もWeb上で公表されている。積極的に活用しよう。

結合テストを強くする



自動で結合テストをしようが、手動駆動テスト手法で結合テストをしようが、結合テストという視点は大事だ。
Agileではこの時に顧客サイドに使用シナリオを書いてもらう、リアルなテストを行うプラクティスがある。
個人的には、より結合テストを強固にするためには(予算との兼ね合いもあるが)、これに加え、やはり「危険な匂いを感じ取れる」職人気質なテスト技術者を招きいれ、シナリオ作成に参加してもらうのが良いと考えている。
またそのうえで、反復しないテストの実施を職人テスト技術者に行ってもらうのがより望ましい。
これをモンキー・テストと言ってバカにする傾向もあるようだが、やはり人間は、実際にアプリケーションを使ってみて初めて気づく、というものがある。
ただし、これを行う場合、テストに失敗したものは自動テストシナリオに組み込む、というタスクを忘れてはいけない。

最近の経験から



最近の経験で、技術者たちの頑迷な強い抵抗に合い、UnitTestを導入できない、という事があった。
仕方なくUnitTestを捨て、従来のようにテスト・フェーズを厚くする手法に切り替えた。(顧客の強い要望により、WF形式での開発だった)
その結果、何がおこったか。
メンテが難しいほどに長い「メソッド」の乱立。
バグを修正するたびに起こるデグレード。
いつまでも終わらないかに思えるテスト・フェーズ。

システムは苦心惨憺の末に大改造して納品した(あらためて書き上げたUnitTestと一緒に)。だが、短い開発期間だっただけに、この時の開発-テスト・フェーズは完全に失敗だった。

TDD/BDDを実践しようとしている人は、それが絶対的に正しい行為だと自信を持ってほしい。
結合テストの自動化を目論んでいる人は、それが絶対的に正しい行為だと自信を持ってほしい。
それはシステムを迅速に仕上げる助けになるだけでなく、システムの品質をより高みに置こうとすることなのだから。
ラベル:Agile応援団
posted by 未知夢 at 12:46| 東京 ☀| Comment(1) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

2009年12月17日

朝会のアンチパターン

この文章は、Twitterでちょっと盛り上がった朝会のアンチ・パターンについて、勝手にまとめ、補足したものです。

朝会のあり方については、M・ファウラー氏の「朝会のパターン:立ってるだけじゃないよ」や、オブジェクト倶楽部の「プロジェクトファシリテーション実践編:朝会ガイド」(PDF)を参照してください。

運営に関するアンチパターン



座ってやっている


フォース


報告が詳細になりすぎている。時間がかかりすぎている。そもそも場所がない。

対策


立って開催することを呼びかける。
ただし、諸事情でどうしても立ってできない場合は、なるべく短くなるように全員が心がける。

シーンとしている


フォース


朝会全体に威圧的な雰囲気、または陰鬱な雰囲気ができている。プロジェクト進行がうまくいっていない。

対策


朝会を行う意義をもういちど全員で確認する。

その他


朝会以前にプロジェクトの建て直しをはかる。

誰も他人の言う事を聞いてない


フォース


朝会で報告することが毎回多すぎる。他メンバーの状況を把握すると自分に仕事が降りかかる。

対策


朝会で言うべきことを整理し、意思統一する。
ファシリテータは朝会が仕事振り分けの場ではない事を徹底する。

最初か最後にリーダーのご高説が入る


フォース


朝会をトップの意思を伝達する場と勘違いしている。

対策


朝会を朝礼と勘違いしない。
ファシリテータはリーダーが演説を始めたら止める。
上記参考文献をファシリテータ・リーダー自ら読み直すこと。

責められる


フォース


朝会が進捗の責任追及の場に転化してしまっている。

対策


他者が報告中は口を挟まないように徹底する。
ファシリテータはリーダーの言動に暴走が見られた場合、注意を喚起する。

その他


リーダーは報告者が報告してくれたことにまず感謝するクセをつける。

そもそも二度手間


フォース


他に日報・時報で作業状況を提出しなければいけない。その時間が業務時間内に保障されているわけでもない。
メンバーが状態を共有するのを苦痛に感じている。

対策


週報、日報をやめる。

その他


諸事情でやめられない場合、週報、日報を全員に開示する方法を検討し、そちらを優先する。

しゃべるメンバーが偏っている


フォース


朝会を自分の意思を伝達する場と勘違いしている。自
己アピールの場と勘違いしている。

対策


ファシリテータは報告の時間を短く区切り、計測する。(30秒以内が妥当)
他者の報告への口出しは朝会の解散後とするよう、徹底する。

@holic



報告内容に関するアンチパターン



問題点のあり/なしを言わない


フォース


うまくいかないのが自分のせいか対象のせいか切り分けできていない。作業報告の中に混ぜてしまっている

対策


問題点はどんな小さなものも報告するよう徹底する。
ファシリテータが報告のなかから問題点をみつけ、指摘する。
本人が問題点に気づくよう、粘り強くファシリテートする。(「困ってることはありませんか?」と尋ねるなど)

@kkd



遅れているか、進んでいるかが重要ポイントになっている


フォース


朝会を進捗掌握の場と勘違いしている。

対策


朝会の報告内容を「やった事」「やる事」「問題点」に絞るよう徹底する。
ファシリテータは朝会で進捗の話が出たら、注意を喚起する。
その他
リーダーは普段から「進んでいるか/遅れているか」と聞くのではなく、「期日に間に合うか」と聞くクセをつける。
そもそもの進捗管理をパーセンテージ主義から成果物主義へ移行する。

メンバーに関するアンチパターン



実施に反抗的なメンバーがいる


フォース


朝会の利点が理解できていない。
朝会が朝礼化してしまっている。

対策


朝会の意義をメンバー全員で徹底的に論じ合う。
上記テキストも活用する。

恒常的に特定メンバーがいない


フォース


ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策


特定メンバーに高負荷がかかりすぎてないか注意する。
特定メンバーというのが大多数ならば、朝会の意義、重要性を再確認する場を設ける。
特定メンバーの悪癖の場合は、ファシリテータがきちっと注意する。

恒常的にリーダーがいない


フォース


ムリが続いてプロジェクトが疲弊している。
朝会が形骸化してしまっている。

対策


リーダーに高負荷がかかりすぎている場合、リーダーは積極的にメンバーに仕事を任せるように対策をとる。
リーダーの悪癖の場合は、ファシリテータが注意する。もしくはリーダーに対する監督権限がある人物に相談する。

朝会はプロジェクトがうまくいくための重要なプラクティスですが、それでも「うまくやるひとつの方法」でしかありません。
もしメンバー全体が朝会そのものに疲弊してしまっているなら、いちど廃止することも検討しましょう。

なお、各内容についてはご意見上等です。
posted by 未知夢 at 13:49| 東京 ☁| Comment(2) | TrackBack(0) | Agile応援団 | このブログの読者になる | 更新情報をチェックする

原点

本当に久々の更新。
自分が腐りそうだから、というのは内緒。

自分のプログラムの原点。

最初は中学生のころ。ファミコンが普及し、売れまくっていた時代。古いね。
当時、友達がそのファミコンを手に入れ、一緒にソフトを一本買った。
スーパーマリオだ、なんだと周りが騒いでいた時にそいつが買ったのが、「ファミリー・ベーシック」だった。どうにも渋いね。

でも、それがコンピュータ初体験な二人には新鮮で、二人して雑誌とにらめっこしてソースを打ち込んだり、ソースの改造をしたりして明け暮れた。
上半身がマリオで下半身が戦闘機のヘンキャラを作ったりとかねw
当時はゲームも作ろうとしたけど、そこまでの力がお互いになくて断念したな。たしか疑似3Dシューティングができないか?とかムチャなことを考えていたようなw
でも、コンピュータの動作を自分の意思で変えられる、制御できる、という魅力にこの時とり付かれたのは確かだ。

高校に入って、ムリしてMSX2を買った。自分の全財産で。当時はいた彼女にモーレツに怒られ、すねられたのは余談w
当時はMSXマガジン、MSXfanという2大専門誌が発行されていて、MSXはちょっとした盛り上がりを見せていた。
とくにMSXfanで流行っていたのが、1ページプログラミング。あらゆるテクニックを使って1ページに収まる量にコードを縮めるその遊びは、ときにマシン語が入り、ときにそれをVRAM展開し、といったひじょうにこった物が多かった。
当時はただただ「世の中には凄い人達がいるな、こういう人がプロになるんだろうな」と思いつつ、サルのようにソースを打ち込んでた。

その中に、「ホンモノのプロ」が作った、パズルゲームのちょっと長めのソースが公開されたことがあった。
「なんだこれ?」読んでみて落胆した。
「俺にも読めるし、この程度だったら書けるよ。プロってこの程度?」
そう、そのソースはあまりに読みやすかった
そして、実行速度もさほど悪くはなかった。
とりあえず打ち込んだ。
遊び倒した後は改造した。なにせ自分で書ける程度のソースだ、手を出さないわけにはいかない。
キャラを変え、ルールを変え、とにかくごちゃごちゃといじった。やがてソースは汚く変形していき、改造不可能になった段階で放り出した。

このプログラムと出会えなかったら、たぶんコ業界に入ろうなんて思わなかっただろう。
そう思わせたのは、Cを学び出してからだった。
ようこそ、構造化プログラミングの世界。すべてを整理整頓できる世界へ。
ロジック本を読んだ。プログラム書法を読んだ。無我夢中で吸収した。そして気づいた。
そうか、わかりにくいテクニックを駆使するのではなく、わかりにくいロジックをなるべくわかりやすく書く、それができるのがプロなんだ!
何かが変わった。プログラムに対する姿勢だろうか。その時、あの「ホンモノのプロ」がつくったソースの偉大さを知った。
十分にわかりやすく、そして十分に実用的。単純なBasic文だけを使い、それを果たしていたのだ。
それを弄繰り回して冒涜していた自分の行動に笑った。
快くソースを公開したプロの心意気に感じ入った。おそらく、当時のやもすると裏技的テクニックだらけが推奨されるような印象のあったアマチュア・プログラマーに、何かを伝えたかったのだろう。ソースのかたちで。

これが自分のプログラムの原点。
もうプロの道に足を入れて、長い月日が経った。
自分ははたして、あの時のプロに追いついたのだろうか?
posted by 未知夢 at 12:21| 東京 ☁| Comment(0) | TrackBack(0) | システム開発 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は90日以上新しい記事の投稿がないブログに表示されております。