[みんなの回答]IT業界人は自分のドッグフードを食べよ

公開日時：: 2007/11/08 02:04
著者：: 吉澤準特

トラックバック(0)

コメント(4)

ブックマーク(-)

インフラコンサルティングの最前線著者：吉澤準特
『IT業界を不人気にした重鎮たちの大罪』への返信

「IT業界を不人気にした重鎮の大罪」というエントリーのコメントで、この業界を取り巻く人々の姿勢についても反省を促したいと書いていましたが、もう少し具体的に述べます。

自分のドッグフードを食べる

SIerや各ベンダーは自社のソリューションや製品を持っているところが多いですが、本来クライアントやカスタマーに提供するサービスを使って自社の業務効率化や改善を図ることを指す言葉です。

元々はWindows NTを開発していたマイクロソフトが、テストを兼ねて自社のシステムに開発バージョンを導入した際、「自分のドッグフードを食べる」と表現したことから使われるようになりました。

最近では、ノキアのCIOがこの言葉を踏まえて、より高品質な自社ソリューションを自分達に適用するということを、「自分のフォアグラを食べる」などと表現していましたね。
（参考：自分のフォアグラを食べよう）
→ http://it-ura.seesaa.net/article/65008865.html

このドッグフードを食べるということについて、2003年のCNETの記事で、ちょうどマイクロソフト社の当時CIOが次のように答えています。

『--「ドッグフード」というコンセプトはどこから生まれたのですか。

「自分たちの製品のリリース前に、研究所ではできない、より実際的なテストを行うことで、製品がどのように機能するのかを知っておきたいという思いが原点となっています。」』
http://it-ura.seesaa.net/article/65010621.html
　

この精神を持ってSIを行っているベンダーがどれほどいるでしょうか。

例えば、サーバソリューションを売りにしているベンダーもしくはSIerなら、自社のシステムの根幹をその技術で賄っていなければダメです。プロジェクト管理を得意分野にしているのコンサルは、もちろん自社内のプロジェクトも同様に管理を行っていることが望まれます。

「自社ではないが他社事例が豊富にあるから大丈夫」

そんなことを呟くベンダーはこの本質をまったく理解していません。大切なのは、どれだけ自分自身が痛みを知っているかという点です。自分自身で痛みを知ることは、その痛みを経験しないためにはどうすればいいかを真剣に考えることにつながります。その結果、クライアントを実験台にすることもなくなり、失敗や炎上するプロジェクトを減らすことにもなるでしょう。相手に対する強いコミットメントを約束しない限り、他社事例がいくら豊富にあろうとも、所詮は他人事に過ぎないのです。

あなたがクライアントにとって真に信頼できる戦略的パートナーとなるためには、クライアントの利益を第一に考えることが必要です。

スティーブンRコビーは著書「7つの習慣」の中で、win-winの関係を築く重要性を説いていますが、Dependency（依存関係）から脱却し、Inter-Dependency（互恵的相互依存関係）を目指すことを強調してます。

いつまでも相手を実験台にするようなやり方では、そのような関係は永遠に望めません。中長期の視点では、むしろマイナスに働くでしょう。

もちろんこれはSIerだけに向けて述べているわけではなりません。クライアントにしても同じようにSIerとの戦略的パートナー関係を築くよう努力することが必要です。「SIerを生かさず殺さず使い倒そう」などと考えているようでは、優秀なSIerはどんどん離れていくでしょう。

最後にIT業界に属している皆さんに伺います。

　　　「あなたは誰のために業務を行っていますか？」

※このエントリは CNET Japan ブロガーにより投稿されたものです。シーネットネットワークスジャパンおよび CNET Japan 編集部の見解・意向を示すものではありません。

ログインしてコメントするこのエントリを評価する

運営事務局に問題を報告

このエントリーへのコメント

　そういえば思い返してみると

確かに
　・顧客さんにデバックさせるというのは変
　・顧客さんに(ライブラリ等)使い方、
　　業務応用例を試行錯誤してもらう

というのは凄くおかしい話だと
以前から思っておりました。

