LAMPエンジニアってこういうもんでしょ

こういうもんでしょって話をつらつらと

「技術のこと教えてください」って言っている人に教えることなんて何もない

表題の通り
本日もポエムです。

友人との会話の中で出てきた話で
当たり前なのに当たり前にならないとても不思議な話だと思います。

 

何かの情報をインプットしようとした時に知識のある人から情報をもらおうとすること自体はとても良いことだと思います。
ただ、何も行動を起こしていない、自分で調べもしていない事に対して「教えてください」では、何を教えれば良いのかわからないわけです。
何を知りたいのかもどこまで知っているのかもわかりませんし、少なくとも検索エンジンがそういう場合に非常に有用な手段だという事を知らないということぐらいしかわかりません。
その場合に返す言葉は結局「ggrks」になってしまうのです。
これは冷たい返答ではなく、まず自分で調べるところから始めましょうという小学生にもよくわかる丁寧な返答です。
調べてみてわからなければ改めて訊いてみてください。
相対的に見てエンジニアの多くは技術の話が好きで教えたがりの人が多いです。
きっと必要の無い部分までたくさんのインプットを授けてくれるでしょう。

 

ここから蛇足です。
この話にはふたつの重要な要素があります。
ひとつは「能動的であるかどうか」
もうひとつは「初めの一歩を踏み出しているか」です。

「能動的であるかどうか」は知識の獲得の上で非常に重要です。
教育論を語る上でどうしても教える側のスキルに目がいきがちで
社内教育の多くは講師側の人間の技量を上げる事でうまくいくと思われている傾向があるように感じます。
しかし本当に重要なのは教育を受ける側のモチベーションだったりします。
人間の脳みそは興味のあることに対しての吸収は早いですし定着もしやすいですが
興味の無い事はほぼ覚えられないようにできているそうです。
能動的に知識を獲得しようとしている人は時間対効率が良く
受動的な人は非常に効率が悪いということです。
日本語で言い直せば
「教育を受けている人」は成長せず
「学習を行う人」はすぐに成長する、ということです。
本当に知識を獲得したいのであれば「教育を受けに行く」という行動ではなく
「調べて飲み込む」というステップの方が圧倒的に量も質も良い、ということになります。

もうひとつの「初めの一歩を踏み出しているか」の話は
ひと昔前に投資や融資の話で聞いた事がある話です。
事業の構想を持っている人が複数いる中で
素晴らしい事業を考えたけど無一文の人で5万円融資して欲しい人と
事業計画には多少穴があって100万円の貯金がある5000万円欲しい人であれば
後者の方が融資を受けやすいという話です。
これは「100万円を貯める」というステップに到達している人の方が
何もしていない人よりも信頼できる、ということらしいです。
また、綿密に練り上げられたサービスのプレゼンを上手にするよりも
プロトタイプを持っている人の方が投資を受けやすい、というのも同じ話かと思います。
何かを始める事にはとても労力がいりますが
何かを始める事ができない人には対価を与える事も応援することも難しいのです。
行動をして初めて得られるものがあるという事はビジネスの世界では常識です。
何も行動を起こしていないのに「知識をください」は当然通らない主張だとすぐにわかりますね。

 

不思議な話ですが
IT企業に勤めている人でエンジニアと業務上直接関わるエンジニア以外の職種の人で
平然と「技術のこと教えてください」と言うだけで何かを教えてもらえると思っている人が少なからずいるようです。
業務がスムーズにいくようにweb技術の基礎の話やプログラミングのワークショップなどは行う事もありますが
事業に関わる技術の領域は広く全てを伝える事は到底できません。
入口を提示してとっかかりを作ること
技術に触れる機会を増やすことが出来る精一杯だと感じています。
技術に限らず知識の獲得は、これだけ情報が氾濫している時代ですから容易なはずです。
その中で、正しい知識を精査し取り込む工程で知識のある人に教えを求めるのであれば理解できますが
能動的に動けない人には誰も手を差し伸べなくなるのは仕方ないことだと思います。

 

早く人間が働かなくても成立する世の中にならないかなと思っている末端のエンジニアのポエムでした。

「エンジニアに向いている人」ってどんな人なのか

最近エンジニアリングの教育資料をアップしているエンジニアを多く見かけるようになりました。
対象者は現職エンジニアと言うよりは、これからエンジニアになりたい人や、他職種ではあるけどエンジニアリングの勉強をしたい人、という切り口です。
システムやITというものが一般化してきて、システムやエンジニアリングに理解があった方がより質の高い生活が出来る、ということだと思います。
実際に学校教育の場でもプログラミングが必修科目になったりしていますし
時代の流れとしてはあっているのかなと思います。

ただ少し思うのは、仕事以外で関わるエンジニア以外の人は漠然と「必要になるかもしれない」という感覚はあるものの
自ら知識を取得しに行っていないということです。
エンジニアがエンジニアとして成立し続けられる理由は自ら学習し続けることにあると思いますし
それをしてこなかったエンジニアが新卒研修と現場での経験という貯金を切り崩し35歳で定年を迎えるのだと思っています。

