黒橡開発室

R:050 G:044 B:040

今年の目標

最終的には3つ目の健康であることにたどり着くことが目的です。
ここ1・2年で、仕事で上手くいかなかったときに真っ先に体調に悪影響が出るということがはっきりと分かったので、1つ目の目標に取り組むことで少しでも仕事で生じるストレスを解消していく必要があります。
2つ目の目標では、自助努力だけでどうにもならない局面がそう遠くない未来やってくることが予想される(すでに来てる)ので、
周囲の意識や仕組みを変えることだけに囚われず、いざとなれば自分の身を置く環境をいつでも変えられるような状態を用意できるように動きます。
3つ目は言わずもがなです。心身が元気じゃないと自分の納得のいく仕事にならない上、何よりプライベートに大きな影響が出るため極力避けたいところです。


1. 仕事を通して取り組むこと

書き出してみるとめっちゃありますね・・・でも全部大事。

  • チーム開発の概念を整備〜布教する
  • 仕様に関するドキュメントの作成・保守の方法を布教する
  • コーディング規約の策定・布教、PSRの理解を深める
  • 環境構築手順の整備
  • テストの手法を整理して布教する
  • デバッグ環境の整備〜布教
  • バージョン管理環境の整備〜布教
  • 自動デプロイ環境の整備〜布教
  • レビュー文化を根付かせる、レビュアーとしての経験を積む
  • チケット駆動開発を根付かせる
  • 基本設計〜詳細設計のスキルアップを意識する
  • TL経験を積む

現状、下3つを除いてどれも今の環境には存在しません。
かろうじてチケットでタスクを整理する取り組みは観測範囲で2案件あるようなので(うち1つは自分の担当案件)、まずは実現までのハードルが低そうなものから取り組んでいこうと思います。
また、去年自分が関わった新規案件ではいくつか局所的ながら実現できたものもありますが、まだまだ発展途上なのでより最適化していきたいです。
(Git導入・レビュー制度・仕様面や環境構築に関するドキュメント作成・チケット駆動開発・基本〜詳細設計・TL業など)

また、入社してから知ったのですがそもそも1案件を複数人で開発すること自体が少なく、レビュー文化やバージョン管理などはほとんど存在していないので、
制度として根付いてそれを回していけるようになるまでにどれだけの時間がかかるかは正直言って想像がつきません。

それでも取り組むべきと思うのは下記の問題に向き合い改善することで、自分も周囲も仕事のコストが大きく下げられると考えたからです。

  • ドキュメントを残す習慣がなく業務の属人化が進んでいる(実装して終わり・保守や引き継ぎの意識が薄い)
  • ドキュメントを残す習慣がなく前任者しか把握していないことを知るには前任者を捕まえて聞き出すしか方法がない(前任者自体いないケースも)
  • バージョン管理の概念がないため本番・テスト環境に大量のhogehoge_20210102_bakのようなファイルが存在する
  • バージョン管理の概念がないためソースコード編集履歴目的と思われるコメントアウトされたコードが大量に存在する(bakファイルの件と相まって影響範囲調査でgrepすると大量のゴミが混じってしまい調査工数がかさむ)
  • バージョン管理の概念がないためどの環境に誰がいつ何を入れたのかを把握する方法がない
  • バージョン管理・特に環境ごとにブランチを分けるという概念がないため、一つのプロジェクトリポジトリにテスト環境用のコードと本番環境用のコードが平然と混在している
  • 自動デプロイの概念がないため環境への反映漏れ・間違いが起きやすい
  • 自動デプロイの概念がないため障害が起きた時に即座に切り戻すのが難しい
  • 本番・テスト環境間の同期が取れておらず、検証環境に入れた変更が本番環境でも動作する保証がない(裏を取るための調査工数がかさむ)
  • 全社的なコーディング規約が存在しないのでコードの品質が実装者個々人の良心に依存しすぎる
  • レビューがないためコードの品質が実装者個々人のスキルに依存しすぎる
  • レビューがないため客観的なフィードバックを得る機会がなく学習・成長機会が乏しい
  • テスト=画面越しの結合テストのみ・全て手動なので時間がかかり過ぎる、ミスやケース漏れも起きやすい
  • テストの時間がかかり過ぎるので必要なテストケースを網羅し切れず障害につながりやすい
  • そもそもテスト設計が事前にされることがほぼなくケース漏れが頻発している
  • 自動テストの概念がないためデグレに気づかず本番環境に上げてしまいがち

開発に関わるものだけに絞り込んでも今の環境はこれだけの問題を抱えているんだなという認識を持っているのですが、
最も問題なのはこれだけのことが起きていても誰も行動を起こして改善する気がないという事実です。
誰もこれ以上タスクを抱える余裕がないことや、開発環境やコードの品質の向上を実現しても会社にそれを正当に評価する仕組みが存在しないことも要因の一つかなと想像しています。
そりゃご褒美がなかったら誰もやる気出さない。
ただ、様子を見るに「どうにかならないかなー」「もうちょっとうまくできたら良いんだけどなあ」という意識は全くないわけではないみたいなので学習コストがかかり過ぎず・かつ直接的に今持っている困りごとを解決できそうなところから攻めていって、小さな実績を積み重ねつつ信用を得られるよう立ち回っていきたいと思います。
会社自体の体制の話になってくると自分一人で出来ることはたかが知れているので、自分がどこまでやるか・目標を何とするかは明確に決めておいた方が良いように思いました。
その辺は書くと長くなりそうなのでいずれ別記事にしようと思います。


2. いつでも転職できる準備
  • スキルの棚卸し
  • 転職の目的を明文化できるように考えを整理
  • 武器の選定して磨く
  • 資格勉強して体系的な知識の習得
  • ポートフォリオサイト作成
  • カジュアル面談を受けてみる

あえて見出しの中に「転職」という文言を入れましたが、先に結論から言うと今は転職するタイミングではないと思っています。
今の環境で頑張れるうちは今できることを一つ一つやり続けていけばいずれ良きタイミングが来ます。
次のキャリアを目指すとしてもまだまだ自分は未熟です。スキルも経験も圧倒的に足りていない。

