過去より未来に近い今

30オーバーでも始めるには今より遅いことはない。育児と技術両方諦めないようにアウトプット。

エンジニアとして食っていく方法@TECHPLAY Academy 参加レポ

エンジニアとして今後食っていきたいと思っているのと、登壇者に及川さんがいらっしゃったので、参加。

似たような内容は他でも聞くことはあったが、今回の参加ではその内容が自分の中で腹落ちしてくることが多く、アウトプット駆動を加速させようと決意した(賞味期限3日※後述)

TL;DR

エンジニアの人材不足やその中でどんな人材が求められ、価値ある人材になるためにはNot only coding, but also xxxである。

  • どんなエンジニアが求められるか?=コード書いているだけでなく、開発のあらゆるフェーズでオーナーシップを発揮できる。

  • エンジニアとしての成長サイクル。学習→知識→技能へ昇華させていく。

  • 自分の置かれた環境を変えるより、自分が変わる、自分のいる環境を変える方が早い。嘆いていないで行動すべし。

  • 技術だけでなく組み合わせで希少人材になる。

  • ITと何かの組み合わせは面白いことが起きる。ビジネスに技術を組み合わせた視点で見ると面白い。

参加目的、何をしたくて参加したか?

  • 35歳、SIer所属エンジニアの生存戦略を考える参考にしたい。

  • エンジニアと言っても、様々な役割ができてきた中で生存していく選択肢としてどう考えるのかの参考にしたい=キャリアパスに悩む状態を次に進めたい。

刺さったキーワード

※言っていたとおりに聞き取れていなかったらすいません・・・。

エンジニアと言われると今の自分は微妙な立場ではあるが、エンジニアでなくてももう少し広い面で技術者であり続けたい。 by 及川卓也さん

めちゃくちゃかっこいいと思った。ほんとそう思う。

決意には賞味期限がある。それは3日ぐらい。 by 許 直人さん

賞味期限実感あった。でもこうやって強い人が明言すると期限を強く意識するようになる。

会社を清算することを経験した時に所属していたエンジニアは他社へ移ったが、自分は残った。当時の社長からエンジニアとしてはまだまだだが、エンジニアだけでなく、マーケティングもできるから残した。それ以来スキルを面で捉えている。 by 許 直人さん

以前及川さんの別のところの話で人材の希少性をベクトルで捉える話を思い出した。実例伴って、かつエンジニアとしての技術力の自分の立ち位置を意識するようになっていたので、更に刺さった。希少人材になり、価値を出したい。

呼吸法と同じ。吐いてから吸う。アウトプットから始まりなので、アウトプットから考える。 by 及川卓也さん

すいません、インプット駆動に逃げてました・・・。アウトプット駆動する。--> とりあえずAdvent Calendarに参加することにした。今年中にどこかで登壇もしたい。

レポ

活躍するエンジニアの条件 及川 卓也さん

日本のプログラミング教育の話から米国のプログラミング教育とプログラミングが貧困を抜け出す手段として広く受け入れられ、事実米国でのソフトウェアエンジニアの価値=年収の高い実情を順を追って説明されていた。

ソフトウェアエンジニアが年収が高いのは価値を生み出しているからであり、価値を生み出すエンジニアとはSIerにある開発者と設計者を分ける、上流、下流などと分けて、要件も自分たちで決めないようなものではなく、ビジネスにコミットしていく=開発のあらゆるフェーズでオーナーシップを発揮し、プロダクト・サービスを考えられる技術好きなエンジニアである。

そして求人で見るような「経験年数◯年」というのは経験≠過ごした時間、ではなく経験=技能としてのレベルを意味しているので、年数足りないからとビビるのではなく、技能を磨け、ということであった。

IT技術者の不足はよく聞く話で、また求人倍率がIT関係は非常に高いということも知っていたが、それは単にITやってきた人、IT得意な人という意味の数字ではないだろうな、とはモヤモヤっと考えていた。今回話を聞いて、この数字に表現されている人材というのがどういうことを求められているのか、そしてそれはなぜなのか?についてわかりやすく、頭が整理された。

日本のエンジニアの給与や待遇はSIerの人月商売の影響で未だまだそれほど高いものではないが、今後はその求められる価値が高まることに合わせて給与や待遇も上がっていくように思う。(徐々にそのような傾向が出てきているらしい。) 技能を磨き続けることについては個人的には面白いし、勉強会やインターネットなどこんなに恵まれた職業はないのではないか?と思っている。ただ、好きでやっていることでも高い価値を生み出せるのであれば、それを評価してもらえる社会であってほしいと思う。

