「組織」を考える
組織って、ありますよね。
皆さんの周りにある企業で１年に１回は組織変更してる、なんてところはありませんか？その度に名刺が変わったりして。
コストのかかる話でもあるので、そんな話を聞くたびに、どうしてそんなに頻繁に組織を変更するのかと、とても不思議に思っていたことを思い出します。
純然たる心理学とは少し外れますが、組織心理学の分野ではどうしても重なるので、
組織の分類について、まずは整理してみます。
これを整理したら、次はこれをシステム開発のプロジェクトに応用したらどうなるか考えてみようと思っています。
どうなるかな……。
組織の形を分類
組織観というものもあるが、組織図の形について、分類してみる。
-
職能制組織
営業や、製造など、各専門知識を持つ人をまとめて、組織を作る。イメージ的にはボトムアップ。ルールやマニュアルに従えない、想定外の自体が起きた場合は、この場合、管理者である社長に意志決定をお願いすることになる。
＜メリット＞
・組織全体での最適化が図れる（中央集権）
＜デメリット＞
・扱う商品の製品分野が違って、営業や、商習慣など流儀が違うものがある場合、全体最適を目指す方が難しいので、却って不効率になる
・社長が扱う商品の事情に精通していないと意思決定に問題が発生する -
事業部、例えば対応する製品分野などで、組織を作り、その製品分野専用に営業、開発などの専門知識を持つ組織を配置する。
１の職能制とは違い、既存ルールでは対応できないような、想定外事象があった場合、事業部制では各事業部に権限が移譲されているので、事業部長が意志決定を行うことになる。
＜デメリット＞
＜メリット＞
・事業部に権限移譲されているため、社長まで意志決定を回さず、機動的に現場対処ができる
・事業部ごとの評価に共通の評価が使える（売上金額など）
※職能制の場合、営業と開発部門は同じ尺度では評価しにくい
・いわゆる「組織の壁」が発生する
・部分最適になり、全社の視点で、物事を考えることが少なくなる
→ こうみると、１と２では権限移譲がポイント、ということがわかる。
組織と意思決定
通常はルールやマニュアルがあって、それに従って業務をするようになっているはずだが、その例外があった場合に、意志決定を他に求める。（その際、どこに意志決定をお願いするか、が組織によって変わる）
意思決定量が多くて、意思決定する側が回らなくなってくると、次に考えるのは目標（方針）をあわせておき、現場判断で動ける部分を多くすると言う形になる。
*1
それでも厳しい、やはり意思決定に課題があると言う場合に、どんな方策があるかと考えると、大きく分けると２つになる。
①意思決定量をもっと多くこなせるように工夫する
②意思決定の局面が起きないような方策を工夫する
①意思決定量を増やす方策（＝情報連携、管理を効率化する）
- 情報システムなどIT化して、意思決定をスムーズにする
- タスクフォースを作る、横連携担当をおくなど、調整や情報共有を最適化して意思決定をスムーズにする
②意思決定の局面を減らす（＝現場でどうにかできる）
- 期待水準を下げる
期待水準が比較的高くなければ、期待水準に満たない可能性がある場合の意思決定局面を減らせる（＝エスカレーションを防げる） - 使えるリソースを現場に用意する
期限の余裕や、費用の余裕を持たせること、現場で足りない人員や機能があればそれを専用に用意して、余計な調整等が発生しないようにする
意思決定に課題がある時の選択肢の選択について
意思決定に課題がある場合、おおまかには４つ方策があることになるが、実際にはどれを取るかとなると、現場では①だと、２：タスクフォースなどの組織を入れて情報連携をスムーズにする、②だと、１：期待水準を下げる という選択を取ることが多い。コストが比較的低いからである。
選択根拠としては無理がないが、②−１を多用すると、緩い組織になってしまう。①−２を多用すると結局、管理側人的のコストが大きくなるので本末転倒になったりして問題が発生、組織変更が必要になる。
組織を規定するときにどう意思決定・情報連携を行っていくか、何を重視するかということを考え、分割と、統合のバランスを考えていく必要がある。
まとめてみて
もともと、心理学を学ぼうと思ったのも、組織の管理や人に課題感を持っている、というのが理由でした。
何となく、組織についてはその中で仕事をしているので、肌でわかってもいたし、知ってもいた（現場にいれば何となくわかる）が、改めて整理して学んでみることで、腹落ちしてくることや気づいたことが複数ありました。
例えば、組織の意思決定については階段状に登っていく形※になるので、そう思えば、マニュアル化・標準化も意味があると思えました。過去、そう思わないという人もいて、その時はそういう考え方もあるかと当時は思いましたが、、その時、見方と切り口を自分なりに考えるべきだったなと反省しました。
※１：ルール化 → ２：組織エスカレーション → 目標設定、方針設定 → 組織に手を入れる（方策適用）
これを日頃、目にしているITでのシステム開発のプロジェクトに引きつけてみると、また自分なりの発見があるような気がするので、それを整理してみたいなと思います。
*1:最近、こういう話が多い気がするのは、それだけ先が読めなかったり、速かったりして、マニュアル化できない問題が多発していると言うことだと思われる
