はじめに
私は仕事でシステム企画・開発をしています。感覚的には社内SEに近いような立ち位置です。
これからシステム開発の仕事に携わりたいと思っている方に向けて、
どのような流れでシステムが開発されるのか、紹介していきます。
記事内容としては、「一般企業がシステム導入をする流れ」の方が正しいのかもしれませんが、
「システム開発の流れ」というタイトルの方が響きがいいかな〜と思い、
タイトルを選びました。笑
説明していくにあたり、開発手法は色々とありますが、ここでは
ウォーターフォールモデルに沿って説明していきます。
システム開発をしていく上でのやりがい、大変なことを是非とも知っていただきたい。
ウォーターフォールモデルとは
ウォーターフォールモデルとはシステム開発手法の一つであり、
開発手法としては最も古くからあるモデルです。
設計、開発など各工程を順番に進めていく上で、
工程ごとに評価を行い、次の工程に進んでいくという開発手法です。
各工程は以下の通りです。
工程１. 要件定義
工程２. 設計
工程３. 製造・開発（プログラミング）
工程４. テスト
工程５. 運用・保守
詳しく説明し出すと、設計工程には外部設計、内部設計があったり、
テスト工程には単体テスト、結合テストがあったりとややこしいので、
深掘りしての説明は、また、別記事にてアップします。
各工程ごとに課題を管理していき、工程終了後には、課題が解決されているか、
また、課題が残っている場合、次工程に持ち越せる課題である理由を明確にし、
工程毎に完了判定会議を行います。
工程ごとにちゃんと課題が出せているかという分析、評価をしたりもします。
もちろん、課題が多ければ多いほどいい。なんてことはないですが。
とにかく、ウォーターフォールモデルで大事なことは
自工程完結！
次の工程に進むにあたり、前の工程でやるべきことを残さない！というのが鉄則です。
例えば、設計工程で「あ、やっぱりこのシステムでこういう仕組みも作っておきたかったわ！」
というように要件定義が不十分だと、手戻りが発生して、
プロジェクトの納期に大きく影響してきます。
とにかく上司には「自工程完結だからな！」と耳にタコができるくらい言われます。
（アンタ「自工程完結」って言いたいだけやん）というのは心にしまいながら、
ちゃんとサラリーマンやります。
要件定義
要件定義の工程では、開発・導入するシステムにおいて、ユーザーにどのような困りごとがあるのか、どのような機能が欲しいのかを詳細にヒアリングしていきます。
要件定義の工程は個人的に2番目に重要な工程であると思っています。
かなり難しい。。。けど、私が1番好きな工程です。
今まで手でやっていた業務が自動化されて、残業がなくなる！とか
理想を語るユーザーの目はキラキラしているんですね。
あの顔はたまらんすね。
（画像の目のキラキラはちょっと盛っちゃった。）
ただ、手戻りが発生する原因はおおよそ、要件定義にあってもいいと言っても過言ではないくらい、重要な工程です。
何が難しいかというと、
まず、ユーザーはシステムの完成図を求めたがります。
既製システムの導入であれば、デモなどを行い、イメージを持ってもらうことができますが、
新規開発システムであれば、要件定義の初期の初期は完成図なんてありません。
完成図がない上で要件を絞り切るというのは非常に難しいです。
ユーザーからは「完成図がないのに要件なんて出せませ〜ん。」
とか言わせないように要件を吐き出させていきます。
ここが社内SEの腕の見せ所です。
システムの製造が終わって、実際にユーザーにテストで触ってもらう頃に、
「あ、これならこういう機能も欲しい」とか「こんなはずじゃなかった」
とか出てきたりするんですね〜〜。
そしたら、手戻りでまた要件定義からやり直しなんてこともありますから。
そうならないように、要件定義の工程ではユーザーの要件を全て出し切ります。
プロジェクトを開始する前に
いざシステム要件が固まり、プロジェクトを開始するにあたって、
やらなければならないことがあります。
予算確保
新規開発システムで、設計、製造（プログラミング）、
テストは請負契約で業者に発注するとします。
会社ごとで違いはあると思いますが、私の会社では要件定義が終わり次第、
システム仕様書を書き始めます。
ここからが社内SEは大変。納期を守るために鬼残業。
仕様書にはこういうシステムを作るから、
このようにプログラミングしないさい。とか。
どこまで業者に発注するかにもよりますが、
システムを作るにあたり、具体的な説明を書きます。
業者は仕様書に書いてある通りに、製造するので、仕様書の書き方が甘いと
思ったものと全然違うシステムが出来上がったりします。笑
慎重に慎重に書き漏れがないよう、仕様書を書き上げます。
初版として出来上がったものを上司にレビューしてもらいます。
そして、ボコボコにされます。（物理的な意味ではない）
仕様書を書き直しますが、これは上司の愛だと受け止めて、踏ん張ります。
（思考は完璧に社畜である）
仕様書が出来上がってから、新しいシステムを開発・導入をするにあたって
全体でどのくらいコストがかかるかを計算します。
コストを計算したら、会社からそのお金を出してもらうために、
経営会議を開き、会社のお偉い様方にお伺いを立てます。
ちなみに会議室はドラマに出てくるような厳格な雰囲気で、
めちゃくちゃ緊張します。
経営会議では次のような説明をします。
- 開発・導入するシステムの説明
- 開発・導入スケジュール
- 費用対効果
- プロジェクト体制を説明（人員確保依頼）
ざっくりですが、上記の4点を説明します。
特に重要視されるのが「費用対効果」です。
費用対効果とは書いて字のごとく、システムを開発・導入することで、
どれだけの収益が見込めるか。ということですが、
当然、収益が見込めないシステムに投資してくれるほど甘くはありません。
これもまた算出するのが大変です。単純にお金を産むシステムであれば、まだ計算は簡単ですが、
業務効率化のためのシステムであったりすると、
システムを開発・導入することにより、
どれだけの工数が削減できるか見積もり、平均給与を掛け算して、
どれくらいの費用削減ができるかというのを提唱します。
文字で説明するだけだと簡単に聞こえますが、
いざやってみると案外難しいです。
お偉い様方よりGOサインが出れば、いざプロジェクトの始まりです。
業者選定
プロジェクトが始まれば、全て内製でシステムを開発するものでなければ、
業者に発注することになります。
そこで、業者を選定していく訳ですが、大きなプロジェクトとなると、
複数の企業に声をかけて、競争させます。
競争させる目的としては、
- パートナーとして、仕事を任せられるかの見極め
- コスト削減
これからプロジェクトを一緒に進めていく仲間として、雑な仕事をしないか、
信頼できるか等を見極めるのも重要なポイントですが、
複数企業に競争をさせると、コストが下がります。
なぜ、コストが下がるのか。
競争している他の企業よりも安く導入できるというのは、
やはり強みなので、企業はギリギリの価格を攻めてきます。
もちろん、競争している企業はうちの予算なんて知りません。
企業が出してきた見積もりが予算を超えている場合、
余程優れている提案をしない限りは一発アウトです。
競争する企業には、その旨も伝える、かつ予算を知らないので、
価格で攻めていかないと選んでもらえない。と刷り込ませることで、
自然に価格が安くなります。
うちの会社はそれなりにネームバリューがある会社なので、
赤字になってでも仕事をとりにくる企業も少なくありません。
たまに、そんなに安くして大丈夫なの？という価格を提案してくる企業も
ありますが、そういう企業はシステム開発後の保守費、
維持費等で採算をあわせにくるようなケースばかりなので、
注意して選定をしていきます。
大規模プロジェクトの業者選定については、もっと語りたいことがありますが、
今回は業者選定の説明をするのが目的ではないので、別記事にて。
価格点とか技術点とかVE提案とか色々な評価・採点をして
業者を選定するのですが、それがまた楽しいんですよ。
システム設計
前章でも前置きした通り、設計も業者に発注するものとします。
業者に任せているとはいえ、ここの工程でもまだ定時では帰れませんです。
本工程では、ひたすら２つの作業を行なっていきます。
- 業者が作成した設計書のレビュー
- 業者からのQA対応
設計レビューでは業者が作成した設計書の読み合わせをし、
疑問点や認識の齟齬、記載ミスがあればどんどん指摘していきます。
ずっとオレのターン。
指摘→設計修正→再レビュー→指摘→設計修正→再レビュー・・・・・・
設計書はシステムの機能ごとであったり、システムの画面ごとであったり、
データベース設計であったり、インターフェース設計であったり、
サーバ設計であったり、プログラム設計であったり・・・・・
一つ一つの設計書ごとにレビューをしていきます。
正直、嫌になります！笑
途中で「もう、それでいいや。」と妥協したくなることもしばしば。
ただ・・・・
理論上、システム仕様書が完璧に書けていれば、全ての仕様が網羅できていて、
業者が正しく、理解し設計書に落とし込むことができているならば、
何度も指摘して、何度も再レビューなんてあり得ないんです。。。
設計工程が延びてしまうと、上司から「お前が書いた仕様書が甘かったんじゃないか」
と言われてしまいます。
それだけ、システム仕様書は大事なものなのです。
製造・開発（プログラミング）
ここでの工程は設計工程までを終わらせて、
実際にシステムを作っていく工程です。
製造・開発（プログラミング）も業者に発注しているという前提で説明します。
（記事での説明を減らし、楽をしようとしているッ！？）
さあ、ようやく私が楽になる期間がきました！
設計を終えて、製造・開発は業者に任せっきりなので、出来上がるのを待ちます。
定時ラ〜〜ッシュ！
毎日、定時になるのが待ち遠しくなります。
とはいえ、プロジェクトも複数抱えていれば、ここでの余った時間で
企画書、仕様書を書いたりしてます。
また、次のテスト工程に備え、テスト仕様書を準備します。
テスト
個人的にテスト工程はシステム開発・導入の中で一番重要な工程だと思っています。
テストが不十分だと運用フェーズに入ってからバグが発見され、
システムを一時的にとめて、修理しなければならないことがあります。
システムをとめるというのは、業務の中断にも繋がります。
業務をとめるということは何としても避けなければならないので、
私はテスト工程を一番大事にします。
徹底的にシステムをいじめていきます。
システムに対しては、ドSです。システムに対しては。
ざっくり説明すると以下の観点でテストを実施します。
- 正常性確認
- エラーチェック
- 性能評価
大規模プロジェクトとなるとテスト項目が1000を超えることもザラです。
正常性確認
文字通り、システムが正常に動作するかを確認します。
大抵、システムを利用して行う業務を何サイクルか回しますが、
正常性確認で大事であることはイレギュラーケースをいかに想定して、
テスト工程に含められるかです。
通常業務を行えるシステムを開発は当たり前。
変則業務に耐えうるシステムを目指します。
エラーチェック
エラーチェックではわざと、システムエラーとなるような
オペレーション、データ投入を行います。
システムエラーとなった結果、正しくエラー画面が表示されるか、
また、エラー画面を一見し、ユーザーがそのエラーに対して、
適切な処理ができるかどうか、処理フローを確認します。
良いシステムというのは、ユーザーが直感的にシステムオペレーションする
ことができるシステムです。
そのためには、エラーが発生した際に、いちいちSE作業が発生したり
ということがないよう、チェックをしていきます。
想定しうるエラーを全てテストしていきます。
性能評価
性能評価では各処理ごとにどのくらい時間がかかるか測定します。
基本的には正常性確認、エラーチェックと同時に行います。
シミュレータを使って同じ処理を１００回、まわしてみたりします。
例えば、WEBシステムの場合、ページを開くのにユーザーが
明らかに遅いと感じられるページに対しては、データベースからの
データ抽出方法を見直したり、表などの出力
（グリッド表示と呼んだりしますが）方法を変えたり、
ユーザーがストレスフリーになるように修正していきます。
運用を始める前に
テストも合格し、晴れて運用開始！
といきたいところですが、私の会社ではシステムを運用開始する前に
稼働判定会議をおこない、運用を開始して良いかどうか、
システムを利用するユーザー、お偉い様方に判断を仰ぎます。
システムを開発・導入する目的をおさらいし、
ユーザー要件がシステムに組み込めている、テストも合格していること、
プロジェクトとして活動してきたことを集大成としてぶつけます。
余程のことがないかぎり、稼働判定でバツを食らうことはなく、
正直、形式的なものです。
ただ、うちの会社では通例のイベントで、判定会議を行うということは
プロジェクトの佳境を超えて、終盤であるということを自覚できる場であり、
区切りのつくイベントであるため、妥協せずに資料も作ります。
運用・保守
ようやくシステム運用開始です！
画像のようにテープカットまではしませんが、笑
運用開始できることは本当に嬉しく、感慨深いです。
すぐに打ち上げの準備をします。
すぐに！打ち上げの！準備を！します！
打ち上げ当日は、プロジェクトの苦労した話とかで盛り上がります。
とにかく盛り上がります。
開発したシステムの名前は開発者である私が名付けたりしますが、
名前を付けたシステムが仕事の会話の中で登場するのを聞いたりすると、
ちょっと恥ずかしい反面、めちゃくちゃ嬉しいです。
「業務量が減った」とか「使いやすい」とかいう声を聞くと、
この仕事をやってて良かったと実感します。
本当の戦いは稼働後の保守であることは触れずに・・・・
おわりに
システム開発の流れを説明しました。
会社ごとにルールや進め方に違いがあるかもしれませんが、
おおよその流れは変わりはないと思います。
これから、システム開発・企画の仕事に携わる方へ、
この仕事は辛い反面、達成感をものすごく感じられる仕事であり、
やりがいを感じられる仕事です。
実際に携わっている私もオススメしたい仕事であることは間違い無いです。