一方で、前述の通り今の環境には何もかもが不足しているのでそれらに起因する精神的な負荷は大きいです。
いつ身体が限界を迎えてもいいように・いざというとき適切に休職->退職->転職のコンボを決められるように準備しておくことは精神衛生的にも非常に効果的です。

スキルの棚卸し
今までのエンジニア業で何をやって来たのか、何が出来るのかを人に見せられる状態にしておきます。幸い前回の転職で作った職務経歴書があるのでそれに肉付け・ブラッシュアップしていけばさほど時間をかけずに用意することができそうです。こういうのは定期的にアップデートするのが大事。

転職の目的を明文化できるように考えを整理
履歴書や面接で言うところの「志望の動機は?」の答えに相当するものの準備です。
なぜ自分は転職をしようと思っているのか、自分が転職して新しい職場に期待することは何か?
日々考えを巡らせてはいるもののパッと今すぐ他人に齟齬なく説明できるかと言われると難しいです。

武器の選定して磨く
一つ目のスキル棚卸しともリンクしますが、自分を売り出すための武器を用意する必要があります。
これまでにやって来たことはより一層精度を上げていきます。自分であればPHPJavascript、設計やテストの技法についてでしょうか。
高い需要が見込めるものについては積極的に新規学習を進めます。AWSやTypescript・Python、クリーンアーキテクチャテスト駆動開発など。
学習が進んだらある程度まとまった成果のアウトプットをいくつかweb上に公開していきます。
一つ一つ大層なものは目指さない様に、回数と頻度をキープすることが大事(去年はたいしてキープできなかった)

資格勉強して体系的な知識の習得
初学者の頃、基本を叩き込む目的でJava silverを取得して実感したのですが、体系的な知識を身につけるのに資格勉強はかなり効果がありました。
しばらく資格取得からは離れて実戦で勉強することがメインになっていましたが、今取り組むとしたらこの辺でしょうか。
aws.amazon.com
www.pythonic-exam.com


ポートフォリオサイト作成
学習履歴のアウトプットの数が揃ったらそれを取りまとめて公開可能なポートフォリオを用意します。
サイト自体はシンプルな静的ページでいいと思います(ただしホスティングの仕組みや何を使っている・なぜそれを使っているかはきれいに説明できるようにする)
デザインはうまく作り込めたら良いんでしょうが自分はデザインについては素人なので・・
でも見る人の印象に大きく関わる要素なので機能美的観点ではこだわれると良いかもしれません。UI/UXは頑張る。
また、次回の転職活動ではポートフォリオを応募条件としている会社に積極的に応募出来るといいなと思います。

カジュアル面談を受けてみる
自分の市場価値をもっと客観的視点から測る癖はつけたほうが良いなと常々思っていたのですが、今の環境に身を置くことでよりそれが顕著に感じられる様になっています(理由については別記事で)


3. 健康について

記事が長くなって来たのでここでは簡潔にまとめます。

  • 日常で感じるストレスの原因を分析する〜文章に残す
  • 睡眠の質を向上・維持する
  • 休職の準備
  • 医者に頼ることも考える

メンタルのバランスをうまく取りながら仕事もプライベートもやっていくというのは一人の力だけでは非常に難しいことなのかもしれません。
適切に他者にアラートを出してヘルプを要請できる立ち回りを意識してやってみます(苦手)


あとがき

ぐだぐだといろんなことを書き散らしましたが、今年も自分の行動指針は変わりません。

今年もどうぞよろしくお願いいたします。

『パーフェクトPHP』を読んでフレームワークを作ってみた(継続中)

ゆるWeb勉強会@札幌 Advent Calendar 2020に今年も参加させていただきました。
こちらは上記アドベントカレンダー6日目の記事になります。
私は普段PHPを書いて何かすることが多いのですが、今回はPHPフレームワークを自作してみた話について書いていこうと思います。

なんでフレームワーク自作?

今年の夏頃から数ヶ月、EC-CUBE4を使ったECサイト構築に関わることになりました。
doc4.ec-cube.net
現在のEC-CUBE4系ではPHPフレームワークであるsymfony(確か3.4)が採用されており、案件では必然的にsymfonyをがっつり触ることになります。
ところが社内にはEC-CUBE4系もsymfony有識者はおらず、この数ヶ月は独力でsymfonyを勉強しながら開発を進めながらという日々を送っていました(余談ですが先日無事本番リリースしました)

なんとか開発自体は回せたものの反省点もたくさんありました。
その中の一つとして大きかったのが、

自分は雰囲気でなんとなくフレームワークを使っている

というものです。
この数ヶ月間、なんとなく既存処理を追いかけ、なんとなくリポジトリクラスのメソッドを呼び出せば、なんとなくDBアクセスができて、なんとなくコントローラからビューに取ってきた値を渡してやればそれっぽいことが大体できる、くらいのレベルの理解度で実装をしていたので、これでいいのかな?本当はきちんとフレームワークの構造や機能を理解した上で最適な選択ができないといけないのでは・・・?ともやもや。
結果必要な成果物が期待通りの動作をしていれば確かにそれでいいのかもしれないのですが、この状況には結構な危機感を覚えました。

処方箋

ある日、しばらく会社の同僚に何冊か技術書を貸していたのが返ってくることになり、久々にこいつを読み返してみました。
gihyo.jp

はい、PHPerおなじみの『パーフェクトPHP』です。世の中にPHPに関する技術書はそれこそ星の数ほど存在していますが、この『パーフェクトPHP』にはちょっと面白い項目が収録されていまして、

上記サイトより
f:id:sakiware208:20201206173213p:plain

<中略>

なんとこの本フレームワークの作り方を説明した章があるのです。
フレームワークの使い方や環境構築について記載した本はたくさんありますが、
フレームワークとは?の説明をやってから、じゃフレームワーク作ってみましょうか。となる技術書は自分は今の所この本以外知りません(他にもそんな本があったら言語問わず是非知りたいです)

というわけでいてもたってもいられずこの本を片手にフレームワーク自作というか写経、やってみました。

環境構築

『パーフェクトPHP』は良書ではあるのですが、発行年が2010年ということもあり本書のサンプルの対応バージョンはPHP5.3となっています。
さすがにこの通りに作っていくわけにはいかないので、今回の環境構築ではdockerを使いつつ以下の通りやってみました。

  • PHP7.3
  • Apache2.4
  • MySQL8.0

