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

本記事は  マネージャー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つの観点が思い浮かびました。

＜仕組み＞

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

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

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

＜組織風土＞

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

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

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

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

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

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

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

超合金 超合体SFロボット 藤子・F・不二雄キャラクターズ

チーム人格が形成されるとどうなる？

チーム人格が形成され、チームがあたかも一人の人のように振る舞うことができたら、プロジェクトを進めるなかで起こるあらゆる出来事を「自分ごと」として捉えられるようになり、アジャイル思考に必要な「組織風土」にプラスに作用するのではないかと思います。

• 「ふりかえり」や「むきなおり」 が内省的な考え方に変わる
  　➝　次につながる本質的な気付きが増えて、改善や効率化が促進されるのでは？
• 自分に遠慮する人は少ないので、弱さを見せたり助け合いが増える
  　➝　心理的安全性が高まるのでは？
• プロジェクトの課題や失敗を素直に言えるようになる
  　➝　自分には甘くなるので失敗も許容されやすく、失敗から学ぶ学習態度が広がるのでは？
  
  

さいごに

ここまで、「アジャイル」という言葉に関する思考の変遷をつれづれなるままに書いてきました。まだまだゴールには辿りついてはいませんが、再考を進めるなかで「チーム人格」という発想を得られたことは大きな収穫であり、目指したい最高のチーム像を1つ見出すことができたのではないかと思います。

あらためて

• アジャイルは開発方法論ではなく思考法（価値基準）
• アプリやインフラなどにこだわらず、各プロジェクトでチーム人格を形成する

を念頭に、これからのプロジェクト運営に携わっていきたいと思います。

また、プロジェクト運営だけではなく、組織運営にもアジャイル思考を取り入れていきたいなと考えているので、これからも空想・妄想をしながら、理想の組織づくりに励んでいきたいと思います。最後まで読んでいただきありがとうございました。それではみなさん、ごきげんよう。

---

*1:Scrum：スプリントという一定の期間毎に、プロダクトバックログ項目の優先順位が高いものから動くソフトウェアを作るアジャイル開発手法の1つ。

*2:Extreme Programming：顧客の要望を取り入れながら、要件定義から設計、開発、テストの工程をイテレーションという単位で繰り返し、開発の品質を高めるアジャイル開発手法の1つ。

*3:Feature Driven Development：ユーザー目線で価値のある機能を中心に開発を進めるアジャイル開発手法の1つ。

*4:基盤デザイン事業部では、「目的・目標を共有し、お互いを尊敬しつつ和気藹々と切磋琢磨する」「遊び心（自分らしさ）を忘れず自らの考えで動く」を理想のチーム像として掲げています。

執筆者林晋一郎

Webシステム開発部門のマネージャをしています。

X（旧：Twitter）：@shin16884

Amazon 著者ページ：林晋一郎:作品一覧、著者略歴 - Amazon.co.jp