連載
NAgileで始める実践アジャイル開発

第1回 .NET+アジャイルなら本当に幸せになれるのか?

デジタルアドバンテージ 一色 政彦 & 正木 理絵子
2005/10/19

Page1 Page2 Page3

2. NAgileを実践すると何がうれしいのか?

―― 率直にお聞きしますが、皆さんにとってNAgileはどこが魅力なのでしょうか?

小島:基本的にわれわれは、どんなに難しいプログラミングでも常に完ぺきにこなせるスーパーマンではありません。確かにそんなスーパー・プログラマーがいるなら、わざわざNAgileでTDDを実践しなくても、最初からバグのないメソッドが書け、最初から将来の変更を見越した安定したメソッドが設計でき、さらに最初の計画どおりに何の問題もなく開発プロセスを進めていけるのでしょう。しかし実際にはそんな開発者は存在しないと思います。

 そのため、普通の人でも難なくこなせる何らかの工夫が必要になります。そこには、「できるだけ開発をシンプルかつ簡単に考えたいし、極力複雑なことはしたくない」という思いがあります。そのような課題に対する解の1つがNAgileなのです。ソフトウェア開発をもっと楽にすること。これがNAgileの魅力だと思います。

小井土:わたしがNAgileを気に入っている点は、いわゆる「正直ベース」であることです。

 「現在のソフトウェア開発において、ビジネスとプログラムは実際には(平行しているのではなく)直交している」という話を聞いたことがあります。これはどういうことかというと、システム(=プログラム)は現時点で必要とされるもの(=要求)に合わせて作らなくては意味がありません。しかしビジネスが進化するに従い、そこには次々と新しい要求が入ってきます。当然ながら、そのような要求の変化に合わせて、システムを作り直していかなければなりません。

 つまり、ビジネスの進化という時間軸に沿った横の線に対して、システムはその横線を縦に区切った時点での要求に合わせて構築しなければならないわけです。これがビジネスとプログラムが直交しているということです。

ビジネスの進化とプログラムの進展における直交
システム開発(=プログラム)は、時間軸を縦に区切った中で、その時点と近未来のビジネス要求に基づいて行われる。これは遠い将来のビジネス要求の変化をあらかじめ予見することが不可能なためだ。例えば、これから10年後の企業システムの主流がSOAになっているかどうかを現時点ではっきりと明言できる人はいないだろう。従ってこの図のように、ビジネスとプログラムはずっと平行したまま進化するわけではなく、実際にはプログラムのバージョン・アップなどでシステム開発が繰り返されるたびに、ビジネスとプログラムは直交することになる。このようなシステム開発の現実に柔軟に対応するには、遠い将来の要求の変更まで予見しなければならない従来のウォーターフォール型開発よりも、変化する要求に迅速に対応することを目的としたアジャイル開発の方が適していると考えられる。

 スーパー・プログラマーといえる人たちがいた時代では、将来的なビジネス要求の変化をある程度予見して作っていました。これに基づく従来のウォーターフォール型開発(以降、従来開発)では、「ソフトウェアは固めるもの」という意識が念頭にあります。いったん仕様を固めてから実際の開発に取り掛かるわけです。

 しかし現在では、ビジネスのスピードが非常に速くなってしまって、このような「最初に仕様を固める」(=途中で作り直さない)という開発スタイルがとても難しくなっているのです。

 NAgileはその点、ビジネスの要求のスピードが上がれば、システムの対応もそれに合わせてスピードを上げていくことを初めから想定しています。NAgileによるシステム開発では、「リファクタリングとテストなどを活用して、作り直しながら作っていくこと」が前提となっているのです。「システムは要求が変化するたびに作り直さなければならない」という現状に目を背けることなく、真正面からにとらえてまじめに取り組もうとしている。わたしはその「正直さ」が気に入っているのです。

―― 森屋さんからは先日、「NAgileは『癒し系』」だとお聞きしましたが、これはどういうことですか?

森屋:従来開発では、設計ドキュメントを眺めながら毎日徹夜して、本当に価値があるのかどうかも自分ではよく分からないコードを機械的に書いていました。しかし、NAgileによるTDDで自ら設計したコードを自発的に、そして確実に書いた方が、本当に価値ある確実なコーディングをしていると自ら納得できるということです。NAgileなら、そういう楽しさが心を満たしてくれます。それをわたしは「癒し系」だと思うのです。

NAgile開発は「癒し系」

