吉原庄三郎『はじめての設計をやり抜くための本』

はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)

はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)

私はITエンジニアではないが、コンサルタントという仕事柄、ITエンジニアと働くこともあるし、ITプロジェクトに参画することもある。最近はかなり本格的なITプロジェクトに参画していることもあり、そもそも設計作業とは何かを包括的に把握したく、本書を購入してみた。本書は設計作業の最初から最後まで解説してくれているため、全貌が見えて、かなり役に立つ。まずは全貌を掴むためにざっと読んだが、今後、何度も読み返すつもりである。

ところで私は以前から「そもそも設計はどこまで必要なのか」という点について漠然と疑問に思っていたのだが、(たまたまだが)著者も問題意識を持っていたらしく、第1章でこんなことを書いている。

 最近では、設計という作業そのものが必要なのか不要なのかが議論されています。それは、アジャイルと呼ばれる開発方法論が、設計を必要としないまったく新しい手法を提言しているからです。新しい技術が常に正しいとは限りませんが、アジャイル開発方法論は非常に魅力的に見えます。これからのシステム開発の主流になるかもしれません。

さらに、最終章である第7章では、設計が必要な理由・不要な理由をそれぞれの立場から整理してくれており、なかなか興味深かった。

余談

アジャイルについては正直あまりわかっていなかった(ウォーターフォールと違って臨機応変に開発するんでしょ程度の理解だった)ので、本書を読みながら色々と検索していたところ、ソニックガーデンという企業の社長のブログが引っかかった。以前ニュースか何かで見かけたのをぼやっと覚えていたのだが、納品をしないというビジネスモデルで最近ブレイクしているIT企業である。

「納品のない受託開発」の進めかたの一つに「ドキュメントを書かない」というものがあります。「納品がないからドキュメントを作らない」というのは事象の結果であって、理由ではありません。その理由について、もう少し掘り下げてみましょう。
一般的にドキュメントには、開発側から見た工程間の伝達や保守への引き継ぎのための設計書と、顧客から見たソフトウェアがどのように動けば正解かという仕様書の2種類があります。
私たちの場合、お客さまとの対話から運用まですべてを同じエンジニアが担当するので、工程ごとに伝達するための資料はいりません。保守運用も同じ人が担当することで、引き継ぎの資料もいらないのです。内部的にはドキュメントがいらなくなります。誤解のないように書いておくと、設計書を作ったりはしませんが、設計作業は毎週少しずつ行っています。
また、仕様書を作ったからといって、その通りにソフトウェアを作りさえすれば良いかというと、それが事業として価値があるかどうかわかりません。大事なことは動くソフトウェアで価値を産み出しているかどうかです。そこで、動いているソフトウェアそのものが仕様である、と考えるようにしています。常に動くソフトウェアで動作確認し、直し続けていくのです。
そもそも動くソフトウェアを構成しているのはソースコードです。ドキュメントではありません。ソースコードこそがもっとも貴重な資源であり、仕様を現した事実です。最終的にはソースコードを読むしかありません。そのソースコードを自ら書いて読めるエンジニアがずっと担当していることで、いつでも仕様の把握ができるのです。

「ソースコードこそがもっとも貴重な資源であり、仕様を現した事実です」というのはなかなか考えさせられる言葉である。設計が不要かどうかというのと、設計書が不要かどうかというのは、また別の議論だからである。
この人は最近書籍も出版しているようだ。面白そうなので、機会があれば読んでみたい。

「納品」をなくせばうまくいく