開発業務はある意味孤独で、実験と発明と応用の繰り返しです。
過去のナレッジを使いまわせる事も多分にありますが、広い世の中から次々に新しい発明が生まれ
それを取り込めるのか、応用出来るのか、あるいは採用しないのかを日々考えながらの作業になります。
そうして作られた製品は一般化していき、ゆくゆくは「当たり前にあるもの」になっていくのだと思います。
プログラミングは日々簡単に書けるように進化していき、もうすぐ非エンジニア職の人がプログラミングをする時代になっていくのだと思いますし
その時にエンジニアリングのスキルがある事は大きなビハインドになるとは思うのですが
その一方で「新しい知識を習得し続ける」というサイクルが作れない人はあっという間に時代に置いていかれると思うのです。
逆に、今から職業エンジニアとして頑張りたいと思っている人は、最低限そこがクリア出来れば大きく可能性が広がるとすら感じます。

 

よく「頭の良さ」とか「論理的思考」とか「数学的な知見」とかが議論に上がりますが
職業エンジニアの多くは研究職ではなく作業者の側面が大きいです。
いかに製品を速く正確に出し続けられるかと、作った製品がどれだけの利益を生み出すかが給料に反映されていきます。
まだシステムエンジニアはたゆまぬ努力でお金が稼げる時代なのかなと思う一方で
エンジニアが夢見るエンジニアはもう少し先の時代に淘汰された先にあるのかなと思ったりします。

Railを捨てて荒野に繰り出す決断をした話

久しぶりの技術ネタです。
今の会社で1年前にRuby on Rails(以下RoR)を採択して
今まさにPHPへの移行を行おうとしています。
技術選定におけるあれこれについての反省を書き連ねて行ければと思います。


前提としてRoRはとても素晴らしいFWです。

RoR disってんのかよこのクソPHPerが!」
という声が聞こえてきそうなので念のため書いておきますが
RoRは本当に素晴らしいFWです。
基本をPHPとしつつPerlもJSもPythonも触ってきましたが
とてもしっかりとしたレールが轢かれていて
ライブラリも豊富にあり
web開発においてとても有力な選択肢のうちの一つだと思いました。
勉強しながらの開発ではありましたが
レールに乗って開発をする楽しさはなかなか面白いと感じる事が出来ました。


でも乗り換えるには理由がある

RoRにおける最大の問題としては
処理におけるブラックボックスが発生しやすいという事だと思います。
これはRubyの問題ではなくFWにおける問題の一つです。
うまくFWにはまっている開発を行う分には良いのですが
FWから逸脱した要件が発生した時にフルスタックフレームワークは牙を剥いて襲ってくるなと感じました。
PHPにおけるLaravelやSymfonyにおいても同様の問題は発生しがちです。
もちろんあらゆる問題を解決するために様々なモジュールやライブラリの開発が行われていますが
根本の解決に繋がらないケースやフレームワークの根底に対してチャレンジングな実装をしているものも多々あると感じます。
特に外部インスタンスに依存するようなAPI開発やNoSQL接続に関しては
かなり神経質にならないといけない上に
ライブラリに合わせて開発を進めてしまった後でライブラリの不具合や仕様要件不足
はたまた開発停止などでライブラリを乗り換えなくてはいけなくなった時に
本当の地獄の始まりをひしひしと感じます。


乗り換えにあたって重視した点

現在のシステムはAWS上で稼働しており
RDS、ElasticsearchService、mongoDB、外部API(http)との接続があります。
データが複数インスタンスに跨って管理されているものを
ひとつの業務システムのデータとして扱わなくてはいけないので
割とゴリゴリとした実装になりがちで
データの複雑性に耐えられる、かつ実装のスピードが確保出来る保守性の高いシステムでなくてはいけません。
技術選定にあたって今回気にしたのは

  • ライブラリの変更が容易である(フレームワークにロックインされない)
  • 技術情報が豊富にある(メジャーである)
  • エンジニアの誰かが中心になれる(詳しい人が内部にいる)
  • 採用が容易である(メジャーである)
  • ソースを追いやすい(困った時には外部から取り込んだライブラリでもソースを追うため)

という点です。


採択にあたっての決め手

選定における条件の中で「ライブラリの変更が容易である」という点を重視したため
今回はマイクロフレームワークを中心に考えることになりました。
社内のエンジニアの技術スタックの中で共通している言語はPHPとJSでしたが
「詳しい人がいる」という点でPHPが有力視されました。
また、過去の職場でマイクロフレームワークでの開発実績があり
今回の要件にマッチしそうという事でSlim3が最終的に選ばれました。
SlimはPHPフレームワークでroutingしか無い、という
マイクロフレームワークの中でもかなりマイクロな構造です。
過去のプロジェクトや個人的な開発のノウハウを投入して移行先のベースは作りましたが
各オブジェクトが疎結合な状態でテストをちゃんと回せる状態になっており
かつライブラリと自作部分を組み合わせて一般的なMVC構造になっているので学習コストも割と低いと思います。


今後の展望

PHPにおいて容易で学習コストが低い故に
低スキルエンジニアを量産してきた歴史がある事は否定できませんが
容易で学習コストが低いからこそ高度な事に手を出しやすいのが今のPHPの良い所だと思います。
もっと綺麗で見通しの良いコードが書ける言語も出てきていますし
どうしても言語特有のバグの問題や
WEBの世界にロックされがちでPHPのタグが気に入らないという意見も受け止めるべきだとは思いますが
食わず嫌いだけでPHPを避けるより
言語選定においてまだまだ有力な選択肢のひとつであるという事を知ってもらえればと思います。


いや本当はRuby使うならSinatraとか使えば良かったじゃんって話なんですけどね。
CodeIgniterじゃなくてSlimってところが今のシステムの悩ましいポイントです。