LAMP環境構築に関して参考にさせていただきました
github.com

今回作るもの

とりあえず何も考えずに本書の通り進めます。自分なりにやったことといえばサンプルコードをPHP7.3の文法にちょいちょい書き換えたくらい。

ディレクトリ構成はこんな感じ

application/
└ controllers/
└ core/
└ models/
└ views/
└ web/

MVCはそのまんまなので割愛しますが、core配下にフレームワークとしての基本的機能を書いたクラスを入れていき、web/はドキュメントルートとして使用するイメージです。
ブラウザからアクセスできるのはこのweb配下のリソースだけに限定させます。

フレームワークに必要な要素?

そういえばフレームワークフレームワークである為の要件ってなんなんでしょう?と聞かれて今の自分は明確な答えを持ち合わせていないのですが、
本書で作成するcore配下のクラス一覧を眺めているうちに「まあ最低限これがあるとフレームワークなんだろうなあ」という感想を持ちました。

core/
└ Request.php
└ Response.php
└ Router.php
└ DbManager.php
└ DbRepository.php
└ Controller.php
└ View.php
└ Session.php
└ Application.php
└ ClassLoader.php

リクエスト・レスポンス・リポジトリクラスあたりは「なんとなくフレームワーク開発」をしていても結構触る部分なのでイメージしやすかったのですが、
ClassLoaderなんかは普段意識して使っていないので、自分で手を動かして実装していきながら本の内容をコメントでメモしながらやりながらちょっとずつ理解を深めていきました。

github.com

最小構成から考えるちょうどいいフレームワークのこと

今回作ったフレームワークは最小構成なので、このままだと開発に使うにはちょっと痒いところに手が届かない感じがする反面、
自分にとってこれは必要だなと思うcore機能は追加で実装したり、ライブラリを導入して欲しい機能だけをあとから拡張するのも面白そうだなと思いました。
まだ触ったことはないですがslimのようなマイクロフレームワークを導入して本当に必要なものだけで構成してみたり、ライブラリの設定を細かくみていけたりできるようになったら、
必ずしもLaravelのようなフルスタックフレームワークしか選択肢がない、みたいなことにはならないのかなあと思ったりもしました(Laravelは使いやすいので個人的に好きですが)

雰囲気でフレームワークを使わないようになるには?のヒント

若干話がそれましたが『パーフェクトPHP』のフレームワークの項目の最後にこんなことが書いてありました。

PHPを深く学習していく効率の良い方法は、ライブラリやフレームワークソースコードを読むことです。特にフレームワークにはwebアプリケーションを作成する上で必要となる様々な機能が盛り込まれています。

当面は今回作ったフレームワークの機能拡張を進めたり、良さそうなライブラリを組み合わせて使いやすい構成をいろんなパターン考えてみたり、
上記のように既存のフレームワークのソースを追いかけて普段使ってる便利なメソッドがどういう実装になっているのか調べたり、引き続き進めてみたいなと思います。
ある程度の研究成果がまとまったら何かしらの発表の場で報告できればと思います。

ステイホームの話

早いもので今日で2020年も半分が終わり、そして私の無職期間も終わりを告げようとしています。

前回記事で退職〜転職について振り返りをしたのですが、今回は丸1ヶ月の無職(+有休消化)期間について覚書しておこうと思います。

(文章が取り留めなくて毒にも薬にもならない内容になってしまった)

 

なつやすみ転職期間の計画を立てる

最終出社日翌日、この時点では次のことは何も決まっていません。気ままに無職を満喫できる期間も限られています。一方やりたいことは山のようにありました。そしてやらなければならないことも山積みです。

やらなければならないことが無秩序にそこらじゅうに転がっている状況はかなりストレスです。頭も手も固まったまま時間が過ぎることだけはなんとしても避けたいところです。そこですぐ何か勉強に取り組みたい気持ちを抑えつつまずは状況を整理することにしました。

具体的には、

- Trelloで「転職活動」「学習」ボードを立てる

- 転職活動ボードに「応募したい会社」カードを深く考えずにたくさん作る・並べる

- 転職活動ボードに「できること」カード・「あんまりできないこと」カードを作る

 

まずは職探しをと思い最初の3日間くらいは「学習」ボードは作りっぱなしにしてどんな会社を受けようか、自分何ができるんだっけ、なんで転職したいんだっけ・・と自己分析風のことをしました。

そうして作りまくったカードを眺めつつ、応募する会社を決めていく中で勉強の方針についても考え始めしました。はじめの内は面接でアピールできそうなことをやろう、とかポートフォリオのために何か作ろうとかとにかく転職活動に絡めて何かをすることを考えていました。

が、それは今回やめました。

あまり深い理由はないですが、義務感に駆られてやる勉強がつまらなくなって挫折するなと思ったので、

- ゆるく楽しいことを途切れさせず続ける(厳しいノルマや難度の高過ぎることはしない)

- 自分のできること+αを新しく覚える・身につける

- しょぼいアウトプットを複数積む(立派な成果物は目指さない)

挫折はしなさそうだけど頑張れば身になりそうなラインを探る作戦です。

 

ゆるく実行する

ちょうどこの頃はTechpitやudemyで面白そうな講座がいくつかあったのでその中からやりたいものを選んで一つずつ進捗を100%にしていくことにしました。

1講座ごとに1カード作って、チェックリストを章ごとに作って終わったらチェックする、やりながら考えたこと・気づき・不明点をコメントしていったり、ちゃんと調べた方が良さそうなことは別カードに切り出してtodoに突っ込んだり。

【よかった】

・カードごとに「期限日」を決めてチェックリストを作ったのはノルマや残りのやるべきこと、やれたことがきちんと可視化された。

・CIツールの導入やAWSに触れたのはよかった。単に環境を作って動かすだけならそこまで難しく無い。自動テストや静的解析の環境を整える機会は今後来そうな気がするので予習になった(かも)

【今後の課題】

・期限日設定が下手。ずるずるとリスケしてしまったり、逆に無理に間に合わせようとして徹夜も度々発生してしまった。昼夜逆転

・ほぼ講座の内容の作りっぱなしになってしまった。追加で改修したり新機能つけたりが進まなかった。

