組織課題に対する、対策への時間軸の違い • Tomorrow Will Be A Better Day

TD;DR

マネジメント業務を行っていると、メンバーから「現在の課題は、会社としていつ頃解消する見込みなのでしょうか？」と質問されることがあります。
マネジメント業務を数年経験している中で、このあたりの内容について、うまくメンバーと温度感が合わなかったケースを何度か経験しているので、自分の考えを整理がてら少し明文化しておこうかなと思いました。

ソフトウェア開発の不確実性について

ソフトウェア開発の考え方として、不確実性コーンの話がありますが、会社経営における戦略レベルの見積もりはさらに不確実性が高いものが多いです。

不確実性コーンの話
 不安とストレスから解放される見積りとスケジュール方法

一方で、ソフトウェア開発の現場では、開発計画よりも上位の経営計画によって、日限が定められていることが多いです。
これは、ビジネス上の要請があればある程度は仕方ないことです。

特に、後者の記事で書かれている、経営計画というのは、かなり不確実性が高い内容での話をしていることが多いです。
ソフトウェア開発を行う以前での議論もされているため、場合によっては途中で施策自体がなくなることも多々あります。
この状態の施策が現場までおりてくると、現場がさらに混乱してしまうことになります。
そのため、経営陣もできる限り施策に対する方向性が確定した状態で現場に共有したいと考えています。

経営側の具体的な議論内容としては、

「A市場のシェアを取りたいので、資金調達したい」→企業M&Aまで発展するケース
「Bアプリの収益性が悪いので、クローズしたい」→プロダクト戦略に発展するケース
「C市場に進出するため、部署の人員調整を行いたい」→社内の雇用調整に発展するケース
「D法規制についての緩和を提言したい」→政府へのロビー活動まで発展するケース

といった内容が一例として考えられますが、これらが未確定の情報で現場までおりてしまうと、現場が通常業務を行えない状態に陥り、マネジメント側としては関係各所の調整作業に追われてしまい、会社としての業務遂行が止まってしまうことになります。
そのため、組織規模がある一定数を超えたマネジメント側としては、このあたりのリスクが顕在化しないように慎重に情報統制を行っています。

何故、情報統制を行う必要があるのか？

基本的には、経営側も現場に納得感をもって実務を行ってもらうため、情報を提供していこうというスタンスだと思います。
とはいえ、業務ががらっと変わるかもしれない議題についての話を現場までおろしてしまうと、

「次年度の評価制度が、親会社の意向でがらっと変わってしまうかもしれない」
「今のタスクが、数カ月後には二度手間になってしまうかもしれない」
「あの部署がなくなる可能性があるので、ノウハウを引き継ぐ部署が適切ではなさそう」

といったレベルの不安まで考慮しながら実務を行うことになります。

「外に出ると、隕石が落ちてくるかもしれない」
「ランチで汁物を食べるかもしれないので、白い服はこれから着れないかもしれない」
「牡蠣や卵は、食中毒になってしまうかもしれない」

といったことは、普段意識しながら生活していないのに、不確実性が高すぎる情報を現場に落とすと、毎日の業務をこれぐらいのリスクを考えながら過ごすことに近くなってしまうことになります。
そのため、ある一定規模を超えたマネジメント層は、ある程度の情報統制を行いつつ、現場にマネジメントを行うという2面性を持ちながらのマネジメントを行うことにになります。

時間軸が異なる課題は、どのような対策を行えばよいのか

マネジメント層の立場としては、時間軸を分けてのアプローチを行っていることを明示して、「将来軸（年単位レベル）」「直近軸（月単位〜四半期レベル）」で行うことを交通整理する必要があるかなと考えています。
現場としては、「この課題の辛さはいつまで続くのだろう」といったことを考えているので、経営側が考えている中長期計画（3~5年）から年単位の施策を共有した上で、現場の直近の打ち手はこれだと伝えることが必要ではないかなと。(この問題に対する有効な打ち手は、まだ試行錯誤の段階で、よりよい方法があれば教えていただきたいです)

場合によっては、現場に今の辛さを耐えてもらうことを伝えることもありますが、何ヶ月も続くと現場も耐えきれないので、マネジメントする側は現場と対話を行いつつ、経営層とも常に対話を行うことができればよいかなと。
現場側と経営側、マネジメントする側は間に挟まることが多いですが、そこに対しての気力を保つのはまた別のお話になりそうなので、今回はいったんここまで。