OhMyZshからZinitに乗り換えてみた話

この記事は Enigmo Advent Calendar 2021の6日目の記事です。

こんにちは。BUYMAでWebエンジニアをやっております、岡本です。エニグモに入ってから約1年が経過しました。

学生の時にプログラミングを始めてしばらくbashを使っていたのですが、イケイケの先輩にzshを教えてもらい、zshの機能を拡張するためのプラグインマネージャーにはOhMyZshを勧められ、数年利用していました。この時期に使っていたmacOSの標準シェルはbashで、zshはわざわざインストールするものでした。

1年前にエニグモに入社した頃、支給されたMacBookProに搭載されているmacOSの標準シェルは既にzshになっていました。(標準シェルがzshになったのはmacOS 10.15 Catalina以降です)

せっかくの機会なので気持ちを新たにプラグインマネージャーも替えてみようと思い立ち、いくつかzshプラグインマネージャーを調べたところZinitが良さそうに思えたので導入することにしました。今回は導入した感想を軽く綴ってみようと思います。

github.com

(2021年12月6日閲覧、以下記載URLも同様)

いいところ

いくつか公式ドキュメントでもアピールされていますが、個人的に良いと思うところを挙げます。

zshの起動が速くなる

公式ドキュメントで喧伝されているのがzshの起動スピードについてです。早いことをアピールしています。

Zinit is currently the only plugin manager out there that provides Turbo mode which yields 50-80% faster Zsh startup

訳(Zinitは現在、ターボモードを提供する唯一のプラグインマネージャーであり、Zshの起動が50〜80%速くなります。)

cf. https://github.com/zdharma-continuum/zinit#zinit

ここでターボモードとは何ぞやとなるのですが、waitを使った遅延読み込みのことを指すようです。これについては後ほど紹介しますが、ターボモードを使わなくても従来のプラグインマネージャーと比較するとzshの読み込み速度は高速になっていると思います。

OhMyZshおよびPreztoプラグインとライブラリの読み込みをサポートしている

OhMyZshやPreztoなどを利用していた方もその資産を継承できます。なお私はOhMyZshのプラグインは現在は読み込まずに使っています。気になる方は以下をご覧ください。

参考URL

https://zdharma-continuum.github.io/zinit/wiki/INTRODUCTION/#oh_my_zsh_prezto

使ってみよう

Zinitのインストール方法はこちらからご覧いただけます。

https://github.com/zdharma-continuum/zinit#automatic-installation-recommended

sh -c "$(curl -fsSL https://git.io/zinit-install)"

source ~/.zshrc

zinit self-update

こちらを実行することで~/.local/share/zinit/zinit.gitにzinitがインストールされ、zshrcにzinitの設定が追加されます。

ここから自分好みにカスタマイズしていくわけですが、現時点の私のzshrcを見てみるとこんな感じになってました。1~7行目はromkatv/powerlevel10kを使うために設定しているものです。一言でいうとターミナルのUIをカラフルにしてくれるものです。ペアプログラミングの機会があると「ターミナルのUIがカラフルですね」とよく言われます。ディレクトリ名やブランチ名が見やすいのでOhMyZshを使っている時からずっと使っています。

  1 # Enable Powerlevel10k instant prompt. Should stay close to the top of ~/.zshrc.
  2 # Initialization code that may require console input (password prompts, [y/n]
  3 # confirmations, etc.) must go above this block; everything else may go below.
  4 if [[ -r "${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh" ]]; then
  5   source "${XDG_CACHE_HOME:-$HOME/.cache}/p10k-instant-prompt-${(%):-%n}.zsh"
  6 fi
  7
  8 ### Added by Zinit's installer
  9 if [[ ! -f $HOME/.zinit/bin/zinit.zsh ]]; then
 10     print -P "%F{33}▓▒░ %F{220}Installing %F{33}DHARMA%F{220} Initiative Plugin Manager (%F{33}zdharma/zinit%F{220})…%f"
 11     command mkdir -p "$HOME/.zinit" && command chmod g-rwX "$HOME/.zinit"
 12     command git clone https://github.com/zdharma/zinit "$HOME/.zinit/bin" && \
 13         print -P "%F{33}▓▒░ %F{34}Installation successful.%f%b" || \
 14         print -P "%F{160}▓▒░ The clone has failed.%f%b"
 15 fi
 16
 17 source "$HOME/.zinit/bin/zinit.zsh"
 18 autoload -Uz _zinit
 19 (( ${+_comps} )) && _comps[zinit]=_zinit
 20
 21 # Load a few important annexes, without Turbo
 22 # (this is currently required for annexes)
 23 zinit light-mode for \
 24     zinit-zsh/z-a-rust \
 25     zinit-zsh/z-a-as-monitor \
 26     zinit-zsh/z-a-patch-dl \
 27     zinit-zsh/z-a-bin-gem-node
 28
 29 ### End of Zinit's installer chunk
 30 以下略

さて、プラグインを設定してみます。zshを使う上で外せないのは補完とシンタックスハイライトではないかと思います。

# 補完
zinit light zsh-users/zsh-autosuggestions
# シンタックスハイライト
zinit load zdharma/fast-syntax-highlighting

ここで、プラグインの読み込み方法はloadlightがあります。

loadを使うことでプラグインのトラッキングを可能にします。zinit report {plugin-spec}プラグインの情報を出力し、zinit unload {plugin-spec}プラグインを無効にします。

一方lightを使うとプラグインのトラッキング機能が無効になり、loadに比べて読み込み速度が速くなるようです。

またsnipetを使うと、URLを直接指定する形でプラグインを読み込むことができます。

zinit snippet https://gist.githubusercontent.com/hightemp/5071909/raw/

cf. https://zdharma-continuum.github.io/zinit/wiki/INTRODUCTION/#basic_plugin_loading

このような感じでお好みのプラグインを追加していきましょう。筆者のzshrcをみるとzdharma/history-search-multi-wordというコマンド履歴を検索するプラグインが入っています。

zinit load zdharma/history-search-multi-word

