2021年の目標
2021年の目標を、2019～2020年を振り返りつつ書きます
2019年
当時は前職に所属していて客先で毎日Excelの設計書を作成していました。
スケジュールが厳しく、日々プレッシャーをかけられストレスの多い日々でした。
プライベートでは土日や空いた時間で勉強会に行ったりRailチュートリアルに取り組みスキルの習得に努めていましたが、
目的のある学習というよりは現状の不安とプレッシャーから逃れるための勉強になっていて中途半端になりがちでした。
2020年～
3月に転職し、また4月からは在宅勤務となり働く環境が大きく変わりました。
客先の業務が複雑なため、業務仕様を把握するまでは苦労しました。
半年目に入った8月頃にはようやく慣れてきて時間の余裕ができてきました。
業務では異なるDB間でデータを転送するシステムを担当していまして、
AWSやGCPといったクラウドのシステムが関連しています。
そのことからクラウドの仕組みに興味を持ちまして11月からAWSの勉強を始めました。
12月頭でAWS認定クラウドプラクティショナーに合格できました。
いまはソリューションアーキテクトアソシエイトの学習を進めています。
それ以前の2020年夏頃はなんとなくNode.jsの勉強をしていたりしましたが、
スキル習得のためというよりは、時間が余ったので何かやらなければとプレッシャーに駆られ、埋め合わせでやったような形になっていました。
これではせっかく勉強しても身に付きません。
このことに気づいたのは10月になって『心理的安全性のつくりかた』を読んでからです。
この本を読んで、不安やプレッシャー、怒りや否定的な態度は人を委縮させるか極端な行動へ駆り立てて、
肯定や感謝で応えるよりも生産性を低下させチームの結束や人間関係を悪化させることが理解できました。
わたし自身を振り返ってもこのことをもっと早く理解できていれば避けられた失敗がありました。
そして、2019年のころ人にプレッシャーを掛けられ不安に襲われながら働き嫌な思いをしていたのに、
わたし自身も不安やプレッシャーで人や自分を動かそうとする発想から脱却できていないことに気づきました。
そうならないように今は今時点で興味をもっているAWSの勉強を「自分自身のやりたいこと」としてやっていこうと考えています。
どんな人もその人の「やりたいこと」を追求するがその人の幸せに繋がりやすいからです。
また、やりたいことをやりたいからやるだけでは不十分で、目指す高い目標がなければなりません。
その目標はまずは「社内業務をAWSで便利にする」ことを掲げていきたいです。
まずは社内のファイルサーバーとしてAWSを活用できないかと検討しています。見積もると意外と費用が掛かってしまうようで苦慮していますが…。
他にもSlackと連携してみたいとか、いろいろなアイデアが思い浮かびますので試してみたいです。
先ずは2021年の目標は以上です。
pub.jmam.co.jp
転職していました
ご報告
3月に転職していました。
今まで
常に気を張っていました。
毎日、朝の出勤から夜の退社まで自分の身を守ることに集中しずっと緊張していました。
緊張に耐える日々が続いているうちにだんだんと心身をすり減らしていました。
- 妻にきつく当たってしまうことが増えてしまいました
- 携帯に時々かかってくるガス会社などからの電話に苛立った対応をしていました
- 間食が癖になり毎日スナック菓子を食べるようになりました。体重が増えました
- 疲れから自己学習する気分になれず、スキルアップが疎かになりました
- ストレスを感じても我慢して行動することが当たり前になり、十分な休息を取りませんでした
現在
働き方は大きく変わっていませんが、気持ちの面でとても楽になっています。
影響
転職してしばらくは前職の感覚を引きずってしまい緊張をしたり余計に頑張ってしまう悪い癖が抜けなかったのですが、
最近は癖が抜けて自然体で行動できるようになった気がしています。また仕事以外でも良い影響がありました。
- 妻との関係がよくなりました
- 人に対して落ち着いた対応ができるようになりました
- ダイエットを始めることができました（まだ成果は出ていませんが…）
- 暇な時間ができたらQiitaを見たり、VSCodeを立ち上げて何かやってみるようになりました
- ストレスが溜まったら無理せずに休息を取るようになりました
カイゼン・ジャーニーを読みました
もくもく会の懇親会で「カイゼン・ジャーニー」を勧められ、今年10月の終わりころに購入していました。
二か月たって年末になりやっと読めましたので、感想を書きます。
「ソフトウェア開発の現場」をより良い方向へ変えていくための方法を届けるための本だと「はじめに」で書かれています。
「より良い方向」とは誰の何のための「より良い」なのでしょうか？
私はソフトウェア開発の現場にいる人々とその利害関係者が、尊厳を脅かされることなく健やかな日々の生活を送ることだと解釈しました。
主人公の江島は勉強会で開発現場を変えた話を紹介する石神の話に惹かれます。
その後、江島の会社では新人がフォローを受けられないまま遅くまで残され退職に追い込まれる事件が起きます。
退職に追い込まれた新人を見て、そんな不幸な開発現場を変える事例を聞いていた江島は現場を変えるための使命感を持ったのだと思います。
その江島の使命感の根底にあるのは人を助けたいという利他的な動機です。
そんなエピソードを踏まえてから第一部では一人、第二部ではチーム、第三部ではクライアントやユーザーも交え、
「ふりかえり」などのプラクティスを紹介しながら改善を進めていきます。
プラクティスの紹介では必ずその手前で江島らが失敗をします。
まずは失敗を見せプラクティスによって改善するストーリーにすることで理解しやすくなっています。
失敗の中には個人の責任だとして切り捨てられてもおかしくないようなものもあります（メンバーが出勤しないなど）。
そのような場面でもチームの問題としてスクラムの手法で全員での解決を目指す姿勢は、
この本から学ぶべきものとして大きいものなのではないかと感じました。
この本で紹介されているスクラム・カンバンのプラクティスは数が多くそれぞれを細かく読み取れてはいませんが、
今後、私が開発現場で困難に遭遇した際には安易に人のせいにせず、
現場の意思疎通といった範囲の広い視野でものごとを考えられるようになりたいです。
アセットパイプラインを調べました
アセットパイプライン
アセットパイプラインとは
CoffeeScript、Sass、SCSSなどを管理する仕組み。
sprocketsというgemを利用しているそうです。
sprocketsとは
カタカナで書くとスプロケット。
チェーンから軸に回転を伝える仕組みのことです。自転車のチェーンが身近な例ですかね。
sprocketsについて調べようとすると「sprocketsを捨てる/移行する」といった記事が多く見つかります。
フロントエンドのツールが充実してきたのを背景に、2015年頃からsprocketsからの移行が試行錯誤されていたようです。
その後、rails6からはsprocketsが標準ではなくなりwebpackを基にしたwebpackerが標準になったそうです
こうした変化の背景には、
・React.js, Vue.jsなどのフロントエンドフレームワークができたこと
・RESTful APIを使いサーバーサイドとフロントエンドを疎結合にする傾向があること
これらが影響しているのではと推測しています。
sprocketsの詳細
sprocketsそのものについては、webpackerへの移行について書かれていた次の記事が参考になりました。
Ruby on Rails で sprockets から Webpacker へ移行し、移行できないものは共存させる方法 - Qiita
チュートリアルではサンプルを真似て stylesheet_link_tag, javascript_include_tag ヘルパーを書いていましたが、
これらがsprocketsと連携するための記述だったんですね。
感想
以前、Laravelをやってみようとしてこちら（ Laravel + Vue.js で出席管理Webアプリを作成する – Part.1 | luftgarden ）を参考にLaravelが動作する環境を作りwebpackにも触れたのですが、当時は何をするためのソフトウェアなのかよく分かっていませんでした。
今回sprocketsからwebpackerに置き換わる過程を追いかけたことで、開発現場でどんな課題があり環境が変化していったのかが垣間見えたような気がします。
アセットパイプラインと呼ぶ仕組みそのものについては、cssとjsを一元化した管理をする仕組みは一定以上
の規模の開発で必要になるものだと思います。
cssの管理が雑で特定のdivに効いているcssが分からなくなりわざわざブラウザの開発者モードで確認するような事態がときどきありますので。
sprockerに限らずアセット管理とバンドラーに対して関心を持っていこうと思いました。
もくもく会に参加しました
感想
README.mdには具体的な作業内容を書く
Ruby on Rails チュートリアル：実例を使って Rails を学ぼう より
最初のアプリケーションのときと同様に、まずはアプリケーションのルートディレクトリにあるREADME.mdファイルを更新して、具体的な作業内容をわかりやすく記入しておくことをおすすめします
GitHubの個人アカウントに置いているリポジトリでは、REAMDE.mdをきちんと書いていませんでした。
後ほど整備したいです。
railsのテスト
test "should get home" do get static_pages_home_url assert_response :success end
railsではこのような短い記述でレスポンスのテストができるのですね。
テストをしたいロジックを書くことに集中できそうな気がします。
ERB
provide と yield でレイアウト間のデータの受け渡しを記述しました。
同じ記述をせずに済むのは利点ですが、多用すると混乱しそうですね。
テストを書くのが重要そうだと感じました。
技書博に行きました
だいぶ日にちが経ってしまいましたが、7/27技書博に行きましたので記事を書きます。
gishohaku.dev
技術書の同人誌の催しに参加したのは初めてでした。
他には、技術書典が知られているそうです。
さて、技書博ですが、公式ガイドブックによると66サークルが参加していたそうです。
サークルの下調べはあまり出来ていませんでしたが、会場を回って気になった本を購入しました。
いくつか感想を書きたいと思います。
購入した本
Onestop勉強会（親方Project）
勉強会への参加や、さまざまな勉強会の開催について、
それぞれの執筆者の体験から、利用したサービスなど具体的な行動や、教訓が書かれています。
勉強会に取り組むきっかけになりそうな本でした。
私はこの本を読んで、このお盆休みに名刺の作成と自己紹介のWebサイトを作成に取り掛かっています。
OneStop転職（錬金術MeetUp）
すべて読めていませんが、ITエンジニアという職を選んだ人が、
労働者としての人生をどう送るかとの視点から転職という手段を説明しているようでした。
転職だけではなく、普段の業務上の立ち回りとしても参考になりそうです。
現場の「ズレ」を解消するコミュニケーションメソッド 第2版（全日本キャリア教育改善推進協会 尾澤 愛実）
すべて読めていませんが、行動分析学、教育心理学を取り入れています。
参考文献が記載されているので、学習を広げるきっかけができそうです。
杉山尚子「行動分析学入門」は以前に読んでいました。
勉強しようと思っても遊んでしまう理由を突き止めようと読んでいたのですが、
技書博でこの本の名前を見るとは思いませんでした。
その他
他にも購入し、まだ読めてない本がありますが、一旦ここまでにします。
もくもく会
ITエンジニアとして勉強したことなどを記録するためにブログを開設しました。
早速ですが、今日はこちらに参加しています。
https://weeyble-creative.connpass.com/event/139474/
やっていること：
「基礎＆応用力をしっかり育成！Androidアプリ開発の教科書 Kotlin対応 なんちゃって開発者にならないための実践ハンズオン」
https://www.shoeisha.co.jp/book/detail/9784798160443
を読んで、サンプルコードを打ち込む。
※ いまもくもく会の最中なのですが、終わったあとだと書き忘れそうなのでまずは記事を作成しました。
※ 7/28追記
勉強会が終わったあとにWeeybleの人と話す機会がありました。
SIerで仕事をしている人はGitやCircleCIなどのチーム開発の経験が不足している場合が多いとのことでした。
確かに、SIerで長年働いている私にも当てはまります。
今は学習していて達成感を得やすいのもあり、kotlinの学習をしようと考えていましたが、Gitなどの基礎的な勉強を詰めるべきなのかと考えています。