　いくら体験版等を配っていたとしても
　　A)使い勝手が悪い点が凄く気になった
　　B)サポートが遅い(悪い)

　　とわかった時点で
　　　購入検討を止めてしまう
　　と思うし

　★「動かしていると落ちる」
　等でない限りは普通悪いところを
　教えていただけないのが普通だと思います。

　　テストは大切ですね＜汗
　工数とのバータになりますが・・・。

===================================================
　受注案件にしても、
　　短納期・低価格
　になってきたので

　受ける側としては
　　「テスト工数を減らしたい」
　　「納期を何とか延長したい
　　　＜2次フェイズ等にずらしたい」
　と考えたいところなんですが

　発注する側もそれを見越して
　　「遅延にたいする損害賠償契約」
　　　　とか
　　「バグ等を発見したら即時直す」
　　「バグXX件で発注費を10-20%減額する」

　等の条件を突きつけてきてはいるので
　どうしても体力ベースの話になってしまうのは
　痛いところです。
　＜徹夜して開発部全員で連日テスト等

きむこう on 2007/11/11

　吉澤さんはじめまして

　この記事を読んでいてとても感動しました。
　
　Unix系に比べていろいろと文句いわれる企業ですが
やることはちゃんとやっているのだなーと。

=============================================================
　自分は以前某アプリケーションを作成している会社で
お仕事させていただいておりましたが

　営業さんの中で一人だけ
　　業務に使われている方がおりまして、(他の社員は使っていない)
　　顧客さんから上がってくる操作周りの苦情等もあわせて
　　いろいろと使い勝手の悪さ等を
　改善要望資料にまとめてくれていたのですが

「GUIの問題で、計算処理等をしている計算ライブラリ(dll)の問題
　ではないので対応はしない＜顧客要望でも黙殺」

「わが社は計算ライブラリの会社なので
　GUIは後々オープンソースにするので、
　メンテ要員にお金をかけたくない＜安い外人の外注さん一人ぐらいで十分」
　　　　　↑
　　　　オープンソースにするとGUIの開発工数が殆どかからなくなる
　　　　と経営陣が考えているようでした＜なんか変

　そこで仕事していた時は
どうもモチベーションがあがらなかったのが正直なところ。
そんな感じなので開発の人の入替わりも激しかったのも事実です。
(中小の会社なので仕方ないのかもしれませんが・・・)
=============================================================

　社内で使うにしても

　経営者や開発者に
「よりよい製品を顧客に提供しよう」
という精神がないと
なかなか実を結ばない気がします。
MSはいい会社です。

きむこう on 2007/11/11

坂本さん、コメントありがとうございます。

ミッションクリティカルなソリューションを完全に自社内のシステムで用いることはできませんが、それを作るための方法論やフレームワークの一部を適用することはできるのかな、と思ってます。完全にクライアントに特化したソリューションであれば、それはクライアントと同意した上で取り組む、場合によっては共同開発というスタイルを取るのが適切なアプローチなんじゃないでしょうか。

にも関わらず、さも経験豊富であるかのように振舞いながら、実はまったく初めてのチャレンジだったというベンダーは残念ながらいます。目先の利益を追うばかりに、中長期的に戦略的なパートナーとしてクライアントに食い込んでいく道を捨てているように思えるベンダーさんを私の周りでよく見かけるので、このようなエントリーを書いてみました。

吉澤準特 on 2007/11/10

吉澤さん、SIerで自社ドッグフードは、あんまりミッションクリティカルなところをやる余地がないと思いますよ、って思っていたら、今、自社で作った開発言語（3GL) で某巨大金融システムを構築したのを思い出しました。開発言語を作る部署と、金融システムの私の部署は別なのですが、お客様に入れるものですから、それなりに仕上がったものを使ってました。
ただ、金融システムをSI会社で使うわけにもいかず、電力とか向けのGISソフトでLANケーブル管理するのも、近所に買い物に行くのにF1カーを使うようなもので意味がないし、自分自身が痛みを知るのは難しいかもです。

坂本多聞 on 2007/11/08