ソフトウェア開発の発注から気づいたこと

以下の文章は、ソフトウエア技術者協会のメルマガの幹事コラムで執筆したものの転載です。
(蔵川 圭, ソフトウェア開発の発注から気づいたこと, 幹事コラム, SEA-MAIL メルマガ版 2011 年 第 10 号, 2011.10)

----
現在、国立情報学研究所で学術情報サービスのソフトウェアの開発を行っている。開発といっても、研究開発的なプロトタイプ作成から実際のサービスとして事業化するための発注と運用を行っている。SEAの仲間に加えてもらって活動をしはじめた頃には、ソフトウェアエンジニアリングとは何かということを大学に籍を置きながら本や論文を読んで、実際のソフトウェア開発ではいったい何が問題であるのかということに思いめぐらしていたことを思い出す。その頃から今に至るまで、一貫してソフトウェアの設計や開発はどうあるべきか、ということを心の中に抱き続けている。

ソフトウェアの仕組み、コンピューターがどう計算するのかという原理、どう設計開発するのかということを大学におけるカリキュラムや研究室の議論で学んだ。現在の居室の隣で毎日のように開講されている弊所の看板事業の一つであるTopSEの講座に立つ講師の声から想像される内容と大学にいたときに学んだことはおそらく同じである。これまでに、細かいことが理解できたかどうかはともかく、ソフトウェアエンジニアリングにはどのような議論や考え方があるのかを知ったことは今の仕事の基礎となっている。

国立情報学研究所にも、事業として提供している情報サービスがある。大学における図書館業務のシステムや、論文や研究助成に関連する学術情報のデータベースであり、それらはWeb上に公開されたエンタープライズシステムとなっている。日本の研究者の中には、NACSIS-CAT、CiNii、KAKENなどの学術情報サービス名を聞いたことがある人も多いと思われる。学術情報サービスというドメインは、ソフトウェアに要求される機能と要件が、よく授業で取り上げられる医療機器の組み込みシステムや大規模な証券システムとは異なる。少なくとも、学術情報サービスは、生死に直結するような品質を求められることもないし、金銭に絡んで紛争を起こすようなこともない。ただ、大学の先生や研究者の名誉や評判に関わるようなことには気を使う。

国立情報学研究所に来て事業システムの開発が仕事の一つとなり、最初に持った興味は、実際の開発はどのように行われているのかということであった。弊所では内製はしておらず、ソフトウェアの仕様を作成して発注する。開発者とは定期的に打ち合わせを行いながら詳細な仕様を決定していき、最終的にソフトウェアとドキュメントができあがる。ドキュメントには設計書やテスト仕様書、運用手順書などが含まれる。これらのすべてをもって、開発の様子を想像する。

弊所での開発体験から得た最初の気づきは、実際のソフトウェアは思うようには動いていないということであった。第二の気づきは、かならずしも大学で教えるような技術をすべての開発者が使っている訳ではないということであった。第三の気づきは、ソフトウェア開発の見積もりはできないということであった。こう言い切ってしまうと弊所の開発チームを無能呼ばわりしているような誤解を与えるが、そうではなくて、どんなに優秀なチームであってもこれらの問題に立ち向かいながら最終プロダクトをリリースするというのがソフトウェアプロジェクトの本質ではないかと思う。

これらのことが起きるのは、少なくとも私が関わっている開発では、初期の仕様を発注仕様書として与えてからプロジェクトがスタートし、徐々に詳細な仕様をつめていって最終プロダクトとして実現されるプロセスを追うからである。仕様詳細化のプロセスを追うとき、上流仕様変更は開発者が最も嫌い、仕様の詳細化にあたっても常に一貫性をもった詳細化が求められる。初期の発注仕様がおおまかな外部要求としてプロジェクトに投入されてからは、発注者としての私がどう詳細化したいかではなく、プロダクトはどう詳細化されたがっているかを常に考えるようにしている。詳細化の結果は論理的な思考のみに導かれる。詳細な仕様が初期の予想と異なっていても、そこに至る思考を明示することで、不思議と開発者は納得して仕様変更を受け入れる。

事業として開発を進めるときコストと納期を常に意識する。ソフトウェアエンジニアリングにおける技術を習熟したり適用したりするにも、コストと納期を意識した結果、あまり細かいことを問わない方が良い結果を生むときがある。むしろその技術の適用によって左右されるインパクトよりも、ソフトウェアを作る人の個性がもたらすインパクトの方が、大きく最終プロダクトの善し悪しを決めると思われる。そういった意味で、適材適所のチーム構成が最終プロダクトの性格を決める結果となることを体感している。

ソフトウェアの見積もりは、開発者との阿吽の呼吸になっている。詳細な仕様が決定していなければ細かい見積もりもできず、あまり細かすぎる見積もりはむしろそれにコストがかかってしまう。発注者の私ならこういう手順でこうプログラムを書いていくというワークを想像しながら、開発者の思いとすりあわせていく。コスト見積もり手法とはほど遠い。開発経験のない営業との折衝ではこの方法はまったく通用しなくなる。

ソフトウェア開発は仕様の決定と実装にかかわる連続的なコミュニケーションの結果であることを発注者の立ち位置から体験している。ここでは関係者全員が理性的であることを常に求められている。理性がコミュニケーションコストを最小にする唯一の方法ではないかと考えている。

最後に、現在もなお私の頭を悩ませていることがある。それは、ハードウェアについて見積もり合わせした結果一番安く想定した製品を購入できるように、まだあまり仕様のはっきりしないソフトウェアの開発案件を見積もり合わせして、結果的に一番安く、想定したソフトウェアを手に入れるうまい方法が見つからないことである。これは可能か、否か？これができれば官公庁のソフトウェア開発入札業務がもっと明瞭で合理的になるであろうに。