freeに見るネット系の開発スタイル

2023年7月21日

以前のブログ記事で、「白色申告において、記帳と帳簿の保存が義務付けられ、これに伴って記帳ソフト(会計ソフト)のニーズが 増大している」ことを書いた。
この記帳ソフト(会計ソフト)の中の1つである、freeの開発にまつわる話が「Web+DBPress (Vol.82)」(技術評論社)に掲載されていた。
この記事は主に、ソフトウェア開発の生産性や効率性、保守性などの観点に重きを置き、 実装面を中心に書かれているが、この開発事例をプロジェクト管理の視点から読むと、なかなか興味深い。

本題に入る前に、「ネット系」と「エンタープライズ系」という言葉について触れておく。
この言葉は日経ITProのサイトで見かけたものである。この用語がIT業界で一般的なものかどうか、私は良く知らない。
私自身はこの分類に従うと「エンタープライズ系」に属するわけだが、自身が属する業界のことをこの名称で呼ぶことも、また呼ばれることもほとんどない。
エンタープライズ系とは、主に企業の基幹システムや業務システムを構築するSIベンダーとその協力会社を指している。 具体的には、NTTデーターや、NEC、富士通、IBMなどである。
一方のネット系とは、一般消費者向けにインターネットサービス(Web系アプリケーション)を提供している企業を指している(と思われる)。 具体的には、ディー・エヌ・エーやクックパッド、サイバーエジェントなどである(と思われる)。

日経ITProの記事によると、ネット系企業とエンタープライズ系企業は、お互いに情報交換や人事交流が無い疎遠な関係であり、 且つ、それぞれが自分たちの業界こそが「IT業界」であり、相手の業界が「IT業界」だとはつゆほども思っていない、ということである。
この指摘はかなり正しいと思う。
そのようなわけで、私もネット系企業のことは雑誌の記事などで知り得る範囲の知識しか持ち合わせていない。 先ほど私がネット系企業の説明を書いた箇所で「・・・と思われる」と書いたのは、そのような理由からである。

さて、freeは、この分類方法によるとネット系企業に属する、若いスタートアップ企業である。
ネット系企業の開発スタイルとエンタープライズ系企業の開発スタイルとは、かなり異なっている。 これは文化の違いと言っても良い。
一番大きな違いは、ネット系企業の多くがアジャイル型の開発手法を採用しているのに対して、エンタープライズ系はほとんどの場合 ウォーターフォール型の開発スタイルを採用している、という点である。
アジャイル型開発は、「仕様は変わるもの」という前提に立っている。 これは、一般のネットユーザを対象にしていることを考えれば妥当な対応である。
アジャイル型開発では、仕様定義から実装、テスト/検証までを短いサイクルで繰り返すことで、仕様の変更に対して柔軟に対応しようとする。
freeも仕様は変わるという前提で開発を進めていると思われる。
一方、ウォーターフォール型の開発は、仕様は要件定義フェーズか、遅くとも基本設計フェーズまでには確定させる。
これは、ユーザー企業がITベンダーにシステム構築を委託する際、実装からテストまでを請負契約で発注することが多いからである。 そして、発注するためには仕様を確定して製造フェーズ以降の金額を確定させなければならない。 これは、ユーザ企業がITに関わる年度予算を確保するうえでも必要な措置である。

エンタープライズ系から見て、freeの開発記事で驚きなのは、スピード、特にリリースのスピードを最優先にしている点である。
記事には「サービス開始から半年程度までは、とにかく動かすことを最優先に、美しいロジックによる バグの無いコードを書くことよりも、一刻も早くデリバリーすることが求められた」と書かれている。
エンタープライズ系では、品質目標よりも早期リリースを優先することはまずあり得ないだろう。 ユーザー企業の業務システムが、プログラムの品質不良に起因するシステム停止や誤動作をした場合、 ベンダーはユーザー企業から損害賠償を請求される事態になりかねないからである。
特にリアルタイムシステムのトランザクション処理では、システム停止やスローダウン、誤動作が命取りになる。
より高い品質が求められる業界や業種の場合、ベンダーは開発部隊によるテストだけでなく、,品質管理部門など独立した組織による 品質検査や品質監査を行うことも珍しくない。

freeの開発で次に驚きなのは、その開発体制である。
freeの開発体制は、スタートアップ企業ということもあるが、当初5名であったという。インフラ系のエンジニアも当初はいなかった。
いくら白色申告とはいえ、会計ソフトの新規開発でこの人数はかなり少ないと感じる。
インフラ基盤にAWS(AmazonWebService)を利用していることが、少人数体制を可能にしている1つの要因かもしれない。
いずれにしろ、少人数体制でシステムを構築するためには、エンジニアの多能工化を進める必要があるだろう。 多能工化によるセル生産方式は、システム開発においても有効な生産性向上手段と言えるかもしれない。

サブシステム(またはアプリケーション)を分割するタイミングも、エンタープライズ系とは異なる。 サブシステムやモジュールを分割する際、お互いを「疎結合」にする、という設計方針は同じであるが、分割するタイミングがエンタープライズ系の思想とは異なっている。
「freeの場合は、・・・1日に複数回のデプロイをしたいと考えている。 アプリケーションが巨大化し、1日1回程度しかデプロイできないような状況が続いたらアプリケーションの分割を考えます。」 と語っている。
ウォーターフォール型開発の場合は、基本設計フェースまでに、サブシステムやアプリケーションの分割を設計しているはずである。
下流工程で分割を行うと手戻りが発生し、進捗とコストに多大な影響がでる。
freeの場合は、アプリケーションをスパイラル的に成長させていく前提に立っているためだと思われる。

開発方法論や標準化に対する考え方もエンタープライズ系とは異なっている。
freeでは、「当初は社内にデザイナもおらず、そのためかHTMLやCSSも独特の書き方をしていた」という。
エンタープライズ系では、プロジェクトが大人数になるケースが多く、またプロジェクト毎にエンジニアの顔ぶれが異なるので、 開発方法論と標準化の導入はほぼ必須である。
すなわち、誰が作ってもある一定レベルの品質が確保でき、出来栄えにバラつきが出ないようにすることが求められる。
そのためには、開発プロセスや手法、規約、ツールなどを標準化する必要がある。
エンタープライズ系の場合、ベンダーごとに自社の開発方法論を持っており、共通フレーム(SLCP)等との親和性も高い。

スタートアップの本来的な意味はイノベーションであろう。
freeの開発にも、先進的な技術を積極的に採用してスピードを追求するイノベーターの姿勢が窺える。 一方で、保守的なエンタープライズ系から見て、危うさを感じる部分も少なくない。
今後アプリケーションが成長し、それにともなって大きくなっていく組織のマネジメントが課題になってくると思われる。
仕訳や決算の知識がなくとも記帳できるソフトとしてスタートしたfreeだが、ユーザの要望を吸収していけば機能がどんどん増える。さらに、青色申告にも対応できる会計ソフトへの成長が視野にあるかもしれない。
組織が大きくなれば、分業体制や標準化の推進も必要になろう。
また、革新性が失われて保守的になったり、セクショナリズムが芽生えるなど、大きな組織特有の弊害が生じる可能性も考えられる。
いろいろと課題はありそうだが、それでも、新しい技術にチャレンジし、アジャイルに開発するイノベーターの開発事例はエキサイティングであり、その姿勢には学ぶ点が多い。

プロジェクト管理あれこれ
「プロジェクト管理あれこれ」のINDEX