2020年3月、NTTコムウェアに新たに誕生した伊山エバンジェリスト（Agile）。
今回は、「テレワーク時代のエンタープライズアジャイル」をテーマに、アジャイルアプローチという観点では同源であるDevOpsの加藤エバンジェリスト、上栗アソシエイトエバンジェリストが話を聞きます。
コロナ禍でもアジャイル開発を成功させていくには？変わりゆく働き方の中で必要なコミュニケーションと、現場から見える理想と現実。そして、マネジメントの未来に迫ります。

• 

  伊山エバンジェリスト(Agile)

  アジャイルコーチとして社内外へのアジャイル開発の普及活動のほか、NTTグループ全体へアジャイル開発を推進する活動のコアメンバとしても活動中。

• 

  加藤エバンジェリスト(DevOps)

  入社以来、仮想化、IaaS、PaaS、オブジェクトストレージ、コンテナ等のクラウド関連技術の研究や実用開発を経て、2018年には「DevOps Agile Skills Associationアンバサダー」に就任。

• 

  上栗アソシエイトエバンジェリスト（DevOps）

  ネットワーク技術を中心に、クラウドサービスやキャリアグレードの大規模システム開発を経験。現在はDevOpsプラットフォームのプロダクトオーナーを担当。

アジャイル開発を普及する活動とは

－加藤：
　NTTコムウェアのエバンジェリスト(Agile)に就任されたということで、まずは、おめでとうございます。皆さんに伊山さんを知って頂くため、簡単に自己紹介をお願いします。

伊山：
　ありがとうございます。技術企画部 技術SE部門 システム開発技術センタ所属の伊山です。2009年NTTコムウェアに入社しました。2014年頃からアジャイル開発に携わり始め、現在社内のアジャイル開発案件の立ち上げ支援や、社内外での普及活動をしています。また、NTTグループ全体でのアジャイル推進施策ではコアメンバーとして活動しています。2020年3月、NTTコムウェアのエバンジェリスト（Agile）を拝命しました。

－加藤：
　エバンジェリスト（Agile）の役割と活動をどう捉えているか教えてください。

伊山：
　大きく二つあります。ひとつはNTTコムウェアがアジャイル開発の先駆的企業であり、お客様のビジネスを変革することが出来る企業である、ということを世の中に広く認知してもらうこと、つまり企業プレゼンスの向上です。
　そのために、社内外でのアジャイル推進・支援、お客様へのコンサルティング、社外でのイベント講演などが現在の主な活動になっています。これまでAgile JapanやNTT Agile Meetupなどのイベントで講演を行ってきました。
　もう一つは社内のアジャイル開発を推進していくことです。そのためにはお客様のマインド変革や理解も必要不可欠なことから、お客様側の変化に寄与する役割も同時に期待されていると考えています。

－加藤：
　では、伊山エバンジェリストの専門領域であるアジャイルについて少し聞いていきます。
社内でのアジャイル推進が役割の一つということですが、NTTコムウェア社内のアジャイル普及率、または案件数はどれくらいなのでしょうか？

伊山：
　2016年は一桁台でまだまだ少なかったのですが、年々倍以上に大きく増加してきました。今年度もコロナ禍の影響はあるものの昨年度を超える見込みです。昨今の業界動向を鑑みると今後も飛躍的に伸びていくと予測しています。
　とはいえ、会社全体の案件数の割合で言えばまだまだウォーターフォールの方が大きいですね。

アジャイル技法を開発チームに
適合させるコーチング

－加藤：
　アジャイルにもいくつかの技法が存在すると思いますが、それらのアジャイル案件プロジェクトはどんな技法を選択しているのでしょうか？

伊山：
　やはり、日本でのアジャイルはScrum（スクラム）がデファクトスタンダードになりつつあります。XP（extreme programming：エクストリームプログラミング）など他の有名な技法もありますが、異なる技法が混在すると社内で会話をするうえで認識の齟齬が生じてしまうため、我々はScrumの適用を基本にしています。
　ただしScrumはとてもシンプルなフレームワークなので、実践するうえではXPなどから技術的なプラクティス等をチームごとに選択して取り入れています。

－加藤：
　SIerという性質を鑑みると、自発的にアジャイル開発を取り入れる事は少ないように思いますが、お客様がアジャイル開発を希望することが多いのでしょうか？

