update it, Inc.社長のブログ

会社の目の前を流れる「滝」です。ジャングルクルーズではありません。

昨日の「私の履歴書」の中で、「私の持論は、システム開発会社は製造業ではなく、サービス業であるべきだと考えています」と述べました。今日はこの意図するところを述べたいと思います。

普通に考えればシステム開発会社は製造業っぽいと思います。ちなみにウィキペディアによれば、製造業とは「原材料などを加工することによって製品を生産・提供する産業で、鉱業・建設業とともに第二次産業を構成する一大分野である」だそうです。大規模なシステム開発を行うSI会社の人達が少し自嘲気味に、「うちの仕事はゼネコンと同じだ」というのを聞くことがありますが、もしやっていることが建設業と似ているとすると、それはやはり製造業なのかもしれません。

一方のサービス業とは、同じくウィキペディアによると「サービスを取り扱う産業」で、そのサービスとは「取引の対象となりうる無形の商品のこと。役務(えきむ)。相手方の時間および手間を肩代わりする概念」となっています。また第三次産業と同義と捉える場合もあり、その定義によると情報通信業などの情報や知識を取り扱う産業もサービス業として扱われています。

ただ私が「システム開発会社は製造業ではなく、サービス業であるべき」という言い方をしているのは厳密な定義の話をしているのではなく、どうあるべきか、というか目指すべき方向性の話をしたいのです。ですので、ここから先は製造業のイメージとサービス業のイメージの対比として話を聞いてください。（ちょっと説得力がないですね。）

まず最初に言いたいのは顧客との距離です。サービス業といった場合、一般に思い浮かべるイメージとして、目の前に、もしくは関係の近い場所に顧客がいると思います。一方の製造業は製品を出荷するまでで、そこから先の顧客まではかなり距離があるのではないでしょうか？　以前のブログ「メニューと値段」で書いた「プレミアム」を得たいならば、この顧客との距離の関係で捉えた場合、製造業よりはサービス業を目指すべきではないか、ということが１つ言えます。

もうひとつは、サービスの定義にある「相手方の時間および手間を肩代わりする概念」というのが、まさにシステムが実現しようとしていることで、システム開発会社は、装置としてのシステムを１から作り上げて提供するという商売から、徐々にシステムによるサービスを提供する商売に移行すべきなのではないか、ということです。

奇しくもSOA（サービス指向アーキテクチャ）という言葉があります。この言葉の本来目指すべきところは、まさにこの「システムによるサービスを提供」するということに尽きるのではないのでしょうか？

なぜ毎回０からシステムを作り上げなければならないのか。それを不思議に思うことから、私は「システム開発会社は製造業ではなく、サービス業であるべき」と考えている、という次第です。

会社ではシエスタを推奨しています。

眠いときにはちょっと寝て、しゃきっと集中して仕事をしたほうが全体の効率はよっぽど高くなるはずだ、と思っております。（はてはの近藤社長の真似でもありますけどね。）

今月の日本経済新聞朝刊の「私の履歴書」はセブン＆アイ・ホールディングス会長の鈴木敏文さんです。私は日経新聞をこの「私の履歴書」を読むために取っているといってもいい程、毎朝この欄を楽しみにしているのですが、今月の鈴木敏文さんの「履歴書」は待ってました！と言いたくなる程うれしい企画です。少なくとも私はコピーをとって永久保存版にします。

最近「見える化」流行りでシステム開発にトヨタ流を導入するという話を良く聞きますが、私はシステム開発会社が見習うべきなのはむしろセブン・イレブンではないかと考えています。もちろんトヨタ流を否定するわけではありません。システム開発を製造業だと捉えるとトヨタ流に学ぶべき点が多いのは事実です。一方セブン・イレブンはコンシューマ向けのサービス業なので、B to Bの形態の多いシステム開発会社の人にセブン・イレブンといっても？という反応をされてしまうのが落ちです。しかし私の持論は、システム開発会社は製造業ではなく、サービス業であるべきだと考えています。もしそうだとすれば、サービス業の１つの頂点の形態として、セブン・イレブンに学ぶべき点は非常に多いのではないでしょうか？

