TOP

日本IBMの開発者200人超のWebシステム開発プロジェクトに自社開発フレームワークを導入

STSD株式会社の強み ~ 自社開発のフレームワークで生産性、品質を向上

いまやシステム開発の必須要件とも言えるになったJavaフレームワーク。私はJava Serlvetが誕生した当時からWebシステムの開発に携わっていました。

当時はフレームワークと呼べるものがなく、Webシステムの事例自体もまた多くない中、日本IBMでの当時AS/400と呼ばれるプラットフォームでの日本初の大型プロジェクトに取り組むことになりました。メンバーは20人程度、画面規模で言うと更新系が300画面超、公開系が100画面超、更新系と公開系のRMIによる通信、大規模なバッチシステム、これらを要件定義から約6ヶ月で終わらせる、という短期プロジェクト。プロジェクトは無事に終了させるこ とが出来ましたが、試行錯誤の末に完成したソースはプロジェクト内で共通化は出来ているものの、再利用が出来なく、一個一個のプログラム単位でも非常に生産性の低いものでした。

繰り返し、繰り返し、徹底的に無駄を省く

当時から、今後システムの中心技術になるのはWebであると確信していたので、近い将来に向けてこのプロジェクトで得た経験をフレームワークとしてまとめ、再利用できるように整理を始めました。

コードの中から、汎用ロジック的なものを共通ライブラリとしてまとめ、共通の振る舞いを分析し・抽出し、これらをインターフェースとして定義します。イン ターフェースとして定義したものを、さらに無駄がないか、もっと簡略化できないか、などの作業を行い、まとまったところでプロジェクトに対して適用しま す。(いずれのプロジェクトも日本IBMの開発者20名超、の中規模以上)

各プロジェクトでは、実際に私自身も開発に参加しました。これは非常に重要なことです。実務開発の経験の乏しい人が作ったフレームワークは「フレームワー ク開発者のためのフレームワーク」のようになっており、単純なことを妙に複雑な手続きを行う必要があったりするケースが往々にしてあり、生産性を下げるど ころか、開発者のモチベーションをも下げることにつながります。

自分も開発を行うことにより、無駄だと思えることは徹底して排除し、開発局面で自分で一から作る必要がないと思えたものは徹底してフレームワーク側に集約しました。また当時の開発に携わった人からの意見も重視し、シンプルに、かつ柔軟性高く、完成度を高めていきました。

そして完成したフレームワーク ~ wisdom

このフレームワークは誕生してから、延べ300人以上の開発者に利用され、要望、意見を積極的に取り入れ、より使い易く、無駄のないものへ進化しました。数度の大改定を経て、根本的な部分が完成した2004年に節目として、それまでのフレームワークのネーミングルールなどを整理して「wisdom」としてリリースしました。一重にそれまでのプロジェクト開発者の方々のご協力によるものです。
 
「wisdom」は以降もさまざまなプロジェクトに適用され続けましたが、「wisdom」自体への変更はほとんどなく、開発者が200名を超えるものでも、各プロジェクトにあわせた共通部分、固有部分の開発だけで済む、というフレームワークの目的を達成できたものに仕上がったといえます。
 
STSDでは、この多数の実績と多くの開発者により支えられたフレームワークを標準として利用することにより、大規模Webプロジェクトと同じ品質、開発生産性を維持したシステム開発を行っています。

フレームワークとは何か

  • 標準化の重要さ

    システムを開発する上で標準化というのは、作り出すまでのスピードと作業工数、完成した後の品質、運用フェーズでの保守工数にいたるまでシステム開発を行ううえで、コスト、品質、スケジュールすべてに大きな影響を与えます。標準化を行い、ルールを策定することで開発に携わる担当者が変わっても、そのルールに沿って開発行うことで保守性の高い高品質なソフトウェアを作ることが実現できるようになります。

    たとえば、プログラマーが10人いるプロジェクトの場合、フレームワークとして共通化できる作業を放置しておいて、10人がそれぞれ1日かけてプログラミングを実施した場合は、10人日の無駄になります。 フレームワークにより、これらを省力化、均一化し、俗人性を排除することができますが、経験の無い開発者がフレームワークの開発を行うと、より複雑化し、工数がかかる場合があります。

    つまり、システム開発を実施するうえで、標準化はコスト、品質、スケジュールを左右すると言っても過言ではありません。
  • 最適化された標準化、フレームワークとは何か?

    一般的にシステム開発における標準の範囲はネーミング・ルーグ、コーディング・ルールなどの基本的なものと「フレームワーク」と呼ばれる開発の土台となる共通基盤のことをさします。フレームワークには、アプリケーションを開発うえで、土台となるパターン、繰り返し利用される処理のモジュール化による再利用の促進、トランザクションなどクリティカルと呼ばれる部分の局所化など開発の標準化をより具体的に実現するために利用されるプログラムの土台です。

    フレームワークには、言語、アプリケーションの種類により、またオープンソースのものからベンダーが独自に開発をしたものさまざまなものが存在しています。オープンソースのフレームワークは、そのまま適用すれば、ビジネスロジックが標準化でき、省力化、品質の向上までが見込めるというものは少なく、そのフレームワーク上でビジネスロジック部分を作りこむ必要があるため、現実はオープンソースベースの上に個々にフレームワークを構築しているのと同じになるケースが多いようです。

    一方でベンダー、メーカーのようなビジネスアプリケーションを中心に開発している開発者が作成したフレームワークは、トランザクション、ログ出力などクリティカルな部分は実装されており、開発者はそれらを再度作りなおす必要はありませんが、フレームワーク自身が強固なルールの塊となり、たった一つの単純な処理を行うために複雑なフレームワークのルールに沿って書かないとならない、あるいはそのフレームワークだとそういうアプリケーションは作れない、ということもあります。
  • いろいろなフレームワーク

    オープンソース・フレームワークの特徴 ベンダー提供のフレームワークの特徴
    • ・プログラム設計上のデザインパターンと呼ばれるものをある程度あつめたもの
    • ・トランザクション処理などクリティカルな部分は独自に実装する必要がある
    • ・単体ではアプリケーション全体をカバーできず、複数のフレームワークを組み合わせる必要がある。
    • ・膨大な種類があり、バージョン互換性も維持されないケースが多い
    • ・ドキュメントが多い
    • ・プロジェクト全体の一プロセスと考えられるので上流工程のドキュメントと深く関連付けられている場合がある (上流工程のドキュメントありきで作成されているため。ドキュメントがないと開発できない、というケースもある)
    • ・ミッションクリティカルな部分は実装済み
    • ・各社の経験、思想に基づき構成され、均一のスキルで開発できるようになっていることが多いが手順が複雑になりすぎ、余分な工数がかかるというケースも多々ある
    • ・ドキュメントはベンダー依存

