アイロベックスメールマガジン　携帯版

6月21日夜、「100万人のキャンドルナイト」が全国で行われました。
http://www.candle-night.org/m/

当日の夜は、各地で行われているイベントの中継やアーティストによるエコミュージックのライブをテレビで放送しており静かに盛り上がっていました。

でも、エコって非常に難しいですよね。私の周りにはこんなことを言う人も。

「エコバッグは確かにビニール袋の削減になるけど、エコバッグを大量に作っていたら、むしろ無駄になるんじゃない？」

エネルギーの使用量からエコかどうかを判断しようとすると、非常に複雑な要因が絡み合っているように思います。

それはさておき、このキャンドルナイトで重要なのは「はっきりと目に見える」ことです。

もちろん、電気を消してろうそくを一斉にともすという行為がロマンチックであることは重要です。

しかし、ロマンチックであることよりも、一斉にみんながイベントに参加していることが眼でわかることが、もっと重要なことなのです。

こんな逸話があります。

ある塗料メーカーが、ゴキブリの寄らない塗料を開発しました。

塗るだけで効果が得られるわけですから、すごい発明です！

ところが、これに優る商品があったのです。

みなさんご存知でしょう。「ごきぶりホイホイ」です。

ゴキブリが寄らない塗料は画期的な発明でしたが、残念ながら売上では「ごきぶりホイホイ」に圧倒的差をつけて負けました。

「ごきぶりホイホイ」が選ばれた理由は、もちろん効果が目に見えてわかることですよね。

粘着テープにヤツらが捕まっているのが見えますから。

塗料では、実際の効果はもっとあるのかもしれません。

しかし、皮肉なことにそれでは本当に効果があったのかわかりづらいわけです。

つまり、「100万人のキャンドルナイト」も「ゴキブリホイホイ」も人々の心をつかんだ理由は同じというわけです。

人の気持ちを動かすためには、「実際の効果」よりも「目に見える効果」がポイントであるということですね。

というわけで、バグの撲滅が一目でわかるバグ管理のフリーソフト「bug-zero」無料配布中です。システム開発に是非、ご利用ください。

http://www.ilovex.co.jp/info/freesoft/kenshu.html（PCサイト）

さて、無理やりこじつけしたような話とお考えだったでしょうか。

今回は、杉山ではなく、わたくし若輩２ｘ歳の黒木がお届けしました。

続きを読む "キャンドルナイトとゴキブリの関係" »

経営コンサルタントとしてあまりにも有名な神田昌典氏が新刊を出しました。

「全脳思考」ダイヤモンド社刊です。
http://www.amazon.co.jp/exec/obidos/ASIN/4478008361/ilovex-22/ref=nosim/

マーケティングを勉強したいと思っている技術者っていますでしょうか？

現在のこんな状況であれば、技術を高めるのも大事ですが、マーケティングを勉強することが、貴方の将来にもっと大きな力を与えてくれると思いますよ。

私が理想とするITコンサルタントに近いですね。

技術だけのITコンサルタントだと、売上管理、粗利管理といったマネジメントに関与できても、突出した新しい価値をもたらすような仕事に関与するのには運を天に任せないといけないでしょう。

でも、技術の上にマーケティングが加わったら、運ではなく自分自身で新しい価値を作りだすこともできるのです。

そんなわけで今週のお勧めは、この「全脳思考」。

450ページという厚さですが、軽々と読めるはずです。

この本を1冊読むことでマーケティングの重要なポイントがほとんど網羅されている。それも分かりやすく説明されているのでお勧めするわけです。

さて、本の宣伝はこのくらいにして、このメルマガはあくまでも「システム開発」についてのメルマガ。

片寄って一部分だけズームインしてみます。

では、本文63ページと64ページから

つまり、クオリティの高い思考には、論理の積み重ねだけでは
説明できない領域があることは、経験上わかっていたのであるが
どうすればその高みにいたれるのかを説明する明確な体系はこれまでなかった。

システム開発のプロジェクトで、詳細設計から全容を理解するのが無理な理由はこれだとわかりました。

で、その解決方法として、神田氏は、こう語っています。

