DXの一丁目一番地である「データ活用」を進めるにあたっては、全体感をとらえたアーキテクチャ設計と内製化が欠かせないのではないか──。
こんな仮説のもと、ユーザー企業とコンサルタント、プラットフォーマーがそれぞれの視点から意見を交わすイベント「『アーキテクチャ』と『内製化』でデータのビジネス活用が激変 先駆者に聞く、劇的なビフォーアフター」が開催された。
本イベントの前半では、国連UNHCR協会 CIO カール・サンドバーグ氏が「内製化で脱データのサイロ化プロジェクトを成功させるまでの道のり」と題したプレゼンテーションを行い、同氏が国連UNHCR協会においてSalesforceの導入プロジェクトを契機にデータ統合基盤の構築に挑んだ背景や経緯を紹介した。
続いてインフォマティカ・ジャパン プロフェッショナルサービス本部 本部長 湯澤弘幸氏、同社 セールスコンサルティング本部 第二セールスコンサルティング部 プリンシパルセールスコンサルタントの中島良樹氏、そして AnityA 代表取締役 中野仁氏を加えた4人によるディスカッションが行われ、講演の内容を振り返りながらデータ統合基盤の重要性や、その構築・運用の体制を内製化することの有用性について意見が交わされた。
これらの内容は、別途「脱・SIerへの丸投げ」で組織とビジネスはどう変わったのか──国連UNHCR協会のサンドバーグ氏に聞く劇的な変化」と題した記事で紹介しているので、そちらを参照されたい。
本稿では本イベントの後半に行われた、イベント参加者から寄せられた質問に登壇者がその場で答える質疑応答の模様をお届けする。
内製のための人材をどう確保するか
中野氏 イベント参加者の方から「内製化の体制を構築する際、内部人材の育成と中途採用のバランスをどうとればいいでしょうか?」という質問をいただいています。
サンドバーグ氏 これはとても難しい問題ですね。ちなみに私が国連UNHCR協会に入ったときには、もう既にチームのメンバーは決まっていたのですが、新たに知り合いの優秀なアーキテクトを中途採用したいと考えていました。
しかし国連UNHCR協会は非営利団体で高い給料を払えませんから、その人の給与水準に見合う待遇を用意することができずに、結局、直接雇用することはできませんでした。そこで仕方なく、知り合いの会社を通して「表向きは外部のSI要員」として来てもらうことにしました。このように、私たちのような非営利団体は、中途で優秀な人材を雇用するのはなかなか難しい面があります。
ただし、中には日本を代表する大メーカーに勤めていながら、中途採用で入ってきた優秀なエンジニアもいます。その人は給料よりも、非営利団体で働く社会的意義の方を優先して、自ら応募してきてくれました。また前職は大企業だったので、自身が所属する部署の担当製品しか扱えなかったのですが、ここに来てからはいろいろな製品や技術に触れることができるようになり、本人もとても楽しそうに仕事に取り組んでいます。
中野氏 私も大手SIer出身なので、「自由に技術に触れることができる楽しさ」というのは、とてもよく分かりますね。ちなみに私はこれまで、IT製品を導入する際には、たとえ高価でもなるべく先進的かつメジャーな製品を選ぶようにしてきました。その理由の1つは、それを扱うエンジニアのモチベーションが上がりますし、キャリアの面でも有利になるからです。そうした製品の多くはライセンス費用も比較的高いのですが、人材の雇用や育成の効果を加味すれば十分に元を取れると考えていました。
サンドバーグ氏 それは内部の人材を育成する上でも重要な観点ですよね。中途で優秀な人材を採用するのはもちろん大切なことですが、私は基本的には「中にいる人たちを育成してどんどんチャンスを与えていきたい」と考えています。
例えば、最近「Udemy」というオンライン教育サービスを契約しました。まだ日本語コンテンツの数は多くないのですが、英語でもある程度内容は理解できますから、こうしたサービスを使ってメンバーがどんどんスキルアップしてくれることを期待しています。
中野氏 こうした教育サービスが普及してきたおかげで、良質なコンテンツに安価にリーチできるようになりましたね。昔と比べると、教育に掛かるコストは本当に低くなったと思います。
内製に理解を示さない上司の説得方法は
中野氏 「ITを理解していないのに、コンサルから聞いたというだけで『内製は悪だ!』と思っている人をどう説得すればいいでしょうか?」という質問もいただいています。企業の意思決定者の中には、これまで長年続けてきた「SIerへの丸投げ」以外のやり方を知らないがために、内製化になかなか理解を示してくれない人も多いですよね。
サンドバーグ氏 ただやっぱり、そういう人たちを粘り強く説得するのも大事な仕事の1つだと思います。そのための材料の1つは、やはりROI(Return On Investment:投資利益率)です。システムを導入することで、具体的にどのような課題が解決し、それによってどんな効果が得られるのかを、内製化に反対する人たちに根気良く説明していけば、少しずつ理解が得られるようになります。
実は今、セキュリティ対策を強化するためにSOC(Security Operation Center)の組織を立ち上げたいと思っているのですが、コストを考えると、実際には自分たちだけで十分な人材や体制を用意するのは現実的ではありません。
そこで、ほかの非営利団体と共同でSOCを運用するような体制が取れればコストもかなり抑えられるはずだと考えて、そうしたやり方のメリットを意思決定者に説明して理解を得ようとしているところです。
このように頭を使って、さまざまな工夫を凝らしながら関係者を説得していくことが大事だと思います。ただこういうやり方は、どうしても時間はかかってしまいますけどね。
中野氏 プレゼンテーションの中でも、カールさんの上長に当たる意思決定者の方が理解のある方でとても助かっているという話がありましたが、もし仮にその方に「内製だのアジャイルだの、お金が掛かるだけじゃないか! 今まで通りSIerに丸投げしろ!」と言われたらどうしますか?
サンドバーグ氏 どの組織でも同じだと思いますが、やはりある程度高い地位にいる方は、新たな責任やリスクを背負い込むことを嫌う傾向が強いですよね。なので、相手のそういう気持ちを汲んで、「責任は私がとります」「うまくいったらあなたの成果だとアピールします」と言い続け、「その人の立場を決して危ういものにはしないことを約束すること」で協力してくれるようになりました。
内製化を推進するために「避けるべきこと」は
中野氏 次に「内製化すべきか、外注すべきかを判断する際のポイントはどこにあるのでしょうか?」という質問が来ています。
サンドバーグ氏 やはりRFP(Request for Proposal:提案依頼書)を出して実際にベンダーやSIerから見積もりをもらって、それらを内製化コストと比較検討した上で判断する必要があると思います。私たちは、場合によってはベンダー・SIerから「丸投げした場合」「内製支援だけを依頼した場合」の2通りの見積もりを要求することもあります。
また、内製化のコストを見積もる場合、出来合いのクラウドサービスをなるべくカスタマイズせず、標準機能だけで構築することを念頭に置いています。実際、これまでの経験を踏まえると、大抵の要件は標準機能だけで8割方は実現できます。しかしこれをSIerに丸投げすると、大抵の場合はすべてをカスタマイズで実現しようとするので、莫大なコストが掛かります。
中島氏 そうやって標準機能だけで自社の要件をカバーできる製品を「探す努力」がとても重要だと思います。そうやって、さまざまな製品を比較検討していく中で知識も深まっていきますし、内製化のモチベーションも上がっていきます。
ただ、弊社の製品もそうですが、新たな製品を導入する際、お客さまが独力でゼロから内製化を推進するのはかなりハードルが高いので、まずは私たちのようなベンダーやSIパートナー企業の助けを得ながら開発のルールや作法などを吸収して、その内容を消化した上でお客さま側でどれだけの部分を内製化できるか判断することをお勧めします。
湯澤氏 ちなみに私はカールさんの意見にまったく同感で、なるべくツールの標準機能を活用して、あまり「外れたこと」をやらないようにした方が結局は製品を長く使っていただけますし、お客さま側でも製品に関するナレッジが貯まりやすくなると思います。
実際に弊社でも近年では、お客さまに標準機能をきちんと使いこなして有効活用していただけるようなサポート活動を心掛けています。やはり一時の思いだけで標準機能から大きく外れたことをやってしまうと、結局は後になって組織の足を引っ張ってしまうことになりがちですね。
中島氏 お客さまの内部で標準機能のナレッジを蓄積できれば、その後要件に変化が生じてシステムに変更を加える必要が出てきた際にも、自分たちで短期間のうちに対応できるようになりますからね。
中野氏 私がコンサルタントとしてお客さまのシステム構築プロジェクトの支援に入る際にお勧めしているのは、これから導入しようとしている製品の導入・運用に関して豊富な経験と知見を持つ人とアドバイザリー契約を結ぶことです。
基本的には自分たちで構築や運用を行うのですが、何か分からないことや問題が出ててきた時に、そのアドバイザーの方に質問したりアドバイスを仰げる状態を作っておけば、その製品に特有の落とし穴をうまく回避しながら内製開発を進めていくことができます。
内部で後継者を育成するにはどうすればいいのか?
中野氏 「内製化以前に、システムの将来像やあるべき姿を描ける人材が社内にいないのですが、どうすればいいでしょうか?」という質問もいただいています。これは人材育成や後継者計画、いわゆる「サクセッションプラン」の話にもつながってきますね。
サンドバーグ氏 サクセッションプランは本当に難しいですよね。私も自身の後継者を探すために、社外の優秀な人にいろいろと声を掛けているのですが、どの人もやはり今いる組織で重要な地位に就いていたり、技術者としては優秀でも組織マネジメントに興味がなかったりと、なかなかうまく話がまとまらないのが実情です。
中野氏 やはりそう簡単に適任者は見付かりませんよね。
サンドバーグ氏 そのため、今は内部で育成しようとしています。ただし1人の人にすべてを任せるとなると、責任が重くなりすぎてハードルが一気に上がってしまいます。幸いなことに私たちのチームには、ビジネスについてはさほど興味はないものの極めて高い技術スキルを持つメンバーと、技術については詳しくないもののビジネスに関しては豊富な知見を持つメンバーがそれぞれ1人ずついます。そこでこの2人がタッグを組んで、二人三脚でリードしていけるような体制を目指して、現在、育成に取り組んでいます。
中野氏 実際のところ、人材がいないからといって外から採用しようと思っても、ちょっとやそっと給与額を上げるぐらいでは優秀な人材はなかなか採用できません。
私も最近では、外部採用による人材確保にはあまり過度な期待を抱かないようにしています。それに、よくよく社内を見渡せば、高いポテンシャルを持つ人材はいるんですよね。そういう人材を見つけて、中長期的な視点に立ってじっくり育成していけば、後継者は育つはずです。
ただし、そのためには決して急がず、成長のリードタイムをなるべく長く取る必要がありますね。「1年で立ち上げろ」ではなく、「2、3年かかってもいい」「1人では重荷になるのであれば、2人で役割分担をしながら成長していってくれ」というふうに、長い目で見ながら育成に取り組んでいくしかないのかな、と最近では思うようになりました。
湯澤氏 私も地道に内部のメンバーをレベルアップさせていくしかないのかな、と思います。特に弊社が扱っているデータ基盤の領域は、基盤製品そのものだけではなくアプリケーションも絡んできますし、それこそお客さまのビジネスの将来構想について上層部の方々と話す機会もありますから、技術だけでなくさまざまな領域の知見や経験が求められます。従って教育も大事ですが、実地でさまざまな経験を積む必要があります。
中島氏 そうですね。本当に幅広い分野をカバーしなければいけないので、やはり現場の経験を通じて育成していくというのがどうしても基本になりますね。
「開発のムダ」を排除するために欠かせないこと
中野氏 最後に、「チーム内の情報共有やナレッジマネジメントをうまく運ぶにはどうすればいいでしょうか?」という質問が来ています。
サンドバーグ氏 以前、証券会社の情報システム部門で働いていたころ、ある優秀なエンジニアにストラタスの無停止サーバの運用を任せていたことがありました。そのエンジニアはもともとピアニストだったのですが、本人の素養と熱意の高さを評価してエンジニアとして採用しました。その結果、とても熱心にストラタス製品について勉強してくれて、見事に期待に応えてくれました。
しかしその後、別の部署に異動することになり、後任にストラタスの運用を引き継ぐことになったのですが、その人は、高さが1メートルくらいありそうなストラタスのマニュアルやドキュメントの束を後任者の机の上にドンと置いて、「これを読んで」と言い放つだけでした。
その後、後任の担当者が私に泣き付いてきたので、適切に引き継ぎをするよう指導してことなきを得たのですが、このエンジニアはきっと「自分はストラタスを習得するのに相当苦労したのだから、他の人も同じように苦労すべきだ!」と考えたのだと思います。こういう考え方をする人は、日本だけでなく米国でも実に多いですね。
中野氏 システム開発の現場では、実によく見られる光景ですね!
サンドバーグ氏 こうした考え方を排除するには、やはりナレッジをスムーズに共有し、引き継げるようにするための「ナレッジマネジメントの仕組み」が欠かせないと思います。
国連UNHCR協会でも、駅前の街頭で寄付を募るメンバーが利用するタブレット端末に関するFAQを「Salesforce ナレッジ」に集約して、どこからでも簡単に参照できるようにしました。また同じ仕組みをコールセンターにも導入して、お客さまから寄せられた寄付に関する問い合わせにオペレータがより迅速に答えられるようにしました。
中野氏 そうやって内部に溜まった知見をきちんとドキュメント化する取り組みは、とても重要ですよね。
最近のWeb系の企業では、社員同士がチャットツールをはじめとする文字媒体を通じてコミュニケーションを取るのが当たり前になっているので、ドキュメンテーションに関する意識がかなり高いと感じます。
一方、昔ながらの日本企業はこれまで対面のコミュニケーションを基本としてきましたし、人の出入りもさほど多くなかったので、やはりドキュメントの重要性が今に至ってもなかなか理解されていないような気がします。
サンドバーグ氏 それに、必ずしもすべての情報を文字で書かれたドキュメントの形に残す必要もないと思います。
例えばデータベースサーバで使われているSQLを誰でも見れるようにしておけば、SQLを読めるエンジニアであれば誰でもこの情報を参照できます。
インフォマティカの製品についても同様で、その設定情報やジョブの中身が公開されていれば、それらを解釈できるエンジニアであれば文字で書かれたドキュメントがなくても十分な情報を得られます。Salesforceの開発言語であるApexも同様ですね。
こうして過去の資産をきちんと理解してうまく流用できるようになれば、新規開発の工数もかなり節約できるはずなのですが、なぜか皆すべてを一から開発したがるんですよね。
その背景には、「頑張っている自分の姿を見て評価してほしい!」という心理が働いているのだと思いますが、私に言わせればそれは頑張りどころが間違っています。
そういう無駄な手間を増やして残業したり徹夜したりする人より、8時間かかっていた仕事を5時間で済ませるようにして早く家に帰る人を私は高く評価したいですね。頑張るのは大いに結構なのですが、頑張る方向を見誤らずに、うまく自分の頭と最新の技術を使って効率よく仕事をしてほしいと切に願っています。