2015年5月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
無料ブログはココログ

« 2010年3月 | トップページ | 2010年5月 »

2010年4月

2010年4月30日 (金)

【生産性向上】調達側からみた生産性向上の意味②

先に「開発費用に関するせめぎあいは、勉強した方が勝ち、なのだと思う」と書いたが、調達側にも勝機は当然ある。

まず、開発方法の改善をSI会社に提案した場合である。
この場合、改善による効果刈り取りは、かなりの割合で調達側が刈り取る権利を有しよう。

さすがに全てというのは酷であろうが。
SI会社には「調達側にあわせる」という負担が起こるから。まあ、これは請負の場合のみかもしれない。

しかし、調達側は、このようなSI会社の領域に入ってどうこういう前に、すべき事がある。

それは「今回のシステム調達に、自社はいくらのビジネス価値を見出すのか」の合理的な金銭換算見積りである。

その上でSI会社に「我々はこの開発にこれだけのビジネス価値を見出す。故にこの予算範囲で開発して欲しい」と対等なビジネスパートナーとして要求するのである。
そしてSI会社は、自分がそれで受注に見合う得をするならば受ければ良いというスタンスが留保されている。
このような関係となるべきであろう。

これは永遠の課題…というかそう「言われてきた」。

しかし、考える価値はある。

得をしたいと考えるのは当然である。

しかし、他者の努力による他者が得るべき利益を掠め取ろうとしてはならない。

他者に自分が依存している時はなおさらである。
そのツケは必ず自分に返ってくる。
ひょっとしたら倍返しで済まないかもしれない。

2010年4月27日 (火)

【生産性向上】調達側からみた生産性向上の意味①

誰でも得をしたい。
利益の最大化を目的とする企業であれば、なおさらである。

このご時世、同じものであれば少しでも安く調達したいと思うのは当然である。

しかし、「同じものであれば少しでも安く」の前半を維持しつつ後半を達成しなければ意味が無いことをちゃんと理解しておくべきである。

同じものであれば…。
大量生産のソフトウェアなら、それは簡単に達成可能な条件である。
「少しでも安いMS-Office2007」みたいに。

しかし、エンタープライズ系ソフトウェアはそういうわけにはいかない。

こいつから得してやろうと思っている相手、つまりSI会社もまた企業である。

SI会社からみれば、理想は、開発生産性を向上させる一方で、顧客には従来どおりの算出方法で開発費用を請求というのが理想である。

開発費用に関するせめぎあいは、勉強した方が勝ち、なのだと思う。
ここでいう勉強は大阪人のいう勉強ではなく通常の意味であるが。

まず、基本的にはSI会社が自己努力で生産性を向上させたならば、その果実はSI会社側のものである。調達側に還元する義務は無い(義理はあるかもしれないが)。
そして、調達側は、自力でその向上策を考え、もしくは知り、SI会社にそれで行うように提示した段階でその果実にあずかることができる。
…このような関係が必要なのではないだろうか。

もちろん、これをベースにSI会社の営業戦略を加味するのであるが。

「契約は人月なのだからSI会社側で現実に人月が減るのなら正直に開示して値引きすべきだ」と言うのは野暮である。
「ならばお宅向けの開発は生産性向上策は取らずに愚直に当初からの開発で行かせていただきます」と言われるだけの話である。口では言わなくとも実行行為として。

SI会社もまた利益の最大化を目的とする企業である。

調達側からみれば、同じ費用でも、SI会社の生産性が上がることは、大抵の場合、好ましい事である。
それが前向きで合理的な改善であれば。

しかし、顧客側からの極端な単価下げ要求等によるプレッシャーに起因する「生産性向上」は曲者であることは言うまでもないだろう。

2010年4月23日 (金)

投資としてペイするソフトウェアとは生産性の高いソフトウェアなのだろうか

我々はどうしてソフトウェアを作るのだろう。楽しみたい、ビジネスに使って儲けたい…何でも良いけれど、
どうして生産性を含む一律の指標で開発者を縛ろうとするのか。

楽しんだり稼いだりするのにペイするか否かの視点は何故無視されるのか。
これを「測るすべが無いから代替指標で仕方がない」というのは本末転倒ではないだろうか。

ペイするか否かは、いわゆる「開発規模/投入コスト」に対してではないのではないか。
いや、ソフトウェアを作って売ってのSI会社ならそうであるかもしれないが、ソフトウェアを必要とする活用するユーザー側の本心はそこではなかろう。
投資価値にどのように作られたかは本来関係ないはずだ。

ユーザーは欲深過ぎないか?
それは大抵、自分のためにならない。

必要なのは投資するに足る価値を生み出すソフトウェアであって、いくらの労働が費やされその対価を如何に低く抑えたかなどではないことは明らかではなかったか。
どこで間違えたのだ…他に測るものが無いから?

それが答えになるのだろうか。

2010年4月20日 (火)

コンサルに実務経験は必要か

コンサルにコンサルの実績を聞くのはともかく、当該分野の実務経験を詳細に聞くのは意味がないと思う。

聞きたくなる気持ちは分かるが、これは物事はまず丁稚からという発想から来るように思える。
コンサルに何を期待するかの問題なのかもしれないが、ソリューションは経験から来るとは限らない。

