« 発信型思考整理ツールとしてのtumblr、twitter | メイン | 「骨」展 »

がんばってるけど顧客のためになってる?と悩むあなたへ

 固い話で恐縮ですが、「現場でがんばってんのに、なんか顧客のためになってなくね?」とお悩みのあなたは読んでみてください。


 システム開発業界(いわゆるSI業界)の状況は決して暗いものではありません。不況とはいいますが、その半面で「ITを活用して復活だ」というノリも聞くようになってきました。システム開発のニーズは中期的にみて縮小しないでしょう。

 ただし、求められる質は変化しています。顧客にしてみれば、ビジネス環境(市場環境、消費者動向、買収合併、グローバルの地政学など)の変化が激しい。そのためITも変化を受け入れて適応していく必要があります。つまり、"持続的な発展をしつつ、短期的な変化を許容する"ような質的変化をしていくべきなのです。テーマとしては、プロジェクトの短期化、接続性の高い技術の採用、全体視点でのテクノロジーマネジメントなどでしょうか。


 ところが、実態はこれとは大きく乖離していると感じています。プロジェクトの開始から終了まで長々とかかり、いざ出来上がっても赤字、あるいは"動かない/使えない"。これには書ききれほど様々な背景があります。

・終身雇用制度を前提に顧客側でエンジニアを抱えられないため全体視点での技術力がない。ただしプロジェクト増減にともなう人的リソースの調整をSIerが担保しているという面もある

・マルチベンダー体制になることが多く、ベンダー間調整ができずにシステム間連携が非効率になりがち。逆に単一だと価格競争力が働かないので、それはそれで危険

・内部統制やプロジェクト管理など、監査やリスク管理が重視されており、重厚長大なレビュープロセスや意思決定プロセスにより遅延が発生する。ただ、なくて良いわけではない。

・プロジェクト管理精度向上のために技術進歩の抑制を行う必要がある(いわゆる標準フレームワーク)。一方、先端的な技術を取り入れようにもROI的な説明責任が果たせないし、教育コストを掛けられないため対応できる人的リソースを集めきれない。

・開発で赤字であっても保守運用やハードウェアで回収するビジネスモデルが成立している(顧客企業側PMも責任回避にその方が都合が良いということもある)

・請負受託契約モデルを前提にした"定義" "調整"主体のマネジメントスタイルになる

・コストにインパクトがある製品/技術の選択権が顧客側にあり、エンジニア側にない

・著作権が基本的には顧客側に帰属してしまい、開発側での積極的な使い回しなどを含めた効率化(規模の経済性)のビジネス的なスキームが作りにくい

・そもそも、日本のマネジメントは非常に近視眼的。目に見える範囲の効率化に注力してしまう。これは顧客側も開発側も同じ。

・エンジニアの性格。1つに決めたがる。1つの手法/技術に固執する

