コメント代わりとして、「効率化」について語る

2010/01/15 17:00:00

 しばらくとっても忙しいので、コメントが返せずすみません。遅れて返すとおかしくなりそうなので、コメント代わりに書かせていただきます。

 基本的にIT技術者というのは、効率のために存在しています。顧客は人間がやるよりも、コンピュータシステムでやる方が効率的だから、コンピュータシステムを導入するわけです。

 「効率化すること」は最も重要な大原則です。「効率だけじゃない」と思う人もいるかもしれませんが、+αはいくらあっても良いので「だけじゃない」は正しいけれど、+αで効率を置き換えれると思うなら、顧客が見えてないでしょう。

 例えばWeb(HP)であっても同じです。会社案内を配って歩いたり、TVでCFを流すよりも、24時間世界中に営業できることになり効率的なので採用されるわけです。

 RDBMSを使う限りSQLを使うことが最も効率的です。最もコーディング量が少なく、最も単純な言語で、パフォーマンスも出ます。

  • できる人にとっては、開発・保守効率も高くなります
  • できない人がいると、開発・保守効率も低くなります

 できない人にとって、効率が下がるのはSQLやプログラミング言語に限らず何でも同じです。

 例えば、わたしがコの業界に入る前にいた会社は、年商20億ぐらいの会社でしたが、経理部長はそろばんを使っていて、全部の書類が手書きで、荷札なんて上得意分はガリ版印刷でした(荷札にぴったりのサイズのガリ版、どこで売ってるのか不思議でした。特注だったのかな? 懐かしいな~)。

 社長以下、幹部の全員がコンピュータは使えませんから否定的というか……。コンピュータを導入して欲しいと、家のPCで提案書を書いていったら、「社内の文章なのになんで清書してくるのか!!」って2時間も怒鳴り続けられるぐらい理不尽なところでした。社長なりに大変効率にこだわる方で、その社長にとってはPCで文字を打つのは手書きの何倍も(というか無限大に)大変なことなのです。

 PCで文字が打てる人が「手書きのよさ」を訴えるのと、PCで文字が打てないから「手書きがよい」というのは、根本的に意味が違います。SQLも同じで、できない人が非効率だ、自分ができるモノが効率的だ。といったところで、それは片方ができないから正しい評価ができていないだけの話です。

 できない人には、できないことはすべて非効率で、できないことを肯定するとそこから先は議論にはならない。

 逆に、PCで文字を打てる人が「手書きのよさ」を訴えその方が良いときもあります。例えば、DMのレスポンスなどは、手書きと印刷されたモノで極端な差が出ます。それをもって「ほら、効率じゃない」って思った人は間違っています。

    掛かるコスト ÷ レスポンス数 = 1件のコスト

 で判断します。つまり「手書きのよさ」で選んでいるのではなく、悲しいかな、あくまでも効率で選ぶのがビジネスです。もっとも、非効率さを無視できるときは好みを出してもよいですし、ビジネスが関係ないお付き合いには、手書きだろうが、携帯メールだろうが、耳元でささやこうが、好きにしたらよいのですが、「効率が悪くてもよい」と思ってSIerに頼む顧客はいないので、IT技術者はあくまでも効率にこだわる必要があります。

 ですから、もし、「手書きの方が効率がよい」と判断したら、手書きの提案をしなければいけません。ちなみに(成約金額にもよりますが)、1000枚までなら確実に手書きの方が効率がよいです。枚数が少ないというのは厳選されたリストで、高額商品のはずで手書きの効果は高い。1000枚を超えるなら、その人の筆跡を再現する「オリジナル手書きフォント」を作る提案をする。というのがIT技術者の仕事です。

 何度も書いているけれど、「初級シスアド」は顧客がメンテナンスをしたり、SIerに依頼するために最低限必要な知識を持っていることを証明する試験です。高校生でも毎年数千人が通るぐらい簡単で、日本のIT関連の資格で最も有資格者が多い、一般的で入門レベルとされている資格です。その「初級シスアドレベルぐらい出来て当たり前」という、極めて単純で当たり前の意見に対して、堂々と「できなくてもプロだ!」という人が出るのは、情けないことだとは思いませんか?

 そういう人が出るのは、医者と看護士の話を書きましたが、看護士の世界では「注射器は使いまわしてはいけない」とすでに常識になっているのに、経験を積んだ医者の方が「注射器は使いまわして当たり前」といってるのと同じです。

 数多くの初心者が初級シスアドを取るためにいったんは勉強していますから、それを伸ばすように教育すればいいのに、この業界で仕事をしている既得権者が上から潰すから、おかしな業界になってしまうのです。

 繰り返しますけれど、初級シスアドは日本のIT関連の資格で最も有資格者が多い、一般的で入門レベルとされている資格で、初心者の多くは、いったんは「現役のプロができないレベル」まで教育されているのです。その教育が終わった直後に、既得権者が上から潰すという馬鹿なことを繰り返しているから、結果的にできない人が増えることになり、「保守できなくなる」という主張をする人が出ます。

 http://www.jitec.jp/1_11seido/h13/ad.html 役割と期待する技術水準を見て、未経験の高校生も取ってきたという現実を見れば、「保守できなくなる」とプロの側がいうことが、どれほど戯けたことか分かると思うけれど……。

 できない人が多いというのは現実ではありますが、いったん、教育を受けても現場で使わなければすぐに忘れるのは当たり前の話。上から潰さずにそのまま現場で使えるようにすれば、それが一番効率的なのは明らかです。ですから、「上から潰すな」と何度も主張しているのですけどね。

 一部に成功しているプロジェクト、会社(エンドユーザー)があるのはコメント欄を見れば分かると思いますし、逆に舵を切っている会社が多いというのが現実だということも分かります。

 現実であっても、くどいですけれど初級シスアドレベル(高校生レベル)を否定したら、プロとして常識的におかしい。顧客が気づいたら言い訳できないですよ。

 「できるけれど使わない」と「できない」は根本的に意味が違います。

◇    ◇    ◇    ◇

 効率には、短期的な効率と、長期的な効率があります。

 できる人が少ない手法を採用すると短期的には教育コストが大きくなりますから、短期的な効率を追い求めたらメンツが揃い易いO/Rマッパーを使った方針の方が楽で、安くできるかもしれません。わたしよりもっと長期的な効率を考える人は、RDBMS以外のモノを作ろうとするでしょう。

 どの時点の効率にフォーカスするかは、経営者の判断であり、自身のキャリアパスを考える各人の判断です。

 反対意見が非常に多いというのは、O/Rマッパー「&Javaなどの言語」というのは非常に習得し易いモノなのでしょう。であるなら、SQLができない人がいるということを認めると、O/Rマッパーにシフトした方が確かに効率的です。

 ただし、そちらにシフトするということは、より習得し易い? 単純作業に近い方にシフトしているということです。ここを読んでいる人の多くは、普通の人よりも技術者として高い好奇心を持った人達で、そのような人達がそちらへシフトするのはわたしは悲しく思っています。

 単純作業化されたモノは、若い人や海外の人が競合相手になります。実際になってますし、オフショアするにはO/RマッパーやFWは必須でしょう。しかし、SQLの部分は海外に持って行かれる確率が少ないのも事実です。複雑なSQLになる部分は、ほぼ同じ内容の仕様書が必要で、こっちで書いた方が早かったり。

 競合相手に負けた人を残すのは、すなわち勝った人を見捨てるという不合理になりますのでできません。となると、若い人や海外の人と競合して勝ち続ける必要が出てくる。わたしは、そんな不毛な戦いは避けたいし、特化したいので(ベンチャーなら当然ですね)バカと言われようと「逆張り」するだけの話です。

 経営者としては、無理をせずにリスクの少ない方を選ぶべきですから、技術者がO/Rマッパーの方を向くならそれで短期に儲けた方が良いのです。今のような苦労もない(苦笑)。

 それでも、わたしはもう少し先を見たい「夢見る僕ちゃん」なわけで、わたしは経営者として、人間として、技術者を使い捨てにはしたくはないから、「できるようになれ!」って警告はしますけれど、無視した人がどうなっても、わたしとしてはそれ以上どうしようもない。

 将来、どちらに転ぶかは神のみぞ知る。

 わたしはVB4の頃からSQLにこだわってきたお陰で、少ないコストで生き残って来ました。逆に舵を切った人も多かったけれど、そちらの人達が今どうなっているかは想像できると思います。その経験からも、今の状況を見ても(会社を立ち上げるならもっとリスクのない方法を採るべきですが)、SQLの方が有利と予想しています。SQLができる人は虐げられているので、同時に経験していますから、どっちもできるようになります。どっちにに転んでもSQLを選んできた人は(安易に逃げなかったってことですから)生き残ると思います。

◇    ◇    ◇    ◇

 ちなみに、SQLが難しいのは業務知識と直結することです。他の言語は積み上げて徐々に考えるのですが、SQLは「基本設計 = プログラム」となるため、業務知識がないとできない。わたしも、SQLと業務知識を同時に教える方法が分からない。これがわたしの最大の悩みです。

 SQL自体は若い人でも十分こなせるのですが、業務知識がないために任せきれない。

 業務知識を持っているほとんどの人は、話をした瞬間にループのイメージができていて、優秀な人ほどそのイメージが完璧なので簡単には崩れない。

 ですからこそ、業務知識を完璧に持っていて、今までコーディング経験がない顧客自身がコーディングする内製化に向いています。

 SQLは本当に簡単なのです。

内製化のススメ

2009/12/24 18:45:00

 「SIerが書いてどうすんだ~?」なお題ですね。

 会社にとって、コンピュータシステムなしでは会社は動かない世の中になってきました。ビジネスの変化に合わせて情報システムの変更を素早く行うことは、企業の生命線を握るような時代になってきています。そんな中、SIerに依頼してコミュニケーションギャップなどの問題を起こすよりも、自分たちが本当に欲しいモノを自分たちの手で作る。つまり、内製化する方が低コストに良いモノが作れるようになってきました。

 まったくもって自己否定するような内容ですが、そんなわけで内製化のススメです。

 主に基幹系・情報系システムの話ですので、コンシューマを相手にするWebサイトを自社内で作りたいというのは似てますが、また別の考え方が必要です(デザインとコンセプトの重要性が増します)。別の機会に書こうかと考えていますが、「クラウド」は基幹系・情報系の仕事には不向きです。それらは用途が違うので別モノとして考えてください。

◇    ◇    ◇    ◇

 システム開発について、現状、SIerに依頼すると、ほぼ上流工程・下流工程という分け方での分業体制を考えてきます。これはウォーターフォールを前提にしており、内製化には向かない考え方です。この分け方に従っていると、内製化はよほどマンパワーに余裕がないと難しいので、まず、ざっくり役割を5つに分けましょう。

  • グランドデザイン(コンセプト)の担当
  • プロジェクトマネージメントの担当
  • ユーザインターフェイスの担当
  • 内部処理の担当
  • ハード・インフラの担当

 ここで、内製化を諦めた方がコストが明らかに下がるのは「ハード・インフラ」部分です。特に中小企業などで情報システムに係わっている人はPCに詳しい人が多く、「自前でサーバを用意しよう」、「俺たちでできる!」となりがちですが、最終的には高くついてしまいます。趣味を仕事に持ち込むべきではありません。

 微妙なのが、グランドデザインの部分です。

 内製化を目指す以上、自分達でやるべきですが、ここでは相談する人を確保しておいた方が良いでしょう。規模に応じてスポット対応のコンサルを入れた方が良いかも知れません。

 プロジェクトマネージメントについては、内製化をする以上、自分たちでやる必要があります。ここは腹を括るしかないでしょう。

◇    ◇    ◇    ◇

 メインとなる開発部分ですが、内製化するわけですから、何らかのプログラミングスキルは必要になります。

 そこで、情報システム部として付けるべき技術を取捨選択しましょう。情報システム部はプロフェッショナルであってもプロフィットセンターではありませんから、技術の取得のためにコストを掛けても、それを回収することはできません。ですから、コストを抑えることが非常に重要で、選択と集中が必要になります。

 つまり、内製化する範囲をユーザインターフェイスの部分にするか、内部処理の部分にするか切り分けるわけです。

 既に、ある程度プログラミングができるなら、どの分野が得意か考えましょう。

 VBなら、Javaならできる、というのであれば、ユーザインタフェイスを中心に置きます。

 SQLならできるというのであれば、内部処理を中心に置きます。
   ※ COBOL・RPGならというのは割愛させていただきます。

 現在、プログラミングできるモノがないというのであれば、単純に、SIerに注文を出さずに修正できたら良いと思うのは、以下のどちらかと考えれば良いです。

  • 画面の動きや見た目
  • 帳票の集計の切り口を変えたり、CSVを出力したい

 前者ならVBやJavaになり、後者ならSQLになります。現在、プログラミングスキルがないのであれば、もちろん、お勧めはSQLです。

 その理由は、VBやJavaなどよりも息が長く、スキルチェンジまでの期間を長く取れること。情報システム部は、一度きりのアドホックな依頼を受けることが多いですが、その対応にもSQLの方が向きますので、教育費を考えたときに費用対効果が高いです。

 ここでも何度か論争になっていますが、VBやJavaなどの言語と、SQLはまったく違うスキルで、プログラミングスキルとして、通常は、アルゴリズムから入るので、アルゴリズムの存在しないSQLは毛嫌いされ論争になるわけですが、プロフィットセンターではない情報システム部がまったく違う2つのスキルを追い求めるのは無理があります。

 片方が完璧にできるようになるまで、もう片一方はいったん諦めることです。

 フォーカスするところを決めたら、その技術のスキルを集積します(当たり前)、繰り返しますが「遅れた技術」とか、そんな雑音に負けていろんな技術に浮気しないことです。浮気しても掛けたコストは取り返すことはできませんし、今や少々遅れた技術でもハードが十分カバーしてくれます。

◇    ◇    ◇    ◇

 いずれか一方のスキルをつければ、足りない技術部分を外に求めることになりますが、ここで重要になるのは、責任範囲を明確にすることです。プロジェクトマネージメントを社内で行う以上、最終的な責任は情報システム部が負うことになりますが、それでも、責任範囲が不明確では外注に出せません。

 内製化する部分を、ユーザインターフェイスを選択した場合も、内部処理を選択した場合も、それぞれの技術の接合部分はストアドプロシージャにするのがよいでしょう。それによって、完全に別立てで開発が可能になり、お互いに依存せず単体テストができますので、責任範囲を明確にすることができます。他のモノで完全に分けようとすると、分けるためのコストが掛かり、結局、高くつくことになります。

 ストアドプロシージャはプロシージャ(手続き)型の記述もできますが、SQLをラップしてストアー(保存)するのが目的です。くれぐれもワークテーブルを作ってCOBOLのような処理をするために使わない。外注するときも、この点はくれぐれも強調して依頼するようにします。

 外注する先は、インターネットで探すことができます。

 上流工程を担当する大手SIerはコーディングしないことが多く、一番金を取れるところなので、大手のプロパーになることが多い。実際にプログラミングをしている人達は、商流の何段か下の派遣の人が多いわけです。そう考えると、プログラミングまでできるようになった情報システム部の方々は、少なくとも自社のシステムにおいては、大手のプロパー(上流技術者)より遙かにできる人になっています。

 上流技術者は傘下の技術者をアサインして指示しているだけですから、情報システム部の方々が、最下層にいる人達に直接アプローチすれば、すぐにでも上流技術者ととって変われます。コスト的にも中抜きができて下がります。現状では、プログラミングをしたことがない上流技術者に情報システム部が要望を伝えて、情報システム部とは会ったこともない人がプログラミングしているなんてことが実際に起こっていますが、そういったコミュニケーションギャップも最小限に留められます。

 上流、下流と分けると、下流をさらに別の会社に頼むことが多く、きっちり仕様を固めないと前に進みませんが、仕様を固めるために非常に時間がかかり、SIerとしても後戻りは非常にコストがかかるため、何かあれば「仕様変更!」と言うための予防線を張らざるを得ません。そういった後ろ向きの工数が大量に掛かり、コストに跳ね返ってくる。

 どちらか一方の技術を持ち内製化することにより、各工程の無駄を最大限に削ることが可能となります。片方ができるようになれば、驚くほどシステム開発費が抑えられることに気づくと思います。

 ユーザー企業から声が掛かって断る中小企業はありません。相見積りを取れば相場も簡単に分かるでしょう。昔は、技術者を集めるのにもいろんなノウハウが必要でしたが、現在はインターネットを使えば簡単に集められます。

 将来、完全内製化を目指すなら、一般派遣をやっている会社(パソナとかインテリジェンスとか)に紹介予定派遣をお願いすればいい。実作業をやって貰いながら相性を確認してから正社員として登用すれば、足りない方の技術をすぐに補うことができます。

 もちろん、社内SEの数は、普段の運用と改修に必要な人員数になりますから、大規模な新規開発や、システム改修が行われるときには追加で外注する必要がありますが、普段から開発も行っていれば、SIerの力量も見抜くことができます。情報システム部がマネージメントしながら外注することができれば、大規模開発になってもコストを大幅に抑えることができます。

 基本内製化、足りない部分をSIerが補う。とんでもないことを言ってるようですが、そうなっても、弊社は全然困らないというか大歓迎ですけどね。上流工程が一番儲かると考えて、技術を軽視してきた大手SIerは、そうなったら大変でしょうね……。

◇    ◇    ◇    ◇

 1月23日(土)24日(日)に大阪で「SQLのセミナー」を開くことになりました。内製化したいというエンドユーザー様もぜひご参加ください。呼んでいただければオンサイトでもやりますよ(笑)。

 よろしくお願いいたします。

◇    ◇    ◇    ◇

 今年は、多分これで終わりです。

 たくさんアクセスをしていただき、たくさんコメントいただきありがとうございました。良いお年をお迎えください。

白熱(炎上)したのでまとめ。

2009/12/16 18:05:00

 不本意にも、一部のコメントを非表示にせざるを得ないほどの状態になったのは本当に残念ですが、白熱(炎上)したのでまとめ。

 前の記事はこの辺です。

 常識のライン

 テレビのリモコンを孫の手で押すなって!

 オブジェクト指向言語で処理したら保守性が悪い!

 自分で書いた1年前のモノも読み直してみると、これらとほとんど同じことを延々書いている。まぁ、10年前から同じことを言ってるし、成長がないな~。

 一応、なぜ炎上したかというと、そもそもの「常識のライン」が合わない人がやってきたためです。初級シスアドというのは毎年1000人以上の高校生(高専や専門学校を入れたら10代の合格者は毎年数千人)が合格してきたぐらいのレベルの試験です。高校時代に合格するのは相当に努力とセンスが必要でしょうが、合格したら即プロというレベルでもない。

 そんな「初級シスアドレベル(以下)でも自分はプロだ」と言い切る人が出現したのが、炎上のきっかけです。

 ■ 反対派の意見

 (RDBMSは使っているのに)SQLはできなくてもシステムは組めるからプロだ。でも、「複雑で遅いときにはSQLを使う

