■おすすめ企業

build service- vol.02「DXがもたらす“エンジニアが幸せに働ける環境”とは」伊藤忠テクノソリューションズ丸山貴嗣・佐々木友也

2021.03.16 2024.01.22 約5分

企業のデジタルトランスフォーメーション（DX）に向けたプロダクト開発を支援することを目的とする『build service』をリリースした伊藤忠テクノソリューションズ株式会社（CTC）。連載の第1回では、シアトル発、世界でも先進的なＤＸ事例として高い評価を得ているスラロームコンサルティング社（Slalom Consulting,以下、Slalom）の取り組みに範をとったサービスの概要をご紹介した。

社内ベンチャー的なチームとして発足したBuildサービス推進チームでは、顧客に対して先進的なDXサービスを提供するだけでなく、そこで働くエンジニア、日本のIT開発の現場にもポジティブな変化を起こそうとしている。

「エンジニアが幸せに働ける環境」を目指すBuildサービス推進チームのソリューションアーキテクトを担う丸山貴嗣氏、ソフトウエアエンジニアの佐々木友也氏に話を聞いた。

アジャイル開発で起きがちな「エンジニアの疲弊」

米・Slalomの先進的な取り組みを参考に誕生したbuild serviceは、国内では大手SIerとして認知されているCTCのイメージを大きく変えるチャレンジングな取り組みとして注目を集めている。この取り組みは、事業のDX化に興味がある企業をブーストし、日本のビジネスに変革をもたらすだけでなく、現場で働くエンジニアの働き方にも変化をもたらすという。

「日本の文化的なこともあるのかもしれませんが、やっぱりエンジニアにしわ寄せがくることも少なくないんですね」

buildサービス推進チームでは、ソフトウエアエンジニア兼ソリューションアーキテクトを担う丸山貴嗣氏は、さまざまな現場でしばしば話題に挙がる「エンジニアの疲弊」について、こう語る。

「特にアジャイル開発では、明確な納期、いつまでに何を終わらせるという約束がしにくいところがあるんですけど、クライアントサイドの仕事は当然期限が決まっています。もちろんクオリティーを保つことが前提になりますが、納期ありきで仕事が進むということが全くなかったかと言われると、過去の自分のが関わったプロジェクトでもそこに頭を悩ませることはありました」

「予算ありき」の日本企業では、納期と納品の成果物が確定していないと予算も含めたGOサインが出づらい。プロダクトを開発中に改善しながら進化させていくアジャイルの手法と日本企業の伝統的な仕事のやり方の相性が悪いのは想像に難くなく、最終的に納期に「間に合わせる」という ”しわ寄せ”がエンジニアに集中し、それがエンジニアの疲弊につながるケースも少なくない。

「build service事業を進めていくチームで共有されていて、強調されてると感じるのが、『エンジニアが幸せじゃないといけない』ということで、個人的にはこれがとても印象的でした」

入社2年目のソフトウエアエンジニア、佐々木友也氏は、buildサービス推進チームが取り組む「クライアントともに共創し、顧客のビジネスの優位性を上げる」という新たなサービス内容とともに、組織のあり方、チームのメンバーに対する姿勢に強い感銘を受けたという。

「事業を進める上でのいろいろな議論の前提条件として『エンジニアが疲弊することはあってはいけない』というのが明確にあって、それをロールも含めた制度設計やチームのあり方で解決しようとしているのがすごいなと」

build serviceがもたらす「エンジニアが幸せに働ける環境」とは？

CTCがbuild service立ち上げと同時に掲げる「エンジニアが幸せに働ける環境」とは一体どのようなものなのか？　ここからは社内ではメンターとメンティーの関係でもある丸山、佐々木両氏の言葉を中心に掘り下げていこう。

── 新たな手法を採用するbuild serviceでは、仕事の進め方というか、プロジェクトの進行も既存のものとは一線を画すと聞いています。それがエンジニアの働き方にも影響を与えるということなのでしょうか？

