人材育成、講師の視点から（3）
こんにちは、天野勝です。
わたしは、コンサルタントという職業柄、人にものを教える「講師」という仕事をすることが多いです。現場カイゼンの導入教育や、C言語でのテスト駆動開発と、かなり多岐に渡っています。
この連載では「講師」をしていて気づいたことをわたしの視点で発信していきます。
■アジャイル開発は特別か？
XPが書籍として紹介されてから約10年が経ち、アジャイル開発が広く適用されるようになってきました。おかげで、アジャイル開発について教えて欲しいとセミナーの依頼も増えてきています。
そこで出る質問にある一定の傾向があります。アジャイル開発は特別なのかという類の質問です。
XPアンギャ[*1]をはじめ10年近くアジャイル開発に関連するセミナーを行っているわたしの感覚では、そう特別なことを行っている感じはないのです。要件定義もしますし、設計もテストも行います。それぞれは、ソフトウェア開発に必要な活動です。
■現場で混乱が起こる理由
しかし、アジャイル開発は特別ではないといっても、実際に現場に適用すると混乱が起こることがあります。これは、アジャイル開発の多くが、開発者視点で語られていること、さらにスキルセットがそろっていないメンバーでチームを構成することに起因しているからだろうと考えています。
アジャイルチームの特徴として、チームで要件定義からテストまでを担当するというのがあります。なかなか最初からスキルがそろったメンバーでチーム構成するのは難しいものです。育成のループがアジャイル開発には組み込まれていますが、いきなり成長することはありません。テストの自動化に手をつけても、スキルがあまり高くない状態では、技術的負債が積まれていってしまい、しばらくしてから自分達の品質や生産性の足かせになってしまうこともあります。リファクタリングをすればよいのですが、それなりのコストは覚悟する必要があります。
また、テストに関するスキルが不足していれば、せっかく作ったテストケースも役に立たないということもあるでしょう。
さらに、チームに自律性を持たせて、指示待ちの受け身な仕事の仕方ではく、主体性を持って積極的に仕事をしていくというのも、これに拍車をかけます。
積極的に仕事をするというのは理想的な仕事の進め方なので問題ないのですが、チームの活動に介入しにくくなるというのが問題です。自主性に任せてチームが気づくまで待つという方針は誤りではありませんが、有効な場面とそうではない場面があることを理解して上で使う必要があると考えています。
自分達が知らないこということすら知らない状態では、ある課題に対して良い解決策があったとしても、その解決策に達するのに時間がかかるか、そもそも使えないのです。新しいやり方に馴染みやすいだろうという配慮から、若手のメンバーでチームを構成するとこのような理由から、混乱が起きてしまう確率がぐっと上がってしまいます。
また、繰り返し型の開発ゆえの落とし穴として、これまでうまくいっていたと思うことを、そのまま続けて思考停止状態になっていることもあります。課題があることに気が付ければ、改善できるのですが、そもそもその課題にすら気づけない状態というのがあるのです。
■どうすれば混乱を減らせるか
わたし自身が講師の立場というのもありますが、必要な教育を受けることが1つの解決策であることは確かです。あまりにも当たり前の事過ぎて、拍子抜けしてしまったかもしれません。しかし、これまでのアジャイル開発を教えてきた経験では、アジャイル開発の前にソフトウェア開発の基礎知識が必要だと感じています。
ソフトウェア開発の基礎知識には、要件定義から、テスト、運用までに多岐に渡ったものです。いわゆる、「ソフトウェア開発ライフサイクル」に含まれる範囲です。それぞれを深いところまで学ぶ必要はありません。まずは、広く浅く学び、今どのような課題があるかについて気づけるようになるレベルまで学ぶ必要があると考えています。
[*1] XPアンギャ http://ObjectClub.jp/event/angya/