愛の反対は無関心な件

読売新聞のナベツネが死んだかと思ったら誤報だったようだ。残念!

とは言え、今はそこまでナベツネが嫌いではないので、よかったねと言っておこう。

そもそも私は子供の頃は大の巨人ファンでした。しかし大きくなってくると大人の汚いところが見えてきます。

巨人の場合は金の力で何が何でも優勝を目指す、汚い集団と考えるようになり、アンチになりました。ナベツネは悪の権化です。

しかし、時は移り、アンチにも飽きてきて今は野球自体に興味がなくなっています。数年前に巨人が優勝したときも、「あ、っそ」という感じでした。

誰かの言葉かわかりませんが、愛の裏返しは憎しみではなく無関心であるというのはホントに事実だと思います。

他の例としては、私は実家が某新興宗教にハマっており、子供のころはその宗教を信じておりましたが、十代になってからはその欺瞞に気づき、親と衝突ばかりしていました。

しかし40を超えると、もうどーでもいいのです。

というか、今は実家には住んでいないので、距離をとれているのですが、たまに実家に帰った時に宗教の話は極力避けるようにしています。

まあ宗教の話をするのであれば実家にもう帰らないと宣言しているので、親も話題にしません。

あと、最近同じような反応になった事例としては、韓国に関する認識ですね。

昔は知人がいたのでそこそこ韓国好きだったのですが、近年の韓国のトンデモ行動で反韓になり。。。でももうその話題も飽きました。

今ではミャンマーとかカンボジアとか、アルジェリアのような、どっか遠い国と同じ。もうどうでもいいです。

憎しみがあるうちは、まだどっかに愛の残骸があるのだと思います。

愛が完全に失われたらもうどうでもよくなる。興味も無くなるのが人間の反応っぽいですね。

とまあ、なんとなく最近思ったことを書きましたが、別にITに記事を縛っているわけではないのでまあいいか。

ではでは今日はこのへんで。

コミュニケーションがやっぱり大事な件

今年も残すところ1か月くらいになりました。

今日は一年の中で印象に残った、とあるダメダメ事件を振り返りたいと思います。

それは、プログラムの総作り直し事件であります。

既に単体テストまで終わったプログラムを作り直すなどという、そんなバカなことがあるのでしょうか?

あるんです。

まあ、話は単純でして、要件定義を行った人と設計を担当した人が違ったわけですよ。

そして設計担当の方がかなりイケていなくて、勘違いな設計書を大量に生み出し、製造まで進んだ段階で本来の要件とまるで違うということが発覚。

そして、要件定義をした人が設計書を作りなおし、プログラム作り直し、テストし直しになりました。

私個人に実害はなかったのですが、一度作ったものを作り直しするのはかなり残念な作業ではありました。

まあ、私はパートタイムで参加したプロジェクトだったので、作業分のお金さえいただければOK牧場ですけどね。

こうゆうことが起きるから、上流工程には優秀な人を入れる必要があるのに、どうしてダメちんを入れるかな。

この業界にもう20年以上いますが、ちょいちょいバカが設計して大炎上する事があります。懲りないね。

でも、こうゆうことが起きる理由は大体わかっていて、それはコミュニケーション不足に起因することが多いのです。

今回の場合、要件定義をしたのが元請の会社で、設計から製造は下請けの会社。要件定義をした人と、設計をした人は別の会社さんなのですね。

往々にして、下請けは遠慮というか、ヘンなプライドが邪魔して質問を十分にできなかったりします。分かった振りしたりするんです。

そして間違った設計書を作るのですヨ。

とまあ、場外で気楽に批判しているようですが、私にも同じような経験があります。私の場合、クライアントの担当者がめんどくさい人でなるべく話したくなかったのです。

なので、REDMINEで指示された通りに設計してあげて、実装してあげて、そして大炎上を起こしました。

モチロン私は言われた通りに作ったと主張しました。テメーの指示が悪いんだよ。REDMINEに記録が残ってるだろ?俺は悪くない。

とはいえ、会社としてはクライアントと険悪な関係を作ってしまったのは事実で、私の社内評価は下がることになりました。

なので今は客を客と思わずに言いたいことを言うようにしてます。

会社の看板を背負うとなかなかクライアントに強く出れないんですが、フリーランスなんで言いたいことを言えるのです。嫌なら契約を切ってくれて結構。

