あまりにもありふれた話なので
「またここに書かなければいけないようなことなのか」
と思ってしまいます。
この話から理解出来るように、
システム開発会社には得意とする規模があるのです。
例えば、ある会社がこれまで機能数20で500万円くらいのシステム開発を
行ってきたとしましょう。
（あくまでも仮定なので、この金額から当社の見積もりを想定するのはやめてくださいね。）
この会社が機能数100のシステムを2000万円で請けるとします。
この値段を、
お客様や開発会社の中で「2500万円のシステムの2割引き特価」だと
考える人がいるかもしれません。
しかしこの開発はおそらく失敗します。
20本のシステムの5倍が100本では無いのです。
そして、もっと大事なことがあります。
2000万円以上のシステムを納めた経験が、その会社に何回あるか？ということです。
最大1000万円で機能数40以下のシステムくらいしか経験が無いとすれば、
100機能の仕事をまともに納品出来るかどうか疑わしいものです。
つまり、
(1) 工数は機能数に比例するよりも、ずっと増える
(2) 慣れていない規模の開発は難しい
という2つの高いリスクがあります。
どう考えても成功する確率は低くなってしまうのです。
一方、100の機能の仕事をやったことがあるシステム会社であれば、
10機能の仕事は確実に出来ます。
ただし、一般的に少し高額な見積もりになってしまうのです。
それは、大規模システムで必要となる「万が一」の
リスクへの対処がどうしても入ってしまうからなのです。
システム会社を探す場合は、そのシステム開発の規模に合った会社、
経験あるプロジェクトマネージャーを選びましょう。
決して金額で選ばないように。
そしてシステム開発会社は、このような不景気な時代だからといって、
背伸びをして大きな仕事を安く取ったりしないようにしたいものです。
自分の得意な規模の仕事であれば、特別値引きをしても大丈夫ですがね。
あれがしたい、これがしたい。
でも、予算には限りが・・・ある。
システムエンジニアは、一通りお客さまの要望や現状の悩みを
聞いた上で、どのような提案ができるでしょうか？
まず第一に、一通りお聞きした要望を、すべて実現する提案書を
作ってしまうのでしょうか？
私は、これはちょっと違うと思っています。
実際は、お客さまは「ここが駄目」と指摘してもらいたいのです。
あれもしたい、これもしたいと思っているのは本当ですが、
現実的に技術として、無理があるものです。
コストパフォーマンスが悪すぎる。
運用が難しすぎて、担当者がいない。
時代の流れから見て、すぐ使えなくなる。
といった、プロの眼から見ての、正直な意見を取り入れた
提案が欲しいと思っているのです。
そうやって、プロの眼から見て、無駄なものを取り除いた結果から
1つずつ、自分の優先順位と金額を見て、どこまでやるのかを
決めたいと思っているのです。
だから、お客さまのご要望だから、何でも断らないという
「思考すること」を放棄した、仕事のやり方はいけません。
そして、自分が経営者だったらここまでやる、という物差しを持って
お客様に提案できれば、もっと良いでしょう。
もちろん、ある意味では、それは真実でしょう。
その仕様が、何がなんでもやり遂げたいお客様の要望をかなえる、
唯一の手段だとしたらです。
しかし、指示された通りの難しい仕様に答えを出すことのみに
時間を費やすことがあってはいけません。
プログラマに限らず、SEもそうですが、自分の時間は自分のものではなくて、
お客様が購入してくださった時間であるという認識が必要です。
ときに、難易度は、指示するシステムエンジニアとプログラマの間でも判断が
異なるときがあります。
設計者が「これは、簡単だから」と思って、修正依頼を出すと、
プログラマにとっては、とんでもなく時間がかかってしまう修正であったと
いうことがあるのです。
こうしたことは、設計者がプログラムの作りを理解していないときに起こります。
また、プログラマが未熟で、ちょっとした修正や変更に耐えられない書き方を
しているということもあるでしょう。
さらに、プログラマが設計者の修正依頼の意味を取り違えてしまい、
色々と考えすぎて、必要以上のことをしてしまうこともあります。
そこで、プログラマは、難解な仕様に必要以上に時間を費やすのではなく、
システムエンジニアと十分なコミュニケーションをとって、
「何をやって、何をやらないか」という判断をしていかなくてはなりません。
同じようなことは、お客様と設計者との間でも起こります。
お客様にとっては、軽い一言であった、思いつきであったということが
あるのです。お客様は、そんな修正は、非常に簡単に出来ると思っていた
ということがあるのです。
「上司は思いつきでものを言う。」という本が売れましたが
「お客様は、もっと思いつきでものを言う。」ことも往々にしてあるのです。
もちろん、その一言の中に、深い真実が隠されていることもあるので
ないがしろにはできないのですが。
1つには、これは、思ったより時間がかかるぞ、リスクが高いぞと思えば
お客様に正直に伝えることも必要です。
そして、何故、お客様がそういう発言をされたのか、
本来の意味を理解して、運用を考え直す、などといった、
お客様の立場にたった正しい提案をすることが必要とされるのです。
ときに、お客様の側に開発費用が十分に用意されている場合、
ときに、開発者側の人間がコミュニケーション能力が低い場合、
ときに、開発者側の人間に言われたことをそのまま実現することが
真の「できる技術者だ」と思っている場合（若い人に多いですが）
こうしたとき、たいした意味もなく、お客様に膨大なお金を使わせてしまう、
とんでもない赤字プロジェクトになってしまう、ということがあるのです。
金額は最初に決まっているから、自分だけが余分に働けばいいんだという考えが
技術者に浮かぶことがあります。
しかし、指示された通りの仕様や難しい仕様に答えを出すことに拘泥し、
技術のみに自分の力の100％以上を出し切って納めようとすることが
本当に仕事として正しいでしょうか。
余裕があれば、より深いところまでシステムを検証し、使いやすさや将来性も
提案できたかもしれません。
しかし、ほんの一部である仕様の難解さを追求することに集中しすぎて、
お客様のために最適な結果を出すための貴重な時間を
浪費してしまっていないでしょうか。
ときに「できる」と自分のことを思っている技術者には、
考えてみてもらいたいものだと思うのです。
そのお客様が、冗談半分で
「システムは、正常に動作しているが、周りの人間が
きちんとシステムを稼動しきれていない・・・」
といったような事を、おっしゃっていました。
その言葉は、システム設計・開発を担当したSEにとっては、
とても心に刺さる言葉だと思います。
システム稼動とは、人間がシステムを有効的に利用するために
動作させて、初めて稼動していると言えるのではないでしょうか？
そこで、システムが利用されない理由と
担当SEとしての問題点を改めて推測してみると・・・
1. 単純に使いづらい
システム設計の段階において、各機能を使用する時の目的や状況を
十分に理解して設計しているだろうか？
2. システム上の流れが、実際の業務にあっていない
一般的な業務の流れを、単純にシステム化しているだけではないだろうか？
実際の業務には、様々なケースが存在していて、
一般的なケースというのは、実際はほとんどないのではないか？
実際の業務において、どのようなケースが多く存在しており、
その結果、それぞれの立場の人が、どのような問題を抱えているかを
理解しているだろうか？
3. システムを利用しても、結局、手持ちの資料との二重管理になってしまう
求められている情報、及び、目的を十分に理解して設計しているだろうか？
他にも、様々な理由が存在することでしょう。
重要なことは、システム設計の段階において、利用する側のことを
十分に理解して設計しているかどうかだと思います。
利用する側のことを理解して設計するということは、お客様の言われるままに、
「何でもできます、やります」という意味ではありません。
常に「どうして、そうなのか？、ならば、こうしたほうがいいのでは？」という
衝突の中で、本当の理解が生まれると思います。
これは、相手のお客様には、嫌がられるかもしれません。
しかし、結果的には、本当の意味でのシステム稼動につながると思っています。
私は、お互いの立場は違っていても、ひとつの目的をもってプロジェクトに
参加するからには、そこにいる人達と一緒に作り上げたという
達成感を得たいと思います。
そのためにも、何でもやります！の「ハイハイ型SE」ではなく、
どうしてなのか？こうしたほうがいいのでは？の「ナゼナゼ型SE」で
ありつづけたいと思っています。
何度、何時間、ユーザ竏窒ﾆ開発側が会議を繰り返し
真剣に討議したとしても
そして、どんなに優秀なSEが設計したとしても
納品されてから気づくこと、納品されなければ分からないことが
双方に必ず残るものです。
それを修正したり追加したりするのに
総機能工数の半分もかかるというのでは明らかにおかしい。
しかし、それが10％の工数で追加できるということであれば
むしろ、これは当たり前のこととして準備しておく方が
お互いの為なのです。
当然、経験のあるシステム開発会社であれば
このくらいの工数がかかるといったリスクを想定して見積りをします。
ところが最近では、どんな仕事も
合見積りなど競合相手がいる場合が多いため、
あらかじめその工数を上乗せした見積りが「高く」なってしまって
仕事が取れないということにもなってしまうのです。
もちろん、ユーザーとしてシステム会社から後に追加工数を請求されて
納得がいかないという話がよくありますが、
それは、原価ぎりぎりの見積りであったか
あるいは、どう考えても全くの追加機能であったかのどちらかなのです。
いったん、システム発注をしてしまえば
後からの追加修正を全くしないで使いこなすということは、
むしろ「テーラーメイド」のシステム開発の良さを
享受しないことにも繋がるのです。
「一括納品でいくら」という見積りが出てきた場合
ユーザー側には是非、最低でも総額の10％は
予備費として追加機能予算をとっておくことを勧めます。
もしくは、そういったことまで「あ・うんの呼吸」でやってくれる
システム開発会社と長く付き合うこともひとつの手なのです。
しかし、餅屋を選ぶ責任はユーザーにあるのである。
「何を言っているんだ」
とお思いでしょうか。
このメルマガでは、かなり突っ込んだこともお話していこうと思っているので、
あまり触れたくないところでも入っていかざるをえません。
システム開発をどこかの会社に頼むといったときに、一番良いことは、
その会社のSEを信じて、短期的、長期的な視点からの
アドバイスを受けるということでしょう。
ところが、相手がアドバイスしてくれないとか、
どうもそんなに経験がなさそうだといった場合には、
その親方なり上司に相談できるようなところが望ましいでしょう。
システム開発でも何でもそうだと思いますが、
お客様とSEの間に信頼関係が無いということが、
徹底的に大きな溝を作ってしまうように思います。
初めてのシステム開発でSEへの信頼を持て、と言っても、
おそらく無理でしょう。
だからこそ、前の記事（システム開発を成功させるには その２）で、
初めての場合は小さく始めるということをお勧めしたのです。
そこで、大事なことなのですが、
「信頼を持てそうもない」ということであれば、素直に申し出て、
早めに担当者を変えてもらったほうが良いでしょう。
とにかく、医者でも、建築家でも、SEでも、
お客様と担当の間の相性が一番大切なんだと思うのです。
「何のシステムを作るか」がわかっている場合には
なんと、プログラミングの金額が一番高くなるのです。
だからこそ、プログラマの人件費が安いオフショアが話題になるし
日本国内の開発においても、外国人を使ってOKなのかNGなのか
といったことが言われてしまうのです。
オフショアのお話については別の機会に譲って、今回はプログラミングを
考えた場合に「何が高いか？」を説明します。
内容によっては設計とも関わってくる部分もありますが
まずはプログラミングの視点、つまり、自分がプログラマだったら
高く見積るというところ、そして、市場的に高いと思われているところを
ご紹介します。
▼こうするとプログラム費用は高くなる。
（1）OSやツール、DB（俗にいう開発環境）が「ニッチ」な場合は高くなる。
これは、開発環境、テスト環境を指します。
安く抑えるためには、OSであれば、Winows, Linux, Unix のいずれか
そして、最新のバージョンから2、3バージョン前までのものとします。
Windowsでいえば、Vista, WindowsXP, Windows2000です。
(実際には、まだまだVistaは制限付きとなっているようですが・・・）
言語でいうと、Java, .NET（ドットネット）, PHPくらいがセーフです。
これ以外は、開発者も経験者も限られてしまうため
金額が高くなってしまいます。
需要と供給の関係から、開発者を探すのが難しい場合は高くなるのです。
ニッチな場合には、金額だけでなく「何かあった場合」の問い合わせ先が
限られているので、リスクが伴います。
これに関連して、新システムを組む場合は、「JavaとOracleで作って
ほしい」という要望よりは、「ツールは何でもいいから」の方が
安くなりますね。
（2）納期が短期の場合は高くなる。
開発者がたまたま空いていて、短期でも、通常のシフトで間に合う場合は
例外です。
今月末までに絶対納品というようなタイトなスケジュールを提示され
「社長命令だ」、「これが条件です」など、「絶対」と言われてしまうと
最終的には「金で人を探して」集めるしか方法がなくなってしまうので
高くなるのです。
（3）帳票や画面照会系よりも画面入力系が多い場合は高くなる。
システムから出力するものと、入力するものとのリスクの違い
という意味もあるのですが、一般的に「入力画面」は技術度が高く
難しいことが普通です。
ただし、次の（4）とも関係してきますが、画面の動き、設計については
システム開発会社にお任せして、それで納得できる場合は別となります。
（4）画面の動きにこだわり過ぎると高くなる。
インターネットのGoogleや、ネットショッピングのサイトで見た使い方が
よかったから同じ動きをしてほしい、今まで使っていたパッケージと
同じ動きにしてほしい（今までのシステムはWEBでは無かったにも関わらず）
といった場合には、プログラマの持っている技術資産がそれに対応していない
ことがあります。
プロが行う見積りは、すでに標準的に持っている技術資産で仕事をして
いくらという見積りです。
例外的に、新しく技術を磨いて作成するという時間が含まれていません。
この場合はプロトタイプを作ってもらい、確認、承認して
互いに納得してから着手することをお勧めします。
この確認を曖昧にすると、互いに幸せにはなれません。
開発側も1本目は慎重にゆっくりと作るのが通常ですから、データ更新
（画面で入力したデータを呼び出せるところ）を含めないで
画面の動きだけであれば、プロトタイプを作ることをいとわないはずです。
（5）個々の画面プログラムの繋がりを複数持とうとすると高くなる。
システムにもプログラムにも、セオリというものがあります。
メニューから機能を選んで起動する、機能が終了したらメニューに戻る
といった動きを、通常はセオリ通りの動きとします。
しかし、売上伝票を入力しながら得意先マスタを登録したい、という
複数のプログラムから互いに自由に呼び出せるような仕組みを作ると
設計、そして確認作業、テストも複雑になります。
（6）後から設定を自由に変更できるようにすると高くなる。
例えば、商品マスタを区分けする商品分類を自由に追加、修正する
これは通常の要求です。
しかし、どんなものでも同様にということは、プログラマに負担をかける
ことになります。
例えば、画面に初期表示する対象期間範囲を「1週間前縲恣俣冝vで表示する
という仕様があったとします。
この仕様を、将来的に変更する可能性がある場合（実際にはあるかも
しれない程度です）、このときに後からのプログラム修正料金を恐れて
管理者がいつでも自由にこの期間設定を変更できるようにすると
後からのプログラム修正の方が、よっぽど安かったということもあります。
（7）仕様が不明確で、いつまでも決まらないと高くなる。
例えばの話ですが、誰が運用しているのかわからないような機能が
あったとします。
以前のシステムには、その処理が入っていたので入れておきたい。
しかし、プログラミング設計をする前に、お客様の運用仕様が明確でない。
「後からこの仕様のこの部分については引き継ぎますから
残りの部分だけで動くようにしておいてください」とお客様が営業に頼み
SEも承諾したとします。
プログラマは、実はこういった仕事が一番嫌いなのです。
彼らのモチベーションを高めるためにも、曖昧な部分になるべく早く
決着をつけるようにしてください。
プログラマは、「わからないものがある」ということに大きな不安を
抱くのです。
以上、7つの金額が高くなる条件を書いてみました。
結局は技術者一人一人の意識や技術、そしてチームワークが
大事な仕事です。
彼らがやる気になって、全力を尽くせるような発注の仕方が
よいシステム発注のコツともなるわけです。
プログラマも技術者ですから、「難易度が高い仕事がしたい」
という気持ちがあるのが普通です。
しかし、本当にその意味があるのか
難易度を高くしてまでプログラミングする意味があるのか
ということも彼らは非常に気にしています。
コストパフォーマンスを気にしているのは、実はお客様だけではないのです。
例えば、パッケージをそのまま導入するとしても、
ユーザー側の作業というのは、簡単ではありません。
通常は、システムで使う各種マスタを登録する作業が、
一番先に課せられます。
マスタ登録を画面から行う、もしくは、記入用紙に手書きする、
はたまたExcelシートで作成する、
他のシステムからデータを抜いてきてCSVを作成する。
マスタ登録作業には、こういった作業が考えられます。
データ加工だけであれば、
開発会社に請負ってもらうことも十分に考えられます。
しかし、過去のシステム資産にどんなデータが入っているのか、
また、それは正しいのか、使っていいのか、
といったことを判断できるのは、ユーザー側のシステム管理者、
もしくは現場でそのシステムをお使いの人であるはずです。
マスタ登録作業というのは、雑用でもありませんし、
誰がやっても良い作業ではありません。
非常に重要な作業であると認識して下さい。
これを、新人など、業務が分かっていない人に任せたり、
全営業マンに全部の得意先リストを紙やExcelに書かせて分担したものを
自動で入れてしまったりとすることは、あまり良い方法とはいえません。
（もちろん、誰か業務が分かる人が責任をもって行う分には良いのですが）
たとえ移行作業は自社でやるという決まりになっていたとしても、
開発会社側を引きずり込んで、
「本当に、集めたデータで動くのか」
「お互いにシステムについて思い違いはないのか」
といったことを検証することが大事なのです。
また、そういったデータの収集は、本番の直前や、
尻に火がついてからではなくて、システムのスケジュールが決まった直後に、
設計書が出来るかどうかの段階で、なるべく早く行うべきなのです。
（システム設計書ができあがった場合に印を押しますが、この直前直後です）
というのは、ユーザー側から見て、
「別に重要でないから」
と思って言わなかったことが、システムとしては「超・重要事項」であり、
それを聞いているのと聞いていないのとでは、大違いという場合があるのです。
システムの基本情報の真実を知らずして、
満足のいく設計はできないのです。
以下、非常に私的、個人的意見だと思って聞いてください。
政府系の仕事に関与したときに「おかしい」と思ったことがあります。
それは、
「彼らはマスタ登録を請負い業者に任せて、自分達では登録しない」
ということでした。
確かに、優良企業で大会社の場合はアウトソーシングで、
そういった場合もあります。
しかし、ほとんどの会社が少しでも経費節約のため、
そして、システム構築にも自分たちで参加するために、
マスタ登録は自分達で行っているのです。
他の仕事がどんなに大事であろうとも、国民のために仕事をしている人達が、
自分たちの使うシステムを、金を使って第三者にお任せして良いのかと
思ったのでした。
「厚生年金のシステムが雑であった」
といったニュースを聞いて、本当にその思いが強くなりました。
感情的になってしまいました。
では、思い直して。
「ユーザーはマスタやデータの中身をなるべく早く、
紙でもいいし、元のデータでもよいので、明確にSEに示すべし」
恥ずかしいから見せたくない、後からでいいや、は厳禁なのです。
そして、システムを成功させるために、
基本情報は自分で整備し、チェックしましょう。
もちろん開発側も、アドバイスや、ツール作成など、
できることは協力いたします。
それでも、選択のミス、安物買いの銭失い、思っていた成果が出ない、といったリスクは伴います。
しかし、パッケージを購入し、カスタマイズせずに使用している企業はどのくらいあるのでしょうか。
これは、システムの種類によりけりでしょう。
たとえば、会計システムや、勤怠システム、給与システムは、パッケージを、そのまま使用することが多いシステムです。
また、たとえカスタマイズしたとしても、企業にあわせてプログラムを作る部分は、そう多くないと思われます。
特に、会計システムは、中小企業においては、どちらかというと、税務署へ提出する決算書等作成のためのシステム、といった度合いが大きく、ルールは簡単で一律なので、パッケージそのままで、使用することができるのです。
これまで、大企業（特に歴史のある会社）は、基幹系システム化の歴史において、過去に手作業で行っていた業務を、テーラーメイドのシステムで、システム化してきました。
しかし、ダウンサイジング（懐かしい響きです）が言い出された頃から、なるべく、共通で使える機能はパッケージを採用し、且つ、カスタマイズで独自の業務を作り出そうとしてきたのです。
パッケージありきの商談でも、カスタマイズの重さによって、金額や納期が決まります。
本体価格の、10倍以上になることさえあるのです。
それでも、パッケージはテーラーメイドよりも安いのでしょうか？
実は、そうとは言えません。
パッケージのカスタマイズであれ、何であれ、システム開発は、30機能を超えた辺りから、大プロジェクトになってきます。
人間のコミュニケーションを考えてみてください。
2人の人間が、コミュニケーションをとるのに比べて、5人の人間が、コミュニケーションをとるのには、10倍の力が必要です。
それは、プログラムも同じです。
10機能くらいであれば、少人数のプログラマだけで、短期間で、設計も開発もできるのですが、50機能、100機能となれば、何十人月といった工数が必要になってくるのです。
これは、プログラム間のコミュニケーションの整合性をとるために、大きな力が必要となるからなのです。
加えて、開発以外のマネジメント、人と人のコミュニケーションのための時間も、大幅に増えます。
正直、システム開発に慣れていなかったり、専任の情報システム担当者がいらっしゃらないお客様に、最初から、大きなテーラーメイドのシステム開発をするのはお勧めしません。
同様に、パッケージのカスタマイズも、30以上の機能を変更・追加するということであれば、やはり、お勧めしません。
むしろ、同じ見積金額であれば、パッケージのカスタマイズの方が、テーラーメイドよりもリスクが高くなります。
自宅を作る場合も、何度も作ると、作るコツがわかって、良いものができるというではありませんか。
システム開発も同じです。
小さなものを作ってみて、経験して、初めてわかることがあるのです。
お客様が思うことに、「システム開発会社はプロだから、注文しなくても、かゆい所に手が届くように、教えてくれるはず」というものがあります
確かに、プロフェッショナルとしては理想です。
（わたしもそういう理想のプロのSEになりたいと常々思っています）
しかし、口に出して言わなくても100％理解される、本心を酌んでシステムを作ってくれる、そのような、システム会社を求めるのは、ギャンブルに近いと思います。
《システム開発を成功させる方法》
鉄則 その1．システム開発は小さく始める。機能は30以下。
]]>「アイロベックスは、どんなシステムに特化しているんですか？」とか、「どんな業種に特化しているんですか？」とよく聞かれることがありました。
正直、これは長い間わたし自身にとっては、きつい質問でした。
なぜなら、自分では「販売管理」が一番得意である、と思っていたのですが、販売管理というのはあまりにも包括的、一般的な名前であるようで、かつ、簡単なシステムであると自分で勝手に卑下して考えていたのです。
しかし、よく考えると販売管理をスクラッチで（手組み）作ることを長くやってきたことが、結局は自分のシステム設計の基本になっていることも確かです。
販売管理をスクラッチで作るということは、ちょっと特殊な業種だったり、在庫が複雑であったり、ＢtoＢだけでなく、ＢtoＣであったりと、常に何か例外的な構造、仕組みを求められるシステムを作ってきたということでもあるのです。
このように様々なシステムに携わってくると、各社のビジネスモデル的な部分はともかくとして、設計思想においては、自分なりの設計マインドといったものが確実に育ってきます。
そしてシステム設計をするということは、「業務そのものを設計すること」であり、「運用のやり方」を設計することであると思い至るようになりました。
つまり、システムを設計するには、その企業の業務そのものを、とことん理解して、かつ、その1つ1つの意味や目的さえも聞き込む必要があるわけです。
だからこそ、できれば、その会社内で「一番よく、業務を知っている人」つまり「その仕事が出来る人」になるべく具体的に教えを請いたいと思うのです。
仕事が出来る人であれば「もっとこうしたい」「もっと無駄を失くしたい」「もっと正確な情報を早く取りたい」という思いを必ず持っているはずなのです。
それができれば、SEは、1つ1つの処理の状況や目的をヒアリングしながら、ITを使って出来ること、出来ないことを説明し、適切な運用のアドバイスが出来るというものです。
つまり、業務システムをより良い結果を生むシステムにするためには、企業でその仕事が一番出来る人＝精通している人、その仕事に一番思いがある人の参加が必要なのです。
そういう人は、一番の稼ぎ頭であったり、社長であったりするのかもしれません。
スーパースターの知恵を共有化し、ナレッジ化することがシステムの開発、そして業務改革には常に求められているのです。
するとSEは、様々な企業のスーパースター達と常に接していることになります。
時には、Ａという会社の業務の知恵が、Ｂという会社や他の会社にも共通に使えることも大いにあるわけです。
これが業務システムを設計して開発、納品していく上でのキャリアの強味であり、醍醐味であるともいえるでしょう。
成長している会社というのは、トヨタのカイゼンと同様に、現場が常に意識高く、次のシステムを狙っている会社だということは、しみじみと感じています。
]]>マーケティングを勉強したいと思っている技術者っていますでしょうか？
現在のこんな状況であれば、技術を高めるのも大事ですが、マーケティングを勉強することが、貴方の将来にもっと大きな力を与えてくれると思いますよ。
私が理想とするITコンサルタントに近いですね。
技術だけのITコンサルタントだと、売上管理、粗利管理といったマネジメントに関与できても、突出した新しい価値をもたらすような仕事に関与するのには運を天に任せないといけないでしょう。
でも、技術の上にマーケティングが加わったら、運ではなく自分自身で新しい価値を作りだすこともできるのです。
そんなわけで今週のお勧めは、この「全脳思考」。
450ページという厚さですが、軽々と読めるはずです。
この本を1冊読むことでマーケティングの重要なポイントがほとんど網羅されている。それも分かりやすく説明されているのでお勧めするわけです。
さて、本の宣伝はこのくらいにして、このメルマガはあくまでも「システム開発」についてのメルマガ。
片寄って一部分だけズームインしてみます。
では、本文63ページと64ページから
つまり、クオリティの高い思考には、論理の積み重ねだけでは
説明できない領域があることは、経験上わかっていたのであるが
どうすればその高みにいたれるのかを説明する明確な体系はこれまでなかった。
システム開発のプロジェクトで、詳細設計から全容を理解するのが無理な理由はこれだとわかりました。
で、その解決方法として、神田氏は、こう語っています。
ジグゾーパズルの完成後の全体像を見たあとは、どんな小さなピースにも
全体が見いだせるようになる。
・・・・（略）
つまり、一度、全体像を理解してしまうと、部分には全体を完成させる
強烈なエネルギーが宿りはじめるのである。
プロジェクトを成功に導くコツは、とにかく全体像を理解させること。
まずはこれなんです。
今日のシステムを成功させるポイント
積み重ねで全容を理解するのは難しい。
全容を見せて考え理解させよ。
・他の人よりも、コンピュータに詳しいからという理由でシステム開発の責任者になった人
・細かなところにこだわって、金が掛かってもいいから自分の思い通りにしたいと思っている社長
・やる気に満ち溢れていて、絶対に良いシステムを作るんだという意気込みの担当者
などなど、担当者にやる気、意欲があればあるほど、実際には逆に作用することもあるのです。
それは、どうしてでしょうか？
システム開発においても、あらゆるプロジェクトにおいても、優先順位、最重要事項ということを考えるべきなのです。
ところが、こういった「やる気にあふれた」担当者は、あれも、これもしたい、と考えます。
そして、自分の思いをかけた、ある一部分に執着したりするのです。
これが、ちょうど最重要事項であれば問題ないはずなのですが・・・えてして枝葉の部分であったりするから、余計にまずかったりするのです。
その上、システム開発を請け負う側の担当者が「能力が高く真面目な人間」であったりすると、まずいのです。
作ったら、できてしまうこと。
システム開発の要件というのは、大なり小なり、ほとんどのことがこれなのです。
作ろうと思ったら出来てしまう。
しかしそこには、時間・金・運用する人、という観念が抜けているのです。
本当に動くシステムというのは、
・作る時間も莫大にかからない
・金もそんなにかからない
・運用も楽にできる
というものなのです。
こういう担当者とうまくやって、システム開発を成功に導くためには、人間的信頼関係を築くことが絶対に必要です。
]]>もっとも、ビル建築のような大規模プロジェクトだから、お客さま→親→子→孫といったことが多いのですが、個人の住宅建設であれば、お客様→建設業者といった直接の取引も多いはずです。
IT業界も同様に、小さな規模のシステム開発だったり、お客さま自体が小さな組織の場合には、お客さま→ソフトウエア会社の直接取引になります。
まずは、IT業界では常識と思われている変なことを幾つかお話したいと思います。
１）システムエンジニアとプログラマの違いは？
ひとつの情報システムというのは何十本、何百本のプログラムからなっています。
その設計をするのがシステムエンジニアで、作るのはプログラマです。
通常、プログラマを何年か経験してから、システムエンジニアになることが多いものです。
当然、システムエンジニアの方が単金は高くなるはず・・・
ところが、現在、この呼び名は不明確なものになっています。
よく見かけるお仕事募集で「JAVAのシステムエンジニア」などと呼ぶのが、いい例です。
「JAVA」はプログラム言語ですから、プログラムを作るときに使うものです。
JAVA自体がわからなくても設計は、できるはずですが・・・
また、キャリアが2年や3年ではシステム設計をできるはずもないのですがシステムエンジニア・キャリア2年以上などという募集もあったりします。
15年前位は、当社では「システムエンジニアの肩書きは、最低でも6～7年たたないとつけない。」などと勝手に決めていました。
当社の場合は、1年目は必ず「プログラマ」なので、2年目以降ということになりますが、SE暦1年目でもつけますよ。もちろん。
まずは、名前を貰ってから成長するでもいいのかな？とも思うしね。
結論：プログラマとシステムエンジニアの違いは明確にあるはずだが
実際の呼び名はビミョーである。
２）IT業界の単価はどうやって決まるのか？
SEやプログラマの料金は、一人月（いちにんげつ）といいます。
一人で一ヶ月かかって、納められる仕事量をこう呼びます。
しかしなぜか、一人月は新人とキャリア30年選手とでも変わることはありません。
ではどうやって決まるか？元請け会社のルールで決まるようです。
例えば、こんな風にです。（あくまでも例）
・システムエンジニア 80万円／一人月
・プログラマ 70万円／一人月
たまに、特殊な技術をもった人だと一人月200万とか300万といった話も聞くことはありますが、まだそういう人とお会いしたことはありません。
「質」は、何人のエンジニアの数を足しても、絶対に手に入れることのできないものです。
３）総費用は「機能」で決まるものなの？
ともいえませんね。
当たり前のことですが、工期にもよります。3ヶ月より6ヶ月、6ヶ月より1年のほうが、料金は高くなります。
仕事の機能が半分でも、長い時間（＝拘束期間が長い）かかれば、お金はかかるものなのです。
まったくシステムとは関係ないところで時間を食ってしまうのです。
これが一番まずいことで、ここが分かっていないお客さまが多いですね。
例えば、事前に社内の意思疎通を図ってないまま会議に出てしまう。
社内の勢力争いや責任のたらい回し。ルール決めで、揉めて仕様がまとまらない。
何度も打ち合わせを繰り返したあげく「物理的に時間が足りないなら、納期は延ばしてもいいですよ」
なんて言っていると、必ず料金や質のどこかでリベンジを食うものなんですよ。
束縛されている期間は、半分、他の仕事をうまく入れてというわけには、行きませんからね。
相手を束縛した時間が、そのまま料金にはね返るわけです。
分かっているお客さまは、ここのところをきちんと理解しているものです。
だから、一気呵成にプロジェクトを進めます。
機能にあったスケジュールをたてる。
短すぎもせず、長すぎもしない。これが重要です。
1999年までに、悲惨な航空機事故を繰り返した大韓航空、最悪のエアラインから世界でも優良のエアラインに立ち直った理由それは、「文化的な遺産の重要性」を認めたことからでした。
これに関連してコロンビアの航空会社の恐ろしい事例が紹介されています。
1990年アビアンカ航空の０５２便が墜落しました。
ニューヨークのジョン・F・ケネディ国際空港へ向かっていたアビアンカ航空の０５２便は、悪天候のため３回も航空交通管制に空中待機を命じられていました。
そして予定より1時間15分遅れで着陸許可が下りたとき、燃料切れで墜落したのです。
この事故の原因は、3つあるといいます。
「出発の遅れ」
「オートパイロットの小さな不具合」
「3度にわたる空中待機」
事故機であるボーイング707型機は、古い型式で操縦が難しく飛ばすのに苦労するのです。
さまざまな要因が重なった結果、機長は疲れ果て、決断力が鈍り普段なら気づく何かを見落としてしまった。
その何かとは、「燃料不足になる」ということだったのです。
ケネディ国際空港のすぐ近くで墜落するまで40分も旋回飛行を続けていた間、操縦室の誰もが燃料が残り少ないことを承知していたはずです。
ところが近くのフィラデルフィア国際空港へ着陸することもできたはずなのにしなかったのです。
3度目の空中待機を指示されてはじめて管制官に「別の空港まで飛ぶ燃料がない」と告げているのです。
管制官の返答は「待機せよ」でした。
そのときどうも機長は、自分たちを管制官が他の飛行機よりも優先させて着陸させてくれると考えていたふしさえみられるのです。
しかしそれは、とんでもない誤解でした。
また、乗組員は「燃料がない」ということを再度大声で強く伝えたでしょうか。
いいえ、燃料切れの問題を伝えたのは、さらに38分後のことだったのでした。
ボイスレコーダーからもっと恐ろしいことがわかりました。
機長が副操縦士に「（燃料がない）緊急事態だと伝えろ」と言った指示に対して副操縦士は、どういう連絡を管制塔にしたと思いますか？
他の報告のついでに最後に付け加えて「こちらは燃料がなくなりかけています」と軽く伝えているだけなのです。
それも、何気ない口調だった、声に切迫感がなく管制官にとっては、「ついでの発言だ」としか思えない連絡でした。
これは「緩和された話し方」と呼ばれています。
発言の持つ真の意味合いを控え目に伝えるとか、聞こえやすくしようとする試みを指します。
私たちは、よくこういった話し方をします。
「もし可能でしたら、月曜にいただけるとありがたいのですが・・・」
機長であれば、副操縦士にものを言うときは、彼らは、明確に命令として「月曜までに納品してくれ」といった言い方をします。
しかし、副操縦士は機長に、はっきりと「命令」できるのでしょうか。
答えはNOです。
圧倒的に多数の副操縦士がその立場のせいか「示唆」と言われるもっとも柔らかい表現を選ぶことが調査でわかっています。
だから、恐ろしいことに過去の例をみれば、機長自身が操縦桿を握っているときのほうがはるかに墜落事故は起きやすいのです。
なぜなら機長が間違ったことをしたときに、副操縦士はNOと言えないのです。
人命がかかっているというのに！
ここ15年ほどの間、民間航空業界においては「表現の緩和との戦い」が重要な課題改革になってきたのでした。
アビアンカ航空機事故も、問題はここにあったのです。
ただひとこと、「無理だ。燃料がない」といった強制力をにじませたアナウンスがされればよかったのです。
しかし、管制塔とやりとりをしていたのは副操縦士だった。
権力格差指標という「その国の文化が権威を重んじ権威に敬意を払うかどうか」を示す指標があります。
権力格差が大きな国では、部下であるがために、常に相手に気を使ったものの言い方をしてしまうのです。
だから副操縦士は、部下から上司に対する話し方で管制塔と話してしまったのでした。
管制官は権力格差が小さなアメリカ人であり、彼にとって緩和された話し方は「差し迫った問題がない」という意味でした。
ここに、副操縦士がアメリカ人であれば、燃料がなくても待機している状況に大人しく我慢していなかったのではないかという国の気質の問題があります。
アメリカが権力格差は最もない国であり、コロンビアは権力格差が大きい国だったのです。
ちなみに世界で一番格差が大きな国は、ブラジルであり、2番目が韓国でした。
もうおわかりでしょう。
大韓航空がどんな改革をおこなったのか。
実は、航空英語の熟達を支援したのでした。
英語こそが航空業界の言語だというものでした。
通常、パイロットは自国の「文化的な遺産」の重みに押し付けられた役割から抜け出せない。
そこで、英語を話すことで、まったく別の遺産を持った文化と言語に参加できるきっかけを与えたのです。
優れたパイロットであるというのは本当はどういうことなのか。
文化や歴史や個人を取り巻く世界が、仕事の成功に大きな関係があるととことん理解することが一歩なのかもしれません。
この本の中に、システム開発と関連付けると非常に興味深い章があります。
それは、第7章「航空機事故の"民族的法則"」です。
ここには、恐るべき大韓航空の歴史が載っています。
1988年から1999年における、アメリカ・ユナイテッド航空のフライト100万回あたりの"機体損失"率は0.27
一方、大韓航空の損失率は4.79 ユナイテッド航空の実に17倍以上の機体が落ちている計算になります。
確かに、10年以上昔には「命が惜しければ大韓航空には乗らない」といったことが秘かに言われていました。
そして1999年、当時の金大中大統領は率直にこれを認めました。
「大韓航空の問題は一企業の問題ではなく、韓国全体の問題である」
そして、大統領専用機を大韓航空からアシアナ航空に変えたのです。
ところがその後、大韓航空は自らの「立て直し」に成功したのです。
1999年以降、彼らの安全記録には非の打ちどころがありません。
大韓航空が最悪のエアラインから世界でも優良のエアラインへ変貌したのは、同社が「文化的な遺産の重要性」を認めたからだったのです。
大惨事はなぜ起こるのか？
それは、小さなトラブルと些細なエラー要因の蓄積の結果なのです。
墜落の典型的な原因は悪天候、しかも過酷である必要はなく、パイロットが通常よりストレスを感じる程度の天気なのです。
圧倒的に多い原因は出発が遅れ、パイロットが焦っているときであり、墜落事故の52％が機長が目を覚まして12時間以上経過したとき、つまり、機長が疲れを感じ、判断力が鈍ってくるときなのです。
さらに、墜落事故の44％が機長と副操縦士が初めての顔合わせのときに起きているのです。
そしてエラーが生じる。しかもひとつにとどまらなく人為的ミスが7つ続く。
7つのエラーが大惨事を招くのです。
ついつい、ヒヤリハットが300続くと29の軽傷事故があり大事故1つに繋がるというハインリッヒの法則を思い出してしまいました。
しかも、この7つのエラーは、知識や飛行技術の問題ではないというのです。
難しい操縦技術を求められて失敗したわけではないのです。
この本には、大韓航空の事例だけでなく、コロンビアの航空会社であるアビアンカ航空の有名な墜落事故について恐ろしい物語をかたっています。
では、どんな理由で航空機は墜落するのか？そして、大韓航空はどうやって立ち直ったのか、気になる人は自分で本を購入されるのもお勧めですよ。
]]>