LOC生産性でチームの開発能力を評価してほしくない

最初に、すいません。ただのグチです。

まあ、仕事をしていると嫌なこともあるわけで、腹の中でモヤモヤしているのも健康上良くないので、ここで整理してみようかと。

チームの開発生産性の比較にLOC生産性を使うな

結論はこれなんですけど、もうちょっとだけ。

保守開発なんてやっていると、他システム起因のプロジェクトにチームとして案件支援を行うことがあるのですが、それらを統括するPMO部隊の発言で、ひっくり返りそうになるのがコレ。

「今回は各チームとも生産性を○○KLOC/MM以上にして欲しい」

「オタクのチームは、見積生産性が☓☓KLOC/MMで生産性が悪いんじゃないか」

この手の発言聞くとやる気激減なわけですけど、仕事なので仕方が無い。。。

所謂クソコードが多いプロジェクトの方が生産性がよく見える

 そもそも、チームの開発生産性を比較するのに、LOC生産性を使うのは問題がおおすぎるのですよ。

保守開発の現場では、今回開発予定規模を「母体係数法」を使うことがあります。

この母体係数法では、

　今回修正規模　＝　実修正規模　＋　母体規模　×　係数

なんて式で開発規模を求めるわけですが、母体規模が大きければ大きいほど今回修正規模が大きくなるわけですね。

てことは、

• コードクローンがたくさんある
• 到達不能コードがたくさんある
• モジュール分割せずに巨大ソースを書く

なんて状態のプログラミングを行っているチームのほうが母体規模が大きいってことになるわけで。

で、オッサンはちまちまリファクタリングしたりして、少しでも書きやすいコード、修正しやすいコードにしようとメンテナンスしているわけですけど、そうやってメンテナンスすればするほど、母体規模は小さくなるし、修正が必要な量も少なくなる。

でも、実現する機能量は変わらないので、必要となるテストやドキュメントなどはさほど減らない。

なので、見た目上LOC生産性が悪くなるようにみえるわけなんですよね。

 改善すればするほど、何もしないチームよりも生産性が低いなんて言われたりしたらふざけるな、といってしまいたくなるわけですよ。

まったく、やってらんない。

そもそもプロジェクト特性を無視して開発生産性を比較するな

LOC生産性なんて指標だと、数字出すこと自体は案外柔軟に行えるもので、プロジェクトの形態を問わず生産性を算出できるわけですが。。。

バッチ中心のプロジェクトと、オンライン中心のプロジェクトの生産性を単純比較するなよと。

同じような理由で、生産性が出づらい基幹系システムと生産性が稼ぎやすい情報系システムを比較したり、生産性が出づらい超大規模なプロジェクトと生産性が稼ぎやすい小規模プロジェクトを比較するのも違うだろうと。

プロジェクト特性により、必要となるタスク、開発量は変わってくるのだから、十把一絡げにLOC生産性を評価してもしょうがないだろうに。

というか、同一チームにおける過去の案件と次回案件での開発生産性の比較以外で生産性なんか使うもんじゃあないだろうと。

予算削減の理由として開発生産性を問題にするべきじゃあない

こんな感じで生産性が問題になるってのは、要は予算を減らしたいって思惑なわけなんですけど、生産性なんて「生産性悪いんじゃないの」なんて指摘したって当然上がるわけない。

むしろ、どこかに歪みが生じるわけで、リスク上昇や品質低下などろくな事にはならんと思うわけなんですよね。

予算を減らしたければ、基本は要求といったフォーカス減らすべきでしょう。

無駄な要求、無駄なタスクを要求し、上積みしているにもかかわらず開発生産性が悪いって言うのは筋違いだろうと思うわけです。

まとめ

まあ、仕事を依頼する側も結局は更に上役に対して説明するために、LOC生産性を利用するって理屈もわからなくはないわけです。

誰にでもカンタンに計測ができるLOC生産性ならば、数多くのチームが共通の指針として算出する事自体は簡単です。

大人数、多数のチームが参画するようなプロジェクトでは仕方が無い理由があるのでしょう。

とはいえ、最初に戻るわけですけど、LOC生産性をチームの開発能力比較に使わないでほしいわけですね。