ジグゾーパズルの完成後の全体像を見たあとは、どんな小さなピースにも全体が見いだせるようになる。
・・・・（略）
つまり、一度、全体像を理解してしまうと、部分には全体を完成させる強烈なエネルギーが宿りはじめるのである。

プロジェクトを成功に導くコツは、とにかく全体像を理解させること。

まずはこれなんです。

今日のシステムを成功させるポイント

積み重ねで全容を理解するのは難しい。

全容を見せて考え理解させよ。

続きを読む "全脳思考からシステム開発のヒント" »

CMS[コンテンツ・マネジメント・システム]って、一般の人は知らない言葉だとばかり思っていました。

でも最近はSEOくらい有名になってきたようです。

ホームページのお問い合わせで、一般の方からいきなり「CMSでホームページを作りかえたい」などと言われて、びっくりすることも無くなってきました。

ただし、こういった言葉って、CRM[顧客関係管理システム]でも　CMS[コンテンツ・マネジメント・システム]でも　SaaS[Software as a Service]でもある意味ベンダー（ソフト提供）側が都合がいいように使っている場合もあるんですよね。非常に残念だけど・・・・。

当社だってそういう気持ちが分からなくもない。

だからこそ、「お客さまに説明するとき」「質問を受けたとき」など表現の仕方がものすごく難しいと思いますね。

CMSを説明するとしたら、なんて答えましょうか。

--------------
ホームページは、デジタルであるというだけでチラシみたいなものです。

チラシのデザインやイラストを変更するとしたら、絵や写真だけでなくもう一度、文章も入力し直して、チェックし直す必要があります。

でも、素人が触るとデザインがズレたりミスプリントされたりする恐れがあります。

そこで、文章（テキスト）がすべて分類されてデータベースという戸棚に入っていたらどうでしょう。

デザインを変えてもズレやミスプリントもなく、そのままの品質が保てるとしたら。

デザインを変えること、新しいサイトを作って複数の場所から情報を流すことが容易にできるようになります。

これにプラスして、承認権限を付けたり、予約公開をしたりすることもできるようにもなります。

コンテンツ（ホームページに載せる記事や企画のことです）を管理できるからコンテンツマネジメントシステムというのです。

--------------

こんな感じでしょうか。

今、楽だなあと思うのは、「ブログ」がノーマルな知識になってきたことですね。

当社にとって（自社の宣伝で申し訳ない）CMSを説明するのはSix Apart(シックスアパート社）のMovable Typeの応用力を説明することとイコールなので、ブログから話を膨らませていくとわりと理解してもらえるようです。

ブログを知らない、分からない人は、むしろHTMLという言葉さえ分かってくれないので、どうしましょうか。

ExcelやWordを覚えるくらい、もしくはもっと簡単にホームページの記事の追加や更新が自社でできます、とでも言うしかないかも・・・。

それから、情報リテラシーが低い人たちに多いのが「ブログって日記でしょ」というもの。

ブログ＝日記＝せいぜい使えても“社長の日記”＝自分の会社のホームページには関係ない。

3年くらい前だとこういう人が多かったのですが、さすがに減りました。

今や、様々な会社がいろいろなCMSを販売しています。

そこで、コンテンツマネジメントシステムを採用する最低限の条件です。

それは、汎用的なデータベースを利用していること（もしくは、できること）。

データベースのどこに何が登録されるかが公開されていることです。

お勧めはOracle、SQL Server、MySQL、PostgreSQLのいずれかのデータベースです。

どんなに安くて便利でも、もしこれら以外のデータベースを使っているとしたら、特に自社開発の・・・だったとしたら、やはりCMSを開発した会社の手の中で言われるがままにホームページなりサイトを作っていくしかありません。

運用費だけでなく将来の作りかえのコストを考えたら、最低限の条件はデータベースだと思います。

ちなみに、フリーでも有料でも有名ブログサイトは、大抵がMT（Movable Type)形式でデータをダウンロードして他のブログに引越しできるようです。

そういった面でMovable Typeはお勧めです。

続きを読む "CMSは何で選ぶ？・・・CMSを選ぶ最低限の条件" »