・もっと細かくブログで記録をつければよかった(1カード1記事500文字程度くらい)

 

Trello運用もプログラミング学習も今後もゆるーく続けてちょっとずつ改善していきたいですね。

会社辞めた話

三行まとめ

- 案件終了のお知らせが来たので翌日会社に辞意表明(GW前)

- 有給消化しつつ転職先探しつつステイホーム(6月上旬)

- 内定出ました(6月中旬)

 

前々から現在の会社にはずっとはいないだろうなあ、次はどんな環境で仕事しようかな、というのはずっと考えていたのですが、今回様々なタイミングが重なったこともあり、退職〜転職活動を行う決意をしました。

というわけで、かねてより憧れていた(?)退職エントリーなるものをやります。

振り返りは大事。

 

転職後のこと

次は受託・自社開発を行なっている会社のエンジニアとして働くことに。

客先常駐なし、クライアントとは直接やりとりでシステム開発を行うことになるので、これまでとは異なる領域の力が試されるのかなと予想しています。

(開発そのものだけでなく要件定義や技術選定、開発フローの整備など?)

不安半分期待半分ですがせっかくこれまでの経歴を見て信頼してもらっているのでなんとかがんばりたいところです。

あと業務でLaravel書けるのはうれしい。

 

前職のこと

SES事業をメインで行なっている会社に3年弱所属していました。

当時自分は業界未経験で、入社前に半年ちょっとプログラミングの勉強をしたり資格勉強をしたものの到底即戦力にはなり得ない実力だったため、若干の不安はありつつ内定を受諾したのを覚えています。当時の目標としては、

- まずは実務経験を積もう

- なにかしらの得意を身につけよう(PHP)

↑こんなことを考えながら日々過ごしていたと思います。

 

前職入社後に感じたギャップ

- 最新動向を追ったり個人開発するような技術好きが全然いない

- 思った以上にスキルの水準を会社は評価対象にしてない(経験年数は重視する)

- PHPの案件全然ない

 

案外技術力自体って評価されないんだなーという気づき。ただし出向先では技術力もあって情報のキャッチアップもまめな人は必ずいました。たまたまうちの会社がそうだっただけ?

どちらかというと、いかに案件に入れやすい人材かや参画後に問題なく業務を行えるか、みたいな点を会社は重視していた印象でした。まあ人材派遣業的な側面が多分にあったのでそれはそう。

PHP書きたくて入社決めたもののめっちゃJava推されるみたいなのは多少想定してましたが、思った以上にPHPの案件を提示してもらえなかったのが印象的でした。そんなに儲からんのかな、PHP。そんなことないと思うけどな、PHP

振り返ってみると、会社に求められているスキルのイメージが自分はズレてたなと感じました。とはいえプロジェクトに入ってメンバーの方々とうまくやっていく力というのは万国共通で大切なことではあるので、それが実感できただけでも十分。

 

どうして辞めることにしたのか 

ある程度の経験年数を積めてそこそこ武器になるものを手に入れたら会社を辞めて次のステップに進もう、というのは割と当初(入社2日目)から考え続けていました。

本当はもっとスキル・実績が盤石な状態で辞めるつもりでしたが、転職の準備が完璧な状態なんて永遠に来ないわけなので(転職に限らず人生のあらゆる決断ごとはみんなそう)

目標達成した後は決断のタイミングを待つだけだなと思って過ごしていました。

前述したように入社後は多少のギャップを感じつつも自己の成長のために全力で走り続けて来たのですが、

- コロナ禍に対する会社と自身の認識のギャップ

- 今後PHP書けそうにない

- 社内だと技術の話題で全く盛り上がらないのがつらい

理由は色々ありますが特に一つ目が辞める決定打になりました。自分の努力でどうにかできることは自分が頑張ればいいだけの話ですが、そうでない場合は環境を変えるのが最も低コストな問題解決方法と判断しました。という旨上司に伝え、引き留めはありつつも最終的には納得していただき、つつがなく退職手続きを進めることができました。

 

こんな時期に無職になって大丈夫か?

今年に入って新型コロナウィルスの影響は各所に大きな爪痕を残してきましたが、そもそも今このタイミングで仕事を辞めて万が一全然仕事が決まらなくて無職になってしまったらどうすんだ?というのはもちろん考えました。

会社辞めまーす、と宣言した時点では転職活動も特に行なっておらず、何のあても無かった為もしかすると普通にそのまま無職で路頭に迷ってたかもしれません。

が、勝算はないものの打算はありました。

- むしろ今のタイミングで動かないと半年後・1年後はもっと転職が厳しいと思った

- この状況でも案件受注が増えている会社があるはずなのでそこに狙いをつけて転職先を探す

- リモートワークOKの会社が増えている状況なので、かえって通勤のことを考えずに全国どこでも仕事を探せる

- 今のままもやもやしながら仕事し続ける方がしんどい

 

1つ目の考えは自身の新卒時の経験(リーマンショック直後)に基づいたものでした。

当時は正社員の仕事に就けるだけで就活大成功だったので、今回もそんなことになるんじゃないかという想像から、とにかく行動を急がなければならないと思っていました

(あくまで主観的な印象に基づいた予想です。半年・1年後普通に転職市場が賑わってる可能性もある)

今回は幸いにして最低限の経験年数を積んでいたので今なら現職と同条件かそれ以下の待遇の仕事に就くこと自体はそこまで難しくないという自信もありました。自信というか「最悪死にはせんじゃろ」的な。

 

2つ目は端的にいえば「ネット販売に注力している会社」をお客さんに持っていそうな開発会社を探せば良いと思いました。今の状況に合わせた商売のやり方にシフトしている話はいくつか耳にしていたので、まずは受託・自社問わずECサイトを作ってる会社を中心に探しました。それなりの規模のEC構築に関わった経験があったのでその経験を生かせるかもな、という目論見もありました。

 

3つ目はほぼ願望みたいなものですが、転職活動が難航した場合は受けようと思った通勤範囲外の会社がいくつかありました(大阪とか沖縄とか福岡とか)

この件では1つ思わぬ収穫があって、世の中には自分の通勤範囲の会社ではやっていないような面白いシステムを扱う会社がたくさんあることに気付けたことです。今後、フルリモートワークが世の中に浸透して来た場合、このような案件に関われる確率も高まるかもしれないという気付きは心理的にプラスに作用しました(カジュアル面談だけでも受けとけば良かったかも)

 

