組織変革の悪い例
新たなビジネスへの挑戦、アジリティの向上、品質改善、リードタイムの短縮、肥大化した組織への対応、積もりに積もった技術的負債の解決…様々な理由で、今日もどこかで変革が進められている。
組織・チームの変革は簡単なことではない。新しいルールや業務フロー（開発のワークフロー）を策定したり、その説明に勤しんだりとてんてこ舞いになるのは毎度のことだ。従業員が理解しているか測るための試験問題の作成なんかもやってたりするだろう。
それだけ苦労した変革、果たして成功しているでしょうか？
ほとんど成功していないのではないでしょうか？
なんなら結果の確認をすることなく、次の変革に着手してたりするんじゃないでしょうか？
私は沢山のチーム・組織・企業の品質改善やアジャイル開発導入のコンサルティングや支援をしてきました。今日はその経験からお話したいとおもいます。
ビジネスモデルを変えるだけでは足りない
多くの組織が変革にあたってまず考えるのは
- 変えたあとのワークフローはどうなるか？
- どんなルールを新設するか？
- 体制をどうするか？
といったことではないでしょうか？（目的は当然考えるとして…。）
これは確かに大事なことです。目指す姿を明確にし、目標を決める。より具体的にしていく。
例えば私が聞いた話として、こんな例がありました。
彼らはとあるパッケージソフトの開発をしていて、売上/シェアなどからみても所謂中堅といったところでした。しかし、時代の流れは残酷かな、様々なSaaS企業がマーケットに出現し、今後の売上予測は散々たるものでした。
そこで、彼らは今までのパッケージソフトをSaaS化することを決断。加えていままでウォーターフォールの開発だったのをアジャイル開発に変更。素早くユーザーニーズを取り込んで市場に適応していく方針としました。
何だかレッドオーシャンに突っ込んでいく無謀な方針な気がしなくもないですが、必要な挑戦にも思えます。一定の顧客基盤もあるので、まだ間に合う、急いで変革だ！となるわけです。
彼らは早速作業に取りかかります。
SaaSになることで売り方（営業）や契約も変わります。経営指標や管理もかわるでしょう。早速自分たちの業務フローを作りました。
開発方法の変革も大変です。アジャイル開発になることによって、開発のワークフローやリリースの流れが変わります。これらもルールなどに落とし込みました。予め従業員に説明会を開くのも忘れずに。
人事のことも忘れちゃいけません。部や課の構成は？誰がリーダーになる？あいつはここが向いてるかな？と検討して配置します。
さぁ準備が整いました。彼らの変革はどうなったでしょうか？
ハイ。皆さんの想像通り大失敗です。
張り切って整えたアジャイル開発はただのミニウォーターフォールになり、俊敏さの欠片も見えないどころか、そもそもリリースになかなかたどり着きません。ユーザーからの不満もいつまでもため込んだままです。
営業もうまくいきませんでした。いままでとは違い個別に営業しているだけでは売上高が見込めず、マスに打って出る必要がありましたが、後手後手のマーケティングで市場での存在感がありません。
経営側も大変です。これまでの安定した立場から、挑戦者の立場になったにも関わらず、あいかわらずリスクばかり目につけてしまいます。でも数字はあがってきません。焦りばかりが募ります。
そして、影響はついに従業員に及びました。多くの従業員が離職を決断したのです。多くの業界では人手不足が叫ばれています。いまどき一社に骨を埋めるなんて考え方の若者はいませんから、離職が離職を呼び、もはや組織は壊滅状態です。
カルチャーモデルに目を向けよ
さて、何故こうなったのでしょうか。色んなことに原因があっただろうと思いますが、ここでは変革の準備段階に目を向けましょう。
彼らは確かに色んな準備をしていました。その1つ1つは決して手を抜いたものではありません。ただ、大きな視点が一つ抜けていたのです。それは組織文化・組織カルチャーと呼ばれるものです。
組織文化？なにそれ美味しいの？あぁなんか夢物語みたいなポエムのこと？
そういう風に思う人も多いでしょう。私も昔はそうでした。
でも、やっぱり組織文化って大事なんです。
考えてみると結構当たり前のことなんですよ。いままで大きな企業に対して壮大なビジネスのプレゼンばかりしていた営業集団に、ビジネスモデルが変わったからといって、光の戦士さながらの電話営業や戸別訪問営業なんてさせて成功できるとおもいますか？きっと彼らのプライドやら何やらが邪魔をして失敗する絵が想像できますよね？
今回の例と同じことです。
まず経営側に挑戦のカルチャーがなかった。保守的な考え方のまま新しいことを、変革をはじめようとした。
営業もいままでは展示会で捕まえた顧客に個別営業していたところから、webベースでマーケティングして制約までもっていくスタイルになった。そもそもどんなマインドで文化であれば上手く行くかなんて考えもしていなかった。
開発もそうだ。ウォーターフォールの、それも誤った考えがそのままだった。テストといえば単体と結合と総合にわけなきゃいけない。ドキュメント化しないなんて以ての外。step/人月の正確な見積もりを。これらを変える？あぁ！なんてとんでもないことを！
そう、ビジネスモデルとカルチャーモデルはつながっているものなのです。両輪ともに回らなければまっすぐ進めないのです。片方を変えるなら、もう片方も変えないといけないんです。
今回の例でいうならば
- 少々のリスクは受容し、挑戦すること自体が是をされる文化
- 1つ1つのお客様にあった提案を作るよりも、大衆の大きなマスを広いにいく効率を重視する文化
- 昔ながらの開発文化に疑いの目を持ち、アジャイルにおける先人たちを見て学び続けることを奨励する文化
こういうものが必要ではなかったかと思います。
これらがないばかりに、挑戦は失敗に終わったのでしょう。
どうやってカルチャーモデルを変えるの？
カルチャーモデルを変えるのは、ビジネスモデルを変えるのと同じくらい、いや下手するとそれよりも大変なことです。
じゃあどうやってカルチャーモデルを変えればいいのか？
私がいつも心がけているのは以下のようなことです。
- 目指すビジネスモデルにあったカルチャーはどんなものか？先人を見て想像する。
- 想像した目指すカルチャーを言語化する。
- カルチャーモデルを構成する要素を洗い出し、相互に矛盾がないように改革を進める。
まずは目指すカルチャーをちゃんと考えましょう。
今回の例だと成功しているSaaS企業を想像しましょう。そこではどんな従業員が、どんな風に日々働いているでしょうか。
彼らは何を目標に、何を大事にして、どんな考え方や理念を持っているでしょうか？
これを可能なかぎり従業員を巻き込んで検討しましょう。
自分が関与していない、人から与えられただけのカルチャーはただの押しつけです。
組織で、チームで、メンバーで、みんなで考えましょう。
そして、考えたものを言語化しましょう。ここが結構ポエムっぽくなっちゃうところです。
大事なのはポエムを書くことじゃなくて
みんながこれなら目指していけるな、目指したいな、こんな企業文化だったらいいなと思える言葉を選ぶことです。
ポエム過ぎてもだめだし、妥協の産物みたいなものも駄目です。そんなの目指したくないですから。
最後に、それを具体的な施策に落とし込んでいくことが重要です。
ポエム書いたってなにも変わりはしませんから。そして多くの組織ができていないのはココです。
組織カルチャーは、何も自然に生まれるものではありません。
従業員の人たちの日々の言動やふるまいの結果、生まれるものです。
そして、そうした日々の言動やふるまいは、組織の体制やルール、制度などによってもたらせるものも多くあります。
「失敗しても構わない！挑戦することが正義だ！」みたいなことを組織文化として掲げたとしても、人事評価の制度が伴っていなくて、失敗したら出世できないよということであれば日々のふるまいは変わらないですよね？
「みんなが主体的に意見を言い合ってより良いプロダクトを作る！」みたいなことを組織文化にしつつ、めちゃめちゃ封建的で壮大なピラミッドのような組織構造を作り、荘厳な会議をいくつも実施しないと提案できないとか、日々の言動は変わらないですよね？
いくらカルチャーが言語化されて共有でき、人事制度や組織構造も適した状態にできたとしても、そのカルチャーにそぐわない人を採用しまくり、カルチャーについて何のオンボーディングもしないと、カルチャーに合わない人が多数になって結果
変わらないですよね？
なので、目指すカルチャーを言語化したら、そんなカルチャーを実行できる組織はどうなってるんだろう？どういう組織ならみんなの日々の言動は変わるんだろう？と思いを巡らせて、具体的なアクションを作っていくのが重要です。
大体重要なのは…
- 採用基準
- オンボーディング内容
- 研修・教育制度
- 組織構造
- 人事制度
- 評価制度
- 日々・週次・月次などの定例イベント
とかですかね？
このあたりが
目指すカルチャーと矛盾ないように改革を進めないといけません。
ただ「いやぁ、人事制度はなかなか手をつけられなくってねえ」みたいなご意見は多いです。
正直に言うと「その程度の覚悟だったら改革やめたら？」と思うのですが、それは残酷なので大体以下のような提案をします。
なかなか変えるのが難しいものがあるならば
出島戦略：対象となる組織だけ、既存のルールから切り離した組織として作り、ある程度の裁量を与える
代替戦略：本物の評価制度とは別に、組織内だけで讃えたり報いる別の評価制度を用意する。
というような始め方をおすすめしています。
そしてできるだけ、これらをスモールスタートで進めるというのも重要です。
ただ根本から変えるつもりでやってくれないと「あいつらは特別だから」とか「自部署で評価されたのに人事は評価してくれない」などのまっとうな意見が出てきてしまう諸刃の剣なので注意しないといけませんが…。
というわけで、ビジネスモデルや開発モデルを変えて新たなチームを作ったりするときには
カルチャーモデルも一緒に変えないとダメですよ。という話でした。
詳しくはこちらの本がおすすめです。私も参考にしています。
カルチャーモデル 最高の組織文化のつくり方/唐澤俊輔