アカウンタビリティを易きに流れLOC生産性を使うのではなく、チーム特性ごとにきちんとした分析指標で説明できるようにしたほうが有用だと思うわけです。

全くやってらんないわけです。愚痴りたくもなりますよ。

以上

システム開発の見積りのための実践ファンクションポイント法

「多重請負」が優秀なエンジニアを幸せにできるかもしれない

ビジネスモデルの違いはエンジニアの価値を毀損しない - プロマネブログ

前回記事に幾つか言及いただいた言を受けて、もうちょっとだけ書いてみます。

エンジニア価値のあれこれ

前回の話について、もう少しだけ整理してみます。

まさにこの、ユーザが必要とする価値と、ソフトウェア原価のと差異が、生み出したソフトウェアの価値です。 

元請けを主体に取り扱っているオッサンは、受託開発におけるシステムの付加価値を以下の様な式で見積もってます。

システム価値　＝　システム売上　ー　システム原価　・・・　①

システム原価　＝　Σ（必要工数×人月単価）　＋　インフラ費用　＋　諸費用

上記の式から、エンジニアが生み出した価値（＝システム価値）を高めるには

• より高い需要を分析し、システム売上が高い案件を取ってくる
• 開発効率を向上し、必要工数を下げれば下げるほど価値が上がる

という認識で考えます。

よりユーザがほしい物をより効率的な開発により、高い付加価値を創造できるという考えですね。

これに対し、「人月商売」と問題視されるパターンでは、以下の様な数式が成り立ってます。

売上　＝　人月単価　×　請求工数　・・・　②

まあ、シンプルに人月単価に対し、需要工数を掛けて売上とする形です。

この場合、個々人の能力は無視して、人月単価の中に利益（＝平均的なエンジニア価値）と原価（＝給与や福利厚生費）などをまぶす形となるため、「能力を無視している」「エンジニアの価値を既存している」となるわけですね。

実際のところ、二次請け、三次請けとの間での契約の場合、このような形になってますね。。。

とまあ、同じ「人月を原価に使って商売している」という話ですが、①、②の両式では様相がかなり違う感じとなります。

※元記事のpaizaの話は、元請けの話なのに②の形で記載していたので、ツッコミをいれてました。

「多重請負」が問題解決の鍵を握っているんじゃあないだろうか

上記の②の式ですが、ずっと違和感に感じていたことがあります。

よく、多重請負構造なんて言われているSIerなんですけど、「請負」契約にて契約金額根拠で②式を使うのはおかしいよなあと思うわけです。

上記②は「成果物」ではなく「工数」がコスト根拠になっているわけで、「請負」ではなく、「SES（＝準委任）契約」を表しています。

多重請負構造において、本来であれば、①に準拠した式が使われていいんじゃあないかなとつねづね思うわけです。

この裏についてはおぼろげながら把握しており、本来であれば請負なので成果物をベースに契約を結ぶべきなんですけど、ひょんな事で工数超過となってしまった場合の追加工数を元請けに請求できなくなってしまうとか、見積もりが甘かった場合の追加工数を元請けに請求しづらくなってしまうとか、諸事情があるわけで。

で、これは単にパートナーさんの問題だけではなく、元請け側の問題として、きちんと成果物定義ができておらず事前の成果物定義を合意が取りづらいとか、要件をがっちり固めきらず要件変更の可能性があるため成果物を固めたくないとか、もろもろの事情があるわけで。

つまり、多重「請負」構造といいつつも、まともに請負ができていないという現実が人月ベースの準委任契約式の契約を常態化させているんじゃあないだろうかって思うわけです。

思考実験的。もし、きちんと多重請負ができていれば。

二次請け、三次請けは元請けとの契約を「成果物価値」で結ぶ形となります。

例えば、元請けの要求に従ってソフトウェア2本納品して２００万円、なんて契約を結ぶ形となります。

これを二次請け会社内の標準的なプログラマが１ヶ月かかって開発・テストすれば、実質人月単価は２００万円の仕事をしたことになります。

二次請け会社内の優秀なプログラマが例えば１週間で開発・テストすれば、実質人月単価は８００万の仕事をしたことになるわけですね。

