目次
■おすすめ企業
2021.03.23 2024.01.22 約4分
伊藤忠テクノソリューションズ株式会社（CTC）が提供するDX支援サービス「Build serivce」には、多様なスペシャリストが集結している。事業の核となるエンジニアには高いスキルが求められるが、非エンジニアもコアメンバーとしてチームを支えるのがBuild serviceチームの強みだという。そんなエンジニアの働き方を整えるBuildサービス推進チームの森氏、丸氏に話を伺いました。
新規事業、しかもこれまでとは一線を画すビジネス手法や組織のあり方で立ち上げられたBuildサービス推進チームは、まさに新型コロナウイルスの感染拡大が日本国内でも深刻になり始めた昨年、さまざまな部署からスペシャリストが集う形で結成されました。
エンジニア組織の非エンジニアメンバーとして環境整備やさまざまな支援を行う丸氏は、「エンジニアが働きやすい環境を整える施策の一例」として、こんな実例を挙げてくれました。
「4月にいきなりフルリモートになり、新たに社内複数部署から集まった15人のメンバーのコミュニケーションをどう構築していくかということには気を遣いました。これから中途採用で新しいエンジニアを迎えようという組織でもあり、リモート会議であっても、業務の話をするだけではなくて、お互いを知ることができるようなものを盛り込んでいこうということで始めたわけです。」
森氏も自らの役割を「エンジニアの力を120％引き出すこと」と語ります。
通常、IT企業の非エンジニア人材というと、事務的な役割、管理的な業務が主になるイメージがあるが、Build serviceの事業、そして推進チームのあり方のお手本になった米・スラローム社（Slalom LLC,以下、Slalom）では、Operationsと呼ばれるロールが、「サポート役」としてではなく、チームのコアメンバーとして有機的に事業に貢献しているそうです。
「シアトルに研修に行ったメンバーから聞いた話なのですが、Slalomではオペレーションメンバーが結構目立っていると。エンジニアのコミュニケーションを深めるために、いろいろなイベントや仕組み、制度制定の働きかけをしたり、ことあるごとに関わってくるという話を聞いて、すごく感銘を受けたんです。日本では、事務担当というふうに見られがちですが、私たちもBuildチームのメンバーとして積極的に自分の役割を担っていきたいなと思いました」（丸氏）
── 森氏は、CHOの肩書をお持ちです。これはGoogleなどでも導入されている役職ですよね。
森：現段階では会社公式の肩書ではなく、あくまで部署内における呼称です。チーム長が、Chief Happiness Officerという呼称をつけてくれたので、それを受け止めていろいろ考えてみたのですが、、あまり大上段に構えると、誇大広告かなと思っているんです。
私としては、「ちょっと変なおっさん」（略して「CHO」）という自覚しかなくて、チームメンバーにもそう思っていただくのが一番しっくりきます。CHOは少しこそばゆいんです。
森：いちおう「自称CHO」として「職場における幸せって何だろう」ということをこの半年考えてきたのですが、「働く人が幸せになれば業績が上がる（だから働く人の幸せを考えるべきだ）」という、企業の業績が目的になる考えには違和感があります。私も企業の管理職として利益を追求するという束縛から自由ではいられないですが、少なくともBuild事業に関しては企業の業績とエンジニア個人の幸せやキャリアはどちらが先というものではなく、両立するものだと考えています。
── すでに複数名のエンジニアメンバーにお話をうかがっていますが、Build serviceの事業のあり方、連載第3回で詳しく説明しているPEM（Product Engineering Method）というフレームワーク自体が、個人の成長や幸せと、企業の利潤を同時にかなえている。
森：Build serviceは、UXデザイン、アジャイル開発、クラウドネイティブ技術で、お客さまにとって価値のあるものをお客様とともに生み出し、最終的にお客様が自分でその取組を継続的に進めていけるようにするまで一緒にやり続ける事業です。これは、どこまで行っても各エンジニアのスキルや働きにかかっているんですよね。
お客さまに価値を提供することと会社が収益をあげること、エンジニアがスキルアップして自分の市場価値を上げることは矛盾しない。極論、エンジニアが自分のために自分のスキルアップを突き詰めていったとしても、最終的にそれがお客さま、会社の繁栄につながると思います。
── そういう意味でBuild serviceにおいて、いかにエンジニアがスキルを発揮し、向上心を持って取り組めるかが重要になるわけですね。
森：一つだけ誤解を生まないようにお話をすると、最終的にBuild serviceが目指すのは、お客さまがDX事業を自走できることなんです。お客さまが自らソフトウエア開発をしたり、事業を進めていく支援をするのがわれわれの仕事なので、「自分だけが手柄を上げられればそれでいい」というのとは違うんですね。自分を高める中でチームメンバーとも高め合い、お客さまもそれに触発されて高まっていく。これがBuild serviceの本質だと思います。
── 事業や組織のあり方からエンジニアが働きやすい環境、幸せのサポートが生まれるということですね。具体的な施策として、アイスブレイクの例が出てきましたが、その他にどんな例がありますか？
丸：弊社はベンチャー企業と比べると、大手企業に分類されるため、ルールは確かに多いです。エンジニアの人が「これをやりたい」「このツールを使いたい」と思っても制限があったり手続きが面倒だったりで諦めてしまうこともあります。Buildサービス推進チームではそこにあえてチャレンジしています。例えば、企業内wikiツールのConfluenceとか、オンラインホワイトボードのmiroなど、他の部署ではあまり取り入れていないものも、導入しています。今のコミュニケーションツールはSlackに落ち着きましたが、Teamsを使ったり、バーチャルオフィスツールのSococoを試したりしていました。
── Slackの利点、導入して変わったことはありますか？
丸：エンジニアがいいなっていうツールはやっぱり使ってみると便利だったりするんですよね。Slackも他のツールと何が違うのかなと半信半疑でしたが、使ってみるとコミュニケーションが高まる。エンジニアの「これ使いたい」というつぶやきは聞き逃さないようにしています。
森：Slackのいいところは、なぜか理由は分からないのですが、Slackで聞くとエンジニアからすぐに返事が返ってくるというところですね（笑）。
── エンジニアのニーズに気が付く、またはエンジニア自身も気が付いていないニーズを引き出すために工夫されていることはありますか？
森：自分がエンジニアではない時点で「聞かなきゃわからない」というのはあるので、まずはしっかり聞くこと。私は当チームの最年長ですが、毎日zoomないしは Slackをオンコールにして、雑談も含めてメンバーと話をするようにしています。
そういう会話から出てくるニーズもありますし、相談しやすい雰囲気をつくることも重要です。もう一つは、エンジニアの世界、技術の世界を多少はリアリティー持って知ろうとすることじゃないかと思っています。
私は技術者のキャリアはゼロですし、全く知見はないんですけれども、素人なりチームメンバーの見よう見まねで、「五十の手習い趣味のAWS」 というサイトを立ち上げて、 AWS を趣味でいじってみたりしています。エンジニアから見たらお遊びレベルですが、好きな音楽に関するサイトをメンバーに教わりながらStatic Site Generatorでつくってみたりと、エンジニアの仕事やツールの感覚値をつかもうという心がけだけはするようにしています。
丸：森さんは常に最新技術を勉強していて、そういう姿勢はすごいなと思って尊敬しています。
森：常に最新技術を追いかけているのはまさにうちのチームメンバーのエンジニアたちなので私ではないですが、私の趣味である音楽を世に広めるウェブサイトをつくるための手段としてプログラミングを学ぶことがモチベーションになっているのかなとは思います。全く仕事の話ではないですけれども（笑）。
── エンジニアの働きやすい環境をつくる上での苦労はありますか？
丸：会社には守るべきガバナンスもあって、経るべきプロセスや手続きにも意味があるので、そこの部分は引き受けつつ、Buildチームに適した運用ができるように柔軟に対応するようにはしています。
森：ベンチャー企業であっても、ある程度組織が大きくなってくると、組織での役割分担、管理するための制限は出てくるものだと思います。しかし、Build service事業に関しては、弊社の中にありますが、一つのチームの中に技術、営業それから管理部門というような一企業に必要な全ての機能を有しているんです。そういう意味では社内ある一つの企業、チームの中で完結する社内ベンチャーのような側面も持っています。
事務作業一つとっても、単に事務処理をするだけではなくて、エンジニアのみなさんがほしい環境、専門家としてのアイデアをくみ取って具体的な形に落とし込んでいくのが私たちの非常に大きな役割かなと思っています。
── お二人はそれぞれどんなキャリアを歩んでBuildサービス事業推進チームにジョインされたんですか？
森：私は2001年に中途採用で入社し、海外IT製品の日本国内展開時の契約やベンダー折衝などを担当したり、管理部門で仕事をしたりしたのちに、Buildサービス推進チームに参画しました。
丸：私も森とはほぼ同期で、第二新卒で入社しました、EPネットワークワーク推進部に配属され、大所帯のSE部署のサポート部署などを経験し、その後通信機器やクラウド商材の立ち上げを経て、昨年4月から現職という形になります。
── 今後ますます発展していくためにエンジニアを増員されていく予定だと聞いています。お二人の立場からどんなエンジニアと働きたいと思っていますか？
森：その質問に関しては、事業責任の一端を担う立場から発言をしなければいけないと思っていますが、まず一番重要なのはBuild serviceの提供のために必要なエンジニアスキル。技術力は必ず必要です。
具体的には、パブリッククラウド環境において複数の言語フレームワークを利用した開発経験を持ち、新技術を継続的に学び活用する意欲と能力を備えていること。さらにメソドロジーとして、アジャイル開発のメソッドに関する知見および、テスト自動化などの手法やファシリテーションスキルも重視するところです。
お客さまと共同で業務を遂行し、メンバーだけでなく顧客側の成長、スキルアップを促すことが重要な事業でもあるので、コミュニケーションスキル、チームワークに貢献するスキルも必要不可欠です。
大手SIerの事業部門だからといって学歴や経歴が重視されるという先入観は払拭しておきたいなと思っています。採用に関してはあくまでも技術オリエンテッド。これからも継続的に事業を拡大していこうと思っているので、現状のスキルが達していなくても、サービスのあり方に興味を持っていただけた方には、スキルを磨いて今後仲間に加わってほしいという気持ちは強いです。
丸：期せずしてリモートワークでの開発という特殊な状況になってしまいましたが、こういう状況だからこそチームワークが大切になってきてるのかなと感じます。スキル要件に関しては、相当高いんじゃないかなと思いますが、入社後の成長も含めてエンジニアにとって最高の環境だと思いますし、私たちも全力でサポートしていきたです。
── 最後に、チームのオペレーションを担うお二人は、この事業を通じてどんなことを実現したいと考えていますか？ 少し先の未来に実現したいことを聞かせてください。
丸：今はDX内製化支援を始めたばかりという段階ですが、私たちのチャレンジによって、この事業が一般的になって、数年後に浸透していったときに、DX内製化支援といえばBuild serviceだよねと言ってもらえるようなサービスを一緒につくっていきたいと思っています。
森：現状は大企業の新規事業に関わる案件がほとんどなので、具体的にどんなお客様のどんなことをやるということは公の場で申し上げられないのが残念ですが、日本の企業が変革をするサポートをすること、エンジニアのみなさんが直接お客さまと事業を行うなかで、その変革を体験する、そういう循環をつくれたらいいなと思っています。
DXによって日本全部が一気に変わるという話ではないかもしれませんが、あなた自身とあなたの周りの世界が変わるということは十分にあり得る、そして意味のあることだと思います。
事業立ち上げの際に、Slalomの幹部の方からこんなことを言われたんです。
「われわれは、CTCがBuild service事業を立ち上げることに対して支援は惜しまない。けれど、ノウハウを教えることはできても最後にそれを実現していくのはCTC 自身にほかならない。君たち自身でやらなければいけないし、それは君たちにとってのチャレンジになるだろう」
全くその通りだと受け止めていますが、いざ事業が立ち上がってみるとまた重たい言葉だなと実感しています。
DX支援をエンジニアドリブンで推進し、最終的には企業が自走できる段階まで持っていく。Build serviceの範となったSlalomでは、このサイクルを繰り返し、いまや1000人規模のエンジニアを抱えるDX支援コンサルファームとなった。
森氏がSlalomの最高幹部から言われた言葉通り、新たに立ち上がったCTC、Buildサービス推進チームが日本の市場にチャレンジを開始したことで、Build service事業が独自のブランドとして自走し始めたのかもしれない。
ライター：大塚一樹
