エンジニアの生き様をウォッチするメディア

エンジニアドリブンの新規サービスの成功は、非エンジニア人材次第? 働き方を整える仕事人。CTC(伊藤忠テクノソリューションズ)森裕信・丸絵美梨

伊藤忠テクノソリューションズ株式会社(CTC)が提供するデジタルトランスフォーメーション(DX)支援サービス『build serivce』は、多様なスペシャリストがその知見を集結させることで機能する。当然事業の核となるエンジニアには高いスキルが求められるが、実はBuildサービス推進チームは”非エンジニア”のスペシャリストもいる。

エンジニアドリブンなチームにあって、環境を整え、エンジニアの働きやすさ、実力を発揮する舞台を整えるオペレーションの役割とは?

Buildサービス推進チームを支える森裕信氏、丸絵美梨氏に話を聞いた。

エンジニアを支える非エンジニア人材

「みなさんのおすすめグルメについて語ってください」

新規事業、しかもこれまでとは一線を画すビジネス手法、組織のあり方で立ち上げられたBuildサービス推進チームは、まさに新型コロナウイルスの感染拡大が日本国内でも深刻なり始めた昨年、さまざまな部署からスペシャリストが集う形で結成された。

冒頭の「おすすめグルメ」は、新しいチームである上にコロナ禍でなかなか対面してコミュニケーションが取れないメンバーのアイスブレイクとして、オペレーションチームが導入した一つの事例だ。

「場の雰囲気をよくするための企画として実施し、好評だったのでテーマを変えて継続しています。エンジニアはシャイな人が多い印象があるので、コロナ禍でもコミュニケーション不足にならないようにアイスブレイクを取り入れています」

エンジニア組織の非エンジニアメンバーとして環境整備やさまざまな支援を行う丸氏は、「エンジニアが働きやすい環境を整得る施策の一例」として、こんな実例を挙げてくれた。

「4月にいきなりフルリモートになり、新たに社内複数部署から集まった15人のメンバーのコミュニケーションをどう構築していくかということには多少気を遣いました。これから中途採用で新しいエンジニアを迎えようという組織でもあり、リモート会議であっても、業務の話をするだけではなくて、お互いを知ることができるようなものを盛り込んでいこうということで始めたわけです」

森氏も、自らの役割を「エンジニアの力を120%引き出すこと」と語る。

通常、IT企業の非エンジニア人材というと、事務的な役割、管理的な業務が主になるイメージがあるが、build serviceの事業、そして推進チームのあり方のお手本になった米・スラローム社(Slalom LLC,以下、Slalom)では、Operationsと呼ばれるロールが、「サポート役」としてのみでなく、チームのコアメンバーとして有機的に事業に貢献しているという。

「シアトルに研修に行ったメンバーから聞いた話なのですが、Slalomではオペレーションメンバーが結構目立っていると。エンジニアのコミュニケーションを深めるために、いろいろなイベントや仕組み、制度制定の働きかけをしたり、ことあるごとに関わってくるという話を聞いて、すごく感銘を受けたんです。日本では、事務担当というふうに見られがちですが、私たちもbuildチームのメンバーとして積極的に自分の役割を担っていきたいなと思いました」(丸氏) 

職場における幸せってどんなものだろう?

連載の第2回では「エンジニアの幸せ」について言及したが、エンジニアの幸せを支える非エンジニアの役割とは一体どんなものなのだろう。 

── 森さんは、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の本質だと思っているんです。

なぜか分からないけど、Slack導入で返事がすぐ返ってくるようになった

── 事業や組織のあり方からエンジニアが働きやすい環境、幸せのサポートが生まれるということですね。具体的な施策として、アイスブレイクの例が出てきましたが、その他にどんな例がありますか?

丸 弊社はベンチャー企業と比べると、大手企業に分類されるため、ルールは確かに多いです。エンジニアの人が「これをやりたい」「このツールを使いたい」と思っても制限があったり手続きが面倒だったりで諦めてしまうこともあります。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だというお話がありましたが、今後ますます発展していくためにエンジニアはどんどん増員されていく予定だと聞いています。お二人の立場からどんなエンジニアと働きたいと思っていますか?

森 その質問に関しては、事業責任の一端を担う立場から発言をしなければいけないと思っていますが、まず一番重要なのはbuild serviceの提供のために必要なエンジニアスキル。技術力は必ず必要です。具体的には、パブリッククラウド環境において複数の言語フレームワークを利用した開発経験を持ち、新技術を継続的に学び活用する意欲と能力を備えていること。さらにメソドロジーとして、アジャイル開発のメソッドに関する知見および、テスト自動化などの手法やファシリテーションスキルも重視するところでしょう。お客さまと共同で業務を遂行し、メンバーだけでなく顧客側の成長、スキルアップを促すことが重要な事業でもあるので、コミュニケーションスキル、チームワークに貢献するスキルも必要不可欠です。

大手SIerの事業部門だからといって学歴や経歴が重視されるという先入観は払拭しておきたいなと思っています。採用に関してはあくまでも技術オリエンテッド。これからも継続的に事業を拡大していこうと思っているので、現状のスキルが達していなくても、サービスのあり方に興味を持っていただけた方には、スキルを磨いて今後仲間に加わってほしいという気持ちは強いです。

丸 期せずしてリモートワークでの開発という特殊な状況になってしまいましたが、こういう状況だからこそ、チームワークが大切になってきてるのかなと感じます。スキル要件に関しては、相当高いんじゃないかなと思いますが、入社後の成長も含めて、エンジニアにとって最高の環境で働ける現場だと思いますし、私たちも全力でサポートしていきたいと思っています。

── 最後に、チームのオペレーションを担うお二人は、この事業を通じてどんなことを実現したいと考えていますか? 少し先の未来に実現したいことを聞かせてください。

丸 今はDX内製化支援を始めたばかりという段階ですが、私たちのチャレンジによって、この事業が一般的になって、数年後に浸透していったときに、DX内製化支援といえばbuild serviceだよねと言ってもらえるようなサービスを一緒につくっていきたいと思っています。

森 現状は、大企業の新規事業に関わる案件がほとんどなので、具体的にどんなお客様のどんなことをやるということは公の場で申し上げられないのが残念ですが、日本の企業が変革をするサポートをすること、エンジニアのみなさんが直接お客さまと事業を行うなかで、その変革を体験する、そういう循環をつくれたらいいなと思っています。

DXによって日本全部が一気に変わるという話ではないかもしれませんが、あなた自身とあなたの周りの世界が変わるということは十分にあり得る、そして意味のあることだと思います。

事業立ち上げの際に、Slalomの幹部の方からこんなことを言われたんです。

「われわれは、CTCがbuild service事業を立ち上げることに対して支援は惜しまない。けれど、ノウハウを教えることはできても最後にそれを実現していくのはCTC 自身にほかならない。君たち自身でやらなければいけないし、それは君たちにとってのチャレンジになるだろう」

全くその通りだと受け止めていますが、いざ事業が立ち上がってみるとまた重たい言葉だなと実感しています。

DX支援をエンジニアドリブンで推進し、最終的には企業が自走できる段階まで持っていく。build serviceの範となったSlalomでは、このサイクルを繰り返し、いまや1000人規模のエンジニアを抱えるDX支援コンサルファームとなった。森氏がSlalomの最高幹部から言われた言葉通り、新たに立ち上がったCTC、Buildサービス推進チームが日本の市場にチャレンジを開始したことで、build service事業が独自のブランドとして自走し始めたのかもしれない。

ライター:大塚一樹


伊藤忠テクノソリューションズでは、エンジニアを募集しています。