美容師からエンジニアへの転身 許 直人さん

ご自身の置かれた状況からいかにして技能を積み上げ、市場価値の高いエンジニアになってきたか、という話。

正直自分とは大きく異なるのでいろんな意味で「すげー・・・」という感想だったが、その中でも以下のポイントは自分の行動にできそう。

  • 定期的に自分のスキルセットを棚卸しして転職エージェントにどのぐらいの価値評価されるかを確認する。

  • 仕事の一部を技術への投資へ回す(食っていくための仕事だけをやるのではなくて、できるかできないかわからないことをやって、常に価値を高めていく)。競争にさらされている意識を持ち続ける。

  • 自分に何ができるか考え、自分から取りに行く。

自分の仕事の中に食っていくための仕事以外を盛り込んじゃおう、というのは最近意識的にしているが、やや後ろめたさのようなものを感じていたが、このように強い人が言ってくれると「だよね!」という気持ちになる。また単に仕事中にプライベートなことをやっているというわけではなく、そういう仕事の仕方をしていくということ自体がその組織に貢献することにもなる、と聞いていて思った。

パネルディスカッション

いろいろ出たが一部自分にとって気付きとなったポイント。

  • SIerでぬるま湯と感じていたときも社内ではなく、外に目を向けていたことで危機感を持ち続けた。それがモチベーションになった。

今私もこの状態。食っていく仕事は余裕を持ってこなせるが、市場価値で見た時の自分が怖い。この危機感を持つために社外との接点は持ち続けるべき。たぶんそれはSIerに限らず、web系でも言えると思っている。

  • 自分を追い込むことで行動せざるを得ない状況をつくることも一つの手である。ただ、年齢が高くなると家族が増えたりでチャレンジするリスクが高くなるのは間違いない。

保育園の点数大事・・・。と思ってしまう今日この頃。

  • 意志が強くない、大きなリスクを取れない場合ではとにかくアウトプットから始めることが大事。学習だけでは技能に昇華しないので、とにかくアウトプットが先で、必要なインプットを入れていくというサイクルを作る。

  • アウトプットの種類は登壇、LTなどいろいろある。勉強会も盛んなので参加すればいいが、受け身で参加するのではなく、常に質問するつもりで話を聞け。

勉強会に参加して満足してしまっていた部分はあるので猛省。今回参加目的を再確認して質問させてもらったが、質問力弱かったな。

  • 困ったら公式ドキュメント読め。英語の方が最新なので英語頑張れ。またトライアンドエラーでやっていってみるのもあり。

  • 面としてのスキルセットを持ったエンジニア(技術者)の方が希少化しやすい。エンジニアでもプロダクトマネージャーやスクラムマスターなどいろいろあると思うが、チームの人とちゃんと話せるレベルの技術は最低限備えた上で、あとは自分が好きになれたものをやっていけばよい。

キャリアを考える上での技術力の最低ラインが認識できた。もちろんそこでいいと思わないし、技術を知ることは好きだし、どんどん様変わりするので、成長し続けていく必要があるが、指針が得られた。

  • 職業エンジニア=仕事でしかコーディングしない、プライベートでコーディングなどしていると変人扱いしてくるエンジニア、はどこかに行って、技術好きなエンジニアばかりになるといい。

いつになるかわからないが、求められる価値が高まれば自然とそうなりそう。そしてその時自分はエンジニア、技術者としていたい、と思った。

すくすく!子育てエンジニアMeetp#3に参加してきた

現在3歳&0歳の子供がいる身として気になっていた勉強会へ参加してきた。

子育てエンジニアというネーミングでもある通り、父母の方々が多く、他の勉強会にはないほっこりした雰囲気の勉強会だった。

すくすく!子育てエンジニアMeetupとは?

イベント概要から抜粋。

・家庭や育児においてもっとエンジニアリングで何か出来るのではないか?と思ったことはありませんか?

・困っていることがあるのだけど、実はこれは何か解決出来るツールを作っている人がいるのではないか?

・今後、こういった困り事が出るから今のうちにツールを作っておいたほうがいいと伝えたい。