※エンジニアの稼働率が下がってしまいますが。。。案件調整は必須ですね。

で、二次請け会社側ではきちんと実質単価を向上させたプログラマに対して、きちんと報酬を払うようにすれば良いわけで。

※例えば、実質単価の３０％を給与にするとかできれば。。。

このように、きちんと「多重請負」が成り立つのであれば、プログラマのスキルを「人月単価」に反映させることが可能じゃあないかな、なんて思うわけです。

※このモデルだと、きちんと保守性などを定義しておかないととりあえず動くソフトが納品されて保守が大変になったりするので、きちんと最初に機能要件だけでなく、標準化や性能要件など含め非機能要件含めて成果物定義することが必須となる感じですね。

きちんと検証してないのでザルな極論ですが、一つの解にはなるんじゃないかなって思います。

まとめ

まあ、だらだらと書きましたが、オッサンの職場でこの二次請け、三次請けに関する人月の話は明確には解決出来ておりません。

色々な壁がおおすぎて、明確な解決策を実現できてないって感じです。

元請けのオッサンの会社内部でも、こういった成果をどのようにパートナーさんと共有すべきか、議論したりもしてます。

まあ、パートナーさんも含めて共存共栄の道は常に考え続けなければいけない話でしょう。

そんな状況で、せめてもの改善策として導入しているのが生産性向上による残業０調整。

同一契約金額でも、仕事の実働時間が短ければ短いほど、実質的な単価が上がるってもの。元契約金額には、ある程度残業代なども織り込まれているはずなので、残業０ならその分だけ単価が上がるって感じかなと。

ほんと、些細な話ですけどね。

以上

なんでもアジャイル適応を追求するのではなく、プロダクトに合わせた適切なプロセス設計力が必要かな

アジャイル開発がSIビジネスと相性が悪い本当の理由：ITソリューション塾：ITmedia オルタナティブ・ブログ

保守開発が「なんとなくアジャイル」になってる事例を見てるので、単にフォーカス分割しづらい案件が一括請負としてまわってきてるだけかな。下手にアジャイルっていうとリリース間際に要件変更言うお客いるだろうし

まあ、SIerは基本要件をお客が持っているわけで、自分でコントロールできる場面はあまりないわけで。まあ、交渉力のあるベンダなら可能でしょうが、お客との力関係が弱い場合はなかなかうまくいかないでしょう。

となれば、フォーカス分割が困難な案件を多々相手にしなければならない場合、アジャイル型開発を相手にするのは困難であり、むしろウォーターフォール型開発や、従来のプロトタイプ／スパイラルモデル型の開発の方が上手くいく場合が多いと実感しているんですね。

実際、保守開発のような小規模要件多量開発型の運用では、至って自然にアジャイル開発を導入可能であり、また、力を発揮できる場面を多々認識しております。

まあ、アジャイル開発をSIビジネスと相性が悪いと認識するのは、「どのようなプロダクト開発をイメージしているのか」という個人のイメージの持ち方に落ち着くのじゃあないかなと思われます。

ウォーターフォール開発が再評価されたアメリカ

似たような話を前の記事で書いたような気がしますが、アメリカではオフショアが2000年前後より増加してきてます。

この時、ウォーターフォール開発が再評価された、という話を聞いたことがあります。

※もう昔なことなので出典は失念。

1990年代にアジャイル開発が産声をあげ、広まったその後、オフショア拡大によりウォーターフォールへの回帰があったわけです。

上記図は、アメリカでのグローバルなウォーターフォールの例です。

小規模プロダクト(例えば、プログラムの一式)ごとに仕様ぎめ、設計／開発、テストといった形の工程を分割し、アメリカ→インド→EUと言った形で、ウォーターフォールの工程を分散して実施する、という方式になります。

この方式の素晴らしいところは、時差を利用することで、常に各拠点はオンタイムで開発が行えることとなります。

つまり、実質24時間3交代制で開発しているみたいなもんですね。

このように、ウォーターフォール開発でも時にアジャイル以上の高速開発を実現できていたりするわけです。

こういう、グローバルな発想ができるのがアメリカの強いところだろうなあ。。。