先週から「天才!成功する人々の法則」の第2部第7章を紹介しています。

1999年までに、悲惨な航空機事故を繰り返した大韓航空、最悪のエアラインから世界でも優良のエアラインに立ち直った理由　それは、「文化的な遺産の重要性」を認めたことからでした。

これに関連してコロンビアの航空会社の恐ろしい事例が紹介されています。

1990年アビアンカ航空の０５２便が墜落しました。

ニューヨークのジョン・F・ケネディ国際空港へ向かっていたアビアンカ航空の０５２便は、悪天候のため３回も航空交通管制に空中待機を命じられていました。

そして予定より1時間15分遅れで着陸許可が下りたとき、燃料切れで墜落したのです。

この事故の原因は、3つあるといいます。

「出発の遅れ」
「オートパイロットの小さな不具合」
「3度にわたる空中待機」

事故機であるボーイング707型機は、古い型式で操縦が難しく飛ばすのに苦労するのです。

さまざまな要因が重なった結果、機長は疲れ果て、決断力が鈍り普段なら気づく何かを見落としてしまった。

その何かとは、「燃料不足になる」ということだったのです。

ケネディ国際空港のすぐ近くで墜落するまで40分も旋回飛行を続けていた間、操縦室の誰もが燃料が残り少ないことを承知していたはずです。

ところが近くのフィラデルフィア国際空港へ着陸することもできたはずなのにしなかったのです。

3度目の空中待機を指示されてはじめて管制官に「別の空港まで飛ぶ燃料がない」と告げているのです。

管制官の返答は「待機せよ」でした。

そのときどうも機長は、自分たちを管制官が他の飛行機よりも優先させて着陸させてくれると考えていたふしさえみられるのです。

しかしそれは、とんでもない誤解でした。

また、乗組員は「燃料がない」ということを再度大声で強く伝えたでしょうか。

いいえ、燃料切れの問題を伝えたのは、さらに38分後のことだったのでした。

ボイスレコーダーからもっと恐ろしいことがわかりました。

機長が副操縦士に「（燃料がない）緊急事態だと伝えろ」と言った指示に対して副操縦士は、どういう連絡を管制塔にしたと思いますか？

他の報告のついでに最後に付け加えて「こちらは燃料がなくなりかけています」と軽く伝えているだけなのです。

それも、何気ない口調だった、声に切迫感がなく管制官にとっては、「ついでの発言だ」としか思えない連絡でした。

これは「緩和された話し方」と呼ばれています。

発言の持つ真の意味合いを控え目に伝えるとか、聞こえやすくしようとする試みを指します。

私たちは、よくこういった話し方をします。

「もし可能でしたら、月曜にいただけるとありがたいのですが・・・」

機長であれば、副操縦士にものを言うときは、彼らは、明確に命令として「月曜までに納品してくれ」といった言い方をします。

しかし、副操縦士は機長に、はっきりと「命令」できるのでしょうか。

答えはNOです。

圧倒的に多数の副操縦士がその立場のせいか「示唆」と言われるもっとも柔らかい表現を選ぶことが調査でわかっています。

だから、恐ろしいことに過去の例をみれば、機長自身が操縦桿を握っているときのほうがはるかに墜落事故は起きやすいのです。

なぜなら機長が間違ったことをしたときに、副操縦士はNOと言えないのです。

人命がかかっているというのに！

ここ15年ほどの間、民間航空業界においては「表現の緩和との戦い」が重要な課題改革になってきたのでした。

アビアンカ航空機事故も、問題はここにあったのです。

ただひとこと、「無理だ。燃料がない」といった強制力をにじませたアナウンスがされればよかったのです。

しかし、管制塔とやりとりをしていたのは副操縦士だった。

権力格差指標という「その国の文化が権威を重んじ権威に敬意を払うかどうか」を示す指標があります。

権力格差が大きな国では、部下であるがために、常に相手に気を使ったものの言い方をしてしまうのです。

だから副操縦士は、部下から上司に対する話し方で管制塔と話してしまったのでした。

管制官は権力格差が小さなアメリカ人であり、彼にとって緩和された話し方は「差し迫った問題がない」という意味でした。