伊山：
　確かにどちらかというと、お客様側がエンドユーザーの要望を取り入れてビジネスを柔軟に変化させたい、だからアジャイルでやりたい、そんな相談を先にされるケースが多いですね。
　また、コムウェア自身が企画するサービス開発においても、プロジェクトが自発的にアジャイルを選択するケースが増えてきています。どちらもビジネス的な戦略としてアジャイルを選択しているケースが多いということですね。

－加藤：
　当社のアジャイルはScrumが主流ということですが、エンタープライズにおいては伊山エバンジェリストも資格をお持ちでいらっしゃる、SAFe® (Scaled Agile Framework)（※1）も無視できないと思います。SAFe®の案件というのはNTTコムウェアでは未だ発生していないのでしょうか？

伊山：
　エンタープライズでアジャイル開発を広げて行く上では、SAFe®のような、上位層も含め戦略をどう複数チームでの開発に落とし込んでいくか、という思考も重要になります。今はまず１チームでScrumをキチンと定着させるところに注力しているのですが、「事業部で大規模に取り組んで行きたい」というお客様が出始めてきているのも事実です。
　SAFe®については2年くらい前からフレームワークの調査、事例収集、研修受講などを通じてナレッジ整備を行ってきました。ただ、実践経験が足りないので先駆企業にナレッジの支援を受けるなどして2021年度には案件適用できるように準備しています。

－上栗：
　お客様からアジャイル開発を希望された時に、ウォーターフォールに慣れている開発者（開発チーム）はかなり戸惑うと思うのですが、そのような戸惑いにはどう対処されているのでしょうか

伊山：
　それはすごくあるんですよ。開発チームもウォーターフォールに慣れているので、アジャイルに慣れるまでは、現在の自分自身の作業や取り組みをよく理解できていない時期が少なからずあります。その対処のため、アジャイル経験者をチームに参画させたり、私を含む社内アジャイルコーチによる立ち上げ支援を行うなど、未経験者をフォローできる体制・仕組みを取るようにしていますね。

加藤：
　ウォーターフォールで言うと〇〇みたいなもの、という変換をしながら理解するので、ウォーターフォールに無いものは、なぜこれで良いのか、あるいは、なぜこれではいけないのか、どうしてこれでやれると思えるのか、自分の中で腹落ちしない時期が初期段階にはありますよね。

伊山：
　そうですね。さらに、上司やお客様にもアジャイルに対する誤解や思い込みがあると、チームに悪影響を及ぼすことになります。例えば、よく分からないけれど有効そうだから、とか、早く簡単に良いシステムが出来るから、とか、そういった幻想を、あたかも現実であるかのように期待してアジャイル開発を選択してしまい、実際に開発がスタートしてから徐々にその幻想と現実が乖離してくると、今度は開発チームへしわ寄せが行ってしまうようなケースです。

上栗：
　こうなるはずだったのに、全然進んでないじゃないか、予算ばかりが膨らんでいるじゃないか、ウォーターフォールの方が良かったんじゃないか、もういいから早くやれ！こういう感じですよね

伊山：
　まさにそれですね。しかし開発メンバーもまだアジャイル開発に慣れていないので、現状の進捗や課題をうまく説明できなかったりします。そうすると上司やお客様は「大丈夫なのか、あのアジャイルチームは」と懐疑的になってしまう。
　ですから、開発チームはもちろんですがその上司である管理者や上位層、そしてお客様にも「アジャイル開発とはこういうものです」という研修を行い、全体でマインドを変革する取り組みがとても重要です。

進むテレワーク、
リモートでやってみて分かる
本当の仕事の価値とは

－加藤：
　さて、本日のもう一つのテーマであるテレワークについても聞かせてください。開発プロジェクトの支援という立場で見ると、支援先のプロジェクトもテレワークになっていると思いますが、やり易い、あるいはやり難いというのはありますか？

伊山：
　支援先もほぼテレワークになっていますが、リモート開発の支援は試行錯誤しています。ただ、イベント（会議等）がリアルからWebになったことで、１日で対応できる案件数が増えましたね。
　反面、リアルだから分かること、例えばチームメンバー間の関係性とか、発言していない人の受け止め方、感情の動きとか、そういった空気感が読み取れないことが案件を進める上で難しいと思っています。

加藤：
　SIerとしてみると、どちらかと言えば有利な環境ではないと思うんですね、withコロナの世界というのは。でも、これまで一つ所に集まってやるのが当たり前だったことが、withコロナの世界ではリモートでやらざるを得ない。で、やってみたら、意外とできるんじゃねコレ？という感触もあります。

