001. 社員が一番

「お客さま第一」、「Customer First」

よく聞かれるビジネス用語ですけど本気でしょうか?

もちろん買ってくれる顧客がいなければ企業は成り立ちません。社員がいくらいい商品を作っても買ってくれる人がいなければダメです。企業が存続しなければ従業員を養ってもいけませんし、決して間違いということではありせん。

「社員が作った商品をお客さまが買う」

 ┌────────┐
 │  お客さま  │
 └────────┘
    ↑買う
 ┌────────┐
 │  商品    │
 └────────┘
    ↑作る
 ┌────────┐
 │  社員    │
 └────────┘

どれが欠けても企業は存続できません。だから優先順位は付けられない。これが結論です。

では経営者の視点から、何に一番気を配るべきでしょうか? 従業員です。会社にとっては社員が一番であるべきです。コンピュータ業界はスキルが資産。大切なものは社員が持っています。

「お客さまのために」という文句でエンジニアを酷使するのはもってのほか。巷では、エンジニアは誰からも大事にされずに疲れ果て、コンピュータ業界を離れていくのです。

それなら社員が向くべきは? 商品・成果物です。詰まるところお客さんです。社員が経営者や上司の顔色を伺う環境は健康に良くないですね。

「お客さまの要望なんだから、多少の仕様変更は現場で吸収」というのがシステム開発の現場ではアタリマエのこと。そもそも要件定義の段階で見えなかったものも、開発途中では見えてくるものです。しかし100%の設計は不可能です。となると、システムの開発段階での仕様変更は「有り得る」という前提で計画を立てるべきです。

お客さんは共存相手であってカミサマではありません。カミサマからお金を取るんですか?

本田宗一郎は、かつてこんなことを言っていたそうです。

「この馬鹿っつら!阿呆っつら!馬っつら!」ときた。それから「お前、給料どこからもらってる?」「会社からです」。「会社はどこから金もらってる?」「買ってくれた人です」。「結局はお客さんからもらってるってことだ。なのに、こんないい加減な仕事しやがって、お前、そのお客さんを殺す気か!」。

「人はよく、かわいいからこそ怒るなんて言うが、おれはそうじゃない。その時はほんとに憎たらしくなる。なぜなら、おれたちのつくる商品は人命にかかわるものなんだ。それをないがしろにする人間は絶対に許せない」と。

そうやって作っている商品、いいですね。安心して買うことができます。

- S.T. -

002. システムは使われてナンボ

せっかく作ったシステムも使ってもらわなければ、それまでにかけた時間やコスト・労力がムダになってしまいます。当然のことです。

しかし、「コンサルに高いお金を払って業務分析をして要件定義をまとめ、ユーザーとのミーティングを毎週開いて意見を聞き、ITゼネコンを通して開発業者に発注し、ユーザー受け入れテストまでして検収書にサインしたのに使ってもらえない・・・」とは、よくある話です。

なぜでしょう?

まず、複雑なシステムはあまり使ってもらえません。使いにくいからです。

またシステム屋はよく「仕様です」と言ってユーザーの意見を圧殺することがあります。そうやって作られたシステムは、機能不足で業務で使えない、または使いにくい、もしくは作り手のポリシーが反映された保守しやすいキレイなシステムかのどちらかです。大抵は前者です。

ユーザーはシステムで使われている資源(ハードウェアやOS、ミドルウェア等)の機能限界・性能限界を知らないため無茶を言うことがありますが、同じようなことがシステム屋にも言えます。性能限界を知らないから中途半端なプログラミングしかできないのだと。

エンジニアは設計やプログラムを書くことだけに集中するのではなく、自分が一番のユーザーになりましょう。システムを構築するときは単純に「使いやすい」とか「分かりにくい」といった直感が大切です。

- S.T. -

003. 上司を使え

「上司を使え」

これは私自身が実際に上司から言われた言葉です。

M部長は誰に対しても仕事に対する要求が非常に厳しい方でした。

耐えられない人続出、タバコ部屋では「やってられないよ」という愚痴もチラホラ・・・

いつも忙しく、声をかけるのもためらわれるほど。スケジュール管理はもちろん秘書。

そんな中でもときどきランチや夕飯に誘ってくれるなど、私には非常にいい上司でした。

ある日、いつものように厳しいリクエストが飛んできました。