※ 特に、こういうことをいう人の「遅いときにはSQL」のSQLは 素人レベルですから、とても読めたモノではない。これが混じると本当に保守できなくなるのですけどね……。

 ■ わたしの意見

 RDBMSを使うならばSQLを使わないと無駄が多い。スキルを身に付ければ最終的には、コーディング量 = 工数(保守性)となっていくので、少ないコーディング量ですむSQLの方が工数・保守性ともにメリットがある

◇    ◇    ◇    ◇

 2つの意見のうち、そもそも、「システムが組める」と「メリットがある」は、まったく争点が違いますね。

 後者は「どちらにメリットがあるか」、つまり、「どっちを選ぶべきか」ということを議題としているのですが、前者は「できるできない」に矮小化されています。さらに、その業界を志す高校生に自分の飯の種で負けても自分はプロであると堂々という人間が出るなんて……、100年に1人の天才石川遼選手に負けるのとはわけが違う。他所の業界ではあり得ないでしょう。

 初級シスアドって、合格率や合格者数から考えると、簿記2級かちょっと上ぐらいの難易度かな。つまり、「なんでSQL」というのは、「なんで複式簿記」というのと同じです。

 単式簿記はお小遣い帳と同じだから理解しやすいけれど、経理部に配属になって「仕訳なんてややこしいことしなくても、単式簿記でできるじゃないですか」というような、「できるできない」の議論はあり得ない。我々システム屋さんは、誰でも仕訳ができるように経理システムを作っている立場ではありますが、それでも経理部員が仕訳を分からないようでは仕事になりませんので、これは議論ではなく強制(矯正)でしょう。

 わたしの常識では、初級シスアドレベルはプロではないから、そのレベルの人にSQLについて必要なのは議論ではなく強制(矯正)です。つまり、「石に齧り付いてもスキルを身に付けるか、違う業界へ転職するかしろ!」です。

 世の中の常識に照らせば、けっして厳しい意見ではないと思います。

 しかし、業界としてそのレベルで公に反対できるほど「できなくてもよい」が常識になっています。そして高校生に負ける部分を覆い隠すために、テレビのリモコンを押すための孫の手を一生懸命作ってるのですから……本当に馬鹿げている。

 そんな馬鹿げたことが業界の常識として通用する以上、業界の内部では変えようがないので、「お客様なんとか変えてください」という情けないお願いでもあります。凝り固まった人を説得するのは外圧でないと無理です。プロを説得したいと思って書いたモノではなく、お客様はあまり見てないかもしれませんが、お客様の目に触れたらよいなと思っています。

 業界外の皆様(お客様方)、IT技術者として顧客にまで求めてきた必須といえるスキルが「わたしは高校生に負けるほどSQLは素人レベルです」と前置きすべき人達に、60~400万/人月ぐらい支払っていることに早く気づいてくださいね。

 実際問題、評価基準がユーザーにはわかりにくいから、そんな詐欺師に大金を払わざるを得なかったわけですが……、高校生も取得してきた国家試験レベルを持ち出して交渉したら、一律xx%下げてくれなんて理不尽な値引き交渉をしなくても、技術力に応じた、当たり前の交渉で一律xx%以上の値引き交渉が簡単にできますよ。お客様にいわれたら、プロとしてグウの音も出ません。

 この不況で、どうせリストラは必要なのです。ぜひ業界に巣くった詐欺師を淘汰してください。大手の数社がやってくれれば、業界はすぐに正常化できると思います。

 違う意見は重要ですけれど、素人レベルのできない人の意見というのは言い訳でしかないので、そんなものを聞いても仕方がありません。もちろん、「やったらできる」なんて意見にも、何の意味もありませんので、そのような類のコメントはよそでやってください。

◇    ◇    ◇    ◇

 なぜ業界としてそんな事態になるかというと、「SQLを鍛えたらいいじゃないか」ということになって、実際に教育が実行されることもあったのですが、マネージャやリーダーに「SQL講座に行ってこい」と誰もいえないから、通常は残念ながら鍛える対象者が新人とか若手になります。そして、せっかく鍛えてきた人たちを、上の人間ができないために無意識でいい放った、たった一言で潰してしまいます。

 自分で潰しているのに、「鍛えてもダメだった」という結論を持っている人も多いわけです。

 その証拠に、新人に初級シスアドの取得を推奨(半ば義務づけ)しているような会社でも、納品物は初級シスアド以下になることが普通にあります。上に立つ人間が、初級シスアドに満たない技術力で設計しているので、下の人間は使いようがないのです。そして、自分で潰しているということに気づくスキルもないのですから、どうしようもありません。

 部下に複式簿記を勉強させても、単式簿記でやるように指示してたら何の意味もないですよね。つまり、上に立つ人間ができなければ何の意味もないのです。

 何度も書いているとおり、初級シスアドなんて高校生でも取ってるぐらいのものです。RDBMSは、高校生にとって他の言語を扱うよりも環境面などで遙かにハードルは高いのですが、それでも習得可能なぐらいSQLは簡単です。開発現場では、RDBMSはすぐに手の届くところにいくらでもあるのですから、上から潰さなかったら何の問題もなく習得できるはずです。

 最低限、上から潰さない程度に、上流技術者が、せめて初級シスアドをもう少し超えるレベルにSQLを習得する必要があるでしょう。

◇    ◇    ◇    ◇

 おまけ。

 自分のプロジェクトは複数のDBベンダに対応する必要があるとか、Web系の仕事をされている方々によく絡まれます。文章をちゃんと読めば分かりますが、条件が違うならプロなんだから自分で判断すればいい。わたしは散々書いてきているのでいちいち前置きはしない。過去のを読んでください。

 Web系にもイロイロな仕組みがあります。弊社は静的なHTMLだけの仕事までやりますし、EC-CUBEなどのカスタマイズも手がけています。わたしも起業したきっかけは、http://el.jibun.atmarkit.co.jp/g1sys/2009/07/post-e118.html のように業務システムとはまったく関係ないことで、Web系システムが嫌いかというと、むしろそちらの方がやりたいことであったりもします(基幹システムをWeb系で作るのは大嫌いですが)。そのような仕事しかやらない人達は、自分たちはメインストリームにいるつもりかもしれません。

 しかし、(コンシューマ向けの)Web系は増えてはいますけれど、まだまだ、割合から見ても決してメインじゃないのですよ。日本の上場企業は約4000社ありますが、Web系(広告費除く)のシステムに投下した資本と、基幹システム、情報系システムなどなどに投下した資本って、今後も逆転するという会社はほとんどないし、中小企業に至ってはさらに顕著です。

 そんなマイナーな話をしても仕方がない。ですから、マイナーな人はご自身で判断してください。

 例えば、Yahooのようなポータルサイトを手がける会社にしても、人事システムも、物流に関するシステムも、経理システムも必要です。そういう業務には圧倒的にRDBMSを使った仕組みが現状では向いています。そういう分野のためにほとんどの企業でRDBMSはすでに導入済みですから、そう簡単にはSQLの需要というのはなくならないのです。

 どちらが汎用的で息が長い技術かは、よく考えた方がよいと思います。

 O/Rマッパーのようなもので覆い隠すようなモノにまったく価値はない。O/Rマッパーは、それなりのセンスがあれば、コメント欄でも書いていらっしゃる方があるとおり、言語を覚えたての頃に一回は企画するレベルのものです。かくいうわたしも企画はしましたから使いたくなる気持ちも若干は分かっています。そんなモノは麻疹(はしか)みたいなものです。まっとうなスキルをつけてSQLの意味が分かれば、O/Rマッパーなど、孫の手の開発でしかないと分かり、麻疹の時期は去っていきます。

 当たり前の話ですが、SQLは現在流通している中では、最も人間に近い高水準言語で、それを低水準言語でラップしても意味がない。

 SQLをやらない人にとっては、何が当たり前で、どう高水準かも分からないでしょうけれど、それが分かるまでに必要なのは議論じゃなくて勉強ですよ。

 それでも、これだけ一般的に使われているモノを拒否する気概があるなら、それはそれで立派なものですが、「SQLを使わない」ではなく、「RDBMSを使わない」とならないと意味がないのです。O/Rマッパーのような孫の手を目指すよりも(作るのではなく使うって……)、テレビそのものであるRDBMSに代わるものを開発すべきでしょう。それが技術者ってものです。

 もちろん、別のモノを開発するほどSQLに不便を感じないので、わたしにはそんなモチベーションは生まれないけどね。

「ググれよ! タイプ」と「ググるな! タイプ」

2009/12/10 18:05:00

 前の続き

 上から目線ですまないけれど、イロイロと考えさせられたので、もったいないから書いておこうと思う。新人は「ググれよ!」がよいタイプと「ググるな!」がよいタイプがいるなと思い至りました。ので、そのことについて。

 若者が常識を知らないというのは当たり前なのです。いつの時代も「最近の若者は……」と言われてきました。

 「在庫」を知らない、というのはかなりヤバいというか、わたしらの時代なら、「幼稚園からやり直せ~ぇ!」っていわれてたと思う。ただ、若いうちはそういうことがあっても良いのです。笑われるのも、叱られるのも仕事のうちです。

 というわけで適切な例かは分かりませんが、「在庫ってなんですか?」というレベルで笑われたとしましょう。常識を知らなければ笑われて当たり前でしょう。それは笑った方が悪いのではない、笑われた方が悪いのです。

 そこで、「笑われた(叱られた)こと」が気になるか、「笑われる(叱られる)ようなことを知らなかった」ことが気になるかに最初の分かれ目がある。

 前者は、ただただ、不快になり周りに恨みを持って終わりです。ですから、次の打ち合わせで「棚卸しってなんですか?」って聞くかも知れませんし、笑われるから質問をしなくなるかもしれません。

 「棚卸しってなんですか?」って聞いてしまう人は、本人は同じことを2回聞いたつもりはないけれど、周りは「常識の範囲で同じことを2回も聞いた」と受け取るから(これ解説イランよね?)、周りとっては最高に「空気読めてない感」を醸し出していることになる。下手をすると「何かあれば解雇」フラグが立ってしまいます。もちろん、質問をしなくなるタイプは周りとズルズル差がつくでしょう。

 一方、後者は「在庫」について調べるでしょう。当然、関連する知識、入庫、出庫、棚卸しなども同時に調べるでしょう。場合によっては「トヨタのカンバン方式」にたどり着くかも知れません。「男子三日会わざれば刮目して見よ」というタイプですね。

 わたしは、「在庫ってなんですか?」って言うヤツを笑い飛ばして、3日後に「今回のお客さんは、なんでカンバン方式じゃないんですか?」って、これまた空気の読めないことをいってくるような変化がないかと待ってます。そんなかわいいヤツを見つけたいのです。

 そういうタイプは、若いうちは、机上と現実の摺り合わせがうまくいかなかったりする困ったチャンが多いけれど、伸びシロは多く、笑われた(叱られた)ことを苦にしていないから、笑われながら、机上の理論と現実を早く摺り合わせることができるし、見る見る間に成長します。

 そういうのは、漫画の世界にしかいないかというと、タマにいます。まぁ、かくいうわたしもそういう「空気読めない君」でした。

 わたしは、自分が知らないことで、笑われたり、叱られたりしたら、なぜ、そんなことも自分は知らなかったんだろう。早く知りたい、もっと知りたいって思うのです。

 ところが、聞けない人はこんな感じ。

 天秤の左に乗っているのは、

  • 忙しい上司に聞きにくい
  • また叱られたらどうしよう
  • 教えるのは上司の仕事
  • 聞くのはプライドが……

 天秤の右に乗っているのは、

  • 仕事だから早く終わらせるためには聞くべき。
  • 調べるより聞く方が楽かな?

 右に傾けば聞くし、左に傾けば聞かない。

 わたしのようなタイプはこんな感じ。

 天秤の左に乗っているのは、

  • 忙しい上司に聞きにくい

 天秤の右に乗っているのは、

  • 仕事だから早く終わらせるためには聞くべき
  • 笑われるほどの常識なら教えて欲しい
  • とにかく知りたい

 「とにかく知りたい」がかなり大きいから、大抵は右に傾いて「聞きに行こう」という行動になる。

 「とにかく知りたい」という知的好奇心が大きい人は強いのです。

 とにかく知りたいわけですから、その最短距離がググることだと思えばググるし、上司に聞くことだと思えば聞きます。「知的好奇心を満たしたい」という欲求で動くタイプは、それがやりたくて仕方がないのですから、少々の障害は乗り越えられます。「聞けない雰囲気」よりも、「相手の都合」よりも、「聞きたい」という衝動が勝るのです。

 ところが、仕事の責任感であったり、新人としての焦り、そいう感情が大きい人は「上司の『聞けない雰囲気』に問題がある。だって、教えるのは上司の仕事だもの」ってなってしまいます。

 知的好奇心、つまり、知りたい欲求は誰にでもあるのですが、あまりに小さかったり、仕事以外(趣味など)でしか発揮できない人が非常に増えていると感じています。知的(?)好奇心がアニメや、ゲームにはしっかり向かうけれど、仕事にはまったく向かわないなんて人も見かけるからね。

 知的好奇心が大きい人(仕事に向かう人)は、テレビを見ても、新聞を読んでも、地下鉄の中吊りを見ても、漫画を読んでも、感じ取るモノが多い。そういう知的好奇心が強いタイプは、ググると良いと思います。なぜなら、ググるという行為はプル型(自発型)だから。好奇心と相乗効果が出ますし、昔より調べやすい分伸びも早いです。

 逆に知的好奇心の弱いタイプは、ググるのを禁止にして本を与えたり、セミナーに送り込む方が良いと思う。ググることは、知的好奇心からではなく「コピペしてでも早く仕事をしたことにすればよい」と考えているから、安易なコピペで終わらしてしまいます。

 本やセミナーはそれを選ぶまではプル型(自発型)ですけども、上司が選ぶ場合はプッシュ型(依存型)です。知的好奇心の弱いタイプは、まず、あるラインまでは強制して知識を引きあげるしかない。押し付けられて「できなければヤバい」と思わせないといけないのじゃないかな~。

◇    ◇    ◇    ◇

 それはともかく、厳しい意見ですが、「笑われた(叱られた)こと」が気になるタイプは、知的労働者に向いていないとわたしは考えている。いや、絶望的なことを書くと、知的労働に限らず、知的好奇心が仕事に向かわないタイプは、そもそもその仕事に向いていないのじゃないかと思います。

 何らかの刺激で変わることはありますけれど、どんな刺激で変わるのかは人によって違うので、上司や先輩の行動が適切な刺激を与えてくれるかどうかは運しかありません。大量採用の時代は、教育したり、競わせたり(これが大きかったり)しながら刺激して、(元からか、運良くかは分からないけれど)知的好奇心を仕事に向けながら自律的に成長できる人と、そうでない人に分けることができた。多分、2:8の法則が成り立っていた。つまり、自律的に動ける2割と、動けない8割により分けることができたのだと思います。

 大量採用の時代は歯車的な作業が多かったので、運悪く2割の方に変われなくても、文句を言わず、言われたことをするタイプなら問題なく仕事がありました。むしろ、最初からそういう人を大量に選んでいたところはあるのです。しかし、歯車的な作業を求められてそれをまじめにこなしてきた中高年の方々が、今の不況で大変なことになっているのは、皆さんもご承知の通りです。

 2:8の法則は自然の法則で今も変わらないと思いますが……、何が変わったかというと8割はアウトソースしたり、オフショアしたりという動きが非常に強くなっているということです。

 ですからね。ぶっちゃけ、昔のような教育ではなく、突き放して2割を選別しようと会社は考え始めていると思いますよ。弊社も似たようなものです。

 ゆとり教育だけではなく少子化の影響もあって、まったくといってよいほど競争もせず、揉まれもせずにきた若い人たちには本当に厳しい状態だと思う。しかし、現実だから仕方がない。例えば、派遣問題というのは、まさしく、8割を派遣社員に追いやろうという動きの現れでしょう。

 これは完全に世界的な流れで起きていますから、鳩山首相ががんばっても変わりません。変えるとしたら「解雇のススメ」「(正社員の)減給のススメ」ですが、鳩山首相が率いる民主党政権ではそれはあり得ないでしょう。

 現状のままでは、正社員はさらに狭き門になります。

 大量採用の時代が終わった今、会社が望む人材は自律的に動くタイプ。たとえ、今、「在庫」を知らなくても、次の質問が「棚卸し」でなく、「カンバン方式について」になっているタイプです。

 というわけで、上司の態度がどうであれ聞けないタイプは、自分の内側から来る危機感か何かを刺激にして、自分で変わらないと厳しいのではないかな。会社は社員の労働力を買っていますから、「新人を育てるのは会社の責任だ」ってふんぞり返っている新人君を、会社がどう見ているか考えた方がいいですよ。

 ちなみに、わたしもIT業界に興味がなかったわけではないけれど、やりたかったことではない。しかし、知的好奇心が強かったからやってこれたと思っています。どんな仕事でも、深く知ればそれだけおもしろみは出てきます。知的好奇心が強いかどうかは、おもしろく感じるまでのハードルの高さなんですね。そのハードルを設定しているのはあなた自身です。

 とにかく、今、大量採用時代の常識を持ち出して同じことを求めていると、自分に返ってきます。さらには、大量採用時代より甘い常識を持ち出してくるようでは、先はないですよ。

 弊社の話ではなく一般論ですけど、わたしのように馬鹿な経営者でなければ、きれいごとしか言わないからね……。

オブジェクト指向言語で処理したら保守性が悪い!

2009/12/07 18:05:00

 如何様にも結論づけられる主観的な話になるので、宗教論争にしかならないからあまり書きたくないのですが……。いつも以上に、布教活動というか、独り言みたいなものですので、気楽に読んでいただければ。

 一般的なシステムで、オブジェクト指向言語で処理を記述することと、SQLで処理を記述することについて、「保守性(拡張性)のために」というのが、オブジェクト指向言語で処理を記述することの金科玉条になっていますが、本当にそうでしょうか。

 そもそも、業務システムの保守性とは

 【保守性】

    オブジェクト指向言語 > SQL >> 混在型

