無料ブログはココログ

« 2014年12月 | トップページ | 2015年2月 »

ランチェスターの法則と売り上げ、利益、利益率

年度末が近づいて、売り上げ、利益、利益率、といった数値が意識されるようになりました。色々と考えているうちに、ランチェスターの法則と組み合わせると良い組織運営ができるのではないかと思いました。

ランチェスターの法則

ランチェスターの法則(リンク先はWikipedia)は戦闘の数理モデルで、経営学では様々な分野に手を伸ばす強者戦略と、ニッチ市場を突く弱者戦略に応用されています(この弱者の戦略はパレートの法則や孫子の兵法に繋がるところがあり、人生の戦略新しい技術の導入にも応用可能だと思います)。

よりわかり易い表現として、ジャンケンのグー・チョキ・パーで表現される事があります。つまり、弱者である導入時期は、ポイントを絞ってグーでグイグイ攻め、成長期には多方面にパーっと攻め、成熟期には効率の悪いところをチョキチョキします(グートパーの間に、徐々に広げる意味でチョキを挟む場合もある様です)。

売り上げ、利益、利益率

会社の経営目標は、売り上げ、利益、利益率で表現されますが、本当は何が重要だと思われますか?売上は達成したけれども利益と利益率が未達と、売上は未達だけれども利益と利益率が達成するのとどちらが良いのでしょうね。

ROA(総資産利益率)やPER(株価収益率)など利益に関する指標が多い事から、売上よりも利益が大切な事はわかります。しかし、それだったら利益だけで良いのではないかと疑問に思いました。

もし、シンプルな指標に統一できるなら、 アメーバ経営のようにゴールからメトリクスを決めることが可能で、効率的な組織運営ができるからです。

ランチェスターの法則と売り上げ、利益、利益率

そこで、ランチェスターの法則に当てはめてみると、今をどのような状況にあるかによって、中心の指標にすべきものがわかります。

(1) 導入期のグー戦略

弱者の戦略であるグー戦略は、ピンポイントにニッチなマーケットを攻めます。利益の達成が一番です。もし、利益を達成しているのに売り上げが未達なら、それは効率が良いと言えます。今後もその調子で無理のない範囲で売り上げを狙うべきでしょう。もし、売り上げが計画を超えているのに利益が未達なら、効率化できるような施策が必要でしょう。

(2) 成長期のパー戦略

強者の戦略であるパー戦略は、拡大戦略です。シェアを押さえないと勝てませんので、少々利益率を落としても売り上げを狙うべきでしょう。いわゆる品揃えや体力で勝負することになります。成長期には「損して得取れ」ということでしょう。

(3) 成熟期のチョキ戦略

成長期が終わって成熟期に入ると、拡大方針を見直す必要があります。安定した利益や次のビジネスに備えて、利益率を基準に優良なビジネスだけを残す必要があります。「赤字は罪」という松下幸之助氏の言葉が指針になると思います。

まとめ

売り上げ、利益、利益率は、区別せずにゴール設定されていないでしょうか。上に示したようにランチェスターの法則に割り当てると、現在の状況をどのように判断して、どのような戦略で経営を行いたいかによって、指標を選択できることがわかりました。このようなシンプルなゴールを示せれば、組織がよりねらった方向に向かうはずです。

また、企業の計画や業績を見る際にも、その狙いや状況の判断に使えると思います。拡大が期待できる時に利益率を重視していたり、そろそろ限界という時に売上拡大だけを狙っている様なら、注意した方が良いでしょうね。

これまで、ランチェスターの法則を単独で見ていた時は、あまり関係ない世界だと思っていました。しかし、売り上げ、利益、利益率に当てはめて考えると、経営とは戦略に合わせてゴールの指標を示す仕事だと思った次第です。

このエントリーをはてなブックマークに追加

労務費からメトリクスを考える - IT勉強宴会に参加して -

第38回 IT勉強宴会in大阪は「中小企業の社長は何を考えているか」というテーマでした。簡単に言うと「なんぼもうかりますねん?」と常に資金繰りを考えていると理解しました。

お話の中で気になったのは、粗利益の考え方です。労務費を含めた粗利益を中小企業の社長さんに説明すると、労務費を入れると作業をしない人が出ると言われたそうです。

プロジェクトに最適化すると労務費を少なくしようとして、余っている人を有効に使おうとしないと言う事なのでしょう。ソフトウェア開発では労務費がほとんどを占めますので粗々(大まかな粗利)と言えども考えにくいですが、同時に稼働率を管理する事を考えると、その主旨は理解できます。