というスタンスになってからはこのような不毛なトラブルには無縁になりましたが、今回のようにパートタイムで実装だけ手伝う形になると、どうしょうもないですね。

まあ、パートタイムなので責任取らなくていいのが救いでした。

ともあれ今日はこのへんで。

IT人材は余っている件

IT業界は人手不足な業界として、よく話題に上がります。

まあ、確かに優秀な人がいないのは事実ですが。普通のスキルの人はそれなりに居る気がしますけど。

おそらく会社や分野によって人手不足で大変だとか、いや人は余っているとか見解が違っていると思うので、ここで整理します。

まず適切な金額を提示すれば、エンジニアはすぐに集まります。これは事実。

ただし安くこき使えて、そこそこ使える奴がいないのです。IT奴隷募集!!

どうやらIT産業だけではなくて他の多くの産業で、過剰な競争をしており低賃金な労働力でなければ成立しないっていう問題を抱えているようです。

例えばコンビニ業界は、中年フリーターと外国人労働者がいなければ成り立ちません。しかし、良く考えてくださいな。そんなにコンビニって必要でしょうか?

ウチの近所には4軒ほどコンビニがありますが1つあればいいんですけどね。しかも3つはセブンイレブン。。。

ドミナント戦略だかしりませんが、利益を追求しすぎで本来のサービスの在り方を忘れている気がします。

そして、そんなアホな戦略を支えるのは低賃金な労働力です。

IT業界も同じようなもんです。何でもかんでもIT化する必要はないんですが、無理にIT化の提案をしては低賃金のエンジニアを探して苦労するって、馬鹿じゃないの?

もう一度言いますが人はいます。しかし単価が追い付いていないのです。

なので高単価を払える一部の案件に人が集中しているというのが実体だと思います。

ではこの問題を解決する方法はあるのでしょうか?個人的にはぜんぜん解決しなくていいと思います。

むしろIT人材不足でエンジニアの単価が高止まりすることを期待します。移民なんてもってのほかですよ。

低賃金な労働力を前提にして成立している企業なんてのは、いわゆるブラック企業なわけです。そうゆう企業はつぶれた方が世の中のためだと思いますが、どうでしょうか?

ではでは今日はこのへんで

実は業務知識はそんなにいらない件

今日はシステムエンジニアがどのくらいお客さんの業務知識を持っているべきかについて書いてみます。

SEの紹介文とか、教科書的なモノを読むと、SEはクライアントの業務知識に関する深い理解が必要と言われます。

確かにそのとおりなのですが、じゃあクライアントと同じくらいの知識と持っているべきかというとそれは違います。

まあ、金融とか生産管理なんかは、それでもお勉強が必要です。なので金融の案件経験者は金融システム開発では引く手あまた。

でもほとんどの案件では、業務知識は一週間くらい集中して勉強すればいけちゃいます。

案件の初期段階で詰め込み勉強すればOKです。

例えば医者向けのカルテ管理システムを作るからって、医師免許が必要ってわけじゃないですよね?

医者が話す言葉を理解できてれば、まあなんとかなる。

むしろ重要なのはコミュニケーション力なんです。医者だってシステム屋に自分と同じ知識を求めるわけがないのです。

そうではなくて、求められるのはお客さんに要件を説明してもらう上でイライラされない程度の基礎知識とあとはポイントを押さえた受け答えです。

じゃあどうやってそうゆうスキルを身に着けるかというと、、、実務で経験を積むしかないっすね。

コミュ力に関しては座学で身に着ける方法はあまりお勧めしません。これってスポーツと同じで体で覚えるタイプのスキルだからです。

私自身は大学院卒業後に営業職に1年だけついていたのですが、結構その時の経験が生きていたりします。

エンジニアになってからも、業種が違う案件を最初から経験することで鍛えられたと思われ。

つまりはいろんなお客さんに当たるしか無いのです。

そうゆう意味ではあまり大きなプロジェクトの一員で長く務めるよりは、小さなプロジェクトを渡り歩く方が有利だったりします。

まあ、だからといってフリーエンジニアになりましょうとは言いませんが、今の職場では同じようなスキルしかつけれないようなら、転職くらいは考えてもよいかもです。

ということで今日はここまで。