伊山：
　これまではアジャイルも一か所に集まってやることが推奨されてきましたが、やらざるを得なくなって、やってみると、問題が無い訳ではないですが、思ったほど悪くない、意外と回せるな、という感触を私も持ちました。

加藤：
　テレワークをやっているうちに、以前にも増して「何でこんな価値のない事をやっているのだろう」というのが目につくようになりました。自分に対してではなくても、誰かが別のチームメンバーに依頼した事ですら、何故この人はこんな価値のない依頼をするのだろう、そして、この人は何の疑いもなく応答するのだろう、そんなふうに考えるようになりました。

上栗：
　これまでは、それが非常に大事なことのような、ある種の臨場感みたいなものに支配されてやっていたのですが、日常の雑音が無くなり文字情報だけが目に飛び込んでくると、何て無駄な事が多いんだろうと、テレワークではそれを強く感じるようになりました。

－加藤：
　制度は必要なんですが、その制度運用のために更に細かい運用ルールがどんどん増えていく。それらはアジャイルでも足かせになりませんか？

伊山：
　マズさに気が付かないと制度も変わっていかないと思います。我々もアジャイルの実行面と企業内制度の整合性を取るのに非常に苦労しています。声を上げれば気付いて変えてもらえるのはまだ良い方です。これは多くの大企業では必ず突き当たる問題で、かなりハードルの高い課題です。

加藤：
　価値の低いこと、無駄なことが浮き彫りになってきたのは、各個人が仕事の重要度・優先度を判断するようになったのが大きな要因ではないかと思っているんです。まさにインバスケットゲームを毎日リアルでやっているようなものです。
　でもこれはゲームじゃない。現実として必ず因果になる。だからスピードが必要なこと、結果が重要なこと、それらに対してより多くの力を注ぎたくなる。そうすると相対的にどうでも良いと思える事の順位が下がり、何回か繰り返すうちに「これが一体何の価値を生むのか」と突き詰めることになる。

伊山：
　まさにアジャイルアプローチですね（笑）。
　NTTコムウェアがスゴイと思ったところは、テレワーク実施にあたって、協力会社を含めた全てのエンジニアにテレワーク用アクセス端末を調達して、SmartCloudデスクトップやDevaaS 2.0というインフラは既にあったにしても、それを一気に開放して短期間で軌道に乗せたということです。こういう思い切った事ができるというのは驚きでした。
　我々エバンジェリストだけでなく、テレワークを通じて価値を考える意味に気が付いた人はたくさんいると思います。これらの人が声を上げることによって、良い方向へ思い切り舵を切る、こういう事もできる会社なのではないか、私はそう期待しています。

テレワークでアジャイル開発、
成功のカギは？

－加藤：
　これまでアジャイル開発では、可能な限り同一ロケーションで行うことが望ましいとされてきましたが、こういったテレワーク環境では、どのように進めて行けば良いのでしょうか。NTTコムウェアだけでなく、いま、日本中の企業が試行錯誤している状況だと思います。

－上栗：
　そもそも、アジャイルは同一ロケーションでやる方が良い、と言われる所以はどんなものなんでしょうか？

伊山：
　コミュニケーションと情報ロスの問題が第一だと思います。情報の引継ぎ、受け渡しはフェイストゥフェイスの方が、ドキュメントよりも齟齬がなく、問題があればすぐその場で解決を図ることができる。つまりコミュニケーションが正確で円滑であるということです。例えば、不明瞭な点があれば、すぐにその場でホワイトボードに描き、納得するまで議論する、そういう事がリモートでは困難と思われてきました。
　しかし、現代では、リモートでもかなりの臨場感を演出できるツールが揃ってきています。それらが無かった時代のセオリーを単純に持ち込むのは得策ではありません。今は、「リモートだとアジャイルは難しい」とは必ずしも言えない時代になってきています。

上栗：
　なるほど。実はつい先日カットオーバーした開発でリモートScrumをやっていて、私はプロダクトオーナーを務めていました。

伊山：
　そうなんですね、是非リモートScrumの体験を聞かせて頂きたいです。

