経営の仕組みを考えるための例題：プロジェクトと人のバランスで採算性と退職率を改善する

例題を通じて「経営の仕組み」を考える

「経営の仕組み」は、競争優位性を構築する上で重要ですが、日々の実務では手がつけられず、放置されることが多いと思います。また、すぐに仕組みが出来ればやる気にもなりますが、仕組み作りは根気が必要で、すぐに効果が見えな い点も、後回しにしがちな要因です。

経営の方法論は抽象的な場合が多く、いかにも万能なように書かれていることが多いですのですが、ご存知のように、 そんなことはありません。方法論は万能ではなく、ある時、ある条件で効果が大きく異なります。経営する立場からす れば、方法論も重要ですが、組み合せや活用方法の方が実際の問題となります。つまり、適用の仕方が重要になります 。

方法論の組み合せは企業によって異なりますが、組み合せの「コツ」には共通項があると思います。本書では、実践的 な例題を使って、実際の思考の流れに沿って考えを進めることで、組み合せの「コツ」を掴もうと考えています。

経営企画の現場から、リアルな例題と実践的な対応を考える

本書では、「あるべき論」「万能論」「理想論」ではなく、不完全で不十分な情報の中で、自分自身も未熟な状況にお いて、そんな中で何を考え、行動するとうまくいく確率が高いか、そんなリアルさと実践的内容を志向しています。

例題の内容ならびに対応は、全て私の感覚に基づくもので、そうだと言い切れるものではありません。しかし、ビジネス本を読みあさり、コンサルティング会社と事業会社の両方で試行錯誤した結果です。分かったように「正しい」理論を振りかざすのではなく、なんとか改善の糸口を見つけ、理想と現実の狭間を行ったり来たりし ながらなんとかうまく回そうとする際のポイントを書いたつもりです。

結果として、新書本やよくあるビジネス本と比べても遜色ないくらいの分量になっています。拙い部分もあるとは思い ますが、実践のヒントは盛り込んだと思います。例題を見て、当てはまる部分があれば、ぜひ読んでください。

例題：プロジェクトの採算性と退職率をなんとかしたい

本書では、プロジェクトの採算が悪化し、退職率も悪化している状況を、プロジェクトと人のバランスを最適にする仕 組みを考えることで解決していきたいと思います。イメージしやすいよう、次の例題に対する解決策とその実施を考え ていきます。

RayDay社アルファ事業部の憂鬱 0日目

IT業界でシステム開発を主な事業としているRayDay社。その中の主力部門の一つであるアルファ 事業部は、約60名の社員を抱え、10以上のプロジェクトが常時稼働しています。先月の経営会議で、このアルファ事業部の売上高はここ数年同程度で推移し、プロジェクトあたり利益率は四半期毎に数%ずつ下がっているという指摘がなされました。赤字転落寸前です。アルファ事業部 の核となる人員は、課長・係長の5人でしたが、今月に入って、核となる人員の一人であるA係長 が退職を申し出ました。これにより、進捗が滞るプロジェクトが少なくとも2つ発生し、納期遅れ の可能性が出てきました。そうなると急速に採算が悪化します。さらに、アルファ事業部の退職 率は、業界平均と比べても高い方です。あなたはRayDay社の経営企画部に所属していて、特命で アルファ事業部の採算性の向上と安定化に対処するよう指示されました。

1日目

あなたはまず、状況を知るために、関係者へのインタビューを試みます。まず急ぐべきは退職予 定のAさんへのインタビューです。人事部の許可を得て、Aさんに話を聞いた結果、以下のような回答がありました。

事業そのものはやりがいがあった。 周りが付いてこない。自分であれもこれも背負ってしまい疲弊してしまった。 自分以外にも、今の課長・係長は全員疲れている。 プロジェクトが大変な状況でも、みんな大変で、誰も手を差し伸べない。 いつまでもこの状況が続く気がして嫌気がさしてしまった。 我慢できず先に辞めてしまい、みんなに申し訳ないとも思っている。

よくある回答です。実際の現場では重苦しい空気が立ちこめていると思いますが、ここでは例題 なのであっさり進みます。さて、あなたはアルファ事業部の収支を確認します。そこで、あなた は意外にも、一部の人を除き、全体の残業時間は少ないことに気が付きます。(一部の人の残業 時間は確かに危険な数値です。)有休消化率も悪くありません。利益率が数%ずつ下がっていますが、障害対応が利益圧迫の原因のようです。

どうも、以下のような図式が成り立つようです。 

品質管理に問題あり → 障害発生に伴い急な対応が頻発 → なんとかしようと課長・係 長が奮闘 → 燃え尽き

そこで、その日の夕方に、アルファ事業部の部長に、品質管理についてを中心に質問します。すると、以下のような回答が返ってきました。

最近、技術の変化が激しく組み合せも多いため、難易度が上がっている。 事業部内ではチェックリスト・テンプレートを整備するなどして障害防止に努めている。 全てのプロジェクトに一人以上の課長・係長をアサインし、品質に問題ないかレビューして もらっている。あとはスキルとボリュームに応じて適宜メンバーをアサインしている。 障害対応は特に対応が難しいため、どうしても課長・係長に対応してもらわざるを得ない。 Aさんに対しては日頃から話を聴き、世話してきただけにびっくりしている。正直、どうすれば良いか困っている。

部長が困ってしまっては、こちらも困ります。今後の対応策を練るために、部長の許可を得て、A さん以外の課長・係長にインタビューを行うことにしました。

2日目

課長・係長へのインタビューの結果、以下のような意見が出てきました。

技術の変化が激しく組み合せも多いため、難易度が上がっている。障害をなくすためには、 我々のレビューをしっかりやらなくてはならない。 チェックリストやテンプレートはおまじないのようなもの。変化が激しいので定型的に進め るのは難しい。レビューは経験がモノをいう。 最近の若者の多くは軟弱で視野が狭い。任せると穴が多くて品質低下を招き、逆にこちら側 の工数が増えてしまう。若くて骨のあるやるはBさん、Cさん、Dさんの3名しかおらず、そ れ以外は叱っても成長が見られず、十分に任せることが出来ない。時代の流れもあると思 うが、採用がうまくいっていないようにも感じる。

後半は愚痴になりつつあったのでうまく切り上げ、業務の合間を見て、課長・係長以外のアルフ ァ事業部のメンバー数名(Bさん、Cさん、Dさんではない)にも話を聞いてみました。(忙しく ないらしく、簡単にセッティングできました。)
課長・係長は全員尊敬できる。すごいと思う。ただ、正直言うと、自分もそうなりたいとは 思わない。 課長・係長は、Bさん、Cさん、Dさんを酷使していると思う。3人とも疲れており、このま まだと辞めちゃうんじゃないかと心配している。

自分としては、指示を忠実にこなし、バグのないプログラムを早く作ることが一番だと思っ ている。出来ることをやろうと思う。

思いのほか、ぶっちゃけトークを聞くことが出来ました。「その開き直りはどうよ」と心の中 でつっこみつつ、今後の対応を検討することにします。

さて、どう対処したら良いものでしょうか。