JaSSTでアジャイル的なテストの話を聞いた

2010/1/28(木)にJapan Symposium on Software Testing、通称・JaSST(ジャスト)に参加してきました。
遅ればせながら、各セッションのまとめと感想を書きたいと思います。
ちなみに、JaSSTは2日に分かれて行われています。
私は1日目のみ、参加しました。

シンポジウムの話を聞いた感想は

「品質」をつくりこむことにもアジャイルの考え方は有用
テスターはだんだんと滝の上流に向かおうとしている
技術者として胸の晴れる技術を身につけるべき

というものです。
1日目の基調講演、ならびにチュートリアルでは、Johanna Rothman(ジョハンナ・ロスマン)氏のお話を聞いたのですが、その内容はアジャイルの考え、手法を色濃く反映されていました。
また、ライトニング・トークスでも、トーカーの方々が、お話の中でアジャイルのプラクティスに触れるなど、全体的にとてもアジャイル色の濃い内容になっていました。

アジャイルというと、ある点からは「乱暴」「乱雑」というイメージがあり、「きっちり」「しっかり」というイメージの「品質管理」「テスト」と相容れない、とテスターの人からはうけとめられているのかな、と思っていました。
しかし、現在進行形で品質管理に携わる人々も、アジャイルの考え方や手法の有効性を取り入れようとしている、ということを知ることができました。

<基調講演ではAgileな教訓を学ぶ>
基調講演は、Johanna Rothman氏(以下、Rothman氏といいます)が、経験を元に、ソフトウェア・マネジメントについて17の教訓を紹介する、という内容でした。
ソフトウェア・マネジメント、ということから、開発者とテスターに関係なく、ソフトウェア開発に携わるすべての人間にとって役に立つ内容でした。
Rothman氏の経験から得た教訓が、その経験からアジャイル的な考え方やプラクティスに近いもの近づいていったのか、もしくは、経験の途上で意識的にアジャイルを取り入れたのか、そうしたことはわかりません。
が、内容の柱は、アジャイルの考え方やプラクティスを中心にすえていたようにおもいました。

個人的には、以下の話が印象に残っています。

◆優秀なマネージャとスタッフは大幅な改善を促す
改善を促す、とはいえ、何の改善を促すのか、その主語がわからなかったのですが、仮に「チームのパフォーマンス」として話を聞いていました。
話によると、
・プログラムの再利用は350パーセント
・優秀なマネージャは65パーセント
・優秀なスタッフは55パーセント
・プロセスの改善は35パーセント
それぞれ改善を促進する、というものでした。

私が注目したのは、優秀な人材による改善率の高さが、プロセスによる改善率の高さを上回っている、ということでした。
というのは、プロセス改善によってこそが、大幅なチームのパフォーマンスが改善される、と思い込んでいたからです。

個人的に、アジャイル、とりわけスクラムは、チームにおけるプロセス改善を主眼においている、感じていました。
もちろん、プロセス改善を導入することで、個人、個人の能力が向上してゆく、ということもあり得る、とも思っていました。
が、基本的には、スクラムなどの一定のプロセスにしたがっていることで、どのような能力・スキルセットのメンバーが集まっても、チームのパフォーマンスが改善される、と思い込んでいたのです。

いまでも、この考え方が間違っている、とは思っていません。
しかし、Rothman氏のお話を聞くまで、

チームを構成する個人、個人が成長しない限りチームの改善はありえない

という単純な事実を、私は忘れていたのです。

アジャイル、スクラムなどによってソフトウェア開発のプロセス改善を促そうと思ったところで、チームのメンバーがそのプロセスを前向きに受け入れられなかったり、必要な学習プロセスを拒否してしまったりすることで、プロセス改善の道は簡単に途絶してしまうのです。
プロセスの改善は、チームのメンバーを選ばず、ある種、その型にはまることで、チームの能力を向上させる、というものです。
ですが、その過程では、かならずチームメンバーの成長、能力の向上やスキルセットの変更、価値観の変更、が求められます。

少なからず、アジャイルやスクラムによるプロセス改善は、かならず個人の能力の成長を求めるものだと思います。
そして、いかなるものであれ、プロセスの改善に伴う変化へ対応する必要があります。

優秀な人材ほど、成長にたいして前向きで、変化には柔軟に対応できます。
こうした点から、プロセスよりも人の能力改善、および優秀な人材の投入が、チームのパフォーマンスの改善を促す、ということに納得がいきました。

プロセスの改善は優秀な人材を生み出す仕組みとなりえる一方で、優秀な人材により促され発展してゆく、人材にも依存するものなのです。

