はじめに

　「企画→開発→本稼働」
その後実際にお客様がシステムを使い始め、運用保守を継続
となるのが一般的な流れです。
開発の形態としては
　・ウォーターフォール型
　・アジャイル型
など複数の型がありますが、以下はウォーターフォール型と呼ばれる一般的な開発の流れを
記載しています。

システム開発・導入

企画・提案

この工程はお客様からお仕事を頂戴するためのものになります。
どれだけ技術力が高い組織であっても、お仕事を頂けなければ始まりませんので
大変重要な工程となります。
弊社ですと営業部のメンバーが主体的に活動を行う場面となりますが、
エンジニアも協力して提案活動を行います。

大別すると
　・こちらからお客様へご提案する
　・お客様からRFI、RFPなどが発行され、提案→プロポーザルとなる
パターンがあります。
RFI(情報提供依頼書)とは、
お客様がシステム発注するにあたり必要な情報提供をシステム業者へ広く求めるものになります。
RFP(提案依頼書)とは、
提案書を依頼するためのものになります。
RFIが、こういう課題があって、システム導入でどう解決したいなどの
大きいレベルでの話に対して、RFPはシステムの機能などの詳細な内容
というような違いがあります。

エンジニアはRFI、RFPに対する技術的な情報提供、機能要件の調査やまとめ
などの部分で営業部へ協力します。
またパッケージ導入の案件の場合、デモをお客様にお見せする場合がありますが
その場合もエンジニアの出番です。
一丸となって営業活動をするイメージですね。

その後、提案活動が実り、ご成約となるとプロジェクトが開始されます。
残念ながら成約まで至らなかった場合でも、今後システム更新や別システムのご提案などの
何らかの場面でまたご依頼を頂けることもありますので、ご挨拶と、
社内では敗因分析をして今後のより良い営業活動に結びつけます。

 

プロジェクトのキックオフ

プロジェクト(以下PJと記載)は何となく始まるわけではないです。
「さぁ、これから一緒にこういう風にやっていくぞ！」
という意識合わせを必ずやります。決起集会みたいな感じですね。
プロジェクトマネージャがプロジェクト計画書などを事前に作成し
プロジェクトメンバー全員集合のもと、目的、期間、役割分担などの
事前に意識合わせが必要なことを確認します。

もともとはサッカーやラグビーの試合開始を意味する言葉ですが、意味合いは同じです。

 

要件定義

ここからがいよいよPJの最初の作業工程、SE主体の作業領域となります。
どういう機能を実装するかをお客様とともに決めていきます。
お客様はシステム部門担当者と実務担当者に大別されますが
実務担当者は必ずしもシステムやコンピュータに明るい人とは限りません。
SEにはシステム開発に関する技術力はもちろんですが、
お客様の理解できる言葉で説明できるコミュニケーション能力、
お客様の業務への理解力など幅広く要求されます。
使いやすいシステムにするための提案力も必要ですね。

お客様はSEに対する期待感がとても大きいです。
よって通常は経験豊富なSEが対応し、経験の浅いSEはサブとして参加し、
作業を通して学ぶという体制をとることが多いです。

 

外部設計

「こういう機能を実装する」などが要件定義で確定された後、
画面や帳票にはこういう項目が必要で、こういう入力チェックがされて…
など使用されるお客様から見える動きなどを設計書という文書で定義するのがこの工程です。
そのためこの工程では設計書を作成後、弊社内部のレビューを経て、
お客様レビューをするのが一般的です。
システムを作った後で、「こういうイメージじゃなかった」となるとお互い困りますので
こういったことをするんですね。
お客様もこの方が早い段階で確認ができるので安心というわけです。

この工程は、基本設計、概要設計などと呼ばれたりもします。

 

内部設計

外部設計を完了後、いざプログラムを、、、といきたいところですが、
その前に内部の処理等を定義し、この後プログラムを作る工程で効率良く作業できるよう
またプログラマーの組み方に個人差が出ないようにするのがこの工程です。
「そんなの無くても実装できるのでは？」
そう思うかもしれません。確かにただ動くだけでいいならできます。
ですが実装したい機能の動きを満たすためのプログラムの仕方は
千差万別ですので、プログラマーにお任せにしてしまうと
ただ動けばいいというような成果物になる可能性もあり、
保守しにくいプログラムになってしまったり、
処理速度が考慮されていなかったり‥‥
後々様々な問題が発生したりするんです。
そうならないためにこういった工程があります。

