そのルール、if文だらけになってない？ “ガイドライン”で思考停止を防ぐ方法
1. はじめに：あなたのチームを縛る「ルール」、疑ったことはありますか？
こんにちは！
あなたのチームには、きっと数々の「ルール」が存在するはずです。
コミット規約、プルリクエストのテンプレート、そして、日々の会議の進め方まで...。
私たちは問題が起きるたびに、再発防止のために新しいルールを作り、それを守ることで秩序を保とうとします。これは、チームを運営する上で、とても自然なことかもしれません。
でも、一度だけ立ち止まって考えてみてほしいのです。
そのルールは、本当にチームを良い方向に導いているでしょうか？
ルールで縛ることが、かえってメンバーの思考を停止させ、チーム全体の柔軟性を奪ってはいないでしょうか？
この記事では、厳格な「ルール」とは異なるアプローチ、つまり**「目的を共有するガイドライン」**によって、チームがより自律的に、そして創造的に動けるようになるための考え方を提案したいと思います。
2. ルールが必要なとき、ガイドラインが活きるとき
もちろん、僕はルールを全否定したいわけではありません。
ルールとガイドライン、何が違う？
この記事では、2つの言葉を以下のように定義して話を進めます。
- ルール: 守るべき具体的な**「行動（How）」**を規定するもの。（例：アジェンダを18時までに書く）
- ガイドライン: 目指すべき**「目的（Why）」**と、そこに至るための指針を示すもの。（例：会議を意思決定の場にする）
例えば 「交通ルール」 。これは、不特定多数の人間が安全に道路を利用するために欠かせない、厳格なルールです。もしこれが「安全運転を心がけましょう」というガイドラインだったら、きっと道路は大混乱に陥ってしまうでしょう。
このように、参加者の顔が見えず、共通の目的意識も持ちにくい大規模なコミュニティでは、個人の判断の余地をなくす厳格なルールがとても重要になります。
ただ、僕たちが働く数人〜数十人規模の開発チームのような、 「顔の見える小さなコミュニティ」 では、話は別ではないでしょうか。
メンバーは共通の目標を持ち、日々対話をしている。そんな環境では、行動を一つ一つ縛るルールよりも、 「僕たちは何を目指すのか」というコンパス（＝ガイドライン） を共有し、そこへ至る道筋は各自の判断に委ねるほうが、よほど高いパフォーマンスを発揮できるはずです。
3. 具体例：ある会議ルールが、僕たちの自由を奪っていた話
少し抽象的な話が続いたので、僕たちのチームで起こった具体例を紹介しますね。
かつて僕たちのチームには、定例会議に関するこんな 「ルール」 がありました。
- ルール①: アジェンダは前日18時までに全員が記入すること
- ルール②: 会議は必ず50分で終了すること
このルールが目指したのは「会議の効率化」でした。しかし、現実は違いました。
メンバーはルールを守ること自体が目的となり、「とりあえずアジェンダを埋める」「時間内に終わらせるために議論を打ち切る」といった行動をとるようになりました。本来の目的だったはずの「活発な議論による意思決定」は失われ、会議はただの形骸化した儀式になってしまったのです。まさに、ルールが生んだ思考停止でした。
4. 新発見：例外だらけのルールは「技術的負債」である
この失敗から、僕たちは重要な気づきを得ました。
コードレビューで、ある関数の中に if-else のネストが何層にもなっているのを見たら、僕たちはどう感じるでしょうか。「この設計、何かおかしいぞ」「もっと良い抽象化ができるはずだ」と、リファクタリングを提案するはずです。
実は、チームのルールもこれと全く同じです。
ルールにおけるif文、それは 「例外」 です。
最初はシンプルだったルールも、運用していくうちに、このような例外がどんどん追加されていきます。これは、現実の多様なケースに、硬直したルールが対応しきれなくなっているサインに他なりません。
例外だらけのルールは、いわば 「ルールの技術的負債」 です。
誰も全体像を把握できなくなり、新しいメンバーはキャッチアップに苦労し、ルールを守るための認知コストが、ルールによって得られるメリットを上回ってしまいます。
もしあなたのチームのルールにif文（例外）が増えてきたと感じたら、それはリファクタリングの絶好の機会です。そのルールが本当に守りたかった 「目的」 は何か？に立ち返り、より抽象的で柔軟な 「ガイドライン」 に置き換えられないか、チームで話し合ってみるべきでしょう。
5. ガイドラインがあれば、もっと「楽」になる
僕たちはこの「ルールの技術的負債」という考え方に基づき、窮屈な会議ルールを一度すべて捨てました。そして、「この会議の本来の目的は何か？」を問い直し、「チームの課題を解決するための意思決定をすること」という共通認識に至ったのです。
その上で、僕たちが新しく作ったのはルールではなく、たった2つの 「ガイドライン」 でした。
ガイドライン①: 会議の冒頭で「今日のゴール（決定事項）」を宣言する
ガイドライン②: 会議の終わりには「次のアクション」と「担当者」を確認する
驚くほどシンプルですが、効果は絶大でした。
大事なのは、全員が「意思決定」という目的に向かって、自律的に判断できるようになったこと。ルールに縛られていた時よりも、導入も、運用も、そして会議に参加する精神も、ずっと「楽」になったのです。
6. 【重要】最適なバランスは、チームと共に変化する
さて、ここまでガイドラインの良い側面を話してきましたが、もちろんガイドラインが万能薬というわけではありません。
例えば、新しく結成されたばかりのチームや、ジュニアメンバーが多いチームではどうでしょう。判断の拠り所が何もない状態で「自由にやっていいよ」と言われても、かえって混乱してしまいますよね。
そういうフェーズでは、むしろ一時的に具体的な「ルール」を設けることで、メンバーは迷わず動くことができ、チームとしての基礎体力がついていきます。
大切なのは、「ルールか、ガイドラインか」の二元論で考えることではありません。
今の自分たちのチームは、どのくらいの『型』が必要な段階だろうか？ と問い続けることです。
- ルールで守る時期: チームの立ち上げ期。まずは全員が同じ基準で動けるように、具体的なルールで交通整理する。
- ガイドラインで導く時期: チームが成熟し、文化が育ってきたら、ルールを少しずつ柔軟なガイドラインに進化させ、メンバーの自律性を促していく。
ルールもガイドラインも、あくまでチームを良くするための道具です。その最適な形は、チームの成長や状況に合わせて、柔軟に変化させていくべきものなのです。
7. 【明日からできる】あなたのチームの「ルール健全度」を診断しよう
この記事を読んで、「確かに、うちのあのルール、見直した方がいいかも…」と感じた方へ。
あなたのチームが最初の一歩を踏み出すための、簡単なチェックリストを用意しました。
8. おわりに：あなたのチームの「ルール」を対話のテーブルへ
あなたの身の回りにある「ルール」を、もう一度見直してみてはいかがでしょうか。
それは、今のチームを守るために必要なルールですか？
それとも、例外のif文だらけになった、返済すべき「技術的負債」ではありませんか？
すべてを一度に変える必要はありません。
そこから、あなたのチームに合った、最適なバランスを見つける旅が始まるはずです。
Discussion