ＳＥ家の家訓 目次「お客さま第一」、「Customer First」
よく聞かれるビジネス用語ですけど本気でしょうか？
もちろん買ってくれる顧客がいなければ企業は成り立ちません。社員がいくらいい商品を作っても買ってくれる人がいなければダメです。企業が存続しなければ従業員を養ってもいけませんし、決して間違いということではありせん。
「社員が作った商品をお客さまが買う」
どれが欠けても企業は存続できません。だから優先順位は付けられない。これが結論です。
では経営者の視点から、何に一番気を配るべきでしょうか？ 従業員です。会社にとっては社員が一番であるべきです。コンピュータ業界はスキルが資産。大切なものは社員が持っています。
「お客さまのために」という文句でエンジニアを酷使するのはもってのほか。巷では、エンジニアは誰からも大事にされずに疲れ果て、コンピュータ業界を離れていくのです。
それなら社員が向くべきは？ 商品・成果物です。詰まるところお客さんです。社員が経営者や上司の顔色を伺う環境は健康に良くないですね。
「お客さまの要望なんだから、多少の仕様変更は現場で吸収」というのがシステム開発の現場ではアタリマエのこと。そもそも要件定義の段階で見えなかったものも、開発途中では見えてくるものです。しかし100%の設計は不可能です。となると、システムの開発段階での仕様変更は「有り得る」という前提で計画を立てるべきです。
お客さんは共存相手であってカミサマではありません。カミサマからお金を取るんですか？
本田宗一郎は、かつてこんなことを言っていたそうです。
「この馬鹿っつら！阿呆っつら！馬っつら！」ときた。それから「お前、給料どこからもらってる？」「会社からです」。「会社はどこから金もらってる？」「買ってくれた人です」。「結局はお客さんからもらってるってことだ。なのに、こんないい加減な仕事しやがって、お前、そのお客さんを殺す気か！」。
「人はよく、かわいいからこそ怒るなんて言うが、おれはそうじゃない。その時はほんとに憎たらしくなる。なぜなら、おれたちのつくる商品は人命にかかわるものなんだ。それをないがしろにする人間は絶対に許せない」と。
そうやって作っている商品、いいですね。安心して買うことができます。
- S.T. -
せっかく作ったシステムも使ってもらわなければ、それまでにかけた時間やコスト・労力がムダになってしまいます。当然のことです。
しかし、「コンサルに高いお金を払って業務分析をして要件定義をまとめ、ユーザーとのミーティングを毎週開いて意見を聞き、ＩＴゼネコンを通して開発業者に発注し、ユーザー受け入れテストまでして検収書にサインしたのに使ってもらえない・・・」とは、よくある話です。
なぜでしょう？
まず、複雑なシステムはあまり使ってもらえません。使いにくいからです。
またシステム屋はよく「仕様です」と言ってユーザーの意見を圧殺することがあります。そうやって作られたシステムは、機能不足で業務で使えない、または使いにくい、もしくは作り手のポリシーが反映された保守しやすいキレイなシステムかのどちらかです。大抵は前者です。
ユーザーはシステムで使われている資源（ハードウェアやOS、ミドルウェア等）の機能限界・性能限界を知らないため無茶を言うことがありますが、同じようなことがシステム屋にも言えます。性能限界を知らないから中途半端なプログラミングしかできないのだと。
エンジニアは設計やプログラムを書くことだけに集中するのではなく、自分が一番のユーザーになりましょう。システムを構築するときは単純に「使いやすい」とか「分かりにくい」といった直感が大切です。
- S.T. -
「上司を使え」
これは私自身が実際に上司から言われた言葉です。
M部長は誰に対しても仕事に対する要求が非常に厳しい方でした。
耐えられない人続出、タバコ部屋では「やってられないよ」という愚痴もチラホラ・・・
いつも忙しく、声をかけるのもためらわれるほど。スケジュール管理はもちろん秘書。
そんな中でもときどきランチや夕飯に誘ってくれるなど、私には非常にいい上司でした。
ある日、いつものように厳しいリクエストが飛んできました。
集計するデータの量は膨大、必要な資料の一部は他部署の知らない人が持っているので、コンタクトを取って自己紹介を少々とこちらの目的、資料の開示範囲などを説明しなければならない。リミットは明日の朝一まで。なんとか出来るかもしれないが、ひょっとしたら間に合わないかもしれないと必死に作業していると、M部長が声をかけてくれました。
「データそろった？ 経理からもらえた？」
「いえ、まだです。メールでの返事はNGでしたので、これから直接会って話してきます。」
「あのね、そういうときは上司を使いなさい。言葉は悪いけど、私（部長）をうまく使うってことだよ。自分でなんとかするのもいいけど、今回の件は時間が無いんだ。私から経理の部長に直接話をすれば早いからね」と。
部長に「これやってください」とお願いをするなんて考えたこともありませんでした。
しかし、当のM部長を見ていると、確かに他部署のミドルから果ては CFO まで使って自分に与えられたミッションを着実にこなしているのです。大切なのは、会社全体を見たときに内部摩擦でロスが生じていないこと、自分のミッションを中途半端な状態ではなくキッチリとしかも早く仕上げること。
会社の中には気難しい人もいます。仲良くしてくれる人もいます。うまく付き合っていくにはいくつか方法があります。その中でも、「上司を使え」はなるほどごもっともです。M部長はもちろん私より高給取り。それだけの仕事をしているのです。
そして何より、上から指示を出すだけではなく「管理職」として下からしっかりとサポートしてくれたのです。
- S.T. -
結論から言います。「文系」です。
もちろんそれぞれにメリット・デメリットはありますが、総じて文系のほうが向いていると思います。
最大の理由は、開発・保守・運用を主とするシステム屋の仕事の特徴として「自分が考えたものを作る」ことは稀だからです。
システム屋の多くは他の人の頭の中をコンピュータで実現するための橋渡しをします。
その最も要となる能力は『読解力』です。
ユーザーの意図を解きほぐす力、要件定義書に落とし込む力、仕様書を理解する力、設計書を読み解く力、それらを他人に伝える力・・・
正確に理解し、共有することなしに、ユーザーに満足してもらえるシステムを構築することはできません。
また、長期にわたってシステムを最適な状態に保守・運用し続けるには、技術力もさることながら精神力が問われます。
コンピュータ・システムといえどもスタートは必ずユーザー＝人間がデータを入力することから始まるため、きちんとメンテナンスしないとシステムは徐々に劣化していきます。
多くの人が入力するシステムであればあるほどデータの整合性を保つのは至難の業です。
暫定対応のつもりが恒久対応となってしまった増改築の繰り返しで複雑怪奇になったシステムに対して更に綱渡りのような変更を続けなければならない「保守」。
つい昨日まで問題なく動作していたバッチ処理が突然インターフェース先のデータに新たな仕様がこっそり加わったためエラーで落ちてしまい夜中に突然呼び出される「運用」。
あちこちほころびが出て手当が難しくなってくると「いっそ全てを再構築したい」という衝動に駆られますが、たいていは許されません。
これは経験則ですが、そう思う傾向が強いのはどちらかといえば「理系」です。
文系の人のほうが比較的柔軟で、傷口に絆創膏を貼るようにサラッと修正を加えて、「問題なく動いているから」と言い放つこともしばしばです。
一方、「作る」段となれば力を発揮するのはやはり理系でしょう。
理系的な思考回路はコンピュータのロジックと同じだからです。
あたかもパズルを解くが如きロジカルな設計や、パフォーマンスを考慮した芸術的なプログラムを書くことが得意なのは間違いなく理系です。
ところがあまりに芸術的過ぎて、ときに他人が解読できないモノを作るのも理系の特徴かもしれません。
バッチファイルでこんなモノを書くのはだいたい理系です。↓
FOR /F "usebackq delims=*" %%a IN (`DIR /A:-D /B /O:N ^| FINDSTR /I "^[0-9][0-9]_.*[^~]\.bat$"`) DO (
...
)
|
一行に複数の機能を詰め込んだ結果、何をやろうとしているのか理解できないと言われます。
結局のところ文系・理系とも一長一短ありますが、ユーザー側から見たらやはり意図をきちんと理解してくれる「文系」有利でしょう。
文系と理系、お互いがカバーし合えることが理想です。
- S.T. -
「上司のアナタ！ アナタね、オレのやっていること理解できるの？
会社の中では上司だからハッキリ言わないけど、市場価値ならオレのほうが上だよ！」
なーんて、心の中で思っていないでしょうか？
会社がある程度大きくなると、「上司」という役割が発生します。
ライン・マネージャとも言いましょうか。
プロジェクト毎にチームを組むシステムエンジニアの仕事では上司＝リーダーというわけではありませんが、そこはプロジェクト・マネージャ、プロジェクト・リーダーに変わります。
チームのパフォーマンスを最大に持っていくための最重要ポジションはもちろんリーダーです。
ところがそのリーダーですが、
（リーダーのシステムのスキルが高い）＝（チームのパフォーマンスが上がる）
というわけではありません。
むしろシステム屋の場合、メンバーのスキルが高ければ高いほど、
ある程度自由にやらせたほうがチーム全体としてのパフォーマンスは上がるわけです。
では、どんなリーダーがいいでしょうか？
・１日＝２４時間でスケジュールを引いていないか？
・仕様を正確に理解しているか？
・各メンバーのタスクは明確か？
・関係各所への連絡は適切か？
・ミーティングは有益か？
・コーディングルール、勤怠ルール等の決め事は適切か？
・メンバーからの質問に的確な答えができるか？
・リーダーのほうから「どうした？」「何かある？」と声掛けはあるか？
・メンバーのスキル向上のために何をしたか？
・休暇は取得し易いか？
・雰囲気は良いか？
書いてみると当たり前のことですが、実際はほとんど違います。
つまり、当たり前のことができる人が少ないということ、リーダーにはリーダーのスキルがあるということです。
困ったことに、そのリーダー／上司がメンバーの『評価』をするわけです。
勤務評定、査定、人事考課、・・・できるわけありません。
明確な基準でオープンな評価を・・・料理人の評価ならともかく、システム屋の評価には無理があります。
360°評価・・・実際のところ無益ですね。
会社のパフォーマンスを最大に持っていくための最重要ポジションはもちろん上司です。
であれば、上司に向いている人が上司をやる組織が理想的ということ。
決めるのはメンバーです。
故に、メンバーが上司を評価する。
ただし、エンジニアのスキルがある程度高いことが前提ですけどね。
- S.T. -
「技術は教えられるものじゃない。盗め。」と言われたことあります。
料理の世界はそういうものだと思っていました。
自腹で食材を買ってきて、今日見たことを自宅でやってみる。
本を買ってきて勉強し、オヤジのやっていることを五感で吸収する。
ストレートに「教えてください」と言っても決して教えてはくれない。
というより「教えてください」なんて言おうものならレードルか坊主鍋が飛んでくる雰囲気。
教えて貰えないけれど、できないと怒られる。
「みんな怒られて育ったんだ」と言われる。
昔は怒られると本当にゲタやナベが飛んできたそうです。
今はやさしいのでグーかパーで済みます。それもよっぽどのときです。
ところがあるとき、突然やって来た料理人は言いました。
「オレの知ってることは全部教えてやる。分からんことは聞け。
ナベ振ってるときは隣でおんなじことやってみろ。
何があってもお客さんに迷惑かけることがあってならん。
知らんモンと分からんモンで話してどうする。怒られてもいいから聞けま。」
その言葉通り、何でも教えてくれました。
丁寧に教えてくれながら怒るんですけど。
「こんなんもわからんのかー！ ダラかお前は！ バカモノー！」（富山弁）
その人は感覚で覚えているから必要ないのに、普段は量らない出汁の割合まで
私に教えるためにわざわざグラムを量ってくれるのです。
出汁巻を巻いていたとき、
「ちょっ来いまー！ 同じようにやってみろ！」と言われたことがありました。
同じ材料、同じ巻鍋、同じ火力で、出来上がったものはもちろん違います。
「1個20円の卵をな、500円いただける料理にするのか、100円にしかならないのか。
腕を磨け、腕を。
お前が巻いたそれは、お前が自分で食べろ。」
巷で言われる料理人とは違うので、あるとき聞いてみました。
「どうしてホントに何でも教えてくれるんですか？」
「お前なぁ、見て教えられただけでうまくなったんか？
家でやんなくてもいい。厨房の食材使っていいから、ちゃんと練習しとけ。
まあ、お前が出汁巻うまく巻けるようになったときには、オレはもっとうまくなってる。
いつまでたってもオレには追いつけん。」
山本五十六も言うてます。
「やって見せて
言って聞かせて
やらせて見て
ほめてやらねば
人は動かず」
- S.T. -
『明日やること』を確認する。
「よっしゃ、今日の仕事は終わり！」とスッキリした気持ちで帰るのもいいですが、
その前に『明日、何をやるか』だけ確認しておいてください。
明日は、
・仕様書を書く
・テーブル設計をする
・プログラム作成
・エラーの調査
・打ち合わせの資料作り
・掃除
．．．
１日分のタスク量で優先してやるべきことを頭にインプットしてから帰ります。
出勤後に確認するのではなく、退勤前に確認するのには理由があります。
行き帰りの時間などに思い出して頭を整理できるからです。
いいアイデアが思いつくこともあります。
また、出勤前にやるべきことを思い浮かべているとスタートダッシュが楽になります。
特異なメリットとして、プログラムのコーディングをしているときなどは
夢の中でお告げがあって解決することがあります。
- S.T. -
「正しい」と思ったことを通すべし。
しかしながら自分では「正しい」と思ったことでも
別の人にとっては「ありえない」ことかもしれない。
本気の人同士だから衝突する。
間違うときもある。
ことさら波風を立てるつもりは無いが、ある程度は引くべきでないときもある。
理屈や情ばかりを通すのではない。
「智に働けば角が立つ。情に棹させば流される。
意地を通せば窮屈だ。とかくに人の世は住みにくい。」
（夏目漱石、草枕）
「こいつは筋が通っている」と思ってくれる人が現れたとき、味方ができる。
- S.T. -
会社にぶら下がるべからず。
自らの技術に拠って立つべし。
高いスキルを身に付けることで自分自身の商品価値を高めること。
会社がつぶれても大丈夫。
どこでもやっていける。
と思えるくらいになるように。
- S.T. -
とあるコーヒーショップでのことです。
（客）このコーヒー、酸化しているので取り替えてもらえませんか？
（店員）申し訳ございません。
淹れたてですので、お取り替えしても同じ味になってしまいますが。
（客）豆は○○ですよね。これほど酸味が強くは出る筈はないので確認してもらえますか？
（店員）申し訳ございません。酸味を感じられるかどうかはお客様ご自身のことですので。
（客）いえいえ、いつもこの店で同じものを頼んでいますが、今日のは違いますよ。
（店員）申し訳ございません。お取り替えしても同じ味になってしまいますが、よろしいですか？
（客）同じ味では困ります。取り替えるのが目的ではないですから。
ちょっと飲んでみてもらえますか？ 酸味ないですか？
（店員）申し訳ございません。私には感じられません。すぐにお取り替えいたします。
（客）それでは、取り替えてください。
・・・
（客）やっぱり同じ味ですね。酸味の強いコーヒーは飲めないので、
別のものに替えてもらえますか？
（店員）別のものというとこでしたら、再度ご購入ということになってしまいますが、
よろしいですか？
（客）差額ですよね？
（店員）申し訳ございません。再度ご購入ということでお願いします。
（客）差額じゃないんですか？
（店員）申し訳ございません。再度ご購入ということでお願いします。
（客）これやっぱり酸味強くありませんか？
（店員）申し訳ございません。
（客）いや、だから酸味強くないですか？
（店員）申し訳ございません。
（客）・・・
席で聞いていた私も同じものを頼んでいたのですが、いつもより酸味は感じるものの、
砂糖とミルクをたっぷり入れているのでだいぶ中和されていました。
ブラックでははっきり分かるのでしょう。
気になったのは店員の「申し訳ございません」という言葉です。
謝罪の気持ちは感じられず、会話になっていません。
お客さんの声もだんだん大きくなっていきました。
聞いているこちらも客サイドに加勢しようかと思うくらいイライラしてきました。
「確かにいつもより酸味強いですよ」と。
その店員は「味が違う」と言われたのをクレームと思ったのでしょうか？
同じ銘柄のコーヒー豆は味が変わらないと思っているのでしょうか？
どうして「自分には分からないけれど味が違うのかもしれない」と思わなかったのでしょうか？
もしかしてマニュアルには
「客からのクレームにはとにかく謝罪すること」と書いてあるのでしょうか？
ところが、人間、会話がかみ合わないまま謝罪だけされると余計に腹が立つようです。
マニュアル通りのことしか言わないなら機械を相手にしたほうがあきらめがつきます。
「パスワードが違います」「パスワードが違います」「パスワードが違います」
相手を怒らせるには「相手の言い分を無視して、ひたすら謝罪すること」が効果的なようです。
相手が真剣になればなるほど「理解してもらえる筈だ」という心理が働くため、
それを逆手に取るということです。
味について・・・
当たり前のことですが同じ豆でもコーヒーの味が変わることはあります。
コーヒーカプセルを売りにするメーカーは「同じカプセルは同じ味」としていますが、
同じ味になるように調整しているそうです。
世界最大の食品メーカーのコーヒーカプセルですら飲めなくなるくらい味が変わるのです。
当然です。
採れた年が違う、採れた畑が違う、まったく同じ味になる筈がないからです。
味覚について・・・
日本人だけ、ほとんどの人が「旨味」を感じ取ることのできる民族です。
辛・酸・鹹・苦・甘＋旨味の六味を味わえるからこそ、日本人には和食なのです。
- S.T. -
入りたい会社を選ぶときの判断基準は？（複数回答可）
・場所
・給与
・歴史
・規模
・商品
・社風
・知名度
・技術力
・イメージ
・○○を活かせる
・・・
「大企業しか入りたくない」
「大企業には入りたくない」
「年収100万はヤダ」
「年収1000万はイイ」
「家から近い」
「外資系」
「コネ」
「BtoC」
「入れてくれるのであればどこでもいい」
「社長＝会社に一番影響力のある人」を基準にする人はあまりいないようです。
大きい会社だとあまり関係ないと思っているのでしょうか？
違います。
社長一人で会社は大きく変わります。
大企業でもです。
もし社長が変わっても社内が変わらないような会社だったら、
ルーチンが多く過去の遺産を食い潰し生産性は低く会議と決裁がダラダラという
大企業病の症状が出ているのでしょう。
お父さんやお母さんが変わったら家の中はガラリと変わります。
会社も同じです。
誰と一緒にやっていくかが大事で、何かあったら最後の砦となる人が社長です。
自分に合う社長を見つけることができれば会社選びは終わりです。
ですが「自分に合う」のは自分だけのことですので、友達や家族の意見とは違うはずです。
一方で、大企業病の中にいるのが心地いい人もいるみたいです。
いい人と出会えたら仕事が楽しくなります。
- S.T. -
一般的に、
開発サーバは本番サーバより CPU、メモリ、ディスク が少ないことが多い。
開発PC はユーザPC よりスペックが高い場合が多い。
これ、全く逆です。
サーバについては CPU とメモリは同等、ディスクは開発環境のほうを多くすること。
開発者は社内で一番スペックの低い PC を使うこと。
CPU、メモリ等の負荷バランスを考えてコーディングするため
開発サーバと本番サーバの CPU、メモリを合わせておかないとテストになりません。
開発に“あああデータ”を使うのは、せいぜい初期のコーディングのときくらい。
できれば本番データそのまま、もしくはマスクをかけたデータを使ってテストします。
カラム長いっぱいのデータも必要です。
当然、開発サーバのほうがディスクが多くないとテストになりません。
データ移行や何やらで２～３倍くらいのディスク量は必要になります。
また、スペックが高い PC では起きない現象もあります。
開発者はスペックの低い PC を使い、それでも快適に動くものでなければなりません。
PC のチューニング、プログラムのチューニング、技術者の基本です。
- S.T. -
野球の話。
外野にフライが飛んできました。
ちょうどライトとセンターの間です。
あなたならどうしますか？
ある日の仕事の話。
古くなったシステムを作り直していたところ、明らかにおかしなデータを見つけました。
「130歳、現役」です。
本番移行データでテスト中のこと、「このデータおかしい」と気付きました。
最初は、すぐに修正してもらえるから大したことではないと思っていたのです。
ところが・・・
データ移行の担当者に「このデータ直してください」と伝えると、
「データの中身は業務部門の管轄です」
「データ変換の仕様書にも業務部門のサインが入っています。仕様通りです」
「そういうデータが入っているのはわかりましたが、システム的には何の問題もありません」
「何か困ることがあるんですか？ 影響範囲を資料にまとめて上げてください」
といった感じ。
「現役従業員の生年月日が1800年代。それだけなんだけど、何を資料にまとめろって？」
次に業務部門の人に言うと、
「旧システムには130歳のデータなんて無いですね。あり得ないです。データ変換の問題はシステム部門に言ってください」
と返される。
「間違っているデータを直してほしい」という単純なリクエストがストレートに伝わらないのです。
普通に「ホントだ。間違ってる。確認して直します」という反応を期待していたのです。
まして「同じロジックを使ったデータ変換が他にもあるはずだから、まずは間違ったデータの洗い出しを」とは誰も言ってくれません。
さらに「このロジックを作った人は根本的にデータの扱いにアヤシイところがある。他の処理もチェックせねば」なんて夢のような話です。
こちらも終いには「このままリリースしたら大変なことになると思いますよ」と、ちょっぴり脅してしまいました。
現実はなかなか複雑なようです。
みんなうまく乗り切っていると思います。
野球であれば、お互い声を出せばいいだけのこと。
飛んできたボールは隣の守備範囲であっても、とりあえず走る。
二人とも引いたらボールは落ちてしまいます。
ビジネスでは、わりと両方とも引きます。
「契約」とか「役割」といったものからはみ出ないことが大事で、
守備範囲外と認識したことについては、「おかしい」と思うこと自体が禁止事項です。
「おかしいと思うけど、どうしようもない」ほうが幾分マシです。
境界に飛んできたボールをうまく捕ってもらったら「ありがとう」。
隣に飛んできたボールでも落ちるとわかっているなら声を出す。「落ちてますよ」でもよし。
自分の守備範囲でさえ 100% 守れるわけではないし、失敗もする。
システム開発はチームワーク。常識ある人はカバーに入ってくれます。
見て見ぬ振りは禁止。
「家訓」にもならない、普通のことです。
- S.T. -
メリットとデメリットは必ず一緒に伝えるべし。
「メリットしかない、デメリットが無い」なんてことはあり得ない。
この世に唯一無二のものでもない限り、必ず比較するものがあり、デメリットはある。
Oracle Database と SQL Server、絶対的にどちらが勝っているということはない。
BI 製品で言うなら Essbase, Cognos, BusinessObjects, MicroStrategy, BIEE, SAP BW など比較対象は数多く存在し、それぞれにできること・できないことがあります。
掛け算や割り算が苦手という製品もあります。
選択しようとしている製品は用途に合っているか、基盤となるデータベースとの連携はどうか、ライフサイクルコストはどうか、開発ベンダーの技術レベルや実際に使うユーザーの OA スキルなど、「どんな場合でもこれが一番」というものは無い筈です。
どうしてもデメリットが見つからないということは、間違いなく知識が足りないのです。
「デメリットを探したけれど、ほとんど見つからない」ということはあります。
自らの未熟を反省し、「申し訳ありません。デメリットはこれしか見当たりません」と言うべきです。
実際のところ、意図的にデメリットが隠されることはよくあります。
しかも大抵の場合、お互い隠し事があるのは承知の上なので、
「そもそも営業やプリセールスは都合のいいことしか言わない」
といった具合に、初めから斜に構えて会話をしています。
もし相手が本当に聞きたいと思って正面から質問をしているのになお隠そうものなら、
「他にもいろいろ隠しているな？」
「自分のことしか考えていないな？」
もしくは
「コイツ何も知らないな？ 話にならない」
と思われてしまい、信用は得られません。
物事を深く捉えること。
相手の立場に立つこと。
ところがこれ、現実には通用しないどころか逆の作用を及ぼすこともあります。
特に日本人以外と仕事をするときは、文化や考え方の違いを理解した上でスタンスを取らないと痛い目見ます。
正直過ぎるのは良くないと指摘されることもありますが、自分を守る盾でもあり、何より技術者としての誠意です。
日本人独特の、相手の立場に立つことの敬意と空気感。
社名の 「ジャパン」 に込めた意味であります。
- S.T. -
問題解決のために検索するのはカンタンです。
インターネットの住民のみなさんは近年ますます親切です。
検索に慣れてくるとピンポイントで問題を解決できるようになるので、すぐ便利に頼ってしまいます。
おかげで目に入る情報もピンポイント。つまり「点」。
システム屋なら、一度はマニュアルの最初から最後まで目を通すこと。
Oracle Database の SQLリファレンス（1400ページほど）でも、ざっと目を通すだけなら１日でできます。
「こんな関数があるんだ」
「こんなパラメータがあるんだ」
「重要なのに隠しパラメータなんだ」
「login.sql って使わないほうがダメじゃん」
AS/400 の開発では、マニュアルを横に置いてコーディングするのが普通でした。
最初のうちは毎日何回も開きますが、だんだん頻度が減って、最後は年に数回になります。
かつては Windows にもためになるマニュアル（ヘルプファイル）が付いていました。
今の Microsoft は一冊のオフライン・マニュアルではなく、検索するように仕向けているので余計に分からなくなりました。
検索項目を正確に入力しないと情報が取れないのです。
つまり、知りたいことしか知ることができないということです。
安易に検索する人ほど、ほぼ例外なく知識量が少なく未熟です。
いくら検索のスキルが高くても、問題解決が早くても、マニュアルに目を通さなければ、全体を体系的に理解すること、知識の枠を一気に広げること、何より最適解を導き出すことはできません。
「技術者は 一にマニュアル 二に検索」
- S.T. -
伝えたことを 100% 理解して消化できる人は稀だと思います。
「この前言ったでしょ！ 何度も聞くな！」と言いたくなりますが、聞いてる本人は頭に残っていないから聞いているのです。
「そうでした。忘れていました。すみません。」なら、かわいいものです。
「わかりました」と言ったにも関わらず、何度も同じことを聞いてくると「何度も聞くな！」と言いたくなります。
しかしこの「何度も聞くな！」を繰り返すと、そのうち何も聞いてこなくなります。
それが一番問題で、精神的ハードルができてしまうと仕事に支障が出ることになります。
本人もつらいです。
何度も言えば覚えてくれる筈ですし、また、忘れない方法をお互い考えたり、伝え方を工夫する余地もあると思います。
メモは基本です。
ところがメモしたことを忘れる、メモが整理されていない、メモを見返さない、・・・
それなら、聞き手が取るべきメモをポイントだけ話し手自らが書いて渡してみる。
伝え方を工夫するのも仕事です。
もっと基本的なことは、人間は忘れる生き物です。
レベルもいろいろ、能力もいろいろ、良いところもいろいろ。
- S.T. -
あなたは小さな会社の経営者です。
従業員が「辞めたい」と言ってきました。
そのとき、あなたはどうしますか？
今まで経営者として自分なりに精一杯やってきた。
勤怠も無理のないように、給与も限界まで支給。
人として正直に接してきた。
それでも「辞めます」と言われたら、手の打ちようがない。
「なんで？」と聞いて、話してくれるならそれで十分。
慰留しますか？
いやいや、それは従業員に対して「精一杯」やってこなかった証拠。
不誠実の上塗り。
「給与アップします」
→ 『今さらアップできるなら、なぜ今まで上げなかった？』
「残業・休日出勤減らします」
→ 『前から言ってただろ。どうせしばらくしたら元通りだろ？』
「何が不満？」
→ 『辞める覚悟がなきゃ話せない』
いまさら感タップリな話ばかりが聞こえてきます。
- S.T. -
何でも正直に、誰に対しても裏表無く同じことを言う。
相手が誰であっても言うことを変えない。
いいことのように聞こえるが、誰に対してもバカ正直に同じことを言えばいいってものではない。
相手が変われば言うべきことも変わる。
「この見積じゃキツイ」
ちゃんと精査もせずにお客さんの目の前で言わんでいい。
イケると思ったら
「はい。わかりました。大丈夫です。ありがとうございます」
ダメかもしれないと思ったら
「内容を確認します。明日中に回答します」
ウソは言わない。
言葉を選べ。
言うべきこと、言わざるべきことをわきまえて、
言うべき人に言うべきことを、言わざるべき人には口をつぐみ、
正しい言動を心掛けるべし。
- S.T. -
「君ならできる！ 君にしかできない！ 任せた！」
これを「仕事を任せる」とは言わない。
「何かやれることありますか？」
いつもそうやって聞いてくる人がいたら、
『キミの仕事も少なくないだろうに、そう言ってくれるのはありがたい』
と思いつつ、
「じゃあ、これ頼もうかな」
となる。
そういう人ほど与えられた仕事を中途半端にしない。
多少不出来でも精一杯やってくる。
そうなると「こんなこともできんのかー」とはならない。
反対に、余裕があるはずなのに何も言ってこない人もいる。
「言われてないから」「指示がないから」じゃないんだよ。
「指示があること」が「仕事を任せること」と思ってる？
「ホレホレ！ オレが成長するタスクを持って来いよ！ ちょうどイイヤツな！」
そうじゃないんだよ。。。
いつまでたっても学生気分が抜けてないんじゃないかな。
いやいや、学生でもそれはアカンでしょ。
仕事を任せるほうは「あれやって、これやって」と仕事を割り振るだけでなく、
待つことも大事。
それではなかなか育たないかもしれない。
50過ぎても変わらないかもしれない。
どうやっても受け身の人もいる。
悩ましいところではあるけれども、いつ私がいなくなっても大丈夫なようにしてもらいたい。
卒業して30年、高校の頃に指導された時の言葉が今になっても思い出される。
「九段の生徒会の指導とは、待つことである」
言いたいのをガマンして、私たちを信じて待っていてくれたのだ。
これが本当の意味で「任せた」ということではないか。
いよいよ良き師に出会えたものである。
- S.T. -
「残業代が出る＝ブラック企業」で間違いありません。
労働基準法に違反することになりますが、法律がおかしいです。
残業代を出さないほうが従業員にとって有利になる企業もあります。
製造業であれば、ラインの労働時間を増やすことで生産量が上がり、売上に直結するため、
超過勤務時間に対して残業代を払うということに違和感はありません。
一方、システム屋のように「月いくら」「成果物に対していくら」のような業態だと事情が異なります。
実労働より先に売上高が決まってしまうため、残業代という意味合いが全く違うものになります。
予め余裕を持って人件費を設定しておかない限り、残業代としての原資が残りません。
特にシステム屋の場合、頭の回転が速い人やスキルが高い人ほど設計やプログラムが短時間で完了するため、
残業代では損をすることになります。
・余裕を持って人件費を設定し、きちんと残業代を支払う
・売上に対して上限一杯の人件費を設定し、残業代という名目では支払わない
残業代が余ったら誰が得をしますか？
どちらが正直な経営だと思いますか？
最終的に賞与で調整するのであれば、もともと残業代は必要ありません。
残業代というマージンを持たせる企業のほうがブラックということになります。
- S.T. -
法律・税金・経営、社会に出て誰もが必要なことをなぜ学校で教えないのか。
一生涯、微分積分を使わないのに、なぜその時だけ勉強するのか。
確かに確率統計は使うが微積は使わない。
しかし、本当に必要なことは「問題を解く力」であり、その延長上に、生きていく上で必要な問題を解決する力が身につくことになるなのだ。
知識を蓄えるにも努力がいる。
公式を覚えるにも努力が必要で、覚えた公式を使うには知恵がいる。
覚えること、覚えたものを使うこと、学校ではその訓練をしているのではないか。
つまるところ、知識と知恵だ。
覚えることは努力でできる。
覚えられないというのは努力をしていないからだ。
やってみるとわかる。人間は結構覚えられる生き物だ。違うのはそれにかかる時間だけ。
頭がいいと言われる人は覚えるスピードが早く、そうでない人は遅い。
何かを理解することも頭のいい人は早いだけだ。
努力せよ。人生かけて一つのことに集中すれば、道は究められる。
仕事では全くのゼロから自分で生み出すということはあまり見ない。
システム屋であれば技術マニュアルとか、過去に誰かがやったこととか、似たような事例を多少アレンジしたりすることがほとんどだ。
極論、システム屋は何も生み出さない。
ロジックにしてももともと用意されているものだ。その組み合わせを作って書いているに過ぎない。
覚えることは大事。ないがしろにしてはならない。
引き出しに入っているものが少ないと取り出せるものも少ないからだ。
覚えること、詰め込みは実は極めて大事であり、全ての基礎となることなのだ。
故に、「学校の勉強ができるからと言って仕事ができるとは限らない」というのは３分の１しか当たっていない。
仕事の課題も学校の勉強と同じようなやり方でクリアできるからである。
覚えて、使うだけだ。その証拠に、知らないことはできない。
ただ、学校では覚える内容自体が限定されているが、仕事では自ら探して取りに行かなければならない。
最初のうちは教えてもらえるものの、会社で一番になると教えてくれる人はいなくなる。その状況を学校では教えない。
オベンキョーはできるのに仕事はできないと言われる人は、与えられるまで待っていることに慣れすぎて、いつまで経っても学生から社会人に脱皮できないのだ。
残りの３分の１はトップランナーだ。
学校の勉強は役に立たない。前例が無いからだ。ただ踏み台にはなる。
世の中に無い新しいものを生み出す力は学校では養われない。むしろ嫌われ潰される。
教授という職業だけが学校内で生み出すことを許されている。
教科書の中身は社会に出てからの基礎知識ですらない。
なのになぜ勉強するのか。
教科書というはあくまで過去の知識であり、政治的なものであって、真に身につけるべきは表面的な知識ではないのだ。
小学校から高校までの教科書を積み上げて、全てを理解するだけのことに12年は長すぎる。（という人もいる）
- S.T. -