STSDが考える「良いフレームワーク」

フレームワークはツールであり、それらを適用、開発することが目的ではありません。それを利用することで、無駄を省き、開発生産性、品質を向上できるもの、と考えています。

1.

利用者(開発者)が書くべきことだけに注力ができるように設計されている

2.

利用者(開発者)が作らなくてはならない作業を減らすことができる

3.

分かりやすく簡潔である

4.

利用者(開発者)の視点に立ち設計、作られていること

導入事例 : 「壊滅に進むプロジェクトを救え!」 

  • 社員数約3,400名の企業が運営する国内最大手求人サイトのリニューアルプロジェクト

    代表鴻田がSTSD起業前からサイト立ち上げやサービス企画などで携わっていた国内最大手の人材会社。2007年に競合他社との合併に伴い過去最大のシステム統合プロジェクトが開始。200人を超える開発者、短期間で広範囲のシステム化対象。メインは古くからこの企業を担当していた最大手のSIベンダー。SIベンダーもまた、これまで経験したことのないスピード感、規模の大きさに要件定義の段階で多くの担当者が倒れていくなど、現場は混乱を来たしていた。
  • 静かに近づいていく壊滅への道

    早朝から深夜まで続く連日の打ち合わせ。要件や仕様をまとめる日が過ぎていく中、開発準備も着々と進められていく。そのプロジェクトでは、主力SIベンダーのフレームワークを使って開発を行うことが前提とされており、その使い方のレクチャーをSIベンダーから受けていた開発チームは「大変そうですよ・・・出来るかな」という不安の声を漏らすようになっていた。新しいフレームワークは使い方を理解して習得するだけでもかなりの時間を要する。ただでさえ広範囲・短期間のプロジェクトですでに数多く参加していた開発者の不安の声の中、開発は始まっていく。
  • 進まない開発、疲弊と沈黙、そしてあきらめる開発現場

    弊社の開発チームも含め、どの開発者もまったく作業が進んでいない。私もその主力SIベンダーが提供しているフレームワークを使って作業を開始したが、一向にはかどらない。驚くことにそのフレームワークはエクセルで仕様書のようなものを書きそれをインプットにしてプログラムコードを生成する、というもので、納品物としての仕様書とは別にプログラムを生成するための資料をさらに作る必要があった。さらに、自動生成されたプログラムコードは修正してしまうと正常に動作しなくなり、そのフレームワークがサポートしていない機能は開発できないという制約があり、そのフレームワークが出来ることは制限が多く、ユーザーが望んだものはほぼ実現できない。フレームワークを作った人間の勝手な都合で、ユーザー、開発者の自由が奪われるのだ。すべての開発者が暗い顔でため息をつきながら、やりたい機能が実現できるか検証するためだけのために終電近くまでエクセルをいじる日が続く。プロジェクト自体がそのSIベンダー提供のフレームワークが前提のため、普段慣れている開発方法も使えず、期日までに終わるかそもそも出来るのかも自分たちで言うこともできないまま、みな何かをあきらめ始める。そのSIベンダーの開発メンバーも全員出来る、とは言わず「会社の方針なので」と口を濁していた。
  • 出来ないものは出来ない、そして軌道修正

    プロジェクト全体の進捗報告では開発リーダーが「出来るかわかりません」という話をする中、「今のやり方では間違いなく出来ない。私たちは自分たちが出来る、と言える方法を使う」とし、独自に自社開発のフレームワークを利用することを提案。2日でこのプロジェクト専用に必要な機能を作り上げ、新たに開発に着手。数日後、他の全開発チームが同様にフレームワーク変更の要望を出したため、弊社開発のフレームワークを寄与。200名を超える開発者が一斉に軌道修正し作業を再開した。
  • 苦難を乗り越えてリリース

    短期間・広範囲・関係者の多さからくる調整の難しさなど、多くの苦難を乗り越えてプロジェクトはなんとか無事にサービスリリースを迎えることができた。現在もお客様内のWeb開発標準の基盤として利用されている。