今後生きていけるソフトウェアエンジニアについて考えた
あっという間に年明けし、親戚周りや宴会で疲労気味です、こんばんわ_(:3」∠)_ 関係者各位におかれましては、2019年も引き続き、宜しくおねがいします。
さて、タイトルが若干主語大きめなのですが、ここ数年エンジニアの需要に動きがあるのでは？と個人的に思っています。
従来どおり依頼された仕様書に沿って作っていくエンジニア、の募集よりビジネスとTechを回せるエンジニアの求人が(体感的に)増えてきていると感じました。去年の転職活動でもいろんな企業を見てきたんですが、SESを収益の柱としている企業以外では、ほぼ確実にビジネスにどういう貢献ができるか？といった軸での採用基準があるように思います。
ビジネスへどういう貢献ができるか？ソフトウェアエンジニアであれば、自身が持っている技術を駆使してビジネス価値を作っていけるか？に言い直されます。
ソフトウェアエンジニアの人材不足という声がよく聞きます。その一方で仕様を元に作るだけのエンジニアの数は十分だ、という声も聞きます。
転職市場においてビジネスを創発できるエンジニアの需要が大きいという感覚が正しいのであれば、つまりビジネスを成長できる人材であることが、今後生きていけるエンジニアとして必要とされている能力なのかもしれません。
と、親戚周りでお酒を頂いていたときにふと感じた、雑多な書き起こしでした。
2018/12/31 気になった記事まとめ
今年も後数分で終わります。年末最後のまとめです。 毎年このタイミングで体調不良なのなんででしょうね？ _(:3」∠)_
slackクローンのOSS
私個人の使い方だとまだフリーなSlackで問題ないので使う予定はないんですが、いざSlackで足りない場合に選択肢があるのはいいですな(｀･ω･´)
行きたかったけどタイミングが合わなかったJetBrain Night
こうして当時のセッション動画が公開されるのいいですね。タイムライン見ていた限りだと貴重が多くあったとのことなので、正月時間があいたら見ておきたいとおもいます。
本日は時間が取れなかったのでこんなところで。
来年も宜しくおねがいします。
2018/12/30 あと1日で今年が終わるので振り返ってみる
早いもので今年もあと1日です。ここ数年で一番動きがあった一年だったと思いますな(´・ω・`)日本の中のことでもそうですし、私個人のことでもそうです。
今年はいろいろと環境が変わったりする一年でした。4年務めた会社をやめたり、今までやったことないEC系の会社に転職したり。入社してすぐリプレース開発にJoinして炎上と戦ったりと、新鮮な経験ができました。
後は、まあ住宅ローン背負ってしまったり( ﾟдﾟ)数千万が一瞬で口座を移動するあのヤバさを実感するなど。今後どう生きていくべきか改めて考える時期に来たのだと感じてます。
話は変わるんですが、今月の頭くらいから毎日ブログを更新する日課を課してきました。これまで気が向いたときにしか書いてなかったんですが、今後の人生考える上でアウトプットすることに慣れる必要があるんじゃないか？と最近特に感じてたんですよね。
度々、「今度は頑張って更新していくぞ！」とやる気を出したのですが続かず。なんとかいい文章を書こうという気負いも合ったかと思います。(8月-10月あたりの迷走っぷりはそのせいもある)
継続する意志を持って、まずはやってみる。それだけで20日ほど継続できる事実があるわけでして、やはり『やってみる』ことは大事。この学びがあるだけでも、来年はより成長できる一年になるんじゃないかな？と思います。
来年は今年以上に結果を出す一年にしたいです(｀･ω･´) 会社以外の成果をきちっと出して、自分の武器としていく。来年はそれを目指して生きていこうと考えています。
どんな一年になったか、来年の今頃改めて振り返る際に、期待以上の一年になったと感じられれば最高ですね。
2018/12/29 気になった記事まとめ
今年はいろいろありましたが、無事に仕事納めを迎えましたね。来年もgdgdだらりと生きていきたいと思いますこんばんわ。
ブロックチェーンはオフチェーンじゃないとつらいぞよ(´・ω・`)
ブロックチェーンでのサービスの作り方の用語解説のようですね。
以前、有料の勉強会でSolidity使ってEthereumのコントラクト書いた事あるんですが、ブロックチェーンで保存される変数、そうでない変数みたいな使い分けが面倒だった記憶があります(´・ω・`)
記事でも触れられてますが、一度デプロイすると原則修正できないです。バグが有っても修正できない_(:3」∠)_
設計やテストをしっかりやって、完全な状態で出さないと行けないので、実際にやるときは注意する必要があります。開発者用のネットワークがあり、そこでお試しできるのが救いですかねー。
個人的に触ってて一番たいへんだったのは、トランザクションの完了が遅いところ。一般的なWEBアプリ的なものを全部ブロックチェーンでやろうとすると、まともに処理できないアプリが生まれてしまうので、本当にブロックチェーンを適用すべき場所を見極める必要があります。
いろいろと運用の癖や課題もあります。以下は結構参考になりそうです。
GraphQLでのアップロード
以前、諦めて普通にRestで処理するようにした記憶が(´・ω・`)
最近、弊社でもGraphQL採用のMicroservice増え始めたんですが、運良くReadしかないのあんまり困っていませんでした。ファイルアップロードするときの良い知見
そういえばあったよTracePoint
これまであまり使い方わからなくて触れてなかったんですが、ブレークポイントを気軽に貼るやりかたいいですね。
いちいちbinding.pry埋め込んでましたよ(´・ω・`) これがあれば動的に差し込めるので、「あ、ここブレークポイント貼って動かしたいな」と思ったときにさっと晴れると、いちいちコード書き直す必要もなく楽に調査できそうですね。
Transient Heapについては、ずいぶんピーキーだなぁという印象。
theap で一度に確保できる領域は 2KB に制限しています。このサイズに何か根拠があったわけではなく、当てずっぽうです。もしサイズを超える場合は、最初から malloc() して、theap を利用しないようにします。
Railsで普通に使っていると、2KB以内で収まるものってあんまりない気がします。それこそ使い捨ての変数くらいで、一番生成されるんじゃないかと思われるActiveRecordモデルのインスタンスだとほぼ確実に超えそうですし...
うまく付き合う方法を模索してきたいですね(｀･ω･´)
開発用DockerでのDBの初期設定について考える
最近、本腰入れて個人開発はじめました。 ちょっと今のブログが使い勝手よくないんで、CMS付きのブログサービスを作ろうかと(｀･ω･´)
さて、今の時代開発環境を構築するにはDockerという便利なものがあります。 諸々の初期設定が出来合いで用意されているので、開発着手までが以前より素早く行えるようになります。いい時代ですね。
さて、今回はCMS付きブログサービスをつくるのでDBは必須です。まあMysqlになりますかね。
もし需要あってサービスインする場合でも、即AWSAuroraに載せられるので楽に運用できますし。
さて、それでは開発を、といったところですが、Database作ったり、アクセスユーザー用のGrant発行したりといった細かな作業する必要あるんですよね(´・ω・`) 今回はDockerつかってScrap＆Buildが繰り返されるので、毎回この作業するの面倒です。
mysqlに関して言えば、公式イメージを使うことで、コンテナ側の/docker-entrypoint-initdb.d以下ファイルを読み込んで、初期設定できる機能があります。
https://hub.docker.com/_/mysql/
この説明の中に、Initializing a fresh instanceの項がありますが、そこに
When a container is started for the first time
とあり、containerの最初の起動時に一度だけ呼ばれるようです。実行できるのは
で、これを用いればDB作ってユーザー権限付与して、SQL dumpから初期データ作成等できますね(｀･ω･´)
実際に呼び出されるタイミングは、
で、この、docker-entrypoint.shはDockerfileの
mysql/Dockerfile at 696fc899126ae00771b5d87bdadae836e704ae7d · docker-library/mysql · GitHub
で呼ばれています。つまり、イメージをビルドしたタイミングで呼んでくれるので、containerの最初の起動時に一度だけの動きをしてくれるみたいですね。良く出来てて、とてもいい(｀･ω･´)
実はMongoDBも使おうと思って調べてたんですが、こちらにも同じような仕組みがあって、
https://hub.docker.com/_/mongo/
This variable allows you to specify the name of a database to be used for creation scripts in /docker-entrypoint-initdb.d/*.js (see Initializing a fresh instance below). MongoDB is fundamentally designed for "create on first use", so if you do not insert data with your JavaScript files, then no database is created.
こちらはjsで実装する形になりますが、同じように初期化処理が実現できるようです。
2018/12/27 気になった記事まとめ
年末、忘年会シーズン真っ只中ですね。 酒あんまり飲まないように言われてるんですが、この時期だとどうしても酒量増えちゃいますね。自重自重。
最近のAuthenticationの動きがわかるやつ
こういう基準があるので、自分や自社でサービスやるときは準拠しておいた方がよさそうですね。 多要素認証にもいろんな決まり事があるのを初めて知りました。再認証の有効期限とか特に。
パスワードの定期変更が推奨されなくなったり、秘密の質問が完全廃止されたりと、これまで当たり前のように使われていたものが推奨されなくなってますね。これまでそれ使っていたサービスは認証の置き換えを考えることが必要になってくると思うんですが、そんな昔のサービスだと認証関わった人が辞めてたりするので、大変そうだなーと思います(´・ω・`)
楽しむための働き方
勉強と趣味と仕事が全て両立できる仕事なんてあれば、人生とても豊かに過ごせそうです。 出勤嫌がったり、難しい仕事を避けがちな仕事と比較して、ソフトウェアを含む全てのエンジニアは、趣味と学習を両立できる希少な仕事だと思います。自分の趣味等と合致していれば苦もなくやっていけますよね(｀･ω･´)
学んだことを発信し続けていれば、それがメリットとなる企業から声かかったり、自分から企画持ち込みしたり、それが巡り巡って面白い仕事が回ってくる。いいですね。
おちんぎんを増やす技術 - 無気力生活 (ノ ´ω｀)ノ ~゜ でも書いたんですが、経験少なくても飛び込んでいってスキルを得る話に近いような印象です。スキルを得てやれることを増やし、さらに新しいことを学んで、それを必要とする会社に売り込みかける。面白い仕事を得るためにはそれをできるだけの能力を示さないといけない。重要なことですね。
この話読んでいて、これちゃんと考えなきゃいけないなーと思ったのは、自分のポジショニングですかね。どんな技術に強くて何ができるのか。仕事ではバックエンド触ったり、フロント書いたり、Unity書いたり、データ基盤触ったり、開発フローの構築したり、ゲームプランナーやったりしたんですが、特にこれが強いってやつが見つかってないんですよ(´・ω・`)
自分が将来どんなことをやりたいかを明確にして、それに関するアウトプットをしていくこと。そこ頑張らないな、と思います。
文化が異なる人と全く同一認識を持つのは難しい
東京は本格的な冬の寒さが訪れ、株価の下落も合わせて心身ともに寒い今日このごろです_(:3」∠)_ ガッツリ損食らってるので、今年はおとなしく損益通算処理したいと思います。ああ無情。
転職した会社が比較的体質の古めな企業で、テック全く理解してない人と話すことが増えたんですが、かなりしんどさを感じてます(´・ω・`)本来であれば一言で言えることを何度も呼ばれて説明しなくてはならず、それでも理解してもらえないのでとても大変です。AWSのカスタマーアグリメントを共有しても「事業者はどの会社ですか？」とか聞かれるのはちょっと....
同じ会社の中ですが部署職種によって文化が異なり、前提知識も異なるのは理解してるんですけどねー(´・ω・`)なるべく技術触れて無くてもわかるような説明をする努力が足らんのか、なんなのか。
人はその環境によって考えは変わる
とあるように、我々人間がなにかを認識するとき、同じものを見ても各々が異なる解釈をしてしまいがちです(´・ω・`) その人が持っている知識、触れている文化、これまで生きてきた環境によって異なり、みなが同じ認識を持つことは大変難しい。
最近英語のヒアリング練習を兼ねて字幕付きTED動画を見ることがあるんですが、この話は、人が触れている文化によって人間の認知が異なることを説明されています。
紹介されている色の見分け方の話ですが、英語ではBlueと青を一つで表すのに対し、ロシア語では細かな青の色違いでも名前があるそうです。青色でも区別した色名がある。
仮に、ロシア人とデパートのハンカチ売り場にいると仮定しましょう。そこでロシア人に「青のハンカチを選んで」とお願いした場合、この時お互いに同じ彩度・明度の青色が浮かぶでしょうか？おそらく無理だと思います。相手にとって青色の選択肢は多く、単に青と言われた場合頭に多くの選択肢が浮かぶでしょう。同じ認識を持つことは難しいです。
同じ文化や国であっても、生まれの年代が違えば、言葉一つとっても各々で異なる認識が生まれます。例えば、『携帯電話』という言葉から、20代の若者世代と、60代のシニア世代で浮かぶものは同じでしょうか？きっと最初に浮かぶものは違うと思います。生まれの年代が違うだけも同じ認識を得ることは難しい。
では、どのように考えるべきか
単に言葉を与えるだけでは、同じ認識に至ることはありません。お互いが持っている認識のズレを合わせて行く以外方法がないと思います。しかしいくら説明しても擦り合わないこともままあります。このようなとき、どのような打ち手を考えるべきなんでしょうか？
エンジニアの知的生産術という本を読んでいます。
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
この本の第六章に抽象概念を引き出す『Clean Language』、『Symbolic Modeling』といった手法が説明されています。相手が何を考えているか引き出すために、以下の5つの質問を定式化したそうです。
①そのXはどんな種類のXですか？
②そのXについて、ほかに何がありますか？
③そのXはどこにありますか？
④そのXはどのあたりにありますか？
⑤そのXは何のようですか？
その時の状況に応じて問いかけの言葉は変わるとのことですが、このような質問を繰り返して、その抽象的な認識を言葉によって可視化します。その過程で必要条件や意図が引き出され最終的にお互いが近しい認識を持つことができると理解しました。
冒頭のAWSわからない問題に対しても
- 相手は今どんな認識を持っているのか？
- それは自分の認識とどれだけ乖離があるのか？
- 相手がわからないことはなにか？
- 相手は、それを知ることで何を得たいのか？
- 本当に相手が知ることで、問題は解決するのか？
といった問を提示することで、お互いの認識のどこが合っていて、どうなっていないのかが見えてきます。
問いかけを行うことで情報が精査され、お互いが理解できる落とし所まで持っていける。人と共通の認識を持つためには歩み寄り引き出すことが大切だと感じました。
まとめ
対話を諦めず、相手のわからないことに寄り添ってあげると良いんだろうなぁ(´・ω・`) 私の努力不足でした、残念。というオチです_(:3」∠)_
