「アジャイル」という言葉を再考したら、最高のチーム像が見えてきた？

本記事はマネージャーWeek 4日目の記事です。
⚖ 3日目 ▶▶ 本記事 ▶▶ 5日目 ⚜

基盤デザイン事業部でマネージャーをしている林です。
マネージャーウィークということでブログ初投稿です。
よろしくお願いします。

まず、私が所属している基盤デザイン事業部について少し紹介させてください。部の主な業務内容は、AWSなどのパブリッククラウドで稼働するWebシステムインフラ（一部アプリも）の提案・構築・運用です。オンプレのインフラ部隊が徐々にクラウドへと活躍の場を移し、インフラエンジニアからクラウドエンジニアに様変わりしていく。そんなエンジニアが多数在籍している部署です。最近では、クラウドネイティブな若手も増えており、時代の流れを感じている今日この頃です。

本ブログに記事を投稿しているメンバーのうち　 k2-kobayashi、 t-tezuka、 y3-shimizu、 nnc-k-ozawa、 m3-wada、 nnc-y-nishi などが所属している部署です。（2022年10月現在　※漏れてたらゴメンナサイ）

マネージャーになるまで技術以外のことにはほとんど興味がなかったのですが、最近ではチームビルディングや組織学習などのテーマに興味を持つようになり、私自身も様変わりしたものだと驚いています。「役割が人を育てる」の典型例かもですね（染まりやすいだけともいう？）。とはいえ、お金の計算やいわゆる「管理」といわれる仕事は苦手です。そういう意味では、管理職にはなりきれていないのかもしれません。

前置きはこれぐらいにして、本題に入りましょう。今回は、チームビルディングに関連して「アジャイル」をテーマに書きたいと思います。

あくまで、現時点での私のアジャイル観です。大半は真面目に書きましたが、少しネタ的な要素も含んでいますので、広く温かい心で楽しんでいただけると嬉しいです。

はじめに
「インフラのアジャイルとは？」という問いはなぜ生まれたのか？
それってホントにアジャイルなの？
そもそも、アジャイルとは？
アジャイル思考に必要なことは？
- ＜仕組み＞
- ＜組織風土＞
アジャイル思考のチームとは？
チーム人格が形成されるとどうなる？
さいごに

はじめに

「アジャイル」という言葉は、時と場合によって、また、人によっても様々な捉え方をされることがある言葉。それに、IT業界に携わる多くの人にとって、それは銀の弾丸（そんなものはない）のようなイメージを持つ言葉でもあるのではないでしょうか。ここ数年で、私が携わるプロジェクトでも「アジャイル」という言葉を頻繁に見聞きするようになりました。

ですが、「時と場合によって、また、人によって様々な捉え方をされることがある言葉」と書いたように、誤解や認識違いが生じやすい言葉でもあるように感じます。そこで、アジャイルという言葉に関する私の思考の変遷をここに書き記したいと思います。

「インフラのアジャイルとは？」という問いはなぜ生まれたのか？

今から2年ほど前、以下のような悩みが頭の中を巡っていました。

最近のシステム開発案件は「ウォーターフォール」ではなく「アジャイル」による進め方が増えてるよなぁ。
アプリ開発は、期間を区切って機能を少しずつ追加していくというイメージができるけど。。
インフラってそもそもアプリを動かすために必要なので、ある程度最初に作り込む必要があるよね？

その結果、私の中で生まれた問いが「インフラのアジャイルとは？」でした。

それってホントにアジャイルなの？

それ以降、「インフラのアジャイルを考えてみよう！」とか「インフラのアジャイルってなんだと思う？」と部やチームのメンバーに問いかけてきたのですが、どうもしっくりこないなぁという思いがありました。もしかしたら、問いかけられた人はその時から「なんだその問いは！？」と思っていた人もいたかもしれません。

そこで、改めて悩みと問いを整理してみると、私の悩みは、アジャイルというよりも「スクラム*1」や「XP*2」、「FDD*3」といった開発手法で解決されるものであって、「インフラのアジャイルとは？」という問いでは解決できないのでは？と思うに至りました。

そもそも、アジャイルとは？