が成り立つと、わたしは考えています。

 オブジェクト指向言語推進派の方は、インピーダンスミスマッチをものすごく嫌う(わたしも嫌いですけど)。つまり、オブジェクト指向言語とSQLの相性の悪さは、わたしよりも分かっていると思うのです。ですから、混在しているタイプが一番保守性が悪い。というのは共通認識と思いますが、いかがでしょうか?

 さて、保守性や拡張性が問われるのは、システムの特に複雑な部分でしょう。単純なマスタメンテナンスなど何でやっても同じです。逆に、特に複雑な部分とは、複雑なだけにパフォーマンスが出しにくく、かつ、システムのコアになることが多いので、パフォーマンスの要求が厳しくなりがちです。

 現実問題、オブジェクト指向言語推進派の方も、遅いときはSQLを使うといいますよね。わたしの経験上、システムのコアになる複雑でパフォーマンスの要求が高い部分ほど、オブジェクト指向言語にSQLが入り込む割合が高くなります。

 この場合、わたしのようにSQLで処理したいという人が設計すると、DBサーバでできる処理は、すべてDBサーバで処理しようとします。ただ、複雑な処理ですから初級シスアドレベルではどうしようもないです。

 逆にオブジェクト指向言語推進派の人たちは、オブジェクト指向で1回考えてから、どうしてもパフォーマンスが必要な部分を、できるだけ小さい範囲でSQLにしようとします。初級シスアドレベル(しつこいな)以下の人も存在するわけですから、最初からできる範囲は限られています。つまり、わたしの考える「SQLで処理する」ということとは全く違ったものになっています。

 さらに、ここからは想像ですが……。

 「できるだけ小さい範囲でSQLにしよう」というのは、つまり、混在型になっているわけですが、それで、とりあえず要件を満たせて納品したとしましょう。

 しかし、そのシステムが保守(仕様変更)の対象になったときに、蓋を開けて見れば、混在型ですから、ものすごく保守をしにくい構造になっています(わたしは言語のスパゲッティと呼んでるけれど)。わたしもしょっちゅう遭遇しますが、ホントにどこを触ってよいのか分かりません、全面コメントアウトの誘惑に駆られる。

 その保守を行う人がオブジェクト指向言語が得意な人であった場合、「SQLを使っているから保守性が悪い」と見えるでしょう。その指摘はある意味正しく、わたしの主張と実は同じです。しかし、これが、「SQLを使うと保守性が悪い」と言われる原因のような気がしています。仮に、そうだとしたら言い掛かりでしかないのですが……、違うのかな?

 すべての処理をオブジェクト指向言語だけで書けるなら保守性が上がるでしょうが、その考えを進めようとすると、複雑でコアになる処理で混在型になってしまうことになるから、わたしは、「オブジェクト指向言語で処理したら保守性が悪い!」「SQLで処理した方が保守性は上がる」と考えています。SQLを「複雑な処理」「時間が掛かる処理」などという曖昧な基準で使って、混在型にするべきではないのです。

 工数、パフォーマンスは、できる人に取ってはSQLの方が確実にあがります。つまり、オブジェクト指向言語で、SQLでできる処理を記述するメリットは全くないと考えています。
※ 日付のフォーマット変換とか、表示・UIに関するものはオブジェクト指向言語ですべきですね。

 もう1回書くと、

 【保守性】

    オブジェクト指向言語 > SQL >> 混在型

が成り立つなら、DBサーバで出来る処理は、DBサーバで行うべきです。つまり、SQLで処理すべきです。

 オブジェクト指向言語派の意見は、

 【保守性】

    オブジェクト指向言語 > 混在型 >> SQL

が成り立たないなら間違っています。これは多分に主観の入る式なので、なんとも言えないけれど(じゃあ、いわなきゃいいのに)、下の方の式が成り立つと感じる人は、SQLの技術レベルが著しく低いハズです。SQLは見るのもイヤでしょう?

 いや、多くの人は、

 【保守性】

    オブジェクト指向言語 >> 混在型(= SQLで処理する)

と考えているのかも知れませんね。

 いずれにしても、SQLがちゃんとできない人がどうやって、「SQLで処理するのは良くない」と結論を出しているのか、その判断材料は何なのか、上に書いたことよりも、もっと歪な主観による決めつけが入っているのではないでしょうか?

 多くのプロジェクトでSQLができる人が足りません。ですから、混在型が正しいと思っている人も多いのではないかな。

 オブジェクト指向言語から入った人にとって、SQLのスキルアップの過程は、

   オブジェクト指向言語 → 混在型 → SQLで処理

となり、途中でものすごく非効率な時点を乗り越えなければなりません。乗り越えてない人(初級シスアド前後のレベルの人)が嫌うのは当たり前で、逆に、初級シスアドレベルで混在型になっていることに問題を感じないのも、技術者としてのセンスが足りない。ともかく、乗り越えてないことが、多くの誤解を生む結果になっているのだと思います。(まぁ、憶測ですけどね)

 2、3段ステップアップすれば全く違う景色が見えます。手っ取り早くステップアップしたい方は、ぜひ、セミナーにご参加を。

◇    ◇    ◇    ◇

 これを乗り切るためには、ストアドプロシージャを使って無条件に担当、ロジックを切ってしまうことがよいと考えています。

 例えば、得意先CDと商品CDで、各種マスタとそれまでの購入履歴から、顧客特有の標準価格が決まる処理があったとしましょう。さらに、上得意のお客様にはイロイロと昔からの約束で価格が決まっていて、顧客固有のテーブルが必要で、全部で10個のテーブルを参照するとします(無理がある例ですが、もっと複雑なこともあるので、ここは突っ込まないでね)。

 この条件で、もし単純なO/Rマッパーなどを使うと、テーブル毎の10個のDAOをつくってしまいかねません。しかし、処理はオブジェクト指向言語ですべて書けますから、統一されていて保守はし易いでしょう。テーブル変更も対象のDAOを変更すれば対応できます。その代わり、コーディング量は多く(つまり、工数が掛かり)、標準価格を取得するだけの処理に10回以上DBサーバにアクセスしなければいけません。非常に重い処理になります。

 それはあまりにも無駄なので、ある程度固まりで取れる範囲をSQLにする。これがわたしがいうところの言語のスパゲッティです。「ある程度」は感覚の問題で人によって違うから、非常にメンテしにくい構造になります。テーブル変更があるような仕様変更があったら、手がつけれないことになりかねない。

 ストアドプロシージャにするというのは、オブジェクト指向言語で標準価格を返すメソッドの中身で使うSQLを、

   SELECT fn_標準価格(pra得意先CD, pra商品CD)
   -- FROM DUAL

これだけにすることです。メソッドはパラメータを渡して戻り値を受け取るだけの処理しかさせない。そうすれば、仮に計算に必要なテーブルがもう1つ増えたとしても、オブジェクト指向言語側は何の影響もありません。

 (テーブルの説明が必要ないぐらい)きれいな疎結合になっているでしょう。オブジェクト指向言語側でテーブルの存在など意識する必要はない。オブジェクト指向側でテーブル構造を意識しするから、インピーダンスミスマッチの段差を強く感じることになるのです。

 きれいな疎結合になるからこそ、オブジェクト指向言語側の人たちと担当範囲を分けて、お互いに専門性を持って開発ができるでしょう。

◇    ◇    ◇    ◇

 標準価格は普通はトランザクションに保存(非正規化)しておきますが、導出項目だった場合、特別価格(標準価格以外)で販売した一覧の出力は以下のようになります。(以下も、ストアドプロシージャでラップする、もちろん、ワークテーブルは使用しない)

   SELECT * FROM
     (SELECT
        得意先CD
        , 得意先名
        , 日付
        , 商品CD
        , 商品名
        , fn_標準価格(得意先CD, 商品CD) AS 標準価格
        , 売価
        , 数量
     FROM ……
     WHERE
        日付 BETWEEN pra開始日 AND pra終了日)
   WHERE
     売価 <> 標準価格

 ※ なぜ、WHERE 売価 <> fn_標準価格(得意先コード, 商品コード)
   
としてないか分かりますか?

 標準価格の計算方法が変わっても(こういう変更は結構ありますね)パラメータと戻り値に変更がなければ、他の言語のプロジェクトで使われていても1ヵ所で済みます。

 逆に、非正規化していて、標準価格のロジックに仕様変更があって、過去データを洗い変える必要が出たときは(この例では、あり得ないと思うけれど)

   UPDATE 対象テーブル
   SET 標準価格 = fn_標準価格(得意先CD, 商品CD)
   WHERE 標準価格 <> fn_標準価格(得意先CD, 商品CD)

ですみます。

 これを、オブジェクト指向言語でやろうとするとメチャクチャ時間が掛かるし、この程度で大騒ぎする人もいるからね、あれって営業的に騒いでいるのですかね?本気で言ってるのか疑問に思うことが多い。バレたらかっこわるいというか、思いっきりマイナスに出ると思うけれど……。

 同様に、DBサーバで処理させるように設計を進めていけば、ビジネスロジックの大半はDBサーバに入ります。オブジェクト指向言語が行うのはユーザインターフェースの部分で、DBに関わる部分は完全なブラックボックスとして考える。基準はユーザオペレーションに対して、基本的に1回のDBアクセスで済むように(明細の更新は明細数回送ってもよいと思うけれど)と考えて設計すればよいのです。

 そうすれば勝手にきれいな疎結合に設計できますし、担当者を分ければ専門性を活かして開発でき、さらには、「テーブル設計は実装の後に!」となると、本当に柔軟な開発が可能になります。

 「SQLは嫌だ」いう人が現実的に大勢いる、初級シスアド以下のレベルの人も大勢いるのですから、そういう人にはSQLに関連するところは触らせないで済む。というか、素人レベルの人に触らせるなんて危険でしょう。

 オブジェクト指向言語で処理していればロジックが再利用し易いとか言いますけれど、ちゃんと設計していればストアドプロシージャの方がもっと再利用し易い。例えば、他の言語でバッチ処理を書いても、エクセルマクロでアドホックな帳票を作るにしても、データがRDBMSにある限りロジックの再利用が可能になります。

 企業のシステムにとって、プログラムよりデータ(構造)の方が長生きなのですから、アクセス方法はRDBMSに入っている方が将来性がある。

 とにかく、上の様に考えれば、SQLもストアドプロシージャ(ファンクション)も苦にしない人に取っては、開発工数も下がるし、パフォーマンスも良くなり、保守がしやすいのです。

◇    ◇    ◇    ◇

 コメントいただいて、Google Analytics で約1年分の集計を見てみた。PVはナイショですが、業界の人しか見ていないハズなのに、ユニークユーザーが10万を超えていた(笑)。ユニークかどうかは、Cookieに1ヶ月持っているキーで判別しているから、実際は1、2万でしょうけれど、それならものすごいリピート率だ(笑)

 とにかく、感謝感謝 happy02 です。

 IT業界って70万人ぐらいらしいから7人に1人は見ている計算になる。相当な人たちにはリーチできていると思うのですが、サイレントマジョリティはやっぱり反発してるってことなのでしょうね。

 10万人に嫌われたって、わたしは何ともないけどね。

 何が言いたかったかというと、セミナーの方もよろしく! ってことなのですが、じゃあ嫌われたらダメですね(苦笑)。

常識のライン

2009/11/27 19:00:00

 前回、炎上するかと思ったら何もなくって拍子抜け(笑)。わたしは相当に怖い人と思われているのだろうか? 名刺交換するとき指が震えている人は緊張していたのではなく、脅えてたのかな(苦笑)。

 まず、結論から書くと、ユーザー企業の皆様、不況の昨今、安く速いシステムを早く作ろうとするなら、依頼しているSIerの技術力を測りましょう。業界にはおかしな常識がまかり通っています。その常識を変えるには、ユーザー企業が声を上げるしかありません。

 下のSQLは、初級シスアドの穴埋め問題の穴を埋めただけのものです

  SELECT 
    資格取得履歴表.社員番号,COUNT(*)
  FROM 資格取得履歴表,社員表
  WHERE 資格取得履歴表.資格番号 
    IN (SELECT 前提資格表.資格番号
      FROM 前提資格表
      WHERE 前提資格表.職位番号 ='02'
      )
    AND 資格取得履歴表.社員番号=社員表.社員番号
    AND 社員表.職位番号 ='02'
  GROUP BY 資格取得履歴表.社員番号
  HAVING COUNT(*) >=
       (SELECT 職位表.取得資格数
        FROM 職位表
        WHERE 職位表.職位番号 = '02')

 毎年、この程度は出てた。個人的にはあまりきれいな書き方とも、良問とも思ってないけど、取って付けた感じになってもHAVINGでサブクエリーを使いたかったようです。しかし、抽象化した問題を作るのは大変難しいのでその辺を許すとすると、単純にレベル感は分かる。

 ユーザー企業の皆様、担当者の技術力を測るなら、「弊社の入社試験にチャレンジして!(3)」の10問目が5~10分でできる程度で、初級シスアドよりちょっと上ぐらいです。

 初級シスアドというのは以下のような技術水準を設定しているそうです。

 利用者側において、担当する業務の情報化を利用者の立場から推進するため、次の知識・技能が要求される。

  1. 仕事の進め方を把握し改善策を考えるためのシステム思考能力、それを支えるDFD、ワークフローなどの手法やコンピュータの活用法に関する知識をもつ。
  2. 情報システムの開発・利用について、ヒューマンインタフェイス設計、テスト及びシステム運用に関する知識・技能をもつ。
  3. パソコンやネットワークに関する基礎知識をもつ。
  4. 業務において表計算ソフトやデータベースソフトなどのツールを操作・活用できる。
  5. パソコン導入・運用・管理における実務的な知識・技能をもつ。
  6. パソコンの様々な使い方やパソコン利用環境・オフィス環境に関する知識をもつ。
  7. 情報化推進のための話し方・文書の書き方・ビジュアル表現方法に関する知識をもつ。

 「利用者側において」、つまりユーザー(素人)のための国家資格です。

 わたしは初級シスアドのことを英検で言えば2級ぐらいの難易度と考えていますが、もっと遙かに高いレベルの試験だったのか?

 初級シスアドって、高校生でも持っている人がいるぐらい、ベンダ試験も含めても、もっとも取得者の多い一般的な資格じゃないのか?

 SQLは、実際の現場で極めて広範囲に使われている技術ではないのか?

 それを常識とするわたしは間違っているのか?

 そんなわけないでしょう。コンサルだから……、PMだから……、SEだから……、コーディングなんて……、すべて関係ないでしょう。

 ユーザーで穴埋め問題ですから、最低限読めて、多少は書けるレベルです。業界としてユーザに求めた技術レベルがそれなのですから、プロを名乗る全員ができなければ、業界としておかしいでしょう

 「この程度ができない」が許されるのは2年生まででは? 2年生を超えてできないのはプロとしてあるまじきことではないのか?

◇    ◇    ◇    ◇

 現実問題として初級シスアドレベルのものすらできない人が、マネージャだったり、リーダーだったりすることは珍しくありません。乃木大将のような神になっている場合もあって、その人のやり方が社内標準ってことも起こりうる。というか、特に大手ではほとんどそうじゃないかと思う。

 上流でそんなこと関係ないと思うかも知れませんが、SQLができない人は逆に他の(手続き型)言語はできるのです。優秀な人ほど顧客との会話の段階で脳内で設計を始めていますが、SQLを使うにも手続き型の中で使うわけです。その手続き型の中で複雑なSQLを使った場合は1ステップでしかありません。1ステップに設計なんて関係ないわけですから、SQLができない人は1ステップですむ処理を、必ず分解して考えてイメージしています。

 わたしも、SQLよりも手続き型の方を長くやっていますから、会話の途中で、手続き型 → SQLの順で考えていることが多いぐらいです。ですから、優秀な人(下手糞のは予想できない)がどんなイメージを持っているかは、実はよく分かっています。

 優秀と言われる人ほど、会話のペースで(分割された)完璧なイメージを持っています。

 そのイメージは完璧であるがゆえ、完璧な形で下流に伝えてしまう。完璧であるが故、それを次の工程では打ち崩せない。結果、成果物を初級シスアドレベルにすら持って行けないこともある。その原因は、上流の人が会話の段階で持った分割した完璧なイメージにあるわけです。

 仮に、新人君が初級シスアドの試験のために一生懸命SQLを勉強していたとしても、上から使わない前提で書かれた仕様書が回ってきますから、使うことなく忘れていくかも知れません。上から潰すというどうしようもない間違いが、ほとんどの会社で起こっているから負の連鎖が止まりません。顧客レベルの技術が「難しい」っていっちゃう人たちが、マネージャだったり、リーダだったり、社内標準を作ったりすることになります。

 ですから、業界として顧客レベルの技術が「分からない」「難しい」という人を許してしまうことになります。みんなで可能性をつぶしているから、ちょっと、複雑な処理を書くとメンテナンスできないとかいう馬鹿げた意見が正論として通ってしまします。

 業界で通用している常識は、「顧客以下の技術力の技術者(と呼びたくない)が大半」という悲しい現実を前提にすると正論ですが、一般常識から考えると「顧客以下の技術力の人間がプロを名乗るな!」というわたしの意見はそれほどおかしくないでしょう。

 ※ 「資格は試験を受けた瞬間だけ分かっていれば良い」という常識が、わたしにはないのも問題なのでしょうけれどね。

 ともかく、完璧なイメージを持っている人は、優秀な人ですし業界の常識にそってやっているのに否定されたらたまらないですね。

 わたしの苦労はそこにある。優秀で完璧なイメージを持った人と戦わねばならないのです。しかも、多数決を採れば必ず負ける劣勢の中での戦いになります。

 苦しいけれど、ベンチャーとして採る戦略もそこにあるわけです。常識を打ち破ってこそベンチャーで、やってることは中小企業にしか見えないけれど、心意気だけはベンチャーなのです。

◇    ◇    ◇    ◇

 本当に単純な話、現実問題として、SQLについては初級シスアドレベルにすらない人間が現場にウジャウジャいるのです。さらに、上に立つ人間の技術力はもっと落ちるから、その問題に気づくことはできず、問題が顕在化してないだけです。

 しかし、SQLに問題があるということは認識されていて、実は理解してないくせに長ったらしい本当にメンテできない(わたしも無理)SQLを書く馬鹿タレもいるし、単純なSQLだけで何とかしようとして、失敗するパターンもある。

 どちらも非常に多い。教育してないのですから、失敗するのは当たり前なんですけどね。

 そのため、極めてレベルの低い禁止事項を作ったり、O/Rマッパーなる珍妙なモノをつくって何とかSQLを隠蔽しようとしたり、つまり、できないことを前提にできない人に合わせて何とかしようとするアプローチが行われています。

 これってね、テレビにリモコンがなく「孫の手」でチャンネルを変えていた時代が合ったのですが、リモコンが登場してもそのリモコンをやっぱり「孫の手」で押すのと同じことなのです。「孫の手」で乃木大将になった人は孫の手を離さないだけで、ボタンが小さくって「孫の手」では押しにくいって文句言われても、話が合わなさすぎて……。

 もっとも、そのアプローチは局地戦の戦術としては間違っていません。与えられた要員のスキル、納期に限界があるときは、教育していては間に合いませんからそういう戦術を採るべきです。しかし、会社が採る長期戦略として間違っているでしょう。

 ところが、単純にSQLが下手糞で失敗した結果と、SQLから逃げる戦術で上げた局地戦の成績を過大評価してしまう。評価する人間の技術力はゼロですから、表面的な結果で見ればそうなるのは当たり前の話です。

 結果、「SQLを極力使わない」ということが、会社が採る長期戦略となってしまったりする。乃木大将という神が大勢生まれるわけです。