そういった家庭や育児におけるtipsを皆で共有しようという場です。 そこで得たナレッジを家庭で共有し、さらによくしていこうという集まりです。

家庭や育児をエンジニアリングでサポート、そのノウハウを共有しよう、という集まりということだった。

家庭や育児など身近な部分をエンジニアリングで良くしていこう、というのは課題解決の敷居としてアプローチしやすい&自分事なので、当事者としての課題設定がしやすい、という面がある一方、実はこういう家庭内でのエンジニア的なアプローチは共有される場面が少ないように感じていたので、このような集まりを企画していただいたのは非常にありがたい。

#3の開催概要

場所:マネーフォワード社新オフィス(田町)

21階ということもあり、夜景が綺麗に見えた。新しいオフィスとのことで全体的にきれいでおしゃれだった。

エンジニアの勉強会としては珍しく、子供向けのお土産あり、黒烏龍茶などの健康配慮された飲料の提供(アルコールはなし)ということで、奥様マネジメント的には好感度が高い運営となっていた。

勉強会で得たこと

身近な課題、悩みを考え方含め整理して、解決するアプローチを複数の事例で伺えた。自分でもちょっとした「こうなっていればいいな」と思うことがエンジニアリングで解決する課題設定になるのだと気づけたのはアウトプットを増やしたい思いと家庭内でもやることをやる必要があるということを両立できるチャンスだな、と思った。

以下、それぞれの発表ごとでの気付きなど。

発表枠(1):tknzk さん

  • VUIを使った育児ログの記録についての話

我が家にもVUI端末があるのだが、イマイチ利用しきれていない。IFTTTとそれだけだと不足する部分はスクリプトを書いて補うというTipsは参考になった。IFTTTなど使えるものは使ってなるべく楽することも時間がない子育てエンジニアには必要なTipsだな、と感じた。

発表枠(2):おおやまみちのくさん

  • Scrapboxを家庭に導入された話

私自体はScrapboxは利用したことがあったが、現在はNotionへ移行している。そのため、ある程度使い心地は知っているつもりだったが、リンク機能や地図などのデモを拝見して、確かに子供とのお出かけ計画などには非常に便利かもしれない、と感じた。

ただ我が家の場合、奥様マネジメント的に利用してもらう敷居が高そう。

発表枠(3):Yuu Ito さん

  • 夫婦でお買い物アプリを作った話

ご夫婦共にエンジニアで、買い物リストの共有が既存サービスでイマイチはまらなかったからアプリを開発されたそうだ。他の人に利用してもらうと環境によってはそれほど効果が出なかったが、ご夫婦にはハマって効果が出たということだった。家庭内のやり取りやその家族の悩みどころというのは世界で1つ、とまではいかないが、ある程度ニッチな悩みになるのかもしれない、と感じた。その時それをエンジニアリングで解決する、という方法はありで、またそのニッチな悩みは世の中にある程度同じ境遇の人がいるような気がした。

アプリを公開されるかもしれないとのことだったが、自分の悩みやその解決方法も他の誰かの役に立つのかもしれないと考えさせられた。

発表枠(4):chocopie116さん

  • 音声を拾うことで奥様の大変度合いを感じる仕組みを作られた話&家庭内マネジメントについての話

TDDを元にした奥様サイクルや家庭内の負のスパイラルの話などエンジニアリング以前に把握しておくべき考え方の話があり、頷く内容だった。よくエンジニアは作ることばかり考えるのではなく、作らずに済むことも考える必要があるという話があるが、抱っこを変わる、アイスのお土産で喜ばすなどはまさにこれに当たる内容で、なんでも何か作ればいいと思ってはいけないな、と感じた。

その上で音声を拾い、それをモニタリング、しきい値を超えるとアラートが上がる仕組みを入れ、赤ちゃんの泣き状況を把握する仕組みを構築され、奥様の大変な状況を共有するということを実施されているというのは家庭内でのエンジニアリングの事例としては自分では思いつかない内容だった。

発表枠(5):shikicheeさん

  • 妊娠されて不安な奥様に対して準備したことの話

家事の外注、家庭内カフェ化=作業効率を上げる環境の構築、Trelloを使った献立管理、保活の実体験として利用した資料や検討の仕方のお話。

我が家の場合Trelloを奥さんに使ってもらうのは敷居が高いなどなかなか展開できそうにないが、webサービスとして保育関係の情報が結構出ている(東京だけかもしれないが・・・)というのは参考になった。

