« リスクと問題と課題を再考 | トップページ | Redmine .Net APIであるredmine-net-api »

2012/12/16

現代のソフトウェア開発で構成管理が重要になった理由

プロジェクト管理ツールBacklogを作っているヌーラボ社の開発者が書いた記事「現代のソフトウェア/サービス開発で構成管理が重要になった理由」がとても分かりやすいのでメモ。
構成管理がソフトウェア開発のサプライチェーンの一部になってきたのが原因ではないかと思った。
ラフな感想。

【元ネタ】
DevOps時代の開発者ための構成管理入門(1):現代のソフトウェア/サービス開発で構成管理が重要になった5つの理由 (1/2) - @IT

DevOps時代の開発者ための構成管理入門(1):現代のソフトウェア/サービス開発で構成管理が重要になった5つの理由 (2/2) - @IT

【1】記事では、構成管理が重要性を増してきた理由として以下が挙げられている。

【1】簡単になってきたプログラミング
【2】クラウド(PaaS)の登場
【3】さまざまな用途のツールの進化
【4】ソフトウェアビジネスの移り変わり―アジャイルへのシフト
【5】リーン型の開発プロセスの重要性の高まり

RedmineやJenkinsやGitなどのツールの隆盛、クラウドの普及、アジャイル開発への注目度の高まりなどの昨今の流れを見ると、ソフトウェア開発をもっと効率化しようとする流れ、つまり、リーンソフトウェア開発の流れが背景にあるように思う。

リーンソフトウェア開発の発端は、トヨタ生産方式(TPS)にあると言われる。
僕はTPSはよく知らない。
でも、その発想の根底には、「いかに効率良く在庫管理すべきか」という命題がある気がする。

【2】在庫は、売れる前の製品や商品を倉庫に保管しておくのだから、在庫回転率が悪いほど、資産価値は劣化する。
在庫問題の構造を把握するために : タイム・コンサルタントの日誌からにもあるように、在庫があると在庫金利が発生して、余計にコストがかかる。
金利がかかるということは、住宅ローンや消費者金融のように、借金にプラスアルファのコストがかかっているということを意味している。

かと言って、在庫がゼロであると、売りたい時、本来売るべき時に手元に製品や商品がないために、販売機会を失い売上が立たない。
JITのような優れた在庫管理と思われていた手法も、東日本大震災などの天災でサプライチェーンがズタズタにされた時は無力だった。
良い在庫・悪い在庫 : タイム・コンサルタントの日誌からでは、安全在庫、計画在庫という概念で、在庫という概念を区別しようとしている。

また、その在庫はストックですか、フローですか? : タイム・コンサルタントの日誌からの記事にもあるように、15年醸造したウィスキーの方が価値があがる場合、在庫とはそもそも何なのか?

【3】BtoB企業とサプライチェーンの強者 ~これから就活をする大学3年生へ : タイム・コンサルタントの日誌からでは、自動車、家電、農業の3つの分野で、サプライチェーンを分析している。

図1 自動車業界のサプライチェーンを見れば、トヨタやホンダ、マツダなどの自動車組み立てメーカーが何故あれほど強いのか、ということがよく分かる。
組み立てメーカーの鎖が一番細いから、彼らが価格決定権を持っている。

図2 電機業界のサプライチェーンを見ると、ソニーやパナソニック、シャープなどの家電組み立てメーカーが苦境に陥っている理由がよく分かる。
組み立てメーカーよりも量販店の方が現代では強い立場にいる。
また、各メーカーがお互いに部品を融通しあっているので、製造計画がマチマチですぐに在庫が膨れ上がる構造がある。

図3 農産物のサプライチェーンを見れば、青果市場が価格を決定しているけれど、天災で農産物は出来不出来がバラつきやすいし、そもそも野菜などは長期間在庫できないから、変動性が高い。
サプライチェーンを作ること自体難しい。

この記事では、生産者から消費者までのサプライチェーンを分析することで、消費者(顧客)へ価値をもたらすには何を改善したら良いのか、どこに問題があるのか、をひと目で分かるようにしてくれているのが興味深い。

【4】すると、ソフトウェア開発のサプライチェーンはどうなっているのか?
ウォーターフォール型開発では、要件定義→設計→開発→テスト→リリースというV字型で流れていく。
一番無駄が多いのは、要件定義とテスト・リリースの工程だろう。

要件定義で要件を聞き漏れていたから、仕様漏れが出て手戻りが発生したり、リリースした後で、こんな機能ではなかった、と言われる時がある。
設計して開発した後、テストで動かしてみて、初めて性能要件を満たしていなかった事実が判明したり、まずい設計のためにバグが多すぎた、とか分かったりする。

アジャイル開発が注目されてきている理由の一つが、要件定義の工程で顧客を巻き込む、ないし、内製開発することでプロダクトオーナーと開発チームが一体化することで、要件の取りこぼしや仕様漏れ、リリース後の認識の食い違いをなくそうとしているのだろう。
また、V字型の流れそのものがサプライチェーンとして長過ぎるならば、もっと短くした方がいい。
だから、タイムボックスでのアジャイル開発もその問題解決になると思われているのだろう。

また、構成管理が重要になってきた理由は、テストやリリース工程の作業が従来は手作業だったり、数多くのプロセスを踏むために時間がかかりすぎていた問題点を解決しようとする流れの一つと捉えることもできるだろう。


業務モデリングの分野では、サプライチェーンの管理(SCM)がとても重要で、問題解決するためにモデル化の技法が数多く生み出されてきた歴史がある。
SCMの基本は在庫管理といってもいいだろうと思う。

この考え方はもっと深めてみる。

|

« リスクと問題と課題を再考 | トップページ | Redmine .Net APIであるredmine-net-api »

Agile」カテゴリの記事

Jenkins」カテゴリの記事

Redmine」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

経営・法律・ビジネス」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



« リスクと問題と課題を再考 | トップページ | Redmine .Net APIであるredmine-net-api »