◇    ◇    ◇    ◇

 煽っているだけで無策ではただの愚痴なので、その抜本的な解決策についてです。

 現状では、設計者(SE)と実装者(PG)というところに担当者の分かれ目が来ても、母言語(手続き型)側とSQL側には分かれていないから、SQLの能力が初級シスアドレベルにすらない人間であっても、SQLを使う部分の設計も実装もすることになります。それが前提になっているから、そんな馬鹿なことになるのです。

 とにかく全く違うスキルが必要であるにもかかわらず、全員に両方のスキルを求め、全員が高いレベルになるのは事実上無理だから低い方に合わせるしかないと考えているのでしょう。

 その根本原因である「設計者と実装者」に分けるという古く長い伝統的な考え方に固執しているから愚策を採っているということが分からない。

 教育するわけでもなく、分けるわけでもなく、低いスキル(素人レベル)に合わすというおよそプロとは思えない愚策が常識となっている。こんな単純なことを10年言い続けても変えれないなんて、わたしの力のなさも酷いものですが。

 わたしは無茶な理想論を唱えているのではなく、できない人がいるという現実にたった上で考えています。母言語(Javaとか.Netとか)側と、SQL側をそれぞれ担当する開発者(設計者・実装者)を完全に分けましょう。といってる訳です。

 つまり、

    母言語側開発者(設計者・実装者)
    SQL側開発者(設計者・実装者)
      ← テーブル設計などもするけれどDBAのことではない。

 として、設計者・実装者を兼任させるなら2パターン、今のSE・PGと分けるなら4パターンに分ければ良いわけです。

 単純でしょう?

 分けるには、DB側のロジックをすべてストアドプロシージャにしてしまえば、きれいな疎結合にでき、担当者を分けることができます。

 SQLができない(嫌いな)人は母言語側担当となればよいのです。「わたしはSQLが関わる部分は担当しません」と言い切れるなら、SQLができなくても何の問題もない。担当分野が違うだけです。

 担当がそれぞれの専門家に分かれていたら、それぞれの良い面を活かしてそれぞれに方針を立てることができます。「専門家でない人でも作れるように」などというアマチュア指向になる愚策に至ることはないでしょう。

 もちろん、上に立つ人間は、どこが切れ目か、それぞれの担当をどうコントロールすればよいか方針を立てれる程度には、技術の特徴を理解しておく必要があります、つまり、上流が高いレベルでSQLができないといけない訳ですが、専門家に任せる部分がどこか分かれば良いのです。

◇    ◇    ◇    ◇

 現実は担当は分かれていないというか、現在の一般的な開発手法では分けようがない。ですから、初級シスアドレベルができないのに、設計をやってるなんて人が現場にウジャウジャ居る。

 初級シスアドレベルを難しいとか、コンサルにコーディングは関係ないとか言って逃げ回る連中に人月何百万払ってるという馬鹿げた現状に、顧客側に気づいて欲しい。もちろん、本当にSQLもコーディングも関係ない部分のコンサルをしている人も居ますけどね。

 大手の顧客(情報システム部など)が気づいたら、一瞬で大変革が起きるはず。

 早く気づいてくれないものか、そうなれば、わたしも多少は儲かるはずなのですが……。

 ベンチャーって、インターネットがテレビ局という既得権者の資産価値をドンドン下げていっているように、既得権者の資産価値を下げて、現在なんの価値もないベンチャーの資産価値と交換することなのです。

 もし、わたしが言ってることが実現すれば、今まで一生懸命スキルを積み上げてきた技術者の「手続き型言語」に関する部分の大半を奪ってしまうことになりますし(UI周りとか、業務理解とか残る部分はちゃんとあるけど……)、大嫌いなSQLを覚えることを強制させられるかも知れません。会社単位では、SQLを避けるための各種の施策に掛かった費用はドブに捨てたのと同じになります。

 そりゃ、恨まれるし、嫌われますわな~。

 でも、早く気づいてスキルチェンジできれば下克上のチャンスです。変わりそうになったら、スキルチェンジのご準備を!

 それにしても、大変革が起きるというのは夢でしかないけれど、恨まれて嫌われるというのは現実だから辛いものです(苦笑)。

 とにかく、わたしの考える常識のラインは、全員が初級シスアドレベル。SQL側を担当する人には、わたし以上のスキルとしたい。

 多分、大手SIerが「極力SQLにロジックを入れる!」って戦略を立てて、全員が上のSQLは見た瞬間に理解できるようになれば、SQL側を担当する人は、これぐらいが30分ぐらいでできるようにすぐになると思います。

 初級シスアドでは、午後の試験はSQLを捨てては合格できないというぐらい、それなりの難易度の問題が数多く出ていますが、高校生もいくらでも合格しているのですから本当に簡単なのです。

 先入観より何より、できなければ仕事を乾されるという危機感があれば一瞬で習得できますって。

「ググるな危険」と常識のラインについて

2009/11/24 20:09:05

 うむ~。炎上したら怖いけれど、いろんなことを考えてしまったので、ひでみさんの「ググるな危険」について書こうと思う(忙しいからコメントは遅くなります)。

 わたしは人を育てられない。それは大部分は金がない焦りから来ています。弊社のように金がないと、技術は盗むものだからどうぞ盗んでちょうだいって方針しか採りようがない。とてもじゃないけれど、大手のやり方はできない。説明したいことは山のようにあるけれど、経済的にそれは許されず、新人だろうが中途採用だろうが、自立的で爆発的な伸び率を見せていただけないと成り立たないのです。ベンチャーですから、わたしのところあたりはメチャクチャきついと思う。

 大手の下請けなどで、新人の育て方を見ることもあるが、「余裕があるとこういうことができるんだな~」とうらやましくなることも多々ある。

 さらには、「甘えんなよ!」って思いも多分にある。ブックマークのコメントを見る限り、口開けて待ってるタイプが多いんだなと、ガッコウと会社の区別がついてないんじゃないのかとも思う。

 そして、わたしの言動を思い返すと、「ググれよ~!!」はよくいっている。

 多分、ひでみさんのところの件の彼がいたらわたしも、「ググるの禁止!」っていうかもしれませんが、「ググるの禁止!」といいたくなるタイプは、わたしが言いたくなる前に淘汰しちゃっているか、危険を察知して逃げていると思われ……、見かけない。本物の新人を相手にするようになったら、そういう人が出てくるのかも知れませんが、確実につぶしてしまうでしょうな、がんばって中間層を作らねば。

 いずれにしても、どこにハードルを設定するのか、つまり、常識のラインというのは本当に難しい問題です。

◇    ◇    ◇    ◇

 常識のラインというのは、何も新人だけに適用されるのではありません。例えば、10年以上前の話ですが、定期券を管理するという仕組みを作ったことがあります。

 想像つきますか?

 その会社(大企業)では交通費は6カ月定期券の現物支給なのです。異動があったり、引っ越しの申請をすると、人事部で払い戻し処理と、新規の購入処理を行い社内メールで発送します。もちろん、期限が近づけば人事部で継続の定期券を購入して発送します。

 その大企業の人の多くの社員は大学を卒業してすぐに入社し、中途採用はほとんどありませんから、他の会社の経験がある人はほとんどいません。つまり、打ち合わせに出てこられるすべての人にとって、定期券は会社が買って届けてくれるのが常識です。

 しかし、中小企業にしか所属していないわたしにとっては、定期券を会社が買って現物支給なんて想像できないことですから、徹底的に質問攻めです。お客様の方は、なぜ、そんな当たり前の質問が来るのか理解できないので、なんだか噛み合わない打ち合わせが延々と続きます。最後には「え~、じゃあ、あなたたちは、まさかとは思うけど、自分で定期券を買いに行くの?」って(わたしにとっては)当たり前のことでびっくりされました。

 どちらが普通なのでしょうか?

 どちらでもよいのですけれど、これぐらい常識のラインが違うと感覚的に質問しなければならないとすぐに理解できます。

 しかし、わたしも半端な自信がついたころ大失敗をやりました。「運送会社の配車システム」をやったときに、配送先を必須にする前提で設計してしまったというものです。「運送会社が荷物を運ぶのに届け先の住所を知らないで運べるわけがない」という馬鹿げたわたしの勘違いからやっちゃったのです。

 常識の違いを踏まえて質問すべきでした。

 異業種のこういう実態を見られるのがSIerの醍醐味なのですが、SIerの仕事というか、本質は「質問されること」ではなく、「質問すること」にあるとわたしは考えています。もちろん、質問に対する答えをまとめて……、と次の仕事がありますけれど、まず、会社毎に違う常識を乗り越えるために、「質問する」のは非常に重要なスキルなのです。

◇    ◇    ◇    ◇

 仕様書の中で書かれる「コンフィグファイル」は、iniファイルを指すのが標準という会社もあれば、.NETのapp.configを指す会社もあるかも知れません。コンフィグファイル = レジストリと変換するのはどうかと思いますが、文化・常識が違えば「コンフィグファイル」では理解できないかも知れません。

 わたしも本文を読んで、app.configとは思わなかったけど、作る前に、「コンフィグファイルって何のことですか? ファイル名とか決まりがありますか?」って聞けばすむ話ですね。他所の会社の文化を知らないことは恥ではないのです。

 一般常識なのか、業界常識なのか、会社固有の常識なのか、いずれにしても理解できなければ質問すればいい。それが一般常識、業界常識のときは、叱られたり、笑われたりするかも知れないけれど、わたしは聞く方の問題か、聞かれる方の問題なのかというと、「聞く方の問題」だと考える。

 もっとも、「分からないことはちゃんと質問するように」って方針でやってて、お客様に「在庫って何ですか?」ってやられて、横にいたわたしもフリーズしたこともあるけどね(今の会社の話ではない)。わたしはそこまでのことはないけれど、鈍感力がありすぎなのか、打たれ強すぎなのか、ガンガン質問してきた。お陰で常識を知らずに恥もかいてきたけれど、恥をかいた分強く覚えている。

 「同じことを何度も聞いちゃいけない!」ってことさえ守れば、知識のなさから常識の範囲の質問して叱られたり、笑われたりするのは、若い間しかできない大事な仕事です。笑われることによって、常識というか、空気というものを知っていくものなのです。

 というわけで、イヤな上司だろうが何だろうが、「質問できない雰囲気を醸し出している上司の方が悪い」なんて考え方をしている人は、その時点でいろんなものを失っている。ガッコウは教えてもらうのが仕事ですが、新人はできるようになるのが仕事ですから、質問しないといけないのです。

 質問できない人は、考え方を変えた方がよいでしょう。

◇    ◇    ◇    ◇

 若い人の話ではなく、中間層以上の年齢の技術者でも同じように悩んでいる。

 こんなことがありました。

 VB.NET + SQLServer という構成のプロジェクトを、当時入ったばかりの(といっても10年の経験者で、会社もできたばかりですけどね)社員にSE兼PMとして任せました。もちろん、任せた以上、わたしは細かいことは言いません。

 プロジェクト開始にあたってお願いしたことは、ストアドプロシージャを使って、SQLを書く人と、VBを書く人を分離して欲しい。初めてVB.NETでやる直請けの案件だったので、社内標準となるコントロールを作って欲しい。という内容でした。

 【重要】ストアドプロシージャでやるのはパフォーマンスの問題ではなく、開発者を分けて担当させることにあるのです。これは何度も書いているけれど、次の記事でもう1回書こう……。

 結果、大きな問題が3つ起きました。

(1).NET Framework Data Provider for SQL Serverではなく、ODBC .NET Data Provider を利用。※ パラメータに「?」しか使えないとか不便不便……。

(2)パラメータがWHERE句(文字列)
※ 意味不明……。

(3)担当者を分けてない
※ 一番重要な部分でなぜ逆らう! ってか、パラメータがWHERE句(文字列)では分離はできませんな。

 新人なら理解できたことですが、10年選手だからこそ体にこびりついた他社での常識が邪魔したのでしょう。おまけにプライドがあるから聞きに来ないどころか、

    わたしが説明する = 今の(今までの)やり方を否定する

となりますから、わたしの意見は聞こうとはしませんし、わたしが説明すること自体を拒否しはじめます。

 もちろん、再利用できる部品など何もできませんでしたし、プロジェクトは無茶苦茶になって、無茶苦茶にしただけで辞めていきました。会社が潰れる危機はここから始まって、5年経ってもいまだに引きずっています。奇跡的に生き延びていますけどね。

 責任は彼に任せたわたしにあります。なので、PMを降ろそうとしたのですけれど、引き継ぎまで拒否しやがって……。サンプルソースを渡しても、説明を拒否されてはどうしようもなかった。

 今もそうですが、あるレベルの人間に真逆のことを説得するのは、相手もプライドを持っていますから簡単にはできません。乃木大将ではなく、彼のようにお山の大将であっても、変えれないラインをしっかり持っている。わたしはそれを超えてしまうようで、説得の方法がなかなか見つかりません。

◇    ◇    ◇    ◇

 何にせよ、仕事をする上で、もっとも重要なのは常識のライン(価値観、文化)をすりあわせることにあるのは間違いありません。

 弊社はベンチャーである以上、社内の常識のラインは偏ったところに引いています。しかし、業界の仕事もするわけで、業界としての常識のラインを計りかねています。

 例えば、INNER JOINを使うべきだと思うし、HAVING以降はとってつけた感が否めないけれど、それはさておき以下のSQLを見てどう感じるでしょう?

  SELECT 
    資格取得履歴表.社員番号,COUNT(*)
  FROM 資格取得履歴表,社員表
  WHERE 資格取得履歴表.資格番号 
    IN (SELECT 前提資格表.資格番号
      FROM 前提資格表
      WHERE 前提資格表.職位番号 ='02'
      )
    AND 資格取得履歴表.社員番号=社員表.社員番号
    AND 社員表.職位番号 ='02'
  GROUP BY 資格取得履歴表.社員番号
  HAVING COUNT(*) >=
       (SELECT 職位表.取得資格数
        FROM 職位表
        WHERE 職位表.職位番号 = '02')

 5年ぐらい前だと、これぐらいでも「メンテできなくなる」とかいって突っ返してくるところは多かったな。今はそういうところはなくなったのかな?

 というようなことを考えないといけない時点でおかしい。もちろん、「INNER JOINで書きなおしなさい」は正しい指導だと思いますけど、この程度が「メンテできない」なんて技術者としていうなら「今すぐ辞めて田舎へ帰れ!」ということを、わたしは個人的に常識として採用しているのですが……。

 田舎へ帰るべき人たちが作った常識なんて糞みたいなものなんですけれど、常識だけに多数決で勝てるわけもなく……。本当にSQLは上からつぶされている。

 わたしには、常識のラインが分からない。ウソ、本当は分かってて、それを変えたいと思っているのですから……、難儀なやっちゃ(大阪弁)。

Winnyとマジコン、そしてシリアル掲示板

2009/11/18 20:00:40

 かなり前の話です。弊社でこんなソフトを製造しているのですが、突然、アクセス数が増えて、かなりの本数がダウンロードされるということがありました。@ITとかCodeZineとか、CNetとか2chとかに載っても(載せても)微増なのですが、それとは比べ物のにならないぐらいのダウンロード数でした。

 それで「どんな強力な人が紹介してくれたのか」とうれしくなって、「御礼をしなくては」とアクセス解析をしたのですが、ダイレクトアクセスばかりで分かりません。それで「メールマガジンかな」と考えて関連しそうなメールマガジンを探したりもしました。

 しかし、どうしても分かりませんでした。

 それで、もう一度冷静にアクセス解析してみた結果、Google Analytics のリンクで飛べないリファラーが2回あります。タイミング的にそのドメインからのアクセスが起点になって爆発的なアクセスになっているのではないか? と思い、それでドメイン名で検索してみたところ……有名なシリアル掲示板なるものでした。

 どおりで、ダウンロード前のアンケートに入力されるメールアドレスに生きているものがほとんどなく、たまに生きてるアドレスも他人のもので、本当のメールアドレスの持ち主から苦情の電話がかかって来たりする。さもありなん。

 たかだか数万円のソフトのためにシリアルの解析をするなんて「そんな暇な奴はいないだろう!」って高をくくっていたのが悪かったのですけれど……。

 その掲示板の上位表示がなくなった時点で、ダウンロードもされなくなりましたが、ダウンロードのピークを見るに、わたしは知らなかった掲示板でも、ここのコラムより絶対にアクセス数が多いと思います。くそー!

 実はとっても有名な掲示板なのでしょうか。いろんな意味で凹んでしまう事件でした。

 バージョンアップに際して、そこに載っているシリアルはもちろん使えなくしましたが、他に対策をしてないので、また破られるのでしょう。

 まったく、めんどくさい話だ。

◇    ◇    ◇    ◇

 わたしはゲームをしないので最近までマジコンの意味を知なかったのですが、日本橋(大阪の電気街)で堂々と看板を出していますし、マジコンは違法とはいえないようです。Winnyの作者にも無罪判決が出ました。しかし、マジコンもWinnyも、主たる目的として「違法コピーのために存在している」といって過言ではない。

 知り合いどおしで合法的にデータのやり取りをするなら、敢えてWinnyは必要ない。「P2Pの技術」と「Winny」は同列じゃない。個人的にマジコンとWinnyの違法性は、ほぼ同じと考えています。

 多くの技術者がいってるように、確かにP2Pのような技術が否定されると問題ですが、だからってWinnyが正しいとはならない(ハズ)。微妙だな~。

◇    ◇    ◇    ◇

 それはさておき、なぜ、このような製品を作ったかというと、生産性を上げたかったからです。

 バインドさせて簡単に画面が作れると非常に生産性が上がる。ダミーのストアドプロシージャをバインドさせれば画面はあっという間に完成するのですが……。

 しかし、製品を使っていただいている方からの質問などを総合するに、まず、空で画面イメージを作って、その後、テーブル設計、ロジックの組み込みと進めているようだ。

 なかなか意図が伝わらない。

 もちろん、お客様に使い方を強制するわけにはいきませんけれど、サンプルの動画もあまり見てはいただけてないようで。

 そんなわけで、今回はサンプルの動画も大幅にやり直しました。弊社が誇る美人社員にナレーションも入れてもらいましたので、ぜひ、ご覧いただければと思います。

◇    ◇    ◇    ◇

 いろんな現場を見ていますが、つくづく、新人に対してでなくベテランに対して「SQLの教育が足りない」と感じる。

 ベテランにとって、アルゴリズムのないSQLは違和感があるのは理解できるけれど、SQLは、Javaよりも.Netよりも古い古典的な言語で、.NetがJavaに、JavaがRubyに置き換わっても使われるであろう息の長い言語です。

 しかも、ユーザ向けに作られた簡単な言語で、コーディング量が激減している。嫌がっている人も嫌々ながらも使っているのですから、ちゃんと使ったら良いと思うのですけどね……。

 Javaだ! フレームワークだ! ってややこしいことをいっている人が大勢いる。そういう人が作ったものって、JavaとDBって全然疎結合になってない。言語のスパゲッティになっている。本当に疎結合にしようと思えばストアドプロシージャにDB上で完結する処理を入れるのが一番です。

 ストアドプロシージャにしたらメンテできないとかいう話も、なんだかな~。慣れてない人はどんなことでもできませんわな。

 慣れるには、最初にちゃんとした教育が必要なんだけれど、極めて初期の段階で「SQLは極力使わない」とかいう方針を打ち出しちゃうと教育しようがないし、本当にどうにかならないものか。

 前にも書いたけれど、初級シスアドでこのレベルです。

 初級シスアド 過去問題 平成14年度 春期 午後(問4)

 初級シスアド 過去問題 平成16年度 春期 午後(問1)

 新人の大抵はこの程度できるのに、上司が「EXISTSを使うと理解できなくなる」なんて堂々といったりしたら、詐欺師と同じです。

 「新人やユーザが受ける試験程度の能力がない人」がプロとして存在できるなんて、コの業界以外にあり得ないと思うけど……。どうにかならないものか。