セブン・イレブンの収益性は他のコンビニエンスストアと比較して群を抜いています。同じようなことをしているのに、また同じような人たちがやっているのに、なぜセブン・イレブンだけがこんなに強いのか。その強さのわけは最初に紹介した鈴木敏文さん流のセブン・イレブンの文化にあるといえます。

勝見 明著の本『鈴木敏文の「本当のようなウソを見抜く」』（プレジデント社）では、このセブン・イレブンの文化として、例えばパートやアルバイトまで巻き込んだ、シンプルなプロセス「仮説・検証」を一貫して実践している、とか、顧客の立場に立ってものを考える（顧客の心理を読む）とか、常識を鵜呑みにしないなどといったことが紹介されています。これと連動する形で徹底した単品管理、商品の売れ行き予測、徹底したフランチャイズの教育などが行われています。こういったことをまとめて統計学と心理学をベースにした経営と紹介されるようです。

単純にシステム開発の立場で見てみるとぜんぜん別世界の話のように思えるかもしれませんが、顧客のニーズ、心理を捉え、如何に顧客ロイヤリティーを得るか、また仮説・検証などといった文化を如何に末端まで浸透させるかという観点で考えた場合、重要な示唆がたくさん含まれていると思えるのです。

具体的な内容についてはまた後日ということで。

会社の前から駅のほうに向かってとった写真です。

三角形の屋根の辺りから階段を降りたところに駅があります。先日ちょうどそのあたりで「深キョン」がドラマを撮っていました。

プロジェクトを確実に破綻させる方法としてご紹介する３つ目は、「曖昧プロセス」です。システム開発の開発プロセスが定義されているというのはすばらしいことなのですが、きちんと運用されていない場合にはかえって弊害になるという話です。

最近ではユーザ企業側でも自社の開発プロセスがきちんと定義されているところが多いです。これ自体は悪いことではありません。そしてシステムを開発する人・チームが常に同じであれば、長年の付き合いの中でそれらのプロセスは自然に理解され、伝承されていくでしょう。しかし、人は入れ替わるものです。またパートナー会社が変わるということもあります。

問題はそうしたときにドキュメントに書かれた開発プロセスに具体性が無く、実際の運用においてどうすべきかが曖昧な場合に発生します。ドキュメントにはいいことが一杯書いてあるんです。でもじゃあ、このときには何をどうしなければならないのか、っていう具体的な進め方が曖昧だと、プロセスについての議論が沸騰して、実際のプロジェクトが進まなくなる、なんていう馬鹿馬鹿しい経験をした人って多くありませんか？

ある意味、プロジェクト推進者が「ものがわかる人」ならば柔軟な対応で問題にはならないのですが、逆に厳密さを追求するタイプの人だと最悪です。

そもそもユーザ会社の開発プロセスって、せいぜい１つか２つのタイプしか定義されていないことが多く、その中でさまざまなタイプの開発を網羅しようとしているので、プロジェクトの種類によっては意味を成さないような項目が並んでいることが多いと思うのです。でもそのような場合にどれは行ってどれは行わないっていうことが曖昧だと、開発者側がそれに右往左往される。先に述べた「伝承された」人達にはここのあたりのことは自明だと思い込んでいるのですが、それがさらに曖昧さの入り込む原因になっているのです。

盛り込みすぎたプロセスも曖昧になりやすいです。プロセス定義書だけで厚さ？センチなんてものは、おそらく運用不可能です。で、結局これはやる、これはやらないなんてことが現場で判断せざるを得ない。ところがこの判断のやり方に明確な基準が示されていないと、人によってやったり、やらなかったり、となるわけです。この状態で先に述べた、厳密さを追求するタイプのプロジェクト推進者がいたりすると、開発プロセスを守るためだけの作業に時間を食われ、プロジェクトは確実に破綻します。

本来開発プロセスはプロジェクトをうまくまわすためのツールであって、それ以上のものではないはずです。目的と手段を取り違えないよう気をつけていれば、この手の問題は起こらないはずなのですが、みなさんのところはどうでしょうか？