f:id:enigmo7:20211202102734g:plain

設定例はzinitのドキュメントに記載されているので私はこれを参考にして設定したのですが、ここでiceというものが出てきます。

zinit ice pick"async.zsh" src"pure.zsh"
zinit light sindresorhus/pure

zinit ice depth=1; zinit light romkatv/powerlevel10k

zinit iceは直後の行で実行されるloadlightの挙動を変更します。iceの後のpicksrcなどはice-modifiersと呼ばれるもので、 iceという名前の由来は、氷は飲み物に入れて少し経つと溶けることから、変更が一時的なものであることを意味すると公式ドキュメントでは説明されています。ice-modifiersの後ろにクォーテーションやイコールで指定されているのは引数です。ice-modifiersが引数によってzinitの挙動を制御します。例えば上記のpickであれば、引数として与えられた"async.zsh"に実行権限を与えてPATHに追加するようにzinitに対して指示しています。

その他のice-modifiersの用法についてはこちらを参照してください。

https://github.com/zdharma-continuum/zinit#ice-modifiers

おわりに

基本的な使い方はできていると思いますが、まだまだ知らないオプションが多いのでもっと使いこなせるように日々精進したいと思います。

次回の記事の担当はデータアナリストの井原さんです。お楽しみに!!


株式会社エニグモ 正社員の求人一覧

hrmos.co

おすすめポモドーロアプリ4選徹底比較!ポモドーロテクニックによる時間管理術

こんにちは、サーバーサイドエンジニアの竹本です。 この記事は Enigmo Advent Calendar 2021 の3日目の記事です。

みなさまは2021年どのように過ごされましたか、株式会社エニグモでは昨年の新型コロナウイルスの影響で2020年2月からリモートワークに以降したのですが、今年はなんとオフィスが半分になり全社的なリモート体制が整いました。(新オフィスの紹介記事 最高なオフィスにリニューアルしました!!BUYMA/株式会社エニグモ | 株式会社エニグモ ) コロナ禍抜けたら出勤再開しましょうなどの展開はなく、リモートに切り替える機動性の高い会社です🤗 採用情報はコチラ

というわけで、1エンジニアの私もリモートワーク中心の生活が続いております。そういう状況の方は多いのではないでしょうか?

ところで、お家での作業は捗っていますか!? あんまり集中できない日があったり、逆にいつの間にか窓の外が暗くなっていたりなど、色々あるのではないでしょうか?そこでおすすめしたいのがポモドーロテクニックです。

ポモドーロとは

ポモドーロテクニックといって25分作業して5分休憩することによって集中力を持続させることができる作業方法です。

私がポモドーロを始めてみようと思ったのはSOFT SKILLS ソフトウェア開発者の人生マニュアルを読んだことがきっかけでした。ポモドーロテクニック自体は知っていたのですが、作業中にタイマーがなるのが鬱陶しそうで敬遠していました。 しかし本書ではポモドーロテクニックは集中のためのツールというよりも、

  1. ポモドーロ何セットかかるタスクなのかを見積もる (以下記事の中ではポモドーロ1セット=1ポモと単位ポモで表記します)
  2. 実際何ポモかかったのかを計測する
  3. 以上を繰り返す

これにより、タスク見積りの精度が向上していくメリットを中心にポモドーロテクニックを紹介しています。

自分でタイマーをセットして見積りと計測をメモっていっても良いのですが、世にはいっぱいポモドーロアプリがあるので、便利に活用したい! というわけで自分の作業環境や、目的に合っていそうなアプリを探す旅に出ました。

以下の条件で選定しております。

  • 無料で試せる
  • macで利用できる
  • 作業ログを見ることができる

そして条件に合った4つのアプリを実際に試したので紹介させていただきます。

  • Pomofocus
  • Kanban Flow
  • life line
  • Be Focused

Pomofocus

https://pomofocus.io/

  • 「pomodoro timer」でググると一番上に出てくる
  • シンプルなUI
  • タスクにかかるポモドーロのセット数見積りを設定できる
  • 中断できる
  • ログが見れる

f:id:enigmo7:20211201121907p:plain
Pomofocus画面

一番最初に試したのがこのアプリでした。本当にシンプルで簡単に利用することができ、私自身「ポモドーロ、試してみようかな…」という段階でこのアプリに出会うことができたところが今もポモドーロを継続できていることに繋がっていると思います。

またタスクの設定時に何ポモかかりそうか見積りを設定し、実際何ポモ経っているのかを計測できるので、当初の目標とマッチしています。以降紹介するアプリの中でも最も簡便に見積りの入力ができるので気に入っているポモドーロアプリです。

Kanban Flow

https://kanbanflow.com/

  • カンバン的UI
  • サブタスクもチェックボックスで管理できる
  • タスクにかかる時間の見積りが設定できる
  • ログがめっちゃ見やすい
  • 中断しようとすると理由を聞かれる

f:id:enigmo7:20211201121602p:plain
Kanban Flow画面 カンバンはユーザーを招待してチームで管理することもできる

名前の通りカンバンUIで全タスクを一望できるのが便利!

他のアプリは作業中のタスクだけ表示の場合も多いですが、こちらはTodo/DoToday/InProgress/Done全てのステータス(ステータスカラムは編集可能)のタスクが表示されており、またカンバンはプロジェクトごとに管理できるようになっています。

何よりSOFTSKILLS作者ジョンソンメズによって開発されているのもあり、こちらもタスク設定時にタスクにかかる時間の見積り設定が可能です。

しかし作業の中断に厳しい設計になっており、ちょっとトイレ行きたい時にも、タイマーを止めようとすると、ポモドーロを中断させられるし(また0からポモドーロを始める必要がある)急いでいるのに理由を聞かれたりして、まあいっかとタイマー回しながらトイレに行くことが多かったです。

f:id:enigmo7:20211201144021p:plain
ポモドーロ停止理由一覧 停止するときはこのくらいの覚悟を持てということなんですね oyatsuは自分で追加しました

