🔖

チーム立ち上げ・拡大を振り返り、いい意味・悪い意味それぞれでハマったことをさらけ出す

2022/08/12に公開

チーム

チームビルディング

idea

はじめに

どんなプロジェクトでも、みんなチームに関して何かしら課題を感じているのがあると思います。そんなチームの課題について、私のチームでも、チームの立ち上げから普通の開発チームになるまで、色々な苦労や取り組みがありました。それを表に出せば誰かの役に立つだろうと思うので、記事に起こして公開します。

テックカンパニー的な会社のチームではないですが、大体チームの話はそう変わらないのかなと思うので、参考になれば幸いです。
各章特に依存関係ないので、気になるところだけでも読んでいただければと思います。

私たちはどんなチームだったか?

元々は要望は日本で受け、ビジネス的な要件検討は日本、技術的な検討は海外で行うような体制でした。
その開発拠点を日本に移動して、一から開発チームを立てよう！というのが、私たちチームの開始状況でした。チーム立ち上げの背景はこちらを参照ください。

私が参画したのは、初期メンバー3, 4人がトライアルとして開発を行っていて、これから本格的に日本チームを立ち上げようと日本メンバーを拡大しようとしていたタイミングでした。その時の状況はこのような感じ

自分たちで開発することはまだ不慣れ
海外と連携して開発自体は進めていたので、開発にかかわる組織文化のようなものはあった
ドキュメントを作るよりも、わからなければ聞いて！知ってる人が解決するから！という文化だった
- ドキュメント自体はあるんだけど、上記のような状態なので情報が古かったリ散ってたりする

こんな状況のチームを立ち上げ、全体で開発メンバーが20人程度のチームに拡大していく際にどんなことをしたか？いい面悪い面両方で、ハマった取り組みを紹介していきます。

*ちなみに、記事を見てくれる方で1チームの規模大きすぎでない？と思う方がいらっしゃると思いますが、そこは様々な要因を考えた上でベターな決断をした結果ですのでご了承ください。

チームビルディングで、ポジティブな意味でハマったこと

ここではいい意味でハマったことを思い出せる限り紹介していきます。

ポジティブ1. 基本情報の可視化

とにかく立ち上げで詰まったことがあったら、それは大抵基本情報なんだから誰でも詰まることになります。元々の文化としてはわからなければ聞いて！だったのですが、聞いて終わりじゃなく、可視化しよう！という形にしたのはまずいい感じにハマりました。
(ネガティブな方で書きますが、まずこの文化のギャップを埋めるのが大変だったので、私たちのチームビルディング的にはこの活動が大きな前進でした)

例えば以下のような情報を可視化していきました。

プロジェクト特有の知識の集約
- 用語集の作成
  - 全員で情報を蓄積
- 組織図や役割の説明をドキュメント化
- リリースプロセスや環境特有の問題をドキュメント化
全体像の可視化
- 構成図の可視化
- 基本設計図
  - 私たちはマイクロサービスアーキテクチャで構成されたシステムだったので、マイクロサービス概要ドキュメントを作成
- etc
手順の最新化、スクリプト化
- リリース手順の自動化、できないところは明文化、テンプレートにして機械的にリリースを実施

ドキュメントを踏まえて説明するとしないで全然キャッチアップ速度が違うし、どうすればより改善できるか声を上げやすいので、いいサイクルが回りやすいんですよね

ポジティブ2. ナレッジをためこむ文化づくり

1と同様、得た知識もドキュメント化していきましょう！という取り組みです。効果は1と同じですし、誰もがやった方がいいと思うことかと思います。ただ、ナレッジ蓄積についてはやったほうがいいよねーという状態から、みんなが実践する状態にするまでが大変だったので、あえて項目にあげました。

何が大変だったかというと、普段の仕事の中でストレスがないようにナレッジを書けるようにしないと、みんな書いてくれないんですよね。このチーム・メンバーではどんなやり方がハマるんだろう？という手段を探るのに苦労しました。

試行錯誤した流れは以下みたいな感じ。最終的にこのチームではBacklogにチケットとしてためこむやり方がいい感じにハマりました。