「坂の上の雲」とプロジェクト

2009/11/09 19:00:00

 NHKでスペシャルドラマ「坂の上の雲」をやるそうです。そこで、「坂の上の雲」は高校時代に手に取ったけれど、全然おもしろく感じず、2、3巻でやめてしまったので、いま読み直しています。大変おもしろい。

 当時、おもしろく感じなかったのはそれだけ子供だったのでしょうね……。

 15分ほどしか乗らない地下鉄の往復で読んでいるので、戻りつつ読むからちっとも進まない。しかし、それも楽しみながら、じっくりゆっくりと読んでいます。

 「坂の上の雲」は、(日清)日露戦争の話です。そういった歴史物はオチは分かりきっていて、その後も分かっているから、読み途中でもさまざまな考察ができる。

 わたしの考察を1つ。「日清・日露戦争に下手に勝ってしまったことが不幸の始まりで、勘違いした挙句に第二次世界大戦であれほどの大敗をすることになった」という流れを、今までよりいっそう理解できてきた。

◇    ◇    ◇    ◇

 陸軍の乃木大将は旅順という敵の要塞攻撃を指揮していたのですが、その戦術は、コンクリートで覆われた山(丘ぐらいかな)から大砲と機関銃を撃ってくるロシア軍に対し、銃剣の歩兵が人海戦術で正面突破するという馬鹿げた方針で臨む。日本海軍から、再三、敵要塞の弱点である二百三高地を大砲で攻めるようにという要請があっても、その方針は変わらない。

 しかも、乃木大将やその参謀の伊地知少将は、敵弾は絶対に届かない後方に司令部を置き、最前線の惨状を知らない。乃木大将は実戦経験はあるが、それは維新前後の戊辰戦争や西南戦争で、コンクリートの要塞を攻めるような近代戦ではない。伊地知少将に至っては実戦経験はない。

 そんなやり方で、10万人の兵士のうち、6万人以上死傷者(戦死者は1万人以上)を出した。

 結局、別方面(本陣)を指揮していた児玉大将が乗り込み、敵要塞の弱点である二百三高地を攻める方針をとり、わずか数日で二百三高地を占領することができた。しかし、児玉大将は乃木大将の手柄を横取りする、つまり究極の組織である軍隊の規律を乱すことは陸軍大将としてできず、本人も手柄が欲しかったわけではないので、旅順攻略の手柄を乃木大将のものとすることに苦心する。

 結果、乃木大将の手柄となり、現在も乃木大将を祀る乃木神社があるように、乃木大将は神格化されてしまった。

 当然のことながら、神となった陸軍大将の戦略・戦術に誰も批判することはできなくなり、旅順と同じ方針が、その後の日本陸軍の基本路線となったといえるでしょう。

 つまり、女子供にまで竹槍を持たせるような玉砕人海戦術に結実していく悲劇につながったのです。

◇    ◇    ◇    ◇

 さて、現状のシステム開発に置き換えれば、当時の日本陸軍と恐ろしいほど一致すると思うのはわたしだけでしょうか?

 違うのは……。イヤもっと恐ろしいのは、プロジェクトは二百三高地を攻めるという方針を取らなくても、デスマーチという人海戦術で一応の終結を見るという点です。

 デスマーチになったプロジェクトも、最初から掛かった分の納期と工数(金額)があれば、同じやり方でも終わっていたわけです。つまり、デスマーチとはどういう状態かというと、単純に工数、納期において見積と現実が合わなかっただけで、予定通りきれいに終わったからといって、それが正しい手法とはいえないです。

 しかし、デスマーチが終わった後は美談に変わります。予定通り終わればさらに美談で、間違っても愚策と責められることはありません。

 どんな会社でも、予定通り終わった、デスマーチを終わらせたということが誰かの功績となるわけで、それが多くの乃木大将という神を生んでしまうことになる。実際、ほとんどのSIerに愚策によって神となった乃木大将が複数存在しています。

 システム業界には、実戦経験は旧式のCOBOLのみという大将格もいるし、実戦経験のない大将も参謀も存在する。そして、実戦経験のない人たちのよりどころは、神なのです。そんな神や参謀に育てられ、それが正しいと思ってしまう士卒も多い。結果的にそんなやり方が、社風、社内文化として定着していくことになる。

 司馬遼太郎先生が、「それは日本人の癖であり体質である」とおっしゃるとおり、変えようがないのだろうか?

 ともかく、わたしは無謀にも、神から連綿とつながる全技術者と対決するために起業した本物の馬鹿だということが、「坂の上の雲」を読んで、いままでよりさらに、強く分かった。

◇    ◇    ◇    ◇

 さらに分かったことは、頭の固い乃木大将を変えることは、天皇陛下(SIerにとってはお客様)にお願いするしかないということです。

 であれば、わたしの今までの活動は間違っていた。

 わたしには業界を変える力など到底ないですから、開発に挑戦するよりも、チューニングという仕事を天皇陛下から与えていただけばよい。天皇陛下のご依頼で、勝因も敗因も分析し直し、天皇陛下のお言葉をもって乃木大将を指弾すればよいわけです。

 もちろん、天皇陛下に直接お願いするために起業したのですけれど、わたしも開発にこだわっていた頭の固い馬鹿者だったわけだ!

 チューニングの営業などしたことがないので、どうしたら良いのか分からないのですが、弊社は開発よりもパフォーマンスチューニングを中心としたサービスに営業方針を変えていくことにしました。もちろん、いきなりは変えれないけれど……。

 具体的には、秘密保持契約を結んだ後、元のソースをご呈示いただいて、診断とチューニングを行います。エンドユーザに限り、初回の診断と、修正可能と判断した場合の一機能の修正までは無料とさせていただきます。

 ひどいテーブル設計という、今からは簡単に変えられない手枷足枷をはめられてパフォーマンスが出ないということもあるので、効果をお試しいただいてからご依頼ください、というサービスです。

 現在、価格(完全なテスト環境があることなどの条件もありますし)など検討中ですが、ファーストユーザーは特に安くさせていただきます。

 実際には、他社が書き換えたソースなどメンテできないといわれるとか、いろんな問題はあるでしょうけれど、そういうときは、わたしがユーザーお抱え(ユーザー様の名刺を持って)コンサルになればいいわけです。

 しかし、わたしがお客様の立場に立ってSIerと対決するとしたら……。

 入社試験みたいなのではないけれど、スキルチェックの問題をやってもらうことからスタートですね。それで「この程度がでケへンのか!」「原因はあんたがスキルが足らなかったからヤンケ~!!」「この○○○がぁ~!!!」とか大阪弁でいわれたら、SIer側から見たら怖すぎです。わたしも夜道を歩けなくなるから、そこまでの無茶はいわないですけどね(笑)。

 実はこういうサービスを始めたいと前から思ってはいたけれど……、全SIerに大喧嘩ふっかけるのと同じだからな~、開発仕事で何とかしたいって逃げてたんだな~。

 もし、情報システム部の方がご覧になっていらっしゃったら、最初は無料ですし、セカンドオピニオンとしてご採用していただければ幸いです

 詳しくは、こちらのメールへ ⇒ info@g1sys.co.jp

 あるわけないけれど、大手のエンドユーザーから依頼があったら、案外簡単に業界は変わるかもね。

 「DBサーバで処理したら、DBサーバの負荷が増える」なんて、「大地は平らだ」って主張するのと同じ、根拠のない宗教ですからね……。ぱっと見は大地は平らですけど、そんな何の根拠もないことを技術者が言うことじゃないし……。

 わたしは社長という立場になっても、結局わたしの方針でプロジェクトを運営できたことはほとんどない。それはわたしの能力の低さの証明ですが、乃木大将という神が創りたもうた常識と正反対のことをさせるのは、わたしが社長以上の立場に立たないと、どだい無理な話です。

 弊社(わたし)に取っては、夢のような話ですが(大手の)情報システム部の皆様、ぜひよろしくお願いいたします。

モラトリアム法案なんてとんでもない!!

2009/10/05 18:05:00

 モラトリアム法案なんて冗談かと思っていたが、

    鳩山由紀夫氏のモラトリアム宣言

    亀井金融相「私はハトを守るタカだ」

などを見るに冗談ではないらしい、日本を諦めるしかないのか。

 借金があるわたしが言おう。モラトリアム法案など通ったら弊社はどうなるか分からない。 それ以前に日本がどうなるか分からない。

 まさか、本当には通らないとは思うけれど、もし、法案が通ったらと仮定して、その影響を考えてみましょう。

◇    ◇    ◇    ◇

 まず、施行前に猛烈な貸しハガシが起きるだろう。

 で、モラトリアムを申請した会社は、そういう馬鹿げた制度がなくなった後にも借りることができない。当たり前の話で、銀行も会社も、お互いに継続した付き合いがあってこそ、金を貸したり、借りたりできるのですから、途中で裏切ったところに、将来にわたって貸さないといけない義務なんてありません。

 例えば、「払いすぎ~♪」の宣伝をあちこちで見ますが、過払い分を取り戻した人は、金融業界から見れば契約を反故(ほご)にして裏切ったわけですから、もちろん金融機関のブラックリストには載ります。それと同じで、国が作ったモラトリアムという制度を利用しても、同じように会社としてブラックリストに載るわけです。

 つまり、銀行は制度を利用した会社には貸さなくなります。

 ですから、真っ当な経営者はモラトリアムという制度があっても利用はしません。しかし、「制度があっても利用しないから貸してください」って話を信じて貸した後に、「やっぱり制度を利用する」と言われたら銀行はたまりませんから、猛烈な貸し渋りが起きることになります。つまり、モラトリアムという制度がある期間は銀行の貸し出し業務は停止することになるでしょう。

 そして、貸し出し業務が停止した分を保証するために、金融機関にジャブジャブ公的資金が流れ込むかもしれませんが、困っている会社には回らないのです。借りる金額と、毎月の返済額とどちらが大きいか考えれば分かる当たり前の話ですが、借りれなくなる方が中小企業の経営に多大な影響を与えます。

 「借金なんてする方がおかしい」なんていう意見もあるでしょうが、まぁ、分かってないよね。もちろん、無借金経営をやっている会社もありますけれど、例えばトヨタ(連結)の有利子負債は12,618,653百万円(12.6兆円)です。規模に応じて適切な額の借金をすることは、会社である以上当たり前の話です。

 融資は血液、金融機関は心臓と同じ。流入を止めたら(モラトリアム)全体が止まるのです。

 結局、真っ当で本当に必要な会社には資金は回らず、倒産が増え、失業者が増え、将来の税負担は国民が負うことになる。

 もちろん、住宅ローンについてもそうです。新たな貸し出しが起きなくなりますから、亀井大臣の大好きな? 土建屋さんの仕事が減るでしょう。新築の家やマンションを購入するときには、家具や家電なども買いなおすことが多く、そういう需要も減る。

 回りまわって、国全体に大打撃を与えることになるでしょう。

 最低賃金の引き上げにしても、派遣法の改正にしても、解雇規制にしても、すべてに言えることですが、あまりに、あまりに近視眼的過ぎる。

 政治家なら近視眼的に「誰それがかわいそう」で動いたらいけない、もうちょっと大局的に考えてくれないものか。とにかく、モラトリアム法案を通したら大変なことになります借金のあるわたしがいうのだから間違いない。国際的にも信用を失うでしょう。

 そりゃーね。ジャブジャブ貸してくれて当分返さなくて良い(できたら、個人保証も要らない)というなら、目一杯借りて人を雇う、まず、社長を雇うかな(笑)。そして、「あんなことやこんなことやってやる!」って思うけれどね。

◇    ◇    ◇    ◇

 小泉構造改革がダメだったのか? それが不況を起こしたのか? ちゃんと検証した方がよい。わたしは個人的には、安倍政権以降、マスコミが明後日の方向へミスリードして、構造改革が中途半端になったのが不況の原因と考えています。

 検証能力がある人はいないような気もするけれど。

法人税減税のススメ

2009/10/01 20:02:58

 法人税は高止まりしている。意外にもアメリカとほぼ並んでいますが、世界一の税率といえます。

 法人税を減税しろとか言うと、「金持ち優遇」などという単純な感情むき出しの反対論に負けてしまう。それらは、一般的な「経営者は金持ち」「企業が搾取する」というような誤解からきているのではないかと感じるのだが……。「企業が搾取する」って、いつの時代の共産主義者かと言いたくなる。いまどき『蟹工船』が流行ってたりするらしいし、いまだに階級闘争とか考えているのだろうか? なんだかね……。

 法人税率って約42%で、法人税は一部に外形標準課税というのはあるけれど、基本的に累進課税ではない。中小企業であれば(その善し悪しはさておき)オーナー経営者が多いのですが、残った58%をオーナーが使うには、配当することになります。その配当にはさらに20%の税金がかかりますので、元の利益から考えると46.4%しか残らないのです。

 「金持ち優遇」なんていう人に聞いてみたいけれど、いったいどれぐらいなら妥当だと思っているのでしょうか?

 経営者でも、まぁ、一気に儲かったりすると大仰になったり、2代目とかサラリーマン経営者は違うのかもしれませんが、初期の不安定な時期に必死の思いで出したわずかな利益のうち42%も持っていかれると、もうがっかりというか、なんとも言えない気持ちになります。ものすごい恨みつらみを胸に秘める人も出るのです。

 幸か不幸か、わたしは恨みを持つほど納税できてないけどね。さほど儲かってないから(苦笑)。

 特に、一代で成功する実力のあるオーナー経営者にとっては、実に53.6%もの税率になり、江戸時代の農民よりひどい税率と戦っていることになります。ですから、苦しみを乗り越えて安定した利益が出始めた経営者の中には、もちろん、そのまま税金を支払う立派な人も居ますが、利益を出さないように努力し始める人も多く出てくるわけです。

 そのとき、利益を出さないように社員の給料を上げるかというと、社会保険の会社負担額(税金と一緒だし)も増えるし、解雇しにくく上げた給料を下げにくい現状では、怖くてそんなことはできません。

 他に設備投資ですが、当然、減価償却分しか経費計上できず手元のキャッシュが大幅に減ってしまいますから、これも簡単にすることはありません。将来に渡り同じだけ利益が出る保障はないのですから、当たり前の話です。

 で、どうするかというと経費で落とせるところに金を使うようになったり、換金しやすいものに設備投資など名目で金を使う。例えば、高級外車を購入したり、社長宅を社宅として購入したり、六本木ヒルズに住んでみたり、接待名目で夜な夜な飲み歩いたり(今では、中小企業でも年間400万までしか使えませんが、一部は会議費で計上したりね)。

 もちろん、税務署が認めないと言い出すこともありますけど、社宅や高級外車に変えておくと、いざというときに担保になる。これはほとんどいい訳ですけどね(苦笑)。

 馬鹿な金の使い方をしている方(失礼)に中小企業の社長が多いのは、金の使い方を知らないのではなく、知りすぎていてイヤになっているわけで、税率の低い退職金を大量にもらって会長職に引き下がったりする人も出る。会社を大きくするモチベーションを失う人が出てくるわけです。

 (わたしは大したことはないけど)経営者は志の高かった優秀な人が多いですが、人間ですから当たり前の感情を持っている。多くは、苦労・努力の対価を求めます。しかし、余りに法人税率が高過ぎるため、結果的に利益を出さないための努力を続けることになるとしたら、本当にもったいない。

 ともかく、税率が高すぎると、能力があっても、税制の抜け道を極めることが合理的になってしまう。抜け道を極めることは社会的正義に反しますが、江戸時代に農民に掛けた四公六民よりひどいのですから、一揆が起きてもおかしくないわけです。こんな馬鹿げたことは、結果的にその企業に所属する社員や地域、ひいては国にとってマイナスにしかならない。

 ですから、抜け道を探すモチベーションを失わすぐらいの税率にすべきです。

◇    ◇    ◇    ◇

 法人税について書こうと思っているうちに、誰かが書いてて被ってしまいましたが、誰がどこに書いていたのか分からなくなってしまってすみません。被っていますが続けます。

 法人税は国税の割合が高い。

 本当に地方の活性化を考えるなら、法人税率の決定権限を、地方自治体に任せればいい。例えば、国税を10%、残りを地方税にして自治体が税率を決めれるようにすればどうでしょう。

 ちなみに、法人税の70.6%が国税で、利益から見れば、

    国:40.2 × 70.6 = 28.4%

    地方:40.2 × 20.4% = 11.8%

 つまり、ほぼ逆ぐらいが良いのでは?

 例えば、現状で大した産業のない地方自治体には利益を出している企業なんてほとんどないのですから、今のままなら税率をいくらにしても自治体の税収に差はでません。それなら、国税のみの10%にすればタックスヘブン状態になりますね。

 国内にタックスヘブンがあったら、国内の企業誘致はどんどん進みますし、海外企業も移転してくるかも知れません。

 もちろん、(地方)税率をゼロにするのですから一旦は税収は減るでしょうが、利益を出している企業が増えれば、同時にその企業で働く人たちがグンと増えますから、住民税と相殺すればチャラどころか税収が増えることになるでしょう。

 業種などによって税率を変えればよいので、例えば、風俗産業を追い出したければ、その税率を上げればよい。ちゃんと申告している風俗産業って少ないような気もするけどね(笑)。

 法人税率を地方に任せれば、東京一極集中も避けれるし、自治体ごとにそれぞれにカラーを出して、特色のある産業を育てれるようにようになります。

 余談ですが、法人税の29.4%が都道府県と市町村に落ちるのですが、割合が少ないとはいえ、これは大きな税収です。しかし、法人税って本社所在地に落ちることになってしまいます。

 でね。東京に本社、地方に工場って会社は多いけれど、どう考えても工場の方がたくさん公共サービスを利用するよね。大きな道路は必要だし、上下水道なども料金を払っているとはいえインフラの大部分に税金は投入されています。

 つまり、地方がコストを掛けて稼いだ金を、東京がコストを掛けずに吸い取っているのです。

 大阪が財政破綻しそうになっているのって、大企業の本社が東京に移ったからですからね。ふるさと納税の議論のときに、(東京に居るであろう)評論家がしたり顔で「受益者負担の原則」なんて言ってたけれど、「じゃあ法人税はどうなるんだ~!」って破綻しかけの大阪人は思ったりするのです。

 というわけで、法人税は受益者負担させるために国税の割合が大きくなっているのでしょうけれど、そこを直したら、ふるさと納税なんて面倒な制度はいらないと思うのですが、いかがなものでしょう。

