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