life line

  • 画面上部のメニューバー下に作業時間が可視化される
  • PCで作業しているとタイマーを自動で回してくれる
  • 休憩時間は画面をグレーアウトしてくれる

kanban flowを利用していたあたりに、「ブラウザでのタイマーはわざわざそのページを見に行かなきゃいけなくて面倒だな…」と思っていたところでこちらを試してみました。

mac画面上部のメニューバー下に1日の作業している時間がグラフとして可視化されます。 また、ログを見ると、作業時間、休憩時間が日ごとに確認することができます。

f:id:enigmo7:20211201143230p:plain
life lineログ画面 お昼休みが黒かったり、MTG中は休憩していなかったりが一目瞭然

またlife lineの面白い機能として、一定時間以上PCで作業しているとタイマーが起動し、25分経過すると画面がホワイトアウトして作業を止めることができるのでやや強制的に作業のリズムを作ることができます。

しかし、自動でタイマーが起動する性質上、個別のタスクに関する見積り、計測が難しいです。 ちょっとslack巡回しよ…って時もタイマーが動き出してしまい、「あー今はタスクやってたわけじゃないのにー!」となります。

Be Focused

  • メニューバーで時間を確認できる
  • タイマーのアラーム音をたくさんの中から選べて愉快
  • 見積りも入力できる
    f:id:enigmo7:20211201145332p:plain
    Be Focused画面 アップグレードしたら広告は消えるそうです

やっぱりメニューバーで後何分か確認できるやつが欲しいな!そしてタスクごとにタイマーを手動で動かしたい!と思いこちらのアプリに出会いました。

タスクを追加して、タスク詳細画面から何ポモかかりそうか入力して、タイマーをスタートさせるというシンプルな流れ。

というわけで現在はBe Focusedに落ち着いています。

アプリはさまざまなものが出ているので、ポモドーロを導入する目的にあったアプリを見つけて、良いポモドーロライフをお送りください!

次回の記事の担当は サーバーサイドエンジニア の 岡本さんです。お楽しみに。


株式会社エニグモ 正社員の求人一覧

hrmos.co

コーポレートITの未来を考えた話

f:id:enigmo7:20211110103537p:plain こんにちは、Corporate IT/Business ITを担当している足立 です。

この記事はEnigmo Advent Calendar 2021の 2日目の記事です。

エニグモでは1人目のコーポレートIT担当として未着手な社内IT環境をコツコツ整備してます。 世間一般的には情報システム(情シス)と呼ばれるポジションです。

昨年はコロナ対応について書きましたが、もう早いものであれから1年が経過しました。
今年はコーポレートITの未来を考えた話について書きたいと思います。

コーポレートITの未来って?

早い話、ロードマップ(中期計画)を考えた話になります。
今後、3年間で実施したいIT投資計画を策定し経営層に対し内容を共有しました。

では、何故中期計画を策定したのか?

私がエニグモに来てから2年半以上の月日が経ち、入社直後のミッションとして下記内容がありました。

  • 老朽化した複合機のリプレイス
  • Google Workspaceのプラン変更
  • 紙ベースの権限申請の電子化

それぞれについて書くと長くなるので割愛しますが、上記の目処が立った矢先にコロナ対応、オフィスリニューアルPJがあり 場当たり的な対応を続けて来ました。 とは言え外的要因が起因とした状況でしたが、エニグモの社内システムの環境は大幅に改善されたと思います。

f:id:enigmo7:20211108114225p:plain
入社直後の社内システムの一部
上記の図は私が入社直後の社内システムの一部になります。 管轄が違うシステムも含まれていますが、全社的に使用する物はコーポレートITが管轄しています。

f:id:enigmo7:20211108114909p:plain
現在の社内システム一部
現在はコロナ対応に伴うリモートワーク環境構築の為に導入した物やオフィス リニューアル時に導入したシステムを合わせると上記の図のようになりました。

環境が大きく変わりましたが思いとしては道半ば。 まだまだ、導入しなければならない物が沢山あると感じていますが、今後も場当たり的に導入するのではなく 中期的に必要性や導入計画も立て予算についても経営層と事前に共有する事が必要と思いました。

例えば導入したい物が高額な場合に経営層も直々にOKを出す事は難しいですし、 導入したいシステムが一部だけ承認が降りたとしても会社全体でのシステム構成にバラツキが出てしまうのも 余計な投資を実行してしまう要因にも成りかねません。 モダンなシステム構成の実現、無駄な投資を防ぐ為にも中期計画が必要でした。

中期計画 策定のパートナー

私自身の中に今後、導入したいシステム構成はボンヤリとありましたが、果たして本当にその構成で良いのか?エニグモに取ってベストな構成なのか?と言う疑問がありました。 そこで中期計画を策定するにあたり外部の力を借りる事にしました。

f:id:enigmo7:20211108135212p:plain
クラウドネイティブさん
パートナーとしてクラウドネイティブさんのご協力をお願いしました。 お願いした理由としていくつかありますが、代表的な事としては下記の通りになります。

  • ベンダーフリー
    • ベンダーに属されていないのでフラットな立場で様々なサービスを提案・導入が出来る
    • ベンダーによっては導入提案出来る商材が決まっていたりする事があるのでフラットな立場で提案して頂ける部分に魅力を感じました。
  • 自立を考えてくれる
    • 支援をお願いすると基本、代行してやってくれるケースが多いですが基本、弊社にナレッジやノウハウを残して頂けるように支援してくれます。
    • また、問い合わせに関してはSlack出来る為、レスポンスが早くスピーディーに対応して頂けます。
  • 強力なスタッフ
    • 情シスSlack内やイベントでお見かけする強強な情シス経験者の方が参画しているので心強い。
    • 尊敬する方もいらっしゃったので一度、お仕事をご一緒したい思いもありました。

元々、IdP導入はクラウドネイティブさん経由で実施する予定でしたので、同時進行で進めていく事になりました。 やはり自分が考えている構成について壁打ち出来る相手が居ることは安心感に繋がりました。

コーポレートITのMVV