ここに、副操縦士がアメリカ人であれば、燃料がなくても待機している状況に大人しく我慢していなかったのではないかという国の気質の問題があります。

アメリカが権力格差は最もない国であり、コロンビアは権力格差が大きい国だったのです。

ちなみに世界で一番格差が大きな国は、ブラジルであり、2番目が韓国でした。

もうおわかりでしょう。

大韓航空がどんな改革をおこなったのか。

実は、航空英語の熟達を支援したのでした。

英語こそが航空業界の言語だというものでした。

通常、パイロットは自国の「文化的な遺産」の重みに押し付けられた役割から抜け出せない。

そこで、英語を話すことで、まったく別の遺産を持った文化と言語に参加できるきっかけを与えたのです。

優れたパイロットであるというのは本当はどういうことなのか。

文化や歴史や個人を取り巻く世界が、仕事の成功に大きな関係があるととことん理解することが一歩なのかもしれません。

続きを読む "大韓航空はなぜ立ち直ることができたのか？" »

全米で100万部を超えるベストセラーになったビジネス本「天才！成功する人々の法則」が勝間和代さんによって翻訳され、講談社から出版されています。

この書籍のもともとの主題は「天才と呼ばれる人々は生まれつきの才能で成功するのか？」ということであり、生まれながらの資質や努力よりも、むしろ時代や環境、与えられたチャンスによって成功しているのであるという話です。

天才は「1％の素質と99％の努力」という言葉が先入観としてある身には、ちょっと「えっ」と耳を疑ってしまうものです。

しかし、説得力のある数字や資料に裏付けされている話です。

この本の中に、システム開発と関連付けると非常に興味深い章があります。

それは、第7章「航空機事故の“民族的法則”」です。

ここには、恐るべき大韓航空の歴史が載っています。

1988年から1999年における、アメリカ・ユナイテッド航空のフライト100万回あたりの“機体損失”率は0.27。

一方、大韓航空の損失率は4.79。

ユナイテッド航空の実に17倍以上の機体が落ちている計算になります。

確かに、10年以上昔には「命が惜しければ大韓航空には乗らない」といったことが秘かに言われていました。

そして1999年、当時の金大中大統領は率直にこれを認めました。

「大韓航空の問題は一企業の問題ではなく、韓国全体の問題である」

そして、大統領専用機を大韓航空からアシアナ航空に変えたのです。

ところがその後、大韓航空は自らの「立て直し」に成功したのです。

1999年以降、彼らの安全記録には非の打ちどころがありません。

大韓航空が最悪のエアラインから世界でも優良のエアラインへ変貌したのは、同社が「文化的な遺産の重要性」を認めたからだったのです。

大惨事はなぜ起こるのか？

それは、小さなトラブルと些細なエラー要因の蓄積の結果なのです。

墜落の典型的な原因は悪天候、しかも過酷である必要はなく、パイロットが通常よりストレスを感じる程度の天気なのです。

圧倒的に多い原因は出発が遅れ、パイロットが焦っているときであり、墜落事故の52％が機長が目を覚まして12時間以上経過したとき、つまり、機長が疲れを感じ、判断力が鈍ってくるときなのです。

さらに、墜落事故の44％が機長と副操縦士が初めての顔合わせのときに起きているのです。

そしてエラーが生じる。しかもひとつにとどまらなく人為的ミスが7つ続く。

7つのエラーが大惨事を招くのです。

ついつい、ヒヤリハットが300続くと29の軽傷事故があり大事故1つに繋がるというハインリッヒの法則を思い出してしまいました。

しかも、この7つのエラーは、知識や飛行技術の問題ではないというのです。

難しい操縦技術を求められて失敗したわけではないのです。

この本には、大韓航空の事例だけでなく、コロンビアの航空会社であるアビアンカ航空の有名な墜落事故について恐ろしい物語をかたっています。

では、どんな理由で航空機は墜落するのか？そして、大韓航空はどうやって立ち直ったのか、気になる人は自分で本を購入されるのもお勧めですよ。

次回に続きます。

●Amazon「天才! 成功する人々の法則」