フリーランスエンジニア最強のスキルの件

本日はフリーランスエンジニアの最強スキルについて考えてみる。

スキルと言っても幅広くて、JavaやPHPのようなプログラミングスキルから、 インフラ構築に関するスキル、ネットワークに関するスキルなどがあります。

技術では無いスキルとしては、営業力や特定領域のビジネス知識、プロマネ経験や英語力なども含められます。

じゃあ幅広いスキルのなかで何が最強なのでしょう?

多分、営業力が最強なのですが、それってどんな仕事でも同じでしょ?という話になるので候補外にします。

あくまでエンジニアの枠内のスキルとして考えてみます。

で、結論としては、どんなことでもサクッと学習できるスキルが最強です。

なんだか抽象的すぎると思いますのでもう少し説明します。

要するにお客さんからこんなことをやりたいと言われたら、NOと言わないで、とりあえず勉強してサクッと実現できる能力が最高なんだと思います。

例えばお客さんが人工知能に関心があって、金はあるからAI使ったマッチングサイトを作りたいと言われた場合、即効で人工知能に必要なスキルを身につけて実現できるエンジニアが最強なのです。

IT系の技術なんてのはどんどん変わります。どのようなスキルが良いかなんて時代の流れ次第で変わるんです。

ならば必要なときに必要な技術をサクッと覚えるスキルが最強なわけです。

ではこのスキルを身に着けるにはどうしたら良いのでしょうか?

ミモフタもない言い方ですが、普段から幅広く勉強しておくだけです。たとえば人工知能が最近は熱いので、じゃあ個人的にパイソンで人工知能のライブラリを使ってなんか作ってみるってこと。

さすがにまったくの未経験で人工知能を使ったサイトを作ることはできません。でも過去に少しやったことがあれば、お客さんの要望に応えることはまあ可能です。少なくとも外注に出したりは出来る。

もちろん人工知能の専門家になるには大量の学習が必要です。理論的なものから実装関係まで極めようとすると数年の学習期間が必要でしょう。

しかしITの現場で求められるのは学術的なものではありません。ビジネスにおいてそれなりに使えればいいのです。そうなると要求されるスキルは限定的、底の浅いものになります。

それこそ、適切なライブラリをつかって、既存のツールを組み合わせればなんとかなったりする世界です。伝統工芸の職人さんみたいに10年とかの修業はいらない。

こうゆう背景を考えると、幅広くいろんな技術をプライベートで試せるスキル、要するに技術的な好奇心が尽きないエンジニアが最強という結論になります。

ではでは今日はこの辺で。

 

理想のIFなんてない件

歴史番組なんか見ていると、江戸時代の鎖国がなければ日本は100年早く近代化できたのに。。。

とかいうコメンテータがたまにおりますが、もうアホかと。。。

欧米以外の国では日本が世界で一番初めに近代化したのです。この事実を忘れていませんか?

似たようなロジックで思い出したんですが、もしヨーロッパ中世の暗黒時代がなければもっと早く近代科学が発達したのに残念だ。という文章を読んだことがあります。

でもご存知のように近代科学は西洋で生まれたのです。ということは結果から素直に考えれば

日本の近代化には鎖国が必要だったし、近代文明にはヨーロッパ中世が必要だった

という結論になるはずです。

まま、歴史の話は大きすぎるのでもう少し個人的な話に持っていきましょう。

私自身も、あの時ああしていれば。。。。とか過去を後悔することは結構あります。しかしちょっと冷静になって考えると、必ずしもそのIFでよりよい人生になったかどうかは誰にもワカリマセン。

日本の歴史に話をもどせば、もし幕府の鎖国政策がなかったら、日本はとっくに植民地になっていたかもしれないってことです。

ちなみに私がよく後悔するのは高校時代のことです。あることがきっかけで高校の教師とケンカして登校拒否しておりました。進学コースのそこそこ頭のいいクラスにいたので、友人の多くはMARCH以上の私大か、旧帝国立大に行っていました。

しかし私だけ無名の中堅私大に行くことになり、コンプレックスを抱えます。もしあの時頑張って高校に行っていたらもっといい学校に行けたのに。。。

でも、冷静に考えると高校は中退しないで、自宅で最低限の勉強は続けていたのです。また高校側もテストは受けにくるのでなぜか出席扱いにしてくれたり。