上栗：
　最初の頃はやっぱりコミュニケーションロスが課題になっていました。ちょっと声をかけて聞くとか、ホワイトボードで説明とか、そういう手段が取り難いという点です。また、自分のメッセージを相手が理解して受諾したかどうか分からない、一方向通信が多くなるなどの問題がありました。
　で、どうしたかというと、開発チーム全員がWebミーティングを朝から一日中つなぎっぱなしにしておく事にしたんです。誰かに、もしくは誰ともなく、声をかけたい時に声をかけられるように。

伊山：
　それは面白いですね、ミーティングというよりは、ワークプレイスを仮想化する感じですね。それで、結果はどうでしたか？

上栗：
　非常に上手くいったようです。レトロスペクティブでもこの改善が良かった点に挙げられていました。また、テレワーク環境ならではの効果もありました。普段あまり議論に参加しない人、自分からは積極的に発言しない人が、この環境下では必要な情報を得るために自ら発信せざるを得ない。そうなると、フェイストゥフェイスの環境より、かえってコミュニケーションが活発になったりしたんですね。

伊山：
　私が担当する支援案件でも、リモートであるがゆえのルールをいくつか追加しました。コミュニケーションが一方向にならないように必ず何らかの応答をすること、というのもその一つです。チャットでの全体向けのメッセージは、些細なことでもまず応答をするようにチームに提案しました。
　上栗アソシエイトエバンジェリストの体験にもあったように、発信力の少なかった人が、自ら発信せざるを得ない状況というのはまさにその通りで、本人は好んでいないかもしれませんが、この状況がチームとしては良い面を引き出せていることもあるのかなと思いました。

加藤：
　プランニングポーカーをやる時に、表情が見えないので、自信を持って出している数字か、皆に合わせて消極的に出している数字かの判断がつかない、というスクラムマスターの意見もありましたね。

伊山：
　表情が読めないという苦労は、みなさん同じようにあるんですね。私が携わっている案件でも、Webミーティングでスプリントレビューをする際、ミーティングのメイン画面をデモと説明メンバーの顔が占領してしまう。すると、ステークホルダーの顔を同時に見られないとか、そもそも顔を映さないステークホルダーもいるので、どう受け止められているのか、まったく感触がつかめなくて困るという意見がありました。

加藤：
　こういう状況になると、普段は意識していなくても、人って五感を使って仕事しているんだなと思いますね。社外講演なんて特にそうですが、ステージからみると聴講席は真っ暗で、聴講者の区別なんかつかない。でも、息づかいとか、視線の圧みたいなものが、自分に向かっているのか、スクリーンに向かっているのか、はたまた寝ているのか、そういうのを感じ取って声の大きさや話し方を変えたりしますよね。

伊山：
　私もそうですが、イベント登壇する人々からも、結構そういう話を聞きますね。今は講演もほぼWebinar形式になっていますが、「とにかくカメラの向こう側にいる聴講者の温度感とか反応が分からなくてすごくやりづらい」という方がほとんどです。

リモートScrumだからこそ
より密着しよう

－上栗：
　ついでと言っては何ですが、リモートScrumにおける開発チームの育成という観点でお聞きしてもよろしいでしょうか。

伊山：
　これは集合かリモートかに関わらずなんですが、初めて開発チームに入った人には、経験者とペアで仕事をしてもらう、というのが効果的だと思っています。Scrumの理解やコーディングの上達も速いですね。

－加藤：
　Q＆Aで完結する事の繰り返しなら良いのですが、その開発メンバーの振る舞いを見て助言・指導するという事は、机を並べて横にいる場合と違って困難だと思うんです。自発的に質問する人ばかりではない。だから、振る舞いが見えないと上級者も支援のしようがない、ということはありませんか？

伊山：
　例えば、コーディングなら画面を共有して通話しながら行うペアプログラミングにするとか、タイムマネジメントには厳しいScrumですが、定期的な勉強会を組み込む、などが考えられます。しかし、これらはおっしゃる通りQ&Aの延長ですので、必ずしも決定打という訳ではありません。
　リモートでの停滞を見つけるためには、あえて各開発メンバーのタスクをもっと小さくすることが有効ではないかと思います。大きくタスクを切ると必然的にタスク完了まで時間がかかります。停滞しているのか、進捗しているのか、外側からは分かりにくい。タスクを小さく切ることで、終わるはずの日時をより手前に持ってくる。そうすると、停滞していることが早期に発見できるので、そこが助言・指導のタイミングになると思うんです。このためにデイリースクラムを日に複数回設定しているチームもあるくらいです。