設計書をまとめていたツールのconfluenceを利用してみる
- そこまで頻度高く編集するものでは無かった && ちょっと重かったのでみんなの筆が進まず
チャットツールとして使っていたslackにchannelを作ってメッセージを蓄積
- これは効果あった。slackはドキュメンテーションするツールではないのは間違いないけど、現実的に一番情報を溜めやすい手段だった
  - 会社の意向でslack→teamsにチャットツールを変更したことでこの手段はご破算
GitHub Wikiを利用してみる
- 開発がマイクロサービス化しておりリポジトリが沢山あったので、あまりハマらなかった。独自リポジトリを作っても見たが浸透せず
Backlog(タスク管理で利用)にKnowledge用チケットを作って活用
- これがハマった。チケット作成のためにBacklogは常時開いているし、チケットを作る作業への心理的障壁が他のページ作成よりも低かった模様。

ポジティブ3. 参入者のわからない！をチーム改善につなげる活動

開発って、進めているうちに知見がついて慣れていくものだと思います。喉元過ぎれば熱さを忘れるという言葉があるくらい、人は慣れると過去のことは忘れてしまうものです。そうするとどうなるか？自分たちがやっていることの複雑な点や不自由な点に鈍感になっていったりするんですよね。当たり前になってしまう。

しかし新メンバーは違います。まだ慣れていない目でチームのことを見るものさしになることができます。新メンバーの違和感を感じる部分から、チームの悪いところを客観的に見直すことができます。これはチームの改善としてはチャンス！
しかもこの状態は慣れてしまうと失われるので、新鮮な状態は期限があります。鮮度が大事！
この新鮮な状態を生かして、なんでも気になったら言ってね！改善していくから！という文化を浸透させ、改善を進めるようにしたのはハマりました。
例えばやってきたのはこんな感じ。もちろんもっと細かな改善もやっていたと思います。

最初に概要説明と見ときたいリンク集もらったけど、まず用語がわからんよ！
- 用語集の作成
全体が分からないと難しいよ。結局どうやって動いてるの？
- 全体アーキテクチャ図をまとめる、各機能の概要をまとめる等地道な作業
仕事の流れもよくわからないかもしれん。この成果物は誰宛のものでどこに出ていくの？
- 体制図やリリースを説明したドキュメントを作成

実際やってることはポジティブ1で可視化したものの半数は、この活きのいい状態で上がってきたトピックだった気がします。

私自身も、最初に入った際はこの鮮度がいい状態だったので、新メンバー側に立った声上げもすることができました。同じ立場に立って改善を進められたのも大きかったなと思います。

ポジティブ4. 全体像の説明

これは、チームがある程度成熟してきた後の話で、その頃に入ってきた新メンバーに対する施策です。
開発プロセスが固まってくると、タスク分割も慣れてくるので小さなタスクを人に振るのがスムーズになってきます。そうすると、新メンバーの立ち上げでスムーズに小さなタスクを渡し進めていくことができます。ここまではいいのですが、小さなタスクばかりが続いてしまうと、中々全体の構造に触れる機会が出てこなくなるんですよね。
なので、そもそもこれって何のためにやるんだっけ？という知見がつかず、本質的にやりたいことを考えられるように中々育たなくなっていきます。

そんな状態が気になり、試しに全体構成や背景の説明会を開いてみたところ、かなり新メンバーからの評判がよく、実際仕事に取り組む際の視野も広くなったように思います。

説明会では、例えば以下のようなことを話しました。オンボーディングとして当たり前に説明している組織も多いかと思います。

プロジェクトの説明、背景
チームの説明
全体アーキテクチャ
開発プロセスとして本番リリースまでの流れ
- 書いているコードがどのように検証環境に反映され、どのように商用に出ていくか？そのプロセスは？といったことを説明

また、この説明を実施することで、新メンバーへの教育以外のメリットもありました。
全体アーキテクチャ図のような全体図って、割と更新の優先度が下がったりするんですよね。既知の話であればみな読み替えて把握することは可能なので。更新自体は必要なんだけど、他のやることを優先して順番が回ってこないこともあるドキュメント更新なんですが、説明に使うようになるとドキュメント最新化の優先度が上がり、定期的に更新を入りました。~~(そんな話が無くてもちゃんとドキュメントメンテナンスしろよという声が聞こえる)~~

