関連することをクリックすると，関連する場所に飛びます。
初めに
今までも何度も作成しようと試みてきたのですが，結局SEの仕事について系統だって説明していなかったような気がします。そこで，今回はSEの業務を段階をおって説明しましょう。
SEのレベル的な話と，分野の話は別
途記載していますのでそちらを御参照下さい。
では，SEとは何をするのでしょうか。
SEはどのような仕事をするのでしょうか−−イントロ
SEは大変幅広い仕事をします。すでに説明しているように，実施する仕事の面
から分類すると
などに分かれるでしょう。これらの人をひと括りにしてシステムエンジニアというようです。
また，業務分野別としては次のような分類になるでしょう。詳細はこちらを参照下さい。
- 金融・保険
- 流通・物流・販売
- 製造・制御
- プラント
- サービス
- 交通・航空
- 通信
これらのシステムを実現するために，使用する計算機の種類別 には次のように分かれるのではないでしょうか。もちろん，これらの種類をいくつか含んでシステムを構築するのが通
常ですが。
- PC系
- ホスト系
- UNIX系
- マイコン
- 制御系
- 古い話では，オフコン系
などに分かれるのではないでしょうか。
技術分野別には
- ネットワーク/通信/プロトコル
- OS
- ミドルウエア
- アプリケーション
- マンマシン
- DB(データベース)
- 情報検索
などの分野が思い浮びます。
これらの分類にそってSEの仕事を順次説明しましょう。
システムとは？は置くとして，これの仕様を決めることは重要です。システムエンジニアの主たる業務と言っていいでしょう。
システムの仕様とは何でしょうか。
- どのような仕事をするのを助けるのか?・・・システム構築の目的，達成目標。これが当初規定すべき内容。お客のどのような業務の遂行に貢献するシステムであるかということを規定する。
- どのように機能するのか？・・・システムが必要な理由。通 常，機能リストを作り，それをだんだん詳しく肉付してゆく。これがほとんど全ての死命を制すると考えてよい。
- どのような性能を持っているか?・・・同じことをするのでも，早いほうが良いけど，それだけ高価になる。だから妥協が必要。性能とは速度だけではないのが大変難しい。
- どのような画面操作を伴うのか？・・・最近はこればっかりの感がするけど，それでもシステムの使い勝手はこれで決まってしまう。へたくそなシステムはこれが本当に悪い。でも，この仕様をきちんと規定するのはすごく大変。
- どのような機器を用いるのか?・・・本当はどのような機器で実現してもいいのだけど，これを最初から規定することもありますね。もちろん，どのようなネットワークを用いるかも決める必要があります。
- どのような応答速度を持つのか?・・・まあ，性能の一部かもしれないけど，制御関係では特にこれを規定することが必要。1秒で完了するのと，1分かかるのでは全然違ったシステムになる。
- どのような精度を持つのか？・・・これも制御関係では必須。
- どのような環境で用いられるのか?・・・単独で稼働するのか，それともホスト計算機などと接続するのか，むにゃむにゃ。。。専用回線で接続された機器と。ダイアルアップで接続された機器では全く異なるシステムになってしまう。全く同じシステムを東京と大阪で動かす，また，アメリカでも動かすなんてことがどんどん要求されてくる。そうするとシステムはだんだん複雑になってしまう。
- 異常時，故障時の対応，バックアップなどはどのようにするか？・・・これを忘れやすい。きちんとしたシステムではこの異常時，故障時の対応やらバックアップをきちんと規定している。どのような頻度でバックアップを取り，どのような異常，故障に対してもどのような時間で復旧することを可能とするか。
などなど，各々のシステムによってこれらの項目は異なりますが，大略上記のような項目を指定することです。［ああ，本当に難しいな。．．．そう言わないで。．．．これをきちんと説明することがよっぽど難しい。］
ここで挙げた仕様は，SEが一人で決めるのではありません。二人のSEで決めることでもありません。そう，お客さんと話しながら決めることです。お客さんが「仕様書」として提出してくれるかもしれませんが，それをそのまま鵜呑にしないことが大切です。そんなことをすると，大変なシステムが出来上がります。通
常，構築不可能なシステムを要求されますからね。それを「値切る」のが立派なSEの仕事です。例えば，「お客さん，このような業務はコンピュータに任せるのは大変ですよ。このような仕事はコンピュータでは実現不可能ですよ。こんな応答速度はとてもじゃないけど，ETにしか実現できないですよ。．．．．」通
常，「値切る」事が多いですね。
でも，「値切る」ことばかりしていては，お客さんの［あなたに対する］信用はがた落ちになります。だから，立派なSEはお客さんが「ほれぼれ」するような「素敵な機能」を提案するものです。例えば，「このボタンを押すと瞬時にあなたの悩みを解決してあげます。」とか，「この入力は，どのような入力をしても，必ずOKとなるような機能を付ける。」とか。「これをクリックすると，綺麗な女性が出てきてコーヒーを入れてくれる」とか。［これは全部冗談ですよ。］：：：もっと具体的に知りたい人はこちらを御訪問下さい。
また，ここでは述べていませんが，世界標準，業界標準を確立できるような仕様を提案できること，これが非常に重要であります。この部分を参照して下さい。
標準仕様，業界標準，高度な仕様の重要性
だから，仕様の決方で重要なのは，
- 機能を出来るかぎり単純に仕様として決めること，
- 機能を出来るかぎり独立した単純な機能の組み合せになるように設計すること，
- マンマシンインタフェースはできる限り簡単にすること，
- データベースとのやり取り，他システムとのやり取りなどもできる限り単純化すること
などが非常に大切です。本当にSimple is the Best!!です。お客にとっても，作成する側にとっても，日本国にとっても。だから，標準化は大切なのです。そうすると，同じような機能のプログラムをあちこちで作る必要がないのです。そうすると，その標準を押える機関，会社，団体が非常に大きい利益を享受できます。でも，日本は，各社とも異なるシステムを好みます。各社とも小さい点で，細かい点で異なる仕様，細かい点で優れているであろうと主張する細かい仕様が大はやりです。細かい点はどうでも良いのです。
- 大きい，大枠をきちんと押える基本的な仕様を
- できる限り単純に，
- できる限り高機能に
- できる限り高性能に
実現するような仕様を提案できることが実力です。
プロジェクト管理と一般的に呼ばれているのでここでは「プロジェクト管理」として説明しますが，要するにシステム全体が出来上がるのを管理する人のことです。管理する事項は下記の通
りです：
などです。沢山ありますね。これは正常な状態で運用されている正常なときの作業内容です。
万一，異常が発生した場合は，これに対応するための手段を全て執り行うのがこの人の責任です。だから，「プロジェクト管理者」の責任は重要ですし，これがきちんと機能していない場合は，プロジェクトは「惨めな運命」をたどります。もちろん，プロジェクトの責任者と同じ運命ですがね。
まず，製作物の製造過程の管理：
お客にソフト，ハードともきちんと期日通りに納入されるためには，手配段階できちんと手配されていること(SEの仕事)が重要ですが，きちんと手配されていてもきちんと製作され規定通
りに出荷されるかどうかは疑わしいのが現実です。だから，プロジェクト管理者はこれらを全て責任部門に確認してゆくため，定期的に工程会議を開催して，工程の進捗状況を管理します。これは極めて大切なことです。これが全てといってもいいでしょう。以下のことはこれの詳細バージョンです。
日程の管理(通常はソフト)：
ソフトが決められた通り製作されているかを確認します。開発品を含みます。また，外注管理も含みますが別
項で記載しています。これは，駄目になって初めて「ああー，あかんわ！！」なんてことにならないことが大切です。ではどうすればいいのかな？ プログラマや，外注全ての人を遠隔監視カメラで監視していくことが必要です。［なーんてことを書くと，馬鹿！！って言われるね。］
ですから，プログラムの製作単位ごとに，どのようなドキュメントが作られ，どのようなプログラムが作られるか，誰が担当して，工程はどのようになっているかをきちんとした工程表を作って［作ってもらって］，いつも持っています。そして，この工程表を元に，上記の「工程会議」で各プロセスでの工程の詳細をチェックします。出来高をきちんと量
ってゆきます。重さででも，ページ数ででも，ファイルの大きさでも，画面 の数でも。何でも良いのですが，要するに量れる単位でプログラムの出来高を計るのです。そして，これが最初に計画されたとおりの工程で出来つつあるかをチェックします。
ソフトでもハードでも，どのような仕事でもそうですが，最初のスタート時点と最終の詰めの時点では進みが遅いのが通
常です。そして，エンジンがかかり始めると，スピードが速くなります。プログラムの種類に応じて，概略のスピードを知っている人がプロですね。また，これくらいの仕様書であれば，これくらいのプログラムが出来るとか，これくらいの時間と人手がかかるとか，なども知っている必要があります。これを知らないと，プログラマのプロ，外注のプロに騙されます。そして沢山のお金，時間を必要とされるなんて申請されたら，そのまま了承する以外ないですね。そうするとどうなるでしょうか。−−−−−＞大変高価なシステムが出来上がります。
人工(人手)の管理(要するにお金の管理)：
ここで書き忘れましたが，プロジェクト全体の工程とお金は前もって決められています。通 常はSEが見積りを提出する段階で決っているのですが，お客さんに値切られたり，競合する他社と競争するために，営業がやむを得ず「値下げ」したり，「工程を短縮」したりするのが通
常行われます。だから，プロのSEは通常何割かの「積上げ」「値切しろ」を持っています。そして，営業部門，顧客などと交渉し，きちんと説得して必要とする「お金」と「工程」を確保している必要があります。
プロジェクト管理者はこの与えられた工程とお金を元に，自分で「目標とする工程とお金」を設定して，これをステップ毎，モジュールごとに割振りします。そしてこの枠内で各モジュール，ステップの業務が完了して，製作物が出来上がることを目標として自分の業務を実行します。ここでも多少の値切しろを持っているのがポイントです。これを持っていないと，通
常各作業は遅延したり，予定以上のコストがかかりますので，これを吸収するためには必須です。でも，どれだけの値切しろ「マージン」を持っているかは各人の秘密ですから，．．．．あまり「マージン」を持たなくてもきちんと仕事をするプロジェクト管理者は，SEにとっても，営業にとっても，お客にとっても「神様」見たいな存在ですね。．．．．．あーしんど。［私はこのプロジェクト管理を長い間勤めてきました。そーして，頭の毛が真白，つるつるテンになってしまいました。．．．こんなもんですよ，仕事って言うのは。．．．SEもしんどいし，プログラマもしんどいけど，プロジェクト管理者もしんどいですよ。］
外注管理：
プログラムを社内で製作するにしろ，外注に依頼するにしろ，工程の管理は同じですが，多くの場合外注に出す場合は余計な苦労が付纏います。しかも，外注に依頼する場合が多いのですから，この苦労を「プロジェクト管理者」の必須の苦労でしょう。
鉄則は「厳しく」「やさしく」です。私は通常，外注の会社や人には，社内の人・部門に対応するより「下手に」「やさしく接する」ことをモットーとしてきました。これは私の性格ですから。「弱気をくじき，強気を助くる」のが世の習いのなかで，「強気をくじき，弱気を助くる」この小林の株がどんどん上がったのは当然でしょうね。＜ウヒヒ．．．＞
でも，これは当然なんですよ。だからといって，日程とお金はきちんと自分で設定して，この中できちんと仕事をしてもらうようにお願いするわけです。これが大変な仕事ですが，ルールは社内に対するのと同じ。相手の財布の中身が見えないだけ余計に面
倒くさいけれども，外注会社が何人の作業になっておろうと，減速として一人の人に対応売るだけで良いのですから，ポイントを抑えておけば，大変に楽な仕事です。
ポイントとは：
- 工程を前もってきちんと策定してもらい，提出してもらう。これには実施する担当者名まで記述してもらうこと。
- お金は外注会社が管理するのだから，我々は日程だけを管理すればいいのですが，どれだけの人数の人がどの期間作業をするかを上記の工程表に記入してもらうわけです。
- また，どれだけの製品（出力）がどの時期に提出されるかをこの工程表とは別
の資料として「ドキュメントリスト」として提出してもらうわけです。きちんとドキュメント番号，ドキュメント名，ドキュメントのページ数なども記入してもらうわけです。［そんなこと出来ないよ．．．．って？？ そんなことはないですよ。これが記入できないような会社は外注会社として採用しないことです。これがポイント。］
- そして，次の項目である，試験要領書も含めてどのような試験をするか，どのレベルまで，どのような環境で試験をするかをドキュメントの形で提出してもらいます。
- そーすると後は簡単ですよね。原則的に，週１回の外注会社との工程会議を開催します。そして，上記の全ての項目に関して，前もって提出してもらったドキュメントに従って，すなわち，工程とお金と，作成されるものの品質を確保することが可能になります。
- でも，ポイントは「厳しく」「やさしく」ですからね。それと，外注会社からの付届け，飲み会はお断りしましょう。そして，外注会社の人には，自前のお金で仲良く飲みましょう。彼らを守るのが自分であり，自分と親しく，そして，自分の要求することをきちんと実施することが「外注会社にとって最善の方法」であることをきちんと「申渡しましょう」。これが大切ですね。本当に。
試験の管理：
試験要領書を元に試験の実施状況を管理します。実際100%試験が完了すればいいのですが，そうは行かないのです。全パス試験などと言ってフローチャート上の全てのパスを通るようなデータ，操作を行って，プログラムが正常に動作するかを試験をするわけですが，膨大な時間，手間がかかります。その上，万一，数多く，バグ（虫）や不良箇所が見付かると，プログラムを製作する部門に差戻してこれを修正してもらうわけですが，直ちに修正してくれるわけではありません。1日とか2日とか，1週間とかかかります。そして，修正されたはずのプログラムを再度試験しても上手く動作するとは限らないのです。プログラムのバグは案外「単純なミス」よりも「仕様書に対する理解不足：常識の齟齬：環境の違い：新式の違い」など種々な要因が影響しているので，プログラマーの「単純なプログラムミス」ではすまないのです。そうすると，その仕様書の理解に関して仕様書を作成した人，その元のお客の担当者に確認をする必要があったりします。そうすると，たちまち，1週間や2週間は経ってしまいます。
だから，試験は出荷の段階で99%とか，95%なんとかで終了してしまう可能性もあります。［残念ですが，このようなプログラムが皆さまのお手元に届いていることも沢山あります。］
必要なことは，プログラムを作成する人と，この試験を実施して管理する人は通常箱となるということ，そうするとその内容を十分に理解するために膨大な時間，手間が必要であるということ，だから，ちょっと大きくなるようなプログラムになると，その試験紙要書を作成し，それを実施するだけで，プログラムを作成する時間の2倍〜3倍の時間がかかるわけです。
すでにシステムを設計し作成する人の「試験要領書」のところで説明しておりますが，プログラムを設計し作成する段階で，同時進行で「試験要領書」を作成します。当然，元になる「システム仕様書」や「ソフトウエア仕様書」は同じですが，「プログラム製作仕様書」などを中心として，プログラムを試験する要領を仕様書の形でまとめます。
単体試験，組み合せ試験，総合試験，出荷試験，現地試験などの段階を踏みますが，基本的にプログラムを作る単位で試験をし，それが完了した段階で，それを機能ごとに組みあわせて試験をし，最終的に製作の最終試験として総合試験を行います。この時，通常お客の現場（実際に使用される場所）の環境が完全に整わない可能性があります。そうすると，その環境は「シミュレーション」をして整えます。その意味でも，お客のところでの環境をきちんと仕様書という形で把握しておかないとこの試験が出来ないわけだし，当然，お客のところに持っていって，「さあどうぞ使って下さい」なんて言っても「お世辞」だけで「全く動かない」システムになってしまいます。
最近，ドコモの携帯がかなりの傷害を発生させています。その理由として，お客が使用する環境が異なること，負荷が異常に高いこと，操作が予定外であること，また，環境との整合性が取れていないことなどが挙げられるのではないでしょうか。本当に非常に沢山の要因が影響しており，これを現場でなく製作の場で完全に試験をすることは容易ではありません。全ての操作を「仕様書」の形でまとめることが非常に困難であることなどが影響しています。
だから，最近ではマンマシンインタフェースに関するような操作は，一種の「シミュレータ」に相当するパソコンのプログラムを使用して，プログラムを作成する必要がなくとも，近似の操作環境を簡単に作れるようになっているものがあります。その場合，実際のデータや，データベースが構築されているわけではありませんので，その当たりの試験は出来ませんが，少なくとも非常に仕様書にしにくい操作自体を「実際の画面」を使用して前もって作ることが出来ます。また，優れていることは，このようなソフトは「操作」をシミュレーションすると同時に，近似的なプログラムのコードを作成してくれます。だから，そのままプログラムをする必要がなくプログラムが出来てしまうわけです。もちろん，データベースとの接続部分やその他の機能との接続部分は当然プログラムを作る必要がありますが。
