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

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

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

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

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

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

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

　例えばやね、

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

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

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

　例えば、こんな感じや。

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

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

　上の図やったら、

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

探すな！ いうてるやろ。

　ここまで、

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

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

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

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

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

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

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

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

　もう一度いうと、

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

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