スイーツ（笑）と呼ばないで!!

古今東西、何かと何かを結びつけることができる人は重宝された。

古典的なものだけでも、それは、ヒトだったり、モノだったり、カネだったり、いろいろある。

その「結びつける」ことを「マッチング」と呼び、それを生業とするビジネスを「マッチングビジネス」と呼ぶならば、おそらくほとんどのビジネスはマッチングビジネスになるだろう。

我々のシステム開発も、システムを作りたいクライアントと、システムを開発できるスキルを持ったエンジニアを、マッチングさせるビジネスと捉えられる。そのために「法人格」や「雇用」と言ったメカニズムを単に利用しているにすぎない。

そんな中、Webの技術が発展したことにより、「マッチングサイト」というメカニズムを利用して、間に介在する専門家に頼らずにマッチングを行うというWebサイトがたくさん登場することになった。

完全に自動化されているものもあれば、メカニズムの信頼性を保つ為の監視だけは人力によるもの、さらにはマッチングを促進するサポートまで人力でするものなど、その自動化の程度には差異が見られた。

そうして出来上がったあるマッチングサイトが、最近、自動化されていた機能を廃止して、再び専門家による人力のマッチングに注力することを知った。

個人的には、これは一つの良い選択だと思う。

産業革命でもIT革命でも、技術革新によって利便性や効率性が急激に上昇した後では、必ず「人間にしかできないこと」を見直す「揺り戻し」がある。

人は対比することによって、逆にそのもの本来の価値を知ることができることも多い。
機械化やIT化されて初めてわかる人間の良さというのは必ずあるだろう。

それをビジネスの中核にするのは一つの正解だと思う。

弊社のコアコンピタンスも、実は、ここで働く人間である。

クライアントの無意識レベルのニーズまで汲み取るスキルを持ったSEと、色々な要素技術を組み合わせて成果物であるプログラムを作成するPGだ。

IT革命の最先端にいるシステム開発会社が、実は一番大事なものは人間である、と言うのは一見不思議かもしれないが、究極まで機械化やIT化によって効率化している我々だからこそ身にしみてわかる人間の大事さというのがある。

オープンソースや、いろいろなクラウドサービスなど、いろいろと便利なものが増えていて、ITエンジニアの未来について悲観的な観測を持つ人も多いが、我々は何も恐れていない。むしろ、それらは全て、我々のような「人間」を大事にするエンジニア集団の価値を引き立たせ再認識させることになるだろう。

未来は明るい。

ただし、大事な前提がある。

「人間にしかできないことをやり続けているか」

ということである。

昔は水はタダだったが今は有料で売られている。
今は「スマイル 0円」という感じで、タダでもらえる人間のスマイルの価格が、有料になり、機械で作らられたハンバーガーの価格を超える時代がいつか来るかもしれない。

そんな時代に生き残るエンジニアになるために大事なキーワードは「人間にしかできないこと」だと思う。

[0回]

• 技術系の話題
• COMMENT：0

昔、ノウハウよりもノウフー、という記事を書いた。

今日は、それの第二回。

あるデキる部下との、ある技術要素に関するコミュニケーション
　
————————————————————————
私「そこの部分は、前にLaracastsで取り上げていたと思うからそこ見てみて」
部下「あ、確かに見た記憶あります・・なんでしたっけ」

(二人して検索、数十秒後・・)

私「このシリーズだね。これの第22回から第24回がそれに関するところで、今回のはたぶん第24回だね。」
部下「あ、この第24回の、xx秒目のところがまさにそれですね」
私「そうだね、その近辺のところに詳しいやり方解説されているから見てやってみてねー」
部下「了解です」
————————————————————————
ああ・・超楽だ・・・このコミュニケーション。

まぁ、Laracastsは教材としてはちょっと特殊ですが、基本的には、「それはxxxに書いてあるので見てみて」で終えられるコミュニケーションは、時間的にも質的にもお互いにとってベスト。何もプロの代わりに自分で必死に下手な解説をする必要もないし、説明する時間も節約される。もちろん、見た上でわからなければフォローすれば良い。

そして、皆が新しいことでハマるのは、自分で有効な情報の置き場を見つけられないことが多いからだったりする。

(まぁ、今回の場合は、優秀な部下なのでこんなやりとりなくてもすぐ辿り着いただろうけど・・)

他にも「それはxxxがoooの案件でやったことがあるはずなので聞いてみて」とかってのも同じ。

技術の分野は幅広いので全てのノウハウを自分の中に蓄積してアウトプットするのはあまり効率的とは言えない。