次回に向けて

全体的に子供の紹介が出るとみんなでニコニコしたり、登壇内容も既存サービスを家庭で適用した事例紹介や、家庭内Tipsや自身で開発したものを育児などに活かした話など幅が広く、登壇しやすい雰囲気であった。

次回はチャンスが有れば登壇にチャレンジしてみたい。

Google Apps Scriptをローカルでコーディングするためにclaspを導入した

Google Apps Script(以下GAS)は便利なので、業務効率化のために利用することが多いが、標準のオンライン開発環境だとコーディング補助や静的解析が弱いので、ローカルでコーディングできないものか?と思っていた。

調べてみると少し前から「clasp」というCLIツールがgoogleより提供されており、これを利用するとローカル環境での開発が可能となることから入れてみた。

環境

参考資料

qiita.com

qiita.com

qiita.com

claspとは?

googleから提供されているCLIツール。これを使うとGASのプロジェクトを作成したり、G Suiteからソースをpullしたり、pushしたり、バージョン作成やバージョン確認が可能となる。

claspを使って何が嬉しいのか?

  • GASは便利だが、web上の開発ツールだとちょっとしたところが足りない。それがローカル環境だと自分の慣れた環境で開発できる。

  • GASはほぼJavaScriptなので、JavaScript的補完が効き、開発効率UP。

  • gitなどでソースのバージョン管理できる。

  • GASはWindows officeでいうところのVisual Basicなので、なんとなく開発と言い切れない部分がローカル環境の開発ツール使って(黒い画面で)操作しているとかっこよく、開発しているっぽさが増す。

claspを入れてみよう

  1. node.jsとnpmのインストール

  2. npmを使ってclaspを導入

$ npm i @google/clasp -g
  1. GAS APIをONにする

このあたりは参考リンクを参照。

  1. clasp loginする

ログインするとwebでいつものグーグルの認証画面が出るので認証を通す。するとwindowsの場合、ユーザーのhomeディレクトリ直下に

.clasprc.json

というjsonファイルが作成される。

$ clasp logout

とするとログアウトするのだが、この時login時に作成された

.clasprc.json

が削除されている。

つまりこのファイルが認証情報になっている様子。

ちなみに自分の環境では上記のlogoutコマンドを叩かない限り、PCそのもののシャットダウンなどをしてもjsonファイルは残り続けており、かつclasp loginせずにいきなりclaspコマンドが利用できた。

claspを使った自分流のローカル開発環境の実現

  • ざっくりした開発の流れ

    1. cloneまたはcreateでプロジェクトを作る

    2. gitリポジトリ作成

    3. VSCodeで開発

    4. Gitステージング→コミット

    5. clasp push

    6. G Suite上でデバッグ

      • この時エラーが出るなど修正があれば、3-5を繰り返す
    7. 正常に動けばclasp version 'hogehoge'でバージョン作成

claspで疑問に思ったこととその確認した結果

  • GASプロジェクトを切り替えるにはどうしたらいいのだろうか?

    参考にした資料でもgoogleのclasp説明資料でもイマイチよくわからなかったので、いろいろ試してみた。

    その結果、最初にcreateまたはcloneをすると

    .clasp.json

    というファイルがカレントディレクトリに作成されるのだが、この中にスクリプトIDが記載されていて、その設定ファイルを処理時に参照してGASと紐づけて処理していることが判明した。

    つまり、プロジェクトの切り替えは特別なコマンドで操作する、などではなく、単純にカレントディレクトリを移動するだけでよかった。

    具体的には以下のようなディレクトリ構成があったとする。

    gas

    ├ gasprojectA

    │ └ .clasp.json

    │ └ hoge.js

    └ gasprojectB

      └ .clasp.json

      └ hogeB.js

    作業時にgasprojectAとgasprojectBを交互に操作したい場合があったとしたら、コマンドプロンプトでカレントディレクトリを都度移動して、claspコマンドを打てば、そのカレントディレクトリにあるjsonファイルに記載されたスクリプトIDに紐づくGASプロジェクトに対して、カレントディレクトリ内のファイルをやり取りしてくれる、ということ。

  • ローカル環境でどのようなディレクトリ管理がよいか?

    参考にしたリンクにはGASのjsファイルに「/」を入れるとclasp pullした時にディレクトリ階層にしてくれるとあるのだが、この「/」があることがもやもやしてしまい、結果自分はローカル環境でそれぞれプロジェクトごとにディレクトリを作成して、そのディレクトリ内にcloneすることにした。