ほんとうに必要なのは「プロセス設計力」

さて、上記のような形でウォーターフォール開発も再評価＋進歩している例を挙げてみたのですが、これをもってウォーターフォール開発が優れていると言いたいわけじゃあないです。

現に、アメリカでも自社プロダクトや時差なしニアショア開発では、アジャイルを利用する例も多い。ベンダでも、アジャイルを利用している例もある。

反面、上記のようなウォーターフォール手法を利用することで、高い生産性を発揮することも確か。

重要な事は、契約など顧客との関係、チームメンバーの特性、対象とするプロダクト、業務ドメイン、コストやスピードなど、様々な要因により求められる開発チームのスタイルは異なるわけで、その状況次第でアジャイルとの相性が良くもなれば悪くもなるというのが実情。

受託開発も一要因ですが、それが全てではないと思います。

なので、ウォーターフォールがよい、アジャイルじゃなきゃダメだ、みたいな単純化された考えに陥るのではなく、現在の状況から、ウォーターフォールが良いか、アジャイルが良いか、はたまたハイブリッドが良いか、適切な見極めをすることが必要でしょう。

つまり、自分がどういったプロセスを踏むべきか、きちんと創りだすことができるプロセス設計力が必要かな。

まとめ

まあ、色々書きましたが、結局のところ「今、自分は何を作っているのか」という視点にたつことが重要じゃあないかなと。

元の記事にある

「アジャイル開発手法でのシステム開発プロジェクトを推進」とか、「より高度なアジャイル開発手法でのシステム提供を目指す」

って取り組みが微妙なのは同意なんですけどね。

以上

IT担当者は、見積妥当性よりも投資の費用対効果を見たほうが良い

1ジョブ5万って普通なんですかね？

 まあ、増田記事の内容見るに、動的コンテンツの改修なんだろうけど、正直なこと言うとランサーズの静的コンテンツ作成5000円と比較している段階で、おそらく元増田氏はシステムの構造や内容など把握してないと思われますね。。。

そんな元増田向けの、保守会社からの見積もり妥当性を見極める簡易的な方法を、ベンダ側のプロマネのオッサンより伝えられればと。

類推法を使おう

昔、見積もりに関する記事*1書きましたが、パラメトリック法やWBS法等の見積手法は、システムの構造を熟知し、大体の作業量を理解していないと妥当性のある見積もりを把握することは困難です。

ユーザ企業側の元増田では、ちょっと厳しいかなと。

このようなユーザ企業側の元増田が見積もり妥当性を検証するための方法としては、「類推法」を利用するのが良いでしょう。

類推法ってのは、「過去の対応案件で似たような案件を元に見積もりを行う技法」です。この手法ですが、新規開発ではあんまり精度がでない見積もり手法なんですけど、保守開発では結構強力で、かなりの精度を出すことも可能です。

おそらく、保守開発って言っても半分くらいの案件は「画面の表示を変えたい」「表示している金額を変更したい」みたいな似たような案件になると思うんですね。

で、そういう案件を見積もったら、毎度見積書を取っておいてくださいな。

大体似たような種類ごとに整理しておくとベスト。

で、次保守会社から出てきた見積を、過去似たような案件と比較して値段が大幅にずれてないかチェック。

ものにもよるけど、個人的には2割以上ズレるようなら理由はきちんと聞いておいたほうがいいかな。

まあ、至ってシンプルな方法ですが、似たような案件、似たような改修内容であれば金額もほぼおなじになるはずなので、それなりに効果があります。

類似案件がない場合は、費用対効果で判断する

類似案件がない場合、その場合も見積もりの妥当性を検証しないといけない場面があるかと思います。

この場合は、割引キャッシュ・フロー法（DCF法*2）等を元に収益性判断使うと良いです。

要は、「案件成果物システムの価格が妥当か」という視点から、「システム価格を投資した場合に収益が十分あげられるか」という視点のほうが良いです。

ランサーズの案件なんて見ても、システム構造、対応内容、品質保証など様々な要因が違う以上は、何の参考にもなりません。