続きを読む "航空機はなぜ墜落するのか" »

公開されたばかりの「天使と悪魔」を観ました。

正直、まったく期待せずに観にいったのですが、驚きました。

あの面白くないどころか「退屈」ですらあった「ダ・ヴィンチ・コード」の続編とは思えない出来の良さでした。

ハリウッド映画のアクション・テンポ・ゴージャスが満載といったところです。

では、製作メンバが代わったのでしょうか。

いいえ。

原作　ダン・ブラウン
監督　ロン・ハワード
製作総指揮　トッド・ハロウェル
製作　ブライアン・グレイザー
脚本　アキヴァ・ゴールズマン
主演　トム・ハンクス

これが今回の主要製作陣です。

多少の入れ替わりはあるものの中枢は全く同じメンバと言えるでしょう。

前作「ダ・ヴィンチ・コード」は大失敗だったと信じていたのですが、実際は興業的にはそこそこ成功していたのですね。

無知でした。

しかし、それでも全く同じメンバで総大な予算を使って続編を作ろうとしたソニー・ピクチャーズも偉いと思います。

前作が賞賛されなかったとはいえ、世界で名の知れたプロ集団ですから、どこが悪かったかを反省し、思う存分に「これがハリウッド映画だ」というところを見せつけてくれたように思えます。

・トム・ハンクスに加えてユアン
・マクレガーという上手いだけでなく魅力ある役者が出ていること
・映像として荘大で美しい印象ある場面が多かったこと
・テンポが速いのにストーリーについていけたこと

これらが良い要素として映画の印象をつくり上げました。

良く出来た映画というのは、やはり戦略にのっとって作られるものなんでしょう。

システムも同様に、失敗したり、いま一つ評判が悪いシステムも、逆にその原因をきちんと精査して、戦略を考えて再構築すれば、素晴らしい出来になるということも十分あるのではないかと思うのです。

成功したシステムの視点
失敗したシステムの原因

をきちんと把握していること。

また、今回の「天使と悪魔」は、ダン・ブラウンの関与が薄れてロン・ハワードが自由に長刀を振るうことが出来たことも成功に大きく貢献したようです。

本来、能力や経験がある人であれば、いろいろ口出しされたり、調整しながら仕事をするよりも自由に采配を振るえるほうがより成果を出しやすいということもいえるでしょう。

【参考】
・超映画批評『ダ・ヴィンチ・コード』
http://movie.maeda-y.com/movie/00726.htm
・超映画批評『天使と悪魔』
http://movie.maeda-y.com/movie/01282.htm

続きを読む "『ダ・ヴィンチ・コード』と『天使と悪魔』の違い" »

ついに連休も終わりました。

新型インフルエンザ、高速道路渋滞などの影響で出掛けるのにも躊躇することが多く、今回の連休はおとなしく過ごしました。

遊びすぎなかった連休というのも、体調だけでなく精神的にもいいものだと実感しました。

さて、連休前に私が出した質問、覚えていらっしゃるでしょうか。

システム開発を行う場合の工程別のコストの割合についてです。

今の私自身の考えは

1）客先での打ち合わせと外部設計　20
2）内部設計　20
3）開発（プログラム作成とテスト）　50
4）納品　10

ということもお話しました。

本当に残念というか・・・仕方がないというか、開発の比重が大きくなることが気になります。

開発の比重を小さくするためには、今や開発部分を切り分けてオフショアして単価を下げることが当たり前なんですね。

しかし、オフショアもいつまでも単価が安いままが続くのでしょうか？

安いというのは、日本が他のアジア諸国に比べて先進諸国であるという理由だけで感じる相対的物差しのはずです。

システム会社としては、この内訳の比率の意味を理解し、常に見直すことが必要です。

私の経験からお話しましょう。

出来の悪い、もしくは進捗がうまくいっていないシステム開発があるとします。あくまでも仮定ですが。

こういったシステム開発の場合、目に見えてわかることがあります。

外部設計、内部設計、開発、納品が工期としてダブることが多いのです。

ひどい場合には、隣り合わせの工程がダブるだけでなく、仕様が戻ってしまい、「 1）客先での打ち合わせと外部設計」と「 3）開発」が同時に行われていたりするのです。