例としては上記のプロジェクト切り替えの通り。

これでwebのGAS上でも「/」がなく、かつGASプロジェクトごとにディレクトリが分割しているので、gitリポジトリもそれぞれ個別で作成可能となった。

claspでもやはりまだイマイチな点

  • pushしないとイマイチデバッグができない

    GASにもよると思うが、スプレッドシートとセットなどG Suiteのサービスとセットになっている場合が多いため、ローカルでの動作確認には限界がある。

  • ネットワーク環境にもよると思われるが、処理に時間がかかる

    もしかしたら都度json見に行っているから?自分のネットワーク環境もあるので、これはイマイチ原因はわからないが、webでコーディングしてそのまま動かす、というclasp利用なしと比べるとこの点はどうしても劣る。

なんだかんだでclaspいいよ

イマイチな部分はあるが、やはりローカル環境での開発とgitでのバージョン管理ができるのはよい。

最近はGASのコンソール画面もあり、webでできることも一覧で確認する方法も充実してきているので、web上でのサービスとclaspと組み合わせると結構幸せなGASライフを送れる。

G Suiteを利用して、GASでなにかしている人にはclaspオススメ。

Djangoのmigrateでハマった

Djangoのmigrateでハマったので、その内容と解決方法をメモ。

背景

Djnagoのオンラインコースが一通り完了したので、参考にしつつ、自分で別のアプリケーションを作成することにした。 models.pyで定義後、一度makemigrationsとmigrateを実行し、adminサイトで確認したところ、想定していたデータベース構成と異なる部分があったので、models.pyを修正し、再度migrationをしようとしたところエラーが発生した。

発生事象①

makemigrationsしたところ以下のエラーが発生。

f:id:gohh56:20181003004742p:plain

作成したmodelの中でデフォルト設定がないが追加しようとしている項目があるがどうするの?ということらしい。

解決方法①

select an option:

と聞かれたので、ここでは1を選択。実際にデフォルト設定値を入力するよう促されるので、e.g.にある内容を参考に入力。

私の場合はtimezone.nowで解消した。

発生事象②

次にmigrateをしようとしたところ、今度は以下のエラーが発生。

f:id:gohh56:20181003005534p:plain

どうやらmakemigrationsのデフォルト設定が良くなかった様子。

解決方法②

ググったところ、以下の記事に遭遇。

まだデータ登録はしていなかったので、データベースを作り直してもよいと思い、migrations以下のファイルを削除、再度makemigrationsとmigrateを実行したところ正常に処理が完了できた。

qiita.com

エラー自体は解消したのだが、削除したファイルが一体何の意味を持つものなのかはっきりしなかったので、調べた。するとDjango公式ドキュメントに以下の記述を発見。

マイグレーションというのは、データベーススキーマに対するバージョン管理システムのようなものです。makemigrations はモデルの変更点を1つのマイグレーションファイルにパッケージングし(コミットのようなものです)、migrate はその変更点をデータベースに適用する、というわけです。

migrationsディレクトリ内のファイルはこのマイグレーションファイルに該当していたようで、この情報を一度削除することでリセットされたということらしい。

ちなみにより調べるともう少し丁寧なデータベースリセット方法があった。次はこのやり方を参考にして再度対応しよう。

https://trybeetle.com/en/detail/4/

育児休職を振り返る

3ヶ月程度ではあるが、妻と同時期に育児休職(以下育休)を取得した。 終了にあたって、育休について自分の体験談としてまとめておきたい。

ちなみに育休そのものについては以下にきれいにまとまっている。

13imi.me

育休を取得しようと思った背景

実は一人目の時はうまく取得できなかった。その背景としてはまだ自分に

  • 仕事大事だよね

という気持ちと

  • 父親になる自覚

というものが足りなかったため、と今では思う。結果、仕事の調整ができず、育休は取得できなかった。しかし、一人目はよく泣く子で妻は育児の疲労感漂う様子の中、父親になれていない自分とのギャップで更にイラ立ち、家庭内がギクシャクしてしまった。その後子供も無事保育園に入ることができたため、妻も仕事に復帰し、家庭内の環境は良くなったのだが、この時に妻がイラ立ちを示してくれたことで、父親としての自覚がだいぶ育まれ、育児、家事を共同経営者としてやってきた(はず)。