そもそもコンサルが一々経験したことしか提案できないと考えると、それは陳腐化しているかもしれない提案しか得られない可能性が出てくる。

あなたは改革をしたかったのではないだろうか。

頭でっかちで実務を知らないやつ…とバカにしたくなることもあろう。

しかし、その発想は間違っている。
あなたは頭でっかちの頭が欲しかったのではないか。
実務はあなたが知っているではないか。

実務も頭も共に充分でないコンサルはもちろん非難に値するが、頭でっかちをバカにするのは折角の機会を失うことになる可能性を自覚すべき。

実務経験偏重は、発想を妨げるものというくらい考えても良いのではないだろうか。

2010年4月16日 (金)

美味しいソフトウェア(2)

美味しいソフトウェアか否かを「ユーザビリティ」の言葉で語り切ってしまうことはできるだろうか。

「ユーザビリティ」の定義次第ということはできる。
しかし言葉遊びに陥って、結局意味は無いかもしれない。

ソフトウェアの美味しさは、ウォーターフォール開発では最後まで分からないというのがステレオタイプ的な考え方だろう。
そして、だからアジャイルで実施すべきだ…と。

しかし、アジャイルも全体最適の観点から見て視野狭窄が起きる可能性が否定できないのではなかろうか。

ソフトウェアの美味しさとはどういうものかを考えてみることは意義が有るのでは無いだろうか。

そしてこれは、人により考えが異なってよいものであると考える。

2010年4月13日 (火)

美味しいソフトウェア(1)

同じソフトウェアを別な組織が開発する思考実験。
色々な切り口が考えられなかなか面白いと思う。

例えば、定量的管理。
設計書では優劣の比較が困難なものでも、出来上がったソフトウェアを使えば人は感覚でその善し悪しは判断できる。

計測なければ制御なし…、これの本質は比較できなければ何も分からないということ。
要は、ソフトウェア開発~エンタープライズ系ソフトウェア開発が特に当てはまるだろうが~では、同じ要求に対するソフトウェアを何個も作り、使ってみて一番良いものを選ぶということは、なかなか出来ない。

では何を比べればよいかということで、「代わりに考えられたもの」が開発品質・生産性などのメトリクスだろう。
過去に作った違うものとの比較…。

そこに人の感覚による善し悪しは現れない。

2匹のサンマのどちらが長いかは測ることはできる。
しかしここからどちらが美味しいかは測れない。
科学的に測ろうという試みはされているだろう。うまみとかそういう視点かもしれないが、部外者で分からない。

しかし、我々は美味しいか否かは食べれば一発でわかる。
で、もちろん少しでも長いサンマを求める人もいようが、より美味しいサンマに価値を見出す人も多いだろう。

それをわざわざ測るには、そのための意義が必要だ。

繰り返しになるが、ソフトウェア開発において、何個も作り、使ってみて一番良いものを選ぶことは現実には出来ない。
そこに知恵を注ぎ込む必要があり、過去に多くの先人が取り組んできた。

誰もが納得できる答えは未だ無い。

しかし、一昔前ならともかく、現在、沢山の労力をかけたソフトに価値があると考える者は少数派になってきているはずだ。

美味しいソフトウェアを調達できたかどうかは、多くの労力を費やしたものを安く手に入れることであると未だに信じることができるのか。

現代は、1行1行手で書いてきた古き良き時代ではないのである。

2010年4月 9日 (金)

【定量的品質予測のススメ】続編のパブリックコメント募集

「続 定量的品質予測のススメ-定量的品質管理実践ガイド」のパブリックコメントが募集されています。

続編であり、改訂版ではありません。
実践ガイドということです。
ソフトウェアの定量管理の「実践ガイド」とはなかなかハイレベルなネーミングだと思います。

本ブログでは、正式に出版されたバージョンで読み進めていくつもりです。

合わせて、「高信頼性ソフトウェアのための開発手法ガイドブック」という書籍もパブリックコメントが募集されています。

興味がある方はコメントを送られると良いと思います。
共に4月28日〆切です。

http://sec.ipa.go.jp/index.html

2010年4月 6日 (火)

やる気とメトリクス

やる気を引き出すことはソフトウェア開発においても非常に重要である。

工場の流れ作業なら生産性や品質はやる気にそれほど左右されないであろうが、
ソフトウェア開発の場合、やる気がなければいくらでもこれらは低下する。

このやる気の重要性については、多くの人に素直に受け入れられるだろう。

しかし、やる気で大きく生産性・品質は変動するなどとは、メトリクス信奉者は口が裂けても言えない。
さて、メトリクス信奉者はこの問題をどう説明して乗り切ればよいのであろうか。

自身はメトリクス信奉者ではないが、これについて考える事は意義あるとは考えている。
考える方向性は、正攻法としては、
  ・既存のメトリクスがやる気に左右されると考える場合、それをどう抑えるか
  ・やる気に左右されないメトリクスとは何か
の2つがあるのではないかと思われる。

しかし、考えるべきは、やる気に影響を与えるメトリクスとは何かではないだろうか。
発想の転換である。

品質・生産性を含んだソフトウェアメトリクスに関する概念を構築しなおすことは有意義だろう。
そして、今、それが必要なタイミングに来ている。

« 2010年3月 | トップページ | 2010年5月 »