理想の開発では、1）→ 2）→ 3）→ 4）と順番に進むものが、「 3）開発」の段階で未だ 1）のヒアリングが終わっていなかったりするのです。

それは、開発途中で、ユーザー企業のおかれている状況が変わり、否応なしに仕様修正が入るということもあるかもしれません。

しかし、もともとの仕様を開発側とユーザー側でしっかり確認していなかったために「 4）納品」になってから発覚したという場合があります。

これが最悪のパターンです。

しかも、ウォーターフロー開発の場合開発途中で誰かが気づくということが非常に少ないのです。

また、開発途中で気がついたとすると、開発期間が延長になってしまいます。

開発期間は、その期間だけ人員増加することが常識ですので長期戦に持ち込むことが、そのままコスト高の理由になってしまうのです。

そこで、プロマネの重要性や上流工程の価値が再評価されるのですね。

やり直しが許されるのであれば、開発に入る前までをやり直したいとシステム会社が思うのは当然のことといえます。

ただ、私個人としては、もっともっと開発のコスト率を下げる方法が他にあるのではないかと思っているのです。

続きを読む "出来の悪いシステム開発とは" »

あなたにGWの宿題です。

前回、トータルコストを下げるのにはコツがあるというお話をしました。

連休前なので長い話や細かい話はやめて、技術者・開発者の皆さんに休みの間に、時間があったら考えていただきたいことがあるのです。

それは、システム開発の工程の割合をどのように考えているのか？ということです。

というのは、トータルコストと言ったとき、どうしても若いころの自分の失敗について考えてしまうからです。

わたしがSEになった当時に、漠然と考えていた工程別コストの内訳は、すべてを100とすると、

・客先での打ち合わせと外部設計　10

・内部設計　 5

・開発（プログラム作成とテスト）　83

・納品　2

こんなイメージでした。

「客先にシステムを納品したら終わり」と頭の中ではイメージしていたのです。

それがどんなに浅はかな考えだったのかは今は理解できます。

なぜなら、経験上、プログラム10本以内の小さな処理だったり現在のシステムの焼き直しであったり、トラブルが起きることの少ないシステムでない限り、イメージ通りにシステム納品が終わったことは実は一度もなかったのです。

現在のわたしのイメージは（もちろんシステム機能の多さにもよりますが）

・客先での打ち合わせと外部設計　20
・内部設計　20
・開発（プログラム作成とテスト）　50
・納品　10

これでも納品に関する工数はまだまだ少ないと感じますし、開発の割合はもっともっと少なくしたいところです。

しかも、これには定期保守に入ってからの工数を含んでいません。

5年先までを考えたシステムであれば、当然、5年間の保守工数が入ってくるので全く違う割合になります。

どうでしょうか？

あなたが考えているコストの割合を今一度考えてみてください。

続きを読む "あなたの考えるコストで大丈夫？" »

一つのシステムを納品するのには、獏大な時間がかかるものです。

今でもそう思いますが、システムエンジニアとして走り始めた頃は、もっともっと大変でした。

COBOLと索引データベースでの開発がその原因でした。

ツールも良いものが無く、生産性が極端に悪い開発環境だったので、無駄に時間を使ってしまったり、障害を特定できるまでに長時間かかることが多くありました。

たとえば、マスタ8本、ジャーナル12本、主機能40本の販売管理を設計したとします。

主機能40本に加えて、マスタメンテナンス8本、マスタリスト8本

これらのプログラムを作るのは当然ですが、加えてジャーナルメンテナンス12本、ジャーナルリスト12本も作っていました。

今では、RDBMSやAccess、Excelであれば簡単に、メンテナンスツールやリストを作ることができます。

ところが、当時は1本のツールを作ることさえ、一から手作りでした。

だからと言って、これを作ることをさぼると、結合テスト中でも納品後に問題が起きたときでも、原因解明に膨大な時間がかかってしまうのです。

当時は、その問題を追及するためのプログラムを現場で作るということを当然のように行っていました。

今、考えるといかに生産性が悪い方法だったかと思います。