集計するデータの量は膨大、必要な資料の一部は他部署の知らない人が持っているので、コンタクトを取って自己紹介を少々とこちらの目的、資料の開示範囲などを説明しなければならない。リミットは明日の朝一まで。なんとか出来るかもしれないが、ひょっとしたら間に合わないかもしれないと必死に作業していると、M部長が声をかけてくれました。

「データそろった? 経理からもらえた?」

「いえ、まだです。メールでの返事はNGでしたので、これから直接会って話してきます。」

「あのね、そういうときは上司を使いなさい。言葉は悪いけど、私(部長)をうまく使うってことだよ。自分でなんとかするのもいいけど、今回の件は時間が無いんだ。私から経理の部長に直接話をすれば早いからね」と。

部長に「これやってください」とお願いをするなんて考えたこともありませんでした。

しかし、当のM部長を見ていると、確かに他部署のミドルから果ては CFO まで使って自分に与えられたミッションを着実にこなしているのです。大切なのは、会社全体を見たときに内部摩擦でロスが生じていないこと、自分のミッションを中途半端な状態ではなくキッチリとしかも早く仕上げること。

会社の中には気難しい人もいます。仲良くしてくれる人もいます。うまく付き合っていくにはいくつか方法があります。その中でも、「上司を使え」はなるほどごもっともです。M部長はもちろん私より高給取り。それだけの仕事をしているのです。

そして何より、上から指示を出すだけではなく「管理職」として下からしっかりとサポートしてくれたのです。

- S.T. -

004. 文系と理系、どちらがシステム屋に向いているか?
2012.09.10

結論から言います。「文系」です。

もちろんそれぞれにメリット・デメリットはありますが、総じて文系のほうが向いていると思います。

最大の理由は、開発・保守・運用を主とするシステム屋の仕事の特徴として「自分が考えたものを作る」ことは稀だからです。

大工が自分の家を建てるより他人の家を建てることのほうが多いことに似て、システム屋の多くは他の人の頭の中をコンピュータで実現するための橋渡しをします。

その最も要となる能力は『読解力』です。

ユーザーの意図を解きほぐす力、要件定義書に落とし込む力、仕様書を理解する力、設計書を読み解く力、それらを他人に伝える力・・・

正確に共有することなしに、ユーザーに満足してもらえるシステムを構築することはできません。

また、長期にわたってシステムを最適な状態に保守・運用し続けるには、技術力もさることながら精神力が問われます。

コンピュータ・システムといえどもスタートは必ずユーザー=人間がデータを入力することから始まるため、きちんとメンテナンスしないとシステムは徐々に劣化していきます。

多くの人が入力するシステムであればあるほどデータの整合性を保つのは至難の業です。

暫定対応のつもりが恒久対応となってしまった増改築の繰り返しで複雑怪奇になったシステムに対して更に綱渡りのような変更を続けなければならない「保守」。

つい昨日まで問題なく動作していたバッチ処理が突然インターフェース先のデータに新たな仕様がこっそり加わったためエラーで落ちてしまい夜中に突然呼び出される「運用」。

あちこちほころびが出て手当が難しくなってくると「いっそ全てを再構築したい」という衝動に駆られますが、たいていは許されません。

これは経験則ですが、そう思う傾向が強いのはどちらかといえば「理系」です。

文系の人のほうが比較的柔軟で、傷口に絆創膏を貼るようにサラッと変更を加えて、「問題なく動いているから」と言い放つこともしばしばです。

一方、「作る」段となれば力を発揮するのはむしろ理系でしょう。

理系的な思考回路はコンピュータのロジックと同じだからです。

あたかもパズルを解くが如きロジカルな設計や、パフォーマンスを考慮した芸術的なプログラムを書くことが得意なのは間違いなく理系です。

ところがあまりに芸術的過ぎて、ときに他人が解読できないモノを作るのも理系の特徴かもしれません。

バッチファイルでこんなモノを書くのはだいたい理系です。↓

FOR /F "usebackq delims=*" %%a IN (`DIR /A:-D /B /O:N ^| FINDSTR /I "^[0-9][0-9]_.*[^~]\.bat$"`) DO (
    ...
)

一行に複数の機能を詰め込んだ結果、何をやろうとしているのか理解できないと言われます。