◆「人を増やせるならどういったメンバーを受け入れたいか」を常に考えておく
これはRothman氏の話を聞いていて、おもわず「はっ」とされられた部分です。
この視点は、

今のチームに必要な要素は何か

言い換えれば、

今のチームの弱点は何か

というものである、と感じたからです。

もちろん、人事権をもつマネージャであれば、Rothman氏の言葉をストレートにとらえてしまえばよいとおもいます。
しかし、私は人事権をもたないので、組織において人材を左右する立場にはありません。

ですので、上記のよう視点を変えて、チームが必要としている要素、弱点を見極めるための「問いかけ」として使ってみたいと思います。

◆毎週、人にあう
お話の途中では、チームに会わない人は「クビ」にする、という考え方も示されました。
しかし、これはあくまでも、チームメンバーとの頻繁なコミュニケーション、およびフィードバックが前提とされています。
Rothman氏自身も、あまりにフィードバックのなさに、「自分が大切されていない」と感じて転職された経験があるそうです。

チームのミーティングで「みんな」で顔を合わせて話し合うことも重要ですが、1対1でのコミュニケーションの重要性を、Rothman氏は特に強調されていました。

確かに、そのフィードバックが良いものであれ、悪いものであれ、ちゃんと事実に基づいたものであれば、ある程度、納得もできますし、自分自身の改善にも活かせます。
また、良いフィードバックはチームメンバー前でも本人にとって良いものになるでしょう。
しかし、悪い点を指摘するものにかんしてはチームメンバーの前で行ってしまうと、フィードバックされた本人にとっては屈辱であり、傷つくものになってしまいます。

加えて、良い点のフィードバックしかせず、悪い点をフィードバックしない、ということも、問題になります。
まったく悪い点をフィードバックしない、ということは、その人が自分の悪い点を改善する機会を奪ってしまいます。
そして、その機会を奪っておきながら、あるとき能力不足などを理由に「クビ」する、という不意打ちを行うことになります。

なによりも、まったくフィードバックを行わない、ということは、その人の行動や存在を無視している、というメッセージを発していることになります。
それは、Rothman氏が転職してしまったように、大変なダメージをメンバーに与えてしまうことがあるのです。

アジャイル、スクラムというと、毎日、朝会、簡単なミーティングをおこなっているため、頻繁にコミュニケーションをとっているように思えます。
それは、おそらく通常の開発チームよりも多くのコミュニケーションを生んでいるのだと思います。
しかし、毎日の朝会だけでは、メンバーとの良好なコミュニケーションを維持するのには足りていないのです。

ちょっとした休憩に、机にいるメンバーに話しかける、というのも良いコミュニケーションのひとつ、だとは思います。
が、実際に仕事中に話しかけられることが、嫌な場合もあります。プログラミングのときや障害対応をしているときなどです。
そうしたときは、良好なコミュニケーションを行うことはできません。
そのようなことになるよりは、正式な話し合いの場をちゃんと用意して、きちんとフィードバックするという習慣を、チームの中で設けるべきだと思います。

◆チームのメンバーを簡単に動かしてはいけない
Rothman氏は、難しいが、長年、同じチームにいても個人の個性を保つことはできると言います。
そして、組織全体がチームのメンバーを動かすことを常態化することによって、プロジェクトごとにチームビルディングが必要になってしまう、コストを強調していました。
ただし、チームとして硬化しないように、チームのスキルセットや人の本性に根ざしている個性が違う人をメンバーとして組み込むことを提案していました。

しかし、私は、この点についてかなり懐疑的です。
というのは、チームが硬化してしまう、ということはなかなか防ぎようがない、ということを、私は感じているからです。
私はすでに稼動して15年近くになるシステムの開発および、保守に携わっています。
長い人では10年を超えて、その開発および保守に携わっています。
こうしたチームにおいては、「暗黙の了解」がチームの支配しがちです。
そして、この「暗黙の了解」こそが、チーム内において知識の属人化を進めたり、チームの硬化をまねく原因になります。

チーム内で「暗黙の了解」が成立する、ということは、むしろ良いことだといっていいはずです。
むしろ、「暗黙の了解」が成り立つからこそ、長い期間、同一のメンバーでチームを構成している意味があります。
ですが、知識が属人化しがちなことは避けられません。
これは、アジャイルかウォーターフォール(以下、WFといいます)にかかわらわず、かなりうまい仕組みづくりを行い、かつ、仕組みがうまく働いているかの絶え間ないチェックが必要になります。