4つ目、「仕事を辞めて無職になる不安」と「今のままもやもやと仕事を続けること」の両者の精神的負担を天秤にかけたとき、自分自身の運命をコントロールしやすい(自分自身の頑張りで結果が出しやすそう)方である前者の方がまだいいなと思いました。

 

転職活動の感想

- 履歴書・職務経歴書つくるのめんどすぎ

応募書類作りが今回1番しんどかったです。内容もさることながらExcelの印刷時のレイアウト調整が辛すぎた。

 

- 「実務経験あり」の威力

どんなプロジェクトでどんなことをやって来たかを具体的に面接で話すことができたことが今回の勝因だったと思います。

あとは単純にこれまで業務で積み上げて来たことが正当に評価されたことがめちゃ嬉しかった。

 

- チャンスを手繰り寄せる腕力

今の自分にその腕力があったことの証明ができたことが本当に嬉しかったです。観てて良かったSHIROBAKO、杉江さんだいすき。

 

- 仕事しながら転職活動は自分には無理

世間一般によく言われる「会社を辞める前に次の仕事は必ず決めておくべし」というのは全くもってその通りなのですが、自分には通常業務を通常通りにやりながら全く別ベクトルの転職活動も並行して行うというのがとても難しかったです。

日常的に脳のメモリを仕事にがっつり回していたので他のことは何も考えられるような状況ではなかったという理由が挙げられますが、次回転職を行う頃には仕事とプライベートのバランスをもう少し取れるようになっていたいものです。これも以降の課題事項。

とはいえ結果だけ見れば今回は退職日の前に次が決まったので終わり良ければすべて良し、です。

 

無職期間の過ごし方

(正確には有給消化期間だけど)

- よく眠る

- こまめな家事

- 自己分析

- スキルの棚卸し

- Reactの勉強

- Laravelの勉強

 

まずは体調の回復に専念しました。仕事してた時はストレスで睡眠がうまくいかなかったり、胃の調子がいまいちだったりしたのですが、何も考えずじっくり休むことでだいぶ調子が戻って来ました。

当初は酒飲みまくったりゲームしまくったりして思いっきりダラけるかな、とも思ったのですが永久無職の恐怖心があったので自分でも意外なほど真面目に生活してました。

酒もゲームも全然やってない(若干の昼夜逆転はある)

また、1日のほぼ全てを家の中で過ごす生活を3ヶ月程度続ける中で、それまで疲労や面倒くささを理由に放置していたハウスキーピングをこまめに行うことができました。

まとまった時間と自分のやりたい時に家のことができる状況であれば案外家事もだるくならないんだなという気付きも得たり。

 

あとは転職活動としてなにかしら書類を用意しなければならなかったので自分にできることや足りないもの、転職の動機や次の職場に望むことをいろいろ考えてはメモしてました。普段からこういうことを考えているようで、いざ提出用の書類に落とし込もうと思うと案外うまいこと言語化できなかったりして苦労しました。これは今後の課題。

 

Reactを学習対象に選んだのはだいたいこんな感じ

- JSフレームワークの中で唯一全く触ったことがなかったから

- React Nativeが扱えれば制作物のアウトプットが捗りそう

- コンポーネント指向・関数型プログラミング・ES6以降の文法を頭に叩き込みたかった

現在進行形ですが、Reactは本当に学ぶべきポイントがたくさんあって勉強してみて本当に良かったです。次の仕事に即使えるわけではないけどReactや関数型の概念や設計思想は今後の設計実装に大いに役立ちそうです。

(React学習に関する参考書や教材については別記事を書いてみようと思いますが、主に公式リファレンスやtechpit, youtube, 技術書典同人誌などで学習しました)

 

Laravelは次の仕事で使うので要復習なのですがReactが面白すぎて全然捗っていませんね・・。まじめにやらねば。

 

あと、各種タスク管理はTrelloで一元管理しました。「転職」「学習」「生活」みたいな感じでボードを作って頑張ってカードの期限日を守れるように進めたり、そもそもどれくらいの期間があれば期限日を守れるかなど、工数感覚を鈍らせないような努力も多少やりました(リスケも結構やっちゃったけど)

 

まとめ・振り返り

- 自分にしては決断も行動も早かったのは◎

- 有給消化期間(無職期間)が有意義過ぎた、もっと無職を満喫したかったまである

- 転職活動は短期決戦に限る(長引いてたらメンタルに不調きたしてたかも)

 

入社後1ヶ月したらまた進捗報告します。

北海道LT大会に参加したら勉強会開きたくなった話

行ってきました。

t.co

普段ほとんど聞くことのできない学生さんのお話など盛りだくさんの内容でかなりたくさんの刺激を受けることが出来て大変良きでした。

日頃の忙しさにかこつけて今回は発表枠での参加を見送ってしまったのですが、他人の発表をみているとやっぱり楽しそうで発表枠参加すればよかったなというのはちょっと後悔。

個人的に刺さった発表

speakerdeck.com

speakerdeck.com

なにが刺さった?

勉強会を開いて良かったお話では、

  • 情報を発信すると情報が集まってくるようになった
  • 色んなエンジニアさんのお話を聞くことができ刺激になる
  • 改めてドキュメントや書籍を読むきっかけになった
  • 飲み会をする口実になった

また、最強のスキルについてのお話では「想像力」について言及されており、

  • 想像力を持って行動すれば未然に危険や懸念を予測・回避できる
  • 想像力を身につけるには「経験」が必要
  • 経験だけで想像力を身につけるのは効率が悪い
  • 学びの抽象化で経験不足による想像力の足りなさを補う

 例:車道にでると危ない

  ->急に飛び出すと何がおこるかわらない

   ->自分の注意力が欠如している状態は危険である

  • 圧縮された経験をインプットする(本・経験者の話)

若干うろ覚えですがまとめとしてはこんな内容だったかと思います。

もう首が千切れんばかりにどれも同意しまくりだったのですが、特に興味深いのは下記の3つです。

  • 情報を発信すると情報が集まってくるようになった

  • 改めてドキュメントや書籍を読むきっかけになった

  • 圧縮された経験をインプットする(本・経験者の話)

