CTOが聞く Vol.6 ICT本部ITBP 粟飯島 & 金井「"べき"と個別化を両立する心強いパートナー、事業部から圧倒的に信頼されているITBPのエンジニアに話を聞いてみた」

CARTA HOLDINGSで働くエンジニアたちにCTOが「最近なにやってるの？」をざっくばらんに聞いていくシリーズです。今回はCARTA HOLDINGS CTOのすずけんが、ICT本部のITBPチームの話を聞きました。

インタビュアー：鈴木健太 Twitter ID @suzu_v（写真左）
株式会社CARTA HOLDINGS 執行役員CTO / 株式会社fluct取締役CTO。社内では「すずけん」と呼ばれる。「みんなのGo言語」「データ分析基盤入門」共著者。ウェブ技術全般に明るい。ポッドキャスト「ajitofm」をやっています。

鈴木健太（以下、すずけん）：今日はよろしくお願いいたします。改めてお二人から自己紹介をお願いできますか？

インタビュイー：金井飛幸（写真右）
金井飛幸（以下、金井）：はい。僕は2011年の中途入社ですね。その頃はサービス・インフラ（事業基盤）を事業部側ではなく全社部門が提供していく方針だったのですが、僕はその全社部門のなかでインフラ構築まわりをやっていました。その後、徐々に事業部側にインフラ構築のお仕事が移っていったので、現在は主に全社向けの情報基盤とかこれからお話するITBPの仕事として、事業部との運用調整なんかをしています。

インタビュイー：粟飯島勝明（写真中央）
粟飯島勝明（以下、awa）：私は金井さんより2年あとの2013年に中途で入社して、すずけんもいたfluct（株式会社fluct）に所属していました。もともと全社部門が担っていた事業基盤を、fluct管理に移すところを担当したので、もう少し厳密に言うと、最初は全社部門（旧システム本部）配属で、そのままfluctへ、という流れです。2019年からは当時のVOYAGE GROUPのシステム本部に戻って全体の統括を行いつつ、ISMS（情報セキュリティマネジメントシステム）の取得をやったり、CARTA HOLDINGSになってからも同様の立ち位置にいます。

すずけん：ありがとうございます。awaさんは書籍『事業をエンジニアリングする技術者たち』でも経営統合とシステム統合ネタで出ているのでぜひ！というかんじですね(笑)

ITBP = ITにおけるビジネスパートナー

すずけん：今日はCARTAのICT本部・ITBPチームのお話をいろいろ聞かせてください。一般的な名称として「ITBP」ってまだ知られていないんじゃないかと思うのですが、改めてどんな仕事か、どんなチームでやっているかを簡単に教えてもらえますか？

金井：ITBPは、ITにおけるビジネスパートナーを略した名前ですね。各事業部から「サービスを始めるにあたってどうしたらいいですか？」というざっくりとした相談を受けたり、情報基盤の繋ぎ込みの調整をしたりしています。

すずけん：具体的にどんなものをイメージするといいですか？

金井：例えば、認証システムやAzureとの繋ぎ込み、あとはGoogle Workspaceを使った外部との情報共有の仕方などですね。

すずけん：なるほど、それらを情報基盤と呼んでいるんですね。ありがとうございます。CARTAのなかでもITBPにお世話になっている部署は多いと思うのですが、ITBPができた経緯もぜひ紹介してもらえますか？

awa：はい。まず前提として、CARTAはそれぞれの事業部の裁量が大きい会社です。情報基盤に関しても、事業部としては自分たちが良いと思うものを使いたい。けれども、なんでも好きに使うことが、本当にそのサービスがその事業や部署にとっていいことなのかというとそうではない場合もある。その認識をすり合わせていくことが必要だよねというのが、ITBPができた一番の理由ですね。

すずけん：なるほど。「もっとこういう良いやり方があるよ」と方向づける、事業部の相談相手のような立場からスタートしたんですね。

awa：そうですね。

