« 仕様の「見える化」と働き方改革 | トップページ | オリンピックをモデリングしよう »

2018.05.23

Excel仕様書を機能タイプ別に様式化する

 商売柄いろいろなシステム開発企業の「Excel仕様書」を見てきたが、Office系ツールで仕様書を書くことの是非は別として、いつも不思議に思うことがある。アプリの仕様を盛り込むための様式が、プロジェクト毎に1種類に固定されている点だ。プロジェクト間の違いはあっても、プロジェクト内ではなぜか1種類の様式で統一されているのである。

 その奇妙さを喩えるなら、役所の申請用紙がたった1種類であるようなものだ。現実には様式はいくつもあって、住民からのさまざまな申請はそれらのいずれかに沿ってまとめられる。開発されるアプリの仕様も同じように扱われたほうがいい。役所での申請だろうがアプリの仕様だろうが、1種類の様式しかないのであれば、その内容を記載しにくいし読み取りにくいからだ。様式を1種類に「標準化」することには何の意味もない。

 複数の様式を整備するためには、アプリを類型化する必要がある。ただし類型は多ければ良いわけではない。多すぎると選び出しにくいからだ。そのためにまずは、共通部分と固有部分を分けて考えるとよい。共通する仕様要素は以下のとおりである。

<共通の仕様要素>
・ID、名称、概略説明
・引数と返数
・テーブルやUIとの入出力レイアウト

 類型毎に固有な仕様要素はどうだろう。アプリの類型、すなわち「機能タイプ」の一例として、「特定テーブル上のレコードを、ユーザ指定の絞り込み条件にもとづいて複数件一覧し、その上の1件を後続処理の対象として選択するためのUIアプリ」を考えてみよう。このタイプを「明細一括表示」と呼ぶとして、以下のような仕様要素を想定できる。

<"明細一括表示"での仕様要素>
・一次テーブルは何か
・参照テーブルは何か
・一覧される項目は何か
・絞り込み条件は何か
・選択行に対して起動される機能は何か

 これらを考慮すれば、「明細一括表示」向けのExcel仕様書と実際のアプリはたとえば次のようになる。ちなみにこの仕様書は、拙作のエンジニアリングツールからExcel出力したものであって「本物」のExcel仕様書ではない。

▼「明細一括表示」用のExcel仕様書様式と実際のアプリ
20180521

 私が日常的に利用している機能タイプは、上掲を含めて8種類程度なのだが、参考までに他の3種類も挙げておこう。こういった類型を整理するには、アプリが扱うテーブルの論理関係をとらえることが肝心だ。

・明細一括更新
特定テーブル上のレコードを、ユーザ指定の絞り込み条件にもとづいて複数件一覧し、その上項目の値を一括更新するためのUIアプリ

・見出し明細表示
特定テーブル上の特定レコードを"親"とする、いくつかの"子テーブル"上の関連レコードを、ユーザ指定の絞り込み条件にもとづいて複数件一覧し、その上の1件を後続処理の対象として選択するためのUIアプリ

・見出し明細更新
特定テーブル上の特定レコードを"親"とする、特定の"子テーブル"上の関連レコードを一覧し、親レコードと子レコード上の項目値を更新するためのUIアプリ

 ここまで見れば、多様なアプリの仕様をたった1種類の様式でまとめることの無理や無駄がよくわかるだろう。そういうわけなので、使っているものがExcelだろうがWordだろうが、まずは機能タイプ別に様式化されたテンプレートを用意したほうがいい。それだけで、仕様書管理は格段に合理化される。Office系ツールでの仕様情報管理をいろいろな事情からやめられない職場でも、とりあえず試してみる価値がある。

 じっさいこの考え方はたいへん有効で、ドメイン特化言語(DSL,Domain Specific Language)を用いてソフトウエア開発を合理化するための基本でもある。すなわち、それぞれのソフトウエア分野(domain)において、処理されるデータ構造を形式化するとともに、それを処理するアプリを類型化する。そして、それぞれの類型に沿った仕様様式を扱うための「仕様書エディタ」を開発する。同時に、様式化された仕様にもとづいてコンピュータを動作させるための「仕様書ドライバ」を開発する。かくして、DSLを基礎とするドメイン特化基盤(DSP,Domain Specific Platform)が完成する。この態勢において仕様書は、従来のような「(人間への)プログラミング指示書」ではなく「(コンピュータへの)動作指示書」である。仕様書を書けば実装とUTが終わるので、実装専任者もテストドリブンも要らない。

 ここまで書いて気づいたのだが、ExcelやWordの機能タイプ別テンプレートのようなものを整備することは、職場の上司からは嫌がられるような気がする。アプリの類型別の仕様様式を考えることと「DSP」とは、概念的にはほんの一歩の違いしかないからだ。テンプレートを切り替えて使ううちに、職場の精鋭がDSPの可能性に気づいて自作してしまうかもしれない。管理者にとってこれは困る。

 なぜならDSPが開発現場にもたらされたら、今まで人海戦術で大騒ぎしながら扱ってきた案件が、少数の精鋭だけで粛々とこなせることがはっきりするからだ。その冷酷な事実は、システム開発に関する「手順に従いさえすれば適性やセンスを問わず誰でもやれる簡単なお仕事」という共同体幻想を損なうだけでなく、外注先と長年培ってきた「事業エコシステム」までを揺るがす。40代以上の管理者なら、自分が退職金を手にするまでそんな変革は起こってほしくないと考えるだろう。

 そのような上司の下で働いているのであれば、この記事で述べた助言は忘れたほうがいい。開発されるアプリは「みんなちがって、みんないい」のであって、それらを類型化するなんてゴーマンなことだ。単一様式のExcel方眼紙上で手間暇かけてまとめられる個性的な仕様を、ひとつひとつ心をこめてプログラミングするのが我々の仕事――そのように考えたほうが、退職金を心配する上司からは嫌われずに済むだろう。まあ、そんな上司に好かれても良いことはなさそうだが。

|

« 仕様の「見える化」と働き方改革 | トップページ | オリンピックをモデリングしよう »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: Excel仕様書を機能タイプ別に様式化する:

« 仕様の「見える化」と働き方改革 | トップページ | オリンピックをモデリングしよう »