なるほどなるほど・・・ つまりまとめると

勉強会を開くと本を読むきっかけができ有識者のお話を聞く機会ができ、その結果開発に必要なスキルとしての「想像力」が身につく

・・・いまいち意味のわからないまとめですが、 勉強会を開くことで、よりよい設計・実装を実現するための能力獲得のきっかけになるのでは、という感想を得たわけです。良き設計・実装、超出来るようになりたい。

というわけで

今年は勉強会を企画・主催します。

とはいえまだなんの勉強会をやるか?どれくらいのペースでやるか?そもそも参加したい人いるのか?何も分からない状態です。

そんな中で今ぼんやり考えているのは技術書の「輪読会」です。意外と札幌に輪読会のコミュニティありそうで無い気がします(自分が知らないだけかもですが)

ひと月ふた月で1冊の課題図書を決めて、章や内容ごとに1回の輪読会で2人くらい10分くらいの発表枠つくって発表後の質疑応答やディスカションに時間多めにとる、みたいなイメージ。

とにもかくにもまずは参加者を集めないとなーという気持ちです。いろいろ企画考えても参加したい人が来なかったら意味ないしなあ・・・

悩んだ結果行動に移せないのは自分の悪い癖なので、今回はさっそく準備に動いてみたいと思います。まずは簡単にでも企画して誰か勉強会主催している方に相談しよう。

CODE COMPLETE 第11章 変数名の力

ゆるWeb勉強会@札幌 Advent Calendar 2019 21日目の記事です。

 

 

命名とは、最小単位の設計行為である

というのはかの有名な誰それの言葉、でもなんでもなく自分が勝手に思っていることなのですが、プログラミングを初めてから2年弱経ち、その中で命名について思うことが度々あったので、

今回は「コーディングにおける名付け」について書いてみたいと思います。

設計はなんだか難しい・・・でも出来ることからちょっとずつやってみたい、

そんな時は命名についてちょっとしたこだわりを持ってみると手軽にコードを綺麗に出来るかもしれません。

 

 

課題図書について

何か道しるべ的なものが欲しいなと思い、適当に参考文献をいくつか漁っていたのですが、だいたいどの資料でも参照・言及されていたのが表題の『CODE COMPLETE』です。

Code Complete 第2版 上 完全なプログラミングを目指して
 

 

今回はこちらの上巻第3部第11章変数名の力を読んでみてのまとめと感想的な内容になります。

ご存知の方・お持ちの方もいらっしゃるかもしれませんが、CODE COMPLETEはプログラミングにおける設計やコーディングについて体系的にまとめられた内容になっており、結構なボリュームになっています(お値段もボリューミーでした・・)

上巻だけでも全628ページあり下巻と束ねれば完全に鈍器といって差し支えない分量なので、一家に一組あれば結構な暇つぶし、もとい勉強になりそうです(いざという時は鈍器になるので防犯的にもよさそう)

個人的にはLTやブログのネタに困った時に1章分読んでそこからテキストやスライド資料に落とし込むこともできそうだなあと思ったりもしたので、また機会を作って別なテーマでアウトプットしてみるのもいいかなと思いました。

また今回は課題図書の都合上、BEMによるcss命名規則やVue.jsのコンポーネント名のルールなど、言語仕様に関わる命名の話題はなしで行きたいと思います。

前置きおしまい。

 

 

本題

良い命名について考えてみる

コーディングをしていて、変数やクラス・メソッドに名前を付けたことが全くない、という人は多分いないんじゃないかと思います。

さてコードを書くぞとなったとき、プログラマはどのような考えで変数に名前をつけるでしょうか。

  • 変数に入れるデータがなんなのかがわかるように名付ける
  • 名前がかぶったりせずプログラムが正常に動作するように名付ける
  • 後で見返したりレビュアーがわかりやすい単語で名付ける
  • プロジェクトのコーディング規約があればそれにしたがって名付ける

他にも命名の基準はありそうですが、だいたい上記のような考えに基づいて名付けが行われることが多そうです(主観)

 

では良い命名とはなんでしょうか?

また、良い命名をすることの意味とはなんでしょうか?

自分はこの問いに対する明確な答えがわかりませんでした。もし良い命名を積極的に意識して行うことによるメリットがあるのならば、実践してみる価値はありそうです。

第11章の冒頭で具体例を交えてこんな一文がありました。

 

良い変数名は、読みやすく、覚えやすく、適切である

 

なるほど、確かに。なんとなくわかる気がします。

最近は仕事でも不具合報告からの調査作業からの既存ソース確認、みたいなことが度々あるのですがソースを追いかけていて楽に感じることと辛く感じることがあります。大抵辛い時は↑の3つに乗っ取った書き方になっていなかったりしていた気がします(つらい要因は他にもありそうですがそれはまた別の話で)

 

 

良さの基準の話

  • 読みやすく
  • 覚えやすく
  • 適切

とはいえこの3つは言ってしまえばそりゃそうだ、という話です。自分が知りたいのはもっと具体的で、簡単な良い命名の基準なのです。どうすればばっちり迷いなく名付けができるのか?

もう少し読み進めるとこんな記述があります。

 

変数に名前を付けるときに最も重要なことは、変数が表すものを完全かつ正確に説明するような名前を付けることである。

 

おお、とても具体的です。試しにこの基準に則って命名してみましょう(本文からの抜粋)

 

// ①アメリカのオリンピックチームに所属する選手の数

let numberOfPeopleOnTheUsOlympicTeam = 10; 

 

// ②現行の利率

let interestRate = 1.1;

// ③現行の利率(よくない例)

let r = 1.1;

// ④現行の利率(おしいけどよくない例)

let rate = 1.1;

 

①や②は解読しやすく自明な単語が使われています。誰が読んでも同じように何を示しているかわかるでしょう。

とはいえ、①は実用的とはいえないほど長いです。こんな長さの変数がぽんぽんコード上に出てきてしまったら正直うんざりします。

③は短すぎて何を示しているかの情報が全くありません。変数rの正体を掴むには前後関係を追うか、運良くコメントがついていればそれを参照するしかなさそうです。