すずけん：いまCARTAでは、事業部という単位でみると20くらいあって、それをICT本部、ITBPで見ていくということだと思いますが、さきほども紹介してもらったさまざまな情報基盤を各部署にどう使ってもらうかは実際に話してみないとわからないということですね。

awa：はい。CARTAの前身であるVOYAGE GROUPはもともとそういう運営スタンスでした。ITBPという名前はなかったものの、同じことはやっていたと思います。CCIと経営統合して組織が大きくなったときに、名前を明確にしないと立ち位置があいまいになってしまうなと思い、改めてITBPという定義をしました。金井さんが当時やっていたことの一部は、ITBPそのものでしたよね。

金井：そうですね。以前からサービス・インフラとしてやっていたことは、事業部との橋渡し的な役割でした。とくにエンジニアがいない事業部とよくコミュニケーションをとっていて、「こういうときどうするの？」という相談を受けていました。技術的な解決策の相談は、いまと変わらないような仕事のやり方ですね。

相談は「ふわっとしているほうがいい」

すずけん：実際には、どんな相談がくることが多いですか？

金井：よくあるのが、コーポレートサイトを作りたいとか、新しくサービスを立ち上げることになったので、サービス用のサイトをWordPressで作りたいんです、とか。他には、取引先との新しい取り組みを始めるので、外部とファイル共有したい。それはGoogle Workspaceでできますか？とかですね。

すずけん：うんうん。よくWordPressの相談をされているイメージがありますね(笑)

金井：そうですね(笑) サイトの立ち上げなんかは、作って終わりではなく、そのあとセキュリティチームとのセキュリティ診断の調整にも一緒にはいったりしています。スケジュール管理もやりますし、ちょっとした社内でのプロジェクトマネジメントみたいなかんじですね。

すずけん：なるほど。例えばコーポレートサイトを作りたいという話がありましたけど、仕組みとしてCMSを入れたくて、それがWordPressなのか、あるいは別のものが良いのか選んでいきましょうとか、問い合わせフォームを作るなら個人情報の扱いをどうしようかとか、セキュリティのレビューどうするとか。そういう全体的なコーディネートをしていくということですね。

金井：そうです。

すずけん：さきほど「エンジニアがいない部署」というキーワードがありましたが、金井さんはそういう部署から相談されることが多いんだとわかりました。VOYAGE GROUP時代からずっとそうだったんですか？

金井：そうですね、役回りというか(笑) サービス・インフラの部隊がなくなってからは「誰がどこを見る」というのがなくなったんですよね。僕はWordPressの全社的な仕組みのコントロールを担当していたので、例えば「WordPressで作りたいっていうから話を聞いてきて」というケースや、ドメインやSSLの管理もやっていたので、サイト立ち上げの話はよく相談を受けていましたね。とくに旧VOYAGE GROUPでは新規事業や会社をたくさん立ち上げていたので。

すずけん：なるほどですね。どちらが先かというよりは、WordPressの仕組みとかコントロール、発注管理、当然ドメインやサーバー管理もしていて、事業部側がヒアリングしていったら「金井さんに聞くのが早い」という流れなんですね。

金井：そういうのを自分がやっていることが知れ渡って(笑)、とりあえず先に相談いっておこう、みたいなケースもありますね。

すずけん：そうすると事業部の人から見たときの立ち位置は、「これを相談しよう」と決めていくわけではなくて「とりあえずITBPに聞いておこう」というかんじなんですか？

金井：うーん。どちらもあるとは思いますが現状は、やりたいことがあったときに相談する相手なんじゃないかなと。ITBPを立ち上げた当初は、案件が発生する前に、事業部のなかに入り込んで話を聞くというところも目指してはいたのですが、まだそこまではいけていないですね。そういう体制ができてくると、要件ベースではなく、事業を進めるうえで必要なものはITBPが吸い上げて話をしていくようにシフトしていけるのかなと。

すずけん：ああ、なるほど。つまり今の話は現状の課題ということですね。理想形としては案件が発生する前の段階で、ITBPメンバーがヒアリングしていて一緒に作っていくのがいいんですね。