結局のところ文系・理系とも一長一短ありますが、ユーザー側から見たらやはり意図をきちんと理解してくれる「文系」有利でしょう。

文系と理系、お互いがカバーし合えることが理想です。

- S.T. -

005. システムエンジニアの評価は下から上に
2013.09.08

「上司のアナタ! アナタね、オレのやっていること理解できるの?

 会社の中では上司だからハッキリ言わないけど、市場価値ならオレのほうが上だよ!」

なーんて、心の中で思っていないでしょうか?

会社がある程度大きくなると、「上司」という役割が発生します。

ライン・マネージャとも言いましょうか。

プロジェクト毎にチームを組むシステムエンジニアの仕事では上司=リーダーというわけではありませんが、そこはプロジェクト・マネージャ、プロジェクト・リーダーに変わります。

チームのパフォーマンスを最大に持っていくための最重要ポジションはもちろんリーダーです。

ところがそのリーダーですが、

 (リーダーのシステムのスキルが高い)=(チームのパフォーマンスが上がる)

というわけではありません。

むしろシステム屋の場合、メンバーのスキルが高ければ高いほど、

ある程度自由にやらせたほうがチーム全体としてのパフォーマンスは上がるわけです。

では、どんなリーダーがいいでしょうか?

 ・1日=24時間でスケジュールを引いていないか?

 ・仕様を正確に理解しているか?

 ・各メンバーのタスクは明確か?

 ・関係各所への連絡は適切か?

 ・ミーティングは有益か?

 ・コーディングルール、勤怠ルール等の決め事は適切か?

 ・メンバーからの質問に的確な答えができるか?

 ・リーダーのほうから「どうした?」「何かある?」と声掛けはあるか?

 ・メンバーのスキル向上のために何をしたか?

 ・休暇は取得し易いか?

 ・雰囲気は良いか?

書いてみると当たり前のことですが、実際はほとんど違います。

つまり、当たり前のことができる人が少ないということ、リーダーにはリーダーのスキルがあるということです。

困ったことに、そのリーダー/上司がメンバーの『評価』をするわけです。

勤務評定、査定、人事考課、・・・できるわけありません。

明確な基準でオープンな評価を・・・料理人の評価ならともかく、システム屋の評価には無理があります。

360°評価・・・実際のところ無益ですね。

会社のパフォーマンスを最大に持っていくための最重要ポジションはもちろん上司です。

であれば、上司に向いている人が上司をやる組織が理想的ということ。

決めるのはメンバーです。

故に、メンバーが上司を評価する。

ただし、エンジニアのスキルがある程度高いことが前提ですけどね。

- S.T. -

006. 知ってることは教えるべし
2013.09.17

「技術は教えられるものじゃない。盗め。」と言われたことあります。

料理の世界はそういうものだと思っていました。

自腹で食材を買ってきて、今日見たことを自宅でやってみる。

本を買ってきて勉強し、オヤジのやっていることを五感で吸収する。

ストレートに「教えてください」と言っても決して教えてはくれない。

というより「教えてください」なんて言おうものならレードルか坊主鍋が飛んでくる雰囲気。

教えて貰えないけれど、できないと怒られる。

「みんな怒られて育ったんだ」と言われる。

昔は怒られると本当にゲタやナベが飛んできたそうです。

今はやさしいのでグーかパーで済みます。それもよっぽどのときです。

ところがあるとき、突然やって来た料理人は言いました。

「オレの知ってることは全部教えてやる。分からんことは聞け。

 ナベ振ってるときは隣でおんなじことやってみろ。

 何があってもお客さんに迷惑かけることがあってならん。

 知らんモンと分からんモンで話してどうする。怒られてもいいから聞けま。」

その言葉通り、何でも教えてくれました。

丁寧に教えてくれながら怒るんですけど。

「こんなんもわからんのかー! ダラかお前は! バカモノー!」(富山弁)

その人は感覚で覚えているから必要ないのに、普段は量らない出汁の割合まで

私に教えるためにわざわざグラムを量ってくれるのです。

出汁巻を巻いていたとき、

「ちょっ来いまー! 同じようにやってみろ!」と言われたことがありました。

同じ材料、同じ巻鍋、同じ火力で、出来上がったものはもちろん違います。

「1個20円の卵をな、500円いただける料理にするのか、100円にしかならないのか。

 腕を磨け、腕を。

 お前が巻いたそれは、お前が自分で食べろ。」