福井:わたしは、従来開発とNAgile開発の違いは、コードを書く人と書かない人を分けるか(=従来開発)分けないか(=NAgile開発)の違いだと考えています。

 従来開発では、分析・設計だけ、コーディングだけというような分業制度にすることが一般的です。これによって、実装を知らない設計者や要求を正しく理解しない実装者が出てきます。設計者は実装イメージが想像できないまま設計を行い、実装者は顧客の要求を正しく理解しないまま実装することになります。これはすごく大きな問題になることがあります。

 設計者は機能要求は理解しているのだけれど、非機能要求(=システムの拡張性や再利用性、パフォーマンス、信頼性などのコード)についてはよく分からないといった問題です。

 一方のNAgile開発では、「職種はアーキテクトだけどコードも書くよ」という人が必要になります。彼らは、(繰り返し型のアジャイル開発手法ですから)ごく短期間に設計フェイズと実装フェイズを行ったり来たりします。先ほどのような問題を引き起こさないためには、こういった人材を多く育てなくてはならないと思います。そしてNAgileならば必然的にそういう人が育ちやすいわけです。

 さらにそういう人の方がシステム全体が分かっているので、きっと仕事も楽しいはずです。1人1人がそれぞれの能力を最大限に発揮して自分でできることを実行し、それをどんどんと横につなげていって、そしてみんながつながったチームでソフトウェアを作っていく。そういう開発スタイルの方が、(分業制度による開発よりも)仕事として面白くて楽しいと思うのです。

中西:そういう開発スタイルを採用することで、「脳内マッピング」のように、各開発者が頭の中でシステムのイメージとコードをきちんとマッピングをしながらシステムを設計できますね。また、開発者は自分が何をやっているのかよく分かるので安心できます。そこがNAgileの「癒し系」の部分ですね。これはNAgile開発ならではの良さだと思います。

小島:確かに従来開発では分業化がなされているので「特定分野のスペシャリスト」が育つのに対して、NAgile開発では「ジェネラルなスペシャリスト」が育つと思います。彼らは、お客さんとも話ができるし、コードも書けるし、オブジェクト指向も理解している。デザインもできて、ユーザー・インターフェイスも作れる。このへんが「癒し系」の楽しさにつながるのでしょう。さらに会社を辞めても食べていけるという自信も付きます。

 逆に従来開発では、設計ドキュメントを渡されて「このとおりコードを書くように」という指示を出されるわけですが、これでは楽しくないですよね。

―― やはり開発者にとっては、設計ドキュメントを書いたり、それを実装したりすることは、あまり楽しくないことなのですか?

市川:プログラマーの本音を代弁すると、本当はWordやExcelを使って詳細設計書に詳細なロジックなどを書いたりしたくないですね。第一、いくら詳細に設計ドキュメントを作っても、そこからはコードは1行も生成されないわけですから、動かして試すことができない。あと単体テストを手動で何度も繰り返すことも面倒です。理想的には、コードを書いていくだけで、設計もテストもコードも、これら全部が一緒くたに出来上がるのが一番うれしい。

 このニーズとNAgileはうまく合っているのではないでしょうか。そのように思っている開発者の方々は、実際にみんなNAgileの思想に納得して、NAgile開発を実践するようになっています。やはり自然言語で書かれた設計ドキュメントは、実際のコードと徐々にブレが出てくるんです。ブレるたびにWordを開いて設計書を書き直したりしたくないですよね。「コードを修正したらドキュメントも修正」という作業は、単なる二度手間だと思います。

―― なるほど。NAgileなら、.NET開発者の負担がある程度軽減されるわけですね。さらに設計とコーディングの両方に携わることで、プログラミングに対する視点が大きくなり、開発すること自体が楽しくなって、本当に心が癒されてくるのかもしれませんね。それ以外にも、開発者がNAgileで開発すると快適に感じられるところは何かありますか?

森屋:NAgileだと、確実に1歩ずつ成功に向かって進んでいることが、(見える化によって)目に見えてはっきりと分かるので、そのへんがとても心地いいですね。