④は何かの割合・利率であることはわかりますが、もしソースの前後に現行の利率の他に過去の利率や登録人数の割合があったとしたらおしまいです。

 

一つの基準として、本文では変数名の長さが平均して10〜16文字程度だとデバッグが最も手間がかからないとの記述がありました(必ず↑の長さでなければいけないわけではなく、これより短い変数名が目につく時は変数名の変更を検討すべき、くらいの意味とのこと)

また一覧表の中に丁度良い長さの変数名の具体例が記述されていたのですが、だいたいどれも2・3単語で表現できているという共通点がありました。確かにこれくらいなら長すぎず短すぎず丁度良さそうです。

(逆に2・3単語で表現できないものを変数として定義すること自体避けるべきなのかも?)

 

 

短い変数名は有無を言わさず滅ぶべきなのか?

ここまでの基準で言えば、"i"とか"size"とかそういう変数名はよろしくないということになります。ではこのような自明でない変数名は抹殺するべきでしょうか?

実際のところどうなのでしょう。

自分は、for文などで局所的な用途であれば別にいいんじゃないかなとなんとなく考えていたのですが、この辺りについては一つの答えが書かれていました。

 

変数にiといった短い名前を付けると、長さそのものが変数について何かを伝えるーーつまり、その変数が限られた処理スコープを持つ一時的な変数であることを示す。

 

これはちょっとした目から鱗情報でした。普段は、自明な単語を用いて正確な変数名を使っておいて、短い変数名はここでしか使いませんよ、というルールに基づいて運用すれば短さ自体に意味を持たせることができるというわけです。かしこい。

 

 

ループ変数の命名

ループの話が出てきたので、forやwhileでよく使うカウント目的の変数について触れてみます。

大抵のプログラミング言語ではi, j, kがよく使われます。基本的にこれらはお決まりの名前として周知されているということもあり、ループ内だけに限って言えば短さが逆に生きてきそうです。

もしiやjがループの外側でもなんらかの役割を持っているならば、ひと工夫あると良いようです。

 

recordCount = 0;

while ( moreScores() ) {

 score[ recordCount ] = GetNextScore();

 recordCount++;

}

 