巷で言われる料理人とは違うので、あるとき聞いてみました。

「どうしてホントに何でも教えてくれるんですか?」

「お前なぁ、見て教えられただけでうまくなったんか?

 家でやんなくてもいい。厨房の食材使っていいから、ちゃんと練習しとけ。

 まあ、お前が出汁巻うまく巻けるようになったときには、オレはもっとうまくなってる。

 いつまでたってもオレには追いつけん。」

山本五十六も言うてます。

「やって見せて

 言って聞かせて

 やらせて見て

 ほめてやらねば

 人は動かず」

- S.T. -

007. 退勤前にすべきこと
2014.10.12

『明日やること』を確認する。

「よっしゃ、今日の仕事は終わり!」とスッキリした気持ちで帰るのもいいですが、

その前に『明日、何をやるか』だけ確認しておいてください。

明日は、

・仕様書を書く

・テーブル設計をする

・プログラム作成

・エラーの調査

・打ち合わせの資料作り

・掃除

...

1日分のタスク量で優先してやるべきことを頭にインプットしてから帰ります。

出勤後に確認するのではなく、退勤前に確認するのには理由があります。

行き帰りの時間などに思い出して頭を整理できるからです。

いいアイデアが思いつくこともあります。

また、出勤前にやるべきことを思い浮かべているとスタートダッシュが楽になります。

特異なメリットとして、プログラムのコーディングをしているときなどは

夢の中でお告げがあって解決することがあります。

- S.T. -

008. 敵がいない者は味方もいない
2015.07.20

「正しい」と思ったことを通すべし。

しかしながら自分では「正しい」と思ったことでも

別の人にとっては「ありえない」ことかもしれない。

本気の人同士だから衝突する。

間違うときもある。

ことさら波風を立てるつもりは無いが、ある程度は引くべきでないときもある。

理屈や情ばかりを通すのではない。

「智に働けば角が立つ。情に棹させば流される。

           意地を通せば窮屈だ。とかくに人の世は住みにくい。」

 (夏目漱石、草枕)

「こいつは筋が通っている」と思ってくれる人が現れたとき、味方ができる。

- S.T. -

009. 技術者は技術に拠って立つべし
2015.07.20

会社にぶら下がるべからず。

自らの技術に拠って立つべし。

高いスキルを身に付けることで自分自身の商品価値を高めること。

会社がつぶれても大丈夫。

どこでもやっていける。

と思えるくらいになるように。

- S.T. -

010. 相手を怒らせる方法
2015.07.20

とあるコーヒーショップでのことです。

(客)このコーヒー、酸化しているので取り替えてもらえませんか?

(店員)申し訳ございません。

    淹れたてですので、お取り替えしても同じ味になってしまいますが。

(客)豆は○○ですよね。これほど酸味が強くは出る筈はないので確認してもらえますか?

(店員)申し訳ございません。酸味を感じられるかどうかはお客様ご自身のことですので。

(客)いえいえ、いつもこの店で同じものを頼んでいますが、今日のは違いますよ。

(店員)申し訳ございません。お取り替えしても同じ味になってしまいますが、よろしいですか?

(客)同じ味では困ります。取り替えるのが目的ではないですから。

   ちょっと飲んでみてもらえますか? 酸味ないですか?

(店員)申し訳ございません。私には感じられません。すぐにお取り替えいたします。

(客)それでは、取り替えてください。

・・・

(客)やっぱり同じ味ですね。酸味の強いコーヒーは飲めないので、

   別のものに替えてもらえますか?

(店員)別のものというとこでしたら、再度ご購入ということになってしまいますが、

    よろしいですか?

(客)差額ですよね?

(店員)申し訳ございません。再度ご購入ということでお願いします。

(客)差額じゃないんですか?

(店員)申し訳ございません。再度ご購入ということでお願いします。

(客)これやっぱり酸味強くありませんか?

(店員)申し訳ございません。

(客)いや、だから酸味強くないですか?

(店員)申し訳ございません。

(客)・・・

席で聞いていた私も同じものを頼んでいたのですが、いつもより酸味は感じるものの、

砂糖とミルクをたっぷり入れているのでだいぶ中和されていました。

ブラックでははっきり分かるのでしょう。

気になったのは店員の「申し訳ございません」という言葉です。