上栗：
　確かにテレワークだと、成果物でしか状況を知ることができず、キャッチアップのタイミングが遅いというのはプロダクトオーナーとしても感じていました。タスクの細分化と、進捗確認機会の増設というのは、とても参考になりました。

受注関係の壁を超えろ、
マネジメントを変革するチャンスが今

－加藤：
　プロダクトオーナーと開発チームの関係というか距離感というのはどうでしょうか。この両者は日本では一般的に対立しがちで、リモートはそれに拍車をかける要因でもあると考えられますが。

伊山：
　１つ海外の事例を紹介させていただくと、過去にとある企業のアジャイル開発の現場を見学させて頂いたことがあるのですが、あらゆる関係者が非常にフラットでした。その現場で見た二人の人物がとても楽しそうに、かつ熱心に議論をしているので、同じチームの開発メンバーかと思っていたら、実は一方はユーザー企業側のプロダクトオーナーで、もう一方は参画している社外のエンジニアだったなんて事もありました。欧米、特に米国ではユーザー企業側が情報システム部を持っていて開発を主導するケースが多いので、開発者とも目的・目標の共有と、協力関係の構築がしやすいのだと思います。
　一方で、日本ではビジネス側（ユーザー企業）と開発側（SIer）が分かれていることが多いので、甲乙あるいは受発注という関係性が根強く、利害の対立になりがちです。リモートによってさらに対立を強めてしまわないためにも、まだまだ互いのマインド変革の努力が必要だなと感じます。

上栗：
　オーナーは開発にどうしても指示をしがちですよね。それをスクラムマスターが止めるとオーナーは不満を持つ、という悪循環で対立が起きやすい。甲乙あるいは受発注という関係性が根強いというのが良く分かります。

－加藤：
　そういった対立から、アジャイルはやれることが減るとか、生産性が低いなどの評価につながってしまっている面もありますが、これについてはどうお考えですか？

伊山：
　実際、初めてのアジャイル開発ではウォーターフォールに比べて開発効率は落ちると思います。しかしそれは習熟度に起因するもので、決してアジャイル開発の欠陥ではありません。
また、アジャイルとウォーターフォールでは生産性が比較されがちですが、従来の生産性という指標には、お客様にとっての価値、これは満足度、事業適合性や事業達成度と言い換えても良いかもしれませんが、こういう観点は含まれていませんでした。アジャイル開発での価値の追求はライン数とコストだけで表現できるものではないですよね。

加藤：
　そうです、そこを言って欲しかった（笑）。アジャイル開発では成果を見る尺度を変えないといけないし、これまでのマネジメント手法をそのまま適用することも出来ない。しかし現実には従来のマネジメントの中に置かれている。

伊山：
　そこに加えてテレワークですから、もう上位者が全ての決定をして、タスクを割り当て、それを指示し、監視する、というマネジメントでは限界があると思います。

－上栗：
　アジャイルの文脈だけでなく、デジタルトランスフォーメーションの文脈でもマネジメントの変革が叫ばれていますよね？

加藤：
　実はこのテレワーク環境というのはマネジメントの変革を一気に促進する大きなチャンスではないかと思うんです。アジャイル開発は究極的には自己組織化を目指していますよね。誰に指示されることなく、自分たちで課題を設定し、改善し、検証して、新たな課題を見つけ、また解決する。そんな自律的なチーム力がいま求められていると思うんです。

伊山：
　それは開発を見ていて強く感じます。全権委任はできないにしても、ある程度の権限をチームに落とさないと、回らなくなるのではないかと思うような場面を何度も見ています。ですから、自律化・自己組織化というのはテレワーク時代の開発には非常に重要だと思っています。
　個々人への監視・干渉・介入ができなくなった現在の環境は、従来のマネジメントから変革するチャンスであると共に、アジャイルチームの成長のチャンスでもあると思います。ですから、アジャイルにおけるテレワークをネガティブに捉える必要はなく、大いなるチャンスと考えたいですね。

上栗：
　我々も逆境と捉えずテレワークであることを最大限活用して変革して行きたいと思います。伊山エバンジェリスト、本日はありがとうございました。

大規模なアジャイル開発手法の１つ。リーン、アジャイル、DevOps の原則、プラクティス、コンピテンシーを組み合わせた実証済みのフレームワークであり、Scaled Agile Inc.が提供している。
https://www.scaledagileframework.com/