ポジティブ5. 汎用的に使える考え方の啓蒙

これは新メンバーだけではなく全体に対しての取り組みです。プロジェクト内部で使う技術についてはやっていれば伸びていくのでいいんですが、それだけではどこでも使えるスキルが身につかない。そうすると未知の課題が出てきた時に対処できないし、なにより当人も物足りないだろう。
というわけで汎用的な考え方の啓蒙にも努めていました。対象は主に若手なのですが、たとえばPMとアーキテクトが考え方の違いでぶつかった(どっちも正しい)みたいな課題が出た時に、その現状可視化も兼ねて記事化したりしました。当時は出せるものは全部出したろうって気持ちで動いていたのを覚えています。

覚えている範囲で啓蒙した話を記載します。結構記事化して啓蒙って形があったので、手前みそなリンク多めになっています(自記事には手前みそって書いときます)。

メンタル系
- ボーイスカウト精神をまずは必ず啓蒙
  - プログラマが知るべき97のことの8. ボーイスカウト・ルール
- HRT
  - Team Geek ―Googleのギークたちはいかにしてチームを作るのか
    - Brian W. Fitzpatrick (著), Ben Collins-Sussman (著), 及川卓也 (解説), 角征典 (翻訳)の名著
  - 大事な言葉・HRT～「Humility（謙虚）」、「Respect（尊敬）」、「Trust（信頼）」。ああなんて難しい
    - 手前みそ
- その他
  - 嫌われる勇気をとにかく推す
    - 岸見一郎 (著), 古賀史健 (著)
  - 嫌われる勇気・アドラー心理学をチームに活かす
    - チーム目線で上記を解釈して説明: 手前みそ
技術系
- 質とスピード
  - Takuto Wadaさんの良記事。ことあるごとに共有
- ミノ駆動さん記事は全般的に勧めてます
- プログラムの複雑さを下げるため、条件分岐を減らす方法を考える
  - 設計を学ぶといいことある例で共有: 手前みそ
- デバッグって何をすればいいのか？を考える
  - デバッグの考え方啓蒙: 手前みそ
マネジメント系
- アジャイルの話を啓蒙
  - アジャイルサムライ――達人開発者への道
    - Jonathan Rasmusson(著), 西村直人 (著), 角谷信太郎 (著), 近藤修平 (翻訳), 角掛拓未 (翻訳), 西村直人 (監修), 角谷信太郎 (監修)
  - チームがアジャイルに働くために
    - アジャイルに対する見てるもののずれをチームに啓蒙するため記事化: 手前みそ
- リスクコントロールの話を啓蒙
  - わからないに立ち向かうプロジェクト運用、計画
    - 不確定要素の多いプロジェクトのリスクコントロールを話すために記事化: 手前みそ

記事を書いて説明ってプロセスは、書く側も思考を整理して話せるのでお勧めです。なんなら書く側に一番メリットがあると思う

ポジティブ6. 振り返り

週に一度チームで振り返りを実施しました。アジャイル開発を採用しているチームなら当たり前にやっていることだと思いますが、自チームでも振り返りは効果的に実施できていたなと思います。

週次の振り返り自体はフロントエンドとバックエンドで別々で行っており、不定期で合同の振り返りを実施していました。手法もそれぞれで異なっていて、以下のような形でした。

フロントエンド: miroを使用
- ホワイトボードと付箋でのKPT
バックエンド: backlogを使用
- チケットの種類でKeep, Probrem, Tryを書いた付箋に、プロジェクトボードをホワイトボードに見立ててのkPT

本当はバックエンドもホワイトボードと付箋の感覚で振り返りたかったんですが、10人以上いるバックエンドでは素早く情報を書き込めるの方がハマりました。

また、振り返りが活発になった施策も挙げておきます。