謝罪の気持ちは感じられず、会話になっていません。

お客さんの声もだんだん大きくなっていきました。

聞いているこちらも客サイドに加勢しようかと思うくらいイライラしてきました。

「確かにいつもより酸味強いですよ」と。

その店員は「味が違う」と言われたのをクレームと思ったのでしょうか?

同じ銘柄のコーヒー豆は味が変わらないと思っているのでしょうか?

どうして「自分には分からないけれど味が違うのかもしれない」と思わなかったのでしょうか?

もしかしてマニュアルには

「客からのクレームにはとにかく謝罪すること」と書いてあるのでしょうか?

ところが、人間、会話がかみ合わないまま謝罪だけされると余計に腹が立つようです。

マニュアル通りのことしか言わないなら機械を相手にしたほうがあきらめがつきます。

「パスワードが違います」「パスワードが違います」「パスワードが違います」

相手を怒らせるには「相手の言い分を無視して、ひたすら謝罪すること」が効果的なようです。

相手が真剣になればなるほど「理解してもらえる筈だ」という心理が働くため、

それを逆手に取るということです。

味について・・・

当たり前のことですが同じ豆でもコーヒーの味が変わることはあります。

コーヒーカプセルを売りにするメーカーは「同じカプセルは同じ味」としていますが、

同じ味になるように調整しているそうです。

世界最大の食品メーカーのコーヒーカプセルですら飲めなくなるくらい味が変わるのです。

当然です。

採れた年が違う、採れた畑が違う、まったく同じ味になる筈がないからです。

味覚について・・・

日本人だけ、ほとんどの人が「旨味」を感じ取ることのできる民族です。

辛・酸・鹹・苦・甘+旨味の六味を味わえるからこそ、日本人には和食なのです。

- S.T. -

011. 会社選びは社長で選べ
2016.02.17

入りたい会社を選ぶときの判断基準は?(複数回答可)

・場所

・給与

・歴史

・規模

・商品

・社風

・知名度

・技術力

・イメージ

・○○を活かせる

・・・

「大企業しか入りたくない」

「大企業には入りたくない」

「年収100万はヤダ」

「年収1000万はイイ」

「家から近い」

「外資系」

「コネ」

「BtoC」

「入れてくれるのであればどこでもいい」

「社長=会社に一番影響力のある人」を基準にする人はあまりいないようです。

大きい会社だとあまり関係ないと思っているのでしょうか?

違います。

社長一人で会社は大きく変わります。

大企業でもです。

もし社長が変わっても社内が変わらないような会社だったら、

ルーチンが多く過去の遺産を食い潰し生産性は低く会議と決裁がダラダラという

大企業病の症状が出ているのでしょう。

お父さんやお母さんが変わったら家の中はガラリと変わります。

会社も同じです。

誰と一緒にやっていくかが大事で、何かあったら最後の砦となる人が社長です。

自分に合う社長を見つけることができれば会社選びは終わりです。

ですが「自分に合う」のは自分だけのことですので、友達や家族の意見とは違うはずです。

一方で、大企業病の中にいるのが心地いい人もいるみたいです。

いい人と出会えたら仕事が楽しくなります。

- S.T. -

012. 開発者はスペックの低い PC を使うべし
2016.06.11

一般的に、

開発サーバは本番サーバより CPU、メモリ、ディスク が少ないことが多い。

開発PC はユーザPC よりスペックが高い場合が多い。

これ、全く逆です。

サーバについては CPU とメモリは同等、ディスクは開発環境のほうを多くすること。

開発者は社内で一番スペックの低い PC を使うこと。

CPU、メモリ等の負荷バランスを考えてコーディングするため

開発サーバと本番サーバの CPU、メモリを合わせておかないとテストになりません。

開発に“あああデータ”を使うのは、せいぜい初期のコーディングのときくらい。

できれば本番データそのまま、もしくはマスクをかけたデータを使ってテストします。

カラム長いっぱいのデータも必要です。

当然、開発サーバのほうがディスクが多くないとテストになりません。

データ移行や何やらで2~3倍くらいのディスク量は必要になります。

また、スペックが高い PC では起きない現象もあります。

開発者はスペックの低い PC を使い、それでも快適に動くものでなければなりません。

PC のチューニング、プログラムのチューニング、技術者の基本です。

- S.T. -