正直、類似案件がない場合の保守案件の妥当性検証は、よっぽど変な見積もりでない限り、同業者だってコンペティターだって検証困難です。

となれば、いくらで作れるか、よりも、現在の見積り価格を正として、このシステム投資で利益が稼げるか、といった観点のほうがよっぽど妥当な投資ができるでしょう。

まとめ

まあ、色々書きましたが、まとめると

• 類似案件があればそれと比較する
• 類似案件がなければ、費用対効果で判断する

っていうのが、ユーザ企業のIT担当者として考えるべき「適正価格の判断」になるかな。特に2点目を重視するのが良いですね。

システムの見積金額にばかり注目が行きがちなんですけど、システムの見積を行うってことは投資を行うことです。

ユーザ企業側の担当者として、ぜひとも費用対効果の妥当性を見極められるようにしたほうが良いかなと思いますよ。

以上

ゼロからの現在価値計算とDCF法（入門編）

*1:システムの工数見積とは統計である - プロマネブログ

*2:DCF法 - Wikipedia

システム開発の価値生産性を高めるためには

サービス価格は労働の値段である: hamachanブログ(EU労働法政策雑記帳)

 この手の話、生産性ってよくIT業界なんかでも話題になる話なので、ちょっと考えてみます。

開発生産性と保守生産性と価値生産性

IT業界、特にソフトウェア開発の現場では、開発生産性、保守生産性、労働生産性それぞれ語られることが多いです。

開発生産性は、主にソフトウェアを作成するのにかかる生産性。プログラミングスキルが高いと生産性が高いとか、記述力のある言語を使うと生産性が高いとかってやつです。

保守生産性は、維持保守に必要となる生産性で、運用を自動化して少人数で保守できるとか、トラブルが起きてもハードランディングしないので復旧に手間がかからないとかってやつです。

労働生産性は、元記事でも言われるように最小の投入工数で最大限の収益を得るってやつです。労働生産性＝価値生産性ですね。

IT業界、特にソフトウェア開発等の生産性を語られる場合、大体の場合開発生産性化保守生産性が語られることが多いかと思うんですけど、あまり価値生産性って語られないことが多いんですよね。。

SIerのシステム開発でよく使われる開発形態として、スクラッチ、パッケージ、SaaSを題材に語ってみようかと思います。

価値生産性あれこれ

価値生産性を語る際に欠かせないのが、価値の売り方です。

ここでは、SIerの観点から、「スクラッチ」「パッケージ」「SaaS(ASP)」の3種でウリ方を考えてみようかと思います。

まず、スクラッチですが、基本的には開発したソリューションの価値が提供価値と等しく、また、それにかかる労力は開発工数に等しいです。

この場合は、開発工数を最小とし、提供するソリューションの価格を最大にすることで価値生産性が最大となります。

つまり、開発生産性を高めることとほぼ同意です。

同一機能のシステムを３回開発しようとする場合は以下の様な形となります。

	提供価値	工数
1回めのシステム開発	スクラッチ開発の価値	開発工数
2回めのシステム開発	スクラッチ開発の価値	開発工数
3回めのシステム開発	スクラッチ開発の価値	開発工数

毎度毎度、同一の開発工数を使い、同一価値のシステムを提供する様な形となります。

※本当は、こなれた開発ができるので２回目以降は生産性向上するのですけど、面倒なので除外。

次にパッケージですが、標準化ソフトとカスタマイズから成り立つパッケージの場合、カスタマイズ部分ではスクラッチと同じ価値生産性の考え方となる反面、標準化ソフトは、一度開発して以降は完全に使い回しとなりますので、2回目以降の適応では開発工数はほぼ0です。標準ソフトはスクラッチ開発でいうところの内部設計以降の開発工程を対象にすることが多く、毎度の開発は外部設計部分までの設計＋カスタマイズソフトの作成となります。つまり、以下の様な関係となります。

	提供価値	工数
1回めのシステム開発	カスタマイズ開発の価値＋標準ソフトの価値	カスタマイズ開発の工数＋標準ソフトの工数
2回めのシステム開発	カスタマイズ開発の価値＋標準ソフトの価値	カスタマイズ開発の工数
3回めのシステム開発	カスタマイズ開発の価値＋標準ソフトの価値	カスタマイズ開発の工数