情報共有会で皆さんの経歴を共有し合う
- 単純に仲良くなり、話しやすくなった
- 各人の背景が分かることで、考え方のベースや特徴がつかめて振り返り内容をふかぼりできるようになった
ソーシャルスタイル診断
- ソーシャルスタイルという、人の性格を4つに分類して対話する際の進め方の参考にするといったものです。
  - 例: 相手がDrivingタイプだと、理論的で素早い結論を求めるので、サクッと結論から話し、淡々と必要なことを伝える方がいいみたいな
- がっつり活用していたわけではないですが、コミュニケーションの参考になったり、単純な会話のとっかかりにもなりました。
振り返り→改善開発チケット作成のプロセス
- 振り返りを続けているけどアクションが中々実践されないという状況が出てきた
  - チケット化はすぐして、実施の順番は改善チケットの中で優先度を議論する形に
  - チケットがたまっていくことに不満を感じるメンバーもいたが、アクションが優先度付きで可視化されることで不満が解消

ポジティブ7. スキルの可視化

これは特定の人に仕事が偏っていた状況を改善するために取っていた施策でした。作業の平準化は重要な要素なのでピックアップしています。
やり方としては、以下マトリックスを作ってレベルを記載しました。

縦軸: 業務上必要なプロセス、もしくはビジネス領域での技術要素
- バックエンドならマイクロサービスの1つ1つと、CI/CD要素
- フロントエンドなら画面のコンポーネントと、CI/CD要素
横軸: チームメンバー

スキルレベルはIPAのITスキル標準等を参考にし、チーム内の言葉に置き換えて定義していました。

ポジティブ8. 情報共有会

人が増えてくると、中々気軽に質問できないという人も出てくるわけで。特に打ち合わせが多くて中々時間が合わない人と話したい！とかになっても、忙しそうだからと気を使って余計話しにくくなったりということもあるあるだと思います。理想は1 on 1を開いて話す場を設けることなんですが、話しにくい原因が時間が取れないことなので中々難しい。

ということで、もう確定で全員必ずコールで集まる日を決め、そこは打ち合わせが入らないように予約しておくという形をとりました。
質問や情報共有の機会が増えてスムーズな開発ができるようになったとともに、コミュニケーションが増えたことでそれ以外の時間での質問もしやすくなったようです。

また、昨今のフルリモート時代でもコミュニケーション量が減らないよう、情報共有会以外でも一定時間コールをつないでおく時間をとったり、定期的にオフラインで集まって仕事して顔を合わせる場を設けたりしたことも効果はあったと思います。
(ここ誤解があると嫌なので注釈しますが、コミュニケーションの取り方については完全に個人差があるところだと思います。私たちは顔を合わせて効果が得られましたが、オフの方が集中できて捗るという人もいると思います。)

ポジティブ9. 普段思っているけど伝えていない感謝・尊敬を伝える

普段心には思ってるけど表に出していない尊敬の念や感情って、誰しも周りの方に持っていると思います。そういった感情を1 on 1のような場の中でなんともなしに話してみたところ、いい感じの効果があったので色々な人に対して実施していました。ある同僚とは褒め会しましょう！って不定期イベント化したり。
効果について話す前に例を出すと、例えばこんな会話の流れです。

Xさんのあの動きが無ければこの前のタスクどうなっていたか。PMみたいなことしてますもんねー。ほんと凄いわ
Yさんのこういう観点での仕事の仕方、ほんとうまいと思うんですよね。ここまでなら出来るけど、この観点が入ると質があがりますよね
Zさん、この作業うまく行かなかったってへこんでいたけど、普通にうまくいっていたと思いますよ。先輩並の動き方はまだできてなかったかもですが、数か月前のZさんから考えると見違えるようでした。めっちゃ成長してますね！

この取り組み、お互いに気持ちよくなれるっていうのがまず効果としてあるんですが、それ以上に育成に効果がありました。
というのも、若い人・経験の浅い人って、成果に対するものさしがまだ足りない状態なので、前進してるはずなのに数年上のできる先輩と比較してなにもできていないと思ったり、失敗ばかりを見てへこんだりみたいなことが結構あるんですよね。
いやいや、あなたがやったことはめちゃめちゃいい成果だよ！って外から客観的に何度も説明することで、自分の成果や成長を正しく見ることができるようになり、前向きな自己評価につながっていったということがありました。