なので、無名でも大学にはかろうじて行けた。

もしあの時、高校中退で家に引きこもっていたら、今頃は中年ニートだったかもしれません。それは誰にもわからない。

どうもみんな過去のIFに関しては良い方にばかり考えがちです。でも、本当にそうでしょうか?

もし今の生活がまあまあ納得できるなら、これでよかったのだと考える方が精神衛生上いいと思いますよ。

ではでは今日はこの辺で

リトルエンディアンにハマった件

とあるデータ解析ライブラリを使用してハマったのでメモ

ライブラリ自体は数値を入れてやるとバイト形式の値が返ってくるものなのですが、どうも出力されたバイト出力をうまく解析できない。

データ自体は16進数の羅列なので、1バイトづつPHPのbase_convertを使って2進数化してやって、あとはお好みで処理すればいいのだが、なんかおかしいぞ。

うにゃうにゃ調べること1時間、これってリトルエンディアンじゃね?と気づき入れ替えをしてやったら出ましたよ。

ということでリトルインディアンに関して整理しておこう。ほぼWIKIの内容だす。

多バイトで構成されたデータをどうやって並べるかをインディアンと言う

インディアンにはリトルインディアンとビッグインディアンがある。

ビッグインディアンはデータをそのまま読んでいきます AA BB CC DD EE  とあれば AA BB CC DD EE の 順番で解析していく。

逆にリトルインディアンの場合は EE DD CC BB AA になります。要は逆さまに解析してくださいってことです。

なんでこんな処理が生まれたかというと、そうゆうCPUが売られているからw

CPUは1バイト単位のレジスタでデータを処理するのですが、インテル系のCPUはリトルエンディアン(逆さま)で読み込む仕様だかららしいです。

なんでわざわざ逆さまに。。。と思いますがもちろん気まぐれでそうしたわけではなくて、メリットがあるため。

私的な理解では逆さまにすると、下位のアドレスから先に読み込むことになるのでオフセットを気にしなくていいのが理由なのかと思います。

どうゆうことか超要約して説明します。説明用のお話なので間違っていても許して。

たとえば 00123  という値と00022  という値を足し算しましょう。

ビックエンディアンの場合、オフセット部分を常に意識してやらないといけないです。オフセットっていうのは、この場合は左側の0を意味します。なおCPUは左から値を読み込むルールとします。この場合

  00143
+00082
=00225

いつも左側の0の数を常に気にしないといけません。

もしこれがリトルインディアンだと0を気にしなくていいのです。

リトルエンディアンでは逆さまなので 34100   と  28000  の足し算をすることになります。CPUは左から読み込むので0は無視してよくて結局

  341
+28
=522

左詰めで計算しています。繰上げは右にシフト。最後に逆さまを戻すと 225となってビッグエンディアンと一致します。

どうも0を気にしなくてよいということはCPUにとっては計算が楽になるらしいようです。

まあリトルエンディアンがいいかビッグエンディアンがいいかなんでどうでもいいですけどね。わたしはC言語を使った組込み系の仕事をしないので、動けばそれでいいです。

でもプログラミングする際にバイト配列が出てきたらコイツは逆さまなのか?は常に意識しておきましょう。

フリーランスエンジニアの仕事の取り方

フリーでやっているならば、仕事を切れ間なく入れていくことが大事です。

仕事が無い=無収入ですので

では具体的にどうやって仕事を取ってくるかですが、エンジニアの場合は次の4つでしょう。

エージェントを利用する
エージェント利用の最大のメリットは案件の数が膨大にあることです。IT業界はまだまだ景気がよいので仕事に困ることはありません。

しかし、希望する現場につけるかどうかはスキルシート次第。あと多重派遣という違法行為がまかりとおっております。そこを納得できるかですね。

パートナと組む
私の場合は前職の同僚が多いのですが、要するに営業さんやWEBディレクターさん、若しくは制作会社さんと組んで仕事をする形です。

勝手知ったるパートナーと仕事を継続していくので、やりやすいです。一番オススメ。

でも、やりやすいのが仇となって、仕事が特定の人脈に固定されます。人間関係に何かあったら大変です。

案件を紹介してもらう
フリーのエンジニア仲間とか知人友人、ちょっとした知り合いから仕事を紹介してもらう形です。新規開拓にはこれが一番