二人目ができた時はこの一人目の時の反省を活かすと共に私も赤子時代を妻と共有したい!と思い、育休を取得した。

妻に取れ、と言われたというよりは自分から取りたい、と思って取得した。この考え方の切り替わりは振り返ると一人目の誕生をきっかけにライフスタイルが変わったと共に自分の思考の変化が大きいと思う。

近年よく考えたことが、自分の人生において、死ぬまでの期間で考えたときに仕事よりも家族の方が一緒にいる期間が長く、また誰にどう思っていて欲しいか?を考えたときにも仕事仲間や上司はずっと一緒にいるわけではないので、最悪どう思われてもいいが、家族に悪く思われるのは避けたいということだった。

多少計算しているような思考ではあるが、この結果家事育児を手伝うのではなく、自分事として捉えるのが当たり前になった。(そのため、イクメンと言われるのは違和感があって、単に父であり、夫であるということで受け取って欲しいのが正直なところで、イクメンと言われても全く嬉しくない。)

育休取得の準備

一人目の時は上記の通り、自分の自覚の問題もあったが、もう一点、

がよくわからなかった、ということがある。

幸か不幸か、自分に子供が生まれる前後は「コウノトリ」のドラマがやっていたりして、出産=当たり前のものではない、という感覚だけはあって、悪い方向になった場合のことなども考えてしまうことがあった。結果、「安定期」になってようやく動き出す始末だったため、タイミングが遅くなってしまったのだった。

一人目の反省から、二人目の時は直接の上司だけに「まだ安定期ではないんで、何があるかわからないんですけど・・・」と前置きをしつつ、子供ができたことと育休を取るつもりでいるということをかなり早い段階から相談していた。たぶん妊娠4ヶ月とかそのぐらいだったかと思う。この頃はまだ期間は決めておらず、ただただ意思表示というか、希望を伝えるだけではあった。当時は最低でも半年、長ければ1年と考えていたのだが、給付金が出るとはいえ、夫婦共に無給状態を続けることがやや心配になり、妻と相談した結果、産後直後が辛いので、妻のケア含め同時取得&3ヶ月強ということにして、それを会社には妊娠8ヶ月頃に正式に伝えた。

上司や会社の担当部署への調整と並行して、準備したこととして、早い段階から会社の制度を確認した。また人知れず自分の仕事を棚卸ししたり、復職タイミングを考慮して、「これはお願いすること」「これは復職後でよいこと」を整理しておいた。育休の取得期間によってはこの調整が変わると思うが、数ヶ月であったため、年次の作業やイベント事は依頼対象外となったので、その点は準備が少なく済んだ要因だと思う。ただ、復職してみて思うのだが、意外に自分がいなくても仕事は回るものなので、もう少し長い期間取得してしまえばよかった、とも思った。

育休中にやれたこと

育児(主に寝かしつけと日中のふれあいと風呂)、家事(食事以外全部)、各種申請事項などは育休中の通常業務として行ったが、以下のような副産物があった。

というのも私の場合、妻と同時に育休を取得したこともあり、妻の体調が戻った後はお互いに育児と自分時間を交代で取得して、自分時間にはそれぞれのやりたいことに時間を使うことができた。(ちなみに妻は主にオンライン英会話をやっていて、私が復職した後も子供の昼寝などに合わせて継続している。ワンオペでも工夫次第、と気付かされる我が妻の行動に頭が上がらない・・・。)

  • プログラミングや技術勉強

    実は想定していた以上にはできなかった。

    それでも日々30分〜2時間程度は不安定ながらもできたのはよかった。

  • 家でヨガ

    我が家にあるAmazonFireTVにてYouTube動画を見ながらリビングでヨガ。外は暑いので嫌だし、教室に通うのはやりすぎ(というか、育休なので教室に通ってしまうのは家庭内問題を引き起こす原因になりかねない・・・。)

  • 英語少々

    プログラミングの気分にならない時はオンラインの英語講座をやった。昼間の我が家なので、声に出しても気にならなかった。

  • 自分のやりたいこと、やろうと思っていたけどためていたことを整理した

    これは精神衛生上一番やってよかった。

    やってみるまで気づかなかったのだが、どうやら私はマルチタスクが苦手なようで、なかなか仕事しながらだと家のことと合わせて、2種類の考え事をしなければならないため、脳みその容量をうまく振り分けることができなかった。

    これが仕事のことを一旦忘れてもよい環境になると脳みそがスッキリして、整理することに集中できた。