別の感謝・尊敬を伝える取り組みもあります。私たちのチームでは定期的にリリースをしていたのですが、せっかくリリースでみんないい仕事してるのに、定期行事なので達成感が薄れ、リリースに追われている感じがありました。なのでいい仕事に対する感謝を伝えるため、リリースへのポジティブフィードバックを集めた寄せ書き(yosetti)を作るようにしました。リリース頑張ったね寄せ書きを行ったりしました。
(SMSという会社がやっていたリリースレゴがとてもいいアイディアだったので、パクりました。)

おまけ: 浸透させたかった積極的なドキュメントアウトプット文化

記事へのアウトプット文化は啓蒙したんですが、これは浸透しなかったです。一個なにかを触ったら、返す刀で1個アウトプットしよう！って啓蒙はしていたんですが、ナレッジと同じで中々このアウトプットをしよう！までは実践されない。人は自分にメリットがないとやらないので、両者にメリットがある行為にするか、もしくは業務に取り込まないとなかなか実践はされないです。それに加え、ナレッジと同様チームで実践するには精神・物理両面でハードルをどう下げるか？が肝心です。

よかったことのまとめ

ここまでは、ポジティブな効果のあった活動をまとめました。正直そこまで真新しいことはないかなとは思うのですが、こういった活動をコツコツやること自体がチームの成長につながってくるというのは、改めて感じます。
また、こういったトライを繰り返すことで、最初は失敗が続いたとしても、チームとして改善しようという文化が出来ていきます。その文化を作っていくことが、具体的な成果を出す以上に大切なことなのかなという気がします。

チームビルディングで悪い方にハマったこと

ここでは、当時チームを拡大していくにあたって失敗した・難しかった点について挙げていきます。主にチーム立ち上げ序盤のことが多く、ポジティブにハマった活動によって改善されたものばかりです。

ネガティブ1. 自身のチーム文化に潜む特殊性に対する新メンバーへのフォローが薄い

チーム・組織には、意識せずともそのチーム独自の文化が根付くことがあります。外に出せないビジネス要因を実現するために仕事をしているので、中の人同士には伝わるけど、それ以外の人から見たらぱっとわからない言葉や習慣が身についているというのは、よくある話だと思います。

私たちのチームもそういった要素が新メンバーに対する障壁になっていました。具体的には以下のような要素がありました。

独自用語が多い
- データセンター用語、独自の略称(Business Analyst => BA, Scrum Master => SM等)
背景や全体構造が一般知識ではわからないものがある
- マイクロサービスアーキテクチャを採用しているので、単独で開発できるはずなのに、実際には専用の開発環境やVPNの設定が必要
  - 開発の為に自社製基盤を使用しており、その基盤を利用する為には開発環境が必要。という前提があったのですが、新メンバーからしたら教わらないとわからない構成
  - (構成の是非はノーコメント)
- 全マイクロサービスが一望できるようなドキュメントがなくて、全容が見えない

こういった要素については、用語集や全体を把握できるドキュメントをつくり、その説明を最初にすれば解決するので、必要なドキュメントを作って対応しました。

ネガティブ2. わからなかったら聞いてを重視し、ドキュメントを大事にしない

独自文化に気付かないことの延長ではあるのですが、既存で使われている構成やチーム特化の技術というのは、新メンバーにとっては把握が大変です。ググっても出てこないのでどう調べればいいのか？みたいなところから入ることになります。
そんな状態で、「わからないことは聞いて！」を優先してドキュメント更新が中々行われない文化だと、新メンバーにとってかなりきついんですよね。例えば

ドキュメントのメンテナンスが間に合っていないので、環境構築の手順書が最新かはわからない
- わからなかったら聞いてと言われるが、どの状態が正しいかもわからない状態になる
- ただエラーを共有→なんか直してくれたの状態から抜け出せない
いつまでたってもプロジェクトの全体像が把握できず、担当周辺がなんとなくわかる状況から抜け出せない
- 全体を見ると整合性取れないようなコードが登場したり
  - 私的には、これは個人の能力に関する課題だけでなく、チームで表に出すべき情報が出ていないという課題が潜在していると思います。
