流行りの小さい組織について考えてみる。
流行りの小さい組織について考えてみる。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則
- 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,黒沢 健二,松永 肇一,美谷 広海,祐佳 ヤング
- 出版社/メーカー: 早川書房
- 発売日: 2012/01/11
- メディア: 単行本
- 購入: 21人 クリック: 325回
- この商品を含むブログ (37件) を見る
なんて本が出てるように今多くの会社で小さい組織という単語が流行っているように思えます。
では、実際に小さい組織というものをうまく機能できているかというと疑問が残る状況が多いことも現実です。
実際に自分の務めている会社も小さい組織化というものを行いましたが、さまざまな問題を残しています。
そのいくつかを紹介しつつ、自分なりの考えをまとめてみました。
（ちなみに自分は事業会社勤務なので今回は事業会社にスポットを当てた話になります）
問題紹介
- 小さい組織にしたら受発注構造が解決できると思っている問題
- とりあえずScrum導入問題
- 評価者が遠い問題
- 結局上層部にとっては小さい組織化とかあんまり興味ない問題
小さい組織にしたら受発注構造が解決できると思っている問題
事業会社ではよく聞く話なのですが、「企画」サイドと「開発」サイドまたは、「営業」サイドと「開発」サイドが受発注構造に陥っているという問題があります。
※個人的には受発注の仕方の問題な気はしてたりしますが、、、
これはなにかというと「企画」サイド・「営業」サイドが考えたものを発注し「開発」サイドが受注するという構造になっているということです。 それによって何が起きるかというと、自社内の開発であるのにあたかも、外注を使うような構造になっているため内製開発の強みが活かせないないということが一つ。 もう一つ大きな不満の温床になりやすいこととして発注サイドと受注サイドに暗黙の上下関係ができてしまうことにあります。
- 「こっちから仕事をあげているんだから言われたことをやれよ」
- 「これになにか口出ししたら次は仕事がもらえないかもしれない」
という無意識の考えが発生してしまうことによるものです。
こうなってしまうと発注サイドが考えたものがおかしいと思っても開発サイドからは指摘ができない状態が発生したり、その責任を開発サイドに押し付けてしまうなどの事態が発生したりします。（現実にそういうことが起きているのをよく目にします）
また、開発の専門家ではない発注サイドが仕様まで考えて発注してしまうことで開発サイドはただの作業者となってしまい、モチベーションの維持に問題が発生し職を離れてしまうという事態も発生します。
ではこれを小さい組織化を行い10人程度のチームに発注サイドと開発サイドを混ぜ込むことで解決を図ろうという試みをした結果起きるのがチームが小さくなっただけという状態になり、受発注構造の解決につながらないという状態です。
これは、何故かというと発注サイドとしては技術に興味がなく自分たちのビジネスに口出しをしてほしくないという気持ちがつよく、開発サイドとしてもビジネスに気持ちがあるかというとそれよりも自分たちの技術やキャリアに興味があるという状態だからです。
では発注サイドと開発サイドのそれぞれの人間が悪いかというとそうではなく、組織を再編するにあたり社員のマインドセットを新たにするということを疎かにしたことが多くの原因であると考えます。
受発注構造が問題だと言われるのは主に他責構造を生み出してしまいやすいということなのでそれを解決するために必要なことはそれぞれを尊重し、かつ当事者だという意識を持つことでしょう。
当事者意識を持つためにはどうしたらよいか、個人的な意見ですが最も簡単なのは個人の評価を担当しているビジネスの成績からするようにすることだと思います。 自分が評価されためにはビジネスが成長している必要があり、ビジネスが成長すると企業の業績もあがるので正しくwinwinな関係ができあがりかつ、自分の給与に直結するためどうしたらビジネスが成長するのかを真剣に考えることでしょう。ただ、評価制度に他の項目を混ぜ込んで救済措置を取ろうなどとすると失敗の憂き目を見る気がしますが、、、（というか失敗しているのをみていますが、、）
とりあえずScrum導入問題
話題を変えて小さい組織にするためにとりあえずScrum導入をしてみることに焦点を当てていきたいと思います。
※Scrumとはどうゆうものかはこちらを参照するとわかりやすいかと。。
簡単にいうとScrumというのはアジャイル開発手法の一つとしてあげられます。ビジネス側の人（顧客）に寄り添い、優先度を決め、短いスパンで提供するというアジャイル宣言に則り
- プロダクトへの要望を優先順位ごとに並べかえ、その順に機能を作る
- 固定の短い期間（1～4週間程度）の単位で開発を区切り、その中で計画を立てる
- プロジェクトの状況や進め方に問題がないか、メンバー同士で毎日確認しあう
- 作っている機能が正しいかどうか、定期的に確認の場を設ける
という手順で開発を行う開発手法を指します。
これを見ると小さい組織にするうえで向いているのではないか？と考えるかもしれませんし、実際に不向きであるとはいえません。
ではなぜ、『とりあえずScrum導入問題』と問題として定義したのかを説明します。
ます、受発注構造になっていた企業にScrumという開発を取り入れることは難しいと考えます。（というかアジャイル開発全般が難しいと考えています）
なぜかというと、『アジャイル開発宣言の背後にある原則』にもありますが
「ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。」
これは、同じオフィスに居るとか同じ企業に所属しているという話ではなく前項に上げた同じビジネスの当事者として働いているということを指します。
さて、今まで発注する側であった人は正しく同じビジネスに対するメンバーだと認識できるでしょうか？受注する側であった人も同様です。暗黙的上下関係を解消できるでしょうか？
人は感情の生き物ですので自分は時間をかけなければ不可能だと考えます。（あるいは時間をかけても不可能でしょう）
Scrumをするという土壌がない中に組織を再編するためにScrumという手法を投げ込み、
- 小さい組織になるということ
- Scrumという手法に対応すること
この2つを同時に行えるでしょうか？個人的な所感にはなりますがScrumという名のナニカを行ない受発注構造時にあった暗黙的上下関係が歪な形で残る可能性が高いでしょう。
そもそも大きな企業になればなるほどPO（プロダクトオーナー）の立場に立った人間にビジネスの責任を委ねることはないでしょう。それができないということはScrumチームの外から横槍が入ることになります。果たしてそれはScrumと呼べるのでしょうか。
企業の中で正しく権限委譲や責任を持たせることができない企業ではScrum（アジャイル開発手法）を導入することは破滅を招く一手になる可能性があることを心に留める必要があります。
評価者が遠い問題
話題を変えて、皆さん仕事をしている上で給与というものは大切ですよね。（自分は大切です！）
定期的に査定があると思いますが、この査定をする人が遠いということも小さい組織を作る上で問題になります。
なぜかというと、前述にあげました当事者意識を持つ上で給与や評価という話は切り離せないからです。
自分たちのチームが上げた実績を査定をする人が年に1回（ないしは2回）しか合わない役員や上司の方であったらどうでしょう？
正しく、評価されていると感じることは難しいと思います。また、大きな企業になればなるほど公平な評価と称してなぞの評価シートやスキルシートを記入させることでしょう。
それに自分たちのチームの実績が記載できることは少ないでしょう。そうなってくるとチームのメンバーにとってのビジネスがどんどん他人事になっていきます。
ビジネスの成績が悪くても評価シートやスキルシートの内容によって一定の評価が得られてしまうのです。
そうなってしまえば小さい組織というものは破綻していきます。なぜならビジネスは他人事で自分の給与をあげるための行ないを優先することになるのですから。
人としてそれが間違っているとはいえません。誰だって給与は大事ですから。
さてではなぜ、評価シートやスキルシートというものが必要になるのでしょうか。
それは評価・査定をする人が遠くにいる人だからです。遠くにいると普段の業務の様子・実績などを見ることはできません。
また、企業が大きく複数の事業を持っていたりすれば担当・配属事業によって実績は変わってくるのでそれでは公平な評価ができず社員が辞めてしまう（入ってこない）と考えることでしょう。
※公平＝評価者の感情というフィルターであることが多いですが
これに関しても正しく権限委譲を行ない、事業成績などから事業ごとの予算配分を行ない査定を行うものをそのチームの中から出すべきでしょう。
評価者からは評価対象者がよく見え、チーム全体で実績をあげることで全員の評価・給与として返って不透明性はだいぶ低減します。
もちろんこれだけでは事業毎の有利不利は解決しませんが、それを解決するのも事業を担当したチームで考えるべきだと思います。
それがこれ以上実績が上がらないと判断したのであれば最小限の保守だけを行ない、そのチームで新しい事業を提案・実現していくべきだと思います。
そして、チームが持っている事業すべてを評価対象にすることである程度の解決はできるでしょう。
※もちろん、失敗することも多々あると思いますが、失敗だと判断したらすぐに手を引いて次に着手すればよいでしょう
結局上層部にとっては小さい組織化とかあんまり興味ない問題
最後に、なんだかんだいって企業の上層部にとっては小さい組織化とか興味がないことが多いと思います。
これは自分の所属企業もそうですが苦笑
上層部にとって大切なのは持っている事業が実績をあげること、担当の範囲が実績をあげることなのです。
当然でしょう。これに否と声を上げるつもりはありませんし必要もないでしょう。
あげるべき声は「正しく権限委譲を行ない、責任も譲渡してほしい」です。
ある程度の予算の決済権や判断権限を与え、報告のみを受け取るというのが正しい小さい組織の使い方です。
そこにマイクロマネジメントをいれてしまえば小さい組織である意味はなく上層部→少人数組織への受発注構造となってしまうのですから。
また、チームとして考え動くことに一々上層部の判断が必要となってしまえば結局、上層部の人間がやりたいことをやるだけになってしまいチームのメンバーがビジネスを当事者として捉えることが出来なくなっていきます。
まとめ
長々と書きましたが小さい組織を成立させていくために必要なことをまとめると
- チームみんながビジネスの当事者になる仕組みをつくる
- 査定などで変な救済措置を考えない
- チームに正しく権限委譲、責任譲渡をおこなう
- マイクロマネジメントしない
でしょうか。
自分の今勤めている企業も小さい組織化に乗り出したのでしばらくしたら小さい組織化に巻き込まれたレポート続！的な記事をまとめられればと思います。