◇    ◇    ◇    ◇

 ともかく、42%という税率はいくらなんでも高すぎです。

 もちろん、弊社は税率が高すぎるから利益を出してないのではなく、わたしの能力がないから出せないだけですが、とにかく高すぎや……。

コラムを書いてマスコミについて考えながら、解雇のススメのまとめ

2009/09/09 19:58:00

 コラムを書いていても1円にもならないのですけれど(※金をよこせと言ってるわけではない)、それでも読まれないなら書いても意味がないからアクセス数は多少は気になる。

 で、安直にアクセスを稼ごうと思うと、褒めるよりもけなす方が、穏やかよりも過激な方が、アクセスが増える。レコードからCDになって簡単にスキップできるようになったため、「頭サビ」が増えたけれど、Webでも顕著で、タイトルやリード部分で面白く過激にしないとアクセスは稼げない。まだまだ慣れないので空振りする(今回も頭サビが思いつかなかったので……)。

 で、例えば、タイトルで目論見どおりアクセスが伸びても、頭サビが効かないとほとんど読まずに去る人もいる。

 本質ではなく煽った部分に反応する人が出てくる。

 枝葉末節が気になって、趣旨にはたどり着かない人もいる。

 煽っている部分を(苦笑しながら?)サラッと流して、趣旨を理解してくれる読者もいる。

 プロのモノ書きからすれば、ごく当たり前のことかもしれませんが、素人には、頭サビを効かせて引き込むような芸当は、なかなか難しいものです。

 煽って書くことは、わたしの文章を読んだために趣旨と反対の方に凝り固まる人が出た場合はもちろん問題ですが、そういう人はもともと反対の思想を持ってらっしゃるのだろうから影響はないと判断しています。理解してくれる人の割合はそれほど差はないはずなので、全体が増えれば趣旨を理解してくれる人が増えるだろうと思って書いています。

 これはわたしの癖かもしれませんが、細かい方より大きい方が気になる。減点主義ではなく加点主義なので、反発はどれだけあってもゼロ、理解してくれる方がいればプラス。全体として理解者が増えればよいと考えています。

 同様に(加点主義だけではダメなのですが)経営者には、マイナスを恐れてはいけない決断という局面が多々あります。

 例えば、ものすごい特別損失を出しながら、(当時日本最大の?)リストラを敢行した日産自動車のカルロス・ゴーン氏は当初、史上最低の冷血人間と、ものすごいバッシングを受けました。当時の日本人にアンケートをとれば、70~80%以上の割合で否定されたでしょう。

 今になって考えて、その経営が正しかったかどうか? 両方のアンケートを比べてみたいものです。

 おそらく、関係ない人はそれなりの評価をし、そのまま雇用されている人は、高い評価をするかもしれません。しかし、実際にリストラされた人や、下請企業の中には、一家離散の悲劇にあった人も少なくないでしょう。そんな人たちはどう評価するのでしょうか?

 仮に、リストラを行わず、そのままの経営を続けていても復活したかもしれませんし、倒産していたかもしれません。倒産していたら、部門ごとにそれなりに売却され、一部の事業は名を変えて継続していたでしょう。決して全滅することはありません。

 それを踏まえて、どちらが多くの人を救ったのかは誰にも分かりませんが、カルロス・ゴーン氏の当時のオペレーションは、わたしはかなりの確率で正しかったと言えると思います。再現できないので、タラレバは余り意味を成さないけれど、経営者ならどんなに批判を受けても、なさねばならない判断というのがあるのです。

 というわけで、カルロス・ゴーン氏のオペレーションが正しかったかは分かりませんが、はっきり分かっていることは、ほんの1~2年でカルロス・ゴーン氏に対するマスコミの評価が180度変わったということです。

 マスコミは自身の間違いを振り返ることはないのか? 今のカルロス・ゴーン氏が正しいならば、バッシングは間違っていたことになる。そして、カルロス・ゴーン氏がもし、日本人であれだけのバッシングを受けたら、自分の決断を貫くことはできなかっただろう。

 カルロス・ゴーン氏がバッシングに屈してリストラを止めた結果、倒産していたらどうなるのでしょう。マスコミは責任を取ることはないし、さらにバッシングしたでしょうね。

◇    ◇    ◇    ◇

 わたしが言う分には大したことはないけれど、もし、総理大臣が「解雇規制を撤廃する!」って言ったら、それこそ、そのクビが飛ぶぐらい失言として扱われるだろう

 ペンは剣よりも強いらしいが、確かに強いけれど、叩くマスコミは本当に正義ですかね?

 日本をどこに連れて行きたいのだろう。信念はあるのだろうか?

 わたしもゴシップ新聞のごとく過激に書いていますけれど、信念は持っています。

 解雇を自由化すると、偽装請負など本当に互助的なモノだけになり、ブローカーは存在できなくなる。企業は生産性をあげることに力を入れるようになるので、SQLの必然性も理解されるようになるし、年配のCOBOLerを再生することも、若い技術者を真の技術者にすべく、教育することもできると考えています。

 ばらばらに書いていますが、大体つながっています。そんな信念があるから煽れるし、乱暴に書けるのです。それがなかったらただの馬鹿です。

 立場を変えて考えると、マスコミの信念は、ここ数年「政権交代をする」ということに費やされてきたように思う。

 本質的な政策を蚊帳の外に置き、「ナントカ還元水」「絆創膏」「産む機械」「酔っ払い」「漢字の読み違い」……。「酔っ払い」以外はどうでも良いことで、単に煽って混乱させただけ、それを分かった上で「政権交代」という大義名分(信念)のために、わざと馬鹿さわぎをやっていたと、わたしは理解しています。

 自民党以上におっちょこちょいばかりの政権になるわけですが、「政権交代」が大義名分に足るかはさておき、目指した政権交代が成った以上、今度はその脆弱な政権を支えるのが、前政権を蹴落とした者の務めだとわたしは考えています。

 もし、マスコミがその政策を支えるために提言をするのではなく、これまでと同じように、ひたすら煽って蹴落とすための馬鹿騒ぎをするなら、マスコミはただの馬鹿となる。大義名分ではなく、ただ煽って視聴率、購読者、アクセス数だけのためにやっていた(いる)ということの証明になるでしょう。素人でもやってる、「褒めるよりも、けなす方が、穏やかよりも、過激な方が」を無差別にやってるだけじゃないか。

 もちろん個人的には、みなまで言わずとも稼ぐための馬鹿騒ぎと思っていますが、お手並み拝見です。ただの馬鹿騒ぎだったら、まぁ、わたしが許さんといったところで、どうしようもないのですけれど、「そんなことは許さん!!」。

 素人でも信念をもってやってるのですから、マスコミの連中にはプロの信念というか、意地を見せて欲しい。小泉総理を作ったのも、安倍総理、福田総理、麻生総理を葬ったのもマスコミですし、民主党政権を作ったのもマスコミですから、責任は取ってほしいと思います。

 もっとも、安直に流される国民が一番悪いのですけれどね(苦笑)。

 自民党は50年も政権を持っていた。政権が変わらないことで日本を腐らせてきたということが政権交代の大義名分でしたが、それが正しいのなら、「終身雇用を前提とした解雇規制は、人間を、会社を腐らす仕組み」ってなぜ分からないのかな……。同じ理屈ですけど。

◇    ◇    ◇    ◇

 解雇の問題に戻って、実際に解雇規制がなくなったら、30歳ぐらいが分かれ目かな。40代以上なら実力のある人はメリットが大きいし、ゴマすりや堪えることで来た人たちは大変でしょう。30代は微妙ですけれど、20代なら確実に得をします。でも、20代も「解雇規制をなくす」なんてとんでもないって考えるのですよね~。「経営者が吸い取ってる」とか分かりやすい方に流れるけれど、漫画の見すぎですがな。

 経営者って何人いて、しがみついている40代、50代が何人いるか考えたらいい。

 しがみついているだけの40代、50代を1人切ったら、20代を1.5~3人雇える。会社としては、もうたまらんほど旨みがある。けどできないのよね。

 若者の敵は法律(解雇規制)と組合なのよ。本当によく考えた方がいいですよ。わたしはアラフォーですから、年齢的にも立場的にも、若者がそっちを向いていてくれた方が利用しやすいけどね(苦笑)。目を覚ました方がいい。

 そうはいっても、40代、50代を見殺すわけにはいかないのでセーフティーネットは必要です。しかし、実際にやるなら、「失業保険の給付期間を倍にする」(アルバイトは認める)&「子供の学費ぐらいは(国が)出す」で十分だと思うのですけどね。そこで、必死で生まれ変わろうとのた打ち回らないと、今まで吸い上げてきたのはなんだったんだってね。

 ちなみに、弊社は若い会社ですから、切りたい40代、50代はいない。

 さっきも書いたけれど、そうなったらCOBOLerの再生計画(SE補完計画)に入りますよ。

 「人の行く 裏に道あり 花の山」ってヤツです。

 つくづく、天邪鬼ですね~。

◇    ◇    ◇    ◇

 読み返してみると、酔って書いているのが丸分かり……。中川さんを笑えないけど、まぁ、ちょっと直してよしとしよう。

解雇のススメ(続き)

2009/09/04 19:46:13

 有名な人がさんざんやってる内容なので、みんな分かっていると思っていたのですけれど、案外理解されてないのかなということで、「解雇のススメ」の続きです。

 最初に雇用契約というのは、平たく乱暴にいえば、

  • 社員側は「特に問題がない限り」労働力を提供し続けます
  • 会社側は「特に問題がない限り」労働対価を支払いを続けます

という契約で、その契約解除を、会社から申し出るとき「解雇」といい、社員から申し出るとき「退職」ということになります。

 この契約は、その契約解除の条件において著しく不平等で、会社側の「特に問題がない限り」は、「解雇しなければ会社の存続が危ぶまれる状態」であり、社員側の「特に問題がない限り」は、「なんかイヤになった」でも良いのです。

 この不平等を正さないどころか、さらに不平等を増幅させようとしたりするから、合法的に社員に「なんかイヤになった」と言わせるように閑職に追いやったりするか、そもそも契約を結ばないようにするという防御策を会社はとってしまうのです。

 そんなわけで、おそらく、会社の経営者なら100%解雇規制をなくして欲しいと思っているでしょう。思ってないとしたら、解雇規制の内容を知らずに、解雇しているのではないでしょうか。

 定額給付金がそのバラ撒いた金額以上に経済効果があったかどうか分かりません。現実的に貯蓄に回した人も多いでしょう。日本人がお金を持ってないのではなく、将来に不安があるから使わない。というのが、サブプライムショックで直接的な被害はないのに、他の先進国より経済が落ち込むことになった要因のひとつでもあります(輸出入に頼っているからということもあります)。

 お金をバラ撒いても、「金を使え!」と強制できない以上、将来の不安を取り除かない限り、消費には回らないのです。

 同じことで、解雇規制をすればするほど、雇用は守られなくなります。

 「人を雇え!」と強制することができないのですから、雇いたくなる政策でないと、雇用が増えることはあり得ません。何度も書いていますが、解雇規制を強めたり、最低賃金を高めたりする政策は、逆の効果しか生まないのです。

 コの業界には直接は関係ないけれど、派遣の規制も同じです。もっと守られない、もっと不安定な日雇労働者が増えるだけの話です。派遣法が悪いなんて、勘違いもはなはだしい。

 話は変わりますが、若いころは無茶苦茶タフだったので、SEをやりながら、土日にはホテルや結婚式場でウェータをやっていました。黒服に白手袋で、新郎新婦を先導したりするあれです。

 で、新郎新婦さんは、基本的に(苦笑)初めてですから緊張されます。入場前とかに裏で説明がてら、いろいろ話をしたりしてリラックスしてもらうようにします。そのとき「この人ら失敗するんじゃないかな~」って思うことがよくありました。

 それは、どういう人たちかというと、結婚(式)ってスタートなのですけれど、「ゴ~~~~~ル!!(ハート)」ってなっている人たちです。まぁ、結婚式であまりに醒められていても困るといえば困るのですけれど(苦笑)。

 追跡調査はしてないし、決して、幸せそうなのを僻んでいたわけではないですが……。

 同じように大学もどういう学問を修めるかではなく、入る(入って遊ぶ?)ことが目的になっているし、(大)企業に入社してそれをゴールと思って「これで安泰!」と思っているんじゃないかと。それはなんとなく日本人の特徴なのかと思ったりもするのですが、違うのかな?

 「サラリ~マンは~気楽な稼業ときたもんだぁ♪」と、かつてそういう日本人が大勢いたのは間違いないですけれど、このご時勢になってこれだけ外的環境が変わってもその変化についていけず、「会社に入ったのに思っていたゴールじゃない!」って考えている人がまだまだ多いのじゃないかと考えています。

 そういう人たちにとっては、解雇規制が緩和されたり、自由化されたりしたら苦しくなりますよね。その人たちは残念ですが、がんばって外的環境の変化に追いつくように努力してもらうしかありません。

 現状では、本当にしがみつく術しか知らない連中が多いのは事実ですから、クビを切られた人たちへのフォローはある程度必要でしょう。

 しかしね、世の中馬鹿ばかりじゃないのですから、ある程度時間がたてば、外的環境に合わせて自分戦略を練り始めるんじゃないですか?切られた人も、切られなかった人も、切られそうな人も。そこから後は自己責任でしょう。

 いつまでもセーフティネットを広げていたら、セーフティネットに依存する人を増やしかねない。セーフティネットは、一時の混乱を乗り切る分でよいのです。

 今、日本は明治維新、第2次世界大戦の次に来る大変換の時期にある。そんなときに「解雇の自由化なんてとんでもない!」ってな考えで会社にしがみついていたら、一緒に沈没するということは、実は分かっているんじゃないかな。

 解雇の自由化だけでなく、大変換期に必要な政策を行えば一時期混乱します。それはいわば外科手術をするのですから、血が出るのは仕方ないのです。それを怖がって、何もしないどころか、解雇規制強化とか、最低賃金アップのような反対の処置をするのは、癌患者に治療をせずに、色黒の司会者が言ってた食品を大量に食べさせるようなものなんですけどね。ネズミの癌は治るかもしれませんがね……。

 日本は、血が出るのを極端に恐れすぎで、失われた10年が、失われた20年になってしまった。スパッとメスを入れて癌を取り除かないと、本格的に立ち直れなくなってしまうでしょう。

◇    ◇    ◇    ◇

 おまけ。

 経営者は、顧客、社員、仕入先(下請)、債権者、株主、地域(国)といろんな人(ステークフォルダーとかいうやつかな)との利益を調整しながら、ライバル会社と戦っています。その利益の調節を、どのぐらい先の利益に目標を設定して調整するか、ウェートをどこに置くかで答えが違います。

 たとえば、村上ファンドは、極めて短期の株主の利益をネタに交渉しましたが、それが正しかったかどうかは分かりません。しかし、村上ファンドに対して経営者のほとんどは、経営者より強い立場の株主様の意見であっても拒否しましたね。

 その拒否した内容は、村上ファンドと経営者の見ている未来のスケールがズレているのか、フォーカスしている相手が違うのかという、ちょっとしたファクターの違いなのです。拒否したことは、経営者自身の保身なのかも知れませんが、全部がそうとはいえないし、ファクターの違いなら議論になり得ます。

 しかし、社員の立場からのみで判断して、「会社が搾取している」とか言っても、それでは経営者は、「ご意見承りました」で終わりです。すべてのファクターを考慮したうえで、ここのバランスがおかしい。って論理的に示さないと、ただの愚痴でしかないから、議論にはなり得ません。

 社員は立場が低いから聞いてもらえないのではなく、愚痴にしかなってないから聞いてられないのです。

 作業している人は、自分と会社の関係しか見えていませんし、見ていません。しかし、仕入を担当している人は自分と会社のほかに、仕入先(下請)との関係も見えてきますし、営業なら顧客が見えています。コの業界ならば、PMになれば自分(部下)と、下請の他に、顧客も見えてきます。

 その上の職位になると、資金繰りのため銀行(債権者)とか、株主が見えてきます。そこまで見えないとバランスが良いか悪いかなんて分からないのです。

 もっとも、決算書(有価証券報告書)を見ればかなりの部分は分かりますから、経営者に文句をいいたいときは、決算書ぐらいは読み込んでからやりましょうね。

 ちなみにわたしはアマちゃん経営者なのでバランス悪いわ~。

 大企業の経営者や政治家が、下々の困窮を知らないというのは当たり前と言えば当たり前です。バランスをとることが仕事ですので、たとえ100人が困っても、1万人が助かる方法を考えるべきです。100人の方ばかり向いていると、全体を苦しめるちぐはぐな方針しか出てきませんから、100人の立場からすると酷いと思われても、やるべきことをやらねばなりません。

◇    ◇    ◇    ◇

 こういう書き方をしていると誤解されるのですが、文章をちゃんと読んでくれたら分かると思うけれど、解雇規制をなくして欲しいというのは、解雇したいからではなくもっと採用したいからです。そもそも弊社など、クビにするほど社員がいないし。

 ここに書くようになって、何人かの方とメール交換してお会いする機会があったりするのですが、みんな怖がっているように見える。

 よっぽど怖い人と思われているようで……。

 まぁ、わたしは他人からどう思われてもなんともないけどね。

解雇のススメ

