問題解決の手段として、システムの新規開発もしくは改修を行うケースがあります。
その場合、一定のプロセスを経てシステムをリリースします。
僕は以前、システムリリースに至るプロセスを、ちゃんと理解していなかったため、手痛い失敗を経験しました。
でもその失敗、理解しておけば避けることが出来たことなんです。
知ってるつもりで分かってなかった僕
リリースに至るプロセスちゃんと理解していますか？
きちんとSEとしての教育を受け、経験を積んで来た方であれば、そんなのは常識かもしれません。
でも「経験ゼロ」の人にとっては、それすら未知の世界です。
僕はそうでした。
あなたは、僕と同じ失敗を繰り返さないでください。
僕の失敗
最初に僕が経験した失敗について、書きます。
素人同然のスキル
僕は、ある会社で何年か社内SEとしての経験を積みました。
でもその会社にいるときには、残念ながらSEとしての体系的な仕事の進め方を学ぶ機会がありませんでした。
そのため、業務経験はあるものの、スキルとしては素人同然だったのです。
そして転職
その僕が、別の会社に転職した時の話です。
転職先はユーザー企業で、そこのシステム部門に配属されました。
ここでも引き続き、社内SEという立場です。
そこの会社では、開発チームと運用チームに分かれており、僕は開発チームを担当することになりました。
理解していない仕事を最初に任される
着任早速、小規模ながら新規システム開発を任されることになります。
以前の会社では社内SEといいながら、ほとんど開発工程に携わることがありませんでした。
そのため、必要なシステム開発プロセスも理解していないという状態です。
テストを終え、リリースへ
さて、僕が引き継いだタイミングでは、すでに設計が完了し、ベンダーの製造まで進んでいる状況でした。
ベンダーの単体テスト、結合テストを経て、ユーザー企業である我々が受け入れテストを行うフェーズになります。
あらかじめ外部設計の内容をもとにテスト計画を作成していた僕は、テスト計画書に沿ってテストを実施します。
テストでは、いくつかの不具合を発見しました。
でもプログラム修正により解消したため、システムを本番環境にリリースすることを判断しました。
そしてリリース計画通りを立て、予定通りリリースしたのです。
問題の発生
早速、ユーザーである利用部門に新しいシステムを使ってもらいます。
朝イチで利用部門に立ち会い、目の前で処理を実行して貰います。
「何だこれ！？」
利用者の声がオフィスに響きました。
問題発生！実は・・・
いきなり問題が発生しました。
今回のシステムは、ある数値を「足して」結果を返すものだったのですが、実は利用部門が必要だった結果は「引いた」ものだったのです。
転職後最初の仕事で、痛恨の問題発生！
血の気が引きました。
事故処理
慌てて、システムを切り戻します。
要は要件定義段階で間違いがあったのですが、この間違いをリリース後まで発見できなかったのです。
理解していれば避けることができたケース
このケース、システムを構築開発のプロセスをちゃんと理解していれば避けることができたんです。
どこに問題があったかわかりますか？
この後、考えていきましょう。
リリースまでの各開発プロセス
この会社の開発基準ではウォーターフォールモデルを採用しています。
そのため、今回はウォーターフォールモデルをベースに書いていきます。
ウォーターフォールモデルでのシステム開発プロセス
システムを開発・修正し、リリースするまでには次のようプロセスを経ます。
- 要求
- 要件定義
- 外部設計
- 内部設計
- 製造
- 単体テスト
- 結合テスト・総合テスト（ベンダー）
- 受け入れテスト（システム部門）
- 運用テスト（ユーザー部門）
- 本番リリース・稼働
先ほどの僕のエピソードでは、この中のプロセスに抜けがありました。
「9.運用テスト」のプロセスが抜けていたのです。
問題を潜在させたままにしない
要件定義や外部設計といった上流工程の段階で潜んでいた問題を発見するためには、受け入れテスト、運用テストは必要です。
その運用テストを抜かしてしまったために、そもそも要件定義の段階で潜んでいた問題が発見されず、そのまま問題の潜んだプログラムが本番環境にリリースされることになってしまったのです。
運用テストが行われていれば、リリース前に問題を発見することができ、手戻りはより少なくて済んだはずです。
つまり正しいプロセスを経てリリースに至れば、途中で潜在した問題をできるだけ早期に発見することができるのです。
それは問題発生を最小限に抑える、リソースを無駄に消費することも抑えることができる方法なのだといえます。
テストプロセスの意味
テストプロセスというと、計画書に従って地道に作業を繰り返すことになります。
そのため、ともすれば単純作業でレベルの低い仕事と捉えられかねられません。
しかし実際は、品質保証を行う重要なプロセスなのです。
各プロセスの対比
- 要件定義と運用テスト
- 外部設計と受け入れテスト
- 内容設計と総合テスト・結合テスト
- 製造と単体テスト
ウォーターフォールモデルの各工程は対になっているのです。
そのためテストが一部でも欠けると、最終的にリリースされるシステムに問題が残ったままとなってしまう可能性があります。
今回の取り上げたシステムリリースのプロセスは、「型」です。
正しい型で、品質の高いシステムをリリースしましょう。
【人生とは時間の使い方】
ミッション：自分が楽しいと思えるコースを、いつでも何度でも走り始められる。誰もが自立して生きていける社会の実現を目指して。
バリュー：無駄な仕事や突然の問題発生、幸せの実現を邪魔する不安や悩みを解決・解消していく。
■吉乃 建志（よしのケンジ）プロフィール■
妻と娘と三人家族／システムエンジニア／40歳過ぎでフルマラソンに挑戦し完走／日本全国巡ることをライフワークに決めた「旅」と「食」を楽しむスキマ旅ブラリスト／本業も副業も成果を出しプライベートも充実できるハイブリッドワーカー
┏ ───────────────── ┓
吉乃 建志
やっちゃえオッサン
Powered by HYBRID WORKER
＜Mail＞info@yoshinokenji.com
＜Blog＞https://yoshinokenji.com
┗ ───────────────── ┛
コメント