中期計画を策定にあたり、経営層との話し合いの場を設けて頂きました。 IT投資を実施する為に役員がコーポレートIT部門に対してどんな目的で、どのようなチームであって欲しいのかヒアリングをさせて頂き その内容をベースにMVV(ミッション・ビジョン・バリュー)を策定し、その内容にあった計画を作る事にしました。

ヒアリング当日は役員に対してコーポレートITに対して思っている事、実現して欲しい事を兎に角、何でも良いので言って欲しいとお願いし 様々なワードが出てきました。 そのワードを元に作成したMVVが以下の通りになります。

ミッション(使命、目的)

全てのStakeholderをHappyに

ビジョン(将来像)

社員と組織のValue実現をITで支えるチーム  

バリュー(スタイル)

「 Location Free 」 「 Always update」 「 Balancing productivity and security」

f:id:enigmo7:20211108160114p:plain
MVV

ミッションである「全てのStakeholderをHappyに」は代表である須田さんのお言葉でした。 ヒアリング当日はワードが出てこないのでは無いのかと懸念してましたが、予想とは裏腹に3人の役員が思いの丈をぶつけて頂きました。 中でも「従業員だけでなく、協力会社の方々、BUYMAユーザー、パーソナルショッパーなどエニグモに関わる全てのStakeholderがHappyになる環境であって欲しい」とお話して頂いた時はミッションはコレしかないと感じました。

f:id:enigmo7:20211108160736p:plain
ミッション

ビジョンである「社員と組織のValue実現をITで支えるチーム」はエニグモの企業理念にある3つの価値基準を大切する行動指針を後押し出来るチームである事を示しました。

セルフスターター

他人や環境に左右されず、自ら目標を見つけ引き金を引き、突き進める人

アウトパフォーマー

自分の強みを鍛え、常識、限界、期待値を超えていく人

チームビルダー

”日頃”のチーム作りと”実践時”のチームパフォーマンスに貢献できる人

f:id:enigmo7:20211108161752p:plain
ビジョン

最後にバリューについては3つの指針にしました。

Location Free

コロナ禍後は会社を身軽にする事に注視し、物は持たずPC端末とインターネット回線があれば世界中どこでも業務が出来る環境の実現を目指す事にしました。

Always update

次から次へと新サービス、新しいシステムが出てきます。既存の環境に満足せずに常にアップデートし続ける事を目標としました。

Balancing productivity and security

管理出来ないツールやサービスが増えると、そこがセキュリティホールになる危険性がありますが、無闇矢鱈に規制すると生産性が低下します。 矛盾した話になりますが、「生産性と安全性」を両立した構成を目指す事にしました。

f:id:enigmo7:20211108163734p:plain
バリュー

MVVについては無くても中期計画は策定出来ますが、私はあった方が良いと思っています。 経営層とコーポレートITの間でチームの方向性について同じマインドであった方がより良い組織になると感じるからです。

リスクと課題の洗い出し

エニグモにある想定されるリスクや課題の洗い出しに着手し懸念点については全てお話し必要な対応を可視化。 それに基づき必要なソリューションをマッピングしていきました。 弊社のセキュリティに関わる部分になるので、詳細については書くことが出来ませんが、箇条書きでも良いので懸念点をメモしておく事をオススメします。

ソリューションの選定に基づきロードマップへ反映しました。

f:id:enigmo7:20211109133233p:plain
ロードマップ

また、概算費用を算出する為、必要ライセンス数の洗い出し、定価ベースでの費用感を算出しました。 大凡の金額感だとしても、これだけの費用がかかるのかと思うと震えました。

未来へ

課題や懸念点、予算感を取りまとめてロードマップにし役員へ共有を行いました。 役員からは「概ね、agree」と言われて、同意して頂いたのでほっとしました。

今後についてはフェーズ毎に改めて詳細なシステム構成案、費用感、検証を実施し役員へ最終提案を行います。 より快適でセキュアな環境構築の為に日々、精進していきたいと思います。

明日の記事の担当は サーバーサイドエンジニアの竹本さんです。お楽しみに。


株式会社エニグモ 正社員の求人一覧

hrmos.co

エンジニアインタビュー 第7回 加藤春樹さん編

Advent Calendar 1日として初日を飾るのは、エニグモのエンジニアインタビュー第7回!今回はインフラチーム入社2年目の加藤さん(@kuromitsu_ka) です。

f:id:enigmo7:20211112171254p:plain
趣味は自転車だそう。夕日すごい!
f:id:enigmo7:20211126171831p:plain
先日広島のうさぎ島に行ってきたそうです。もふもふしている。



インタビュアー
穴澤:2019年1月入社。エンジニアマネージャー。

穴澤:
加藤さんはエニグモ入社丸2年ですね。エニグモはサービスエンジニアリング本部という部署の中でアプリケーション開発、アプリ開発、インフラなど複数のチームにわかれていますが、 加藤さんはインフラチームですね。前職もインフラをされていたんですか?

加藤:
SESで、お客さん先に常駐するタイプのインフラエンジニアでした。SIerに2年、サービス運営会社に1.5年お世話になりました。新卒で一番最初に常駐させていただいたSIerでは、主に運用周りを担当していました。(Cactiの監視とかコードリリース、アラートが飛んでくると調査するなど) その後知人の繋がりでサービス運営会社にも常駐させていただきました。 ここはモダンな開発環境で、プロパー社員もいい人でIaCやクラウドサービスを使った新規構築、新規OSSの検証、運用周りの自動化をさせていただきました。 こちらの現場の仕事を通して「自分もサービス開発に関わる仕事をしたいな」と思って転職することにしました。 エニグモは一番早く連絡をくれていて、BUYMAも知っていたので記念受験のつもりで受けたら受かりました。(初の転職面接でした。)

穴澤:
入社後、実際の実務をしながら独り立ち、という流れかと思いますが具体的にはどういうフォローだったりサポートをうけていたんでしょうか?入社後のギャップってありました?