でも、普通は紹介なんかしてくれませんよね。私だってしません。なので必ずキックバックすることを伝えましょう。

受注金額の2割を紹介料としてお支払いしますと言えば、思い出してくれる確率は高まります。

ただし、あくまで初回限りの紹介料ということで、再度の発注に関してはお支払しません。

ブログ・SNSから集客
これって結構大変です。今でも仕事の割合としてはほとんどないです。問い合わせはたまにありますがビジネスにはならないですね。

まだブログの集客力が弱いってもあるのですが、個人的には開発が必要な会社さんがエンジニアを直接ネットで探すってことはあまり無いんだと思います。

なので先に書いた、パートナーや案件の紹介者と、このブログをきかっけに知り合う形を目指しています。

名刺にこのブログのURLを記載しているので、直接会った人にブログを読んでもらって、もっと知ってもらうっていう使い方もしています。直接会った人は結構このブログを読んでくれているようです。

 

ブログには書きたいことを書けばいい件

今日はこのブログのスタンスをちょっと書いてみます。

実は私はこれまで2回ほどブログを立ち上げては閉鎖を繰り返しております。理由は簡単で、ネタが無くなるからです。

最初はプロマネの話題で書いていました。その次はAI系の話題で書いていました。でも

ネタ切れ=>放置=>誰も読まない=>閉鎖

を繰り返し。。。。

なのでもうテーマの縛りはしないことにしました。ブログのセオリーだと何か専門性がないと読者にメリットが無いからダメというお説教がありますが、そんなの無視無視

書き続けなければアクセスは集まらないのです。なので書きたいことを書きたい時に書くだけです。

記事の文字数も最低でも2000文字とか言われますが、そんな制約があると嫌になるのです。なので好きな長さの記事にします。

ただ、今日こんなもの食べたました!とか、こんなところ出かけたよ!なんて書いても誰も興味ないし、自分も書きたくないので、そうゆう意味なし記事はNGになってます。

ほとんど縛りがないのでプログラムの話から英語の話まで、脈絡なく書かれておりますがご理解のほどお願いします。

基本は何も変わってない件

今日はおっさんエンジニアのたわごとです。

タイトルの通りでIT技術は次から次に新しいものが出てきているのですが、実は基本は何も変わっていないのです。

例えば車で考えてみましょう。車を構成するのは

タイヤ  シャフト  エンジン ハンドル ブレーキ

これって車が生まれたと同時に生まれて、基本的な機能は変わっていません。

同様にITの世界も

2進数計算 CPU メモリ ディスク TCP/IP  HTTP

と、こちらも基本技術はここ20年でほとんど変わっていません。

変わっているのは開発言語や、ミドル以上で動くソフトウェアなのです。ハードの容量と速度が上がってきたので、それに合わせてソフトも進化しましたが基本的な部分は何も変わらず。

今ではクラウドとかAIとかが話題になっていますが、それも基本技術の延長線上で実現されているものです。

再度、車で例えると、ギアがオートマになったとかナビが付いたとか電装系が進化したとか、そんな感じです。

クルマの基本構造は何にも変わってない。

ということを前提にして、これからITエンジニアになりたい人に伝えたいのは、まずは基本的な知識を知っておく方がいいということ。

昔はパーツを組み合わせてパソコンを作ったりしましたが、今はノートが基本なので、ハードをじかに見る機会が減っています。特にサーバはクラウドが基本になっていくので、サーバというものが物理的なコンピュータであることすら理解できないかも。

だからこそ、基本的なITの構造を知っているかどうかで、エンジニアの伸びしろが変わってくると思う訳です。

基本構造を理解して使うのか、構造は理解してないけどとりあえず動かせますというのか。。。

今後、エンジニアにフルスタック的なスキルが求められていくのであれば、基本的な構造を網羅的に知っておかないとフルスタックな対応はできません。

では、どうすればいいか?

基本的な技術に関する書籍を10冊程度読めばよいと思います。重要なのは言葉を覚えるのではなくて、WIKIでもなんでも使って腑に落ちるところまで構造を理解することです。

まあ、優秀なエンジニアが少ない方が、私的にはライバルが減っていいんですけど、年を取ったので説教くさいことを書いてみました。