Lazy Diary @ Hatena Blog

PowerShell / Java / miscellaneous things about software development, Tips & Gochas. CC BY-SA 4.0/Apache License 2.0

「詳細設計書」の目指すところと戸籍情報システム標準仕様書

日本の各自治体で行われている戸籍事務は法定受託事務です。ですから、各自治体で実施する事務の内容がバラバラでは困ります。

そのため、戸籍情報システムを開発するベンダー向けに、法務省が「戸籍情報システム標準仕様書」(標準仕様書)という資料を公開しています*1。この標準仕様書は、ISO/IEC12207:2008(SLCP-JCF2013)における「ソフトウェア詳細設計」のレベルで書かれていて、戸籍情報を保存するファイルの構成や、実装すべきロジックを事細かに規定しています。どのベンダーでも標準仕様書の通り実装すれば戸籍システムが作れますし、どのベンダーが作った戸籍システムでも同じように戸籍事務が行えるわけですね。

戸籍システムを各自治体へ導入するためには、標準仕様書への準拠を法務省に認定してもらう必要があるので、一度開発してしまうとアーキテクチャを変更しづらいというデメリットはあります(システムを作り直すと認定も取り直しになるため)。ただそういったデメリットはあるにせよ、標準仕様書は実際に機能しているように見えます。1600ある日本の各自治体で使われてる戸籍システムが、すべて法務省の認定を通るレベルで同質になってるわけですからね。*2

ソフトウェア開発における、いわゆる詳細設計書は、かなりソースコードに近い内容を書くこともあって、生産性を下げる原因として槍玉に上がることがよくあります。ただ、この標準仕様書こそ、「誰が実装しても同じようになる」という詳細設計書の目指していたものを体現する実例なのでは、と思うわけです。

この詳細設計書は、戸籍事務の種類ごとに処理内容が「全部書いてあって、上から読んだらわかる」*3ような、トランザクションスクリプトの形をしています。やっぱり、開発者のレベルに関係なく実装のレベルを揃えるにはトランザクションスクリプトの形がいいんでしょうかね。

あと、作られたのがかなり昔ということもあり、標準仕様書の内容は基本的にCOBOLで実装することを念頭に置いたような書き方になっています。学生のときにインターンで行った某社では「アーキテクチャ設計さえちゃんとしていれば、ロジックは誰でも書ける」ことを重視して、基幹系業務のビジネスロジックの実装にはCOBOLを採用していました。ちょっと話がズレますが、アーキテクチャ設計とビジネスロジックの設計とを分離できるかできないかが、エンタープライズアプリケーションとそれ以外の境目、という気がしています。

さて、戸籍システムを知っている/作ったことのある会社では、上層部から投げかけられる「戸籍システムではうまくいっているのに、なぜ他の業務では詳細設計書を作らないのか」という問いに反駁できるようになるまでは、「誰が実装しても同じようになる」詳細設計書を作ることを目指し続けることになってしまうのではと思うわけです。その問いに答えるには、やっぱり詳細設計書を作ってデータを集めて分析する必要があって……しばらくは詳細設計書から逃げられそうにないですね!

*1:http://www.moj.go.jp/content/000112223.pdf

*2:余談ですが、総務省では戸籍以外の自治体業務(介護とか住基とか)に対しても標準仕様書を策定しようとしているようです。参考: https://www5.cao.go.jp/keizai-shimon/kaigi/special/reform/committee/20191009/shiryou3.pdf

*3:https://twitter.com/satob/status/1181240183506685952