マーソ株式会社を退職します
6 月 30 日付けで退職、昨日 28 日が最終出社日でした。 2018 年 2 月から、約 1 年半お世話になりました。
マーソ株式会社 is 何
( 2019 年 6 月末時点の情報です )
MRSO という Web サービスを運営している会社です。 MRSO は、人間ドックや検診を全国の医療施設から検索・予約できるポータルサイトです。 登録されている医療施設数は、国内の類似サービスの中ではトップクラスの規模です。
他にもこんな事業をやっています。
- MRSO で利用できるギフト券、マーソギフト券の販売
- 健康をプレゼントするとう考え方
- ご両親に人間ドックを受けてほしい！ というユースケースが多いようです
- 企業向けの健診結果管理システムの開発・運用 ( toB )
何をしていたのか
MRSO の開発・運営に必要なほとんどの領域を担当していました。 具体的には、
- 新機能の開発やバグ修正
- 問い合わせ対応
- 現行の仕様や不具合の調査 ( ほとんどの仕様がドキュメントに残っていない )
- 一部機能の設定変更
- エッジケースの手動オペレーション
- 障害時のトラブルシューティング
- データの抽出
- こんなデータが欲しいんやけど、を SQL にゴリゴリとトランスパイルしていました
- 開発環境、テスト環境、本番環境のインフラメンテナンス
こんなことをやっていました。
他にも片手間で、
- 技術的な相談
- こういうことを実現したいけどどうしたらいい？
- 壁打ち役
- Slack bot を作る
- 分かったことをひたすらドキュメントを残していく
- 新卒 3 名 ( ベトナム人 ) の教育
- 議事録をとらせて、あとで一緒に振り返り
- モブプロ ＋ TDD
もやってましたが、特に教育に関しては思いつきベースで取り組んだものの、 もっとちゃんと考えてあげたかったな～と反省しています。
何を残せたのか
具体的な成果物として残って、特に活用されている ( と感じている ) 順に並べてみるとこんな感じです。
- 本番環境相当のテスト環境作成
- テスト環境 Docker 化
- 社内にあった Jenkins サーバーを AWS 上に引っ越し
- メルマガの配信作業を都度から 月 1 回にまとめた
- 仕様などを調査したドキュメント
- CakePHP 2.x -> CakePHP 3.x のコア機能移植
- 管理画面のセキュリティ強化
- WordPress Plugin & CLI 開発
特に 1. 本番環境相当のテスト環境 は社内・社外関係者含めてめちゃくちゃ使われています。 網羅的な状態パターンのテストができていないと、本番環境の状態の再現してテストする必要があって、 そのコストをすっ飛ばせるようになったのは大きいです。 構築当初に想定していた以上の ROI だったんじゃないかと思います。
なぜ辞めるのか
会社や上司、同僚の仕事に対する考え方が合わない
一言でいうとこれにつきます。 具体的には、
- エンジニアがあまり大事にされないと感じる
- フレックス・リモートワークなし、 9 時 - 18 時は要出社
- 実際は出社しないとできない仕事はほとんどない
- リモートでコミュニケーションをうまく取れない人が多いのは事実
- 保守的な考えの人が多く、変化を恐れがち
- 技術レベルの高い人がいない
- みんな見様見真似で CakePHP を書いている
- チームで成果を出すことを真剣に考えていない
- 要するに個人プレーの集まりで仕事をしている感
- とりあえず人を集めてリソース効率高く仕事を振ることはできる
- 成果の品質やフロー効率は考えられていない
- あまり情報をオープンにしない文化
- 期限を守ることが最優先され、品質の妥協や残業でカバーといった手を打ちがち
- 事前にプレスリリース打ってるわけでもないのに、みたいなのがちらほら
- オンボーディング、教育が無
- エンジニア採用をあきらめている感
- このまま居ても優秀な人には出会えなさそう
こういうことが積み重なって入社直後からモチベーションが下がり、 遅刻や欠勤が目立つようになってしまいました。 単純に体調が悪い日もあれば家で自己研鑽する日もあり、 そうやって身に着けたスキルや経験を仕事に還元していくスタイルでやっていました。 しかし面談では勤怠が悪いと評価はできないと通達されてしまい、 その際に働き方や今感じている問題を話し合いましたが、解決は難しいと確信し、退職を決めました。
2019/07/01 追記 評価と反省点、よかったところ
一方的に前職のネガティブな面を書いているように見えるので、上司や同僚からの評価と自身の反省点、前職でよかったことも書いておきます。
上司や同僚からの評価
Good Point
- キャッチアップが早い
- 入社数日でバグ修正の Pull Request 出してた気がする
- インフラ、特にネットワーク周りが強くて助かった
- 問い合わせへの回答が丁寧で的確
- 仕事の仕方がスマート
Bad Point
- 勤怠が悪い
- 期限切れのタスクを抱えたまま報告がないことが度々あった
- 特にクリティカルなものに関しては一人で考えて決める前に相談して欲しい
???
- 先生みたい ( 新人談 )
反省点
- 勤怠不良がアウトプットの物量にも影響し、結果として担当タスクの完了が遅れるなどした
- コミュニケーションで誤解や不安を与えるような伝え方をしてしまっていたかもしれない
- 良いことも悪いことも包み隠さず発言していたが、社内の文化からは逆行していたように思う
- とにかく「論理的」に「正しい」主張をするため、冷たい印象を与えたかもしれない
- もっとたくさんコミュニケーションをとったほうがよかったと思う
- 特にエンジニア以外ともっと話すべきだったな〜
- 新人の教育にしっかり取り組めなかった
前職のよかったところ
- 休みを取りづらいという雰囲気はあまりない
- あれだけめちゃくちゃ休みまくってたけど逆に気を遣ってくれてもいた
- 性格の悪い人は居なさそうだった
- そういう人も自然とフェードアウトしていくのかも
- ビジネス面でもまだ伸び代があると思う
- ルールが整備されていないので自分たちでルールを作っていける余地がある
2019/07/01 追記終わり
次はどうするのか
株式会社ゆめみ でサーバーサイドエンジニアとして働きます。よろしくお願いします。
ゴリラ.vim #4 に参加してきました #gorillavim
当日飛び入りで参加してきました。 今回は神回という声もあって、そんなタイミングで参加できたのは幸運だったなと思います。
各発表のサマリと感想
翻訳プラグイン作った by ゴリラ さん @gorilla0513
- コマンドやバッファで入力した内容を翻訳
- GAS ( Google Translate ) + Go + VimScript で実装
- バッファに文字列を入力して Enter すると逐次翻訳されていく様は見ていて楽しい
- 学生の頃、英単語の勉強のために xyzzy で似たようなことやってたな～としみじみ
- ゴリラさん、 さくらのナレッジで vim の連載が決定！ 今から楽しみです。
- 書籍も出したいとのこと
【速報】
— ゴリラ (@gorilla0513) 2019年5月13日
さくらインターネットさんのさくらのナレッジでvimの連載が決まりましたhttps://t.co/GRgdjHmrBi
GWで初めてVim Pluginを作った話 by かまたけんし さん @knsh14
- Vim のバッファ上の選択範囲から GitHub のリンクを作ってクリップボードにコピーするプラグイン
- 便利！
- コードレビューとかで「ここの実装見てみて」といったアドバイスするときに URL 欲しくなる
- いつもブラウザでアクセスしてアドレスコピーしてた
- 今のところ GitHub と GitLab に対応
選択範囲から GitHub のリンクを生成してクリップボードにコピーするプラグインhttps://t.co/JSFZKZg0MB#gorillavim pic.twitter.com/kDyWQ9Y9D4
— ɐɯɐsɐʞ! (@ikasamak) 2019年5月15日
terminal-api について by てんなし さん @tnnsh1
Tapi_oka を call すると ● を出力する vim plugin#gorillavim
Neovim 0.4.0 新機能 フロートウィンドウについて by ドッグ さん @Linda_pp
- 既存のウィンドウの上にオーバーラップしたウィンドウを作ることができる！
- 従来の Vim ウィンドウと同じように使える
- はみ出すときは自動で位置とサイズを調整してくれる
- こういうところ考えなくてよくなるのは楽！
- フロートウィンドウを使った Plugin 例
- git-messenger.vim
- カーソル位置のコミットログをフロートウィンドウで表示 github.com
- vim-iced
- カーソル位置の Clojure の評価結果をフロートウィンドウで表示 github.com
- git-messenger.vim
- 惜しむらくは Neovim の機能というところ
- 本家 Vim にもほしい！
- それか Neovim に乗り換えるか
飛び入り LT by tamy さん @__tamy
- comamnd-line fuzzy finder の紹介
- 作者謹製の Vim Plugin もある
- バッファをたくさん開いているときのバッファ選択とかに強い
- fzf はいいぞ！
- ぼくも enhancd と組み合わせて使ってます
飛び入り LT by ujihisa さん @ujm
- ライブコーディングが印象的でそれしか覚えてない、、、
grepコマンドを VimScript で実装してみることに- 「美しいけど動かないコードより汚くても動くコードのほうが無限倍良い」、至言
- 小さく実装して QuickRun を回す
- スピードが圧倒的に違う、、、
- マニュアルを参照しながら実装していく
- これはフレームワークに乗っかって開発するときはよくやる
最終的に出来上がったコード ( 所用時間: 15 分 ) gist.github.com
米国に行かれるそうなので、これが日本で最後の LT になるかもとのこと
- 最後に面白いもの見させてもらいました！
飛び入り LT by はやぶさ さん @haya14busa
- タブにラベルを付与して表示させて、それをもってタブ移動できる
- タブ 4 つ以上開いてるときは便利そう
- でもぼくは tmux 使うから Vim の中であんまりタブ開かないかも……
VimConf 2019 の告知！
全体を通して
レガシーをぶっつぶせ。現場でDDD！ 参加レポート #genbadeDDD
申込み時点で +100 人くらいで補欠だったので諦めてたんですが、 当日の 0:30 に繰り上がり通知が来て、慌てて参加しました。
全体を通して、いくつか印象に残ったことを書いておきます。
- 始める前にメンバーとの共通認識をつくる
- DDD の方法そのものの学習
- 業務知識の理解
- エンジニア以外のメンバーとの共通認識も重要
- 良い設計のためにはビジネスの理解が必要
- まったく新しく取り組む場合はリスクを小さくする
- 小さく始める
- 重要だが緊急性が低いもの
- 緊急性が高いと品質を犠牲に完成を強いる圧力がかかりがち
- ビジネスサイドへの説明は簡単ではないが大事
- 小さく始めると少ないコストで実績を積んで成果を確認できる
- 刷新前と刷新後のコードベースに対して同じ改修をして効果測定をした
説得のために刷新前と刷新後全く同じ機能を作って効果測定したらしい！すごい #genbadeDDD pic.twitter.com/xVcRCk8kfn
— 松岡@DDDブログ書いてます (@little_hand_s) 2019年5月11日
- 変化に弱い = レガシーになりやすい
- とりあえずマイクロサービスにすればいいというわけではない
- サービス分割がイケてないとやっぱりポシャる
感想
- 新規開発ではつまづかないような、レガシーと戦う上での知見が聞けてよかった
- チームで DDD に取り組むための心構えができた
- まだ仕事で実践できていないけど、学んだ内容の再確認ができた
- DDD は銀の弾丸ではない。レガシーとの戦いは泥臭い作業の繰り返しだ。
zsh + zplug で最強でポータブルなターミナル環境を作りたい
タイトルで言いたいことは全部言いました。
なんとなくインストールしていた zplug, よく見ると何でもかんでもインストールできることに気づきました。
zplug "jhawthorn/fzy", \ as:command, \ rename-to:fzy, \ hook-build:"make && sudo make install"
これを使えば、言語環境から各種 CLI ツールまで全部 zpug で管理できるのでは？ 最終的に、まっさらな環境で
sudo yum install -y git zsh git cllone git@github.com:ikasam/dotfiles.git chsh -s /bin/zsh exec zsh -l
と実行するだけで開発環境が出来上がるかもしれない。
導入するもの
次に新しい職場に行くまでに作っておきたい。
技術書典 6 の本の感想 / 技術を伝えるテクニック
- テクニックの具体例があって実践しやすい
- 文章だけでなく、登壇のテクニック、上手く教わるテクニックも紹介されていて良い
- 目次だけでもだいたい伝わってくるところがすごい
技術書典 6 の本の感想 / フリーランスを完全に理解できる本 / バーチャル幼女プログラマー きりみんちゃん 公式ファンブック
フリーランスを完全に理解できる本
- フリーランスという働き方にまつわる事柄を 1 冊で知れます
- 一つ一つのトピックは自力で調べられる内容だけど、コンパクトにまとまっていて良い
- 単価水準は参考にしてみようと思いました
- あくまで 2019 年現在、東京都内の Web 系エンジニアの相場です
- 税金周りはサラリーマンでも知っておいて損はない内容だと思います
- キャリアについては軽く触れられている程度ですが、すぐに実践しやすい内容です
- このあたりを掘り下げたかったら、より詳しい専門書をあたると良いでしょう
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
バーチャル幼女プログラマー きりみんちゃん 公式ファンブック
- 文字が少ないので脳のリソースを使わなくて良いです
- 1 ページ目に
Hallo kirimin-chanって書いてあるけど幼女キャラの演出かなと好意的に捉えています - 君も公式ファンブックを買ってきりみんちゃんを応援しよう！
CakePHP 2.x の PaginatorHelper をハックする
TL;DR
この CookBook にあるようなパラメータを $this->request->params['paging'] に渡すことで任意のページネーション表示ができます。
https://book.cakephp.org/2.0/ja/core-libraries/helpers/paginator.html#PaginatorHelper::params
実際にパラメータを渡すサンプル。
$params = [
'page' => 2,
'current' => 10,
'count' => 777,
'prevPage' => false,
'nextPage' => true,
'pageCount' => 4,
'order' => null,
'limit' => 10,
'options' => [],
'paramType' => 'querystring',
];
$this->request->params['paging']['YourModel'] = $params;
背景
いまどき CakePHP 2 かよ！ とお思いかもしれませんが、なかなかレガシーから抜け出せない組織、ありますよね。 弊社ではようやく新しいフレームワークに移行することが決まったんですが、それがまさかの CakePHP 3 。 どうせならもっとほかのフレームワークにしてくれや……と内心思いながら移行の仕事をしています。
今回の移行は、利用者や役割の異なる複数のアプリケーションにそれぞれ書かれている、同じようなビジネスロジックを API に一本化してしまおうという目的があります。 単なるデータフェッチなら API にまるっと移してほぼ同じ構造のデータを返してもらい、 Controller とかがそれを受け取ればいいだけです。 しかし Paginator は View に がっつり Helper として入っていて、正直修正したくない。 *1 ということで Paginator によるデータフェッチをレガシーから切り離しつつ、 レガシーの Paginator には出来合いのパラメータを渡して PaginatorHelper を生きながらえさせる作戦を考えました。
実装
PaginatorHelper のパラメータサンプルの URL を再掲します。
https://book.cakephp.org/2.0/ja/core-libraries/helpers/paginator.html#PaginatorHelper::params
各パラメータの意味はこんな感じ。間違っていたら指摘ください。
$params = [
'page' => 2, // 現在のページ番号
'current' => 17, // 現在のページに表示している件数
'count' => 3, // 全体の件数
'prevPage' => false, // 前のページがあるか？
'nextPage' => true, // 次のページがあるか？
'pageCount' => 4, // 全体のページ数
'order' => null, // ソート順
'limit' => 26, // 1 ページの件数( {:start}, {:end} の計算に使うのはこちら )
'options' => [], // ページネーションのオプション。なんかいろいろあるっぽい。
'paramType' => 'querystring', // 生成するリンクのタイプ。この場合は ?page=2 のようなリンクを生成する。
];
こういうデータを渡してあげることで、実際のデータフェッチ内容とは無関係のページング UI を生成できます。
しかし無意味なページング UI を構築しては使い物にならないので、フェッチしたデータとの整合性をとる必要があります。
今回、データフェッチは API 化して HTTP の JSON でレスポンスを返してくれる実装になりました。
なので、データと横並びでページングのパラメータをセットし、それをそのまま横流しする形をとりました。
気を付ける点として、 API 側は CakePHP 3 のため、若干パラメータのキーが変わっています。
以下、 CakePHP2 => CakePHP 3 の形式です。
order => sort*2limit => perPage
この変換は CakePHP 3 側に実装しました。 こういった互換性対応は新旧どちらに実装するかは好みによるところですが、新 : 旧 = 2 : 4 という事情もあって新側に実装しました。 *3
余談
今回の CakePHP 2 => CakePHP 3 移行でこういうのも作りました。 レガシーと戦う全国 5000 億人の CakePHPer のためにも、また別の機会に紹介できたらなと思います。
まとめ
$this->request->params['paging']にパラメータを渡すことで PaginatorHelper を操れます- CakePHP 2 <=> CakePHP 3 の Paginator のパラメータには一部互換性がないので気を付けよう