この労務費の扱いを聞いて思い出したのはアメーバ経営です。アメーバ経営ではGQMのようにゴールからメトリクスを決めます

アメーバ経営では付加価値を示す時間あたりの採算(人件費を含まない)を用いて、「売り上げを最大に、経費を最小に」を実現します。ソフトウェア開発でも基本は同じはずです。

しかし、ソフトウェア開発ではプロジェクトの粗利(労務費含む)の最大化と稼働率の最大化という少し矛盾したメトリクスが管理されています。変な話です。

粗利を最大にするなら労務費を減ら減らせば良いのですが、稼働率を最大にしないと行けないので社員から使うことになります。常に社員は100%稼働していて、足らないところを協力会社に外注することになります。

大まかに考えると間違ってはいないのですが、稼働率が100%だと必要なアソビがなくなり、未来に向けての活動が難しくなります。会社が一定の投資を義務化するなどの対策が必要になってきます。そこまでトップダウンに決めないといけないのでしょうか?

2次会でお話をしていたところ「会社にとっては部門の利益が大切で、労務費が粗利に入っても入らなくても関係ない」というお話を聞きました。確かにそうです。稼働率まで会社が管理するのは、一種のマイクロマネジメントだと思いました。

メトリクスには2つあると思います。1つはゴールを示すために必要なもの、もう1つは監査的な管理に必要なもの、です。会社のゴールを達成するには、部門の利益だけをゴールとし、それ以外の監査的なメトリクスはトレーサビリティと部門内での自律的な管理に用いれば、うまくいくようになるのではないかと思いました。

会社が関与しないといけないのは、最低限の標準化、ゴールの達成に必要なリスク管理、部門間の全体最適、そして教育、だと思います。プロジェクトマネージメントと同じですね。

このエントリーをはてなブックマークに追加

