プロジェクトのライフサイクル

前回は IT 業界の成立ちについて説明しましたが、今回は実際にシステムがどのように発生し維持されていくかについて説明します。

システムのライフサイクルは大きく企画、開発、運用に分けられます。システムは企画が始まった時点でプロジェクトが発足されます。プロジェクトとは一般的に、特定の目的のために発足された組織のことを指しますが、システムにおけるプロジェクトではフェーズによって要員が流動的になります。詳細については後述しますが、各フェーズでの大まかな流れについては以下に図を添付しますのでイメージを掴んでください。

各フェーズについて説明します。

企画フェーズ

サービスの企画・検討

企画フェーズでは、まずどのようなサービスを世に提供するか、サービスの企画と検討が入念に行われます。規模や期間はサービスの傾向により異なりますが、共通してマーケティングに基づいて、サービスの根幹であるシステムの目的・売上目標・予算・マイルストーン^[1] … Continue readingなどが検討されます。

ここでは IT の専門家はもちろんのこと、サービスプロバイダの経営陣、規模によってはマーケターや各業種のコンサルタントなども参加し、事業レベルで議論されます。どのようなサービスをどのような属性の顧客を対象に展開するか、どれほどの費用がかかりどれほどの利益が見込まれるかなども入念に検討します。「準備 8割」という言葉がありますが、ここでの検討が甘いと後続のプロジェクト運営を見事に炎上させます。利益が出る見込みがなければ、廃案として別の企画を立ち上げたり、場合によってはプロジェクトを解散させることもあります。

システム要件定義 / 提案依頼（RFP）

企画が承認されるとシステム要件定義に移りますが、ここでは企画したサービスを具体的にどのようにシステムとして構築するかが検討されます。例えば利用するプラットフォーム（クラウド）やミドルウェア（言語、データベースなど）などです。また、ユーザの操作に対し、システムとして望まれる動作（仕様）もここで概ね確定します。これらを要件定義書としてまとめ、承認を受けると次工程に進みます。

要件定義書の完成度は場合によって異なります。それは図にもある通り、システム要件定義後に外注する前提かどうかによります。外注する場合は要件定義書をもとに、幾つかの IT 企業に対し提案依頼（RFP^[2]提案依頼＝RFP（Request For Proposal）：システム要件資料を提示し開発工数の見積を依頼すること）をかけます。この場合の要件定義書は仕様のみを記載している場合もあれば、利用する技術がすでに選定されていることもあります。前者であれば、技術選定は各 IT 企業が検討し、それにかかる期間や予算もあわせて提案することになります。RFP については複雑な工程を踏むことも多いのですが、最近は減少傾向にあるのと、開発工程が請負契約となることが慣習です。僕は請負契約には否定的な立場を取っているので、詳細は割愛します。請負契約の諸問題について興味がある方は過去の記事をご覧ください。

逆に全面的に外注しない場合、システム要件定義が完了するとそのまま開発フェーズに進みます。そのため、システム要件定義の工程では企画より技術者が比重が増えること、この時点で外部の技術者が参画することも覚えておくとよいでしょう。

色々と書きましたが、開発フェーズに入る前にシステム開発に関するインプットは（誰が作るにしても）企画フェーズでほとんど揃うとだけ覚えておいてください。

本項の最後に、繰り返しにはなりますが、開発は始まった段階で勝敗が決まっています^[3]システムの勝敗について：敗北は開発開始の段階で確定するが、勝利についてはどのような技術者が開発に関わるかによる。企画がよくても SE … Continue reading。企画フェーズはプロジェクトにおける最も重要なフェーズと言えるでしょう。

開発フェーズ

開発フェーズ以降の主体は主に開発チームとなります。

開発

企画フェーズでシステム要件が一定まで確定すると、開発、つまり実際に稼働するシステム構築に入ります。プログラミングを行うのもこのフェーズとなります。開発の中にはいろいろと細かい手順があり、そちらのほうが SE に直接関わるのですが、まずはシステム全体を俯瞰して理解することを目的としているため、本記事では詳細を割愛します。

開発では設計・実装・テストを行います。既存のサービスをカスタマイズすることもあればゼロからプログラミングすることもあります。われわれ SE にとっての晴れ舞台、つまりサビです。このようにシステムの立上げとしてプログラミングを行うことをスクラッチと呼びます。

サービス開始

開発で数々のテストを経て一定の品質が担保されていること（バグがないこと）を確認するといよいよサービス開始、つまりユーザが利用可能となります。尚、サービスを開始することをサービスインと呼びますが、スマホアプリが配布開始されることをローンチ（Launch）と呼び、最近ではこちらに寄せる傾向があり、Web システムのサービス開始も同様にローンチと呼ぶ機会が増えています。

運用フェーズ

一度サービスが開始されると、それ以降は運用フェーズに入ります。運用フェーズには大きく、機能追加、改善、保守があります。これまでのフェーズと異なり、これらに決まった順番はなく、適宜順位づけをしながら作業を進めます。尚、保守以外の機能追加、改善については、業界の慣習として使われているので、プロジェクトによっては呼び名が異なる可能性があります。それでも実施する内容に大きな変わりはないので、内容については把握するようにしてください。それではそれぞれの概要を説明します。

機能追加

機能追加はその名の通り、システムに新たな機能を追加します。これまで存在しなかった機能を追加することあれば、既存の機能を拡充（例えば検索機能に新たな検索条件を追加）することも機能追加に含まれます。機能が追加されるきっかけが大きく 2つあります。