2009/08/31 19:33:59

 わたしが言わなくても、勝間女史とか(URLは「勝間 解雇」でググッてトップを選んだ)、池田先生とか(URLは「池田 解雇」でググッてトップを選んだ)、有名な方が散々やってる内容で、当たり前の話なのであまりやりたくないのですが、「解雇のススメ」です。

 実際に会社(社長)をやってみれば分かりますが、解雇なんてできないのです。リストラにしても早期退職制度を作って、大変なコストを掛けて行われます。その証拠に、リストラやった後の決算書を見れば、ほぼ結構な額の特別損失があがります

 (整理)解雇の条件ということは、客観的に見て「これは社員を雇っていられる状態ではない!」というのが条件なのです。

 ということは、誰が見ても、「もうこの会社は潰れるよ」って状態を証明しなければなりません。つまり、致命的になるまで解雇できないのです。

 実際、整理解雇するところまで行うと、かなりの確率で倒産は免れません。例えば、整理解雇じゃないけれど、内定取り消しをした会社がその発表のすぐ後に倒産したでしょう。

 そんな風に会社が潰れたら全員の雇用が守れないばかりか、不払いなどが起きるため、仕入先(下請け企業)が連鎖倒産することもあり、もっと多くの不幸を生みます。しかし、致命的になる前に整理解雇できるならば、何割かの社員は救えることになりますし、社会的に迷惑を掛けることも避けれるかもしれません。

 どちらが良いでしょう。現状では、残念なことに、前述のとおり致命的な状態にならない限り、整理解雇は法的に許されないのですが、政権をとるであろう党は、現在の社員を守るべきとおっしゃっています。つまり、倒産してもっと不幸を作るべき、といって政権をとろうとしているわけね。 

 経営者は、客観的に倒産状態になる前に、リストラを敢行すべき状況を把握しています。それでも法的にリストラができないから、ものすごい閑職へ追いやって陰湿なイジメの末に自分から辞めるといわせるようにしむけたりすることになる。しかし、現実にそれをやっているのは人間ですから、そんな非人道的なことは、やった方も、やられた方も精神を害します。当たり前です。そのために、年間に3万人も自殺するような世の中になっている。

 毎年、9.11の犠牲者の約10倍ですよ。戦争ですがな。

 こんな異常な状態を改善するには、解雇が普通になればいい。解雇されたことが不利益にならないぐらい、普通のことになればいいのです。少なくとも、法的規制がなくなれば非人道的なリストラをする必要がなくなりますし、経営者も無用な意地を張る必要もなくなります。

 しかし、一般的な人は「解雇はひどいこと」と考えるでしょう。その根底には、深く考えない教育と、日本人に根付いてしまった終身雇用の意識があります。

 その終身雇用ですが、企業側から見れば新卒採用は入社試験と数回の面接で、海のものとも山のものとも分からない学生を採ることになるのですが、サラリーマンの生涯賃金は2~3億。つまり、解雇できない人を新規採用するということは、入社試験と数回の面接で2~3億円の買い物をするということになります(もちろん、2~3億円というのは、大企業の話ですけどね)。

 高度成長時代は日本は途上国だったわけで、あらゆる分野に成長の余地が大きくあったため、一括新規採用して終身雇用の抱え込みを行っても、経営は成り立ちました。しかし、先進国になった以上、それでは経営は成り立たない。追われる立場ですからね。

 当然、選考は(中途採用も)厳しくなり、できることなら「派遣社員で」となる。

 つまり、経営が成り立たないのに解雇できないから、新規だけでなく中途でも雇いにくい。雇いにくいから非正規雇用に頼るようになる。そのため若い世代が職にあぶれたままスキルもつけずに歳をとる。ワーキングプアになったり、将来の不安が大きくなり、結婚もできず少子化が進む。

 日本は、国力が落ちるための悪循環を繰り返しているわけです。

 解雇規制という法的な問題と、「解雇はひどいこと」という学級会的な国民感情、つまり、深く考えさせないという教育がない交ぜになっている現状では、企業の努力では悪循環を止める手立てはありません。仕方がないので、現状を維持、つまり、正社員という既得権者を守る努力をするしかなく、新たな雇用は生まれません。それでもダメなときコストを掛けてリストラするか、倒産しかないのです。

 ですから雇用を生み出そうとすれば、国がすべきことは解雇規制ではなく企業が安心して解雇できるような大幅な規制緩和と、解雇された人のためのセーフティネットを組むことです。

 しかし、学級会的に考えると、規制を強化して、解雇しないようにするためのセーフティネットをたくさん作ることになるでしょう。解雇しないようにするためのセーフティネットは、既得権を持った正社員にしか効かないセーフティネットで、既得権を持った人をこれ以上守っても仕方がないのに。

 解雇規制をしたまま(さらに強化したり……)、どんなにバラマキをしても、若者に回る仕事は単純作業になり、国力はどんどん落ちていく。それで、若い頃に単純作業しかしてない人が、中高年になったとき新たな仕事ができるかというとできませんし、単純作業は発展途上国の安い労働力との争いになり、安い労働力の流入はこれから益々増えるでしょうから、もう悲惨です。

 大きな悪循環の真っ只中にいるわけです。

 何とかならないものか……。

 解雇が自由になれば、新卒も経験者も雇いやすくなりますから、解雇されても次の就職先を探しやすくなります。ただし、どこでも活躍できるスキルが必要になりますから、この業界に限らず、看板ではなく能力で勝負する当たり前の世の中になる。

 受験戦争を勝ち抜いて会社に入って、そこにしがみつくスキルばかりを磨き続けるなんて、何が楽しいかわからない人生を多くの人が送るよりも、常にスキルを磨いて自分で立つ、そういう、当たり前の世の中になってくれればと思います。

 そうはいっても、現状の中高年の大部分は(もちろん全員じゃない)、しがみつくスキルしかないから、他所に行ったらまったく使えないでしょう。実際に解雇を自由にするなら、セーフティネットとして、十分な再教育をすることは必要ですね。

 ともかく、もともと勤勉な日本人です。企業が解雇しやすくした方が、今よりも国力は伸びますし希望も出てきます。

◇    ◇    ◇    ◇

 これが掲載されるころには、労組系の支持を受けている民主党が政権を取っているのでしょう。労組の中で「解雇しやすくすべき」なんて口にしようものなら、ボコボコにされますから、あそこからは出てくるわけのない提案ですね。つまり、労組の「若者に仕事を回すより、自分たちの椅子が大事!」っていってる人たちを若者も支持してしまったわけなんですよね……。予想ですけどね。

 民主党が「解雇しやすくする」って言い出したら、拍手喝采で支持するよ、わたしは。

偽装請負のススメ

2009/08/26 18:30:47

 偽装請負というのは、コの業界(古い隠語だけれどコンピュータ業界のことね)のいわゆる悪弊であったりするのですが、それぞれについて分からないというお話や勘違いしてることも多いかと思うので、ちょっと整理してみよう。

まずは言葉の意味から

 ■ 請負契約

 納品物に責任を負う契約。つまり、成果物が完成しなければ報酬はもらえない。どのように作ったかは個別に契約していない限り問われない。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。

 ■ 委任契約(準委任契約)

  作業に責任を負う契約。ちゃんと作業をしていれば(善管注意義務を果たしていれば)成果物がなくても報酬がもらえる。受注側が従業員を使う場合、発注側が指揮監督をすることはできない。

 ※ ここまでを分かりやすくいうと(かなり乱暴ですが)

  • 委任や派遣は課長以下、残業がついて従順であることがよい。
  • 請負は課長以上、まじめであることは評価の対象ではなく、結果を出すかが問われる。
  • 課長以上は残業はつかない。

 ■ 派遣契約

 労働力を提供する契約。指揮監督は発注側にある。

   □ 特定派遣

   正社員(契約社員?)を派遣する。
   登録だけのスタッフを派遣することはできない。
   届出だけで派遣会社になれる。

   □ 一般派遣

   登録型の非常勤スタッフを派遣する。
   厚生労働省の認可が必要。

 ■ 出向(法律上そういう契約はない)

 他社に常駐することを指して『出向』ということもある。通常は、子会社などに長期間異動することをいう。その場合、基本的な労働契約は子会社(出向先)の方が適用されるが、退職金などは親会社の基準であったりする。

 ■ 常駐

 他社で長期間(その間、基本的に自社に戻らず)作業することをいう。

互助的な多重派遣(偽装請負)

 最近は特定派遣の届出を行っている中小SIerは非常に多い。これ自体は問題がないのです。委任契約・派遣契約で仕事を出すことも、請けることも何の問題もありません。

 何が悪弊かというと、多重派遣、偽装請負派遣、偽装委任派遣です。

 多重派遣になると、ほぼ、客先(or 大手SIer)常駐になり、必ず人月単価でやり取りされることになるので、「常駐が悪い」「人月単価が悪い」ということになりますけれど、常駐や人月単価が悪いわけではありません。

 互助的な多重派遣(偽装請負)とはどういうことかというと、好景気のときは仕事はたくさんあるけれど、どうしても人が集まらないということが多々あります。そんなとき中小企業同士で仕事や技術者を回し合いますが、同業他社に案件を紹介すると、ライバルを育てることになる。自社の社員が空いたとき、紹介した同業他社で埋まっていたらシャレになりません。

 しかし、ライバルといっても仕事を回しあって助け合う必要がある、つまり、今日は仕事を出しても明日は人を貰うことになる。お互い様ですから、お互いの商流を守っていくためには、どうしても多重構造になってしまうわけです。

 法的な問題では、最終顧客が派遣契約を望んでいた場合、多重派遣は明確な法律違反なので、間に入った会社は契約書に派遣契約と書くわけにはいきません。そのため、実質は派遣契約を行うのに、請負契約や委任契約を結んで人を派遣してしまう。

 これがコの業界の悪癖といわれる人月ビジネスです。多重派遣、偽装請負派遣、偽装委任派遣、いずれも同義語と呼べる法的な問題です。

 偽装かどうかは、どこまでの責任範囲で、誰からの指示で仕事をしているかというのが問題。微妙です(だから偽装できるのですけどね)。

 たとえば、孫請会社の社員で、大手SIerに常駐して作業しているとします。そこには自社の上司がプロジェクトにいて、その上司からの指示で仕事をしている。しかし、上司も上位の会社の名刺を持って仕事をしている。

 これは悪名高い偽装請負かと言うと、全うな請負(委任)の可能性が高いです。つまり(ペーペーの)社員の立場では分からないことも多いわけですが、変に知恵をつけて偽装でも何でもないのに、「偽装だ!」と騒いでみたり、「違法行為の犠牲になった」とか馬鹿なことを言い出す連中も少なくない。「なにがどう悪くて、どう犠牲になったのか言ってみ」って言ったら何も言えなくなるのですけどね(苦笑)。

 人月商売(ビジネス)というのは、人身売買とか、奴隷とか、なんだか悪い言葉にすりかえられて、意味を分からず批判する若い人が多いのですけれど、それ自体が必ずしも悪いことではないのです。

問題はなにか?

 最初は中小企業間の互助的な人のやり取りであっても、これが常態化すると、ずる賢い?人が出てくるもので、中間マージンを抜くことだけを目的としたブローカー的な会社が誕生する。つまり、人を右から左に紹介することばかりで技術ではなく頭数をそろえ「人月いくら」のみで技術者がやり取りされることになるわけです。このブローカーは最初っから、偽装請負派遣を前提に会社が存在、つまり、違法行為をするために存在しているとも……。

 しかし、社員の立場であれば、偽装だろうがなかろうが直接的には、納得する報酬を得ていれば大差はない。中小企業としては経営が安定するので、好景気が続いているなら社員にもメリットがあったともいえます。ただし、技術者として長期的な非常に大きな問題があります。

 問題は偽装かどうかはさておき、開発仕事を委任や派遣でやってしまうことです。会社として委任や派遣(偽装請負)に偏りすぎると、人月いくら、オーバーチャージいくらの契約になって、デスマーチになったら会社はそれだけ儲かるため、生産性を上げるモチベーションにつながらない。

 時流から「次はJava」と計画し教育することはあっても、それは生産性を上げるための教育ではなく、売れる技術者(スキルシート)にするためでしかなかったりする。社会人になりたてからプロとして生産性&品質で勝負できるはずがないので、スキルシートを作ることは間違いではないけれど、会社が「売れる技術者」を目標にしてしまっているのに、社員がそれ以上に伸びることを望むのは無茶な話です(というか望まないしね)。

 また、大手は大手でマネージャ、コンサルと呼ばれる人にした方が儲かるのと思っているので、技術をつけるモチベーションにつながらない。その結果、大手に技術力がないということになる。つまり、技術を評価する指標がないわけですから、とにかく(見せ掛けの)スペック=スキルシートで判断し頭数を集めて終わらそうとして、中小企業は需要に合わせて頭数を集めることに努力の方向が向くことになる。

 つまり、技術者の集まりであるIT系企業が、大企業から中小零細まで、技術をつけるという目標を持たないまま仕事をするという悪循環が生まれるのです。

 これがわたしの考えるコの業界の構造的な問題です。

なぜそういうビジネスに流れるか

 技術力で仕事をするならば人月いくら(単価はさておき)ではなく、成果物で勝負する請負契約であるべきなのですけれど、それは成果物の対価を受け取る契約ですから、ぶっちゃけプロジェクトが完成するまで金になりません。

 それはつまり、半年のプロジェクトなら、半年以上入金がない状態で社員の給料や事務所家賃などの経費を払い続けないといけないわけで、いわゆる、デスマーチになれば大赤字になり、最悪、納期が守れず、違約金や損害賠償を請求されることもあり得ます。

 一方で、委任契約というのは成果物を問われないので、時間(人月いくら)の契約になります。もちろん、派遣契約も同じです。

 つまり、請負契約は大変なリスクがあって、体力がないとできないので、中小企業では現実には簡単にすることはできません。中小企業が請負でやっても資金繰りがつくようになればと思うけれど、借金をするのは大変なリスクですからやりたくないでしょうし。

 いまだに銀行の担当者に「なにやってるか分からん」っていつも言われるからな~。まぁ、分かったところで弊社には 貸してくれないんですけど……、悔しいねぇ。

委任・派遣契約が悪いのか?

 では、委任契約が悪いかというとそうではない。

 成果物のない仕事、たとえば、保守作業やシステム運営などは、委任契約にならざるを得ません。開発前のコンサルティングも請負契約もありますが、開発ボリュームを決めるための作業ですから、請負ではなかなか難しい。

 派遣会社が問題かというと問題ありません。実際問題として、作業量が一定でないのですから非常勤の方は必要です。

 派遣会社は、働き方の多様化と、仕事量の増減を調節するために、派遣スタッフ、利用者の双方にメリットがあります。不景気になれば派遣社員から仕事がなくなっていくのは、その構造上仕方のない話です。正社員を希望して派遣社員になった不幸な方もいらっしゃいますが、少なくともサブプライムショック以前というほんの1、2年前まで、コの業界ならばわずかの努力で正社員になれたのですから、派遣切りに合おうと自己責任といっても過言ではないです。

 しかし、開発会社であるならば、せめて開発仕事は請負にシフトしていくべきだと考えています。前述のとおり、最初は資金繰りの問題で簡単にはできないけれど、シフトしていかないのなら会社組織を立ち上げる必要はないはずですが、派遣中心でやっているところはリスクを負ったことがないし(ぞっとするようなデスマを見てるし)、請負でするための技術が蓄積されていないから、資金があっても尻込みしてしまうようです。

 つまり、悪循環の中に入ってしまうと、なかなか抜け出せなくなります。

 技術者なら、そんな悪循環の中で飼いならされたらダメですよ。悪循環の中にいるということを認識してそれを利用しないと将来がないです。

 SQL云々言ってたときに反論してきた人たちは、悪循環の中で飼いならされた人たちだろう。たとえフリーでやってても人月いくらで適度な残業はありがたいとかね。請負でやってたら、数分の1の工数にできたら収入は逆数になりますからね。

元の濁りの田沼恋しき

 現実問題として、もう1つ別の問題があります。

 田や沼や 汚れた御世を 改めて 清らに住める 白河の水
 白河の 清きに魚の 棲みかねて 元の濁りの 田沼恋しき

 という江戸時代の狂歌があります。田沼は賄賂政治をやった老中田沼意次のことで、白河は腐敗した田沼政治を立て直そうとした田沼の次の清廉潔白な老中、白河藩主松平定信のことです。

 行き過ぎた賄賂政治にうんざりしていた江戸の庶民は、松平定信の就任に喜びましたが、程なく杓子定規な法運用に息苦しくなって、田沼意次の方がよかったと言い出すわけです。

 余談ですが、民主党が政権をとって同じことが起こるのよね。半年から1年で「元の濁りの……」って言い出すと思うのですけど、そうなったら200年前から成長がないってことやな(苦笑)。

 それはともかく、偽装請負は確かによくないことです。ってか違法ですし。しかし、一方で中小企業同士の互助的なシステムでもあったわけですが、今、食べあぐねている方たちに仕事を回してあげたいと考えても、偽装請負&コンプライアンス云々が邪魔してできないという問題になっています。

 偽装請負の問題は、多重になった商流の下位にいる方たちの権利を守るためにあったのですが、コンプライアンスを守るようになったために、商流の上位に入り込める営業力のない弱いところから、逆に首を絞めてしまう皮肉な結果になっています。不況が重なって、小さな会社やフリーランサーなどが悲惨なことになっている。

 業界として何とかしないといけないのに、大手も自分のことで手一杯ですから情けない。

 法定速度を守るより、安全な速度で走ることの方が重要なように、法律自体よりも、法律の意味するところ、つまり、「商流の下位にいる人たちの権利を守ること」が重要であるはずです。

 しかし、大手は、法的な罰則以上のマスコミなどの正義の鉄槌を恐れてできませんし、意味も分からずブラックとか言い出す僕ちゃんも多いので、もう、あきらめるしかない。日本全体で学級会状態ですな。

 受けてくれるところがあれば、弊社は偽装だろうがなんだろうが、できる技術者には仕事を回します。偽装請負が会社の主業になるのはまずいけれど人助けなら良い。実際、今は受けてくれる大手がないので、空振りですけれどね。

 まぁ、わたしなどがいくらがんばっても、協力できるのは何万人?の中の数人もないので意味がない。

 どうにかならないものかな……。

 業界を良くするならコンプライアンスじゃなくって、SQLに限らず上流が技術を磨くことなんよね。そうして、委任ではなく請負で中小企業に出していくこと。大企業が頭数ではなく、技術を求めるようになったら、下はあっという間に変わるのよ。

 当ったり前の話過ぎてバカバカしいオチだな。

 SaaSになったら?って……。それを構築・製造するのは誰でしょ?製造する人が人月で請けてたら意味ないって……。

◇    ◇    ◇    ◇

 派遣法の規制強化や、最低賃金の増額など、同じように、もっともっとひどい結果になるのは目に見えている。あらゆる業界で派遣やパートの方の数が減って、正社員はもっと過酷な残業に耐えることになり、派遣やパートの人たちは今よりも仕事がなくなり、失業者であふれることになる。

 本当に失業者を少なくしたかったら、「解雇しやすくすること」とや、正社員の権利をもっと小さくすることが一番です。

Lunarrが解散するらしい

2009/05/08 16:55:00

 Lunarrというサービスを提供する会社がアメリカのポートランドにありますが、6月末でその短い歴史に幕を下ろすそうです。残念です。

 LunarrのCEO(社長)はサイボウズ創業者の高須賀氏でした。

 お会いしたことがあるのですが、わたしが、もっとも影響を受けた社長の1人です。高須賀氏は間違いなく天才です。その高須賀氏ですら成功できなかったというのは、新しいものを創造するのは、本当に難しいことなんだと痛感せずにいられません。

 起業するよりもやめる方が遥かに難しい。資金的に余裕はあるけれど清算してしまう(Lunarrは倒産ではなく清算です)なんて、これは相当にツライで決断です。

 もちろん、ダメと思えば清算した方が良いのです。

 しかし、いざやめるとなると、取引先や社員、その家族、自分の意地やプライド、その他もろもろの思いが綯い交ぜになって襲ってくる。それに耐えて決断をするというのは本当に大変なことで、多くの経営者が判断を誤ることになる。最後の足掻きで成功する人もいますから、さらに判断は難しい。

 わたしには到底できないことで(すでに最後の足掻きモードだったり……)、そのツライ判断を素早くできるところが、本当に経営者として立派なところだと思います。

 高須賀氏は、サイボウズの成功もあってか、目標をそれ以上において、最初からグローバル、世界一を狙うという戦略でした。それがきつかったのかもしれません。

 弊社は高須賀氏の基準ではベンチャーではなくただの中小企業になるのですが(わたしも中小企業と思っている)、わたしは世界一を目指しているのではない。

 「井の中の蛙大海をしらず、されど天の深さを知れリ」

 後半は誰かの創作らしいが、わたしは大海で1番を目指す方ではなく、「井の中の蛙」でもよいので深く極めたい。1つの道を極めるというのは、自己満足になるかもしれないけれど、それでもわずかばかりは社会に貢献できると思います。

 それはこっちにおいておいて、Lunarrというサービスについて。

 わたしも早くからIDを貰ったのですが、結局使わずに終わってしまった。

 使わなかった理由は、Lunarrはコラボレーションツールですから、わたしだけが使っても意味がない。わたしの説明が下手なのか、全員に使わせるというのは難しいと感じてしまった。それにLunarrを使わずとも、既存のアプリケーションにある程度満足している。

 つまり、