では、その悩みを解決するために「インフラのスクラム（XP、FDD）とは？」を考えよう！　となるのが普通の流れかと思いますが、今回は「アジャイル」をテーマにします。あらためて「アジャイル」ってなんなんだろうと考えたとき、まずは原点に戻ろうと「アジャイルソフトウェア開発宣言」を参照してみました。

～アジャイルソフトウェア開発宣言より抜粋～

プロセスやツールよりも個人と対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を
価値とする。
すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

「ソフトウェア開発」という言葉には、アプリケーションだけではなくそれを支えるインフラも含む、私たちが生業とする「Webシステム開発」を包含しているのではないかと思います。この開発宣言をみて、アジャイルはウォーターフォールと対になる開発方法論ではなく思考法（価値基準）であるという考えを持つようになりました。であるならば、そもそもアジャイルには「アプリ」も「インフラ」もなかったのです。

アジャイル思考に必要なことは？

アジャイルは思考法だという一旦の結論に至りました。では、アジャイルな思考ができるようになるためには何が必要なのだろうか。そう考えていると「仕組み」と「組織風土」という2つの観点が思い浮かびました。

＜仕組み＞

「仕組み」としては、『組織を芯からアジャイルにする』の中で紹介されている、「重ね合わせ」「ふりかえり」「むきなおり」という仕組みがとても参考になると思います。この書籍はほんとにおすすめです。ぜひ、ご一読を。

重ね合わせ（状況を見える化する）
- 見える化手法の例
  - かんばん　　：　目指しているゴールに辿りつくために、いま実施しているタスク・テーマ
  - バックログ　：　目指しているゴールに辿りつくために、今後実施すると良いタスク・テーマ
- チーム、組織内のお互いの状況を共有できる状態を作る
- お互いの状況を理解して、フィードバックを送りあえる環境を作る
ふりかえり（共通認識を持つ）
- 重ね合わせから見えてくる、改善につながる学びを得る
むきなおり（向かうべき方向性を見出す）
- そもそもの目的や目標を定期的に捉え直し、現状の計画と実行の正しさを確認（修正）する
  - 自分たちはなんのために集まっているのか
  - いま進めているやり方で目指すべきゴールに近づいているのか

組織を芯からアジャイルにする

作者:市谷聡啓
ビー・エヌ・エヌ

Amazon

＜組織風土＞

「組織風土」としては、以下の3つがあげられるように思います。これらは、私が普段から組織のマネージメント方針として掲げているものです。*4

心理的安全性の確保
- 弱さを見せあい、助け合える組織・挑戦できる組織になる
- より高い基準を目指すために切磋琢磨する
対話によるコミュニケーション
- 価値観の違いを顕在化し、そのズレを埋めていく
- 思い込みをなくし、考えを伝えることによって相互理解を促進する
経験学習によるスキルとノウハウの習得
- 成功するために小さな失敗を早くする・失敗から学ぶ
- 経験だけではなく、体験を重視する（身体で経験する）

アジャイル思考に必要な「仕組み」と「組織風土」について簡単に書きましたが、1つ1つ細かく説明していると長くなりますので、また機会があれば書いてみたいと思います。

アジャイル思考のチームとは？

アジャイル思考に必要な「仕組み」と「組織風土」がプロジェクトを実施するチームに浸透すれば、とても一体感があるチームになりそうだな。と、理想のチーム像を膨らませていると、1つのチームをあたかも一人の人として捉えることができないだろうかという発想が思い浮かび、それを「チーム人格」と名づけました。チーム人格という言葉だけだとイメージが伝わりづらいので、何かいい可視化ができないかと探していたところ、ピッタリな物を見つけました。それが、「合体ロボット」です。

もちろん、各メンバーは一人の人として自律しているのですが、合体ロボットになることでチーム人格が形成され一体感が高まる。そんなイメージです。（うまく伝わるか少し心配ですが。。）

ネットコムでは、アプリケーション開発部隊やインフラ部隊、デザイン部隊が組織（部・課）として分かれていることが多くあります。しかし、組織としては分かれていても「チーム人格」という一体感を持つことができれば、プロジェクトをうまく進めることができる理想的なアジャイル思考のチームになるのではないかと考えました。