そもそも今やっていることが何がわからないかわからない
- 特に若手だと、方向性も見えない状態だとまずなにしたらいいかわからない状態に陥りやすい
- ただ、既存メンバーにとっては、長くプロダクト仕様に触っているので何が難しいか認識しにくい(よくあるやつ)

みたいな状態だったりします。最初のうちはそのギャップを理解するのに時間がかかりました。わからないことは聞いてねというけど、チーム独自の話だからそのとっかかりが出来ない。
ドキュメント化して誰でも同じことできる状態にするのが重要という意識合わせを最初のころはよく実施していたと思います。

わからなかったら気軽に聞いて！偏重から抜け出すためには

わからないから聞いて状態の難しさって、結局メンバー同士の見えている景色の差があるからなんですよね。このギャップを埋めるには、双方のコミュニケーションが必要です。既存メンバーからは最初の方向性や文化の共有をする必要がありますし、新メンバーは何が分かるかの問い合わせをする必要があります。このコミュニケーションツールとして、チームの概要を説明したドキュメントがかなり効力を発揮するわけです。

また、新メンバーからすると、こういう最初のどう言語化したらいいかもわからない状態って、かなり質問しにくい状況だったりします。言語化できないんだからそりゃ聞けませんよね。なので、こういった場面で質問のしやすい、心理的安全性の低い環境を作れるかも1つ大事になります。

わからないことがあったら聞いて！じゃなくて、なぜわからないことをスムーズにキャッチアップ出来ない状態になっているんだろう？チームとして改善できるところは？と考え行動に移していくことがチームとして重要だと思います。

また、視点を変えてキャッチアップ出来ない要因を考えると、この要因ってすべてが「その人の力不足」にはならないと思うんですよね。例えば「特性がハマらない」って可能性もある。人には性格や思考考え方のスタイルがあるので、とにかく聞いてくれ！にハマりにくい人もいると思います。
力不足でない人に対して、アプローチを変えてチームの間口を広げキャッチアップ手段を少し変えてみるのか、それとも「生き残ったもののみついてくるがよい！」みたいなスタンスで行くのかはチームによるとは思いますが、チーム拡大のためにはある程度スケール前者の考え方が必要なのかなと思います。チームの守備範囲を広げるよう改善を続けていくことが、チーム自体の拡大につながると思うのです。

ネガティブ3. 理想だけに拘る / 役割に拘る

私たちのチームは、最初アジャイルなスタイルで開発をしたかったんですよね。チームの背景で書いたように、スムーズな価値提供をしたかったのが理由です。ただその中で、開発プロセスとしてこうあるべきという理想・形式にとらわれていた感があった気がします。例えば

スクラムマスターがスクラムをコントロールしてタスクが回るようにするべき
アーキテクト、テックリードは技術的要素に集中するべき
スクラムチームは全員で自発的に動くべき

みたいな。

まあ理想はそうなんですが、特に未成熟なチームで全てが理想通りに回るわけがないです。そんな中で役割だけ当てはめて、こうあるべきだから動け！といっただけではうまく回るわけもないです。シンプルに言うと現実的にどうするべきかが考えられていなかった部分がありました。

私たちの当時の状況としては、立ち上げ間もない不安定な状態のチームで業務委託に適切にタスクを渡す必要がありました。また、彼らは準委任契約だったため、彼らの仕事を元にしたスケジュールと成果物品質のマネジメントも行う必要がありました。
そんな難易度の高そうな状況のスクラムマスターを、開発経験の浅いメンバーが担当していました。アーキテクトなど開発に関する役割の人は開発に集中すべきというあるべき論が背景にあったのですが、その結果、開発経験が浅い人に高難易度の役割が当たることに。今振り返ってみてもこれはきつい

なんとか進めていくがタスクの進捗状況が見えなくなり、期日も近づいてきたこともあって立て直し。役割は一旦置いておき、現実で出来ることを話し合い対策を立てることになりました。当時取った対策は2つ

開発のわかるメンバーが状況把握に入り、現状をガントチャートにしてスケジュール化(アジャイルスタイルを一時的に辞める)
開発のわかるメンバーをスクラムマスターに立て、アーキテクトと兼務してタスクの状態と内容詳細の同期をとることに努める