金井：そうですね。新しいサービスを作るところに立ち会っていて、そのなかのひとつとしてサービスサイトを作る話があれば「こうやっていきましょうか」と最初に話せる関係値を築く、みたいな。

すずけん：そうですよね。そもそもどういうことをやっていこうか、とか、コーポレートサイトを作るならこういうアセットや方法があるけどどうしていきましょう、とか、もっと先のシフトレフトというか、先々まで決める段階ではいっていくというのが、ITBPの理想的な状態ですよね。

awa：「◯◯が使いたい」と事業部に言われるのは良い状態ではない。「◯◯がしたい」と相談してもらえるのが理想。ツールありきで話をされたときに気をつけないといけないのは「そのツールでなにをしたいんですか？」と確認をとること。確認してみると、実現したいこととツールが噛み合っていないこともある。

すずけん：つまりHowではなく、Whatの段階で持ってきてもらうということですね。そこから一緒にどうしようか考えられるようにしていきたい、と。

awa：普通の情報システム部門だったら、やりたいことを明確にリクエストしてもらったほうがやりやすいかもしれないけれど、ITBPの場合は真逆で、ふわっとしているほうがいい。

すずけん：いいですね、「ふわっとしているほうがいい」。これはITBPの理想を表しているキーワードですね。ありがとうございます。ここまでの話を聞いて、ITBPがどういう狙いで作られてきたか少しずつ伝わってきました。

ぎりぎりまで標準化しない

すずけん：WhatではなくHowの段階で相談が来てしまうという話がありましたが、それを解消するためにITBPとしてトライしていることはありますか？

金井：うーーーん。トライはあまりできていないかも・・・(苦笑)

すずけん：忙しいですよね〜(笑)

awa：純粋にマンパワーが足りていないですね。

すずけん：ICT本部全体を見ると、セキュリティチームや情報基盤チームなど他にもチームがあって、共通の情報基盤を作ったり整備したりすることもあるわけで、金井さんもそこを担っていて。そうなると100%、ITBP業だけに集中できるわけではないと。

金井：はい、そうなんです。

すずけん：マンパワーという話もありましたが、事業部が20強あるなかで、単純にITBPの人数を増やしていけば解決する話もあるかなと思いつつ、仕事のやり方やツールの標準化をしていくことで、ITBPのサービスレベルをあげていこうとか、そういうアプローチは考えているんですか？

awa：標準化を念頭においてしまうとうまくいかないと思うので、優先度は下げていますね。こういう業務基盤を作って提供すれば仕事がまわるでしょうと思って提供してもできないことがたくさん出てくる。標準化ありきで、こちら側が提供できるものでなんとかしようと思うと事業部側が使いたいもの、やりたいことから外れていってしまうんですよね。

すずけん：ふむふむ。

awa：仕事のやり方の面では、もっと事業部のなかに入っていくことかなと思います。例えば、定例MTGに参加したり。金井さんはある程度できるようになっていて、他のメンバーはこれからですね。

金井：今はサポーターズ（株式会社サポーターズ）とCARTA GAMES（株式会社CARTA GAMES）には定例に呼んでもらって、話をその場で聞いて「それはこうやればできそうですね」みたいなフォローができています。ただ、すべての事業に対してできているわけではないので、もっと増やしていきたいです。

事業をつくっている現場の「こういうことしたいよね」を拾いに行く

すずけん：例えばサポーターズの定例に出ていると、要望がけっこう出てくるんですか？

金井：サポーターズはエンジニアがいる部署なのですが、エンジニアが抱えている課題に対しては、それは事業部のエンジニアではなくこちら側（ICT側）で解決できますよという判断は、その場でできていますね。定例に出ていると事業部のエンジニアとコミュニケーションもしやすいですし。

すずけん：なるほど。事業部側のエンジニアが解決する問題とICT本部で解決する問題のすみ分けがその場でできるんですね。ちなみにそのタスクの線引きはどういうところでしているんですか？

金井：それはけっこう明確で「事業として作っているサービスかどうか」ですね。

すずけん：サービスは事業部側ですね。サポーターズでいうと学生さん向けの支援ツールをたくさん作っていますが、そのあたりは事業部のエンジニアが作る。

