Versus Excel Workbooks.

同僚というか後輩の一人にものすごくコードを完成させる速度の速いやつがいる。技術的にもある程度信頼できるので、瞬発力の必要な局面で重用されている。その技術と仕事の速さにはだれも申し分ないのだけど、どうにも仕様書の行間を読めないようだ、というのがこの間同僚の間で話に挙がっていた。 その時話題に挙がっていたのはコードと名称が対になっているような項目で、入力画面で選択したものを別な画面で表示項目として見せる時に、当然名称をラベルとして表示すべきところを、設計書の記述が十分でなかったために彼はコードを表示する実装をつくって作業完了と報告してきたらしい。 設計者とプログラマはここでは別々だったのだが、設計者側にしたらこのくらい気を使って当然というか、せめて何かおかしいのではと声をかけるくらいしてきてもいいのではないかという。まあ、まっとうかどうかはわからないが、気持ちはわかる。

結局システムなんてお客様に使っていただいてなんぼなので、使いにくい実装を看過するという態度そのものが問題ではあるのだけど、果たしてそういった局面でいちいち気をまわしていては当然実装の手も進まなくなってしまうわけで、この辺生産性をどう考えたらいいのか悩んでいる。いくら早くできても使いにくかったら意味ない、という反面、実際に試してみなければ問題にすら気づくことすらできない設計とやらに時間をかけていてもどうなのかという気がする。究極的には顧客の利便性であるとか利益につながることが正義であるにせよ、もちろん時間と金は有限であるわけで、限られた中で最適なやり方を選択していく必要がある。

設計書の行間を読むべしというのはそもそも設計書を疑ってかかることに等しいわけで、となればその設計というものの価値がどの程度であるのか再考する必要はありそうだ。

設計者が自分の意図したことを設計書という特定のフォーマット（大体のケースに於いてExcelで何種類かのシートでまとめられたアレだ）にエンコードし、実装者が設計者の意図を推測しつつそれをデコードしていくという作業が日々行われているわけだが、改めてこう書いてみるとなんだかすごく非効率なことをしている気がしてくる。「特定のフォーマット」というのがまた厄介で、これは設計者の生産性を顕わにする代わりに記述の柔軟性と著者の思考力を制限する。制限された記述でまとめられた設計書にはいろいろ記述しきれないものが出てくるが、基本的にそういったものは捨てたほうが設計者の生産性は向上する（ように見えるようになっている）。実装者はこの記述しきれなかったものを拾うためにExcelワークブックと格闘しなければならないことになる。

ここで捨ててしまう記述をすべて漏らさず記述すればよいのか、といえば、それもばかばかしい話なのはご存知の通りで、実装を一意に確定できるレベルまで設計書を記述するということはできるかもしれないが、それでは実装作業をしたのと同じくらいのコストがかかるはずであるし、そのくせ設計を動かして検証することはできないのだから、その設計で正しく動く保証もない。いくら時間や金をかけてレビューしたり見直したとしてもつまりマイナスでしかない。実装面から見ていくら抜けがあろうとも設計者にとってみればそれでもさまざま考えた挙句の成果物なのであるし、人間だれしも限界はあるわけで、こんなことを考えるのは無駄な努力という気がする。

結局のところ設計は実装の裏打ちがなければ正しいと断定することができないのではないか。であれば、設計が正しいと断ずるところですでに実装があるべきのように思われる。 （証明可能なソフトウェア設計書というのは少なくともこの21世紀にあってまだ登場していないとおもうが、もしご存知の方があれば教えていただきたい）

個人的にこの頃、設計と仕様という言葉は意識的に使い分けている。設計はあくまで計画だ。実際にできているものとは異なる。仕様はできているもののありようを説明するものだ。だから、本質的に設計は仕様ではないし、仕様は成果物に基づいて記述されなければならない。さらにいえば、本来的には両方存在しなければならないのだろう。（どちらかしか成果物として定義されていないプロジェクトがほとんどだし、両方を成果物として作成する時間をあらかじめ見積もっているプロジェクトなんて見たことない）

個人的にはだいぶ以前から、「プロジェクトにかかわるすべてのステークホルダーそれぞれに対して、それぞれに説明するためのドキュメントが本来発生するはずである」という考えを持っているのだけど、その中で、設計書は設計者から実装者へ、仕様書は実装者から実装以後のプロセスに関わる人たちの一部に対して書かれるべきものとして捉えている。

設計が計画であるということを意識すれば、それを使って行うことのそれぞれがどのような意味を持つかが少し変わってくるかもしれない。設計をレビューするのは、計画をレビューするということであり、それによって仕様が説明されるわけではない。仕様をレビューしたいのであれば、成果物に基づいて行う必要がある。

効率を考えれば設計書なんてほとんど正式な文書として存在する意味がない現場も多いだろう。実装を始めるために、最終的な出来を全体で共有するためのイメージや、全体的に重複した作業を共通化したりなどの段取りのためにもちろん事前の設計はあったほうがいい。が、それだけのことかもしれない。ただ、安定的に速やかに実装を確認できるレベルに持っていけること（あるいはその確信）が前提にはなる。先に述べたとおり最終的な決定としてのレビューや承認はそれに基づいて行われるべきなのだが、現時点で経験的に考えられる以上にレビューの差し戻しが発生することが予想され、それを実装力でカバーできるという素地は必要になるだろう。

「実装力でカバー」できなくなると、多分言った言わないとかスコープがどうのの議論になるので、それを回避するために設計フェーズという知恵が生まれたのかもしれない。ちょっと話がそれるが、そう考えると、やはりアジャイルソフトウェア開発宣言とはまず設計フェーズの破棄であるような気がしてくる。設計フェーズとはまさに「お前、最初にこう言うたやん」の言質をとるために必要で、アジャイルはそんなやりかたは（より）価値がないと考える、という宣言だとおもっている（私は）。

まあその話はいい。

そういう意味では、実装の熟練者がプロジェクトの早期から入る必要があるはずだ。設計を作る傍ら、フィージビリティとユーザビリティの裏打ちのために実装も開始しなければならない。そうすればたぶん、実装者と設計者は実装を中心に話をすることになるだろうし、Excelを介して探り合いをする必要はなくなるんじゃないか。

まあこんなことを言ってても直近では何も解決しないんだけど。