上記を実施し、まずは期限までの開発に集中。山場を乗り越え、周囲からきちんと成果が出せるチームである評価を得たところで、改めてスプリントを組んだ開発に徐々に移行する形をとりました。その流れを現実的な体制を議論、アーキテクトは開発に集中すべきというあるべき論は一旦取っ払い、私たちのチームではスクラムマスターをアーキテクトが兼務する形をとりました。

上記の例で書いたような話は、現実のチーム、特に未成熟なチームではよくある話だと思います。アーキテクトは設計"だけ"をやる人、PMはプロジェクトをマネジメントする"だけ"の人、BAはビジネス要望をまとめる"だけ"の人で分けて、適切にやるべきことが拾われて回っていくのは理想かもしれません。しかし、実際進めてみると、スキルや適性、もしくは隙間作業の所在など、想定していなかった課題が出てきます。そんな状態でも現実に向き合わず、役割に固執して目の前の課題に立ち向かわないとジリ貧です。素早く現実を把握し、ベターな状態に適応する。まさしくbe agileです。チーム立ち上げ、拡大でうまくいっていない時こそ、Don’t just do agile. Be agile.が効果を発揮するはずです。

理想だけに固執するのではなく、現実を回しつつ理想を実現するための下地を作っていくのが重要です。

ネガティブなハマりを脱出するには？

ネガティブな意味でハマってしまわないようにするには？それを脱出するには？のポイントを改めてまとめると、現状を正しく把握すること、現実を改善するために変化すること、それをチームで実践できる文化を作ることが重要だと思います。

自分たちの特殊性や理想とのギャップを正しく把握し、理想の状態に近づくには何をする必要があるのかを考え、地道に実践していく。そんな文化を作るための要素についても考えてまとめていきたいと思います。

ボーイスカウトルール

来た時よりも美しく。自分がかかわった事柄に対して、ちょっとでもいいので良くして帰る。この考え方はチームを前に進めるには重要だと思います。
新人指導で詰まっている状況があれば、以降そうならないように説明の仕方を変える、ドキュメントを充実させる、チームの歩き方を定義してみる、少しずつでもできることはあるはずです。できることを少しだけでもよくしていきましょう。

課題の分離

嫌われる勇気の中で紹介される考え方です。これをチームに当てはめると以下のようになると思います。

課題の内容を分析・分解
その内容を各人のものとチームの課題に分割
個人の課題は個人に任せ、チームではチームの課題に取り組む

正しくチーム全体の課題を捉え、解決していくことは効果を発揮するはずです。

Don’t just do agile. Be agile.

アジャイルソフトウェア開発宣言で謳われているのは、端的にいうと実現手段よりも、対話を重ね素早く意味のある価値を顧客に提供することの重要性です。なので、プロセスをアジャイル開発に当てはめることよりも、状況を正しく理解してゴールに向かって進むことが重要です。極論アジャイル開発っぽいプロセスを踏むことは本質的に重要なことではないです。

"アジャイル開発"を実施することにこだわるのではなく、現実に対して機敏に対応していく。Don’t just do agile. Be agileはたとえアジャイル開発プロセスを採用していないチームだとしても効果を発揮、不変の振る舞いなんじゃないかなと思います。

HRT (Humility（謙虚）、Respect（尊敬）、Trust（信頼）)

上記で書いた行いは、どれもその根底にHRTが必要なことかと思います。自身とチームに対して謙虚に取り組み、相手へは尊敬をもって向き合う。そして互いに信頼しながら改善を進める。大事なことだと思います。

最後に

結構長くなりましたが、チームでのよかったことや苦労がかけたと思います。チームに対する取り組みや悩みってどこも一緒だと思うので、参考になる部分もあるんじゃないかなと思います。ここで書いたことが皆様の生活に少しでも関係するような一助になればと思います。

またこの記事を読んでなにか自分のチームでもやってみよう！と思っていただけた方がいましたら、ぜひボーイスカウト精神で一歩前に進めていただければと思います。Just Do It!