育休取ってよかった!

振り返ってみると育休中は楽しく過ごせた。

私個人の考えでは、育児の方が仕事より大変だが、それでも大変さを楽しさが上回ったようだ。

心なしか二人目の子は私になついてくれているような気がするので、一緒の時間を過ごした効果が出ているように思う。この状態を継続するために残業はなるべくしないようにしたい。

また、何より妻の機嫌というか調子が一人目のときに比べ格段によい状態を保っており、これだけでも育休をとった効果はあったと実感している。

以前転職を検討していた時に「育児したいので残業したくないが、仕事は楽しく、給与もいい会社がいい。」と言ったら、「ワークライフバランスとか言っていますが、まだまだそんな環境は整っていない会社の方が多いですよ」とエージェントの人に言われて、「ええ、そうなの?」と自分の意識と環境とのギャップを感じたことがあった。

自分自身が短いながらも育休をとってみて、改めて、男性の育休が取りやすい会社が増えて、どこにいっても仕事も家庭も楽しめる様になってくれると結構いいことあるんだろうな、と感じた。

自分も育休を取る時にいろいろ体験談など調べたので、多少なり育休取得の参考になるといいなーと思う。

viがこなれないのでnanoインストールした

GCE上でCentOSを立ち上げて、設定を行っていたが、viになれず、nanoをインストールして対応した。

ちなみにGCEでCentOS7でVMインスタンスを設定したが、viはデフォルトあったが、nanoはインストールが必要だった。(常識・・・?)

参考

以下のブログを参考にさせていただいた。

dotnsf.blog.jp

nanoとは?

  • ターミナル上で利用可能なviよりメモ帳慣れした人に向いている軽量エディタ

viはチュートリアルをやってみたことがあるが、確かにカーソル移動時のキー操作など指の移動が少なくて済むのだが、モード変更がイマイチなれなかった。また通常コーディングではVSCode利用中のため、ちょっとしたVMの設定変更する程度であるとnanoで十分であるため、こちらにした。

インストール

yum install nano

ログインユーザーの権限次第ではインストール権限がないことがあるのでその場合は

sudo yum install nano

でインストール可能。自分の設定環境では後者だった。

操作

操作自体はメモ帳やVSCodeキーバインド未設定時に近く、迷わず作業できた。

保存なども画面の下部分にガイドがあるため、それに従って実行すると都度ガイドメッセージが出たので、迷わなかった。

Google Cloud Next Tokyo 18に参加してきた

2018/9/19-20と開催されていたGoogle Cloud Next Tokyo 18に参加してきた。

子供のお迎えや通院などがあったので、2日目のみ、かつ途中退席ではあったが、得られたものもあり、来年も参加したい。

Google Cloud Next Tokyoとは?

cloud.withgoogle.com

Next は、Google Cloud Platform(以下GCP)やG Suiteといったクラウドサービスに関するイベント。

イベントページによると以下のとおり。

クラウドによって、私たちの働き方はどう変わっていくのか、いかにビジネスを成功に導いていくのか、多彩なテーマのセッションを通して学んでいきましょう。

参加意図

GCPは少し触っていたし、G Suiteは利用中の上、好きなサービスであったので、もう少し使えるようになりたい、という思いがあった。

また、GCPに限らずだが、サーバレスとFirebaseに興味があったので、そちらのセッションを聞きに行った。

基調講演

保育園送迎があったため、途中参加。

デモを交えつつ、新しい情報なども紹介されていた。

DevOpsの自動化デモはソース変更後テストやデプロイなど自動で進んでいったのは印象的であった。

セッション: Cloud Functionsではじめよう、サーバレスアプリケーション開発

改めてサーバレスとは何か?からCloud Functionsそのものの説明とあまり知らない私でもスムーズに理解ができた。

Cloud Functionsを利用すると従来のアプリ設計とは異なり、トリガーとなるイベントから複数の処理を並行して走らせることができる。例えば画像をCloud Storageに保存したら、

  1. 画像のサムネイルを作成する

  2. 画像分析を行う

ということが同じイベントから処理されるということを実現できる。いづれも個別処理となるため、並列処理に伴う性能低下等はない。