(全員の)移行コストの高さ > Lunarrを使うベネフィット

とわたしの目には映ったのです。長期的には違うのでしょうけれど、短期的には「移行コストの高さ」がどうしても気になります。

 翻って、わたしが言ってること、

「SQLを覚えましょうね」
「テーブル設計を後回しにしましょうね」

も、一般的に、移行コストがものすごく高く見えるのでしょう。それに問題はあるでしょうが、一応、すでに確立した手法で問題なくプロジェクトは終わる(こともある)。

 「何年もSQLを書いてきてもこんなの書けないのに、ちょっとセミナーに出たぐらいで書けるわけない」。そう思うのも無理はないけれど……。

 この壁は本当に高い。高須賀氏が超えられなかったのですから、わたしに超えられるはずもないか……。そんな弱気にならずに、どこまでもドン・キホーテのようにがんばって続けます。

 高須賀氏の次のチャレンジにも期待してます。チャレンジしてないと死んじゃうぐらいアグレッシブな人だから、次はもっともっと大きいことをきっと成し遂げるでしょう。

 5月15日にセミナーをやることになりました。http://www.g1sys.co.jp/

 ごく基本的な部分から、テーブルファンクション・OLAP関数ぐらいまで説明します。

 ご興味のある方はこちらまで ⇒ info@g1sys.co.jp

法律ギリギリの経営について

2009/04/20 15:55:00

 忙しいのと、書き溜めていたのがなくなったので、更新が滞ってしまいました。

 今回も昔から書いているネタです。

 ライブドアは、元のオン・ザ・エッジという社名からも、違法ギリギリを攻めることをいわば社是としていたわけです。

 この違法ギリギリってやつは、幼稚園の先生が「スカートめくり禁止!」って言ったのに対して、「わざとコケて覗く」みたいな感じですかね。

 100分割(実際には何回かやってるので数万分割)についても、MSCBについても、夜間取引についても、粉飾といわれた利益の付け替えにしても、「わざとコケて覗く」のと同じ、「確かに法律には明記はされてないグレーゾーンだけれど……」という内容のものです。

 わたしは一瞬考えたけど、そこまでできずに見てる同級生みたいなものか。

 「あいつは馬鹿だ!」と思いながらも、本心ではうらやましいと思っていなくはない。

 しかし、一事が万事、違法ギリギリなら幼稚園の先生(司法側・世の中)も、「いつかは懲らしめないと」と思うのも当たり前の話です。違法ギリギリがあってもよいかも知れないけれど、全部がそれでは「合わせて一本」でしょう。

 例えば、「100分割について流動性を高める」(100分割とファンドでのライブドア株売却の関連性について続・100分割とファンド株売却スキーム)というもっともらしいイイワケをしているけれど、結果、22万人も議決権を持った株主がいたわけで、その経済的不合理は、彼の今までの言動からは説明がつかない。

 なぜなら、それはスピード重視のベンチャーとして真逆の方針です。逆に、公共事業がスピードをもってできないのは、議決権(投票権)を持った株主(有権者)の合意を得なければいけないためです。

 例えば、駐車場の足りないところに格安の駐車場を作ろうとする。

 交通渋滞も緩和され、公共事業として一見良いことに思えるけれど、近辺で駐車場を経営する人にとっては死活問題になりますから反対が起きます。

 駐車場を経営する人が社会的強者か、弱者なら公共事業は潰れます(中途半端なときは、公共性が優先されますけれど……)。

 同じように、何かしようとすると対立する業界団体から「民業圧迫!」という理由の抗議が起きるので、抗議が起きない当たり障りのない政策しかできなくなるわけです。

 企業経営に置き換えると、株主が多くなればなるほどベンチャーと真逆の経営方針を採らざるを得なくなるので、ベンチャー経営者なら避けたい経営方針です(22万人というのは、ちょっとした地方都市の有権者数を軽く超えている……)。でも、今、どうしてもキャッシュが欲しいベンチャーがやることはあるでしょう。

 新聞、雑誌などが彼を責めている「売り抜け」うんぬんの根拠は知らないけれど、当時のネットバブルという状況や、「時価総額世界一」というよく分からない目標を考えると、分割によって株価を吊り上げて同時にアドバルーン(M&A)を上げれば、何倍にも注目が集まって株価を維持し易い(高止まりする)と考えた。

 その高止まりした株価で、さらに価値の高い会社を買収していけば良い。

 「実際の会社の価値は後からついてくる」と考えたんだろうと思う。

 つまり、彼が言ってた目標の「時価総額世界一」を手っ取り早く実現しようとすると、安くできるアドバルーンはいくらあっても良いわけで、その1つと考えれば合理的に説明がつく。

 「次のアドバルーンに、選挙にでも出るんじゃない?」って思ったら、本当に出てびっくりしたぐらい。

 ニッポン放送の買収に使ったMSCB(引き受け先は今はなきリーマン)も、リーマンが大量に市場で売却し続けるので、通常は株価が暴落する。

 ニッポン放送の買収というアドバルーンと一緒にやったから株価は維持できたけれど、その利鞘を全部リーマンが持っていったわけです。

 このようなギリギリの行為は、その時期は、やらざるを得なかったか、勢いでやったのか。

 とにかく、彼がそんなことが分からないはずがなく、分かってやっているだけ罪は重いと思う。

 そんな彼の大胆さがうらやましいというのは、例えば、わたしも未だに「前例がない」「できるわけない」で一蹴され続けるのは、本当に腹立たしく思っているからです。

 「裏技でも通したろうかい!」と思わなくはない(わたしが言ってることは極めてベーシックなのですけれど)。新しいことをしようとすると正攻法ではなかなか勝てない。

 わたしでも、好き勝手な暴れ者に見えるかもしれないけれど……、社内外で暴れるのも、このような公なところで実名さらして煽って書くのも、かなり迷った(ヤケクソの)結果で、実は大変なんです。

 「既存の枠組みを壊したい!」と考えているのは、わたしも同じですが、ギリギリの線引きがかなり違う。ホリエモンと一般との中間ぐらいなのでしょうか。

 せいぜい、アクセスを稼げそうなネタ(ホリエモン)を持ってくるぐらいしかできない。

 ホリエモンは、正直あまり好きではなかったわけです。

 しかし、

なぜなら、そういう大きな事業は時に発想が早すぎて一般には理解されないことが多いからです。昔は王様がいて、そういう無謀な投資をしたものですが、今は事実上民主主義共和制の国家がほとんどなので、そうはいきません。国家予算をそういう海のものとも山のものともわからないものに投資することに対して反発する人は多いでしょう。そういう人はこういいます。「そんなことやっている場合か。福祉や社会保障、世界中の飢えている人々に施すべきだ」と。もちろんそれも大事ですが、夢も大事です。停滞した後ろ向き、現状維持の世界に、若者はどういう希望をもって生きるのでしょうか?私は、そういう意味で無謀な、ほとんどの人に理解されないであろう、投資をするためにせっせと稼いでいました。
落合弁護士ネタ|六本木で働いていた元社長のアメブロ

私は嫌な努力をしたいとは思いません。ですが、夢を実現するための努力は厭いません。人によっては、その努力を「命を削って」と表現したくなるのかもしれませんが、私はそれくらい大変なことをしていても、「いやー、簡単だったよ」とかいって平気な顔をしていると思います。好きなことをやって稼げているということ自体がハッピーなわけで、それが客観的に大変そうにみえようが、私にとっては「適当に」なわけです。
「額に汗して」とか、のうのうと言える人間が逆に私は良く理解できません。好きなことをやる、夢に向かって突き進む人は、人一倍苦労して「額に汗して」仕事をするのが「当たり前」です。そして、そういう人は自分の努力している部分をひけらかしたりしません。
田中角栄元首相とタクシン元首相|六本木で働いていた元社長のアメブロ

 この感覚は近いんですよね~。

 「努力してる!」って大げさに言うときは、実はしてないときだったりするし(苦笑)。

 何をもって努力とするかは人によって違う。イチローは努力しているのだけれど、イヤイヤやっているわけではないでしょう。

 努力と苦行は違う。

 おそらく、多くの人は努力を苦行と勘違いしてみるのだろうけれど、やっている方は苦行とは思ってないから、「たいしたことはない」と言うために、偽悪的になってしまうのかな。

堀江: 「僕も『モノ書き』になりたいと思ったことがありましたね。山口瞳さんの『草競馬流浪記』( 新潮社) を読んで、こんなふうなのを書いて適当に食っていければいいなって。」(後略)
(「だから、結局、ホリエモンなんだ。 - ショウちゃんのエーガな日常」で引用された「朝日ジャーナル」4月30日号の文章:「堀江貴文氏と浅尾大輔氏の対談」)

 わたしも、天邪鬼で素直じゃないから……、照れ隠しか何か知らないけれど、似たことを口にすることはよくあるが、あらためて他人が言ってるのを聞くと「ヤダな~」と思ってしまう。

 同属嫌悪(そんな言葉はない)と言うには、わたしは何も成し遂げていない。

 何とかしたいのですけれど、若くして成し遂げるには(もう、若いとは言えない?)、ギリギリの無茶もしなければならないのでしょうか?

 とにかく、そんな世の中はヤダなと思うのです。

今さらながら「10年泥のように働け」

2009/03/27 18:59:00

 今さらながら、「10年泥のように働け」について。

 わたしはこれは、伊藤忠の丹羽氏の本で先に読んでいて、しばらく話題になっていることも知らなかった(笑)。

 ちなみに、元になった丹羽氏の話はこんな感じ。

「伝書バト世代」覚悟問う――若手社員の育成法 丹羽宇一郎氏に聞く

【「『人財』潜在力どう生かす」08.05.10日経新聞(朝刊)】

「会社の繁栄は人材にかかっている」と強調する伊藤忠商事の丹羽宇一郎会長に若手育成法を聞いた。

   ◇

私は最近の若手を「伝書バト世代」と呼んでいる。自ら考えることをせず、言われたことを単に伝えるだけ。ひどくなると「飛んでいけ」と言われるまでじっとしたまま指示待ちの姿勢だ。それなのに自負心は強い。少子化やゆとり教育のせいか、競争意欲に乏しく、北風に当たったこともないのに自分はよくやっていると思っている。

会社に入ったら、自分の力を自分で評価してはいけない。学生時代は点数化できる知識の量で評価されるが、会社は社員の能力のうち数値で測れない部分をじっと観察しているということを覚えておいてほしい。

評価するのは未知の世界に挑戦する情熱、逆風での競争力があるか。さらに相手の立場や社会的な視点から物事を考えられる良識と常識を持っているかだ。必要とされている、頼りにされているという実感こそが働きがいにつながる。

リーダーとしての資質は仕事でしか磨くことができない。うちの会社は入社したら完全なゼロからのスタート。平等に機会を与え、だれにも平安な道を用意するつもりはない。厳しくかつ戦略的に鍛え上げる。

まず入社して十年間は泥のように働いてもらう。はい上がる気力や苦しい時に周囲を思いやる気持ちを育てるには、どん底に突き落とすしかない。入社4年までに全員を海外に研修に出す。海外の若者がどれだけハングリーに働いているかを見てきてほしい。

毎日深夜まで会社にいろとは言わない。本を読み、人と会い、ものを考えることで知的能力を再生産する努力を続けることだ。大変ですよ。ついて来られない社員が出ても仕方ない。

次の十年間は徹底的に勉強させる。経営の環境は刻々と変わる。現場で感じた疑問を勉強で解消し、学んだことを現場で検証する。昨年からビジネススクールに短期間通わせている。二十年間以降は本物のリーダーとして人間性そのものに磨きをかけさせる。本気で人材を育てるつもりなら、十年単位の時間と費用をかける必要がある。経営者にとって最大の仕事だ。

 丹羽氏とわたしを比べたらいけないけれど、「まったくそのとおり」と考えている。

 もちろん、弊社では海外に出したりできませんが、ウォータフォールしかあり得ないガチガチの大手SIerも一度は経験してもらうようにしている。

 いずれにしても、どんな道(商社/IT業界)であろうと、最初の10年ぐらい泥のように働かないで「何かをつかめるわけがない」とわたしは思っています。

 IPAの重鎮たちは、3Kと言われる業界にあって、「商社の丹羽さんも言ってるでしょう?(ITが3Kじゃなくって、どこでも同じでしょう)」って言いたかったのかどうかは分かりませんが、少なくとも、わたしにはそんな風に聞こえるのです。

 それに学生が反発したってのが、「なんだかな~」って思ってしまう。

 会社にいたから働いているわけでもない。タイムカードはないけれど、時間をつけずに最後まで残って勉強していました。図太いわたしは、すぐに本を持って帰っても良いか交渉して、ほとんど持って帰るようになったし、欲しい本は会社の金で買うすべも覚えました。自分じゃ、あんな量の本を買えないし、当時はISDNは引いておらず28.8kbpsのモデムしかなかったし、テレホ(死語)もやってなかったし……。

 わたしは、若い頃から呑んだくれていて、1年のうち300日は外食でした。カウンターしかない居酒屋で1人酒とかやっていましたけど、「Oracle チューニングガイド」などを肴に呑んでました。しかも、大阪でも最もディープな天下茶屋という街ですから、周りからは相当、変な人に見えたでしょうね。

 それでも、「明日、会社行ったらこれ試そう!」って、会社へ行くのも楽しみにしていたし、酔っていても、夢の中でも、ずーっとソースコードと戦っていましたから、酔っ払った状態で、夢の中で、昨日つまった箇所が解決することも結構ありました(先週も、ソースコードではないが、夢の中で1つ解決した)。

 もちろん、仕事を忘れてリフレッシュする時間も必要ですけれど、丹羽氏も、「毎日深夜まで会社にいろとは言わない」って書いていらっしゃるとおり、「10年泥のように働く」とは、酔ってても「あのエラーは何で……」って、仕事のことをガムシャラに考え続けるという意味だと思う。

 それに、「10年泥のように働く」のは会社のためではないのです。

 自分のためでしょう。

 そこに反発する若い人は……大丈夫か?

 別にその会社に骨を埋める(転職する/しない)は関係なく、まぁ、10年ぐらいは泥のように働かないと力はつかないし、どんな業界でも簡単には芽は出ないですよ。中には一瞬で芽が出る天才もいるのでしょうけれど、そんな人はとっくに芽が出てるしね。

 簡単に芽が出る業界は、簡単に他の人(例えば外国の労働者)に置き換わってしまう業界です。

 少なくとも、現在の社会は「ほどほどに」ということが許されにくい世の中になってきている。わたしたちの世代は、学校でもそこそこ競争があった。今の若い人たちは、小学校から大学まで本当に無風で育っていますが、社会に出たらかつてないほど厳しい競争が待っています。

 そのギャップはどの世代よりも大きく、ある意味かわいそうに思うけれど、プラスマイナスゼロでしょう。受け入れるしかないよね。

 格差社会というのは収入を指すのでしょうが、努力できるかどうかが本当の格差なんじゃないかな。昔は窓際族なんて、ほどほどに生きていけるポストも存在して、出世コースのガムシャラに生きるポストもあったけれど、今は、ガムシャラに生きるポストか、ドン底の生活の非正規雇用か、両極端になってしまった。

 それでも、若いうちに夢を見てガムシャラに生きる方が楽しい人生ではないですか?

 せめて若いうち、10年ぐらいはガムシャラになってみたらどうでしょう。

 もっとも、IT業界ではガムシャラだけではダメで、要領も、戦略も、かなりの割合でいる。

 単純には、横着な人間でないとダメです。コンピュータは人間が横着するために存在していますから、そもそもの大原則を理解してない(真面目な)人は潰れる可能性が高い。

 「手を抜くにはどうしたらいいか?」を「10年泥のように働いて」考えるわけです。矛盾しているけれど、手を抜こうとしない人は、ただ単に、「10年泥のように消耗した」になっちゃいます。

 あと絶対にやってはいけないのは、人生の時間を切り売りすると考えることです。

 この考えを持って10年もやったら擦り切れて、何もかも残らなくなりますよ。

 同じ仕事をしても、人生を切り売りしている人と、技術を売ろうとする人では、将来に歴然たる差が出る。たとえ人月いくらの仕事をしていたとしても、「自分は技術を売っているんだ!」と強く思うことで乗り切れる(少なくともわたしはそうだった)。

 技術者なら、自分で育てた自分の技術を売らないとね。

 技術を売っている人は、技術を自分で育てられるから、減ることはないどころか、売っても売っても増えていったりするけれど、「切り売りしている」と思っている人は、必ず潰れます。わたしも技術を売っていると思ってやっていたころは自分でも驚くほどタフでしたが、「時間を切り売り」と思った瞬間に自我が崩壊したこともありました(今は何を売ってるんだろう……)。

 時間を売るという感覚でやっているかどうかは考え方だけの問題。アウトプットは同じなので、周りからは分からないけれど、ものすごく危険です。そんな考え方で10年ももったら本当に強靭な精神力だと思う。わたしはナイーブ(笑)なので無理だ。

 とにかく、時間は減っていくから売っちゃダメですよ。

 というわけで(どういうわけ?)要領よく横着する技術をつけるために、SQLのセミナーやります。お問い合わせください。info@g1sys.co.jp

 結局、商売です(笑)。

エンジニアライフ 最新の投稿コラム

@IT自分戦略研究所 新着記事

エンジニアライフ スポンサー

コラムニスト プロフィール

生島勘富
株式会社ジーワンシステムの代表取締役。
新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。

- PR -

@IT Special 注目企業
iPhoneアプリは外注?いやオレらが作る!
社内エンジニアに“檄文” 開発秘話公開

New!
【転職体験談】mixiに転職したエンジニア
8年間のSIer生活で得たスキルとは何か?

New!
→ インデックス

@IT Special ラーニング 
◆クライアント企業から求められる人材
⇒IT技術と経営戦略を併せ持つ「戦略家」

New!
◆気になる社会人大学院。興味はあるけど仕
事と両立可能?実際に通った6人に聞いた
→ インデックス