ソフトウェア開発のムリ・ムダ・ムラ
先日こちらのブログを読ませて頂いて、なるほどねーと思ったのですけれど。
割としっくり来ていない同僚とかもいて、ちょっと別の視点から考えてみる。
<前提知識:管理工学の世界>
「マネジメント」と呼ばれる世界にはちゃんと工学的な学問体型が存在します。
所謂「管理工学」とか「経営工学」とかがそういうところにあたります。
慶応の理工学部管理工学科とか、東工大や早稲田の経営システム工学科がこのあたりの領域。
だと思う。多分。早稲田はそうだった。
この辺りの学問はどちらかというと工場とかを対象にしたものが多くて、
ソフトウェア開発にはあまり向かないのだと思っていたのだけれど。
意外とこの管理工学の世界での知識が使える部分もある一方で、
ITの人たちが知らない世界でもあるなぁと感じている。
<ムリ・ムダ・ムラ>
「三無主義」と呼ばれるこの、「ムリ・ムダ・ムラ」を徹底的に排除する、という考え方。
あるじゃないですか。
トヨタ生産方式の根幹となる考え方ですけれど。
参考文献はこのあたり。ちょっと今手元には無いのでページとかはわからないです。
「ムダ」な仕事を失くしましょう、はわかりやすいと思うんです。
「ムリ」な仕事を失くしましょう、もまぁ炎上したくないですもんね、誰も。
ネットで検索すると、ムラは「ムリとムダが混在している状態」と書かれております。
この、「ムリとムダが混在している状態」っていうのが結構わかりにくいと思うんですが、ここが結構肝だったりします。
ムリとムダが混在した状態とはどういう事か。
例を出すと、5分で終わると思っている仕事が1分で終わることもあるし10分かかることもある、という状態。これがムラ。
トヨタがムリやムダを無くすためにどうしたか、というと。
まず、この「ムラ」を徹底的に排除することから初めたわけですね。
りぴーとあふたみー。ムリやムダを無くすためにはまずムラから。
そうしないと、何がムリなのか、何がムダなのか、どうすれば排除できるのかもよくわからないのです。
「ムラ」を排除するために何をしたか。
ここで出てくるのが「標準化」の考え方ですね。
「標準化」という言葉には色々な意味があって、
部品の標準化や作業の標準化、サプライチェーンの標準化まで色々な事が考えられますが。
全て、「ムラを無くす」ために行われているものです。
詳しくここを解説しだすとボロが出るのでしません。
じゃあ、ソフトウェア開発でも真似すればいいじゃん。
とはならなくて。
標準化の概念はあくまで、「毎回同じ仕事で同じものを作る」という、
量産の考え方なので、
基本1つ作ればあとはコピーできるソフトウェアの世界には使えないわけです。
じゃあ何でこんな話を書いているのかと。
<ムラと時間の関係>
ムラっていう言葉は、言い換えると、「ばらつきの大きい状態」の事をいうわけです。
ばらつきの大きい状態、とは標準偏差の大きい状態ですね。
ということで最初に引用したブログに書いてある事の根本的な考え方は、
製造業で1970年代とかから言われている事なので、
まずちゃんと抑えておきたいところです。
じゃあこのムラ、どうすれば抑えられるのか。
一般的に、ムラのあるものに対して、長期で予測しようとすると、
期間が長くなるほどにリスクは高まります。
この辺りは金融工学の人が得意なはず。
参考文献はこのあたりで。
確率・統計でわかる「金融リスク」のからくり (ブルーバックス)
- 作者: 吉本佳生
- 出版社/メーカー: 講談社
- 発売日: 2012/08/21
- メディア: 新書
- 購入: 2人 クリック: 15回
- この商品を含むブログ (6件) を見る
まぁ読んでもらえればわかるんだけど、
長期投資というのはリスクもリターンも高いです、というお話。
金融に限った話じゃなくても、
サプライチェーンにおけるブルウィップ効果なんかも同じ理由。
ブルウィップ効果 - Wikipedia
期間が長かったりレイヤーが多かったりするほどこのばらつきが大きくなるのは、
ビールゲームをやってみると凄くよくわかるのでおすすめ。
多レイヤーで全員がリスクヘッジを始めるととんでもないことになるんですよ。
で、更に厄介なのは、開発においては多くの場合、
突然開発に必要な時間が短くなる ことよりも、
突然開発に必要な時間が長くなる
事のほうが圧倒的に多いということ。
結果としてこのムラの分布って、悪い方に振れる割合の方が高くなるのです。
ああやだやだ。
<ムラを減らす方法>
徹底的にムラを排除する方法っていくつもあるんですけれど。
その一つが長期予測→短期予測に舵をきる、ということ。
これが最初に引用していたブログで言われていた事ですね。
短期予測の方がリスクが低い、という話はちょっと上でしたとおり。
ここまで書けばなんとなくわかってくれると思うんですけれど、
「ムラの多い状態」って「管理のできていない状態」なんですよね。
で、そもそも開発というただでさえムラの多い仕事に対して、
「全体を予測して管理すること」なんて不可能なんですよ。
不可能なことをやろうとして「やっぱりできませんでしたてへぺろ(死語)」
っていうよりは、
最初から諦めたほうがまだマシ、ということなのではないかと思うのです。
不可能を可能にするにはそれなりの理屈や理論か、強運が必要ですから。
逆に言えば、短期での予測であれば確度高く出来るので、
そっちは徹底的にやる必要がありますね。
それをちゃんとやって、まず管理できる状態を作ることが大事で、
管理できる状態が出来ると自然にムリやムラが見えてくる、という事。
ムラを無くす>ムリやムダを無くす というこの優先順位が大事なので、
結構僕は最初のブログがしっくり来ているのです。
<まとめ>
- 管理は工学されている
- ムリやムダを無くすためにはまずムラから
- 長期予測はムラが大きい
- ムラを無くすには長期より短期
- ムラがなくなればムリとムダが可視化される
- ムリとムダが可視化されれば削減方法を考えられる