システム開発と役割①

はじめに

社内教育用に話したことを再編している物です。
特にプログラマーに語りかける切り口になっています。
最終的にプロジェクトスタートアップに向けて
チームの意識を同じ方向に向かせることが目的です。
新人も対象なのでかなり当たり前な話も含まれます。

システム開発に関わる人々

システムには様々な人が関わります。
プログラマーだけでシステムが出来上がるわけではありません。

• お客さんと会社をつなぐ営業
• システムを発注するお客さん
• 受注までの手続きに関係する人々
• お客さんの要件をまとめる人
• お客さんの要件を設計する人
• 設計を実現するプログラマー
• プログラムの品質を検証するテスター
• 全体をコントロールするマネージャー

などなど、実に様々な人が関わっています。
そして、それぞれの人達は自分の役割に従って行動します。
この役割どおしがうまくかみ合わないとシステムはうまく出来上がりません。

大きく分けると

大きくはシステムの欲しいお客さんと、システムを開発するベンダーに役割がわかれます。

お客さん

お客さんはその業務のプロです。
どんなシステムが欲しいのか、何のためにシステムが欲しいのかと言った情報はお客さんしか持っていません。
しかし、お客さんはシステムのプロではないのでどう実現するのかは分かりません。

それ故にお客さんから正しく情報を引き出すことがシステム開発成功の最初の入り口です。
お客さんとの対話は、最初にして最大の難関になりますがそれは、それはまた後の話で触れます。
忘れないで欲しいのは、給料は会社から出ているかも知れないが、その給料をだすお金はお客さんから出ていると言うこと。

開発ベンダー

ベンダーはシステムを作るプロです。
お客さんの求めるシステムを作り上げることは、ベンダーしか出来ません。
お客さんは実現の手段を持たないので、どのようなシステムが良いかを提案するのもベンダーの仕事です。

それ故にお客さんはベンダーに期待するのです。
つまりベンダーの持つシステムを作ると言う技術力の対価としてお金を出してくれるわけです。

もうすこし、お客さんを掘り下げるよ

決裁権者

システムの発注の可否の判断権限を持つ人達です。
この人達が首を縦に振らないとシステム開発は始まりません。
本当にシステムを欲しているエンドユーザが稟議書をあげても、納得できる物でなければリジェクトされることもあります。
首を縦に振ってもらうために、営業やＳＥの人達がいろいろと苦心するわけですがここで詳細は割愛します。
でも怖い人達ではありません。
彼等は会社の最終防衛戦でもあるので厳格なだけです。

エンドユーザ

実際にシステムを使う人達です。
エンドユーザも、部長や、担当者などそれぞれもっと細かく分かれますが本来の発注元（部門）と考えて良いと思います。
（ここではエンドユーザをそう定議します。）

システムが欲しい理由はエンドユーザだけが知っています。
それらを提案依頼書(RFP)とまとめたりするための情報ソースもエンドユーザです。

提案依頼書はお客さんが作る物でベンダーが作ることはまずありません。
コンサルやお客さんの情報システム部門などが取り纏めを行います。
場合によっては要求定義書としてまとめてくれることもあります。

いずれにせよ、稟議書にはエンドユーザが何故システムを必要としているのかを元に提案依頼書、要求定義書とともに決裁権者に判定されることになります。
決裁権者はもちろん費用対効果もみますので、お客さんといえど社内政治にたけていないと大変です。
（という場面を何度もみたり、稟議を通すヘルプなんかもしたこともあります）

開発WG（Working Group）

あえて開発ワーキンググループと表現しました。
このシステム開発に当たって、システムの要件のコミットやプロジェクトの旗振りなどお客さん側でシステム開発の窓口となってくれるグループです。
その会社に情報システム部などがあれば、ほとんどの場合はその部署の人が当たってくれます。
但し、情報システム部の人は業務に関しては素人であることが多いです。

そのため、うまくコミニュケーションを取らないと「エンドユーザ　⇔　開発WG　⇔　ベンダー」の情報伝達が滞ったり、正しく伝わらないことがあります。
それは開発WGの人のスキルの問題ではなく、役割の違いから生じる物なのでこの部分のコミニュケーション手段は重要です。
仕様の決定権限を持つ場合も多いので、その仕様が本当にエンドユーザの欲している物と合っているのかを確認してもらわないと、エンドユーザ試験でひっくり返ることもあるので注意が必要です。
なので、仕様のレビューには必ず、エンドユーザにも同席してもらうのが無難です。

もうすこし、ベンダーを掘り下げるよ

決裁権者

もちろんベンダー側にも決裁権者はいます。
受注したくても、不当に安い単価で受注しようとすれば赤字にもなるし、お客さんの決裁権者と同じように厳しい目で見積もりの精査などもします。
社内も、この人達が首を縦にふらないとシステム開発は始まりません。

マネージャー

開発プロジェクトを管理する人達です。
単体のプロジェクトを見る人も居れば、横断的にプロジェクトを見る人も居ます。
名ばかりの人も…ごにょごにょ
いずれにせよ、プロジェクトマネージャがプロジェクトの全体像を把握することになります。

営業

仕事を取ってきたり、仕事の種をまいたりと、システムを開発すると言う部分ではなく活躍します。
営業が居ないとそもそも、開発プロジェクトが始まることはありません。
SE起因で発生するプロジェクトの多くは、既に受注を受けているお客さんからとなるので、営業が新規顧客を獲得しないことには広がりません。
また、いざという時の折衝や、防波堤になってくれる場合もあります。
（そういう営業の人とは仲良くなりましょう）

たまに、んんん…な顧客を捕まえてくることもありますがそこは丁重におことわりしましょう。

SE

お客さんの要件などをまとめる役目を担います。
システムに落とすための論理設計にあたる部分を行います。
お客さんの言葉を、開発者向けに翻訳したり
開発者の言葉を、お客さん向けに翻訳したりと
何かとコミニュケーション能力が要求されるポジションです。
場合によっては、営業と、場合によってはマネージャと密に連携を取る人でもあります。
お客さん、開発者双方から風当たりが強い場合もあり大変なポジションです。

開発チーム

開発チームは、SEのまとめた設計を元にシステムを実現化する部隊です。
お客さんの求める物を、品質を担保しつつ作り上げるのが仕事です。
実現するとは、エンドユーザが使える状態を指すのでもちろん現地での環境構築や、デプロイなど行う作業は開発に留まりません。
場合によっては実現するための研究なども行う必要も出てきます。
実際には開発チームはさらに、役割が細分化されます。

その、細分化された役割の一つがプログラマーです。

さいごに

こうしてみただけでも、プログラマーだけがいればシステム開発は進むかというとそうでないことが分かります。
次回は、さらにベンダー側の開発チームを細分化してみます。

関連する投稿