システム開発を学びたい!ビジネススキルを身につけたい

システム開発の間違ったユーザー・社内SE・ベンダー役割分担と対策

システム開発を学びたい!

システム開発におけるユーザー・社内SE・ベンダーの役割の違いを教えて

と言った疑問に答えます。

この記事を読むことで、社内SEがプロジェクトを進める際にどんな役割分担でプロジェクト構成すべきか?のフレームワークを構築することができます。

以下間違った体制図ですが、こんな体制図を見て、「これおかしい!」と言えるようになります。

画像に alt 属性が指定されていません。ファイル名: image-13-800x462.png

本記事では体制図を中心に解説しますが、成果物におけるユーザー・IT/ベンダーの役割の違いを理解したい方は、こちらの記事を参照ください。

✔記事の信ぴょう性

✔記事の信ぴょう性

kato
kato

SIer SE→現、一部上場企業社内SE(IT歴15年以上)。過去、基幹システム開発~グローバル16拠点への導入等実績。社内SEの為の情報サイトIT Comp@ss運営者。社内SE講師としても活躍。自身の社内SEとしての学びや経験を元に情報をお届けします。


※当ページのリンクには広告が含まれる場合があります。

システム開発に関連する登場人物

システム開発で登場する登場人物は以下です。

PM(プロジェクトマネージャー)
プロジェクト全体を統括

PL(プロジェクトリーダー)
プロジェクトマネージャーの元実際のプロジェクト(特定領域の場合もあり)を推進

PMO
プロジェクトの推進を支援

開発ベンダー
開発を発注をうけ実際の開発を実施

社内SE
自社内に在籍し、主に開発ベンダーと業務ユーザーの間を取り持ちシステム開発を推進

業務ユーザー
システム化するための要求・要件を洗い出し。導入に向けた業務的な準備 例 トレーニング・物理的準備・契約等々

まずは、至極一般的な基礎の体制図から解説します。

システム開発体制図をIT関係者のみで構成した場合

以下の様な構成が一般的です。
・PMの下に、PLが存在
・プロジェクトのサイズによりますが、PMOが補佐をします。
・その下に各領域ごとの開発領域が存在
・その更に下に開発領域のシステムを担当するベンダーがはいります

特に違和感はないと思います。

業務ユーザーも加味したプロジェクト体制図

社内SEがシステム開発を進める際には、実際にはシステム開発だけではなく、業務・サービスも開発プロジェクトに参画します。以下の様な図になります。

業務の領域A・Bの部分を業務ユーザーが担当します。

これも違和感はないと思います。

場合によっては、業務PLが業務を取りまとめ、IT側もPLが存在し、それぞれがPMに報告の対せずでもきぼよよってはありです。

間違った体制図と解決する為の勘所

画像に alt 属性が指定されていません。ファイル名: image-13-800x462.png

システム開発に関連する役割・登場人物はご理解いただけたと思います。ここからは、システム開発を推進する際に良く発生する注意点を以下の観点で解説していきます。

上記のサンプルを使いの本当によくあるNGな体制図を使いながら解説します。

スムーズなシステム開発に、組織・プロジェクトのレポートラインを混同しない

システム開発を推進するときに、役割で混同してしまうのが組織としてのレポートラインと、プロジェクトのレポートラインを混合してしまうケースです。

スムーズなシステム開発を目指しこの注意点の理解が必要です。

赤が本当にプロジェクトに参画している人
青は実際には参画していながい、名前だけ記載のある人
を表しているとします

プロジェクトですので、実際の組織の上司・部下の関係と依存せず構成すべきです。

しかし、企業文化によっては上記の様ないびつなプロジェクト構成を見かける場合もあります

この場合、係長の二人は組織のレポートラインとプロジェクトのレポートラインが混同してしまい作業が肥大化する可能性があります。

本来は、以下の様にシンプルな体制図であるべきです。

そして、組織としての報告をプロジェクトとは別に行い推進することが望ましいです。課長職の人が別に係長にレポートしてもOKです。