コマンドでも、よく使うコマンドのオプションとかは頭に記憶しておいたほうが良いけど、たまにしか使わないものについては覚えるのではなくヘルプを引けば良い。

自分の頭の容量には限界があるので、優先順位をつけて記憶するようにしている。
技術情報とかであれば、例えばこんな感じ。

-------------------------------------------------------
◉優先順位

第1位　その技術の世界観

　確か、あの技術でこんなことができたような気がする・・という感覚。確かこんな機能があったよな・・とか。これはPGだけでなく、SEとしてお客さんと話をする時にも有効だ。お客さんの要望を聞きながら、「ああ、これはあの技術、それはあれだな」とか頭の中でイメージしながら聞けて、話を聞き終わったら大体の提案ができたりもする。引き出しの広さ、アドリブの提案力というのは、直感とかヒラメキによるものだろうけど、それらはすべてこの漠然とした世界観があってこそのものだと思う。

第2位　ノウフー

あることに関する情報を得るには、誰に聞くのが良いか、どこを見るのが良いか等についての知識。人に限らず、サイトや本なども含む。必要に応じて、自らその情報源から情報を引き出しても良いし、今回の例のように丸投げも可能だ。

第3位　使用頻度の高い技術ノウハウ

日常業務で使用頻度の高いものについては、記憶してしまったほうが良い。もしくは、真逆で、シェルを書いたり、エイリアスをきったりしてシステム化してしまう。これは徹底的にスピードと効率を重視する。慣れるまでは、大真面目に練習するのもアリだ。無意識レベルになっていると思うがブラインドタッチも最初は誰もいきなりはできなかったはず。大脳新皮質を使わず、小脳レベルでこなせるレベルまで持っていく。各ツールのショートカットなんかもそうだ。いちいち考えながらではなく、体が勝手に動くまで、大げさだけど素振りや空手のカタのつもりで取り組めば良い。

第4位　通常作業のノウハウ

機械化出来ず、毎日の作業の中心となる事柄に関するノウハウはこのレベルだ。頭の中の記憶や自分のノウハウ帳などからノウハウを引き出しなから、考えながら作業していく。
-------------------------------------------------------

これより優先順位が下のものについては、私はあまり記憶していない。どこかに自分向けに記録するか、そもそも記憶することを諦めて、ざっくりとした世界観だけ覚えておいて、あとはノウフーとしてのインデックスだけを記憶しておく。

ただ大事なのは、それらの情報自体は優先順位は低いが、世界観やノウフー情報は記憶の優先順位は高いということ、この辺が特殊なこだわりかもしれないなと思う。

ちなみに、よく「資格試験は意味があるかないか」みたいな議論を見かけるけど、上の話に照らし合わせてみると、

・資格試験の教材などは、その技術に関する世界観を掴むには、体系的な知識も得られるし効果的だと思う。

・資格試験に合格することは、もし、通常使用頻度の低いノウハウまで記憶する必要がありその分量が多いのであれば、優先順位は低く片手間にやるくらいで良いと思う。ただし、優先順位が低いだけで、やったらやった分の価値はあり無駄ではないと思う。

というのが私の考え。世の中に本当に無駄なものなんてあまりなくて、ただ、時間と予算の制約があるので、優先順位をつけて取り組む必要があるだけだと思う。

優先順位の低いことにとらわれて優先順位の高いことをおろそかにしたらダメだけど、優先順位の高いことをしっかりこなしつつ、その上で優先順位の低いこともこなしている人は、その分野においてより高みにいる人だと思うしとても尊敬をしている。両者は大きく異なる。前者が世の中に悪評を撒き散らし、後者まで軽んじられてしまうのは不幸だ。

なんだか収拾がつかない感じの文章になってきたので、今日はここまでにしようかと思う。

大事なことは、記憶できる量には限界があるので、何を記憶するのがより効率が良いか意識しながら動こうというお話。

[0回]

• 技術系の話題
• COMMENT：0

たまに、メールが届かないんだけど、とかって連絡があり調査をしたりすることがある。

今日は、そんな連絡を受けた部下とのOJTの一コマを紹介。

部下:「yamada@abc.comというメールアドレスに今朝7時に一斉送信されたメールが届かないらしいんですよね」

私:「なるほど。じゃ、エラーログを確認してみよう。サーバーにSSHでログインしてみて」

部下:「ログインしました」

私:「まず、ログはデフォルトだと/var/logの中にあるね。今回はmailの話なので/var/log/maillogを開いてみて」

部下: 「えっと、ファイルを開くのはcatコマンドですよね」

私:「そうだね、それで開けるけどそのままだと大量に表示されてしまうので、メールが届かないユーザーのemailアドレスで絞り込んでみよう」