スクラッチ開発と比較すれば、１回めのシステム開発では通例標準化開発部分では開発生産性が高くない（スクラッチに比べれば面倒な設計となる）ため、スクラッチ開発より開発ボリュームが増加するため、価値生産性が低いのですけど、２回目以降のシステム開発ではスクラッチ開発よりも、標準ソフトを利用している分開発工数が少なくなります。

同一の標準ソフトの提供回数が多ければ多いほど、スクラッチ開発より価値生産性が高いこととなります。

ただし、保守生産性はスクラッチよりも低いです。システムが１つの標準ソフトに対して複数のカスタマイズソフトが存在することから、レグレッションテスト等の負担が非常に高まります。標準ソフトは開発会社資産となるため、メンテナンス費用は自社持ち出しが多いです。そこら辺の負担は無視できない場合も多いです。

次にSaaS(ASP)ですが、標準システムとデータパラメータシートの入れ替えによりシステムを提供するため、標準システムの初回開発以降はほぼ開発工数は０となります。パッケージよりも標準化領域が多く、外部設計（外部仕様）も統一化されます。導入要件である概要設計以降のすべての部位が再利用されるわけです。つまり、以下の様な関係となります。

	提供価値	工数
1回めのシステム開発	SaaSの価値	標準ソフトの工数
2回めのシステム開発	SaaSの価値	パラメータ入れ替え
3回めのシステム開発	SaaSの価値	パラメータ入れ替え

パッケージ開発と比べれば、１回めの標準システムの開発はパッケージ以上に開発生産性が高くないです。パッケージは比較的ステートレスな設計ができるのですけど、SaaSでは利用する複数のユーザデータが共通の領域にであるため、セキュリティや権限管理などに多数の開発が必要となるからです。

反面、２回目以降はパラメータの入れ替えだけでユーザ導入が対応できるため、工数はほぼ０みたいなもんです。

つまり、パッケージと同様に影響回数が多ければ多いほど、価値生産性が高くなることとなります。

ただし、保守生産性はトコトン低いです。維持にかかるコストはスクラッチやパッケージ以上です。パッケージと同様、標準ソフトは開発会社資産となるため、メンテナンス費用は自社持ち出しが多いです。そこら辺の負担は無視できない場合も多いです。

価値生産性を高めるには 

スクラッチ、パッケージ、SaaSの各種生産性についてまとめると以下のようになります

	価値生産性（１回売り切り）	価値生産性（複数）	開発生産性	保守生産性
高い	スクラッチ	SaaS	スクラッチ	スクラッチ
↓	パッケージ	パッケージ	パッケージ	パッケージ
低い	SaaS	スクラッチ	SaaS	SaaS

 ※ざっくりなので、必ずしも成り立つわけではないのでご注意。

１回だけのシステム開発に限定すれば、スクラッチ開発が最も価値生産性が高く、開発生産性や保守生産性の高いソフトウェア開発ができます。

コレに対し、複数回のシステム提供を念頭にするのであればSaaS形式が最も価値生産性が高いこととなります。

となれば、理屈上は非スクラッチ開発の方が良いって結論になりそうですが。。。

非スクラッチ開発はときとして開発生産性の低い開発手法を選ばなければならない場合があります。前述した通り、開発物も多く複雑です。

また、パッケージもSaaSもソフトウェア資産の扱いで、契約締結方法の見直し（顧客資産から自社資産への変換、運用費の自社持ち出しなど）が必要となるので、基本的には開発の現場だけでは対応は厳しいかなと思います。

複数の売り先も無いのに非スクラッチ開発を行ったら、開発・運用コストだけでエライことになりますしね。

したがって、非スクラッチ開発の適応可否について、現場の立場導入するインセンティブは働きづらいので、ときには個別プロジェクトや開発現場の枠を超えた戦略的な開発計画が必要になるかと思います。

また、ユーザの要求を達成しようとした場合、SaaSはあまりにも固定的で、業務要件を達成できないこともしばしばです。

となると、カスタマイズやその他パッケージ適応なんてのも必要になるわけで、そういった複雑なシステムをきちんと開発、運用できるようマネジメント能力が問われる形になるかと思います。

