こんにちは。心理セラピスト きくちかなこ です。
今日は、「システム化」について、ちょっとまとめてみました。私の中でも、今までやってきたこととはちょっと考え方が変わってくるので、、、
まず手始めに、今までやってきたことの整理をします。
基本はウォーターフォール型での開発です。
ウォーターフォール型：開発からリリースまでを複数工程に分けて、後戻りが発生しないように工程を着実に進めていく方法。
※ウォーターフォール型ではなく、アジャイル型開発については明日に現状課題とあわせてｕｐします。
大型プロジェクト（特に大型汎用機）の時は大抵コレ。
【設計】→【ＰＧＭ】→【テスト】→【本番】
めちゃくちゃ簡単に言うとこんな感じ。ＳＥじゃない方々でも聞いたことあるような言葉で表現しました。
実際は、こんな感じで、、、
【要件定義】→【外部設計】→【内部設計】→【ＰＧＭ開発】→【単体テスト】→【結合テスト】→【システムテスト】→【運用テスト】→【移行】→【本番】
要件定義：お客様の要望をヒアリングして実装すべき機能や満たすべき性能などを明確する。
外部設計：要件定義の内容をもとに画面や帳票などのユーザーインターフェースを設計。
内部設計：外部設計の内容をもとに開発するシステムを大まかな機能ごとに分割し、それらのコンポーネント間をつなぐインタフェースの仕様などを設計。
ＰＧＭ開発：内部設計をもとにプログラム言語を用いてプログラム(モジュール)を作成。内部設計とプログラミングの間にプログラム設計を書く場合有。
単体テスト：作成したモジュールが設計書で要求された機能を満たしているかどうかを検証。
結合テスト：複数のモジュールを組み合わせて検証。主にモジュール間のインターフェイスがうまく機能するかを確認する。単体テストが完了したあとに実施するのが普通（たまに未完のモジュールをスキップして無理矢理テストすることも。）
システムテスト：システムが全体として要求された機能や性能を満たしているかどうかを検証。結合テストが完了したあとに実施するのが普通（たまに未完の結合部分をスキップして無理矢理テストすることも。）
運用テスト：実際の業務の流れに沿って利用してみて問題なく動作するかを検証。また、業務担当者がシステムの操作や運用に慣れるための研修を行ったりもする。
移行：実際の稼働環境へシステムを移す。ある時点で旧システムから新システムへ一気に切り替える一斉移行や、システムの機能単位ごとに新システムへ切り替えていく順次移行、新旧を同時に動かし、新システムで問題がなければ旧システムを終了させる平行稼働もある。
本番：実際には『運用』『保守』の大きく２点。「『運用』はマシンの起動や停止、現行のシステムを日々動かしていく作業。運転状況の監視や、CPUやメモリの利用状況などシステム資源の監視も行う。
『保守』とはシステムを改善・変更する作業。主にシステムの障害や改善要望に伴うプログラムやデータの改修を行う。また周辺機器のリプレースやアップデートなども含む。
また、現行システムの解析が入ってくるのがほとんどなので、【現物理モデル】→【現論理モデル】→【新論理モデル】→【新物理モデル】と、現状の業務フローを解析し、新要件にあうように新しい業務フローを構築します。プロジェクトにもよりますが、この新論・新物が外部・内部設計となる感じです。
ただ、、、後戻りが発生しまくってましたけどね(^^; この工程通り、スムーズに進んだプロジェクトに出会ったことはありませんでしたが。
もっというと、案件ごとに遅延が発生するため、同時並行で様々な工程を平行に動かし、にっちもさっちもいかないって方が記憶に新しいかも。
というのが、大人数（何百、何千人月といった工数）で行ってきた開発です。もちろん、相当なお金がつぎ込まれます。（どれくらい有意義に使われていたかっていうのは、、、恐ろしくて計算しない方がいいかもしれませんね。私がプロジェクト責任者だったら、それこそ『死をもって償います』レベルです。それですらも償えないかと。。。）
・・・そういう状態を見ているので、色々な支払とかが「なんだかなぁ」と思うわけです。”あんなムダ遣いの費用を負担してるってことだよなぁ、、、”って。
ちなみに、新人さんらは、通常はPGM開発＋単体テストから作業をします。そのうち、内部設計→外部設計、結合テスト、その後要件定義やシステムテスト、と担当範囲を広げていきます。
ここで、PGMをロクに経験せずに設計をいきなりやってしまうと、何にどれくらい工数がかかるのか見当もつかず、スケジュールもまともに引けずに、もうなんとも手に負えないほどのエライコッチャ状態（よく言う「炎上プロジェクト」）となるわけです。
経験しても、、、スケジュール引けないって管理者もいましたけどね(^^;
本来であれば、工程ごとに担当者を変えて、各工程の出来上がり度合いをチェックします。例えば、内部設計を担当したＡさん、ＰＧＭ開発＋単体テスト担当のＢさんがいたとすると、Ｂさんの作業前にＡさんがポイントを説明したりして一任します。Ｂさんは作業終了後、Ａさんに結果を提出し、Ａさんは設計観点から機能が正しく動いているかを確認する、、、わけです。
ただ、必要人員が集められないといった残念なプロジェクトですと、ぜーんぶ同じ人が行ったりします。（私はこのパターンが多かった気がする。丸投げされてたような。。）
そうなると、チェックが甘くなるので、後々障害発生の可能性が高くなるんですよね。。。
というつぶやきは一旦置いておいて。
実際問題、億単位のお金をシステムにつぎ込めるような会社さんは、さすがに大手のみ。
じゃあ、中小零細企業さんってどうしてるの？というと、、、
パッケージソフトを使ったり、自分たちで作ったり、手作業で頑張ったり。。。
という現状についてはまた明日、私が『課題』と思っていることをｕｐします。
