|
巷で流行りのアジャイル。取り入れてみたいけれども不安がいっぱい、取り入れてはみたもののうまく行かない、そんなことを考えてはいませんか？
正しいアジャイルって何でしょう。ここでは、みなさんのそんな質問にお応えします。
2004年に公開した「アジャイル勘違い集」ですが、公開してから10年経ちましたので、内容を再検討しました。
|
|
|
|
| Q. |
アジャイルって、やる気さえあれば誰でもできるんですよね！
|
| A. |
やる気さえれば誰でもできますが、誰でもがすぐにできるわけではありません。できるようになるまでに、時間がかかる人の方が圧倒的に多数派です。
やる気のある人だけでチームを組んでアジャイル開発をすることを前提とします。このようなチームであれば、コミュニケーションにまつわる問題は少なくなると想像しがちですが、実際はそのようなことはなく、連係ミスなどが発生することは珍しくありません。コミュニケーションに関してだけでも、チームがアジャイルやっているという状態になるには時間が必要です。
また、後発の要求に耐えられるようなシステムやソフトウェアの構造をつくるには、それなりのスキルが必要であり、このようなスキルはやる気だけではすぐに身に付けることはできません。
しかし、やる気を持続していければ、いつかはアジャイルにやれるようになるはずです。
そもそも、「アジャイル*を*やる」ということ自体が勘違いです。開発を成功させるために関係者が一丸となって「アジャイル*に*やる」というのが、アジャイル開発の本質です。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルって、デキる人・優秀な人・ベテランにしかできないんじゃないの？
|
| A. |
アジャイル開発では、チームの総和でデキるかどうかを考えます。デキる人達が集まっても、互いの力を出し切れず、チームの総和としてはそれほどではないということもあります。そもそも、デキる人が集まってチームになるということはめったにありません。
ごく普通の人達が集まり、互いが良い影響を与えあって、チームとして力を出せるようなれるのが、アジャイル開発のメリットの一つです。
しかし、あまりにもデキない人達だけでチームを組むという場合は、対策が必要です。
チームの中で知識が流通することで、互いと知識が増えて行くのですが、その知識があまりにも少なく、そもそも流通する知識がない場合は、チームの近くに必要な知識を提供してくれる人を置くことを、オススメします。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルプロセスはドキュメントを書かないと聞きました。そんなプロセスは不安で採用できませんよ。
|
| A. |
これは、アジャイルソフトウェア開発宣言の「包括的なドキュメントよりも動くソフトウェアを」というのを勘違いしているようです。これは、アジャイル界の都市伝説です。
これは「ゴールに向かって、本当に必要なものを考えて作る」ということを示唆しています。いくら中間成果物的なドキュメントを書くことに注力しても、動くソフトウェアができるわけではありません。しかし、何も考えず動くソフトウェアができることもないのです。
どのようなドキュメントが必要かは、プロジェクトやプロダクトの性質によって異なります。ゴールは何か、そのゴールに向かって進むために必要なモノは何かを、常に考えることが重要です。
|
|
| ▲ページTOPへ |
| Q. |
メンバー間でコミュニケーションがうまく行われていないように感じています。これではいけないと思い、メンバーを呑み会に誘うようにしています。
毎回ほとんど全員が参加してくれて、その場は楽しく過ごすのですが、次の朝になるとまた以前と変わらない雰囲気です。なにか、アドバイスをください。
|
| A. |
「コミュニケーションがうまく行われていない」とは、具体的にどのようなことでしょうか？
コミュニケーションという言葉は、様々に解釈されやすい言葉の代表格です。まずはどのようなことを問題としているのか、分かりやすい言葉で表してみましょう。必要な時に必要な情報がない、古い情報が飛び交っていて混乱する、特定の人に話しかけにくい、相談したいときに相談に乗ってくれる人がいない、などのように困っている状況を明確にすると解決の糸口が見えてくるものです。
「以前と変わらない雰囲気」とあるので、必要な時に必要な話をしない、問題を個人で抱えてしまっているという状況かもしれません。「メンバー間でコミュニケーションがうまく行われていないように感じている」ということを、他のメンバーの方に伝えていますか？
まずは、ご自身が感じている問題意識を、周りの人と共有するところから始めてみてください。飲み会で話してもよいですが、たんなる愚痴として流されてしまうこともあるので、フォーマルな場で話すのが良いでしょう。ふりかえり会などは、そのような普段感じているが、周囲に伝えていないことを話す絶好の機会です。ぜひ、活用しましょう。
|
|
| ▲ページTOPへ |
| Q. |
XPの「シンプル」を実践し、表記法などを使った設計に時間をかけずにプログラミングに注力しました。
すると、ソフトウェアの複雑さが増大し、手がつけられなくなりました。どうしたらいいですか？
|
| A. |
まずは、現状の問題を何とかしたいということですね。
現状にもよりますが、この状態からリファクタリングをしていっても、その複雑さを解消するのは至難の業です。単体レベルのテストコードだけ残して作り直そうとしても、その複雑なコードに対して作られているので、複雑さを減らすことにはつながりにくいでしょう。システムテストレベルのテストコードを元に、作り直した方が良いでしょう。
そうでなければ、追加分を既存のコードに依存しないように作ってみるというのの検討の余地があるでしょう。
予防策としては、普段からTDDとリファクタリングを行なって、複雑度を上げないようにしていきましょう。また、事前の設計を軽視しすぎるのは禁物です。メンバー間で共有できるように、話し合いをしながら設計をしてみてください。
|
|
| ▲ページTOPへ |
| Q. |
アジャイルで開発していますが、うまくいきません。どうすればうまく行くのでしょうか？
|
| A. |
アジャイルかどうかはいったんおいておいて、どのようにうまくいっていないのでしょうか？
うまくいっているかどうかが判断できるということは、なにかしらの理想像をお持ちのことでしょう。まずは、その理想と現状のギャップを明確にしてみてください。
そのギャップを、「アジャイル宣言の背後にある原則※」に照らしてみてください。ギャップを埋めるヒントが見えてくることでしょう。
※http://agilemanifesto.org/iso/ja/principles.html
|
|
| ▲ページTOPへ |
| Q. |
プラクティスを実践すればアジャイル開発をやっていると言えるんですよね？今日も上司にアジャイルのプラクティスの重要性を訴えてきましたよ！！
|
| A. |
アジャイルのプラクティスの重要性を伝えるなんて、とても積極的で素晴らしいです。もっともっと、宣伝をしてください。上司に限らず、その他の方にも伝えていってください。そして、どんどん実践してください。
そうすれば、「アジャイル開発をやっている」と言うこと自体になんの意味もないことに気付けると思います。
|
|
| ▲ページTOPへ |
| Q. |
いつでも仕様変更できると思って、アジャイル開発を始めました。なのに、仕様変更がある度に激務になります。
仕様変更に機敏に対応できることがアジャイル開発ではなかったですか？
|
| A. |
なぜ仕様変更をしようと思うのでしょうか？変更前の「仕様」はどのように決めているのでしょうか？
アジャイル開発をすることで、仮説を検証しながらより良いシステムを作っていくことは可能ですが、検証のために必要最低限の「仕様」にとどめましょう。
また、激務になるのは別の話で、イテレーション中の変更を受けれいていませんか？イテレーション開始時にチームで合意した開発内容を進めるということが重要です。イテレーション中の仕様の追加変更は避けましょう。
|
|
| ▲ページTOPへ |
| Q. |
アジャイル開発を行えば品質が高まるなら、テスターは必要ないのではないですか？
|
| A. |
「テスター」の定義によるのですが、誰かが決めたテスト手順書に基づいて動作を確認する人、というのであれば、確かに不要ですね。このような確認作業の多くは自動化することも可能です。
しかし、テストケースを考えたり、動作を確認しながら想定していない動きをあぶりだすようなことをする人は必ず必要になります。
|
|
| ▲ページTOPへ |
| Q. |
リファクタリングしたら、いままで動いていたものが壊れてしまいました。
やはり、「動いているものには触るな」のアドバイスに従ったほうがいいと思うのですが。
|
| A. |
リファクタリングの期待結果は、保守し易いコードを手に入れることであって、今まで動いてたものを壊すことではありません。「リファクタリング」とは呼べない活動になっていることが推測されます。（もし、「後で纏めてリファクタリングしてます」であれば危険な臭いがします。）
チームにリファクタリングの習慣を浸透させる場合は、名前の変更やメソッドの抽出など小さなリファクタリングを頻繁に安全に実施できるように練習することをお勧めします。自動テストとともに壊れていないことを確認しながら、リファクタリングしましょう。
大きな修正を伴うリファクタリングの場合は、実施すべき理由を明らかにして優先順位を決めて取り組んでください。リファクタリングする理由が説明できない場合は、実施しないことも選択してください。実施する場合は、一人ではなく、ペアプログラミングや Mob Programmingなど複数人の目で確認しながら安全に実施してください。必要なら、自動テストだけではなく、頻繁に手動テストも実施して壊れていないことを確認してください。
中長期的には、「動いているものには触るな」を繰り返すことで、保守しにくいコードが出来てしまうことが予想されます。保守しにくいコードは、言い換えれば、機能の追加修正の見積りが困難なコード、修正コストの高いコード、バグを混入し障害が発生し易いコード、プログラマの健康を害するコード、プロジェクトコントロールを失うコードです。
リファクタリングを中止する場合は、保守し易いコードを維持するために、リファクタリング以外のアプローチも検討してください。
|
|
| ▲ページTOPへ |
| Q. |
ペアプログラミングでナビゲータになると、手持ち無沙汰で眠くなります。なにか良い方法はありませんか？
|
| A. |
ペアプログラミングの用語では、キーボードを打っている人をドライバー、その隣にいる人のことをナビゲータと定義していますが、この定義というかメタファがそもそもいけないのではと考えています。
ペアプログラミングの理想としては、頻繁にお互いにキーボードを受け渡しますので、ドライバーや、ナビゲーターとして10分以上続くことはありません。二人漕ぎの自転車を、二人で一緒に漕いでいるというほうが、メタファとしてはマシなのではないかと考えています。
|
|
| ▲ページTOPへ |