ちなみにプログラムの規約（この変数はこういう名前にしてね、というような決まりごとが
文書にまとめられたもの）というのも通常ありますが、
それもこういった理由があるために存在します。

プログラムを組んだ人が今後もずっとそのプログラムをメンテナンスし続けてくれる
というわけではありませんから、こういう考え方は大変重要なんです。

この工程は、詳細設計などと呼ばれたりもします。

 

製造（プログラミング）

設計が完了するといよいよプログラムの作成です。
弊社ではC#、JavaなどPJによりいろんな言語が利用されます。
PCに向かって一心不乱にカタカタカタ・・・
一般的にエンジニアのイメージがこの工程なのかもしれません。

でも、結構話もしたりするんですよ。
例えば
「この部分こういう挙動するように組みたいんだけどなんかサンプルないかな」
「あぁ、それなら前のPJで似たようなの作ったよ、それ見てみ。パスをteamsしとくわ」
「サンキュー、助かるわ」
こんな風にチームで協力しながら、効率良く、品質のいいものを作り上げていくんですね。

この工程は、コーディング、実装などと呼ばれたりもします。

 

単体テスト

プログラムが終わると実際に動かしてみて期待した動きになっているかテストします。
これ以降のテスト工程が品質を確保するうえで大変重要となります。
漏れ無くダブりなく(この考え方をMECE（ミーシー）と言ったりします)テストケースを作成し、
エビデンス（テスト実施した証跡）をとります。
NGがあれば不具合修正をします。
全てのテスト項目がOKとなるまで、根気がいる作業ですが、
ここをしっかりやらないと後工程に影響が大きく出ます。

この工程は、UT(Unit Test)などと呼ばれたりもします。

 

結合テスト

単体テストは単一の機能に対するテストですが、
結合テストは複数の機能を横渡りでテストするものになります。

例えば、ある画面で入力したデータが、ある帳票に出力されるというものがあった場合、
　・ある画面の入力に絞ったテスト→単体テスト
　・ある帳票の出力に絞ったテスト→単体テスト
　・ある画面で入力したデータが、ある帳票に出力されることを確認するテスト→結合テスト
こんなイメージになります。

この工程は、IT(Integration Test)などと呼ばれたりもします。

 

総合テスト

要件定義で決めた要件の内容が満たされているかを確認するテストです。
ここまで来るとテストも終盤になります。
仮にここで不具合が多発してしまうと、後戻りが大きくなり非常にまずい状態になります。
そうならないために単体テスト、結合テストで十分にテストをしておく必要があるんです。
また、機能面だけではなく、処理速度が十分出ているか、セキュリティに配慮されているかなどの
視点でもテストします（こういったものを非機能要件といいます）。

この工程は、ST(System Test)などと呼ばれたりもします。

 

受入テスト、運用テスト

ここのテスト主体はお客様になります。
受入テストが納品したシステムの検品に相当します。
運用テストは実際に実務で使用する場面を想定して、データも実務に沿ったものを作成して
テストします。
テスト主体はお客様ですが、お客様は通常業務の合間を縫ってやることが多いため、停滞しがちです。
そのため弊社からはスムーズに進むように支援を実施します。
問合せも多くいただく工程ですが、迅速な回答を行います。

この工程は、UAT(User Acceptance Test)などと呼ばれたりもします。

 

操作説明

お客様にシステムの操作方法をご説明するイベントです。
SEが先生、お客様が生徒、みたいな感じですね。
運用テストを兼ねて実施する場合もあります。
事前に操作説明書を弊社にて作成して活用します。

余談ですが、学生の時に、教育関連の勉強をし、教員の免許を持っている、
塾講師や家庭教師のアルバイトをした
なんていう学生さんはこの工程は得意なところかもしれませんよ。

 

データ移行

上記の　「要件定義」～「総合テスト」　の開発作業と並行して
旧システムから新システムへデータを移す作業が通常あります。
膨大なデータ量になるので通常はプログラムを作成してデータ移行を行います。
そのままだと移せない不整合なエラーデータがあったり、
その場合取り扱いをどうするか協議し個別対応したり、
一筋縄ではいかない、非常に時間がかかるのがこの作業です。
地道に根気強くかつ繊細さを求められます。
（私もこの作業では随分苦労しました…）
エンジニアの腕の見せ所ですね。

 