$sudo cat maillog|grep yamada@abc.com

私: 「catコマンドでmaillogのファイルを開いた後で、パイプ(|の記号)でつないで、grepすれば良いね。」

部下: 「なるほど。結果を見ると確かにErrorとなっていますね。この人だけエラーになっているのでしょうか?」

私:「そういう時は、Errorという文字列でgrepしてみると良いね」

$sudo cat maillog|grep Error

部下:「なるほど….わっ! たくさん出てきましたね。何件くらいあるのでしょうか。」

私: 「そういう時は、wcコマンド(ワードカウント)に-l(ライン)というオプションをつけて実行すると良いね。そうすると行数を表示することができる。」

$sudo cat maillog|grep Error|wc -l

部下: 「なるほど。これで件数がわかるんですね。とてもたくさんありますね。あ、でもこれって同じ人宛のもありますよね。重複を排除したいですが、全部日時もバラバラだし整理するの無理ですよね。。」

私:「そういう時は、まずメールアドレスの部分だけを切り出すと良いね。そういう時に使えるのはcutコマンドだね。maillogはスペース区切りで項目がならんでいるから、-d(デリミタ)オプションにスペースを指定するね。そして、スペース区切りで7番目がメールアドレスだから-f(フィールド)オプションに7を与えれば良いね。」

$sudo cat maillog|grep Error|cut -d’ ‘ -f7

部下:「おお!!メールアドレスだけが表示されるようになりましたね。あとはこの時系列でならんでいるメールアドレスしかも重複ありのをどうすれば良いか。。。」

私:「そんな時はsort(並べ替え)コマンドを使うと良いね。これはアルファベット順で並べ替えてくれるよ。そして並べ替えた上で、uniq(ユニーク)コマンドを使えば、重複を排除したリストが手に入るね。先にcutコマンドでメールアドレスだけにして、sortで並べ替えているからこそuniqが有効に使えるんだね」

$sudo cat maillog|grep Error|cut -d’ ‘ -f7|sort|uniq

部下:「なるほどー。これで先方にエラーになっているメールアドレスのリストをお送りできますね。あれ、これ見ると@abc.comの人ばかりがエラーになっているようですね。@abc.comの人でエラーになっていない人っていますかね。。」

私:「そういう時は、grepで-vオプションを使うと良いね。これを使うと"含まない”という反対の絞り込みができるよ。つまり、-v Errorと書けばよいね。あとは、@abc.comを含むgrepを入れてあげれば良いね。」


$sudo cat maillog|grep -v Error|grep abc.com|cut -d’ ‘ -f7|sort|uniq

部下:「なるほど! お、この結果を見るとabc.comでもメールがエラーにならずきちんと送られている人がいますね。逆に、abc.com以外でエラーになっている人はいるのでしょうか。」

私:「それは、今度はabc.comの前に-vをつけて、Errorの前の-vを外してあげれば、abc.com以外でErrorのものが抽出できるね。」

$sudo cat maillog|grep Error|grep -v abc.com|cut -d’ ‘ -f7|sort|uniq

部下:「なるほど。そうやって応用すれば良いんですね。あれ?1件だけありますね。残念。。。あ、でもこれabc.COMとcomの部分が大文字になっていますね。これは登録したユーザーが間違っていますね」

私:「そうだね。ただ、それでもメールは届いたりするので間違いとは言えないね。そういう場合には大文字小文字を区別しない-i(ignore case)オプションをつけると良いね。」

$sudo cat maillog|grep Error|grep -i -v abc.com|cut -d’ ‘ -f7|sort|uniq

部下:「本当ですね。それだとabc.com以外でエラーになっているものの結果は無しとなりますね。ただ、0とは表示されないんですね。」

私:「人数を見たい場合は、最初の頃に教えたwc -lを使えば良いね」

◎abc.com以外でエラーになっている人数

$sudo cat maillog|grep Error|grep -i -v abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l

0人

◎abc.comでエラーになっている人数

$sudo cat maillog|grep Error|grep -i abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l

123人

◎abc.comでエラーになっていない人数

$sudo cat maillog|grep -v Error|grep -i abc.com|cut -d’ ‘ -f7|sort|uniq|wc -l

3,123人

私:「ということで、ここまでのメールログの解析から、

abc.com以外のドメイン宛のメールは全て正しく送信されている。
abc.comのドメイン宛のメールでも正しく送信されているものがある。

ということがわかるね。それぞれのリストや人数も把握できるね。

例えば、人数ではなく件数を出したいなら、途中で追加したsortとuniqを削れば良いね。
こうやって、コマンドをいろいろと組み合わせると、解析不可能に思える膨大なログの中から真実を突き止めることができね。これはapacheのログの解析とかにも使える技術なのでいろいろ勉強してみると良いと思うよ。」

