目次
■おすすめ企業
2021.03.18 2024.01.22 約4分
伊藤忠テクノソリューションズ株式会社（CTC）がリリースした、企業のデジタルトランスフォーメーション（DX）を支援する『build service』は、顧客のDXの隠れたニーズを引き出し、推進する画期的なサービスだ。従来の「なんとなくDX」と大きく異なるのは、アメリカ・シアトルで大きな成果を収めるDXコンサルファーム、スラロームコンサルティング社（Slalom Consulting,以下、Slalom）が採用するフレームワーク、PEM (Product Engineering Method)の存在だ。顧客のDX需要を発見し、アジャイル開発で有用なプロダクトを共創するためのフレームワーク、PEMとは一体どのようなものなのだろう？ Buildサービス推進チームのソリューションアーキテクトを務める羽田野晋一氏に話を聞いた。
新型コロナウイルスの世界的感染拡大は、リモートワーク、インターネットを介したテレビ通話、会議の浸透を大幅に進めた。急激な変化は、IT業界にとってポジティブに捉えられることも多いが、企業の危機感、意識の変化が、次なる波、事業のDX化に進む可能性は高い。
「コアビジネス影響が出ている企業は結構多いように感じます。事業ドメイン自体の変化まではいかなくても、なんらかの方向転換の必要性、危機感がある空気はありますよね。そういう意味では、いまbuild serviceをスタートさせるのはいいタイミングじゃないかなとは思っています」
Buildサービス推進チームでテックリードを務める羽田野氏は、新機軸ともいえるbuild serviceの立ち上げへの手応えを語る。
CTCが捉えるDX の本質は、企業の競争上の優位性を確立すること。既存業務のデジタル化による効率化、最適化だけでなく、技術を使って新たな価値を生むような共創へのニーズが高まっていることは、まさに「必要は発明の母」というところだろう。
羽田野氏がプロジェクトで担うロールは、デジタルプロダクト開発ソリューションアーキテクト。このロールは、build serviceの範となった米・Slalomが採用するフレームワークPEM (Product Engineering Method)に基づいたものだ。
「みなさんになじみのあるロールでいうと、テックリードに近いですかね」
テックリード、リードエンジニアといえば、プロダクト開発やプロジェクトにおいて主動的な役割を果たすエンジニアのリーダーのこと。マネジメント要素より「技術でエンジニアチームを引っ張る」側面が強いロールだが、ソリューションアーキテクトはPEMの独自性にともなって、その他複雑な要素を内包するロールになっている。
PEMは、①プロジェクト全体のプレセールスに当たる『ENGAGE』、②クライアントとビジネス要件を議論し、実現可能性を検証する『DISCOVER』、③エンジニアがアジャイル開発を担う『DELIVER』、④クライアントの自走を支援する『TRANSLATION』の四つのフェーズで構成される。
ソリューションアーキテクトは、②『DISCOVER』で、クライアントともにDXに寄与するプロダクトを”発見”し、実現のための十分な準備を行い、③『DELIVER』のフェーズでは、設定された技術要件に沿ってプロダクト開発を主導的に進めることになる。
ここからは、羽田野氏が担うソリューションアーキテクト、build serviceでも採用されるフレームワーク、PEMを通して、今回CTCが実現しようとしている開発手法に迫っていこう。
羽田野 ソリューションアーキテクトは、開発の比重が大きいテックリードとは違って、開発前のプロダクトのアイデアの方向性と実現性、実行性を開発前に検証することがタスクとして加わってきます。開発フェーズでは技術面の中心となるのでここはテックリードと言ってもいいロールなのですが、build serviceでは、アジャイル開発を円滑に進めるためにSlalomのPEMというフレームワークを採用しているので、テックリートの差分が大きな違いになると思います。
――従来のアジャイル開発、日本におけるアジャイル開発では、発展可能性という魅力はありつつ、現場では混乱が生じたりクライアントとの齟齬が生まれたりするケースもありますよね。
羽田野 アジャイル開発では、「取りあえずやってみよう」「やってみなきゃ分かんないよ」みたいな感じで始まることが多いですよね。PEMを採用している私たちは、開発の前段階で、「ちゃんと準備しましょう」という考え方が強調されています。
新しい技術、例えば VRのような技術を使いたいというアイデアが出たとします。これを取りあえず採用して走りながらやっていきましょうとするのではなくて、お客さまのニーズをかなえるために本当にVRを使う必然性があるか？ 技術自体に普遍性があるか？ などの検討を行い、プロダクトオーナーと一緒に、完成するプロダクトを実効性のあるものにするために実際の開発に踏み切る前にちゃんとした準備をする。ここの部分が重要な役割かなと思っています。
── 『DISCOVER』というフェーズがアジャイル開発の肝になるのかなと思うのですが。要件定義でもなく、企画でもなく、「DISCOVER＝発見」なんですよね。そこは面白い視点だなと
羽田野 そうですね。従来のSIerのような「仕様決め」というやり方ではなくて、クラウドでアーキテクチャーのモダナイズをする、クラウドネイティブで回せるようなプロダクトを提案するという提案型の要件定義と言うんですかね。お客さまのビジネスが変わるような提案型の要件定義をします。
── このフェーズ、ソリューションアーキテクトの具体的な作業の流れはどんな感じになるんですか？
羽田野 ちょっと細かくなるんですけど、まずステークホルダーへのインタビューを実施して、ビジョンやミッション、目的を確認させていただき、顧客分析をしながらターゲットアーキテクチャーを決定します。アプリケーション開発ではアジャイルツールの決定、最初のプロダクトのバックログの作成、バックログには優先順位を付け、プロダクトロードマップを作成してストーリーポイントの見積もりを行って、ようやくデリバリーチームの形成になります。
── クライアントとの「発見作業」は、ソリューションアーキテクトが一手に担うんですか？
羽田野 DISCOVERフェーズでは、ソリューションアーキテクトの他に、ソリューションオーナー、エクスペリエンスデザイナーのロールを持つ3名がクライアントと話します。この3つのロールは、セットで動いているというか、開発が始まってからも3人が各分野をリードする形になります。
── PEMは、Slalom社での取り組みがお手本だと聞いています。このフレークワークのどんなところに先進性を感じますか？
羽田野 方法論というより、北米で大きく成功しているということが要素としては大きいのかなと思っています。1000人規模の開発者、エンジニアを抱えているコンサルファームが、ここ10年でDX支援で成長してきている。その手法にはすごく興味がありました。
── build service立ち上げ前に、シアトルにあるSlalomに研修に行かれていたんですよね。
羽田野 5カ月弱行っていました。
── 日本との違い見たいなものは感じましたか？
羽田野 環境や業務というより、エンジニアという仕事に対するエンジニア自身の考え方の違いが心に残りました。彼らは、自分が持ってるスキルや 経験にアイデンティティを持っているんです。日本人だと所属している組織、会社を最初に言う人が多いんですけど、 Slalomでは、自分がどんなことができるエンジニアかというのが先にくるんです。
話をしていてもメディアを見ても、自分のできること、得意分野を押し出した〇〇エンジニアみたいな肩書がどんどん生まれている。そういうのはやっぱり日本の文化とはすごく違うなと思いますね。
エンジニアにはそれぞれのアイデンティティ担っているスペシャリティをどう活用して、どう成果に結びつけるかということを、エンジニア一人ひとりがそれぞれ考えているんです。そういう人たちが集まって大きな成果を生み出している。組織としても意識、働き方にしても日本人とは根本的に違うような気がしています。
── 羽田野さんのキャリアについてお伺いしたいんですけど、どんなキャリアを歩んでbuild service、その鍵を握るソリューションアーキテクトのロールを務めるようになったのかを。
羽田野 200年に入社して、ソフトウエア開発のキャリアを積んできました。入社時点で、エクストリームプログラムとかアジャイルの2回目の波が来たところだったんですけど、私自身、早い段階でテストの自動化などにエンジニアとして関われたのがその後のキャリアに大きく影響していると思います。
その後、2008年くらいに AWS が出てきて、ソフトウエア開発にフォーカスしたいなというという時期があって、ソフトウエア開発の社内標準化に関わって、横串を通して社内の標準フレームワークを策定するような仕事をしていました。2012年ぐらいからアジャイル開発の推進活動を担うようになって、その流れがあってbuild serviceでもアジャイル、DXの推進、旗振り役をやるようになったというところです。
── キャリアの最初からアジャイルに関わっていたんですね。なかなか一言では難しいと思いますが、羽田野さんから見てアジャイルってどういうものだと思いますか？
羽田野 開発手法とかテクノロジーの話ではないのですが、言われたものを言われたままにつくるのではなく、お客さまであったり、社会に対して価値のあるものを作る。そのためのやり方、考え方がアジャイルなのかなと思います。
── エンジニアのキャリアの中で大切にしてきたこと、一貫して守ってきたことはありますか？
羽田野 一つはやっぱり新しいことにチャレンジしていくことですかね。自分ができる範囲、単にできることを続けていくというよりは、新しいことにチャレンジをしていくことがすごく大事だなと思っています。その上でそのチャレンジをちゃんと成功させることがさらに大切で、たくさん経験したから成功率が上がるかというと、どうやらそうではないという研究データもあるんですよね。新しいチャレンジをしつつ、成功体験を継続していかないといけない。戦略とか計画を立ててしっかり準備をした上で思い切りチャレンジするのことを心がけています。
── 技術でいえば新しいものが次から次に出てくる世界だと思うのですが、それをキャッチアップするためにやっていることはありますか？
羽田野 グローバルな視点は大事だなと思っています。昔は海外の情報を仕入れることが難しかったですけど、 SNSやいろいろなメディアを通じてグローバルな情報が仕入れられるようになりました。弊社もアメリカにブランチがあるので、できるだけグローバルでの新しい情報を仕入れて、トライするみたいなことは続けています。
── グローバルな視点で新しいことでいうと、build serviceがまさに北米の最新の成功トレンドを日本化してDXの推進にトライする試みだと思います。ソリューションアーキテクトとして心がけていることはありますか？
羽田野 一番大きいのは、従来のSIer的な動き方、ウォーターフォールの請負仕事ではないということですよね。標準化して要件に沿って、その通りにやるのではなく、チームにどんな人をアサインするのかというところから、考えなければいけません。個を生かす、それを前提にしてチームを生かすことを心がけています。
PEMでは、スペシャリストなロールが多い様に見えますが、ソリューションアーキテクトは役回り的にはジェネラリストの部分が必要になると思っていて、全体を俯瞰的に見て戦略を立てられる、広い知識を持ってる人が向いているのかなとは感じています。
── 今後build serviceが成長していき、エンジニアやさまざまなロールを担う人材が必要になってくると思います。どんな人と一緒に働きたい、どんな人にチームに加わってほしいというのはありますか？
羽田野 「能動性」は重要なファクターかなと思います。既存のビジネスのやり方、フレームワークに乗っていけば成果が出せるというやり方ではなくて、新しいビジネスが始まって、そこで自分の特徴や得意分野を生かしてチャレンジできる人。自分で課題を見つけて、能動的に動ける人のが私から見ると魅力的に感じます。
── Slalomで出会ったエンジニアたちのようにアイデンティティを持ってるエンジニアということですよね。
羽田野 そうですね。エンジニアがアイデンティティを確立しつつ、チームとして良い仕事ができる。お客さまのビジネスが大きくなっていくという指標でわかりやすく貢献できているという状態を将来的につくりたいと思っています。
お客さまや社会にとって意味のある、価値のあることが広がっていく状態をテクノロジーで実現する。それが何なのかを見つけるところから関われるプロジェクトだと思うので、SIerのに対する受動的なイメージが大きく変わるような、社会に対して変化をもたらすようなことをこれからも仕掛けたいと思っています。
ライター：大塚一樹
