システム開発って何をするの？

システム開発って言葉、よく聞きませんか？
「うちの会社、システム化するためにシステム開発するんだ～」
的な(笑)

そもそもシステム開発って何するの？ってことを知らずに、システム開発プロジェクトに突入すると、
エライコッチャになります。

あえて可愛く表現してみましたが。

費用はかさばるし、期間もかかる、日々の業務もあるのに開発にも携わることで疲弊する従業員も増える、、
挙句の果てに、ＩＴ化したのに想像していた成果が得られない。。。

そんなことにもなりかねません。

ということで。
四半世紀超、システム開発プロジェクトに携わってきた経験から、
システム開発の作業工程を簡単にご説明したいと思います。

どちらかというと、、、システム屋さんよりもシステムを使うユーザーさん向けです。
ユーザーさん方が、システム開発で何をするのかご存じではないことの方が多いと思うのです。
それによって、システム屋さんとの認識相違が起きたり、事の重要性がお互い伝わっていなかったり
といった問題が起きてしまします。いや、起きていたんです。

ユーザーさんもシステム屋さんも気持ちよくシステム開発プロジェクトに関われるように、
何かヒントになればいいな～と思い、まとめることにしました。

システム開発には順序がある

例えば、、、
「今日の晩御飯」
を作るとき。

何を食べたいのか
何が冷蔵庫にあるのか

などから、「豚の生姜焼き」に決めたとしましょう。

すると、肉焼いて、生姜ダレをかけて、付け合わせの野菜を用意して、、、
と大まかな手順が決まります。

その後、具体的にお肉を冷蔵庫から出し、、、と始まるわけです。

お料理でしたら、料理本もありますし、最近では便利なアプリで動画で見れたりも。
けど、システム開発用の本だとか、ましてやアプリってそんな目にしないですよね。

それなのに、会社運営の未来を決め、多額の費用をつぎ込むプロジェクトが
「イチかバチか」なんて、ちょっと怖すぎる、、、と思うのは私だけでしょうか。

システム開発をお考えのユーザーさん側に、何となくでもよいので『開発の流れ』を
知っていただきたいと思うのです。

では、早速始めます。

システム開発の種類

実は、大きく『ウォーターフォールモデル』と『アジャイル型』の２つに分かれます。

これはざーっくり言うと、
『ウォーターフォールモデル』
⇒要件をきっちり固めて、工程を順番に確実に進めていくよ！
『アジャイル型』
⇒とりあえず出来るところから作ってみて、あとから微調整しよう！
の２種類です。

私の場合、大手さんの大規模プロジェクトばかりでしたので、前者の『ウォーターフォールモデル』で
「きっちり進めるぞ！」タイプばかりでした。
”ウォーターフォールモデルは前の工程に戻らない”のが基本なんです。。。
（とは言っても、、、結局要件が決めきれていなかったり、途中で変わったりと大混乱だったなぁというプロジェクトが大半でしたけどね）

細かなマクロ作成をする場合、ある程度要件は聞きますが、出来たとこ勝負な感もあるので、
ウォーターフォールモデルとアジャイルの中間っぽいこともしています。

ただ、ある程度の規模（業務全体を把握しシステム開発する）の場合は
基本的にはウォーターフォールモデルでの開発を進めていきます。

では、システム開発の多くで行われる『ウォータフォールモデル』について、
各工程を見ていきます。

先に述べましたが、「ウォーターフォールモデルは前の工程に戻らない」ということを忘れてはいけません。
プロジェクトが始動したら、1つ前の工程が完了していない状態で次の工程に進むことはないのです。
ということは！
当然ながら前の工程に戻ることもありません。
（とはいえ、現状は、、、いやいや、そんなこと言っちゃいけませんよね～）

つまり、各工程で成果物を出していくことになります。
常に計画性を保ちながらシステム開発を進めることができるだけに最初の打ち合わせで決定する計画こそが
重要です。

Ｖ字モデルとも言いますが、各設計工程と各テスト工程の位置づけです。

では、各工程・各テストが何をしているのか見てみましょう。

ウォーターフォールモデルの各工程

1．要件定義（要求定義）

この工程では、新しく開発するシステムでは何をしたいのか、どんな要素を盛り込みたいかを明確にします。
さらに、この要求をもとに予算や人員、期間を計画していきます。概算見積もりは必須です。
システム開発をおこなう目的やターゲットについて、システム開発会社と打ち合わせを行います。
システム開発の最終的な完成に相違がないように認識を合わせてがめちゃくちゃ重要です！

2．外部設計

要件定義の内容をもとに、ユーザーインターフェースを設計します。

ユーザーインターフェースとは、画面や帳票などの目に触れるもののデザインです。
ユーザーにとって使いやすいシステムを作るための重要な工程です。ユーザーの使い勝手が
ここで決まるといっても過言ではありません。

また、ここで決まったユーザーインターフェイスを基に、データーベースや処理方式などが
確定します。

3.内部設計

外部設計はユーザー側からの視点でしたが、内部設計においてはプログラムの設計など、
開発者側からの視点でシステムを設計します。
この工程と次のプログラミングについては、細かな成果物をユーザーさんが確認することは稀です。