中西:そういう1歩ずつのリズムがNAgileでは非常に大事です。例えばTDDを行えば、テストが1つ成功したなどのささいなことでもはっきりと見えるので、進んだことがリアルに感じられるわけです。いわゆる「ドライブ感」。このようにきちんと進んでいるという感覚が常に味わえるのは、開発者としてやはり楽しいですよ。

 逆に従来開発では、高速道路をバックしながら走っているような感覚がありました。1つ1つ前に進んでいるのではなくて、押し迫る納期にプレッシャーを感じ、わけも分からずにたまった要件を黙々と消化しながら、自分がどんどんすり減っていくような感じです。それゆえに道を誤って時には大きく逆戻りもする。これだと苦しく感じますよね。要するにちっとも楽しくないわけです。

NAgile開発ならではの「ドライブ感」

―― ところで、先ほどから「見える化」というキーワードが何度も出てきていますので、見える化はNAgileにおいて非常に重要な概念のようですね。そこでお聞きしたいのですが、見える化とは具体的に分かりやすく説明すると、どういうものなのでしょうか?

小野:NAgileでは、「見える化」はいろんなことに当てはまります。例えば、プロジェクトの進ちょく管理も誰にでも見える形で行いますが、これも「見える化」です。ほかにも、「コードの共同所有」や「ペア・プログラミング」によるコード自体の「見える化」もあります。冒頭で紹介されたCC.NETでは、ビルドとテスト結果の「見える化」が実現できますが、このようにN*ツールでどんどん自動化していくことの中にも「見える化」が含まれています。

 これらの見える化では、われわれが見に行く(=look)のではなく、見えてくる(=see)ところがポイントです。つまりCC.NETなどのツールが、わたしたちに結果を知らせて見せにくるといった方がしっくりきます。

小井土:見える化の重要な特徴の1つが、「いつも見える」ことです。いつも目に入ってくることがとても大切なんです。なぜかというと、それがコミュニケーションの基本だからです。すべての状況は何らかの形で常に目に見えるようにしておかないと、それについて(問題が顕在化するまで)なかなかコミュニケーションが図られないことになるからです。

 さらに「いつも見える」ことに加えて、「早く見える」ことも重要です。例えば恋愛において、破局に至るであろう問題点が「付き合ったときに見えている」のと、「別れて初めて見えてくる」のとでは、どちらが好ましいでしょうか。付き合っていたときに見えていれば何らかの手が打てますが、別れてからでは遅すぎます。要は、できるだけ早いうちに(問題点が)見えていないといけないわけです。見えるのが早ければ早いほど手を打ちやすいわけです。

見る化の特徴は「いつも見えること」と「早く見えること」

 これに関して、例えばCC.NETの見える化のタイミングはすごく早い。CC.NETでは、ソース・ファイルをソース・コード管理ツールにチェックインするだけで、即座にビルドとテストが実行されて結果が通知され、非常に早いタイミングで問題個所を発見できます。

 一方、例えば通常の結合テストでは、問題点を発見するまでに1週間や1カ月くらいかかってしまうことが多い。このように問題の発見が遅れれば遅れるほど、問題もそれに比して大きくなる可能性が高いでしょう。遠距離恋愛がつらいのは、「いつも見えて」いなかったり、「早く見えて」いなかったりするためです。

―― つまり、現状のソフトウェア開発は、見えるようになっていないということですか?

市川:なっていません。見えていないから、会議で開発者が「進ちょく率何パーセント」という報告をするわけです。

 いまはオフショア開発が全盛期ですが、特にそのような開発現場ではまったく何も見えないことの方が多い。そして、実際にプログラムが手元に来ていざ結合してみると、とんでもない問題を抱えていることにそこでやっと気付く。そういうことが多々あるわけです。

 確かに、普通は中身が見えないというのは自然な状態ですが、「それを何とかして見えるようにしていこう」というのが「見える化」なのです。

―― NAgileでは、「見える化」が根本的な概念として取り入れられていて、そのため問題を早期に解決できるわけですね。

 ここまでの話から、NAgileの良いところは、シンプルに考えられること、自分が何をやっているかよく分かるという実感や癒しが得られること、さらに見える化によって着実に進んでいることが分かるので楽しいこと、見える化で問題が早期に発見できることなどだと分かりました。

 それでは最後に実際にNAgileを始めるための方法についてお聞きしたいと思います。


 INDEX
  NAgileで始める実践アジャイル開発
  第1回 .NET+アジャイルなら本当に幸せになれるのか?
    1.そもそも“NAgile”って何?
  2.NAgileを実践すると何がうれしいのか?
    3.NAgileを始めるにはどうすればよいのか?(+NAgileの将来展望)
 
インデックス・ページヘ  「NAgileで始める実践アジャイル開発」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間