アジャイルに行こう!

データモデリングなきアジャイル開発は危ういか?

»

尊敬するDOAの先輩である、渡辺さんがこう書いている。

「データモデルなきアジャイル」の危うさ、より

その種のシステム(※引用者補記:販売管理システムや生産管理システムといった基幹系業務支援システム)をアジャイル開発しようと考えるのであれば、それまでにシステム全体の「あるべきデータモデル」が確立されていなければならない。
業務システムを「身体」に喩えるなら、データモデルは「骨格の設計図」に相当する。いっぽうアジャイル開発で導き出せるのは身体の表面上の諸問題、すなわち「皮膚のぐあい」とか「顔つき」のようなものだ。そういった特徴についていかに緻密に決定できても、それらから「あるべき骨格の姿」は導けない。

それに対して、稲見さんがこんなコメントをしている。

アジャイル開発と言っても色々で、最近流行りのScrumという手法は、開発の中身に関しては何も言及していません。ですが、私の知っているある人達は、データモデルは書いています。また、FDDという手法では、ドメインモデリングから始めると有る様に、データモデルが出発点です。

ぼくも実はこの考えには基本賛成である。というか、確かにデータモデルを初期に設計しなければならない場面はかなりあると思う。このへんのことを少し書いておきたい。

Agilecake ピュアなアジャイルでは、機能を縦スライスで作る。UIからDBまで、細い縦の線をつなぎ、それをユーザのフィードバックを得ながら太くしていく。ぼくはこれをたとえるのに、ぼくは水越さんが書いてくれたこのケーキをよく使う。

つまり、ケーキをつくるのに、一層目のスポンジ、二層目、そしてクリームを塗って最後にイチゴを乗せる、という作り方ではなく、まさに、すぐに食べられるショートケーキを縦に作っていくのだ。

この利点は明らかで、作り終えるまでの半完成品(仕掛、在庫)が少なく、仕様変更のインパクトが引くいこと。また、ユーザに食べさせることで、フィードバックを早期に得、より効果的な仕様を引き出せることだ。

ケーキ屋がもしホールケーキを作らず、ショートケーキで作ることができたなら、売れ残りリスクを低く抑えることができ、かつ、フレッシュなショートケーキをいつでもお客に食べてもらえる。ということになる。これは、要求がなかなか固まらないシステムや、要求のゆれが大きなシステムでは、とっても有効で、ここがアジャイルのポイントだ。ここまでが原則論。

ところが、全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。データモデルはアプリケーション全体に影響を与え、データモデルの後での変更は高くつくのである。このように、「後戻りが高くつく」ような意思決定は、どうしても先に行う必要があり、そのような制約をもったものには、データモデルのほかにも、

  • 開発言語
  • レイヤーアーキテクチャ
  • セキュリティ
  • スケーラビリティ(※ここは後で議論)
  • 。。。

