デジタルビジネスの競争が本格化する中、ニーズの変化に迅速に応える上で、アジャイル/DevOpsはもはや不可欠なアプローチとなっている。このような時代に開発現場はどうあるべきなのか。ITエンジニアに必要なマインドセット、技術などについて、アジャイル/DevOpsを実践し続けるヤフーの塚穣氏とプロダクト・エンジニアリングアドバイザーの及川卓也氏に聞いた。
デジタルビジネスの競争が本格化する中、ニーズの変化に迅速に応える上で、アジャイル/DevOpsはもはや不可欠なアプローチとなっている。だが、新しいことに取り組みやすいスタートアップや新興企業とは異なり、既存事業、既存システムの上に立脚してきた一般的な企業がアジャイル/DevOpsに取り組む上では、さまざまなハードルがあるのが現実だ。
このような時代に開発現場はどうあるべきなのか。組織、体制はどうあるべきか。ITエンジニアに必要なマインドセット、技術などについて、アジャイル/DevOpsを実践し続けるヤフーの塚穣氏とプロダクト・エンジニアリングアドバイザーの及川卓也氏が対談を行った。
――あらためて、ご自身の直近の活動について教えてください。
塚氏 SRE部の部長として、ここ2年は“エンジニアがつらい仕事をなくす”仕事に取り組んでいます。例えば、社内のエンジニアがもっと簡単にモノづくりができるようにNoOps環境の整備を進めたり、エンジニアの関わるシステムの状況を把握できるよう監視ツールを提供したりしています。医療でいえば、対症療法ではなく、予防医療を提供しているような感じです。楽をするためには、どこかで苦労が必要なので、その苦労をSRE部の40人が担うことで、社内にいる3000人のエンジニアやデザイナーなどクリエイターたちが良い仕事をできるようにサポートしています。
及川氏 私は外資系企業を渡り歩いてきましたが、約1年前にフリーになり、現在は日本の大手企業5社をメインに、スタートアップも含めてさまざまな業種、規模の企業のアドバイザーをしています。主な仕事内容は、良いプロダクトを生み出し続ける組織体制づくりを支援する「エンジニアリングマネジメント」、プロダクト戦略の立案や実施、プロダクトのグロースを支援する「プロダクトマネジメント」、そして純粋な「技術アドバイス」の3つです。
メガITグローバル企業に勤めた経験の中で、成功している企業にはモノづくりの秘訣があることを実感しました。その秘訣を多くの日本企業に紹介し、日本ならではの形で発展させていければと考えています。
――アジャイル/DevOpsのチーム/部門ごとの理解度について教えてください。
塚氏 当社では、アジャイル/DevOpsの理解度について、クリエイター部門の部門長に対して毎年アンケートを行っています。2017年の集計ですが、理解度は6割を超えたくらいですが、おそらく真の意味で実践できているのはその中でもさらに1〜2割程度ではないかと思っています。
及川氏 アジャイルという言葉だけの認知度ならば、日本の企業全体でも6〜7割はあると思います。ただ、不安なのは、その言葉の中身をどこまで知っているのかということです。アジャイルをふんわり理解しているというのは、逆に危険な状況だと感じます。いろいろなところで“魔法の杖”のように「アジャイル」という言葉が出てきますが、それぞれの「アジャイル」が同じものを意味しているかは疑問です。
本来、アジャイルもDevOpsも手段であり、その言葉の前には解決すべき課題や目的があるはずです。とくにアジャイルについては、「アジャイル宣言」があるように、ウオーターフォール型モデルの課題をどう解決すべきかを考えるのが最も重要で、その手法としてスクラムなどを活用していくことになります。今は、このアジャイルの精神がフワッとしたまま、言葉だけが独り歩きしてしまっているように感じています。
――アジャイル/DevOpsについて、どのような組織、体制で取り組んでいるのかについて教えてください。
塚氏 部門によって違いますが、基本的には、1プロダクト4〜8人のチームでアジャイル/DevOpsに取り組んでいます。例えば、社内システムを使うユーザーの手元に直接プロダクトをデプロイしていくようなプロダクトでは、ディレクター、デザイナー、エンジニア2人の計4人で小さなチームを組んでいるようなケースもあります。こういったチーム単位でプロダクトディスカバリーから始めて、プロットを開発し、社内テストを行い、評価されたものを3カ月後くらいにローンチするという動きをしています。
巨大なプロダクトの場合は、「Scrum of Scrums」や「LeSS(Large-Scale Scrum)」にも取り組み始めています。1つのプロダクトに複数チームでスクラム開発を行っていくのですが、全コンポーネントに各チームが触れられるようにします。また、プロダクトのオーナーシップは別の部門に持たせることで客観性を保つようにしている部門もあります。まだ始めたばかりなので、これからもっと練習が必要だと思っています。
システムの開発や構築を外注するケースもありますが、あまり永続的にお願いするようなことはせず、限定的なお願いが多いです。個人的には、自ら企画、開発したプロダクトを、自らデプロイすることが重要だと思っているので、そういった観点で、できるだけのことを自分たちでやろうとしています。
及川氏 確かに開発を全てフルアジャイルにするのが理想ですが、現実を見ると、それでは回らない開発現場はたくさんあります。特に、日本企業のほとんどの開発現場は外注だらけです。
例えば、ウオーターフォール開発をメインにしている受託企業から派遣されたエンジニアが、業務委託でフルアジャイルの開発現場に入り、アジャイル開発を学んだとしても、自分の派遣元企業ではそのエンジニアのキャリアにプラスになることはありません。また、その派遣エンジニアのマインドセットは、「決められた仕様通りに開発すること」なので、それをすぐに変えるのは難しい。アジャイルに取り組む際には、まず課題を明確にして、その課題をどうやって解決するかを考えた上で、プロジェクトごとにアジャイルの適用範囲を決めていくことが現実的だと思います。自社以外のエンジニアにどのように参加してもらうかというのも考えないといけないことです。
――今後、エンジニアはどう変わっていくべきか、マインドセットについて教えてください。
塚氏 マインドセットとして、僕はスクラムの5つの価値基準を大事にしています。「尊敬」「確約」「集中」「勇気」「公開」の5つなのですが、この価値基準は否定しづらいものばかりです。この価値観多様性を重んじており、相手との関係がうまくいかなかったり、仕事のやり方が気に入らなかったりしても、それを受け入れ、敬意を持って相手のことをサポートしようというマインドセットだと理解しています。これを実践していれば、仕事上で争いが起こることも少ないと考えています。この5つの価値基準までも否定してくる人とは、さすがに一緒に仕事をしたいとは、あまり思わないでしょう。
及川氏 私は、対立軸の立て方がマインドセットのポイントだと思っています。例えば、カスタマーサポートのスタッフとクレームを訴える顧客との間に対立軸が発生することがありますが、実はここに対立軸はないのです。本来は、トラブルそのものに対立軸があって、顧客とコールセンターのスタッフが一緒になって、トラブルに対峙していく必要があります。アジャイルにも、その考え方が大切です。顧客とスクラムチーム全員が、解決すべき課題や達成すべき世界観を共有することで、現場でさまざまな対立が発生したとしてもそれ自体には意味がなくなり、本当に対立すべき“課題”や“目標”に向けて、チーム一丸になって向かうことができると考えています。
――エンジニアを取り巻く環境を変えるために何をしているのか、今注目している技術や手法を教えてください。
塚氏 SREの観点から「カオスエンジニアリング」に注目しています。私は、エンジニアほど自分以外のことのために脳を使っている職業はないと考えています。それだけに、他の煩わしいこと、例えば人がやらなくていいものは機械に任せたい。いわゆるNoOpsを実現することが重要だと思っています。その一つが障害対応で、何らかの障害が起こったときに、自動的に動いて対処してくれるシステムを用意しておけば、運用負荷は大幅に軽減できます。ここに、カオスエンジニアリングが重要な役割を担うと期待しています。
また、エンジニアは自分で作ったものに対して慢心してしまう傾向があるのではと私は考えています。その伸びた鼻を折ってくれるという効果もあります。特に成熟したプロダクトこそ、カオスエンジニアリングによって内部から壊してみるのもよいと思っています。カオスエンジニアリングで発見された障害は、いずれ起こるものです。であれば、実際に起きる前に体験しておくことで、最適な対処法を見つけることができます。障害発生のリスクと、その対処法のバランスを表現しているカオスエンジニアリングは、非常に奥深い技術だと感じています。
また、リモート開発という観点からは、「Visual Studio Live Share」にも注目しています。最近、九州に新たなチームを作ったのですが、そのチームとは常設のテレビ会議システムでコミュニケーションをとるとともに、「Visual Studio Live Share」でエディタを共有して開発を進めています。さすがに毎日九州には行けないですし、九州まで行かなくても毎日顔を合わせながらコードを通して会話ができるので、重宝しています。また、エディタの中でターミナルも開くことができますので、リモート開発の阻害要因がだいぶ減って素晴らしいと感じています。
及川氏 私は監視の技術をもっと有効活用できるのではないかと思っています。今は、監視できる領域は限られていますが、本当は全ての物を監視できると考えています。例えば、あるサービスが解約されたとき、解約防止のためにカスタマーサービスのチームが後追いで顧客に解約理由をヒアリングしています。しかし、解約を決める顧客には、それまでに典型的な行動パターンがあるはずです。この動きを察知できるような監視インフラがあれば、解約リスクを低減できるのではないかと思います。一見、定性的にしか判断できないようなものも、どこかに定量化できるポイントがあるはずなので、それを認識できる技術に期待しています。
――デジタルトランスフォーメーション、アジャイル/DevOpsを実践するためのIT人材が足りないと言われる昨今、今後、IT人材が増える社会になっていくには、何が必要と考えますか?
及川氏 これは、答えるのは簡単な質問ですね。エンジニアの給料が上がれば、IT人材は確実に増えます。例えば、中国では、優秀なエンジニアは営業マンの3倍の給料をもらっています。そうすることで、優れた人材がエンジニアになり、良いプロダクトが生まれてくる。この結果、企業競業力が高まり、収益が上がり、エンジニアへの投資がさらに拡大していく。こうした仕組みを日本でも作ることができれば、優秀なIT人材が常に集まるようになると考えています。
塚氏 私も同感です。
及川氏 日本企業のほとんどは、エンジニア職の昇格先としてマネジャー職があるという構造ですが、これも見直すべきです。エンジニア職とマネジャー職のラダーを別にすれば、マネジャー職よりもエンジニア職の給料が高くなっても不思議ではありません。ただし、マネジャー職を超える給料をもらうためのハードルは高いものになるでしょう。例えば、50人の組織を管理しているマネジャーを超える評価を得るために、エンジニアは何をすればいいのか。これについては、エンジニア自身も考えてほしい。そして、そこから上がってきたアイデアから、エンジニアの新たなロールモデルが生まれてきてほしいと思います。
塚氏 実際に当社では、エンジニア職とマネジャー職、それぞれのラダーを設けています。「ある道を極めたい」という気持ちも、その人にとっては自然な欲求だと思うので、そういった方へのキャリアパスも当然用意すべき、と考えています。
――今後の日本のITを担う若手エンジニアにメッセージをお願いします。
塚氏 私は、“実感”のある仕事が効率良くできていることが大切だと考えています。会社への貢献でも、自分自身の成長でも、日々の仕事の中で何かを実感していれば合格点です。もちろん、残業は絶対にしないことが前提です。そうしていると、自然と周囲から一目置かれる存在になっていくと思います。
また、顧客のことを最優先に考えることも重要です。SRE部の顧客は、社内のエンジニアですが、そのエンジニアは社外のユーザーに向けてサービスを開発しています。SRE部が、社内のエンジニアに価値あるツールを提供できれば、サービス価値の向上につながり、ユーザーが増え、結果的に会社の利益につながることになります。まずは、一番近くにいる顧客を幸せにするための腕を磨いていくことが大切です。
及川氏 エンジニアのすごさを、もっと周りに伝えていってほしいと感じています。特に、ITにあまり投資していない企業のエンジニアは、決められた仕事をするだけではなく、自分たちの技術力でこんなものが開発できるということを実際に見せていってほしい。そうすることで、エンジニアに対する周囲の見方が変わってくると思います。例えば、定形処理を自動化する簡単なRPA的なものであればすぐに作れるはずなので、社内の現場で非効率なところがあったら改善するためのツールを作ってしまえばいい。エンジニアは“魔法使い”であるということを自ら積極的にアピールしていくことで、経営陣のマインドを含めて周囲を変えることができるはずです。
本記事でご紹介した「ヤフー」に関するアンケートを実施中です。
アンケートにお答え頂いた方から、抽選で10名様にQUOカード3,000円分を差し上げます。ぜひご回答ください。
※賞品(QUOカード)の発送をもって発表にかえさせていただきます。
※賞品(QUOカード)の発送は、2018年10月上旬以降を予定しております。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:ヤフー株式会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2018年9月27日