丸山　build serviceでは、プロジェクト全体をプレセールスに当たる『ENGAGE』、クライアントとビジネス要件を議論し、実現可能性を検証する『DISCOVER』、エンジニアが関わってビジネスを成立させるアプリケーションをアジャイルで開発する『DELIVER』、クライアントの自走を支援する『TRANSLATION』の四つのフェーズに分かれています。ソフトウェアエンジニアが担うのは、『DELIVER』のフェーズからですが、ソリューションアーキテクトのロールでは、『DISCOVER』の部分も重なってきます。

自分としては、クライアントのメリット、クライアントのサービスを利用するユーザーの立場でどういうメリットがあるのかを整理して、具体的にプロダクト開発に生かせるような粒度に落とし込む『DISCOVER」のフェーズがその後の『DELIVER』の鍵を握っていると思っています。

── 丸山さんは、ソリューションアーキテクトとして『DISCOVER』と『DELIVER』をつなぐ業務も担われている？

丸山　ソフトウエアエンジニアをやりつつソリューションアーキテクトの役割も一部になっている状況です。ソフトウエアエンジニアとしては、アジャイルの手法でお客さまのシステムを開発していく、ソースコードを書いたり、テストを書いたりすることがメインの仕事。ソリューションアーキテクトとしては、しっかりと時間をかけてどういうプロダクトにしていくのかをお客さまと考え、整理して、本当に価値のあるものを開発していくための準備をしています。開発フェーズにおいては、スピードが優先されるイメージを持たれがちかなとは思うんですけど、弊社ではエンタープライズのクライアント向けにサービスを提供していることもあり、速さのためにセキュリティ、クオリティを犠牲にしないようにということは強く意識しています。

── build serviceでは、セキュリティやクオリティをコントロールするためにどんな具体的な施策が行われているんですか？

丸山　セキュリティも一部関わりますが特にクオリティでいうとクオリティエンジニアという専任のロールを立てています。スクラム開発、アジャイル開発では、チームメンバーでセキュリティ、クオリティの品質を保っていこうということが多いと思いますが、クオリティに責任を持ったロールを一つ置くことで、例えば、テストの観点が間違っていないかソースコードレビューの際に確認する、プロジェクトのテスト戦略と乖離していないか適宜確認することを通して、出来上がるプログラムの品質向上に寄与しています。

── 丸山さんは、ソリューションアーキテクトとして、顧客ニーズを掘り起こしたり、開発するプロダクトの要件を決めたりするところにも関わっている？

丸山　そうですね。『DISCOVER』に入るメンバーは技術のこともしっかり理解していて、技術的に実現可能なのかを調査・検証してプロダクトをより実現性のあるものにしていきます。実際の開発フェーズに移行しても、「あとはよろしく！」と受け渡してメンバーが入れ替わるわけではなく、『DISCOVER』を行ったメンバーはそのまま『DELIVER』のフェーズにも関わります。アーキテクチャの策定に関わったメンバーに加えて、プロダクトの実現するために必要なスキルを持った build チームのエンジニアがアサインされるので、開発への移行も比較的スムーズに進めていけるのかなと思っています。

── 佐々木さんは、入社２年目とのことですが、どのような関わり方をされているのですか？

佐々木　私はソフトウエアエンジニアとしてビルドプロジェクトに参加しています。まだ開発案件にソフトウェアエンジニアとして直接参加してはいませんが、すでに動いているプロジェクトの情報を共有してもらいながら事業構想段階の顧客事業のアイデアを上級エンジニアと一緒に考えたりしつつ、模擬案件などでエンジニアとしての経験も積み、準備をしているところです。

── build service自体が新しい試みだと思うのですが、このサービスに関わることについての率直な感想を教えてください。

佐々木　build serviceでは、 AI だったりビッグデータ解析だったりとか最新の技術を活用していく動きがあって、新技術のキャッチアップは大変だなと思うと同時にやりがいにつながっています。

── CTCと言えば、「SIerのイメージが強い」というのが自他ともに認めるイメージだと思いますが、build serviceはこうしたイメージとは180度違う働き方になるかなと思います。その辺の戸惑いはありませんでしたか？

