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

第2回 ソフトウェア開発をシンプルにする考え方のコツ

福井コンピュータ株式会社 小島 富治雄
Micosoft MVP 2005 − Visual C#)
2005/11/05

■■NAgileにおけるシンプルさの極意“NSimplicity”■■

さて、「プチ・パラダイム・シフト」だが、今日は5つの価値の中の1つ、「シンプルさ」にコミットすることの意味とその理由を話そう。

 いまさらいうまでもないことだが、ソフトウェア開発というのは、複雑さとの戦いだ。大規模になるにつれ、開発が進むにつれ、そして利害関係者(ステークホルダー)が増えるにつれ、問題は複雑になっていく。その複雑な問題にどう立ち向かうか?

 工学的に考えてみると次のような感じだろう。

工学的アプローチによる複雑さへの対処:

  • 大人数をうまく分業化する
  • 問題を分割し、適切に割り振る
  • それぞれの分割単位を独立させる
  • 複雑な現実世界のものをモデル化する
  • 現実世界の問題をITでの解決領域にマッピングする
  • 予測し、なるべく正確に計画する
  • 変化する部分と変化しない部分を分離できるようにする

 これらはアジャイルだとこんな感じになる。

アジャイルのアプローチによる複雑さへの対処:

  • プロジェクトを大人数にしない
  • チームに利害関係者を入れてしまう
  • 「見える化」や「フェイス・トゥ・フェイスなコミュニケーション」で、チーム内のコミュニケーションの帯域を広げ(=ブロードバンド・コミュニケーション)、問題を素早く単純なうちに解決する
  • モデルやコードが複雑にならないようにする(=YAGNI:You Aren't Going to Need Itの原則)
  • 常にフィードバックを行い、ズレを俊敏に補正する

 もちろん工学的アプローチは重要だし有効だろう。だがアジャイルのアプローチもまた、別の角度から問題解決にとても役立つ。

 アジャイルの方では、シンプルに考えることが大切だ。例えばアジャイルでは、以下のようなことをいつまでもくよくよと思い悩んだりしない。

プロジェクトを成功させるためにどうしたらよいのだろうか?

  1. どうすれば前もってできるだけ綿密な計画が立てられるのだろう?
  2. どうすればすべての人にその計画を順守させられるのだろう?
  3. どうすれば前もってすべての要望を盛り込むことができるのだろう?
  4. どうすれば前もってすべての要望に応え得るモデルを作れるのだろう?

 これらのことは重要かもしれない。だが、状況や要望というものはどんどん変化していくものだ。これらのことを、悩んだり検討したりしている時間は、結局「変化」によってムダになってしまうことが多い。アジャイルではそのようなムダ、つまり結局はプロジェクトの価値に結び付かないものを嫌う。

 NAgileでは、シンプルに考えることでムダを排除する。取りあえずNAgileでいう「シンプルさ」のことを、(N*ツールになぞらえて)ここでは“NSimplicity”とでも呼んでおこう。

 それではこれから、その「シンプルさ」にコミットする具体的な例を挙げていこう。まずはその考え方に慣れてもらう。

■■シンプルさの第1原則:「冷蔵庫にキリンの原則」■■

まずこの問題に答えてもらおうか。

「キリンを冷蔵庫に入れるにはどうする?」
(“How do you put a giraffe into a refrigerator?”)

   

え? なんか唐突ですね。

 うーん……えーと、キリンを小さくする? 特大の冷蔵庫を日立に頼んで特別に作ってもらう? 当然キリンは切っちゃ駄目なんですよね。キリンはアミメキリン? それともマサイキリン?

   

もっと、シンプルに考えるのだ。この問題の答えはこうだ。

「冷蔵庫のドアを開けて、キリンを入れ、ドアを閉める」
(“Open the refrigerator, put in the giraffe and close the door.”)

   

同様にこちらの問題はどうだ。

「ゾウを冷蔵庫に入れるにはどうする?」
(“How do you put an elephant into a refrigerator?”)

   
えーと……。
   

こちらの答えはこうだ。

「冷蔵庫のドアを開けて、キリンを取り出し、ゾウを入れ、ドアを閉める」
(“Open the refrigerator, take out the giraffe, put in the elephant and close the door.”)

 シンプルに考えろ。正解が重要なのではない。考え方を学べ。

   
はい。
   

では次の例だ。

 次に挙げるのは、アジャイルを現場に導入しようとしている2人の開発者の会話だ。

開発者A:「アジャイル開発を現場に導入していきましょう」

開発者B:「でもノウハウを持った経験者がいませんからね」
開発者A:「最初は試行錯誤が続くかもしれませんが、これから少しずつ勉強をしながら経験を積んでいくべきかと」
開発者B:「でもいまは忙しい時期ですし。それに上の人間はきっと反対しますよ」
開発者A:「そういって先延ばししていてはいつまでたっても現状のままですから、徐々にやっていきましょうよ。実績を積んでいけば、上も説得できますし」
開発者B:「徐々にじゃ、なかなか効果が見えてこないですね」

 前もってリスクを適切に評価するのは重要なことだ。だが、この開発者Bは問題に対して起こってもいない問題をどんどん付け加えていって、問題を複雑にしている。解決方法を提案しても、また新たな問題を持ち出してくる。

 問題を、解けない方向に解けない方向にと、持っていっている。しかもそれに気付いていない。結局、開発者Bは、本心ではアジャイル開発をやりたくないのかもしれない。

 だが、ここでお前にいっておく。

「問題は単純なまま解け。複雑にするな」

 これが「冷蔵庫にキリンの原則」(Giraffe-Refrigerator Principle)だ。

【「冷蔵庫にキリンの原則」のポイント】
問題は複雑にしないで単純なまま解く。

■■シンプルさの第2原則:「サイバラの原則」■■

さて、別の例だ。サイバラ(西原理恵子さん)という漫画家がいるのを知っているか?

   

またまた唐突ですね。

   

サイバラのある漫画に、数値などの具体的なところは忘れたが、こういうような式が載っていた。

1+1=2
123×456=たくさん
12÷34+56÷78=そんな問題を解かなければならない状況に自分を持っていかない

 さすがサイバラだ。

   

え。そうなんですか。単に小学校レベルの計算が苦手なだけでは……。

   

まあ待て。私は以前、こういう質問をされたことがある。

「バグがいっぱいあってどうにも手が付けられない状態になった場合、どのように修正していけばよいでしょうか? テストとデバッグに、いつもものすごい工数が掛かってしまうので何とかしたいのですが……」

 これは難問だ。テスト工程のコスト・ダウンは重要で、かつ、やっかいな問題だ。ウォーターフォール型で開発している場合にはこういう状況に陥りやすい。

   

ウォーターフォール型開発に対して偏見ありません?

ここでサイバラのやり方だ。

え!? そうなるんですか?

答えは、

「そんな複雑な状況に自分を持っていかない」

 NAgileでは、日ごろからなるべくシンプルなソース・コードを心掛ける。また、「テスト・ファースト」と「リファクタリング」を行う「テスト駆動開発」(TDD:Test-Driven Development)に取り組む。これらにより、ソース・コードをなるべく複雑にしない。

 そして、顧客へのレビューを常に行うことで、仕様バグを含む不具合をできるだけ早い段階でつぶしておく。プログラムの確からしさを常に確認し、また、ソースも「ペア・プログラミング」や「コードの共同所有」によって、ほかのプログラマーが常に確認するようにする(*2)。

*2 このあたりの手法は、「.NET開発者のための開発プロセス入門」に詳しい。

 つまり、「『バグがあり過ぎてどうにも手が付けられなくなるような状態』に自分を持っていかない」ということだ。

 覚えておけ。これが「サイバラの原則」(Saibara's Principle)だ。

【「サイバラの原則」のポイント】
複雑な問題を扱わなければならないような状況に自分を持っていかないようにする。

 

 INDEX
  NAgileで始める実践アジャイル開発
  第2回 ソフトウェア開発をシンプルにする考え方のコツ
    1.“NAgile”って何? どうやる?
  2.NAgileにおけるシンプルさの極意“NSimplicity”
    3.「シンプルさ」にコミットする演習 ― シンプルに考えるための問題意識
    4.「シンプルさ」にコミットする演習 ― 実際のDateクラスのソース・コードの実装
    5.“Be Agile. That's my attitude.”という心構えを持とう!
 
インデックス・ページヘ  「NAgileで始める実践アジャイル開発」

@IT Special

- PR -

TechTargetジャパン

Insider.NET フォーラム 新着記事
  • 配列のコピーを1行でするには? (2017/4/26)
     配列をコピーするには、for/foreachループを使う方法もあるが、ArrayクラスのCopyメソッドを使うのが一番簡単で速度の面でも有利である
  • Microsoft Small Basic (2017/4/25)
     Microsoft Small Basicは学習を目的としてマイクロソフトが提供しているBASICの処理系。シンプルな言語仕様、習得が容易、簡潔な記述がその特徴
  • 第2回 Visual Studio 2017の基礎を知る (2017/4/21)
     開発環境Visual Studio 2017を使ったプログラミングに不可欠な知識とは? ソリューションの概念から画面構成まで基礎を説明
  • XmlSerializerでシリアライズ/デシリアライズする (2017/4/19)
     XmlSerializerクラスでシリアライズ/デシリアライズを行うと、デシリアライズに失敗することがある。その回避策を含め、XmlSerializerクラスの使い方を説明する
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Insider.NET 記事ランキング

本日 月間
ソリューションFLASH