連載
開発をもっと楽にするNAgileの基本思想

第1回 アジャイル開発ではドキュメントを書かないって本当?

福井コンピュータ株式会社 小島 富治雄(Microsoft MVP 2006 − Visual C#)
2006/02/22

■■ソース・コードにアカウンタビリティを持たせよう!■■

設計書の一部となるようなソース・コードを書く、ということ? なるほど……。

 どないしたら、じゃなかった、どんなふうにしたら、そんなソース・コードが書けるようになるでしょうか? 何かコツはあります?

   

どないしたらソース・コードでアカウンタビれるか、か? よっしゃ。コツを教えたろ。

 念のためにいうとくけど、これからいう話は、オブジェクト指向に限った話やないで。オブジェクト指向プログラミングか手続き指向プログラミングかによらん話や。だから、C# やのうても、Visual Basic でも C でもおんなし理屈や。あんじょう聞いてや。

 始めのうちはな、図ぅ描いてみたらええねん。そういえば、おっちゃんの若いころは、フローチャートいうのがあったな。でも別に、フローチャートを使えとか、UMLを使えとか、そういうこっちゃないねん。

 例えばやね、

「ある点からもっとも近い図形を選択状態にする」

というメソッドを書くとするわ。

 図の描き方はなんでもええねん。しいていうなら、そやな、自分の現在の思考に最も合う図や。最も分かりやすく表現したら、どないなるか、いうのを描いてみる。そしたらそれが、「自分のモデル」や。

 例えば、こんな感じや。

ある点から最も近い図形の選択:

 それをそのままなるべく変えんようにC#に置き換える。

 上の図やったら、

ある点から最も近い図形の選択()
{
   点から最も近い図形を検索する();
   if (見つかった)
   {
     その図形を選択する();
     その図形を描き直す();
   }
}

に近い形のソース・コードになるわな。

 この場合でいうと、大体このぐらいの行数、つまり6行程度のソース・コードになるはずや。そうならんとおかしい。

 もし仮に、これが数十行にもなったとするわな? それはつまり、自分の中のモデルとソース・コードがかけ離れとるいうことや。それは自分の設計モデルやない。「自分の設計モデルをシンプルに分かりやすく表したソース・コード」やない。設計モデルをアカウンタビっとらんソース・コード、いうわけやな。

   

要は、設計モデルがそのままソース・コードになるようにするわけや。

 フローチャートでもUMLのクラス図でもほかの図でもええけど、自分にとってなるたけ分かりやすい図になるようにする。まあ、チーム内で、決められた図があるんやったら、それを使といたらええがな。

 どんな図にせよ、「その中がどんな固まりで分割されとるか?」いうことと、「その固まり同士がどんなふうにつながっとるか?」いうことが肝心や。固まりの大きさ(=粒度)は、その時々で自分にとって一番分かりやすい大きさやな。その固まりがプログラムの単位や、つまり、「自分のモデル」での、メソッドやら、クラスやら、サブシステムやらに相当することになる。

 後はこの繰り返しや。それぞれの固まり、上の図でいうと「点から最も近い図形を検索する」や「その図形を選択する」に関しても同様のことを繰り返していったらええ。粒度が小そなってくだけで、おんなし理屈や。

 慣れてきたら、図は描かんでもええかもしれんな。頭の中のモデルと一致するようにソース・コードを書いたらええねん。逆に、頭の中のモデルと違うことはなるべく書かんようにすんねん。ソース・コードが自分の意図をそのまま表現する、ようになるわけや。

 それから、ソース・コードが時とともにだんだん自分のシンプルなモデルから離れていくこともままあるこっちゃわな。モデルが複雑になってしまうこともある。そうならんように常日ごろのリファクタリングが大切やね。

 こんなふうに、ソース・コードがアカウンタビるようにする、いうのは別のいい方をすると、

ソース・コードの意図の「見える化」や。

 ソース・コードもモデルの表現方法の1つなんや。これができたら、C#でモデル駆動開発(Model Driven Development)ができまっせ。どないだ、滝ちゃん。

【ポイントやで!】
ソース・コードの意図の「見える化」が、ものごっつぅ大切なんやで。

■■シンプルなコミュニケーション■■

さっき、ひどいソース・コードの例を挙げたやろ。あのソースで、特にひどいのはコメントや。

 ようけ付けたらええっちゅうもんやない。「int nn」に「/* 数 */」なんてコメント要らんねん。「数」いうことは見たら分かるっちゅうねん。そんなんしとる暇があったら、意味と一致した変数名をきっちり付けとけ、いうねん。

 余計なコメントは、重要な情報を埋もらせる。ろくなもんやない。そんなんコミュニケーションにとってノイズでしかないねん。

 要らんことまで伝えたらあかんねん。要らん情報を大事な情報と一緒に伝えようとするのは、いうたら、

「雑音だらけのラジオ放送」

みたいなもんや。S/N比(Signal to Noise ratio。S:信号とN:ノイズの比を表すオーディオ用語)が悪いねんて。重要なことが、シンプルに伝わるのがええねん。

 「ソフトウェア開発をシンプルにする考え方のコツ」でシンプルさの大切さを学んだようやけど、質の高いコミュニケーションにもシンプルさが必要なんや。

【ポイントやで!】
情報の「S/N比」に注意しようや。

■■モデルでシンプルなコミュニケーション■■

さあここからや。
   
え? どこどこ?
   

探すな! いうてるやろ。

 ここまで、

  • モデルを伝えることの重要性
  • コミュニケーションにおいてもシンプルさが大切

いうようなことをしゃべってきたわけや。シンプルさの重要性については「ソフトウェア開発をシンプルにする考え方のコツ」で学んだはずやな。

   
はい。
   

モデル、モデルいうてるけど、何でそないにモデルが大事か?

 モデルっちゅうのは、「シンプルにコミュニケーションする」手段の1つでもあるんや。一般的に、「モデル」いう言葉の意味するもんは何か? モデルとは、すなわち、実在するモノや現象からムダなもんを取り去って、シンプルにしたもんなんや。ムダなもんいうのは、いうたらそんときの関心の外にあるもんや。

 例えば、物理学では……。滝ちゃん、じぶん物理好きか?

   
嫌いです。
   

愛想もくそもないがな。まあそう構えんと聞いてや。

 例えば、物体の運動を考えるとしょうか。

 「リンゴを上向きに放ったら、どないな動きをするんやろ?」みたいなこっちゃわな。

 で、こんときには、問題をシンプルにする。リンゴの色がどうやとか、味がどうやとか、「おかん、どこでこのリンゴ買うてきたんやろ?」とか、「そういや最近おかんとばあちゃんの嫁姑問題はどないなっとんやろ?」とか、そういうのは要らんねん。運動に関係のある、リンゴの質量とか放ったときの速さとか、そんなんだけでええねん。

 そうやって関係のないことを省いて思い切りシンプルにした「物体が運動するときに起こること」を考えんねん。それがモデルや。

 ソフトウェア開発のモデルも似たようなもんや。例えば、設計モデルは、ソフトウェア開発全般から、ある視点で設計に関する部分だけを取り出したもんや。分析モデルも同様や。

 1つ例を挙げると、「社員名簿アプリケーション」を作るとする。ほんで、その中で社員を表す「社員クラス」というのがモデリングされたとするわな? このとき、「社員クラス」が持っとる属性は、現実の社員が持っとる情報のほんの一部や。現実の社員が、「好きな食べ物」「好みの音楽」「好きなスポーツ」のような情報を持っとったとしても、そのシステムのユーザーの視点からそれらの情報が不要やとしたら、「社員クラス」には入れへんやろ?

 もう一度いうと、

関心の外のものを取り去ってシンプルにしたものがモデル。

 せやから、モデルを使うと伝えたいこと(=関心事)だけをシンプルに伝えられるいうわけや。

【ポイントやで!】
モデルを使うことで、関心事だけを伝えるS/N比の高いシンプルなコミュニケーションができるんや。

 

 INDEX
  開発をもっと楽にするNAgileの基本思想
  第1回 アジャイル開発ではドキュメントを書かないって本当?
    1.アジャイル開発ではドキュメントを書かないの?
    2.アカウンタビリティは大切
    3.ソース・コードのアカウンタビリティとは?
  4.ソース・コードにアカウンタビリティを持たせよう!
    5.モデリングのコツ
 
インデックス・ページヘ  「開発をもっと楽にする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 記事ランキング

本日 月間