そういった製品戦略に対して適切な能力開発についてもきちんと計画を立てなければ、価値生産性の向上は絵に描いた餅でしょう。

資本集約と労働集約という言葉がありますが、SIの世界はよく労働集約と言われます。

であれば、労働資本をいかに高めるか、適切な投資計画がカギを握るかと。

まとめ 

上記の様に、システム開発の価値生産性を高めるためには、キーワードとして「再利用」「標準化」そして「戦略的投資」なんて言葉で表せます。

上記例はSIの話ですが、一般論でも通じるところはあるかと思います。

価値生産性を上げるためには、現場の努力で開発生産性を高めることももちろん必要ですが、何より経営方針といった戦略レベルで立案することが必要かなと。

というわけで、結論としては元記事の話と同じ。労働生産性あげたきゃ

なにい？労働生産性が低いい？なんということだ、もっとビシバシ低賃金で死ぬ寸前まで働かせて、生産性を無理にでも引き上げろ！！！ 

 ではなく、そうやって文句を言っている経営者や役員が、きちんと知恵絞って戦略練らなきゃ労働生産性をあげようなんか無いですよってことで。

以上

戦略思考トレーニング (日経文庫)

McFarlane IT Portfolio分析の学習メモ

ただの情報を残すためのメモですが、何かの参考になれば。

「McFarlane　IT　Portfolio」のメモ

ITコンサルなんで最近よく使われるIT資産分析手法で、McFarlaneって方の提唱した「McFarlane　IT　Portfolio」ってのがあります。

簡単に言うと、「現時点戦略的か」「将来戦略的か」でIT資産を占うっていう分析手法です。

それぞれのエリアについて説明すると以下のとおり。

• 革新性が高い＆現収益性が高い　・・・　strategic（戦略的システム）
• 革新性が高い＆現収益性が低い　・・・　turnaround（変革システム）
• 革新性が低い＆現収益性が高い　・・・　factory（工場システム）
• 革新性が低い＆現収益性が低い　・・・　support（支援システム）

で、これらについて代表的なシステムをマッピングすると以下の様な形となります。

戦略的システムには、新しいサービスを提供しつつ収益を上げるECや各種ウェブサービス等が該当します。新技術などが比較的適応しやすい領域で、ウェブサービス企業などが多く参入してます。

戦略システムの様な革新技術を元に収益を稼がなければならない方面については、ウェブサービス企業みたいな形で内製化を行うことで差別化の原動力とするインセンティブが働きます。アジリティの高さが生かせる分野です。

変革システムには、直接収益には上がらないけどチャネルの拡大等を目指した投資用のウェブサイトやCRMなどが該当します。

変革システムは、当初は変革でも、ゆくゆくは工場システムになったり、戦略的システムになったりと成熟度合いによりほかの領域へ移動するシステムです。例えば、EDIも十分業界に普及し、革新性がなくなれば、工場システムへ移動したりもします。

工場システムには、目新しさは無いけど、確実に収益を上げるための業務基幹系システムが該当します。枯れた技術と安定運用が好まれる領域で、SIerが最も得意とする領域です。組み込み系等もこちらに該当することが多いです。

工場システムに該当する業務基幹系では頻繁な改変よりも、安定稼働と低コスト化が求められる領域であり、自社で人員を抱えるよりもSIer等のベンダに業務委託を行うことにメリットが出てくる領域です。ウォーターフォールなどでかっちり対応するほうが利点が大きいです。

支援システムには、直接収益にはならないし、最悪なくても代替可能な人材管理やコミュニーケーションサービスなどが該当します。

支援システムは、直接的な収益につながらないため、あまり企業ごとの差別化を働かせるメリットが無いシステムです。このため、ERPなどのパッケージやSaaS等の利用が強い領域です。 

※細かい分析は元論文を参照していただきたいのですが、元論文のリンクを紛失。。。

得意領域については、元論文にはない話ですが、独断と偏見で追記してます。

まとめ

とまあ、こんな感じでMcFarlane　IT　Portfolioを使ってIT資産を分析できるわけです。

