どうもタスです。
以前の記事に書きましたが、僕は社内SEをしており、業務システムをトータル管理する部署にいます。
そこで今回は、システム開発とはなんぞやということと、システム開発の流れについてお話ししたいと思います。
この記事の目次
システム開発とは？
この冒頭に書かれていることが「まさに！」という感じなのですが、僕が考えるシステム開発とは「業務そのものをシステムに乗せること」です。
これを見てピンと来た人もいるかと思いますが、そうなんです、システム開発はシステム屋さんだけでは行えないのです。
なぜかというと、システム屋さんは業務が分からないですからね。
会社ごと、部署ごと、引いては人ごとに業務が違うことがありますから。
また、システム化することと並行して、業務を見直すこともシステム開発の作業に含まれます。
業務をシステムに乗せる過程で、業務の冗長化や無駄な作業の廃止、さらには効率化した新しい業務なんかも取り入れることができれば、システム化することの価値はもっと高まりますよね。
特に、以下が成功すればパフォーマンスの良いシステム開発といえるのではないでしょうか。
- 業務に対するリソース（人員や時間）の削減
- 業務自体の見直しによる効率改善
- 1.と2.が成功することで可能になる新規業務の追加
なので、システム開発とはPCをポチポチすることが全てではないのです。
利用者と話し合い、どういうシステムにしようか、どうしたら業務がもっと円滑に回るか、システムを利用することを想定して業務をもっと効率化できないか。を考えていくのです。
コンピューターとは離れたところで行われる作業って思っている以上に多いですよ。
システム開発の流れ
システム開発はザっと以下のような流れになります。
★基本設計 → 要件定義 → 外部設計 → 内部設計 → プログラミング → 開発テスト → 運用テスト → リリース★
ってな流れですね。
それぞれのフェーズを簡単に説明したいと思います。
基本設計
これはシステムの目的を決めるフェーズです。
- 何のためのシステム？
- システムを作る目的はなに？
- 利用者とシステムの関係は？
- いつまでに完成させるの？
などなど、システムの目的を掘り下げ、システムの根幹を決めるフェーズです。
ここがブレると後続の作業に進めないですし、システム完成以降も運用するうえでもとても大事な内容になるので、利用者とよくよく話し合います。
後は納期や開発体制などの内容も決めます。
要件定義
字のごとく、要件（システムに必要な内容）を定義するフェーズです。
具体的には、決まった目的に対して、それを達成するために必要な業務を明確化することです。システムに乗せる前に、乗せるものを理解しないとならないですからね。
このフェーズも利用者さんとよくよく話し合い、現状の業務を根掘り葉掘り聞きだします。
聞き出した後、それをまとめる過程で、業務の効率化や無駄な作業などが見えてくるかもしれません。
それについても、今後はどうするか検討し、利用者さんに「今後もその業務を続けるか」決めてもらいます。
※決して、システム屋さんが決めることではなく、利用者さんに決めてもらいます。
この作業で、システムに乗せる必要がある業務とその詳細をまとめることが可能になります。
それぞれの業務でどのような項目を管理したいのかということも利用者さんから聞き出しておきます。
外部設計
このフェーズからシステム寄りの作業になります。
外部ということで、主に外見を決めていきます。利用者の目につく部分ですね。
この業務を行う時は、この機能を利用してもらいます。この機能の利用方法は、ここに〇〇を入力して、このボタンを押下すると登録可能です。
登録した内容は、この画面から見れますよ。そして、紙に出す場合は、このボタンを押下して帳票を出力してくださいね。
みたいな。抽象的ですが、こんな感じです。
このフェーズでは、業務を効率よく行うために、利用者にとって使いやすい機能や画面、見やすさを考えた画面の項目配置などを提示し、利用者さんと合意に達するまで検討します。
検討する元ネタは要件定義でリスニングした業務そのものです。
- どういった業務をシステム化したいのか。
- その業務で扱う項目は何か。
- 誰がその業務を行うのか。
- その業務の目的は何か。
それらを実現するための機能を検討します。
内部設計
ここまで来たらあとはシステム屋さんが頑張るフェーズです。
外部設計で決まった内容について、プログラムするための設計書を作成します。
といっても、作る資料はプログラムと1対1になってはいけません（設計書がプログラムそのものになってはいけない。むしろ、それだと意味を成さない）。
プログラムはプログラマーが力を発揮する作業なので、それを補佐するよう、どういった機能を実現したいのかを明確に伝えるための資料を作る感覚です。
例えば、〇〇画面を表示した際は、このような表示になっていること。とか、登録する際に、この項目が入力されていなかったら「ダメですよ！」ってメッセージを表示する。
とか、機能の細かな部分を定義する作業を行います。
この作業は最も工数が膨らむのではないかと思っています。
プログラミング
設計した内容をシステム化するのがプログラミングのフェーズになります。
内部設計のとおり、手を動かしてプログラムを書きます。出来上がったら、正常に動くか単体テストまで行います。
※ここで単体テストなしに「できた！」っていう仕事をしてはいけません。動作確認がOKとなるまでがプログラミングです。
開発テスト
プログラマーが単体テストをしてくれますが、それはコーディングした機能が正常に動くことの確認で、プログラミングの確認しかしていない状態です。
よって、仕様通りに正常動作をするかどうかを検証する作業が必要なので、設計者がそれを確認します。
ことによっては、ここで設計に修正が入ることもあります。
この業界に入って10年経ちますが、テストは本当に重要で、最も重要な工程といっても過言ではありません。
プログラムの観点、要件の観点で十分にテストを行います。
運用テスト
このフェーズは、利用者さんが行います。
利用者さんが実運用と同じようにシステムを利用し、不正がないか確認します。
基本的には要件定義や外部設計で詰めた内容を確認するのですが、たまに、「やっぱりこの機能、この方が良いんだけど…」みたいなことを言われることがあります。
「だって、こう決めたじゃん！」とは言わず、残工数や要員などを考慮して、対応するかどうか決めています。
※プロトタイプを作って、検証してもらいながら進める方法もありますが、一長一短があるので、進め方は開発プロジェクトによります。
リリース
全てOK！となったら、あとはリリースのみです。
リリースとは、利用者さんにシステムの利用を開始してもらうための作業のことです。
ということで、ここまで来て晴れてシステムが利用できるようになるのです。
長いでしょー？そうなんですよ、ほんと沢山の工程があるんですよねー。
本当はもっと細かく書こうと思えば書けますが、簡単にまとまらないので、少しずつピックアップして記事化しますね。
まとめ
今回は、僕の仕事であるシステム開発についてお話ししました。
システム開発の「いろはのい」ですが、この記事で少しでも理解していただければ幸いです。
特に、利用者側の方には、開発の裏っ側を見て頂けると嬉しいなーと思います。
利用者の協力なしに良いシステムは開発できないですからね！
今後もスポット的にピックアップして作業やシステム開発の実情などを紹介できればいいなと思っています。
長々となりましたが、そんな感じス！
