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

桜舞い散る4月になりました。当社にも新入社員が登場しました。

わたしがこの業界に入ったのは4月ではなく、8月なのですが、いつも、この時期、新人を迎えると過去のことを懐かしく思い出します。

ちょっとだけ、過去に遡って自分の経験をお話しましょう。

当時、プログラマで職を得たわたしは、プログラマに専念していた3年間を含め、少なくとも5年間はプログラミングをしていました。　

COBOLという“手続き言語”と呼ばれたものが最初に覚えた言語でした。

当時のプログラムは、現在のプログラムと比べてはるかに簡単なことしか実現できないにも関わらず、想像を絶するような「かったるい（面倒な）手順」が要求されました。

一人一台のPCすら無かった頃ですから、プログラミングを行うのは紙と鉛筆でした。

コーディング用紙という、カラムごとに線が引かれた設計用紙にプログラムコードを全部書いていきます。

複写機能を使うことさえできず、紙にひたすら延々とコードを書きつけることが仕事でした。

そのため、プログラミングの作業は長時間を要しました。

しかし、この無駄に思えた長い時間も、今になって思えば良いことでもありました。

当時の自分にとって、一度書いたコードが間違っていたり、後から無駄だと気がつくことは、それこそ天を仰ぐほどつらいことでした。

だからこそ、無駄なコードを書かないため、正常に動作するコードを作るために一生懸命に頭を使ったわけです。

「急がば回れ」それが常にテーマでした。

最終的に無駄にならないコードを書く。

書き出す前に、作り出す前に、どれだけ考えてから走り出すのか。

現代のプログラマは、当然のごとく、PCの画面にプログラミングをパンチすることでプログラミングを行います。

また、ひょっとすると、過去のプログラムを元にして作成することの方が多いかもしれません。

昔は、方法が無かったために、仕方無く紙にコーディングをし、無駄なコードを書くのが嫌なばかりに、頭を使うことを覚えたわたしでした。

しかし、この「先に考える」という力は、とてつもない財産を与えてくれたような気がします。

プログラミングも、設計もプロジェクトマネージメントも、そして文章力もすべて、まずとことん「考える」ことが大事なのだとつくづく思うのです。

考えることも一種の慣れが必要です。

そして、慣れた人は間違いなく成長が速いのです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「巧遅は拙速に如かず」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（次週に続く）

あなたにGWの宿題です。

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

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

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

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

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

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

・内部設計　 5

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

・納品　2

こんなイメージでした。

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

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

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

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

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

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

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

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

どうでしょうか？

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