加藤:
入社当初の試用期間、3ヶ月間は上司が日々何かと面倒を見てくれていました。ガイダンスもありましたが日ごとにわからないことはそこで解決していただいていました。その後別の先輩とawsのプロジェクトに参加しています。毎日MTGしつつ作業の相談やわからないことはオンラインですすめていて、特に困ることはありませんでした。入社後のギャップとして良かったこととしては、リア充キラキラ系だと思っていて、自分にはちょっとしんどいかなと覚悟していたら、落ち着いた感じでした。自分が入社する当時は、「やんちゃであれ」が社訓だったので、もっとやんちゃにやってみたい/やんちゃな人に出てきて欲しいなとは日々思っています。

穴澤:
みんなキラキラ系におびえて入社してきますね(笑)。 今の一日の流れと、実際一週間で実務作業がどのくらいなのかおしえてください。

加藤:
午前中は作業やMRレビューなどをやっています。ほぼ毎朝同じプロジェクト(AWS化)の先輩とMTGしつつ作業です。ロールとしてはインフラ/SREですがペアプロ開発っぽい形で進められています。 午後は特定の曜日はMTGがあったりしますが基本作業です。作業は17:00くらいまで。作業中の不明な点はチームのslackか定例で聞いています。作業時間は概ね7,8割だと思います。まとまった時間がとりやすくありがたいです。

以前、障害対応をしたことがあったんですが先輩とzoomで画面共有しながら一緒に作業した時先輩の操作を直接みれて勉強になるし質問もすぐできるし、すぐ教えてもらえるので普段の業務でもペアプロのように一緒に作業してもらえる時間をつくってもらえるようになりました。この進め方は今もとてもよかったと感じています。些細なことですが、チームでの仕事の進め方みたいなことも相談できるのでありがたいです。

f:id:enigmo7:20211028172420p:plain

直接会社とは関係ないかもしれませんが、リモートになったことで都内で飲んだり遊ぶことがなくなりました。その代わり、ジムや誘ってもらったバレーボールチームに参加したりと自分の時間を調整しながら仕事のバランスが取れてると感じます。

f:id:enigmo7:20211115163857p:plain
コロナ禍になってからキャンプも始めました。 先日は、友達とゆるキャン△聖地巡礼キャンプにいって、富士山の日の出を見てきました。

穴澤:
おープライベート充実してますなあ。 インフラチームでも、ペアプロみたいな一緒に作業ができるのって安心感ありますね。 まとまった時間がとれるのもいいですね。コードを書く時もそうですが設定や実務やってると途中で遮られたり、ノッてる時にMTGになると辛いですもん。 今リモート勤務だと思いますが、加藤さんたまに出社してます?

加藤:
週1くらいの頻度で定期的に出社してて、リゾートエリア(休憩エリア)にいると自部署以外の人からちょっとしたお困りごとみたいな相談をうけることがあってそれが嬉しかったりもします。最近ではブックマークレットのjsの書き方を質問されて、答えるなどしました。ちょうど自分がNode.jsを勉強してたのもあって、自分の勉強にもなってよかったです。入社してすぐにリモートになったので、社内に知らない人が多いのが悩みでした。たまに出社していれば、社内の誰かが声をかけてくれるので、内心凄くありがたいです。

穴澤:
あ〜そういう相談って結構リモートだと難しい、、DMみたいな深刻さもないし、かといって大勢のいるチャットできくようなだいそれた事でもないし・・すれ違ったときに「そういえばこれしってる?」みたいなノリがとてもいいですね。エニグモでは、リモート後に入社した人むけにオンボーディングと称して各部署の方が定期的に部署の役割や他部署とのつながりを説明してくれるオンラインのイベントがありますが確かに別部署の方と接点というのは限定的になりがちですね。

さっき入社後のギャップみたいなお話をしましたが、入社後、仕事の仕方とかで大きく変わったことってあります?

加藤:
自分は、客先常駐の仕事から事業会社の社員に転職したのもありますが、仕事で何かトライする際のハードルが下がった気がします。プロジェクトを進めている時も、振られたタスクを進めるだけじゃなくて、提案や、課題発見→起案がし易いですね。些細な事の相談や、新しいサービスを導入するなどの相談と意思決定が早いので取り組みたいことや試してみたいことを予算やある程度の準備をしてお願いすれば大体「OK、やってみよう。」という流れになる。事業会社ならではだと思います。

穴澤:
わたしもそういう文化をエニグモに感じます。まず話をきいてくれる環境というか、耳を傾けてもらえるところがすごくいいなと。自分で考えてチャレンジしたり提案できるって環境や風土は大事にしていきたいですね。私も、組織づくりをがんばります。

開発環境周りでいつもサポートしてくれる加藤さん、これからも頼りにしています。また、入社3年目突入ということでますますの活躍、期待しています! 今日はインタビューありがとうございました。

明日の記事は人事総務グループの足立さんです!

エンジニアインタビュー 第6回 平井蒼大さん編

エニグモの若手社員インタビュー第一弾、平井さんです。入社3年目を迎えている平井さんに、現在の日々の仕事内容やリモートでの環境の変化などをざっくばらんに聞いてみました。入社直後のインタビューもどうぞ!

f:id:enigmo7:20211013180653p:plain
寝癖があったぽいですがご本人の許可を頂きました。:)   ウェーイ感ある。



インタビュアー
穴澤:2019年1月入社。エンジニアマネージャー。

穴澤:
3年目ということで実務やチームの立ち回りも、ご自身のリズムみたいなものができてきてるかと思います。一日の流れを教えてもらえますか。

平井:
午前中は主に1日のタスク確認、そのまま所属する開発チームの朝会に出席します。基本的には実装メインなので、午後は実装していることが多いです。施策によってはミーティングが入ることもあります。

穴澤:
平井さんのスケジュール、毎日朝30分、プロジェクトの朝会がセットされていますね。ちなみに入社後、業務を行うまでどんな感じでフォローしてもらっていたんでしょうか?