・システム開発産業の未成熟さから、ノウハウが蓄積されておらず見積もり精度が甘い、工法が安定していないといった問題がある。当然、見積もり根拠を定型的に出すことなんてできない。


 これらが個別に悪いとか悪くないというのは簡単に言えないし、ある面で最適化されてきたところもあるので否定はしません。しかし、結果的には「現場の意識が、そのプロジェクトの成功だけに行き過ぎてしまう」という構造的な特徴を持っていると考えています。つまり、現状では"長期的に顧客側と開発側が健全な関係を保ちつつ、互いに発展していく"ということがやりにくい構造になっているのです。

 このような状態でプロジェクトを自転車操業をしていたら、顧客側も開発側も疲弊してしまいます。顧客の強引で残酷な要求に従って泣く開発か、開発に巧妙にぼったくられて会社の魅力を失っていく顧客。そんなことではシステム開発業界のみならず、すべての産業が脆弱になっていきます。

 単に現場がダメだと言うことでもありません。現場はがんばっているんです。非常に。PMが技術抑制するのも、エンジニアが新しい技術を採用したがるのも個々の視点では間違っていません。しかし、残念ながら近視眼的になっていると言えるでしょう。
 

 では、どうすれば現場が頑張った上で"長期的に顧客側と開発側が健全な関係を保ちつつ、互いに発展していく"ことが可能になるのでしょうか?

 答えを定型化するのは非常に難しいでしょう。状況によって答えは違う。おそらく一段階上のメタ的な思考によって"全体視点と個別視点のバランス"を取ることが必要です。個別のプラクティスや手法は大事ですが、それを「どうやって使うのか」が重要です。


 僕も30歳ぐらいまでは"個人のサバイブ重要"、"フリーランスかっけー"、"コードが王様"とか思ってましたが、経営に近いところをやり、知見を広げて振り返ると「あれ、そもそも土台が緩んでね?」という危機感を持つに至りました。

 個人のQoLも、モチベーションも、生き方も大事です。が、上記の問題は個人がどう生き抜くかではなくて、その個人が立つべき基盤をどうするか、ということです。トヨタ生産方式は優れていますが、いくら効率あげても、仕事がなくなってしまえば意味がありません。エンジニアは仕事の上に生きているんです。良い仕事がなければ、良いエンジニアにはなれません。


 とまぁ、難しく書いてきましたが、ようはみんながwin-winになれるようにがんばるってことで、それを見事にえがいているのがid:yuripopの「案件管理のお仕事」というエントリ。ここで書いていることは「要件定義」なんてもんじゃなくて「開発のお仕事を作る。しかも、なるべくみんながwin-winになるように」ということです。奥が深くて当たり前。でも、それがあるからみんながプログラミングできる。僕からすれば、こんなに素敵な考えを持った人がコアにいれば、それだけでみんなのパフォーマンスが上がると思うよ。顧客にとっても開発者にとっても、パートナーとしてふるまっている。もちろん失敗も反省もあるんだろうけど、ぜひ、頑張ってほしい。


 僕らはもっと「真面目にちゃんと」システム開発をしていくべきです。できるとも思います。ぜひ、多くの方と意見を交換したいと思っています。メールでも、メッセージも、くださいませ。なんか、どこかでそういう会でもしたいなぁと。

トラックバック

このエントリーのトラックバックURL:
http://www.arclamp.jp/mt33/mt-tracback.cgi/2666

コメント (2)

mark-wada:

mark-wadaと申します。いつも有用な記事を拝見して、勉強しています。私は今業務システム構築の方法論と実装技術を研究していますので、今回の記事に大変興味を持ちました。

ここ15~20年IT技術・サービスあるいはインフラは急激な変化をとげていますが、業務システムの作り方は全然変わっていません。

ビジネス側でもその環境も劇的に変化して、それへの対応の迅速性を求められています。経営者はできれば、それをITを活用してやりたいと思っています。ところが、ITがそれに答えられていないため、経営とITが乖離したままというのが、日本のIT業界の大きな問題であると思っています。

それを打破しないと、日本の企業の競争力の足を引っ張り続けることになります。ところが、一部の先進ユーザを除いて、依然として従来の「システム開発」の延長でしかものを考えていないため、いっこうに経営や事業に貢献できていません。

ですから一旦ゼロベースで考え直す新たな発想をしていかないといけないと思っています。

そのとき、重要なことは「ビジネス視点・ユーザ目線」ではないでしょうか。業務システムは、あくまでビジネスがあって、それを生かすにはということで成立しています。

ですから、そのビジネスが起点となるシステム構築を急がねばなりません。そういう意味では、「要件定義」の前に「要求定義」がより重要であると考えています。

こうしたことについて、ぜひ議論をしていただけるとありがたいと思っています。よろしくお願いいたします。

mark-wadaさん、コメントありがとうございます。
"ビジネス視点・ユーザ目線"は、確かに重要ですね。要求定義や要件定義を含め、幅広い部分での議論が必要と考えています。
これからも、よろしくお願いします。

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2009年06月15日 01:20に投稿されたエントリーのページです。

ひとつ前の投稿は「発信型思考整理ツールとしてのtumblr、twitter」です。

次の投稿は「「骨」展」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Creative Commons License
このブログは、次のライセンスで保護されています。 クリエイティブ・コモンズ・ライセンス.
Powered by
Movable Type