部下:「しかし、linuxのコマンドって、こんなことできるんですねー。感動しました!!」




というようなOJTを必要に応じて部下にやっていたりします。

実案件で困っている時は部下も必死ですので、その困っている状況をさっと解決できる技術を目の当たりにすれば勉強しようというモチベーションも少しは上がるのかもしれません。

今回登場したコマンドはコマンドリファレンスを見れば全部載ってますし、オプションも--helpというオプションつけて各コマンドを実行すればすぐに確認できますね。ただ、リアルに直面している問題に対してどう組み合わせるかというところは、やっぱり先輩についてOJTで教えてもらうのが一番手っ取り早いかもしれません。その上で復習をしっかりとね。



今日も偉そうに自画自賛してしまいました(笑)

それでは、またいつか会いましょう^^

[0回]

• 技術系の話題
• COMMENT：0

最近、サクッと短いブログを書いています。

弊社では基本的にroot権限は弊社で管理していますし、
相当な事情がない限り、クライアントにサーバーへのアクセスを開放することはございません。

しかしながら、いろいろ大人の事情ですとか、
テンプレートと画像、cssなどについては自分たちで変更したい、
とかおっしゃるクライアントのために、開放せざるを得ないことは結構あったりします。

例えばクライアントがアクセスしたいディレクトリ構成が

/var/www/project_name/private/client/template
/var/www/project_name/public/client/css
/var/www/project_name/public/client/image

このような場合どうするでしょうか?

【レベル0】

「私たちがソースアップしているlinuxユーザーをクライアントに教えて使い回せば良いじゃん」

→ダメです。そんなことしたら、事故が起きた時の責任の所在も原因の追跡も困難になりますし、そもそも事故が起きる可能性がたかまります。

【レベル1】

「じゃ、プロジェクトのルートである/var/www/project_name/をホームディレクトリとする別ユーザーを作れば良いじゃん。その上で/var/www/project_name/private/client/と/var/www/project_name/public/client/にのみアクセスできるようにすれば良いよね。」

→ダメです。そもそもそれでは内部構造も丸見えですし、プロジェクトのルートにlinuxのユーザー管理に使うゴミファイル(SFTPを想定)がたくさん置かれることになります」

【レベル2】

「わかったよ。そこまでセキュリティとかうるさいなら、
/var/www/project_name/private/client/をホームディレクトリとするclient_privateと
/var/www/project_name/public/client/をホームディレクトリとするclinet_publicという二つのユーザーを作れば良いよね」

→それなら必要なアクセス権はなくなるけど、管理が煩雑だよね。それにFTPでなくSFTPでいくなら上記のようなゴミファイルの問題もあるし。

【レベル3】

「じゃ、どうすればいいの?」

→clientというlinuxユーザーを普通に作成します。ホームディレクトリは/home/clientです。で、/home/clientの下に、/var/www/project_name/private/client/へのシンボリックリンクのprivateと/var/www/project_name/public/client/へのシンボリックリンクのpublicをはれば良い。SFTPでそれでアクセスすればセキュリティの問題も特にないし最小限でかつ必要なものについてのアクセス権はある。


ということで個人的にはこのレベル3の方法が良いのではないかと思っています。

たまに、クライアント用に複数のファイルアップ用のユーザーを作っているプロジェクト(特にクライアント内部での権限の区別はない)を見かけます。

まぁ、いろいろと事情があるんだとは思いますが、特に深い理由がなければ、このような管理も良いのではないでしょうか。

[0回]

• 技術系の話題
• COMMENT：0

さっきTLSのバージョンの違いで困っている部下がいて説明したので、簡単に情報共有。

SSL/TLS のバージョンとしてはSSLv2とかTLSv1.2とかいくつかあるわけですが、
最近のサーバーだと例えばTLSの1.2じゃないと受け付けないよ、とかってセキュリティの設定が高めになっているものがあったりします。

で、それを簡単に確認する方法。

例えば、TLSのバージョン1.0で接続して確認するには

　#openssl s_client -connect ドメイン名:443 -tls1

とかってやると接続できます。

バージョン1.1 なら -tls1_1
バージョン1.2 なら -tls1_2

とかオプションつければ大丈夫です。

気軽に確認するには便利ですね。

s_client

は他にもいろいろ使い道があるので知っていると便利かもしれません。

ちなみに、詳しく知りたいなら

https://www.ipa.go.jp/files/000045645.pdf

この辺を読むと良いと思います。

[0回]

• 技術系の話題
• COMMENT：0