佐々木　たしかにCTC にSIerのイメージはありますし実際そうですが、大きい会社ですから中にはweb開発に近いことをやっているチームもあるだろうなと想定し、できればそういう経験も積みたいなと思って入社したので、ギャップはありませんでした。むしろいまbuildチームで仕事ができてすごく幸せだなという感じでやっています（笑）。

私は、もともと大学で経済学を学んでいたんですけど、経済学が自分の直近の課題というか、求めていることの解決に直接は貢献しないなという思いがあったんです。そこでプログラミングや開発に興味を持って、自分で勉強していろいろなものをつくったりしながらやってきたというキャリアなので、自分のバックボーンが文系であることも含めて、従来のSIerのように案件をガンガン請け負うのとは違う仕事に取り組みたいなと思っていました。なので、build serviceをはじめ新しい取り組みをしているCTCならば自分の特徴を生かしながら楽しく働けるかなと思ったんです。

── 開発にチャレンジするきっかけになった自分の直近の課題というのは？

佐々木　カードゲームにハマっていた時期がありまして、カードゲームってやっぱりやるからには勝ちたいじゃないですか。だけど勝つためにひたすら練習するというのはちょっと効率が悪い。もっと効率的に勝つ方法はないか、練習をするにも効率を上げる方法はないかということで、経済学ではどうしようもないからIT の力を使って何かできないかなと勉強し始めたんです。

そこで勉強したこととかを仕事に生かせたらいいなと思っていて、クライアントのアイデアをプロダクトにして日本の経済を活性化させる、そういうコンセプトのbuildチームに関われているのは、とてもうれしいなと思っています。

── 丸山さんは2013年に入社されていますね。これまでの経歴を教えていただけますか？

丸山　2013年に新卒で入社して、入社直後はVMwareを使った仮想化基盤のサービスを提供する部署に所属していました。入社3年くらいは同じ部署で経験を積むのが通例のようなんですが、なぜか私の場合は1年で別の部署に突然異動になったんですよね。でもこれが結果的に見れば今につながっているんですけど、この異動をきっかけに AWS や弊社のプライベートクラウドなどに、お客様のシステムをどのような戦略をもって移行していくのか、検証・提案する業務に携わっていくようになりました。クラウドを使う仕事を経由して、その後開発にシフトしていったことが自分のキャリアに生きていると感じます。

── buildチームに入るきっかけは？

丸山　buildチームが立ち上がる前に、シアトルのslalomに4カ月くらい何名かのメンバーがトレーニングに行ってるんですけど、そのメンバーに誘われたんですよね。声をかけてもらったときも興味はあったのですが、当時は別の部署にいたので期中の部署異動はさすがに調整できなくて、トレーニングに参加するのは難しかったです。しかし、それがきっかけで新しくチームが立ち上がることを知ることができて、立ち上げ当初からチームにジョインすることができました。

── 実際にジョインしてみて、build serviceとSIer的な仕事との違いを感じますか？

丸山　クライアントと一緒になって新しいプロダクトを検討・検証しながら開発のサイクルを短い期間で回していくのが特徴的な取り組みなので、ウォーターフォール開発とは異なるところですね。また、製品やサービスにとらわれることなく、要件を満たすためにベストな技術を妥協せずに選べるというのは、大きな変化だと思います。プロジェクト進行に関しても、複数案件に同時にアサインされてコンテキストスイッチが大変で、エンジニアが疲弊するというような事態がそもそも起こりにくいようになっていますね。

── エンジニアが疲弊しないという点については先ほどお聞きしたロールの話もそうですが、プロジェクト、組織の立て付けでも担保されているんですね。

丸山　組織の仕組みとして、非エンジニア人材が担うロール、その専門家もチームに加わっています。エンジニアが本来の業務に集中できるようにサポートしてくださるメンバーがいるので、技術的な課題を解決することに集中して力を割くことができる実感はありますね。

Scrum 開発を採用しているので、1 週間や 2 週間といった短い期間で区切って都度開発計画をするのですが、決まった期間でどれだけの機能をつくるか計画をする際にはできるだけ詳細な見積もりをして、オーバーコミットはしないことを徹底しています。無理やり詰め込むより、エンジニアが100%のパフォーマンスを発揮できる計画を立てることが重要だと思っています。