もう葉桜です。早すぎませんか？

システムのメニュー化大作戦第３弾です。昨日は作業と仕事という観点からメニュー化はシステム開発を作業から仕事へと変化させるという話をしました。今日はメニューと値段について、です。

あなたが外食に出かけたとします。店にはいろいろあって、サービスのいい店、味のおいしい店、価格の安い店、などさまざまです。そして提供する値段もそれぞれです。選ぶ側は徹底して安い店指向の人もいますし、高くてもおいしい、サービスの良い店にこだわる人もいます。

この例では個人の嗜好が入るので、ビジネス上の選択とは必ずしも一致しない点がありますが、とはいえ、ビジネスの世界も必ずしも安いだけがすべてではないはずです。システムを開発する会社にも業務ノウハウを持ち合わせたシステム会社とか、優れた開発プロセスを確立しているシステム会社とか、いろいろ選択枝があります。特に大規模なものや複雑なもの、対応する業務が難しいものなどについては、目的のシステムについてかなりのノウハウがないと開発に失敗する可能性が高くなります。

つまりそういったノウハウを有する会社は当然、契約代金は高くなってしかるべきなわけです。これは原価（システム開発の場合はほとんどが人件費）が多少高いのはありますが、それ以上にプレミアム（上乗せ価格）が付いても買う側が必要ならば払うわけです。

ところが作業ベース、つまり人月計算でシステム開発を行う場合にはこういったプレミアムを載せる余地はあまりありません。ですので受ける側も大して努力しようとしない。しかしメニューで提示するやり方の場合は提示する側に自信があればメニュー価格にプレミアムを載せることが可能です。つまり会社として一杯努力して、すばらしいノウハウを有することができた会社は、プレミアムの恩恵にあずかれるようになる、というわけです。

つまり高いメニュー価格を提示する会社というのは、それなりの自信の表れである、ということになります。もし中身が伴わない会社が高いメニュー価格を提示すればそもそも受注できないですし、すぐに淘汰されていくことになると考えられます。

春ですね。駅から会社まで約１分なのですが、その間の畑で菜の花が咲いています。

社員の一人は花粉症で今日は仕事にならん、とぼやいています。

人から聞いた話ですが、その人の昔の上司に「おまえが今やっているのは作業？　それとも仕事？」という質問をする人がいたそうです。作業とは、いずれ自動化されるようなもの、仕事はクリエイティブで付加価値を生み出すもの、という意味で、お金をもらってするのであれば、作業ではなく仕事をしなさい、という意味だそうです。（言い換えれば作業をしているのであればそんなに金を払わないよ、という厳しい指摘ですね）

確かに仕事ってこの２面性を持っているのだと思います。

さて、昨日書いたブログ人月の神話において、今までの日本のシステム会社は人月で金を払っている、これからはメニューを用意し、メニュー毎に値段を決めるように改めてゆくべきだ、という提案を書きましたが、上記の作業と仕事という観点で考えると、今までの日本の会社は「作業」に対してお金を払ってきた、ということになります。効率が良くても悪くても、かかった時間に対して金を払う。やっていることを作業とみなしているわけです。

もちろん今までのやり方でも係数という形で上記の効率をお金に換算してきました。プログラマー（もしくはSE）のランクってやつです。SE、PL、PG…　などといった形で人に値段（単価）を付けています。でも実際このランクってやつはほとんど経験年数で決まっているのがほとんどで、実際の能力を正しく表しているとは言いがたいのではないでしょうか？

もしこれをメニュー毎の値段という形に改めることができれば、本来PGランクの経験年数しかない人達だけのチームでも、会社で仕組みを整え、品質の高いものをタイムリーに提供できれば、高い粗利を得ることが可能になります。逆に約束したものがうまく仕上げられない場合にはリスクを負う。これが「仕事」に対してお金を払う、ということですよね。

ただ、メニューに高い値段を載せるためには、それに相応の内容なんだってことをお客様にわかりやすく提示しなければなりません。ということで、この話はまた後日。