本稼働

上記の開発作業、データ移行作業が終わり、お客様の本稼働OKの承認が得られると
プログラムを適用(リリース)し、晴れて本稼働となります。
この日は何か独特な雰囲気がありますね。
我々のような業者側は不具合が出ないだろうかの心配と、いやいやこんなにテストしたんだから大丈夫！！
という思い、そういうのが混在した気持ちになります。

何事もなく本稼働を迎えられた時の達成感は何にも代え難いものがあります。
お客様から
「このシステムを入れてよかったよ、ありがとう！」
なんていう大変嬉しいお言葉を頂くこともあり、さらに頑張ろうという気持ちになります。
これがエンジニアのやりがいに繋がっていきます。

 

PJの振り返り・反省

無事、本稼働。よかったよかったでおしまい、、次の仕事へ。となりがちですがそれではいけません。
PJでは良かったことだけではなく、大抵悪かったこともあります。
良かったことは維持もしくはさらに改良して良いものへ、悪かったことは是正します。
次のPJではさらなる良いものを作り上げるべくPJメンバー全員で行います。
システム開発の世界でもこういう考え方は同じなんです。

また社内のPJメンバーで打ち上げ（飲み会）をしたりします。
必須ではありませんが、こういう活動も良好なチームワークを維持するには
大事だと考えています。

これらを経て、「PJ終結」となります。

運用保守

問い合わせ対応

日々システムを利用するお客様から様々なお問い合わせをいただきます。
システム操作に関するもの、システムの挙動に関するもの、月次処理のサポート依頼など
多岐に渡ります。
弊社ではヘルプデスクを開設し、お電話とwebサイトの両方で受付しており、
経験豊富なSEが丁寧に対応します。お客様の業務を止めないことが大事ですので
「早く、正確に、丁寧に」
が大事です。

 

機能改善、要望対応

システムを使用していると、
「ここはこうなってた方がいいなぁ」
などのご要望を頂くことがよくあります。
使ってみて見えてくることというのは、どの世界でもありますよね。

他にもお客様の業務が変わった、法改正に対応する、などシステムに変更はつきものです。
それらの対応は保守費用とは別に基本的に有償での対応となりますが、
要件をお聞きし、お見積りをしたのちに、契約、その後開発作業を行います。
流れは上記の開発の流れとほぼ同じです。

 

不具合対応

全員「不具合0」を目標に作業をしていますが、不具合が発生してしまうことがあります。
現実的にはなかなか0にするというのは容易なことではありません。

発生してしまった場合は、お客様への影響度をいかに少なくするかを考えつつ迅速に、
誠意ある対応を実施します。
緊急の事象の場合は、夜を徹して作業をするということもあります。
こういうことを書くと残業への規制が厳しい昨今、どうなのだろうというのもありますが、
大事なお客様へご迷惑はかけられません。
起こしてしまった不具合は迅速に対応し、その後はお客様への謝罪、復旧後のサポートを行います。
またそれで終わりではなく、きちんと再発防止策を策定してその後確実に実施します。

その積み重ねが品質の維持に繋がります。
それらがお客様からの信用に繋がっていきます。

まとめ

いかがでしょうか？
何となくイメージ出来ましたでしょうか？
「意外と対人の作業が多いな」
そう思われたかもしれません。
それはその通りでPCの前に座って集中する作業は、もちろん工程によってありますが、
システムエンジニアの作業の一部分にしかすぎません。
ITに関する技術力はもちろんのこと、
折衝力、コミュニケーション力、指導力、管理力…様々な能力が求められる職種なんです。
「なんか、、大変そうだな…」
正直に言います、確かに大変です…。
だけど、だからこそやりがいが無尽蔵にある職種なんですね。

人間として成長したい、、そんな思いを叶えてくれる職種…
ちょっとカッコイイこというとそんな見方もできるんじゃないかなと思います。

 

興味を持っていただき
もっと詳しい話を直に現役エンジニアからお聞きしたい場合は
OB・OG訪問、会社見学など随時受付しています。
気軽にお問い合わせくださいね。

お読みいただきありがとうございました！