ウォーターフォールモデルとは
ウォーターフォールモデルとは、名前の通り水が流れるように開発工程を上流から下流へと一方通行で行う方法です。段階を区切って進めていくため分かりやすいのですが、後戻りはできません。
ウォーターフォールモデルの工程
要件定義
要件定義とは、これからどんなシステムを開発するのか？という要件を定義する段階です。システム利用者や関係者とのヒアリングを重ね、開発の目的や期待される効果をまとめます。お客様が抱える問題やニーズ、業務フローを理解する為に重要なステップです。他にも機能要件・非機能要件の洗い出しを行います。お客様にヒアリングを行った上で、システム開発者側が提示してお客様に了承をいただくという流れになります。お客様からGOサインをいただけたら、設計に移ります。
機能要件
システムが提供するべき機能や操作性、処理速度などの要件を指します。
非機能要件
セキュリティ、パフォーマンス、拡張性、互換性などの機能要件に含まれないが、実現するべき要件を指します。
設計
設計には基本設計と詳細設計があります。
基本設計（外部設計)
要件定義で決めた要件を達成する為に必要なシステムの機能や性能、制約条件を明確にします。例えば、画面のレイアウトや操作手順、各機能の処理フロー、データの保管方法、出力方法などがあります。これらを機能ごとにまとめた基本設計書を作っていきます。
詳細設計（内部設計)
基本設計書が出来上がったら、それを元に機能をモジュールごとに分割した詳細設計書を作っていきます。詳細設計は、機能をプログラムによって実装するためのエンジニア向けの手引き書という役割です。詳細設計はクラス図・アクティビティ図・モジュール構成・シーケンス図などさまざまな表し方があり、設計が終わったらいよいよ開発段階に進みます。
開発プログラミング
実際にシステムを作っていきます。プログラミング言語を使用したソフトウェア開発、ソフトウェアを動作させる為のサーバー構築などを行います。システムインテグレーターの中には開発段階を下請け等に出すこともあります。
テスト
テストには主に4種類のテストがあります。
製造・単体テスト
システムが要件定義通りに動いているかを確認します。まずはモジュールごとにテストを行います。不具合が発見されたら都度修正をしていきます。
結合テスト
モジュールごとのテストに合格したら、次はモジュールとモジュールを繋ぐサブシステムのテストを行います。
総合テスト(システムテスト)
サブシステムのテストに問題がなかったら、システム全体のテストを行います。
運用テスト
最後に、実際の運用に沿ってシステムが正常に動くか、期待通りの操作性があるか等をテストします。必要に応じてお客様(実際のユーザー)にシステムを使っていただき、確認をいただきます。
リリース
システムに問題がなければ、納品となります。既存のシステムがある場合は、システムの移行作業を行います。
運用・保守
システムが問題なく動作するように、また、不測のトラブルに見舞われることがないよう運用・保守を行います。開発会社によってはこの運用・保守の部分を外注したり、社内の保守専門チームに担当替えをしたりすることがあります。
シースリーインデックスは、
開発に関わるすべての工程を自社で行っています
実は、一気通貫で要件定義からアフターフォローまで行うSIerというのは、決して多いとは言えません。 さらに当社の場合は、保守の担当にはそのまま開発担当者が就く、という大きな特徴があります。開発時の経験を有したエンジニアがそのまま担当した方が不具合に対応しやすい上に、お客さまとしてもコミュニケーションが取りやすいと好評いただいております。小規模な会社だからこそ叶うきめ細やかなサービスで、開発の前も後も、お客様に安心してご利用いただいております。
ウォーターフォールモデルのメリットとデメリット
メリット
進捗管理がしやすく安定した開発が実現します
ウォーターフォールモデルでは段階的に工程を進めていくため、明確なマイルストーンを置くことができ、何がどこまで進んでいるかという進捗管理がしやすいというメリットがあります。また、一つの工程を完結させてから次へと進むため安定した開発が実現します。また、段階ごとの境界が明白なため、プログラミングやコーディングなど開発段階を下請け企業に任せるといった体勢を取りやすいという特徴もあります。
デメリット
後戻りができない点に注意
ウォーターフォールモデルの1番のデメリットは前工程への後戻りができないという点です。工程ごとに確定をさせてから次に進むため、変更が必要になった場合は修正に大幅なコストと時間を費やすことになることがあります。要件定義や設計段階が甘く、開発の時点になってから問題が発覚した…といった失敗もよくあるため、進め方には注意が必要です。また、下請けを使っているケースでは前工程のしわ寄せが後工程に及ぶことになり、短い開発期間で無理難題を押し付けられるといったことも問題になっています。開発が順調に進まないと、納期遅れが発生します。
このようにウォーターフォールモデルには、
メリットだけでなくデメリットもあることを認識しておくことが大切です。
アジャイル開発とは
アジャイル開発とは、ウォーターフォールモデルの欠点をカバーするために登場した開発手法です。機能やモジュールなど小さな単位で迅速に開発とテスト、修正作業を繰り返すのが特徴です。2～4週間程度で開発→テスト→修正という工程を繰り返すため、スピーディーで柔軟な開発が可能です。
ウォーターフォールモデルのメリットとデメリット
メリット
スピーディーかつ柔軟に開発が可能
アジャイル開発のメリットは、迅速に柔軟な開発ができることです。アジャイルで開発をする場合は、途中で要件が変わった場合でも、お客様とコミュニケーションを取りながら柔軟に試行錯誤することができます。小規模な開発をスピーディーに行う際にお勧めの手法です。短い期間で開発が終わるため、開発コストも低く抑えることができます。
デメリット
安定した開発が困難になることがある
前工程を固定化しないため、開発の質が不安定になることがあります。また、要件定義書や設計書といった書面も使わないために開発の方向性がブレやすく、書面が残らないことで運用や保守がやりにくくなることがあります。
小さな開発をスピーディーに行う際にはメリットがあるアジャイル開発ですが、
大きなプロジェクトには不向きだと言えます。
適切な開発手法を選ぶには？
ウォーターフォールモデルとアジャイルモデルにはどちらもメリットとデメリットがあるため、開発の規模や条件、要件などによって適切な手法を選ぶ必要があります。また、ウォーターフォールモデルの流れの中で、一部アジャイルのプラクティスも用いて開発をすることで、双方のメリットを得ようとすることもあります。システムインテグレーターは、各々の企業の方針や開発チームの方針により、都度最適な開発手法を選択して、開発を行っています。
シースリーが常にコンダクター（指揮者）である理由
システム開発は、その性質から時には複雑な下請け構造になったり細分化された分業体制になることがあります。たとえば、この部分はA社が開発、この部分はB社が開発、テストはC社が行うなど…。ですが、シースリーインデックスでは、常に自社がコンダクター（指揮者）という立場でしか開発を行いません。それには以下のような理由があります。
責任の所存を
明らかにしたいから
開発するシステムは１つなのに、開発の工程を単なる作業として切り離すとリスクが生じます。なぜなら開発に関わる社数（人数)が増えれば増えるほど、ミスや不具合が生じた時の責任の所在が曖昧になるからです。コンダクターなら全体を見通しながら指揮を執ることができるので安心です。
開発の質を高めるために
コミュニケーションが重要だから
たくさんの人（企業)が介在すると伝言ゲームのようになり、お客様の意思がシステム開発に正しく反映されにくくなる恐れがあります。お客様のご希望通りのシステム開発が実現できなければ意味がありません。そこでシースリーインデックスでは当社がお客様との窓口となり、すべての工程の指揮命令を行います。
スムーズに開発を進めるために
必要だから
きちんと管理を行わず下請け任せにすると、開発が途中で止まったり、開発に遅れが生じることがあります。スケジュール通りシステムがリリースできなかったり、追加費用が発生するのはお客様にとって損でしかありません。開発の全行程を把握している当社が主管を務めれば、綿密な工程管理が可能です。
当社ではすべての開発案件の指揮命令を自社で執っております。
開発の責任を最後まで持つため、大規模なプロジェクト案件に関しても安心してお任せいただけます。
よくある下請けのケース
よくあるケース
たとえば工程の中の開発はA社、テストはB社、保守運用はC社と下請け契約を結び、設計以降は自社では一切関与しないなど、自社で引き受けた案件を手放してしまう企業も存在します。下請けを利用する主な目的は、開発コストの削減と手間の解消。また、自社開発ができないから委託するということもあります。
シースリーインデックスの開発
当社の場合、一気通貫でシステム開発を実現するスキルがあるため、基本的にはすべて自社で完結します。お客様の希望される開発を実現する上で必要だと判断した場合に限り、最適なベンダーに委託することがありますが、開発の指揮・命令や管理は一貫して当社が行うため、責任の所在が明白で情報の伝達ミスなども起きません。
当社では必ずすべての工程を一気通貫で請け負うことで質の高いシステム開発を
実現し、お客さまの課題を解決していきます。
シースリーインデックスが考える「良い開発」の条件とは
お客様ファースト
お客様の「こんなシステムが欲しい」という思いに寄り添い、親身にヒアリングを行いながら最適な提案をすることが大切です。このシステムを売りたい、というシステムインテグレーター側の自分本位な提案ではなく、お客様の立場に立った開発を行う姿勢が求められます。
課題を解決するためのシステム
お客様がシステムを通じてビジネス課題を解決できるようにするために開発を行うことも大切です。開発の本来の目的を失わず、既存システムの良いところは継承し、課題だと感じているところは改善する提案をすることで、システムの導入やリニューアルを企業成長のきっかけにしていただけるように、開発を行います。
最初から最後まで責任を持つ
当社は要件定義から設計、開発、テスト、導入、そして運用保守の段階まで、すべて自社で責任を持ちます。当社の役割はコンダクター（指揮者）です。お客様と足並みを揃えて、一緒になって開発を行い、目指すゴールに向かっていきます。運用・保守についても開発担当者がそのまま担当させていただくことで、お客様には安心してシステムを使い続けていただけるようにしています。
