本記事の背景
IT企業にとってエンジニア社員の育成機会拡充は非常に重要なテーマです。特に私が所属するARIにおいては、社として掲げる「BXdesigner」というコンセプトの実現に向け、技術的な知識や実践力を磨き続けるのは当然のこととして、そんな技術力を活かすための「ソフトスキル・コンセプチュアルスキルの向上」も非常に重要な課題と捉えています。
そこで過去社内外において実施してきた登壇素材を元に、cacumo様のご協力を得てより消化してもらやすい形での言語化を試み社内に研修素材（動画＋記事）として整備するプロジェクトを開始しました。この記事はその第一弾です。
cacumo藤木さんのファシリテーションのおかげで、伝えたいことを十二分に引き出していただくことができました。社外の方にも参考になるのではないかという示唆もいただき、こちらで公開させていただくこととしました。システム開発ビジネスの現場で奮闘されている多くの皆様の、何か少しでも気づきや学びになれば幸いです。
前回（前編）はこちらをご覧ください。
1.情シスの業務範囲
[藤木]
本日はITベンダーが知っておくべきクライアントワークのお作法の続編として、特にお客様の情報システム部門に関することを中野さんにお話しいただきます。よろしくお願いします。
[中野]
こちらの記事や資料では敢えてわかりやすさを優先して『情シス』と表記してはいますが、『情報システム担当部門の方々』と呼ぶ方が適切かもしれません。DXの広がりでデジタル担当部門と情報システム部門とを分ける企業も増えてきましたしね。
まず第一に知っておくべきは、情報システム担当部門の方々の業務領域が、非常に多岐にわたるということですね。
ITやデジタルに関しての企画から導入、運用までかなり幅広く担当されています。
[藤木]
これは広いですね。
[中野]
はい、とても幅広いです。しかも、バックオフィス的な事務作業や、コールセンターなどの特殊な機器の保守なども情報システム部門が担当されている企業もあります。
[藤木]
一般の人からすると、自社の社員に対するヘルプデスクだけを担っているようにしか見えないかもしれないですね。こんなに幅広くやっていることを知る機会はあまりないかもしれません。
[中野]
とにかく知っておきたいことは、会社によって直接担当されている範囲は異なるということなんですよね。すごく極端な話をすると、この右下（バックオフィスのインフラ）だけをお願いされている情報システム部門の方もいます。
先入観だけで『情シス』という組織を捉えてしまうと、大きく誤解してしまいます。情報システムに関する仕事がいっぱいある中で、我々が今対峙している部門の方はどこをメインで担当されていて、どこをサブで担当されているのか、逆にその方が担当されてない部分は誰がやっているのか。地図を塗っていくような見方をする必要があるなと感じます。
2.システム開発時の情シスの役割
[中野]
システム開発における、情報システムの方の守備範囲について説明します。
従来までシステム開発の場合には、一般的に情報システムの設計開発から運用までの範囲を情報システムの皆様とITベンダーとで担当することが多かったと思います。
[中野]
『DX』というテーマが流行る前から、ITとビジネスを分断して考えること自体がITの本質を分かっていないんじゃないかという話はありました。それが『DX』という新しい概念がメジャーになるにつれて、その必要性を理解される企業が増えてきた気がします。今では業務とITを切り離さずに考えることはもはや当たり前ですよね。
[藤木]
最近では情報システムの方々が業務に入っていったり、DXのプロジェクトを担当することも多いということですか？
[中野]
元来情報システム部門の方に対して業務を深く理解することへの期待は大きいと思うんですよね。
私が新人だった25年ほど前は、アプリケーションを内製している企業が多くて、メインフレームやAS400といったハードの上でCOBOLやRPGなどのプログラム開発言語を使って、基幹システムを情報システム部門の方が開発されるのは当たり前にありました。
[藤木]
そうなんですね。
[中野]
当時インフラは基本的にメインフレームなので、ベンダーが全て面倒見てくれて、非常に高額だけど安定していました。代わりに情報システム部門の方はソフトの部分をちゃんと作らなきゃいけないということで、皆さん独学でCOBOLやRPG、データベースを学びアプリケーションを作っていました。
そのうちオープンシステムが主流になり、WebとかRDBなど技術の選択肢が増えました。オープン化されることで競争が起こって総論としては良くなったんですけど、情報システム部門の現場の人たちにとっては、覚えることが増えて技術的負担は増えたと思います。その結果、それぞれの技術的な部分はベンダーに頼らざるを得ない状況が起こりやすくなってしまったかなと思います。
[中野]
経営者からすると、自社のIT部門には自分たちでしかできないことをやって欲しいじゃないですか。なので、実際に決めたことをITの形に実装したり、運用オペレーションするところは社員じゃなくてもいいという判断が増えてきたのは自然な流れかなぁとは思います。かつてはITへの期待の中心は、事務業務の効率化が中心だったことも一端としてあるかなと思います。
ただ今はITが事業やサービスに直接的に及ぼす影響も大きくなりました。先が見えない不確実性への対処が大前提で「アジャイルだ」みたいな話になっている。全てベンダーに言わないとシステムを変えられないというスピード感が問題になって、今改めて「内製化」という話になっていると捉えています。
でも情報システム部門は技術的なバックグラウンドを持った人ばかりじゃないですよね。その中で技術がどんどん新しくなるし、情報システム部門としての幅広いミッションをちゃんとやり遂げろと言われる。それはハードルが高いですよね。
[藤木]
そうですね。業務の種類もいっぱいありますしね。
3.情シス組織の形態、その種類
先入観で判断しない、企業の数だけ情シスの形がある
[中野]
各社の情報システム部門の組織形態について説明します。
この話はいろんな意見を生むと思っています。情報システム部門のあり方は千差万別で、企業の数だけ情報システム部門の形があると言っても過言ではありません。トップのITに対しての重要性だったり、理解度だったり、過去からの流れ、CIOやCTOのようなITを任せられるような人がいるかいないかとか、様々な要素が絡んでIT組織の形態が決まってくると思います。
[藤木]
先入観を持たずに、どんな組織なんだろうと確認しなきゃいけないですね。
[中野]
そうなんですよ。企業によって結構違う。特に大手企業は、IT部門がグループ会社や子会社みたいな形になっているケースもあるし、ホールディングス側でITを全部統括する企業形態も珍しくないです。まず、クライアントさんのなかでITに関する機能がどう分担されているのか、大枠に関心を寄せたいですね。
組織図と実態が乖離していることもあるので、それも注意したいところです。組織図上はBになっているんだけど、実態はAなんですとか、実は逆なんですとか。こっちの事業部はこうなんだけど、こっちの事業部はこうなってないとか、そういうこともあります。
[藤木]
資料の表はどう見たら良いですか？
[中野]
「①集権型A」は、ITに関することは全て本社の情報システム部門が担当される形態です。一定の企業規模になるまでの基本形と言えるでしょう。情報子会社などはありません。
一方「②集積型B」は情報システム子会社と役割を分担した形態です。ITに関する企画業務は本社の情報システム部が担当され、実際の開発・運用は●●システムズのような子会社が担当します。
「③集権型C」は、全体の投資予算や大きな流れについては本社が方向性を示しつつも、企画的なことも含めてIT実務を機能会社に託します。役割分担というよりも、グループ内でのシェアードサービスというかアウトソーシングに近い状態といえるかと思います。
なお注意したいのは、いづれの形態でも実務をどこまで内製しているかは別の議論であるということですね。BやCの形態においても実務の多くをベンダーに依頼しているケースは少なくありません。あくまでもこの形態の違いは、ITに関する実務責任を企業法人としてどの法人や組織が担うかという整理の分類です。企業におけるガバナンスや組織設計におけるパターンと捉えていただければと思います。
[中野]
連邦型は、製造業のような会社や地方拠点が多い会社に多く見られます。本社で統制やガバナンスをかけているけど、基本的な各システムは現地にいるシステム部門の人が運用しているケースですね。
「④連邦型A」は、例えば製造業の経理や人事、営業、受発注などの本社系のシステムと、工場で使う制御系やCADなど工場特有のシステムでは性質が違います。工場の情報システム部門は本社と独立した形で工場組織の中に置かれるケースがあります。
「⑤連邦型B」は少し細かく分かれます。大きな会社になると事業部単位でそれぞれの規格があり、アウトソーサーがいたり、グループ子会社があります。ホールディングスの全体と、各事業部のIT企画のようなお財布を持っている部門と、オペレーションやデリバリーをやっている部隊が違っている形態です。こういったこともあり得ます。
[藤木]
ITベンダーはこの全てと関わるんですか？
[中野]
基本的には担当するフェーズによって出てくる人が変わってきます。ほとんどの場合は、情報子会社の人が窓口になるんですけど、必ずプロジェクトに担当の事業部もしくは本社の人が入るから、その人を意識しつつ目の前の情報子会社の担当の人をうまく立てるということになりますね。
[中野]
「⑥分散型」は正直あまり聞かないですが、IT自体を完全に事業部に渡している形態といえるでしょう。
[藤木]
分散型にすることも出来るということですね。
[中野]
あり得ますけども統制を取りづらいのが難点ですね。例えばチャットツールとして部門AではSlack、部門BではTeams、部門CではChatwork、みたいなことが起こり得ます。
[藤木]
立ち上げたばかりの会社が急に大きくなったときに出てきそうな問題ですね。
[中野]
スピードを優先するのか統制を優先するのかみたいなところでしょうね。
4.情シスとRFP
RFP（提案依頼書）とは？
[中野]
情報システム部門の方の『RFP（提案依頼書）』との関わり方を説明します。
企業の情報システムを扱うときに、システムを作るという行為と、作るモノを決めるという行為が大きな分岐点になるんですよね。何を作りたいのかを決めてもらわずにモノを作ってしまうと、手戻りが大きくなってトラブルプロジェクトになります。
なので、一般的にベンダーを選ぶという名目の中で、自分たちの社内で作るべきモノを整理することが業界的にはよくありました。これまでだとRFPはベンダーへ喋るだけで、ベンダーさんが提案して初めてドキュメントになるみたいな。言語化・整理を含めて、ベンダーさんに助けてもらうケースも多かったと思います。
最近ではベンダー出身のCIOさんとかも増えてきて、ユーザー企業のリテラシーも上がってきました。最低限、自分たちがどういうモノを必要としていて、優先順位をどう置くのかとか、どういう方針で作ってもらいたいのかを自分たちで資料にまとめないといけないということが一般的になってきていると思います。その提案してもらいたいものをまとめた資料のことを『RFP（提案依頼書）』と言います。
100点満点のRFPとは、現実には
[中野]
ベンダーが知っておくべきことは、RFPとは本来担当の情報システム部門の方が簡単に書けるものではないということです。業務部門の方や情報システムに関係する方たちの間でしっかりコンセンサスが取れていて、システムの業務要求までカバーできている状態。「こういう業務要求を満たしたいから、こういうふうに作ってほしい」となっている状態が、100点満点のRFPだと思います。
ただ時には、ITの部門の方がアテで業務要求を書いていたり、承認されてないRFPになってたりすることもあります。RFPは本来ユーザー企業内で業務部門も合わせて完全にコンセンサスを取られているべきものですが、必ずしもそうなっていないこともあると。というよりむしろやりたいこと、やるべきことがまだ明確になっていないこともありえます。
RFPが出てきた段階でまだ明確になっていないことも受け止める。それを責めるわけじゃなく、理解することがはじめたいですね。今は技術面もビジネス面でも選択の自由度が多く要求を固めることは非常に困難です。提案の段階でその業務要求が本当に吟味仕切ることは本当に難しい。そういった事情にも寄り添い、本当にその要求が適切なのかどうか。RFPからそうした迷いを感じ取れたとしたら、提案の前に現場部門の方も交えてすり合わせることを提案することも効果的だと思います。
RFPのコンセンサスが現場部門の方と取れているかを質問してみて、「時間がなかったから、これは仮説なんですよ」などと回答があったら、「これで業務が回るのかどうか最初に業務部門の方たちとディスカッションした方がいいですね」みたいな。あまり先方を責める文脈を作らずに提案に繋がっていけばベストです。
RFI（情報提供依頼書）とは？
[中野]
次に『RFI（情報提供依頼書）』について説明します。さっき説明したRFPって内部事情が絡んだ要望も含まれるので、ユーザー企業は無造作に幅広くバラマキたくないんですよ。
あと、いろんな会社にRFPを投げたら、いろんな人の提案を聞かなきゃいけないのでそれにもコストがかかります。そこで、1次審査、2次審査みたいな方法でベンダーを選定していくのですが、その1次審査で使われるのがRFIです。
RFIでは「会計システムを刷新しようと思うんだけど、御社はERPを入れますか？それとも手組みですか？」「御社の会計システムに関する実績を教えてください」という情報提供をベンダーへ依頼します。RFIを受け取ったベンダーは、精緻な見積もりやスケジュールよりは、大体どのくらいの期間がかかるのか、この会社規模だとどういうソリューションが良さそうか、などを回答します。
RFIはRFPを渡す先を決めるための予選会みたいなもので、RFIでいい内容を出せたところに個別にRFPを送ります。
5.情シスが好むベンダー
情シスの関心ごととは？
[中野]
ベンダーにとって情報システム部門の方とのコミュニケーションは不可欠です。ただそのときに、部門に”システム”という名前が付いているから、相手の方もエンジニアリングな人だと勘違いしてしまうことは要注意です。名前に踊らされちゃいけなくて、情報システム部門の方はむしろ”エンジニアじゃない”と思った方がいいと思います。
資料はアプリケーション領域に限定した例ですが、「どれくらいのお金がかかるんですか？」「スケジュールはどうなんですか？」「セキュリティの面は大丈夫ですか？」とか、担当者はITの要素以外の観点に関心があるわけですよ。もちろん中には技術に長けた方もいますので、アーキテクチャや技術選定に関心を寄せてくれる人もいます。多くの場合は「保守費用は見積もり入りますか？」「事例はあるんですか？」「どれぐらい在庫が減りますか？」とか、そういった目線のやり取りを期待してますね。
[藤木]
技術よりビジネス寄りの関心が強いんですね。
[中野]
そうなんです。特にアプリケーションについては、情報システム部門の役割の一つに営業や業務などの現場の方とシステムエンジニアを繋ぐ役割があります。会社が違うし、窓口としての役割として場繋ぎをしなきゃいけない。これは間に立つ以上やらなきゃいけないんだけど、そのときに中身まで翻訳するのは結構大変じゃないですか。
適切で高品質な技術を提供できることは大前提として、それをビジネスの言葉に翻訳する作業を楽にしてあげると、ベンダーとして頼りにされるんじゃないでしょうか。例えばレンジでチンするだけで持っていける状態にしてあげる。とりあえず材料だけ持ってきて「調理はおまかせします」だと相手に手間がかかっちゃう。ベンダーとしてはビジネス観点で説明できるように、資料の中の言葉の使い方とか気を付けたいですね。
顧客が求めているものは何か？
[中野]
全般的にITベンダーに発注する顧客は、頼んだシステムが出来上がることは当たり前の話として捉えていることが多いです。我々からすると大事なことで、期日通りにシステムを作ることを期待されていると思ってしまいます。お客さんからするとプロに任せているので「作ってもらって当然」という感じです。
例えばラーメン屋さんに行ってラーメンとチャーハンを頼んだら、ちゃんとそれが出てくるのが当然ですよね。出てこない可能性はあまり心配しないじゃないですか。だいたい数分でラーメンとチャーハンが出てきます。お客さんからすると、頼んだものが出来上がることは大前提で、それを食べて美味しいかどうかとか、急いでるのに悠長に作られても困るとか、チャーハンが来てからラーメンが来るまでの間が空いて冷めたとかが気になります。
システムに話を戻すと、お客様としてはシステムをどうやって仕事の中で使い切るのか、システムを変えることでどう業務を変えるのかに関心があります。ベンダー側もそれを当たり前に思わなきゃいけないですよね。
6.情シスが扱う予算
[中野]
次に予算の話です。通常の事業会社だと年度で予算を持っていますよね。欧米の会社は12月に決算というケースが多いですけれども、日本の場合は3月末が決算という会社が多いですよね。
僕が若い頃は、恥ずかしながらお客様は年度でいろんなことが決まっていくことをあまり知らなかったんですよ。だからシステム開発の追加の話が出てきたときに「今期は予算取ってないんだよね」と言われてもピンと来ていませんでした。投資対効果が見えるならなぜすぐにやらないのだろう？と。
会社は年間で動いていることがほとんどで、期初より前に予算や計画が作られています。例えば、4月1日始まりの会社は、大体12月から2月ぐらいまでに来期の計画を取りまとめます。大企業はもっと前倒しになります。なので、秋から年末ぐらいに4月以降の計画や予算取りが始まって、ベンダーに対して見積もりを取る仕事が増えます。今まさにそういう時期です。（12/23 収録）
年末年始にご挨拶へ行くのがなぜ重要かというと、4月以降の予算を検討するタイミングと被るので、「見積もりを取れてないテーマがあるんですけど、今から検討してもらうことできますか？」みたいな話がご挨拶の中で起こる可能性が高いからです。なので、「年末年始は積極的に接点を持とうね」と言われている会社が多いのかなと思います。
もっと言うと、担当するクライアントの予算編成のスケジュールをちゃんと聞きましょう。いつ情報収集して、どの会議体でどの時期に正式にオーソライズされるのかを聞いておく。大きなお客様を担当している営業の方や担当のSE、特にマネージャークラスにはとても重要なことです。
[藤木]
お客様を助けるためのことなので、聞いても嫌がられないですよね。
[中野]
お金のことだから聞くのは忍びないと思うかもしれませんが、クライアントの方々からすると、当たり前のビジネスルールです。予算編成のスケジュールや予算枠をちゃんと聞くことは全く失礼に当たりません。
決裁稟議とは？
[中野]
決済稟議という仕組みがあることも知っておく必要があります。大手企業においてはルールがあって、金額の大きさによって決裁できる意思決定者が異なります。ITに関する何千万円の金額は、重要な会議の中で承認することが多いです。ほとんどの会社が役員会などを通さなきゃいけません。そこで承認してもらうために、どういった資料を作らないといけないのか、その根回しとして誰にOKをもらわなければいけないのか、ということを聞いておく必要があります。
7.情シスの働き方や環境など
[中野]
これまで挙げたこと以外に知っておいてほしいことを紹介します。
情シスの立場
「情シス」の立ち位置や立場の強さは会社それぞれ
[中野]
情シスが非常に力を持っている企業もあれば、事実上のオペレーションだけを担当している企業もあります。何をどうやるのかは、経営陣や他の事業部門が決めているところもあります。なので「情報システム部門はこうなんだ」という先入観を持たないことが大事だと思います。
情シスの専門性とバックグラウンド
「情シス」はみんなエンジニアになりたかったわけではない
[中野]
情報システム部門の方はエンジニアだと思われがちなんですけれども、エンジニアという気持ちで情報システム部の仕事をしていない人もいます。なので、情報システムそのものに対してのリテラシーがそこまで高くないかもしれないです。
「情シス」はみんなITの専門家というわけではない
[中野]
みんながITの専門家というわけではありません。なぜかというと、製造業や小売、金融などメインの商売があって、メインの商売の営業や商品開発がやりたくて入社しているのに、ITの部門を担当することになってしまい、「マジで？」という感覚の方も比較的多いです。
日本の会社は、ジョブローテーションがあるので、その一環としてITを経験します。昔は人事が出世のポジションだと言われてましたが、最近はITが重要だから優秀な人に経験させる会社も多いです。いずれにしても全員がエンジニアのバックグラウンドを持っている人とは限らないし、そうじゃない人の方が多い。
「情シス」は自社の業務とシステムのことを何でも知っているわけではない
[中野]
お客様はお客様の会社の事をなんでも知っていると思いがちですが、自分に置き換えてみて「あなたはどうですか？」。10人20人の会社は別ですけど、数百名以上の規模の会社で他の部門のことや会社全体の事を説明できるエンジニアの方は少ないと思うんですよ。これはお客様も一緒なんですよね。だから「お客様に聞けば、何でも答えてもらえる」というのは幻想ですよ。システム化の目的についても100％は理解できていない場合もあります。
お客様も会社のことを、よく分かっていないという前提でお付き合いをしていく。分からないことを責めない。「そうですよね、分からないですよね。聞いていただけますか？」「どういう方に聞くのが効果的ですか？」という姿勢でコミュニケーションしてあげると、先方はやりやすいと思いますね。
情シスのプロジェクトへの関与
PJにアサインされている担当者の時間はいつでも抑えられるわけではない
[中野]
プロジェクトに対しての向き合い方も人それぞれで、前向きにアサインされた人もいれば、他にやりたかった仕事があったのに、天の声でアサインされた人も少なからずいますよね。なので、お客様側の社員だからと言って、プロジェクトの成功に100%向き合っているわけではありません。自分のモチベーションが常に安定していないのと同じです。
むしろお客様は100%でフルスイングしてくれない方が多いですよね。いろんな仕事を少ないメンバーで抱えているので。そういう中でどれだけプロジェクトにコミットしてもらうか、これは提案書やプロジェクト計画をキックオフのときに握らないといけない。最低0.5人月を使っていただくとか。「担当を出せないなら、このプロジェクトは無理です」と勇気を持ってベンダーが言うことも大事だと思います。
情シスを取り巻くルールや制約
J-SOXやISO、各種ポリシーなど無条件に守るべき制約が結構ある
[中野]
情報セキュリティポリシーや内部統制、予算編成スケジュール、会議体など、お客様の社内には必ずたくさんのルールがあります。お客様にとってそのルールは守るべきものなので、ベンダーとしてはまず受け止めてほしいです。
情シスとの信頼構築のポイント
お客様も当然組織の一員、保身もするし評価も気にするのは当たり前
[中野]
最後に、お客様もサラリーマンだからプロジェクトを失敗させたくないわけですよ。なので、どうやったらお客様を成功させられるかと考えて動く、失敗しないように配慮してあげることも一流のクライアントワークのビジネスパーソンだと思います。お客様に手柄を取らせてあげるっていう感覚ですね。これは特にマネージャークラスのメンバーにはとても重要です。
[藤木]
残念ですがそろそろお時間ですね、ありがとうございました。
[中野]
当たり前の話に聞こえてしまうんですけど、「確かにな」と気づくきっかけになれば嬉しいです。僕も「そうだな」と思いながら話しました。本日の内容は以上です。
[藤木]
こういったことを早めに気付けると仕事しやすそうですね。本日はありがとうございました。
仲間を募集しています！
ARIではエンジニア・ITコンサルタント・PM職全方位で仲間を募集しております。
カジュアル面談、随時受付中です！
ご興味ある方はこちらをご覧ください。