課長の人は、プロジェクトとは全く別で、組織のレポートラインに従い以下のようにプロジェクトとは別で報告をすべきです。

プロジェクトを上手く進めるための体制図の勘所

システム開発プロジェクトは、システム開発だけじゃない
これからのシステム開発|変化する社内SE・業務ユーザーの役割

システム開発プロジェクトは、システム開発だけじゃない

多くの場合、なぜかシステム開発はシステムを作るだけがフォーカスされがちです。

しかし、システムは構築したいサービス・業務の一部の仕組み=システムであり、それが全てではありません

したがって、システム開発とサービス開発がセットであるべきです。。。

ですが、業務ユーザーからシステムに全て丸投げなんてのは、よくあることです。

社内SEとしては、この【システム開発とサービス開発】両方セットが必要な事を理解させる必要があります(社内SEの仕事で骨の折れる仕事ですが大事な要素です。)

後ほどご紹介する2章-5の【システム要件定義の進め方とは?】で更に詳しく図解入りで解説しています。

これからのシステム開発|変化する社内SE・業務ユーザーの役割

ここまでは、至極一般的なシステム開発の役割の話をしてきました。ここまでの理解もシステム開発する際にどんな役割の登場人物が必要か?の理解につながります。

もう一つ理解が必要な視点が、【これからのシステム開発・業務ユーザー・社内SEの役割】です。

一昔前のシステム開発といえば、

業務ユーザーから頂いた仕様に基づき社内SE・情報システム(もしくは外部ベンダー)がプログラミングなどを行いシステムを作り上げる工程

でした。

IT技術の進展とビジネス・生活への浸透と共に状況も変化しています。

現在のシステム開発とは

システムは、自社内で作る時代から、使う時代に変化

この変化をエコシステムの活用が進んでいると表現できます。

エコシステムとは?

本来は生態系を表す用語ですが、IT業界で使われるエコシステムは、クラウドサービス・データセンターなど広く経済でシェアして使われる仕組みを活用する事を指します。

自社内単体の視点ではなく、経済視点でとらえ【エコ】な【システム】の活用と認識ください。

エコシステム活用のメリット

このエコシステム化によりビジネスにおいては、自社の強みに直結しないIT部分は低価格でシステム化し、必要な部分に資金とリソースを集中できるといったメリットが生まれます。

例えば、中小企業が自社でクラウドを立上げるよりは、使った方がコスト・性能の面で圧倒的に有利です。

ビジネスに必要ではあるが自社の強みに直結しない部分をどんどん様々なITサービスを活用する時代に変化しています。

この変化により、

システム開発と業務検討の垣根があいまいに(良い変化)

このエコシステム化によりシステム開発はより業務を検討し、業務ユーザーでもシステムに関して検討をする必要が出てきています。

業務ユーザー目線
以前は社内SEにお願いしていたシステム導入が、開発を伴わない場合そのまま業務部門が推進する事も可能です

社内SE目線
業務ユーザーが事業を企画していた時代から、様々なシステムソリューションで業務改革を提案・推進できる時代に変化しています

つまり、エコシステムというITの加速により、システム導入の価値が作る事から急速に、システムを使い事業価値を生み出す事に変化していることになります。

これからの、時代の社内SEは、何が作れるか?ではなく、求められるのは何を創れるか?です。

社内SEとしては、様々な情報にアクセスし整理し活用できる能力が求められうようになります。

システム開発の間違ったユーザー・社内SE・ベンダー役割分担と対策まとめ

ユーザー・社内SE・ベンダーの役割分担の違いは、
・ユーザー:サービス開発
・社内SE:システム開発推進
・ベンダー:システムを実際に開発
でした。

しかし、現代のエコシステム化・情報システム・業務ユーザーに求められる役割の変化によって、業務ユーザー・社内SEがそれぞれの領域からお互いにはみ出しシステム開発を推進する事が求められています。

この変化に対応できない社内SEは価値を失っていく可能性があります。

タイトルとURLをコピーしました