平井:
1年目のときは毎週金曜日に同じチームの先輩エンジニアの方に参加頂き、週の振り返りをしていました。振り返りは事前に週で行った業務の中で改善したほうがいいことや来週やることをesaに書いて、その週で詰まった部分の原因や解決方法を相談させて頂いていました。あとは朝会でも不安点など相談していました。業務でわからないことは、基本的にslackのチャンネルで尋ねることが多いですが、文章で伝えづらいこととかは、朝会で聞いたりします。



f:id:enigmo7:20211012154701p:plain
当時の平井さんの振り返り



穴澤:
基本的にはOJTですね。その後入社した若手社員も週次で先輩と一緒に振り返りをやっていて、これはもう誰ともなく部内で引き継がれています。今は今年入社の岡本さんの振り返りに先輩として参加してる感じですね。エンジニアとしての開発業務は8時間のうちどのくらいの割合ですか?

平井:
平均したら7, 8割くらいかなと思います。最近だと金曜日はミーティングが多めなのでそこまで開発できないですが、他の曜日はほぼ開発してる日もあります。

穴澤:
(平井さんのスケジュールをみて)確かに金曜にまとまってミーティング入っていますね。結構こういうやり方してる人多いかも。エニグモのエンジニアはほぼみんなリモートですがお昼ってどうしてます?

平井:
常にコンビニに行って弁当買って食べています。運動はあまりしないので、意図的に歩く機会を作っています。リモート勤務になって、通勤が減って体動かす機会がなくなったことです。あとは、ずっと部屋にいるのでもう少し広い部屋に引っ越したいなと思い始めました。通勤する必要がなくなったのは、かなりストレスが減りました。逆に、仕事とプライベートの切り替えは難しいなと感じています。


f:id:enigmo7:20211014132222j:plain
写真いただきました。すっきり片付いている作業デスク



穴澤:
運動不足は重要な課題ですよね。わたしもミーティングはできるだけスタンディングデスク使っています。歩かないですよね・・。引っ越しいいですね! 仕事とプライベートの切り替えというお話がありましたが、業務の中で先輩、後輩との雑談とか業務外のちょっとした会話ってできてます?

平井:
雑談はチームの振り返りを行った後ちょっと雰囲気が砕けたタイミングで他愛のない話をすることもあります。 あとは最近後輩と時間がとれてないのでそこはフォローしたいと思ってるところです。

穴澤:
先輩っぽい!仕事の話に戻りますが、入社後、業務で一番達成感のあったものってなんですか?

平井:
パーソナライズ特集ですね。先輩に教えてもらいながら環境も自分で構築して、独立した新機能を全部自分で作りきったところが達成感につながったと思います。今思えば設定ファイルでできてしまう部分が多く構築はそんなに大変ではなかったですが初めての事も多くローンチできた時は嬉しかったです。*1 tech.enigmo.co.jp

穴澤:
あー!これ私もアプリでレコメンド出てきたので覚えてます!記事が去年なので2年目の平井さんが作ったものですね。たしかに自分で全部作り切るってやりきった感ありそうです。 3年目、新しい社員も入ってきてフォローしたり指導したりということも増えてきてると思います。この後どういうエンジニアになっていきたいなという漠然としたものってありますか?

平井:
同僚(エンジニア、非エンジニア)が安心して一緒に仕事できる存在になりたいです。技術的にプロダクトの課題を解決できるようになりたいです。

穴澤:
平井さんが丁寧にレビューを返したり、岡本さんのtimes(slack上の自分チャンネル)にちょくちょく顔だしてサポートしているのをみかけて丁寧だなあ〜と言ってる諸先輩達も多いです。これからも一緒に頑張りましょう!ありがとうございました。

f:id:enigmo7:20211012140847p:plain
今年入社の岡本さんのtimesで召喚される平井さん(平井さん実はもっと岡本さんによばれたい)

*1:データテクノロジーグループのレコメンドデータとアプリケーションをつなぎこみ、特定のユーザに適切なブランド・カテゴリを表示する機能。レコメンド取得APIGCP上に構成されている。

技術書・OSSの輪読会 "junior_workshop" を1年続けたのでふりかえる

サービスエンジニアリング本部アプリケーション開発グループの岡本です。 私の前回の投稿からおよそ1年が経ちました。

本記事ではエニグモ社内で行われている勉強会の中から、私も参加している通称「若手勉強会(Slackのチャンネル名は#junior_workshop)」の取り組みについてご紹介します。

勉強会の概要

こちらの勉強会は「Web開発における基礎知識を身に着ける」をテーマに掲げ、経験の浅いアプリケーションエンジニアの知識の底上げを目指して2020年の6月から開始しました。二週間に一回のペースで業務時間内にZoomやGoogle meetを繋いで実施します。

f:id:enigmo7:20211022094906p:plain
「若手勉強会」のREADME(一部)

主な参加者はBUYMAのWebアプリケーション開発を行っている入社数年以内のエンジニアです。

各回、1時間半程度を費やして技術書を輪読したり、普段利用しているOSSソースコードリーディングを行っていました。

扱った題材

技術書 1

技術書を読む際は一週につき1章ずつ進めます。「メタプログラミングRuby」を輪読した際は、各週で本の内容をまとめたドキュメントを作成する担当者を決め、わからなかった点・気づいた点を質疑応答の時間で話し合うという形式で進めていました。

Java言語で学ぶデザインパターン入門」では章の初めに作りたいアプリケーションの要件が付されていることが多いので、その部分だけ読んで自分でクラス図を設計し、余裕があればコードを書き、全員集まってクラス図やコードを共有してレビューしながら本を読んで答え合わせをする、という形式をとっていました。

OSS

業務では主にRuby on Railsを使って開発をしているため、普段使っているRubyのgemやRailsの機能を題材とすることが多いです。学んだことは若手勉強会用に作成したSlackの#junior_workshopチャンネルにメモしたり、esaで記事を作成していました。

f:id:enigmo7:20211022094458p:plain
筆者がesaに記録していた回

f:id:enigmo7:20211022134709p:plain
Slackの#junior_workshopチャンネルで知見を共有している様子

1年のふりかえり

1年以上定期的に勉強会を行ってきたので、先日参加者全員でふりかえりを行いました。今回使ったふりかえり手法は「YWT(やったこと・わかったこと・つぎやること)」です。

Y(やったこと)は上記のため割愛しますが、WとTの中から参加者の皆さんの声を一部ご紹介します。

W

技術書、OSSを読んでわかったこと

  • デザインパターンを自発的に学習する機会がなかったが、いざ勉強して色んなソースコードを読んでいるとデザインパターンの文脈で扱われる用語が使われていることがあることに気づきコードの意図を理解しやすくなった
  • デザインパターンの輪読会において)同じテーマで各自プログラムを作成し、その実装・設計に関して議論することで他の人の設計アイディアを知ることができ設計の幅が増えた。
  • Rubyデザインパターンを学ぶことができ、BUYMAソースコードを読むのに役立てることができた。
  • 技術書の輪読に関しては、自分の理解が曖昧な箇所について質問したり、他の人の疑問に答えることで一人で読むよりも理解度が上がったのが良かった。
  • pryのソースコードリーディングに関しては、自分の中でブラックボックス化していた内部処理を理解していく作業が単純に楽しかった。
  • OSSを読むことに抵抗が少なくなった