Leanandcostescalation などがある。これらは「リーンソフトウェア開発」において、高リスク制約(High Stakes Constraint)と呼ばれている。左の図は、2003のMary Poppendieckの講演につかわれた図。もともと、変更を受け入れるのがアジャイルの姿勢であり、どうやったら「後で変更できる」というオプションを開発のライフサイクルにおいてキープし続けるか、というのがアジャイルのテーマなのだが、変更コストが極端に高いものはしょうがないのだ。(ちなみに、それでも意思決定を遅らせたい場合、「セットベース設計」を使う、というのがリーンソフトウェア開発。合わせてリーンソフトウェア開発全体の資料をここに共有しておきます。

でも、ポイントはこの高リスク制約は非常に少なく、「決定を遅らせる工夫」をすることが大切。実はリーンソフトウェア開発では、データモデルも、高リスク制約には入っていない。(ぼくは、場面-たとえば渡辺さんの言われるような基幹業務システム-によっては入ると思っている)

Balance このバランスの話をすると、プロジェクトや製品の文脈によって一概には言えない(だから、文脈ごとに考える必要がある)。Barry Boehm は、このバランスをこんな図(需要供給バランスの図に似ている)で表している。

横軸に、「設計への投資時間」を、縦軸に「設計しすぎ、および、設計しなさすぎ、のリスク」をとって、プロジェクトごとにプロットする。当然、設計や計画に多くの先行投資をし決定事項を多くつくってから開発すれば、設計不十分というリスクを抑える。ところが逆に、設計しすぎて先行投資しすぎるリスクが高まるのだ。

そして、この損益分岐はプロジェクト毎に異なる、というのがベームの主張である。さらに、これはプロジェクト毎、ではなく、サブシステムごと、レイヤーごと、など細分化して適用できるため、先ほどのメアリーの主張とあわせると、

高リスク制約を抜き出して、そこだけは、設計を十分に行え。そうでない部分は変更可能性を保ち、アジャイルに進めるべし、ただし、高リスク制約は思ったよりも多くないぞよ。となる。

最後の但し書きについて一言。

高リスク制約と思われていたものが、最近変更コストが低くなった、という例も本当に多い。たとえば、インフラアーキテクチャの選定と構成は、クラウドが出てから本当に劇的に変わった。先日、AWSの玉川さんと話していて分かったのだが、いまや、机上の推定と計算でインフラの構成を決めているなんて時代遅れだ。クラウドでは、マシンやロードバランサー、コア数やCPUスペックまで、プログラムのように変更できる。すなわち、変更可能性が飛躍的に向上した。こうなると、「緻密に設計する」のではなく、「まずやってみる」、とか、「やって見て、足りなかったら変更する」という方が圧倒的に、コストが低い。

これは、少し年代が高い人は分かると思うが、昔はマシンの時間が高価で、コンパイルにとても時間がかかったから、机上デバッグしていたのに、今は一人ひとつのPCが当たり前になり、IDEが進化してその場でどんどんコンパイルできるようになった。こうなると、「机上デバッグ」なんてするよりも「まずはコンパイルしてみる」という方が圧倒的に生産性が高い。

そんなわけで、高リスク制約と思われているものでも、最近は後で変更が可能となってきたものが多い。それに、工夫すれば後で変更するオプションをできるだけ維持しながら開発できる。こう考えることで、できるだけ、ユーザに見える動くソフトウェアを、すばやく提供すること、すなわち、ケーキを縦に作ることが可能になってきた。

それに、クラウドをはじめ、試すコスト、はどんどん下がっている。ケーキをどれだけ縦に切れるか、その勾配はどんどん垂直に近くなっているのである。

P.S.
ところで、実際に苺ショートケーキ、だが、最近はホールケーキをカットするのでなく、まさに、ショートケーキで作る、とうい話を聞いたことがある。この話の真偽を知っている方はぜひ教えて欲しい。

P.P.S.
また、データモデリングをアジャイルの中でどう扱うか、という話はScott Amblerが昔からしていて、Agile Data とか、Agile Modeling という分野がある。ぼくも、Astah をMindmapと組み合わせて、もっともっとホワイトボード的に使い、Agile Modeling の分野に活用したいと考えている。

(※9/6 追記

Comment(8)

コメント

オオノススム

むかし、あるDOAを導入した銀行の情報系システムは全体への適用にはギブアップしていましたね。そのくらい事前に全てのモデリングを完了させることは難しい。ただし、やる気にさせないと基本部分もモデルなしに進めてしまうから、「最初にモデリングすべし」と言う。まあ、昔はできることとできないことを使うわけたうえで、「すべし」と言ったんだけど、だんだんそういう融通の部分が抜け落ちて、「絶対」になってしまったことに悲劇、もしくは喜劇の起源がありそうに思います。
それはアジャイルに関しても一緒で、アジャイルで言われていることが絶対に昇格してしまうとおかしくなってしまうように思いますよ。

オオノススム

「机上デバッグ」なんてするよりも「まずはコンパイルしてみる」という方が圧倒的に生産性が高い。

この考え方は反対だな。おバカなプログラマばかりを再生産することになるから。
例えば、学校の試験を期末の一発ではなく、毎日の小テストで合格するまでテストするからそれにかえるとすると皆勉強しないでしょ。結果として、勉強が身につかないことになる。
テストも一緒で、自分がミスする部分を事前に特定しようとしないといつまでもミステイクを繰り返すことになる。コーディングミスを防ぐなんて簡単で、半年もミスをフィードバックしてやればほとんどの間違いは事前に取り除けるようになる、というか、そういう間違いの入ったコードを書かなくなる。これがハンフリーの提唱したPSPの簡単な理論的な背景です。
だから、ミスを起こすうちはテストをする前に机上デバッグをする癖をつけないといつまでもおバカプログラマを卒業することは難しいと思いますよ。きれいなコードが書けるようになると、モデリングに全精神を注げるようになるから、楽になるはずなんですけどね。

渡辺幸三

おひさしぶりです。ケーキの喩え、カワイイし的確ですね。

他の高リスク制約とは違い、DB設計は今も昔もクリティカルな設計課題であり続けています。そうでなかったら、業務システムの融通の利かなさに苦しんでいる企業が今でもこんなに多くあるわけがありません。どんなに最新のマシンの上で動いていようが、いったん出来上がってしまったDB構造を含めた変化には大きなコストがかかる。それだけに周到なデータモデルを確立する必要がある。それはなによりも「将来の変化に対応しやすいDB構造」を手に入れるためなんですよね。

オオノススム

プログラミングと言う作業は数学の証明を一生懸命に書くようなものだと思っている。
もし、証明者が証明の途中で誤っていることに気付かずに証明を終えてしまったらどうなるだろう?
もし、証明することを求められた者が正確に証明する対象を記述できなかったらどうなるのか?
正確にプログラミング言語を使用して論理がかけないプログラマと言うのはそういう証明者と一緒なのだと考えている。
正確に証明できないのなら、もっと先にある「エクセレントな証明」なんてもののたどり着けるわけがないじゃないか?
いつまでも先生と答え合わせをしているのなら、生徒以上の存在にはなれない。
先生になりたければ、机上でちゃちゃと見直して完璧な証明ができるくらいまでは上達してくれないと困ると思うんだけどな。

平鍋

渡辺さん、コメントありがとうございます。

「DB設計は今も昔もクリティカルな設計課題であり続けています。」確かにそうだと思います。
海外でのアジャイル開発の中心はスタートアップ企業などの若い企業であり(これは言い過ぎですが傾向としてはそう)、過去の資産の少なさ、将来への設計よりも事業の立ち上げ重視(いくら長期使える品質の設計をしてもビジネス成立しなければおしまい)、日本の終身雇用とエンジニア流動性の低さ(これも変わってきています)、なども起因していると思います。このあたり、IPAからレポート出てますので参考まで。(これが簡潔に紹介しています。 http://www.publickey1.jp/blog/12/_ipaga.html)


平鍋

平鍋

オオノさん、

>「絶対」になってしまったことに悲劇、もしくは喜劇の起源がありそうに思います。それはアジャイルに関しても一緒で、アジャイルで言われていることが絶対に昇格してしまうとおかしくなってしまうように思いますよ。

はい。そうなんです。ぼくは文脈依存性が強いことがソフトウェア開発の大きな特徴で、「これをやればいい」、という真理が非常に少ないと思っています。ソフトウェア設計についてはそれでもかなりあるのですが、ソフトウェアプロジェクト、およびソフトウェア工学全体については、まだどうやっていいか産業が分かっていないのだと思います。そのあたり、SEMATにも期待しています(http://blogs.itmedia.co.jp/hiranabe/2010/02/sematorg-2a87.html)ようやく、本が出るようです。(http://my.safaribooksonline.com/9780133153156/pref03)

また、机上デバッグについても、おっしゃるとおりで、勉強している段階では必要です。また、ロジックがクリティカルである場合、私自身も、印刷してずっと読み下すことが今でもあります。

ただ、オオノさん、最近のEclipse環境でコーディングされた経験ありますか?この部分はやったことのある人ない人でまったく感覚が異なりますので(ぜひ教えてください)。。。これは自戒ですが、最近、過去の参照で話をするのはとても危険だと思うようになりました。アジャイル宣言自体の前文が「実践者として」となっているのはこのあたりなんだろうなぁ。と思っています。

>「プログラミングと言う作業は数学の証明を一生懸命に書くようなものだと思っている。」

そういう分野もあるでしょう。UNIXのカーネルなんかを見ると、一行一行が本当に濃いのでこの感覚は分かります。ただ、そうでない分野もあります。あまり良い例ではないですが、「いれぽんだしぽん」といわれる、DBと画面がほぼ直結して、データを出し入れするだけ、に近いようなシステム構築もたくさんあり、そうなると、緻密さよりも使いやすさとデザイン、で勝負する場面も多いです。またWebのシステム(B2C)では、そもそもビジネスの成功(ユーザがつくかどうか)で勝負がきまるような場面は、特にアジャイルの採用率が高いようです。

また、「一行一行証明している」感じは、アジャイルのTDDがすごく近いです。テストと対でプロダクトコードを書いていくので、複式簿記をうめるような感覚を覚えます。

もともとの渡辺さんの記事でも触れていますが、本当に文脈依存度が高いので、ソフトウェアの話は難しい。。。

オオノススム

Eclipseですか?ちょっとだけね。でも、感覚は分かります。
ただ、機械的に直しているだけだとせっかくの形式知がプログラマの暗黙知にならないのですよ。
野中さんの著作をご存知のようですが、プログラマがクリーンなプログラムを書けるというのも非常にナレッジマネジメントの世界なんです。間違えた結果を元に、それを形式知の形に変換して、自分のノウハウとしてフィードバックする。これを地道に繰り返すことで、コード依存のバグの混入は飛躍的に減ります。そのひとつのフィードバックの形態が机上デバッグです。ハンフリーのPSPの基本的な構造になっていますよ。
プログラム言語といういわゆる基本的なモデリングが自由自在にできるようになることで、一般的なプログラマの生産性は上がるはずです。逆に、プログラマにそこまで要求しない文化の下では、そのデバッグを機械的にさせようとする。
全体的なソフトウェア工学の基本的な構造は簡単なんですけどねえ。
とタイム24のソフトウェア工学研究会主催のアジャイルセミナーで、「そんなことは現場でやってるよ!」とそのファッション性を指摘してからもう10年なんですね。

オオノススム

もちろん、機械的なチェックも有効な場面はあります。
例えば、人的な成長があまり有効でないようなケースですね。プログラマを期間限定で採用したような場合や中国やインドに見られるような1年に従業員の30%も離職してしまうような組織の場合にはフィードバックループによるレベルアップは期待できません。むしろ、スキルアップしたなと思われたら転職される危険性もあります。だから、そういうときには単純にツールを活用してもぐら叩きをさせます。
一方で、育成したいプログラマ要員の場合にはきちんとフィードバックループを使って、コードモデリングのレベルアップを図ってあげた方がモデリングの基礎力が上がります。構想段階でばっとクリーンなコードがモデリングできるかどうかは、一般的なプログラマの場合にはプログラムコードのバグフィードバックをきちんとしたかどうかが鍵だと考えています。
机上デバッグを呆然としていても効果は上がりませんが、きちんとフィードバックがまわせれば半年くらいあれば、机上見直し後のコードバグの混入率は0.5件/KLOCくらいまではすぐに落ちますよ。べらぼうに高い静的解析ツールなど必要ないですね。
ただ、それができない要員を使うような場合には必要に応じて使えばいいです。
わかりませんかねえ?

コメントを投稿する