エルフシステムソリューションズ！

第二章 プロジェクト

設計書

　先日のスケジュールに関する騒動から十日ほど後。僕らのプロジェクトは、大きな問題もなく進んでいた。
「じゃあ明日の打ち合わせには、予定通り先輩の作った仕訳表示機能の詳細設計書を持っていけますね」
「ああ、もう少し残ってやってけば完成する。ラインガウさんに見せて仕様の取り違えとかないか確認してきてくれ」
　午後九時半、ヤン先輩とそんな会話を交わしてから、僕は家路についた。
　システム魔法の設計段階においては、通常『基本設計書』と『詳細設計書』の二種類を作成する。基本設計書は入力されるデータの取得元や取得条件、表示や出力される内容など、機能の外部とのデータのやり取りやシステムの外側から見た動作などを記載したもので、外部設計書とも呼ばれる。それに対して詳細設計書は、機能の内部でどのような処理がなされるかについて細かく定義したもので、内部設計書とも呼ばれる。システム魔法の開発はまず基本設計書の作成から始まり、ついで詳細設計書の作成を行うが、今回のプロジェクトは現在、基本設計書が一通り完成して詳細設計書に取り掛かっていた。開発者三人で分担して作成している詳細設計書のうち、ヤン先輩が担当している仕訳表示機能の設計書がまもなく完成するので、明日のラインガウさんとの打ち合わせでそれを提示し、お互いに仕様についての認識のズレ等がないか確認する。
　ちなみに、我がエルフシステムソリューションズの作成する詳細設計書は、本来の詳細設計書としては少し不完全なのだそうだ。本当ならば詳細設計書というのはもっと処理の一つ一つを厳密に、術式を構成する呪文の一文節ごとに、逐一この国の日常語であるマザール語に変換するくらいの粒度で記述するものなのだそうだ。詳細設計書を十人の魔法技術者に与えたら、十人とも一字一句完全に同じ術式を組み上げるくらいのものなのだ。だが弊社の詳細設計書はそこまで細かくない。何をしたときにどんな処理をするかを、なるべく細かく記述してはいるものの、同じ設計書を異なる複数の技術者に実装させたら、実装者ごとにある程度術式の差異は出るはずだ。ヤン先輩が過去に経験した他の現場では、このレベルの設計書は詳細設計書と呼ばないそうだ。その現場では基本設計書と詳細設計書の中間レベルの『システム設計書』というものも作成しており、うちの会社の詳細設計書はその現場におけるシステム設計書に相当するそうである。
　ただ、詳細設計書と称してシステム設計書レベルのものを作成し、本来の意味での詳細設計書を作らない現場は、うちの会社に限らずたくさんあるのだそうだ。
「大体、厳密な設計書なんてのは設計者と術式作成者コーダが分業されてるような場合でなければそもそも必要ないんだよ。開発チームがちゃんと自分で設計して術式を組める魔法技術者だけで構成されていれば、システム設計書を見れば術式は組める。しかも本当の意味での詳細設計書を作るのには、実際の術式を組む以上の時間がかかる。そこに書かれるのは技術者なら術式を見ればわかるような内容なのにだ」
　いつだったか、ヤン先輩はそんな風に言っていた。
「じゃあ三種類の設計書の中で、術式を組む上で僕らが一番重視しなきゃいけないのはシステム設計書なんですね」
　僕がそう聞き返すと、ヤン先輩は「そうとも言えるんだが、違うとも言える」と意味深な言い方をした。
「確かに、システム設計書を書いて、詳細設計書を省略するプロジェクトにおいては、システム設計書を見ながらそれに沿った術式を作らなければならない。だけど例えば……そうだ、これ読んでみろ」
　ヤン先輩は自分の机の引き出しをごそごそやって、底の方から何やら書類を取り出した。僕の知らないプロジェクトの詳細設計書だ。うちの会社の詳細設計書だから、つまりシステム設計書相当のものである。
「このシステムはもう運用すらされてないから部外者に見せてもいいだろう。この設計書を見れば、アリステ魔術の術式でそのとおりの動作をするものを作ることはクロトなら難しくないよな？」
　僕はうなずく。伝票データを加工・集計して表示し、必要なら紙に印字する機能の仕様書で、印字する場合は表示するものよりも細かい内容を出力しなければならないため、内部的にややめんどくさいデータ加工を行っているが、詳細設計書通りの処理をする術式を組めばいいだけなら作れるだろう。
「じゃあ、このシステムを修正しなきゃならない場合を考えよう。集計条件を入力した時点でその期間の売上伝票・仕入伝票の合計金額が表示され、魔法陣上の『表示』ボタンに指で触れることで日ごとの集計が出るようになっているが、ここで期間集計は税込みの金額、日ごとの集計は税別の金額、印字するのは両方となるように修正しないといけなくなったとする。そういう修正は往々にしてシステムが運用されている期間に発生するから、設計書を直している暇はない。一刻も早く修正したシステムをリリースして、その後で設計書にその修正をフィードバックしなきゃならない。そんなとき、この設計書からいきなり修正した術式を作れるか？」
　ヤン先輩の問いに、僕は設計書を睨んでしばし考えた。現状では期間集計も日計も、印字されるさらに細かいデータも、全て税込みの表示をしているようだ。日計に表示される金額を税別に修正するとして、日計には『税額』も表示されているが、これは表示されている金額から税別の金額を引くことで算出しているから、それも修正しなければならない。印字するデータにも、従来表示されている税込み以外に税別表示も追加する必要があるが、今まで税別は表示していなかったために、そのデータは集計後に捨ててしまっているから‥‥。
　単純な修正かと思いきや、意外に難しい。何より考えの妨げになるのは、現状の実装が妙にまわりくどい処理をしているからだ。恐らく今までに何度も急ごしらえの修正を繰り返して来たのだろう。集計後にいくつかのデータを捨ておきながら、印字する際に捨てたデータのひとつが必要になって他の項目から算出したりしている。項目一つ一つがあちこちでいろんな計算に使われていて、一箇所を税込みから税別に変えるとどんな影響が出るかわかりにくい。『どうしてこんなにまわりくどい事をしているのか』が判然としないから、処理を変えてしまって良いかの確証が持てないのだ。
　上記の理由で簡単に修正できないという僕の考えを先輩に伝えると、彼はその答えに満足げに頷いた。
「こういうケースは珍しくない。改修を繰り返してわかりにくい術式。しかも作った人は別の現場に異動している。そんなとき、重要になるのが基本設計書だ。表示や出力、他機能との間のデータのやり取りなどが、基本設計書に書かれている仕様と変わってしまわないかぎり、内部の処理はどう変えても良いはずだ。クロトも、基本設計書があれば改修できそうだろ？」
　僕は頷く。
「だからな、なにが言いたいかっつーと、詳細設計書だけじゃなく、基本設計書も重要だって事だ。仕様変更があった時に、忙しさにかまけて詳細設計書のみを修正して基本設計書をそのままにしたりすると、実際の仕様と設計書とが食い違ってしまう。そうなるとこういう修正の時に苦しむ事になるんだ。だから、基本設計書のメンテを怠るなよ」
　訓戒を垂れるヤン先輩に、山猫が茶々を入れる。
「そう言うヤン君こそ、今詳細設計書を書いてる仕訳表示機能で仕様変更があったのに、基本設計書に反映させてないにゃ」
　ヤン先輩は、脇ヘよけていた仕訳表示機能の基本設計書を慌てて引っ張り出すと、修正を始めた。