知識が属人化してゆく背景には、「信頼」という暗黙の了解が働きます。
ある人がある業務にはすごく詳しい、ある技術にすごく詳しい、ということがチーム内に認知されてしまうと、暗黙的にその人が詳しい部分について抱え込みがちになってしまいます。
格好よく言うとスペシャリストです。
そして、いったんスペシャリストが認知されると、そのものごとに関しては、「スペシャリストが行えば良い」「自分がそれほど詳しくなくても良い」という雰囲気が生まれがちになります。
そうすると、スペシャリストはさらに「自分が詳しくなければ」という意識が働き、よりいっそう知識を高めてゆきます。
そうすると、チームメンバーは、さらにスペシャリストまかせになり。そうすると…、といったように、徐々にものごとはスペシャリストに集中してゆきます。

こうした状態がさらに進むと、あるものごとを判断するのは、特定のスペシャリストだけになります。
そうなるとチームの決定や行動自体が属人化して行き、ついにはチームの意思決定や判断は硬直し始めます。
というのは、特定のスペシャリストのみが判断を下すための知識を持っており、そのため声も一番大きくなるからです。
また、周囲のメンバーには、スペシャリストの得意分野に切り込んでゆくための知識も自身もなくなってしまっているからです。

たしかに、ペアプログラミングなど、アジャイルには知識の共有をはかるためのプラクティスも存在します。
また、単に知識を集中させたくない、チームの硬化をさせたくない、という理由だけで、人を移動させることは、とても乱暴な解決策だといえます。
もしかしたら、Rothman氏がチームを解散させてはいけない、というのは、知識の属人化やチームの硬化を防ぐという理由だけで、そうしてはいけない、という意味なのかもしれません。
チームのメンバーが固定化しているから、知識の属人化やチームが硬化するのではありません。
チームの硬化を防ぐための適切な仕組みがないために、知識の属人化やチームが硬化するのではないでしょうか。

とはいえ、そのことについての有効な仕組みとはどういったものでしょう。
しかも、人を入れ替えることなく、という方法で。
また、仕組みをつくったとしても、今度は、その仕組みが陳腐化していないか、などを見直す必要も出てくるでしょう。

私は、その仕組みのひとつに、「人が入れ替わるかもしれない」というプレッシャーも、必要なのではないか、と今のところ考えています。
みなさんは、どのようにお考えになるでしょうか。

<技術力のともなった技術者でありたい>
基調講演を聞いた後、思ったことは、

自分は技術者として有効な技術力をチームにもたらしているか

ということでした。

現在の会社に入社して以来、汎用機での開発に携わってきた私は、技術的に現在の技術をキャッチアップできていない、という劣等感があります。
先日まで、ちょっとしたゲームのWebアプリの開発に携わっていましたが、自分に技術力がないのが良くわかりました。
アジャイルであれ、WFであれ、技術者が提供するのは、技術力が基礎となるはずです。
これを無視してはいけない、そう思うようになりました。

私は、ビジネス・マネージャでもなく、さりとて現在の中心的な技術に携わるSEでもありません。
技術者でありながら、技術に疎い立場です。かなり中途半端な、立ち位置いる技術者です。
ですので、技術のわからない人が、プロジェクト・チームに入っていることの戸惑いがわかります。
一方で、技術のわからない人が、プロジェクト・チームにどのような影響を与え、メンバーの精神状態を悪くするかもわかります。
こうした立場の人たちをつなげる役割をにないたい、と考えていました。

が、その役割は、技術力をもっていてもできるのです。
プロジェクトにおける人系のスキルというのは、システム的なスキルをもたない人間のために、あるわけではありません。
なにより、システム開発というプロジェクトにおいて、チームメンバーに認めてもらうためにも、自信をもってチームメンバーにサジェスチョンを行うためも、システム的なスキルにおいて自信のもてる分野が不可欠だと思います。

Rothman氏の話を聞いていて、技術者としての自分の立脚点を確保したい、そのように強くをおもいました。

ちなみに、基調講演の俯瞰的な内容は、以下のURLで簡単にまとめられています。さすがプロ、簡潔ですね。
http://journal.mycom.co.jp/articles/2010/02/01/jasst/index.html

本当は、チュートリアルの感想、さらにLTの感想も書きたかったのですが、力尽きました。
後日、今週中にでも、つづきを書いてみたいと思います。

文頭に書いた結論のフォローもできてないですしね。

◆JaSST公式サイト
http://www.jasst.jp/

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

タグ:

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。