IT戦略を立案する場合、自社の事業拡大のために領域ごとに適したシステム導入方針や、システムを開発するための技術、開発手法、運用方針などを考える必要があるわけですね。 

以上

「アジャイルの神話」にしないためのプロマネ力

ブルックスの法則とはなにか - 未来のいつか/hyoshiokの日記

後半の下り。ウォーターフォールでも、出荷前検収は当たり前だし、結合テストで中間検収やったりするので、ちょっと違うかな。基幹系だとフォーカス分割できない場合があるので、単純なアジャイル礼賛は危険だよ

以前*1似たような記事を書いたのですけど、アジャイル開発はウォーターフォール開発(以下WF)の欠点を克服していると言う様な言説は危険と思っているのでちょいとだけ書きます。

アジャイルが使いづらい案件

 いろいろな開発を行っていると、アジャイルが有効に作用するプロジェクトと、WFが有効に作用するプロジェクトを見かけます。

アジャイルが有効に作用するプロジェクトは、フォーカス分割が可能でフォーカス制御が可能なプロジェクトです。

このフォーカス分割ですが、適応条件がかなり厳しいと感じることもしばしばです。

フォーカス分割づらい事例ですけど

• 請負案件（請負案件はフォーカス分割しづらい力学が働く）
• 制度案件（制度案件は制度施行日がユーザ利用日であることが多く、制度施行日にすべての機能構築が求められるフォーカス分割困難案件の代表）
• システム更改（EOSL*2対応などは、現在の要件と同一性を求められるフォーカス分割困難案件の代表）
• バッチ系案件（バッチ系の案件は、システム全体で1つの機能を構築することが多い）
• 外部接続システム等の関連するステークホルダーが多い案件（関係者が多いと、ステークホルダー全員でのシステム仕様の合意を取る必要がある場合も多くフォーカス分割しづらい）

などなど。ココらへんの案件で無理矢理アジャイルを適応した結果、イテレーションによる反復コストが増大して、結果ウォーターフォールで予想されていた以上のコストとなってしまった案件を見かけたりします。

 言い換えれば、「WEB・オンライン系」「自社の非基幹系」「制度に関係のない営業案件」といった案件が、アジャイル適応の鍵と言えます。

組織学習と開発手法

あと、アジャイルのメリットとしてよく言われる「組織による学習」ですが、ウォーターフォール開発だからやらないってわけでもないのが実情。

よくある大規模システムの保守開発では、保守メンバーが継続して開発を行うこともあるため、ウォーターフォール開発でもテストの自動化や知識集積を行っている事例はよく見かけます。

新規開発主体の場合でも、チーム制を敷いて、コアメンバーの要員を固定的にしたチームで複数の開発を繰り返すことで、知識集積を行う例もよく見かけます。

というか、身も蓋も無いこと言ってしまえば、アジャイルだってイテレーションの度にメンバー入れ替えしていた生産性上がらないわけで、組織学習の利点は、開発手法の問題ではなく組織管理の問題だということなんですよね。

まとめ

アジャイル開発もまた、銀の弾丸でも特効薬でも無く数多の開発手法の一つでしかありません。

人月の神話は名書だと思いますし、前半部分は非常に同意なんですけど、そこからアジャイルを開発手法の有用性を訴え、ウォーターフォールを貶してしまうと、また別の危険が生じると思います。

それこそ、アジャイルの神話になってしまいます。

そういった意味では、プロジェクト特性を見極め、アジャイルが有利か、ウォーターフォールが有利かきちんと判断する目利き能力を鍛えることが必要だと思います。

また、組織としての学習の有用性を理解し、組織育成を行うマネジメントを積極的に取り入れることは、開発手法の如何にかかわらず必要だと思います。

真のプロジェクトマネジメントとは、開発手法の使い方にとどまるのではなく、そのさらに一歩先の深淵にあるのではないだろうか、と常々感じざるを得ないのです。

※まあ、人月の神話は名書であることは間違いないので、一度は読んどくべきだという結論は変わらないですけどね。

以上

人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)

*1:ウォーターフォール開発とアジャイルの本質 - プロマネブログ

*2:EOSL = end of service life