デザインパターンを学んで新たな視点が芽生えたという意見が多かったです。普段使っているOSS、一見難解に思えますがじっくりと時間をかけて内部構造を読み解いていく時間が私も楽しく感じました。

その他

  • 輪読形式だったため発表することを意識し、一人で読書するときより知識が定着した。
  • 他の人が利用しているエディターやその他のツールを知ることができた。
  • 質問を受けることでなんとなくわかった気になっていた内容を復習し記憶として定着させることができた。
  • 途中から業務が忙しいという理由で参加しなくなってしまった…

自学することに加えて他人に教えたり発表するなどして知見をアウトプットすることで理解が深まることを実感しました。

T

  • OSSにコントリビュートしたい、今後も継続していきたい
  • OSSソースコードリーディングで培った速読力?を普段の調査系のタスクで生かしていきたい。
  • なかなか OSS へのコントリビュートもできていないので積極的に OSS 活動にも参加していきたい。

実は既にRuby/Railsに関するOSSに貢献している方もおられます。

tech.enigmo.co.jp

おわりに

1年が経過し、参加者それぞれが重要なタスクを任されることが増え忙しくなってきたので、このタイミングで定期的な若手勉強会は一旦ストップすることにしました。今後はRubyに限らず、勉強会でやりたい企画があれば随時開催しようということで合意しています。(今度はデザインとかフロントエンドの勉強会やりたいですね〜という話をしていました)

エニグモではエンジニアを採用しています

hrmos.co

VPN製品の社内PoCを通して考えたことなど

お疲れさまです。インフラチームの山口です。

新型コロナウィルスの影響下でのリモートワークに伴い最近社内でいくつかのVPNアプライアンスのPoCを実施したのでその際に考えたことや振り返ってこうしておくべきだったという内容を戒めとして各フェーズに沿ってエッセイとして記載します。 なお、現在進行系で数種の製品のPoC中のため、「何か特定の製品を使ってうまくいった」や「弊社はこうしている」などの情報は何もない、私が感じたチラシの裏的なレポートになります。

要は、技術的に新規性のあることはない内容ですが、同じような問題意識を持ってる人間に届けばいいなといった感じの文章になります(文章でもなんでも刺さる人にだけ刺さればいいというポリシーなので、そういった感じです)。

本稿の構成を以下に記載します。

まず、筆者の経歴および、前提条件を説明します。 次に、製品選定や実際のPoC準備から実施までに考えたことを記載します。 そして、最後に感想をまとめます。

筆者の経歴

前職は以下の感じの業務に従事しており、お客様のネットワーク構築やビデオ会議の導入などをしていました。

  • 顧客のNW(主にWAN)構築・運用(所謂ネットワークエンジニア)
  • ビデオ会議の端末やサーバの導入・運用など(これは何エンジニアなのか適切な表現は思いつかない)

その後弊社に転職して今に至ります。

要は、法人のお客様にベンダーのアプライアンス製品を導入したりする仕事をしている人の気持や挙動は薄々イメージつくといった感じになります。 前職では、企業の情シスの方が主に対面となる顧客の形でした。

が、今回のPoCでは、どちらかというと企業の情シスに近い動きをしており、立場変わると見え方変わるなというのを感じています。 その一方で、再販のベンダーさんが英語の資料ベースにパワーポイントなどでまとめられた日本語の手順書などいただくと、「こういう類作るの面倒だよね(困ったら英語の一次資料頑張って読むけど、利用者としては日本語でアウトラインまとめられているのはありがたい)」という気持ちもあったりして日々勉強させて頂いています。

前提条件

本稿全体の前提にかかる弊社の現状について開示可能な範囲で簡単に箇条書きで記載します。 今回のPoCについては基本的に情シスと協力して進めるという形を取っています。

  • 社員数
    • 150人強(業務委託の方なども含む)
  • 人員の構成
    • 情シス: 2名
      • 社内NWや社内のPC/社内で利用する外部サービスの管理など
    • インフラ: 7名
      • 自社サービスのインフラ部分を担当
      • 当初は情シスワークもインフラで実施していたが、専任の情シス担当者着任に伴い移管したという経緯がある
      • 情シス・インフラは部署としては別ライン(会社でよくある構成だと思いますが、情シスは人事総務系の所属・インフラはエンジニア部門の所属)
  • NW構成と運用
    • オンプレミスからAWSへの移行中のためデータセンタ・AWS側それぞれへのIP到達性が必要
    • リモートアクセスVPNはルータではなくLinuxサーバで終端(PC側は各OSに組み込みのクライアントを利用)
    • VPN関連はインフラの管轄(ただし、社員からのVPN関連の問い合わせやサポートは情シスでも一部対応してい頂いているケースもある)
  • 問題意識
    • リモートワークに伴い以下の工数が増えている点を改善したい
      • VPNの初期設定時のサポート
      • VPNがつながらないなどのサポート