結局、最初からメンテナンス用のプログラムを作っておいたほうが、生産性は高くなるのです。

また、お客さまに納品したシステムエンジニアが、運用保守まですべて引き受けるという慣習があったため、土曜の早朝にいきなり電話がかかってくることもありました。

電話応対で対応できる問題であればなんのことはありません。

ときには、すぐ現地に飛んでいかなければなりませんでした。

いつなんどき「呼び出されるかわからない」というのが当時のシステムエンジニア、そう、私の宿命でした。

しかし、キャリアを経て気付いたのですが、それは私自身の設計に問題があったのでした。

自分が作ったシステムは「正しく動いて当たり前」と考えていたのがその理由でした。

土曜、日曜も関係なく「緊急に呼び出される」システムを作っていたのは自分だったのです。

　請求書が発行できない
　請求書の表記が間違っている
　データの不整合がおきる

とにかく、データが正しく処理されない場合に電話がかかってくるのです。

そして、何がおかしいのか、離れた場所からはわからないので駆けつけなければなりませんでした。

今でこそ、遠隔地からでもリモートメンテナンスが可能ですが、当時はファックスも普及していない時代です。

大変苦労もし無駄な時間を使いました。

システムの開発には「押さえどころ」があるのです。

トータルコストは、お客さまの運用時間だけでなく、システムエンジニアの納品後の稼働率や駆けつけ時間までも含んで考えるべきでしょう。

いかにして「駆けつけなくてもよいシステム」を作るのか

それには、いろいろなコツがあるのです。

（次週に続く）

続きを読む "トータルコストとはなにか？" »

IT業界の常識をそのまま鵜呑みにして行動していると幸せになれない、そう気づいたのはいつのことだったでしょうか。

そのひとつが、外部からプロジェクトメンバーを募るときのやり方です。

自社で要員を確保できない場合、派遣会社や同業のシステム会社に人の手配をお願いすることがあります。

・仕事の概要（業務内容、OS、DB、言語）
・期間（○月○日から○ヶ月）
・応募人数（○名）

という内容でお願いすると、先方の営業が、自社や知り合いの会社のSEの職務経歴書を送ってきます。

そして、発注側が気に入れば「採用面接」になるという手順です。

この採用面接ですが、名の通り、面接だけのことが多いようです。

つまり、これまでの業務経験について質問し、その応対能力を見て判断するのです。

しかし、これが企業の入社試験であれば、どうでしょう？

筆記の能力診断テストが課されたりして、1対1の簡単な面接だけで、あっという間に採用したりはしないはずです。

たとえ、明日からプロジェクトが走り出そうとしていて、技術者が一人も決まっていないという状況だとしてもこういった安易な方法を採るべきではありません。

まず、プログラミング技術者を採用しようとしているのであればとにかく、簡単なコードを書かせることが先決でしょう。

簡単なアルゴリズムや、数十行のコーディングで実現できる（慣れたプログラマであれば5分くらいで書き終えてしまうような）問題を出すのが良いでしょう。

それは基本的なアルゴリズムの問題であり、たとえどんなに緊張して本領が発揮できなかったとしても、間違えたり、スペルミスをすることは問題外です。

テストをすることは、発注側にとって応募者がコーディングにどのくらいの時間をかけるかを確認することができるというメリットもあるのです。

「巧遅は拙速に如かず」

どんなに教科書通りの素晴らしいコードを書いたからといって、普通の人が5分で書き終えるものを、5分待ってから書き出し、書き終えるのに10分かかるようでは、採用してはいけないのです。

また、コードを書かせることで、会話だけでは気付かない面も見えてくるはずです。

採用面接で1時間、どんなに真剣に質問を考えたとしても技術者の能力を見抜くのは難しいものです。

確かに、一緒にいて楽しい人や、気の合う仲間を採用するという意識も多少は必要なのかもしれません。

しかし、技術者を助っ人として雇うのであれば、気のいい仲間ではなく、結果を時間内で出してくれる人を求めるべきではないでしょうか。

決して、コードを書かせるテストをはずしてはいけません。

続きを読む "プロジェクトメンバーをどう採用する？" »