if ( recordCount < 100 ) { // なにか処理する }

 

または、ループが結構な長さになってくる場合も同様に良き名前をつけてやると可読性が上がりそうです。

あるいはループが入れ子になっている場合もi, j, kで済ませたりすると辛そうです。

外側のループ・内側のループで明確に区別できる変数名を用意すると良さそうです。

 

↓個人的にこういうのは結構嫌いです(たまにみかける)

foreach ( $userList as $index => $value ) {

 foreach ( $codeList as $index2 => $value2 ) {

  // なんかやる

 }

}

(余談ですが$userListの1件目を$valueで表現しているのもつらいポイント結構高めです。$valueってなんだよ、ってなってしまう)

 

計算値による変数名の修飾

プログラムの処理上、足したり・掛けたり・集計したりとなんらかの計算をしてその結果を変数に入れておくような場面も多いと思いますが、 そのような値を入れておく変数名にはお決まりの修飾語を付けるようにすると良いようです。

たとえば、

  • totalSum
  • pointAverage
  • expenceRecord

のように「[ 何の ] + [ 計算 ] した値」と表現する感じでしょうか。このルールで統一していけばかなりコードが読みやすくなりそうです。

本文では付け加えるように

名前に一貫性があるとコードが読みやすくなり、保守作業が容易になる。

と記載されていました。プレフィックスなのかサフィックスなのかは、最低限コーディングルールとして定めておくのが良さそうです。

ちょっとだけ話は変わりますが例えばキャメルケースとスネークケースが無秩序に混在していると確かにそれだけでテンションが下がってしまいます。

あとで読み直した時にテンションの上がるソースであってほしいものですね。

 

また、計算値の修飾についての例外について一つ記載がありました。

Num修飾子は位置が慣習的に決まっているため、変数名の先頭に付けると合計を意味するのに対し、末尾につけるとインデックスを意味する修飾になるそうです(ぜんぜん知らなかった・出来れば上記の根拠やルールのソースが読みたかったのですが本文でも言及されておらず、ググってもよくわからず)

以上のような背景もあるのでそもそもNumは多用しないのが無難、おとなしくtotalやindexを使えばええやん、的に締め括られていました。確かに。

 

 

おわりに

本書では他にも色々と変数名について有益な情報が載っていましたが、それはまた別の機会に記事に(または本記事の更新を)してきたいと思います。

特に命名規則に関する説明が結構ページ数多めに書かれていたのですが、これはこれで別な形でまとめてみたいです。(いつか自分がプロジェクトの命名規則を作ることがあるかもしれない)

本書が気になった方は、ぜひ書店等でお買い求めいただければと思います。

鈍器版(紙版)はちょっと・・という方はamazonで上下巻合本の電子書籍版も出ているようなので、持ち運びの利便性重視の方や人の頭をかち割る予定のない方はこちらが良いかもしれません。

お値段もほんのわずかですが安いです。

 

最後になりますが、冒頭でも書いたように本記事はtacckさん主催の勉強会「ゆるweb勉強会」のアドベントカレンダー企画に参加させていただいたものになります。

個人的に、今年は仕事外でも自主的に勉強をしてみようという余力がほんの少しでも出来たこともあり、札幌市内の勉強会や道外のカンファレンスにもいくつか参加することができました。

その中でもゆるweb勉強会では何かと勉強の機会をいただいて大変お世話になりました。

tacckさん、いつもありがとうございます。来年もどうぞよろしくお願いいたします。

 

エンジニア視点で見るRISING SUN ROCK FESTIVAL2019

 

rsr.wess.co.jp

 

※ライブレポ的な話題は特にありません

 

ライジングサンに参加するのは5年ぶり。
すっかりバンド活動やライブから離れた生活をしていたものの、今年はNumber Girlの復活公演があるとのことなのでこれは行くしかないとなった次第。

 

 

なんやかんやあったものの

rsr.wess.co.jp

 

kai-you.net

 

 開催決定した17日は天候にも恵まれ結果としては楽しいフェスだった。

 

本題

今回は自分がエンジニアとなってから初のライジングサンでした。

エンジニアリングと夏フェス、関係がないようで関係がある気は前々からしていて

前回記事でも「夏フェスタイムテーブルアプリを作るぞ」などと息巻いていました(仕事に忙殺されて結局形になる前に当日になってしまった)

今回、技術の力で世の中の困りごとを解決する立場になったことで会場で1日過ごしてみて色んなことに気がつきました。

(あんまり関係ないけど久々に石狩に来たら風力発電用のどでかい風車がいくつも設置されてて暇なときはぼけーっと眺めたりした)


石狩湾新港RSR会場予定地に建つ風力発電風車

 

技術的な気になりごと

・ドローン空撮?みたいなことをしてた気がする

→単純に動画撮影目的で飛んでた模様。もしかしたら積んでるカメラで撮影した画像を解析してエリアの人口密度とか分析してないかなとか思ったけどよくわからない

・物販でクレジット払い用のスペース発見

→おっ、クレカ決済の物販ある?でも普通の物販はみんな現金払い?なんであの一角だけ・・?と思ったらどうやら事前販売してクレジット決済済みの商品を引き換え番号で受け取る窓口だったっぽい

・ネット配信番組やってたっぽい、ボヘミアンにモニターがあった

rsr.wess.co.jp

会場限定の配信だったのか、なるほど

 

会場内での困りごと・気付きなど

シャトルバスがチケットor現金払いのみ

→基本チケット制で現金でもOKですよーくらいの温度感だと思うので今なおSAPICA対応してないのかなと思うなど。対応してくれたら列整理のスタッフの仕事も減りそうなのにな

・屋台のラインナップ、場所がわかりにくい

→と思ったけど会場マップ上に自分のスマホの位置情報を同期させるサービスがあった

rsr.wess.co.jp

行きたいお店の場所も一発でわかるしすごい

↓こちらの企業さんが提供しているサービスのよう

weare.stroly.com

 

・ステージやエリア・トイレの混み具合が読めない

→このバンドの出番前だとここは混みそう、この時間帯はご飯エリアは人多そう、などある程度の予測はつくが、この辺りをスマートに情報を出して人の流れを少しでも整理する方法ってないのだろうか。

特に昼間のトイレはどこも混雑・行列が常態化していて女子トイレはかなりの行列待ちをしていた。

・トイレに入れたものの紙がない問題

→想像するだけで絶望的な状況だが、この辺りはスタッフ・参加者の行動によってコントロールされているようだった。

・定期的にスタッフが紙の補充をする

・紙がなければスタッフに声かけをする

・紙がない時のために流せるティッシュを常備して難を逃れる

せめて仮設トイレのドアに営業中/準備中的な「紙あり/なし」の札でもつけてくれたらスタッフも参加者も分かりやすくていいのにと思うなど

 

・ありとあらゆる会場内の支払いが全て現金のみ

http://nekotp.com/wp-content/uploads/2016/05/bendhead016cat.jpg

な ぜ な の か

単に自分の行ったお店で導入してなかっただけで一部ではやってた可能性はあるけど

自分はXPayとか使わないしせいぜいクレカ払いくらいの人間だけど、これだけ世の中キャッシュレスの動きが広がってるのに会場内どこに行っても現金払いだけだったことに若干驚き。

これはもはやライジングサンだけの問題ではなさそう。

大きく分けると立地的な問題とコスト的な問題に二分されると思うので他のフェスの状況はわからないけどなんとかした方がいいのでは。

会場内で小銭じゃらじゃらするの結構嫌だし。

 

軽く調べたらこんな記事も↓

realsound.jp

この情報が事実ならフジロックでは会場内で電子マネーが使えるみたいだ。

健康ランドのリストバンド的な感じで、全部かざすだけで決済できて、

アプリで残高確認とか決済履歴確認とか出来ないかな。コスト的に辛いか・・・

 

・帰りのシャトルバスの行列待ち状況がわからない

以下状況

  1. 帰り5:30ごろ荷物をまとめて乗り場に向かう
  2. めっちゃ人いる、どれくらいでバスに乗れるか前が見えず全くわからないがとりあえず並ぶ
  3. 前に進むにつれてだんだん状況が見えてくる、多分前に400人くらいいる
  4. 30分くらい並んで前進する中で気づく、タクシー使えば+1500円程度で今すぐしかも確実に座れてその上家の目の前に下ろしてくれる。しかし今から列を離脱する気も起きない(眠くて思考力が低下中)
  5. 結局バスに乗れたのは7:00、しかも運悪く立ち乗りに

この時間帯がこんなに混むことを知らなかったのも悪いが、せめて列の待ち状況だけでも看板でアナウンスすることはできなかっただろうか・・・

以下運用的な状況

  • バス自体は随時出発できる状態にあった(ピストン輸送でほぼ途切れず乗車待ちバスが待機していた)
  • 待機している数百人を随時乗せて出発する運用なのに乗車口が一つだけ
  • 一度に乗れる人数はせいぜい30人くらい
  • 列の形状の都合上、途中でタクシーに切り替えるなどで離脱することが難しい
  • 仮に離脱したとしてもタクシー乗り場の状況がわからないため無駄足になる可能性もありやはり列を抜ける決断はしづらい

スタッフの配置やコストの問題はあるかもしれない。できる限りさっさと客を帰したいという思惑もあったのかもしれない。事情は色々だろうと思うので文句を言う気はない。

ただ、一つだけ確実なのは

帰りのシャトルバス行列はとにかく辛かった

 

 とはいえやっぱり楽しかった

学生時代のように分単位のステージ移動のために会場を駆けずり回ってわずかな合間時間にちょっとしたご飯を食べる、みたいな遊び方はしなくなり

代わりに今は本当にみたいやつをいくつかだけ決めてあとは目的を定めずにぷらぷら歩く、またはテントでのんびりするようになった。

 歳をとったのか、大人になったのか

 会場内を今の自分目線で見聞きしてみて、案外ユーザの問題解決やフェス参加の付加価値を上げるようなサービスについて色んなことを考えることができた。たまには仕事と関係のない遊びでもして制作物のネタ収集するのも良いものだなと思った。

 

ちなみに

今回の個人的ベストアクトは青葉市子でした。機械仕掛乃宇宙聴けて本当に良かった。


青葉市子 - 機械仕掛乃宇宙(20131125) Shibuya WWW