シェアリングスのコラム
要件定義という虚構
日経コンピュータに「要件定義技術」某大手SIベンダーが取り組みを行っており、
この記事に対して、
まず、ウォーターフォール開発の場合、
システム発注の段階で顧客は発注するシステムに関する要件が
はっ
システム屋の仕事は、それを聞き出し、書きならべることで、
不可能です。
不可能以前に、前提条件が破たんしています。
「システムに関する要件がはっきりしていること」
なんていう前提は、
「
それどころか、
「
あり得ないことだと断言できます。
ちなみに、要件の存在有無については、
大切なことは、
「システム開発時点では、
数学界では、虚数の導入に際して激しい議論があったと聞きます。
その存在を素直に受け入れることが難しかったことは想像できます
しかし、虚数を使ったほうが、
また、量子論についても同様に、
余談が長くなりましたが、この場合も、
「
と確定してしまったほうが、
存在しない物に対して、「専門家」
うまくいくはずがないと思います。
要件は、常に変化し、追加されます。これは、
どんなに否定しようとも、クラアントを馬鹿にしようとも、
どんなプロジェクトでも
当初決まっている要件ですが、筆者の経験を元にざっくり言うと、
世のシステム開発会社は、その3～4割を100%
これでシステム開発がうまくいくわけがないですよね？
要件だけでも、2～3倍に膨らむわけです。開発中に。
それ以前に、当初の要件分を開発するだけでも、
システム屋さんの苦悩が目に浮かびます。
そんな惨憺たる状況の中ですので、
開発要件が変わることは絶対に避けたいと思うのは当然のことだと
でも、それが一番の罠なのです。
無いものねだりです。
前提条件が間違っているのです。
ありもしない要件を確定するために心血を注ぐぐらいなら、
「変化する要件に対して、
そして、この方法は必ず成果が表れます。
効率的なプログラミングツール、言語、データベースを使い、
スモールスタートで徐々に拡張していくような開発手法をどんどん
注意してほしいのは、
「要件ありき」で進めたのでは、
「要件が確定していない」ところからスタートして、
失敗しないシステム開発のコツは、この一点です。
簡単なことです。
拍子抜けするほど単純なことが、
さらに余談
システム開発に「要件が存在しない」ことを実感する、
それは、自分のために、
自分自身がクライアントなんだから、「要件を聞き出す」
ハンディ0です。
「要件定義が存在するが聞き出せないだけ」が事実なら、
100%
が、
うまくいきません。
うまくいかないのです。自分自身がお客様なのに。
なぜ？
開発前に、要件が存在しないからです。
またまた経験則ですが、
当初予定していた機能の3倍ぐらい作りこまないと、
本当に使いやすいシステムとするためには、さらに3倍。
これが現実なのです。
なぜRuby On Railsなのか？
弊社が開発に主に利用する言語は「Ruby On Rails」。では何故シェアリングスの開発チームはRubyを選んだのか？それについてご説明します。Ruby On Rails で開発するメリット
- 開発スピード向上
- 変更の容易性
- 開発工数の削減
- 開発標準化
- 品質確保
開発の側面から見た、最大のメリットは、開発スピードの向上です。
「とにかく動くものを」作るスピードは(Java, C++, PHP, Perlなど)他を圧倒します。これによるビジネス・メリットは、とにかくニーズにマッチしたシステムを供給できるようになることです。
今、我が国で一般的に行われている開発スキームは、ウォータフォールモデルと呼ばれるものです。これは、要件定義から、製造、テストという風に段階を進み、最初のデリバリーまでにすべての要件を固定していくという思想に基づいたシステム開発手法です。この方法の問題点は、お客様が最初にシステムに触れるまでどのようなシステムが出来上がるのか全く見えてこないということです。
要件に現れないようなシステムの動きや暗黙知としてのビジネス要件は、お互いに十分に理解することが難しく「出来上がったシステムがビジネスニーズにマッチしない」という結果となって表面化します。しかも、要件を変更するには多大なコストを伴うため、気づいた時には「手遅れ」だったということも少なくありません。その場合、多大なコストを払って修正していくか「使えないシステム」と諦めてごまかしながら使っていくしかありません。
この問題に対する打開策は、1秒でも早く「実際に動く形で」システムをデリバリーすること以外にありません。良いシステムを作るには、スケジュールや予算に余裕があるプロジェクトの初期の段階から実際に動くシステムを情報伝達のツールとすることが必要です。動くシステムを見ながら認識を合わせることは、ビジネスニーズに即した「使えるシステム」の構築の足掛かりとなります。
このことを信条に最も適した開発ツールとして、Ruby on Rails(以下Rails)をお勧めしているのです。
Ruby言語には、『複雑な機能を非常に少ないコード量で柔軟に記述することができる。』という特徴があります。ビジネスの変化やシステム習熟に伴う要望の変化に柔軟に素早く、低コストで対応することができます。導入費用だけでなく、その後のメンテナンスコストも低く抑えることができるのです。
とはいえ、システムの増改築に伴い複雑さが増加することは避けられないことです。しかし、同じ複雑さを持つのであれば他の言語より柔軟簡潔に記述することができる、Ruby言語の特徴が大きな武器になります。つまり、Railsで構築されたプロジェクトは、他のシステムで作られたプロジェクトよりも多くの増改築に耐えうるということです。Ruby言語上に構築された、Railsというフレームワークは、非常に規約の多い開発環境といえます。この「規約が多い」という特徴は業務システムを構築する上では大きなメリットとなります。なぜなら、規約に従うことで標準化が促されコードの統一性が保たれることになるからです。開発者は必然的に規約に従ったコードを書きますので、無法者コードが氾濫することを抑止します。このことは新たにRailsを学習する者にとっても大きなメリットとなります。簡単なルールさえ覚えてしまえば、システムの全体を"規約に従って"理解することができるようになるのです。
加えて私たちは、Railsの強固なフレームワークの上に独自のノウハウを結集した「業務システム開発用」の開発スキームを構築しました。いわば、『業務用Ruby on Rails』ともいうべきもので、DB設計からコードの実装、テストまで、業務開発で特に必要となる機能について、あらかじめ用意された規範に従って、より素早く開発することができます。このフレームワークを活用することで、Railsの特徴である、素早さ、柔軟さ、堅牢さをさらに進化させることに成功しました。
Ruby On Rails で開発するデメリット
- 実績
- メンテナンスコスト
- パフォーマンス
- スケーラビリティ
Railsを利用するにあたって、不安となる要素もあります。
まず、まっさきに思うのが「稼働実績」ですが、このことについては問題ないレベルまで来ていると思います。海外を含めて既に非常に多くの稼働実績があり、そのうちいくつかは非常に大規模なシステムに適用されています。また、私たちも既にいくつかのプロジェクトでの利用実績があり、システムの安定稼働についてはノウハウを有します。
Rubyに関しては、開発要員の確保が難しいといった声も聞きます。特に保守要員の確保が難しく、リリース後のメンテナンスを不安に感じるというのも事実だと思います。しかし、上記に述べたとおりRailsでのシステム稼働実績も増加しており、学習曲線も急峻であることから、今後確実に要員数は増えていくと思われます。特にPHP、PerlなどWeb開発経験を有する技術者であれば、スムーズに移行することができるでしょう。
Rails単体としても常にパフォーマンスチューンが行われています。現在最新版となる2.1.0では、十分高速なフレームワークとなりました。また私たちは、これまでの開発実績によってRailsを使ったシステムでのパフォーマンスを確保するためのノウハウを有しています。過去の実績から、システムの設計を正しく行えばストレスなく軽快に動作するシステムを構築できることが分かっています。
スケーラビリティの問題についても、大きな不安材料とは言えません。Railsで構築されたシステムは、アプリケーションサーバを複数台に増やすことが容易であるため、システム要件にしたがって、柔軟にスケールアップしていくことが可能です。超高負荷環境やバッチ処理での稼働となると、他の手段(Java やC++など)と比べて見劣りするかもしれませんが、通常利用する範囲でシステムパフォーマンスが不足することはありません。
これらのことからシェアリングスではRuby On Railsを採用し多くのお客様に喜んで頂いております。