システム屋さん（ベンダー）としては、ここでＰＧＭの開発本数なども明確になり、
詳細見積もりなども確定します。

4.プログラミング

内部設計で、ある程度のプログラミングが設計できたら、ひたすらプログラムの作成を行います。
次の工程でもある「５．単体テスト」とはセットで作業することがほとんどです。

生産性を測りやすいこともあり、プレッシャーを感じながらも負けん気で頑張った記憶がよみがえります。

5.単体テスト

作成したプログラムの1つひとつがプログラミングの対象単位、いわゆるモジュールごとに要件を満たしているかをテストします。
ここでいう「要件を満たしているか」は「３．内部設計」で定義した要件を満たしているか否かを
確認することになります。

6.結合テスト

複数のプログラムを組み合わせた状態で、それらがうまく機能するかを検証します。
データの受け渡しなどの際にプログラム同士が正常に連携するかをテストします。
ここでも「要件を満たしているか」のテストを行うのですが、「２．外部設計」で定義した要件を
洩れなく満たしていることの確認を行います。

7.システム（総合）テスト

単体テスト、結合テストが完了したら、それらすべてを含めたシステム（総合）テストをおこないます。
その名の通り、すべてのプログラムが、本当に「１．要件定義」の通りに動くのかを確認する工程です。
多くのアクセスへの耐久性や処理速度などをテストします。

私は経験してきたシステムテストの多くは、本番データを使用して特殊なデータパターンがないか確認したり、
処理件数を大幅に増やして処理速度の確認をしたり、、、
次工程の「８．運用テスト」を兼ねていたりもします。

現行システムとの結果を比較したり、相違していたらＮＧな部分、あえて相違する部分など
想定通りかの確認を行ったりもします。

また現行システムのデータを新システムに移行する必要がある場合、
移行テストも兼ねてシステムテストを実施します。
どれだけプログラムが正しくても、移行データが間違っていては正しい結果は得られません。

※開発プロジェクトですと、この工程では期間的にも精神的にも追い込まれている頃でもあります。。。

8.運用テスト

無事システムテストをクリアしましたら、実際に業務に取り入れることができるかを確認します。
運用テストでは、実際にシステムを運用する環境下においてシステムに不具合がないかをテストします。

ここで現行システムと新システムの結果比較（現新比較）をする場合もありますが、
ほとんどの場合、先の「７．システムテスト」で行うことがほとんどです。

例えば、実際のユーザーさん（例えばデータ入力の係の方など）に直接触っていただき、
使い勝手を最終確認すると共に、新システムになることで操作方法が変わる部分など、
ユーザー教育もこのタイミングで実施します。
⇒ということは、ユーザーマニュアルはこの時点で完成している必要がありますね。

9.システム移行（リリース）

実際に使えるよう、旧システムから切り替える工程です。
一気に切り替える一斉移行や、徐々に切り替える順次移行などの移行方法があります。

例えば銀行システムなど、システム停止が日本中どころか世界にも影響が、、、というような場合、
一斉移行ではなく、複数のエリアに区切って、各エリアの複数店舗ずつ切り替えを行うという、
数か月かけての移行もあります。

私が社会人になったとき、ちょうど「第三次オンライン」（銀行のオンライシステム（Wikipedia）参照）の
システム移行真っ只中でした。
移行は夜中に行われるため、夕方頃に”ジャージ部隊”が出勤してきて作業されていた、、、のを見ていました。
夜中の作業なので、ジャージ出勤可だったんです。

10.運用・保守

問題なく運用できるようメモリの利用状況などを確認するのがこの工程です。

さらに、よりよい状態でシステムを利用できるよう、ＯＳのアップデートなども、
この工程に含まれます。
開発したシステムを持続的に活用し続けるためには、常にシステムを監視する必要があるのです。

まとめ

いかがでしょう。

何かをモノ作るときは
・何を作るのか
・何故作るのか
・誰が使うのか
・それを使うとどうなるのか
・それを使って何をしたいのか
といったことが明確にする必要があると思います。

「システム開発」だから難しそう、、、ではなく、
基本的な作業は同じです。
（専門知識云々は必要ですが、どんな業種業界でも同じですよね）

ユーザーさんにお願いしたいのは、この章の冒頭でも書きましたが、
・何を作るのか
・何故作るのか
・誰が使うのか
・それを使うとどうなるのか
・それを使って何をしたいのか
これを明確にする必要があるということです。

「いや、分かるけど、、、じゃあどうやって明確にするのか分からないんだけど」

そんなお悩みの方もいらっしゃるかもしれません。
当然のことなんです。

何故なら、ユーザーさんは「システム開発屋ではない！」んです。
どんな工程で何が必要で、どうまとめればいいの？なんていうのは、
日々の業務にはないことです。

システム屋さん側から「要件ハッキリして！」と言われても、
手が出せない、という場合も多いに考えられます。

では、ユーザーさん側が何をどう準備すればよいのか、、、について
システムを導入する際に必要なこと
を参照していただけると、何かしらのお手伝いになるのでは？と思います。

『システム開発でユーザーもベンダーも幸せに！！』

私の夢です。