【メタエンジニアの戯言】良い組織を維持し変わり続けることの難しさ

2023.09.08松林弘治の連載コラム
  • このエントリーをはてなブックマークに追加

相変わらず毎日のように、ChatGPTに代表されるLLM(Large Language Models)の新しい話題が生まれ、飛び交っています。プロンプト(指示文)の工夫やパターンの探究、APIを使った活用例の開発、など、今後もますます目が離せないのは事実でしょう。

と書いておきながら(笑)、今回のコラムはもっと人間臭いドメインにおけるお話です。

開発、企画、営業、経理、人事、管理、その他。部門や仕事はいろいろあれど、雰囲気/風通し/空気/透明性といった表現がされる、いわゆる「組織風土」が、いかなる業務でもパフォーマンス、そしてやる気の面で重要でしょう。これは、あらゆる職場や組織で意識される(べき)ことでしょうし、事実、多くの知見が書籍やWebにあふれています。「オープンネス」という視点で分析するものもあれば、「ファシリテーション」という技法で改善を探るものもあったりしますね。「スクラム開発」もそうですね。

多くの場合、現状の職場に問題を感じていて、それを改善する、または新たな組織を作り上げる、という視点で語られますが、実はその逆の場合も少なくないように感じています。つまり、「以前はとても心地よく仕事が出来ていたのに、最近どうも雰囲気が悪くなってきて、ギスギスしてきているな。。。」といった具合です。

以下、いくつかの実例をモチーフにしたフィクションであることをご了承ください(笑)

プロジェクトを構成する人数が少ない段階では、開発者も、プロジェクトマネージャも、意思決定者も、財布を握る人も、それこそ「全員野球」(このコトバがもう古いかもですね)で進めやすいことが多いです。全員に当事者意識がある状態、といってもいいでしょう。結果として、情報の偏在がなく、「なぜ今これをやろうとしているのか」「なぜこうしたいのか」といったビジョンも見取り図も全体で共有され、コミュニケーションの透明性も高く、フットワーク軽く議論や開発を進められ、個々のパフォーマンスを最大化しやすい状況が生まれやすくなります。

しかし、プロジェクトが進行して規模が大きくなるにつれ、全体を見渡すことが徐々に難しくなってきたり、企業内の組織間や参画企業間で「責任分担/役割分担」が意識されはじめたりすると、コミュニケーションチャンネルが無意識に絞られていくなど、伝言ゲームが発生しやすい状況が生まれたりすることがあります。

結果、例えばSlackやTeamsで日常的にコミュニケーションをとっていたとしても、公開チャンネルでの議論ではなくDMでのやりとりが増えてしまったり、その少数による議論の結果がWikiやオンライン議事録など全体で共有される場に記録もされないまま、あとになってポンと他のメンバに出されたり、「あれ、そんなのいつ決まったの?」「その話ってどういう文脈から出てきたの?」というすれ違いが起こり始めたりします。

また、年月が経つにつれ、あらゆる作業がルーチン化してしまい、あまり考えなくても回る状態になってしまうと、小さな疑問が解決されないまま積もっていくこともあります。定期的なリフレクション(振り返り)が重要なゆえんですが、このリフレクション自体もルーチン化してしまったり、正しく機能しなくなることもありえます。それでいて、日々の業務に忙殺されるばかりだったり。

上に書いてきたようなことが起こらないためにも、常に組織を「保守」し「カイゼン」し続ける、という意識が必要ですが、なにしろ我々人類はもともと怠惰な生き物ですから(笑)、考えずにルーチン化して回す方が楽だし、まぁいいや、とそのままにしてしまいがちです。その結果、組織改善の「回帰不能点」(Point of No Return)を超えてしまい、もはやチームや組織を立て直すのが非常に困難(または不可能)な状態に陥ってしまっては後の祭りです。

プロジェクト発足当時に、先々を見据えてチームビルディングに精力を注ぐ、このポイントの重要性は広く認識されていますが、逆に「優れたチームの風土を維持する」または「より良くし続ける」という部分に関しては、もしかしたらあまり陽の目が当たっていないのかもしれません。

ソフトウェア開発の世界においても、新規開発時点の勢いに比べて、運用・保守・改良のフェーズは、モチベーションの意味で低くなりやすかったり、「普通に動いていて当たり前」と、日々の運用保守の重要性や貢献度を理解されにくい、なんて話があるのにも似ていますね。

ともあれ、「回帰不能点」を回避するためにも、各部署や各チームをまたいで話ができ、個々の事情を理解し、技術的な裏打ちもあり、さらに意思決定にも関与できる、組織の小さなほころびも見逃さすにすぐに改善の手立てを打つ、そんな人がとても必要とされているわけです。しかし残念ながら、日本の企業や組織においては、工学的・科学的知見を備えた意思決定層が多いとは言えません。また、意思決定層とのコミュニケーションチャンネルが限られていることが多い、といった現状もよくみかけます。

プロジェクトに関わり、プロジェクトを改善し、より良いものを開発・運用・保守していきたい、と日々格闘している、様々な立場の人、もちろんわたしもその1人ですが、製品やサービスを開発するチームや組織を新たに作ること、または維持し続けることも、メタな視点から見るとまさに開発なんだ、という点を再確認させられます。単純な正解がない世界ではありますが、今後もより良いチームを形作るために実践と学びを続けていきたい、と強く思っています。あ、上記はあくまでフィクションですので(笑)

【他社事例から学ぶ】自社のDX推進を成功に導くために

DX時代をけん引する人材を育てるための戦略

  • このエントリーをはてなブックマークに追加