製品の選定

製品の選定の際に考えたことを記載します。

まず、選択肢として、ベンダーの提供している製品を使うか、自分たちでOSSをベースに構築するかがあると思います。

弊社の状況としては、OSSなどを組み合わせて自分たちで独自に構築して運用する工数を取ることは避けたかったため、ベンダーの製品を選択する形を取りました。 また、ベンダーという単語は本稿では、サービスや製品を提供している企業と、その製品の代理店をなんとなく指す意味合いで使います。

  • OSSを組み合わせて構築する
  • ベンダーの製品を使用する

次に、製品を選ぶ際に考えた点を以下に記載します。 以下に明示的に記載はしていませんが、コストも気にはします。

  • 利用者の観点で設定が簡単か
    • VPNの設定のサポートが辛いという問題を解消したいのでこれは重要。
  • 端末のアップリンクでのポートの遮断などに対応可能か
    • 要は、リモートワーク時のご自宅のNWなどでポートが遮断されている場合はTCP:443などにフォールバックしてつながってくれるような製品かどうか。
    • リモートワークの際に、社内のメンバーのご自宅のNW機器の設定起因と思われるトラブルに対して、会社としてどこまで手を出すかは悩ましいところなので極力robustに動いてくれる製品が良い。
    • 前職なら「お客様責任のお客様機器」なので設定変更はご法度的な箇所を、製品の型番教えてもらいマニュアル読みつつ影響なく問題を回避する方法を調べ対応するのは面白くもあるが、しくじったときにお互いに辛い。
    • が、まあ最近の製品は、おおよそフォールバックして通信してくれるのでそこまで気にする必要は実際無い印象。
  • PoCや導入に際し既存への通信影響がなく、可能であればNW構成も変更せず利用可能なこと
    • 要は、PoCや検証のために既存の通信経路などの変更はしたくない。
    • 最近の流行りだと大概はデータセンタやVPCに配置するVPNサーバに相当するアプライアンス側でも、アウトバウンドでクラウド側と接続するデザインが大半の印象なのでこれもそこまで気にする必要はなかった。
    • また、オンプレミス側に配置する仮想アプライアンスのためには、ESXiがあれば良い
      • Dockerのイメージが提供されている製品もあるようであったが一部機能に制限などがあるため基本はESXiかHyper-V仮想マシンをデプロイする。
      • 余力があればEKSなりECSで動かしてみるかといった気持ちを当初抱いていたが実際はそんな余力はなかった。
  • サポート体制
    • 英語での問い合わせでも良いですが、辛いので可能であれば日本語でサポートが受けられるのが望ましい。
  • 息が長い製品であるかどうか
    • 要は、ベンダー都合でEOS(End of Support もしくは End of Service)にすぐならなさそうか。
    • これは前職でベンダーの日本法人がなくなったり、EoSに伴う後継の製品への置き換えが辛かったりというケースがあったので少し気にしました。
      • が、根本的に利用者側としては回避する方法はないので頭に留めておく程度。

PoC準備

次に社内PoCの準備に際して考えたことを記載します。

  • 事前に製品の検証をしておく
    • 社内でPoCの依頼をする前に、事前に製品の挙動などの検証をしておきます。
    • 社内のメンバーに使ってもらう状態になると気軽に設定変えて試験といった形が難しくなるため事前に気になる点は検証をしておくのが望ましい。
  • 協力を依頼する部署に事前にお願いしておく
    • 会社の規模にもよるとは思いますが、流石に昨日の今日で社内の各部署に「明日から社内PoCやるんで協力よろしく」は避けたいので、事前に協力を依頼したいメンバーをリストアップし、上長含めて事前にご協力のお願いを出すという形にしました。
    • 各部門で数人ずつ協力していただき、概ね漏れがないような人選としました。
  • 各種手順の準備
    • インストール/アンイストール/トラブルシュートの手順は事前に準備しておきます。
    • 準備しておけばおくだけ、後が楽になるため注力しておいた方が良いと思いますが、後から漏れなどが出てくるので実際社内PoCの間にも追加で準備したりしていました。
  • ローカル開発環境でも影響が無いか
    • PCから各リソースにIP到達性さえあればよしとしてしまっていて盲点的な箇所ではあったのですが、弊社サービスのローカル開発環境がリモートのDBなどと通信している箇所があり、PoCを行う製品でも既存のVPNと比較して、ローカル開発環境が極端に遅かったり不安定にならないかを確認します。
    • たまに遅いなどの問題をうまく検知するために、事前に負荷試験ツールの類でローカル開発環境に対して数時間試験をしてレスポンスタイムを記録し定量的に比較できるようにしておきます。

PoC実施&評価

PoC実施中から評価の際に考えた内容を列挙します。 実施する状態になったらやりきるしかなくて、どれだけ事前に準備して問題潰しておくかだなと言うのが正直な印象です。

  • PoC中はPoCに対する問い合わせ対応を最優先にする
    • 社内PoC中はPoCに関連する問い合わせの対応を最優先にするよう事前に自分の持っているタスクの段取りなどを調整していました。
  • PoC実施中にうまくいかないケースがあったら問題判別を強行しない
    • PoCしてもらっているメンバーからうまく動かないなどの問い合わせがあった場合、長時間に渡る可能性がある問題判別は極力避けるようにしました。
    • これは、社内PoCに協力いただいていること起因で、既存の業務に影響が出てしまうのは本意ではないため、うまくいかない点の解消がすぐできなそうなら、既存のVPNに切り戻して業務継続していただくような形です。
  • 評価方法
    • 複数製品を評価する場合何らかの形で数字に落として比較できると嬉しいので、PoCに協力していただいたメンバーにアンケート取る形にした。

まとめ(というか感想)

まとめというか感想なのですが、社内の利用者・情シス・インフラ・再販事業者・製品ベンダーなど立場が変わると見え方も変わると思いますが、それぞれの立場でみんな幸せになる形で、構成を改善していけるといいなという気持ちです。