IT会社と仕事をする
仕事を依頼するIT会社と
開発工程について説明します。
■仕事をどこに依頼するか
IT案件を依頼する場合、
依頼先企業の選択が
案件の成否が決まる。
メーカー系IT企業
コンピュータメーカーや
情報機器メーカーの子会社
である。
自社製品の知識が豊富なのが、
メリットだが、他社製品の
知識が疎く、
マルチベンダ環境のシステムを
構築する場合は、注意が必要で
ある。
ユーザー系IT企業
銀行、商社の子会社である。
特定業務に非常に精通して
いるのが、メリットだが、
特定業務以外の知識が疎い
場合もあり、また、親会社の
仕事だけで満足している子会社
ならば、外部受注に対しては、
真剣身がない。
独立系IT企業
親会社とのしがらみが無いのが、
メリットであり、デメリットで
ある。
マルチベンダ環境のシステムを
構築する場合は、有効だが、
メーカー系IT企業、
ユーザー系IT企業との協業が
多い場合、その知識に偏り
がちである。
■開発の依頼
営業者との面談
IT企業との最初の面談は
営業者である。
営業者に対しては、下記の
知識を判断しておかなくては、
ならない。
・技術知識
・業務知識
両方の知識を満遍なく
持っている者は少なく、
業務知識は豊富だが、
技術知識については、
システムエンジニア(SE)が
同行しなければ、話が進まない
場合が多い。
要求定義
依頼者側としては、要求定義を
まとめておく必要がある。
・こんなシステムが欲しい
・こんな機能が欲しい
要件定義
要求定義（要求定義書）に基づき、
システムアナリスト(SA)やSE
は、「要件定義書」を作成する。
・依頼の概要
・解決したい目的
・システム全体概要
・機能要件（開発する部分）
・非機能要件（セキュリティなど）
・予算、スケジュール
・全体工数、工程
・コミュニケーション方法
コミュニケーション方法
・ブレーンストーミング
少人数で焦点を絞ったテーマ
についての話し合い。
発言への批判はしない。
・KJ法
１つの問題を１枚のカードに
記述し、そのカードを
グループ化、階層化、
相関関係の図式化などを
行い、全体構造を理解する。
・バスセッション
少人数、短時間で、
何らかの結論を導き出す。
リーダー、記録係が必要。
顧客側注意点
「要求定義」には下記の点を
に注意し作成すること。
・自社業務に対して、何を
したいのか？具体化すること
・システム化に対して、
意思統一がされていること
<例>
・商流、金流、物流などに、
一般的な業務でなく特殊業務
が存在している
・自社システム部門が独自で、
仕様を決め、IT企業に提案、
その結果、一部管理者、
システム使用者からの反発を
受け、システムが使えない
新技術が良いのか？
IT企業は、新技術での提案を
持ちかけてくるが、
そのメリットは、顧客側に
あるのか？、開発者への
メリットではないのか？
<例>
・この新技術を使えば、効率が
アップする → 顧客業務が効率化
するのか
・オブジェクト指向を利用し、
効率が高くなる → 開発者側の
メリットが多く、顧客メリット
は少ない
・Web化しましょう
→ 必要性があるのか？
※効率化、メリット化を進めて
くる場合、デメリットは何か？
を必ず確認すること。
見積方法とは？
ハードウェアの見積もりは、
形あるものの値段のため
分かりやすいが、
ソフトウェア開発人件費は、
かなり曖昧である。
使用される単位は「人月」
という、１人が１ヶ月作業する
仕事量で計算されるが、
各要員（SA、PM、SE、PG）
により個々単価が異なってくる。
しかし、各要員の特性、
パフォーマンスなどは加味
されない。
<見積方法の例>
・ファンクションポイント法
システム規模を見積もる
ための手法である。
各機能を「易、並、難」に
３段階分類し、係数を乗じて
基準点を設定する。
特性の複雑さを６段階評価
して、基準点に加算する。
最終的な得点を算出する。
得点大→大規模、高コスト
得点小→小規模、低コスト
・COCOMO法
作業工程数、難易度より
工数を把握する。
しかし、上記の手法は、
難易度、複雑性などが属人的
であり、正確性に欠けるため
その後、手調整により人月で
換算されるのが普通である。
SE業務と開発手法
要件定義後は、
その開発手法により
開発は進められていく
<開発手法の例>
・ウオータフォールモデル
古典的ではあるが、
多数の企業で使用されている。
「要件定義→設計→開発
→テスト」の順次工程で、
進められる。
順次工程のため手戻り
（前工程遡り）に非常に
時間が掛かる。
しかし、大規模システムでは、
この手法でしかできない場合が、
多い
・プロトタイプモデル
早い時期に疑似完成品を作成し、
それを顧客、開発者で改善点を
検討し、完成品に近づけてゆく
手法である。
改善点の意見は言いやすいが、
要求定義以外の意見が出てくる
等、完成までに時間が掛かるのが
難点である。
・スパイラルモデル
ウオータフォールモデルと
プロトタイプモデルの
良いところを取った開発手法
である。
大規模システムを小規模の
パートに分けそのパートに対して
プロトタイプモデルのを作成して
いく。
理想的な方法に見えるが、
パート単位の開発工程となり
完成までにかなりの時間が
掛かる。
・アジャイル開発
これまでの開発では、
ドキュメント類が多くなり
ドキュメント（計画）を
重視するのではなく
小さなシステムを作成し
すぐにリリースすると
いう、適応重視の軽量開発
である。
・書類が残らず、
コミュニケーションだけで
開発ができるか？
・優秀な少数精鋭PGだけで、
大規模開発ができるか？
等、課題は多い。
実際は、開発手法ではなく、
開発思想である。
■開発工程
設計
要求定義、要件定義の工程が
終わるとSEにより次の設計書が
作成される。
・外部設計
システム化計画、プロジェクト
実行計画、システム全体構造図、
画面設計、帳票設計、
論理的データ設計
・内部設計
機能分割、物理データ格納方法、
入力方式、エラー時対応
・詳細設計（プログラム設計）
書く機能における処理詳細
※各書類を顧客（依頼者）が
見ることは、殆どないが、
工程管理、進捗管理でけは、
確認しておく必要がある。
クライアント方式
・ファットクライアント
エンドユーザー端末に、データ、
ソフトウェアが保持される形式。
セキュリティ問題、個人情報
保護の点で脆弱性が多い。
・シンクライアント
管理性を高めるためにデータを
サーバーなどの外部に保持する
形式。
サーバーに接続できないと
何もできないが、サーバー、
ネットワーク、クライアントの
性能が向上しているので、
利便性は高くなっている。
EA（ｴﾝﾀｰﾌﾟﾗｲｽﾞｱｰｷﾃｸﾁｬ）
部門や部署間で、ばらばらの基準や
仕様を標準化し、相互接続・連携を
すること。
下記の４つの要素よりなる。
政策・業務体系
データ体系
アプリケーション体系
技術体系
開発、開発言語
プログラミング、コーデイング
とも呼ばれ、ここからが、
プログラマ (PG)の仕事である。
<プログラミング言語の例>
・FORTRAN
1956年に開発された
科学技術計算向け手続き型
プログラミング言語。
数学関数を持ち大規模計算を
行う分野で、スーパーコンピュータ
などで使用される。
・COBOL
1959年に開発された
事務処理用手続き型
プログラミング言語。
英語記述を元にし、金額計算、
文字列処理に優れ、金融機関等で
使用される。
・C言語
1972年に開発された
システム記述用手続き型
プログラミング言語。
移植性、自由度が高く、
オペレーティングシステム (OS)の
記述や機械制御で多用される。
・JAVA
1995年に開発された
OSに依存しない平易性重視の
プログラミング言語。
オブジェクト指向が強調されるが、
手続き型言語としても記述可能。
Webサービスやスマートフォン
向けアプリで多用される。
・PYTHON
1991年に開発された
オブジェクト指向、関数型
プログラミングが可能な
インタプリタ型のプログラミング
言語。
強力な構文規則により
ソースコード記述が統一され
読みやすいプログラムとなる。
データサイエンス、Webサービスや
スマートフォン向けアプリ等
多用される。
言語翻訳
プログラミング言語で記述された
ものをコンピュータで実行できる
形（機械語）に翻訳する。
・コンパイラ
言語を一括で翻訳する方法。
全体を一括で行うので、
高効率の機械語に翻訳される。
・インタープリタ
言語を１文づつ翻訳し、実行する
動作速度は、コンパイラより遅い
が、プログラムが完成しなくても
途中実行できるので、デバッグ
（不具合の修正）も行い易い。
検収（テスト）
開発完了後は、検収（テスト）
である。
要件定義で決められた機能、
性能が十分か確認すべきである。
テスト手法
・ブラックボックステスト
システムが出力する結果に
着目し、異常がないか確認
する方法。
ユーザー側のテストと言われる。
＜例＞
・同値分割法
正常値、エラー値（上限、下限）
を準備し、処理が正しく
行われるか確認する方法。
・境界値分析
正常値、エラー値（上限境界値、
下限境界値）を準備し、処理が
正しく行われるか確認する方法。
・ホワイトボックステスト
システム内の論理構造に
着目し、異常がないか確認
する方法。
開発者側のテストと言われる。
＜例＞
・制御フローテスト
プログラムの処理経路を
全て網羅的に実行するかを
確認する方法。
・データフローテスト
プログラムのデータや変数が、
順番通りに行われているかを
確認する方法。
・グレーボックステスト
ホワイトボックステストと
ブラックボックステストの中間を
行うテスト。
内部構造を理解した上で外部からの
機能や仕様を確認するブラック
ボックステストを行う。
■本番稼働後
検収（テスト）後に、リリース、
本番稼働となるが、
テスト手法を十分に行っていないと
本番稼働時に不具合が発生する。
開発者側と顧客側での「瑕疵対応」を
明確にしておくべきである。
この記事が気に入ったらサポートをしてみませんか？