[#TiDD] 補完型チケット駆動開発で外乱に強い組織を作る

オスターワイルのプロセスプログラミングの論文に習い、食事のメタファで補完型チケット駆動開発を考えてみます。お正月ですので外食のメタファしました。

外食のメタファで考える

近年のファミリーレストランは管理が行き届いています。全ての調理は標準化され、自動化されているので、どのお店に行っても一定の品質が保たれています。新商品の開発は専門の部門が行い、商品が開発されるごとに標準化された手順が共有されます。

これは大人向けのレストランになると少し様子が変わります。客の注文や食材の状態に応じて調理方法を変えるからです。基本的な技術を備えた調理師が状況に合わせて工夫をし、料理長が管理するようになります。しかし、レストランは店の品格をまもるため、食材がない時には遠慮なく注文を断ります。

かつてNAIST開校時にあった学生食堂は、工事現場の人や数少ない学生・教員向けの仮ごしらえのプレハブでした。プラスチックのプレートで出される定食はお世辞にも上品とはいえませんでしたが、品質はそれなりに管理され、パートのおばさんたちはとても親切でした。ある日、定食もカレーも売り切れたとき、近くにコンビニもなく途方に暮れている学生に「ご飯が残っているからチャーハン作ってあげようか?」と次善の策を提案していました。

それぞれの特徴

外食のメタファをプロセスの視点で見ると以下のようになります。皆さんの求める理想の組織はどれでしょうか?

(1) 標準化された組織

  • 考えない人も活躍できる
  • 高度に自動化され、安定している
  • 改善の浸透には時間がかかる

(2) テーラリングの許されれる組織

  • 基本的な技術・自動化がベースにある
  • 定められた範囲である程度は現場で対応ができる
  • 無理をせず、勝ちパターンに持ち込む

(3) 状況に最適化された組織

  • ムダの少ないプロセス
  • 自律的に考える組織
  • 外乱に対して対応が早い

これらの違いは、想定外の外乱への組織のあり方です。共通性を重視して、より安定した計画的な進め方を前提にするか、個別性を重視して、プロジェクトのリスクを低減させるか、です。

それぞれに良さがあり、一概にどれが良いとは言いがたいです。しかし、ソフトウェア開発の特性を考えると、いずれの組織に於いても外乱に強い事が求められるでしょう。

実は埋もれているだけ

上記の様にプロセスを単純化して考えると標準化された組織やテーラリングの許される組織には外乱に対して脆弱なように思えます。しかし、これはターゲットとなる組織の規模が異なるのでそう見えるだけです。実際には想定外の問題に対し、制約の中で何とか解決しようと現場は必死に考え、行動している事も多いでしょう。

ここで大切な事はトップダウンでトップの活動を支援するだけでなく、ボトムの組織を支援できているかどうかだと思います(管理強化はプロセス問題を解決しない(こともある))。多くの大規模プロジェクトに共通する問題の解決を中心に改善活動が行われていますが、支援されていないので再発明が繰り返されています。現場の開発を効率化するには外乱への対応方法を共有し、支援する事が望ましいでしょう。

かつての日本では、QC活動などそれぞれのチームの経験や工夫を共有する活動が各組織で行われていました。しかし、CMMブームの頃から活動が組織中心の視点になり、個人やチームの経験に埋もれてしまいました。やはり、ボトムアップの仕組みも必要だと思います(トップダウンのWF、ボトムアップのスクラム、その成功の鍵)。

補完型チケット駆動開発

チケット駆動開発はBTS/ITS(障害/課題管理ツール)の障害票に相当するチケットでタスクを管理する開発技法です。全てのタスクをチケットで管理する完全型チケット駆動開発と、予め計画されていないタスクだけをチケットで管理する補完型チケット駆動開発があります(元気が出るチケット駆動開発 - 補完型TiDDの経験 - @XP祭り関西2010)。

補完型チケット駆動開発は計画外のタスクだけがチケット化されますので、プロジェクトでの工夫が記録されます。過去のプロジェクトの経験では

  • 仕様変更により発生した作業
  • 障害対応により発生した作業
  • 環境構築やリリースなど環境特有の作業

がありました。このなかでも、環境特有の作業の作業は一般化できると思われるTIPSが多く含まれていました。

プロセスのダイナミックな変更と補完型チケット駆動開発

プロセスモデリングの例題にあるプロセスのダイナミックな変更は、モデリング言語には表現が難しい課題でした。しかし、補完型チケット駆動開発では、チケットには開発中に動的(ダイナミック )に追加されたタスクの履歴が記録されています。

ダイナミックな変更は予め計画できなかった事象への対応により生じていますので、そこにはその事象に対する解決策が含まれています。事象が一般的であれば、他のプロジェクトでも有効なTIPSが含まれていることになります。

チケット駆動開発ではチーム内でタスクを共有し協調して開発できます([#TiDD] プロセスモデリングの課題からチケット駆動開発を考える)。補完型チケット駆動開発で得られるTIPSの共有を支援できれば、外乱に強いチームづくりができるでしょう。

組織強化への課題

現場で実践されたTIPSを組織的に活用できれば、外乱の度に再発明を繰り返さずに効率的に、問題を解決する事ができるでしょう。

その反面、過去の経験を一般化する作業はそれなりに負担になるほか、組織的な利用を標準化すると、最初に挙げた標準化された組織の様に考えない人を増やしてしまい、新しいTIPSを考える事もなくなってしまうかもしれません。

そこで、エキスパートシステムのように過去のチケットを参考に対策を考え(参照)、プロジェクトの問題にあわせてチケットを起票し(計画)、チケットを共有して協調する(実践)という利用方法が良いと思います。

このような一連の流れをすすめるには

  • チケットの運用方針を明確にする
  • プロジェクト完了時のふりかえりでTIPSをWikiにまとめる文化を創る
  • 事例やTIPSの発表会や勉強会など、チケット以外の情報共有を推進する

といった組織的な支援が必要でしょう。

まとめ

外食のメタファから外乱に強い組織を示し、補完型チケット駆動開発の利用を考えました。補完型チケット駆動開発はボトムアップな改善に利用可能で、組織プロセスをも補完するものでした。

利用にはそれぞれの組織文化に合わせた検討が必要で、現在の開発標準の見直しも必要になるかもしれません。しかし、プロセス改善はプロセスを固定化する事が目的ではなく、その名の通り改善する事が目的です。組織の経験や能力をうまく蓄積・利用できる様に、組織の目的に合わせて見直しを続けることで、組織の能力を最大限に発揮できるでしょう。

なお、今回は補完型チケット駆動開発を中心に説明しましたが、外乱が部分的で安定したプロセスなら、チケット作成時期でフィルタするなどの工夫で、完全型チケット駆動開発でも同じ事ができるでしょう。

このエントリーをはてなブックマークに追加


« 2014年12月 | トップページ | 2015年2月 »