金井：そうですね。一方、サポーターズが使っているZoomの管理をしていきたいという話であれば僕たちですね。

すずけん：なるほど、理解しました。サポーターズの事業サイドのメンバーからすると、とりあえずITまわりで困ったことがあると定例でリクエストを投げておけば、事業部のエンジニアとICTでよしなにしてくれる、という感覚なんですね。

金井：そうですね。ただ、サポーターズはエンジニアがちゃんと事業サイドのメンバーとの間に立っているので、これまでもある程度切り分けしたうえで僕たちに依頼をくれていたと思うんですよね。でも定例に出るようになったことで、事業部のエンジニアがそこをプロキシする役割をしなくても、その場で話ができるようになりました。

awa：近しいトライとしては、ITBPに質問するためのSlack窓口を作っていない、というのもあるかな。窓口を作ってしまうと事業部側から相談に来てもらわなければいけなくなる。そうではなく、私たちが日々事業部のSlackを眺めていて「こういうことしたいよね」という声を拾うようにしています。

すずけん：事業部から要望が落ちてきてから対応するのではなく、自分たちから取りに行くということですね。こういうのは、ITBPを象徴する動きと言えそうですね。依頼をさせない、という。

ITBPの醍醐味 〜 「べき」論と個別化の両立

すずけん：最後に聞きたいのは、ITBPの醍醐味についてです。ITBPの仕事の面白さとか大変さ・・・大変さはだいぶ聞けたと思うのですが(笑)、どうでしょう。

金井：事業部と一緒に話をしていくので、事業部メンバーになったかのようにサービスに携わっていくことができることが醍醐味ですね。

awa：バックオフィスのエンジニアって「いまこの事業は盛り上がっていて、こっちの事業は苦労している」というのが見えづらかったりもする。

すずけん：事業をやっている肌触り感みたいなところですね。

awa：はい。金井さんの言うとおりで、ITBPとして事業部と関わりながら仕事をすることによって、そういう見えづらさは解消できる部分だと思いますね。

すずけん：ICT本部は情シス的だという話もありましたが、いわゆる全社基盤を支える部署でもありながら、そのなかにITBPがあることで、もっと事業の肌触りや、実際どういうことを考えて何をやろうとしているのかわかるんですね。ITBPがフロントに近いところで事業部のパートナーとしてIT提供の機能を持つことで、何を提供していくべきかICT全体としてのレベルがあがっていく。そういうところを期待していると。いいとこどりのポジションですね(笑)

awa：はい。でも、事業側にどんな狙いがあって、何をしようとしているかを理解していないとコミュニケーションがとれないので、そこは大変なところかもしれないです。

すずけん：ドメイン知識をちゃんと身につける必要があるということですね。

awa：それを楽しめる人に向いていると思います。

すずけん：ICT本部としては、みんな同じものを使ってもらったほうが楽ですよね。だけどITBPは「いや、使うものは違ってもいいかんじにやっていこうよ」という立場。

awa：そうそう。なので、本部内では実際にそういうやりとりはたくさん起きています。ITBPと情報基盤、セキュリティチームの間で。

すずけん：ICT本部のなかで議論できるのはいいですね。「べき論」だけで決まって、事業部と戦う構図もありがちなことかなと。

awa：そうさせない緩衝材のような役割でもありますね。

すずけん：すごく重要ですね。それがないと事業部が「ICTがこれ使えって言ってるんですけど、どうなってるんですか！」みたいなことが起きると思うので(笑)

awa：起きやすいと思いますね。そのためのITBPです。

すずけん：ありがとうございます。このあたりに面白みを感じられる方はぜひお待ちしています！

PR

CARTAのITBPに興味を持っていただけた方は、ぜひこちらからお申込みください。 hrmos.co

そのほか、ICT本部では他のポジションでもエンジニアを積極大募集中です。 hrmos.co hrmos.co

いきなりエントリーではなくとも、まずはお話ししましょうという形でカジュアル面談も受け付けています！ hrmos.co