その他の気付きメモ。

  • サーバレスとは

    1. みえないインフラ=管理不要なサーバ

    2. 自動スケーリング

    3. 使用時のみ課金

  • インフラスケールの規模

    サーバ構築>IaaS>コンテナ化>PaaS>FaaS

  • 対応言語はNode.js。Python3.7、Goなどがβ版またはα版となっており、今後拡大予定。

    LamdaはPython対応済だったと思うので、このあたりはまだ差がある様子。

セッション: Firebase入門、低コストで迅速な開発を行うには?

Firebase=サーバの代わり + 便利なツール集。

Firebaseはバックエンドを支える基盤として利用可能であるため、とりあえず利用してみる、ということが容易にできる。

リアルタイム同期ではあるが、アクションゲームなど動機頻度があまりに短いものには向かないが、それ以外はサービスメニューも増えてきているため、対応可能は範囲は広い。

Firebaseにすることで開発チームのメンバー構成がシンプルになるため、Firebaseの費用だけでなく、エンジニアの費用+コスト(時間、手間など)のトータルコストで考えると効果を出しやすい。

中規模までのアプリケーションであればFirebaseへ一気に切り替えてしまうのがオススメ。(大規模は移行方法を考慮して切り替える必要がある。)

また、Googleからも日々新しいメニューが提供されているので、今後もFirebaseでできることは拡大するだろう、ということだった。

FirebaseはmBaaSと言われていたので、スマホアプリのバックエンド用と思っていたが、webでも利用可能なので、触ってみようと思う。

セッション: BigQueryを使用した分析基盤の運用を進めていく上で見えてきた課題、乗り越えてきた軌跡

リクルートライフスタイル社の事例紹介と運用経験での課題解決の紹介。

課題やそれに対する解決方法について具体的に紹介されていたが、これほどのレベルのデータや複雑なデータ収集をするというケースが自分の場合当てはまらないので、そのまますべてというよりは一部、特にBigQueryそのものの便利さや注意点が参考になった。

特に

  • GCPサービスとの連携の容易さ

  • データ連携をbotを作成し、ビジネス部門にも扱いやすくした

  • 不足している部分は開発で補い、運用コストを下げた

という点は参考になった。

おまけ

もらいもの

  • 折り畳み傘

    受付したらいただいた。ちょうど雨が降った&会場が2箇所に分かれていたので、大活躍した様子。

  • サコッシュバッグ

  • Tシャツ

  • USBケーブルつきスピナー

    イベント中のクエストとハンズオンを行ったらいただいた。

会場、設備等

  • ランチ

    ランチセッションは満席で参加できなかったが、カフェスペースにておにぎり、パンと飲み物の無料提供がされていた。

    外出せずにお昼を取れたのでそれは助かった。

  • シャトルバス

    東京プリンスホテル

    ザ・プリンス パークタワー東京

    の2箇所開催であった。徒歩でも10分ぐらいだが、観光バスほどの大きさのシャトルバスが15分間隔で運行しており、そちらを利用しての移動も可能だった。

  • 電源とネットワーク

    チャージスポットが用意されており、スマホ用ケーブルとコンセントが用意されていた。電源難民にならずに済むのでこれは助かる。

    wi-fiもあったが、こちらは展示スペースのみでセッション会場までには展開されていなかったのが残念だった。

  • カフェスペース

    軽食と水が用意されていた。これもありがたい。

  • 公式アプリ

    iOSAndroidの公式アプリがあり、これが思いの外役にたった。

    事前に登録したセッション情報が見れるだけでなく、アプリ上で申し込み、キャンセル、アンケート回答ができ、また会場の地図やwi-fiの情報なども確認が可能。セッションにはQRコードでチェックインするのだが、それをアプリ上でも参加済といったカタチで反映される。

    一部残念だったのが、そのチェックイン用のQRコードはアプリでは表示できず、メールかwebページか印刷した紙を利用していた点で、これは来年改善されることを期待したい。

    それでも、こういったイベントの公式アプリとしては使いやすく、他のイベントでもあったらいいな、と思った。こういうイベント用のアプリを簡単に作れるサービスがあったら、需要あるかな・・・?

サービス紹介関係のイベントなので、参加は無料でできるが、全体的に充実した内容だった。来年は全参加して、最後のネットワークパーティーにも参加してみたい。