佐々木　それに付随して、ソリューションオーナーが「期待値コントロール」ということをよく言っているんですけど、クライアントの要望を全部拾ってすべて詰め込むのではなく、どうしたら顧客満足につながり、システムに利する機能の実装につながるかを考えて仕事をしている方がチーム内にいることで、エンジニアが無理しすぎないでいいようにプロダクトの方向性をコントロールしてくれているんじゃないかと思っています。

── 「疲弊しないこと」は間違いなくエンジニアの幸せにつながる一つの要素だと思います。では、お二人はエンジニアの幸せってどんなことだと思いますか？

丸山　新しい技術をどんどん取り入れていける環境ですかね。開発の過程では、枯れた技術を使わなければいけないことも当然あるし、そこは適材適所なんですけど、決められたことをただ漫然とやるのではなく、新しい技術を積極的に使って課題を解決していく、それができる環境にいることが幸せかなと思います。

佐々木　自分がイケてると思う技術だったり、設計思想をチームだけでなく、クライアントも受け入れてくれて、それに対して感謝されたり、役に立っていることを認めてもらえることが一番幸せなのかなと思っています。

待機のない現場で学び、高め合う

── お二人は、メンターとメンティー関係ということですが、CTCでは、社内にメンター制度を定めているとか？

丸山　そうですね。制度としては新入社員に対してメンターがつくということになっています。中途採用にはメンターはつきませんが、その人が入社後にメンターになる可能性はあります。組織や状況により多少扱いが変わるのですが、現在の私のポジション的には「困った時の相談役」みたいな立場です。チーム全体として気軽に相談できる環境があるのですが、「これって誰に聞いたらいいんだろう？」ということを聞きやすいのがメンターなのかなと。

佐々木　例えば「AWSの勉強がしたいな」と思って情報を収集するときに、ちょっとチーム内の Slack とかでつぶやいておくと、丸山さんがこう言う資料あるよとか、この資格試験を取得するとその過程で体系的に学べるよとか、そういう情報提供をしてくださったりするんです。チーム内にはそもそも誰にでも聞ける雰囲気があるんですけど、誰に聞いたらいいんだろう？　ということもあるので、メンターになら聞いてもいいんだと思えるのは大きいですね。

── そういう技術のキャッチアップが容易な環境もある？

佐々木　弊社にはいろいろな制度があってハンズオンの教材を使いながらいろいろ試してたりできる制度もありますし、有料の教材についても補助してくれるのでいろいろ勉強できています。buildチームとして取り組んでいるプロジェクトの内容に関しても、守秘義務に関わるようなこと以外はたくさん共有してもらえるので、実際に動いている案件から学べることも多いです。

丸山　人に教えるってやっぱり難しくて、自分の持っているものを言語化することは自分の思考を整理することにもなりますよね。さまざまなロールを担う人が集まっているチームでもあるので、それぞれのスペシャリティについて教え合う雰囲気はすごくあると思います。

── build serviceについては、立ち上がったばかりのサービスではありますが、注目度も高く今後どんどん発展していくサービスだと思います。お二人がbuild serviceを通してどんなことを実現したいのか、未来の話も含めこれからの目標を教えてください。

丸山　サービスとしては、まずはいろいろなお客さまに知ってもらうこと、その良さに気付いていただくことからだと思っています。エンジニアとしては、クライアントから与えられた課題だけではなく、クライアントと一緒に最善のアプローチ、技術を考える中で、クライアント、そのサービス・機能の利用者どちらにも価値のあるものをつくっていくことが目標かなと思いますし、技術を適切に使ってお客様の課題を解決していくことが使命だと思っています。

佐々木　これからbuildチームの一員として案件にどんどん関わっていくことで、日本の企業がこれから5年後、10年後に、2025年の壁を乗り越えて、成長していけるように、微力でもソフトウエアをつくることを通してお手伝いできればなと思っています。僕個人としても、現状の世界基準、しっかりした品質、UIも含めた見た目や使いやすさもそうですけど、中身がしっかりしたプロダクトをつくっていきたいなと強く思っています。

ライター：大塚一樹