• サービス運用チームでは利用者増加の施策が幾つもあり、協議を重ねた結果、最も効果的と認められたもの
• 利用者からの要望として上がり、上記同様サービス向上に効果的と認められたもの

これらについて対応要否を検討し、優先順位がつけられます。そして、次に対応すると決まった要件については、開発フェーズと同様の方法で開発進められます。このようにすでに稼働しているプログラムを修正することをエンハンスと呼びます。これは後述する改善、保守も同様です。

改善

改善はシステムについての課題を解消することです。こちらは大きく以下に分かれます。

• 現在ある機能で使いにくい部分を修正して使いやすくする
• 致命的でない程度のバグを修正する
• システムの振る舞いに変更はないものの、内部のプログラムを最適化する（リファクタリング）

基本的には記載した通りになりますが、幾つか補足します。

ほとんどのシステムでは多くの不具合が内在しています^[4]バグについて：プログラマの格言に「1行書けば … Continue reading。この場合の「致命的でない程度」とは望ましくはないものの、運用に差し障りがない程度の振る舞いのことです。例としては、入力フォームに特殊な値を入力するとエラーが発生する、などです。概ねレアケースのため即時対応はされないことが多く、改善としてチームのタスクに積み残されることになります。また、システムからのレスポンスが極端に遅いなどいった性能改善もこちらに含まれることになります。

尚、リファクタリングとはプログラムをきれいに短くして可視性を上げる（見やすくする）ことですが、プログラムの可視性は開発のスピードと精度に大きな影響を与えます。また、特殊な記法によりプログラムにドキュメントを書いたり、テストコードを導入してプログラムの品質を上げたりすることもここに含まれます。

保守

保守はシステムの健全な稼働を保持することです。具体的には致命的なバグの修正、データベースのメンテナンス、言語やソフトウェアのバージョンアップが含まれます。

機能追加、改善と異なり保守の対応事項は必須です。例えばバグの報告がありそれが致命的なバグだと認定された場合、ほかのすべてのタスクを中断として最優先で対応することになります。「致命的」とは上記とは逆にシステムが運用不可能になるような不具合ですので、早急な対応が望まれます、当然ですね。

バグの修正はピンとくると思いますが、ほかの 2点については少し分かりづらいかもしれません。データベースのメンテナンスは、例えば市区町村の統合によりデータベースに変更が発生した場合に対応したり、デーアを追加したいがシステムから投入する画面がないような場合 SE が直接データベースを操作することになります。

最後に言語やソフトウェアのバージョンアップですが、利用している言語やソフトウェアのバージョンのサポートが終了される場合、セキュリティに大きな欠陥を抱えることになるため、バージョンアップが実質的に必須となります。モダンな言語では年に一回メジャーバージョンアップが発生するため、少なくとも 2〜3年に一度はバージョンアップが必要になります。

補足ですが、システムの言語や OS を更改（＝一新）することをリプレースと言いますが、これはほとんど場合、要件の見直しが発生するため、広義の新規プロジェクトと判断できます。また、規模も膨張しやすく、保守費用と別の予算として扱われるため、保守には含んで考えません。

各フェーズの重要性について

以上がシステムのライフサイクルになります。まず、サービスの企画検討がなされ、事業として妥当と判断されたら開発してサービス開始となります。それ以降はサービス終了となるまで運用され続けます。

システムにおいて最も長いフェーズは運用フェーズです。その長さはほかとは比較になりません。昨今のシステムでは、企画からサービスインまでの期間を極力短縮し、素早くサービスを開始してユーザのフィードバックを受けて修正を重ねるという、スモールスタートが増加傾向にあります。但し、各フェーズの重要性は期間の長さと比例しません。整理すると以下のようになります。

• 期間の長さ：
  • 企画フェーズ ＜ 開発フェーズ ＜ 運用フェーズ
• 重要性：
  • 企画フェーズ ＞ 開発フェーズ ＞ 運用フェーズ

誤解のないようにしたいのですが、前提として、すべてのフェーズは重要で、どれも欠けてはならないということです。

これを踏まえたうえで、重要度についてお話しますが、やはりシステム開発の成功度は企画で決まります。サービスの内容は言うなればシステムの心臓です。サービスの内容いかんにより利益を生むかどうかが決まります。そして継続的に利益を生むことができれば、その分開発に予算をかけ、よりよいシステムを構築可能となるのです。

その次に重要なのは初回の開発です。なぜなら、初回の開発フェーズで決まる様々な取り決めによって、その後の運用フェーズの作業効率に重大な影響が出るためです。初回の開発で、取り敢えずは動くものの、プログラムが非常に読みづらかったり、ドキュメントを書く習慣がなかったり、レビューをする習慣がなかったりと、穴だらけの開発手順を踏んでいると、運用フェーズでの開発を非常に困難なものにします。読みづらいコードや仕様の不透明性はそれだけでも充分な運用のお邪魔虫としてシステムの寿命が尽きるまで付きまとうことになります。

---

物事は何につけ実践が重要であることが自明ですが、ことシステム開発については「準備 8割」が重要です。言い方が少し悪いですが、素人が感覚で作り上げたシステムでは保守性という意味で大きな欠陥を含むことになります。そして、運用フェーズが最も長い以上、運用に備え、システム開発時点で保守性を強く意識しておくことが重要です。

上記の通り、近年サービスインまでの期間は短くなる傾向にあるため、尚のこと、せめて初回の開発だけは精鋭で取り組むべきでしょう。

開発の細かい工程については別記します。