JP
Business/Technology
NTTコミュニケーションズ
ヒューマンリソース部
植田 純生
NTTコミュニケーションズ（以下、NTT Com）の技術顧問としてご支援を頂いている及川卓也氏、吉羽龍太郎氏、和田卓人氏を交えて、NTT Comグループ経営幹部との勉強会を開催しています。今年1月には「Tech Casual Lunch」と題して、ランチ時間を利用して実施しました。各技術顧問がそれぞれの専門領域である「プロダクトマネジメント（及川氏）」「アジャイル開発（吉羽氏）」「ソフトウェア開発（和田氏）」をテーマに講義を行った後、参加者全員による活発なディスカッションが繰り広げられました。
この記事では、勉強会の中で各顧問が語られた内容をいくつかピックアップしてご紹介します。
また今月には第2弾を開催しました。その模様も準備でき次第ご紹介させていただく予定です。
及川卓也さん：「プロダクトマネジメントの重要性」
冒頭、「日本産業の弱体化はIT力の低下が大きな要因の一つである」というお話から始まりました。講義の中で及川さんはあえて「IT産業」という言葉は使用せず、現代では自動車産業をはじめ主要産業は全てITをコアとして活用し発展していく時代にあり、NTTグループをはじめとする主要なIT企業の変革・発展が、ひいては日本産業・国力の復権につながると述べられました。
次に、日本のIT力低下の要因を大きく次の3つの要素に分類し解説いただきました。
１）実装軽視
２）弱いプロダクト志向／思考
３）プラットフォーム戦略の失敗
本記事では、１）と２）について詳しくご紹介します。
１）「実装軽視」について
及川さんの著書『ソフトウェア・ファースト』（出版社：日経BP、出版年：2019年）の中で説明されている内容も交えてのお話でした。及川さんが著書に込められた思いは、「プロダクト・事業開発は、ソフトウェアの破壊力（や弱点）を十分知り尽くした上で、企画段階からソフトウェアをどのように活用するかを考えながら進めていく必要がある」ということです。
しかし、日本の多くのIT企業では、下流工程に位置付けられる「実装」部分や運用が軽視されている実態があります。例えば、「あなたは3年間エンジニアとして実装をやったので、今度は設計やマネジメントにまわってください」といった考え方に実装軽視の意識が表れており、技術変化が激しいITの世界では、3年前の技術はもはや負債であるケースが多いにもかかわらず、実装フェーズでのエンジニア価値を軽んじることは、現代のプロダクト開発においては非常に危険であると及川さんは説かれました。
また、ソフトウェアをビジネスに活用していくポイントとして、製造業のプロセスとの違いを例にとり、IT業界においても「ソフトウェアをはじめとするコア技術を内製化（＝手の内化）」し、すべてのプロセス（企画・仕様検討・設計・実装・品質確認・リリース・運用）において、製造業と同じく委託側が主導権を持つことが重要であるとも述べられました。
２）「弱いプロダクト志向／思考」について
「現代においてはプロダクト≒事業そのものである」単純なもの売りから“顧客体験の最大化”に事業価値がシフトしていく中で、営業・マーケティング・開発・カスタマーサポートまで、すべての事業プロセスをプロダクトの一部として捉える必要があります。
そして、それらのプロダクトチームをけん引する「プロダクトマネージャーの重要性」を及川さんは説かれました。プロダクトマネージャーは、プロダクトの「Why／What／When」に責任を持ち、すべてのプロセスを束ねるミニCEO的な存在として、ビジョン・ミッションに基づく多くの意思決定・判断を通じてプロダクトを成功に導く存在です。
最も印象的だったお話は、プロダクトマネージャーには必要なスキルセットやフレームワークが数多くあるが、最も重要な要素は「オーナーシップ」「プロダクト愛」だということでした。「関係するメンバー全員がプロダクトのビジョン・ミッションに共感し、メンバー全員が主体的に、細部までこだわりを持ってやり抜かなければいいプロダクトは作れない」と及川さんは熱く述べられました。
後半のディスカッションの模様も少しご紹介します。
Q：プロダクトマネージャーやソフトウェアエンジニアといった人材を効果的に育成していくにはどういったやり方が有効なのか？
A：プロダクト愛のような内発的動機付けを強くするような成功事例を増やすのが最も大事。一方で、人事制度・報酬といった外発的動機付けも重要だと考えます。したがって、内発的および外発的の両方が重要であり、組織文化と制度の双方からアプローチしていく必要があります。
Q：事業としては、目先のコスト削減とか効率化を重視してアウトソースしていくケースが多いが、その中でも一定の初期コストをかけてでも、内製化を進めた方がいいのか？
A：内製化した方が絶対にトータルコストは安くなるはずです。ただ、必ずしも全て内製化にこだわる必要はなく、コアとなる部分に主導権を持って一部分を委託すること自体は決して問題ではないです。
他にも、組織設計や権限移譲、人事評価制度など活発な議論が行われました。
吉羽龍太郎さん：「新規事業とアジャイル」
講義スライドはこちらにも公開されています。
【資料公開】マネジメント向けアジャイル開発概要
(Ryuzee.com)
前半は、事業戦略の観点からクラウドやアジャイルの必要性についてご説明いただきました。サービスライフサイクルやビジネスモデル自体の短命化、Netflixのピボット、Amazonの戦略、などを例にとり、企業は事業ポートフォリオを短いサイクルで見直しをすること、つまり、体力があるうちに次の事業の柱を創り出す必要があると述べられました。
大規模システムやインフラ事業のような比較的計画が立てやすい領域に対し、新規事業創出のような複雑で変化が激しい領域では、「予測可能性が低い」ことが多くあります。従来のウォーターフォール型の開発手法では「最終的に完成したものが顧客の求めていたものではない」「必要かもしれない、とムダな機能をたくさん付加し結果的にコスト高・技術的負債となっている」ような状況を引き起こす可能性があります。
どんな開発手法であれ、あらゆるムダを排除していくことが重要であるということも、トヨタ生産方式の話を例に説明されました。従来型の開発プロセスの課題は「作っているものの有効性を検証するまでの時間と金額が大きすぎる」ことで、結果として複雑で変化の激しい領域では市場優位性を保つことが難しくなるということにつながっています。
新規事業創出のような将来の予測可能性が低い領域においては、ビジネスの作り方そのものを変える必要があり、失敗を受け入れる企業文化・体質を持ち、小さなサイズ・短いサイクルで仮説検証を繰り返しながらポテンシャルを見極めていくことが重要ポイントになります。この時、クラウドやアジャイルの適切な活用が求められることになります。
後半は、アジャイル開発の原則や方法論について「アジャイルソフトウェア開発宣言と12の原則」を紹介しながらご説明いただきました。
アジャイル開発に対するよくある誤解として、「アジャイルだからドキュメントを作らない」とか、「計画を立てない」などがあります。決してそういうわけではなく、この宣言ではアジャイルにおいて特に重視する点が表現されています。
その後、アジャイル開発を導入する際の重要なポイントをいくつかご説明いただきました。
- クロスファンクショナルなチームを構成し、チーム内でできるだけ全てのことを実施する（＝内製化を進める）こと
- コミュニケーションのオーバヘッドを減らすため、チームの人数は3～9名に保つこと
- チーム内にノウハウが蓄積されるため、チームはできるだけ解体しないこと
- アジャイルを適用すべき領域をきちんと選定する（全てではない）
- 関係者のアジャイルに対する理解と期待値を揃える
このようにアジャイルの成功には、プロセスや組織体制・価値観を変化させることが不可欠であるということを吉羽さんはご説明されました。
その後のディスカッションの模様を少しご紹介します。
Q：自組織でもアジャイル開発に取り組んでいるチームがあるが、アジャイル開発に取り組む人材の評価が非常に難しいと感じている。
A：人事評価はアジャイルでも難しいトピックの一つ。定量的に個人指標を設定しすぎると、チームとして目指すものと齟齬が生じることが多い。外資系企業では定量指標が多いイメージがあるが、実はそうではなく、ビジョンや価値観に即した行動をしているか、など定性的な側面の占める割合も大きい。チームへの貢献度を見るための360度評価とプロダクト全体の評価をチームの全員に適用することとを組み合わせたハイブリッド型の評価がおすすめです。
Q：マネージャーはどの程度技術力を持つべきなのか？
A：細かい部分まで指導できるレベルのスキルまで持つ必要はなく、会話ができるレベルでいいだろう。一方で、1on1やチームビルディングなど日々のコミュニケーションを通じたコーチングスキルやモチベーションマネジメントなど部下のパフォーマンスを最大化するピープルマネジメントの部分がAmazonなどではマネージャーに強く求められていました。
その他、組織設計やNTT Comでアジャイル開発を増やしていく方法など、活発な質疑が行われました。
和田卓人さん：「内製組織を支える技術」
前半は『LeanとDevOpsの科学』（著者：Nicole Forsgren Ph.D., Jez Humble, Gene Kim, 武舎広幸, 武舎るみ、出版社：インプレス、出版年：2018年）という書籍を題材に、ITが事業のコアになるに従いシステム開発の生産性と品質の指標が変わってきているというお話から始まりました。
例えば、クラウドコンピューティングを中心とする開発手法への変化により、品質に関する指標はMTBF（平均故障間隔）からMTTR（平均復旧時間）に軸足が移りつつあります。これは、すべての不具合をリリース前に0にすることに投資しすぎるのではなく、リリース後に不具合が発生しても早期に回復できていれば品質は高く保たれているとする考え方です。
MTTRを重視するためには、リリース後の監視やQAサポート、テスト／デプロイの自動化などに適切に投資し品質を保つことが大事になってきます。また「品質を優先するとスピードが落ちる」というのは現代のシステム開発の世界では大きな誤解であり、スピードとトレードオフの関係にあるのは「スコープ（機能の数）」で、品質とスピード自体は両立でき得ると、和田さんは述べられました。
その後、書籍の中でレポートされているサーベイの結果を紹介されました。現代のシステム開発のキーメトリクスは、リードタイム・デプロイ頻度・MTTR・変更失敗率の4つであり、これらは企業のパフォーマンス（収益性、市場占有率、顧客数、顧客満足度など）と因果関係があるということが書籍のサーベイから分かっています。
より短いリードタイム・より頻繁なデプロイ・より短いMTTR、より低い変更失敗率の企業はパフォーマンスが高い、さらに、ハイパフォーマー企業では、開発速度と品質は決してトレードオフの関係ではなく、片方が高まればもう片方も高まるというステージにあります。一方で、ローパフォーマー企業となる傾向が強いのは、「開発を外注している」企業ということも分かっています。
講義の後半では、現代のソフトウェア開発を支える「技術プラクティス」についてご説明いただきました。一昔前は、顧客満足・ビジネス創造といったプロダクト開発のゴールに対し、協働・チームワークといった「ソーシャルプラクティス」に注目が偏りがちでした。しかし現代では、継続的インテグレーション・テスト駆動開発・DevOpsに代表される「技術プラクティス」も必要不可欠となってきている、と和田さんは強く説かれました。（いいチームだけでは、いいコードは書けない）
技術プラクティスの一つである継続的デリバリの実践を支える技術的基盤は、包括的な構成管理・継続的インテグレーション・継続的テストの3つが柱になります。特に、継続的テスト（テスト駆動開発）については、さまざまなデータを用いてその有効性をご説明いただきました。こうした開発基盤へ企業として投資していくことがソフトウェア開発の開発速度と品質を高める効果がある。その初期投資は数年という単位ではなく短期間（1カ月など）で回収できる、と和田さんは強く述べられました。
他にも、リファクタリング・ペアプログラミングなど、スピードと品質を両立する現代のソフトウェア開発で再注目されている要素についてもご説明いただきました。
その後の質疑では次のような議論がありました。
Q：ペアプログラミングは人材育成の効果も期待できるのか？
A：その通りです。ジュニアエンジニアのOJTとして、シニアエンジニアとペアプログラミングをすることは育成効果が高いですし、チームのエンジニアリング力を一定レベルにすばやく引き上げることにもつながる有効な手段です。ジュニアエンジニアだけのチームでは厳しいので、内部にシニアエンジニアを確保していくことが重要となります。
Q：開発環境への投資とはどういうものか？
A：自動化等の開発基盤へのハード的な投資と、テストコードを書けるエンジニア教育へのソフト的な投資があります。大事なのは、これらの開発環境への初期投資の損益分岐点は思っているより早く来るため、決して投資を惜しむものではないということ、さらに、その受益者はエンジニアたち自身であるということを伝えていくことです。
NTT Comグループは、社外技術顧問の強力な支援を活用しながら、真の「DX Enabler®」としてお客さまから選び続けていただけるサービス・ソリューションを開発する力を身につけ、Smart Worldの実現、ひいては社会的課題の解決に一層取り組んでいきたいと思っています。
