2024年の振り返り

こんにちは。akitoshigaです。

2024年ももう大晦日なので今年一年を振り返ってみたいと思います。

東京から大阪に引っ越した

人生のほぼ大半を東京で過ごしてきましたが、今年の1月1日から大阪に引っ越しました。

大阪に来た理由の一つに以前ブログで紹介した京都で過ごした日々が関係していて、どんな経験も人生にどう影響するかわからないなと感慨深く思っています。

大阪は暮らしやすく人も温かくて引っ越してきて非常に良かったです。

色々なミートアップに行った

今年はRuby関係を中心に色々なミートアップに行きました。

一番行ったのがKyoto.rbでその次がKOBE.rbだと思います。

Kyoto.rbへの参加がきっかけで自分の世界がものすごく広がったので本当に感謝しています。京都には足を向けて寝られません。

特にluccafortさんとonkさんには本当に感謝しています。

KOBE.rbは主催のなかにしさんに越してくる前から仕事でお世話になっていて、直接お会いできたのが本当に嬉しかったです。

英語の勉強をやり始めた

Kyoto.rbでルーカスさんと出会ったことがキッカケで英語の勉強をやり始めました。

元々英語は大学を卒業したらやるつもりだったのですが、彼と出会ったことがきっかけで今年から英語の勉強をやることにしました。

ちなみにルーカスさんは大阪にきて初めてできた友達です。

彼はブラジル在住なのですが来年のRuby Kaigiの季節にはまた来日してくれると思うので、彼に会えるのが今から楽しみです。

登壇デビューした

Kansai Dev Garageさんのある勉強会で初めて登壇しました。

speakerdeck.com

これをブログ形式にして投稿したものは、はてなブックマークのトレンドに乗ったりして嬉しかったです。

この記事は9000人弱のたくさんの方に見てもらえた反面手厳しいフィードバックも頂いたりしました。

公開した当初はこんなに沢山の人の目に触れるものと考えておらず、何かを世に公開するときはもっと責任感を持たなければいけないなと反省しました。

ただ、トータルではものすごく自分にとってプラスになったと考えていて、自分のアウトプットを誰かが役立ててくれるということに喜びを感じるきっかけとなりました。

qiita.com

めちゃめちゃ本を買った&読んだ

今年は技術書だけで94冊買ってました😇

会社の制度とかを利用したとかではなく全て自腹で買いました💸

大学の教科書だったり、自己啓発とかビジネス書的なものはカウントしていないので、おそらく本全体では120~130冊くらいは買ったと思います。

買っただけでなく読書もものすごいしました。

こちらは数えてないのですが技術書だけで少なくとも60冊は読んだと思います。

モデリングや設計、アーキテクチャに関するものがほとんどです。

特に印象に残っているのが『パターン指向リファクタリング入門』で、デザインパターンをリファクタリングという実践的なテーマでどう応用するかについて書かれています。

他には『セキュア・バイ・デザイン』とか『単体テストの考え方/使い方』とか『進化的アーキテクチャ』などなど良い本を本当にたくさん読んだなと思います。

あとは長らく積んでいたOOP界隈で鈍器として有名？なメイヤー博士の『オブジェクト指向入門第2版原則・コンセプト』も読みました。

『方法論・実践』の方も持っているのでこちらは来年読みたいなあと思います。

会社でやったこと

今は自身のプロジェクトと並行して自社のエンジニアの技術力の底上げをする活動をしていて、以下の取り組みをしました。

勉強会を主催した

今年は2つの勉強会を自身が主催となって行いました。

テスト駆動開発についてのワークショップ

ケントベック好きが高じてテスト駆動開発のワークショップを行いました

speakerdeck.com

『Railsの練習帳』の輪読会

こちらはまだ途中なのですがigaigaさんの『Railsの練習帳』の輪読会を週一で行っています。

スポンサー活動

『Kaigi on Rails 2024』カンファレンスのスポンサーを企画して実行しました。

どこかのカンファレンスにスポンサーを自社としては初めてのことで、当日は有志で現地参加もしました。

その他プライベートなこと

いいライブをたくさん見た

今年は自分が好きなアーティストのライブがあってめちゃくちゃ嬉しかったです。

特にLalah HathawayとIncognitoをこの目で見ることができたのが本当に感無量でした。

タバコをやめた

去年の健康診断の結果が悪かったことがきっかけで20歳の時から吸っていたタバコをやめました。

ちなみに禁煙治療をする直前の肺年齢は95歳だったそうです。

めちゃめちゃ太った

大阪のご飯が美味しすぎてめちゃめちゃ太りました。

本気で危機を感じているので来年はしばらく懇親会の参加は控えようと思います。

めちゃめちゃ病院に行った

先ほどの禁煙治療も含めて3つの病院に通ってました。

あとの二つはヘルニアと腹痛で、腹痛の方は最近何も異常がないことが確認できたのですが、ヘルニアの方は今もリハビリに通っています😇

初めて一人で海外旅行に行った

今年初一人でタイに行きました。

一人で海外旅行をしたのは初めてでかなり刺激的で面白かったので来年もどこか行きたいなあと思います。

キーボードをめちゃめちゃ買った

今年はキーボードを4台買いました。

色々迷走した挙句、今はHHKB Studioで落ち着いています。

キーボードはこれまでにかなりお金を使っているので早く楽になりたいです。

総括

コミュニティへ参加したことがきっかけとなり、今年は自分の世界がものすごく広がった一年でした！

自分と関わってくださった人全員にお礼を言いたいです。

来年は今以上に技術を通して交流していきたいなと思います！

アウトプットの機会ももっと増やしていきます！

では良いお年を！

 

 

エンジニアになって5年経ったのでこれまでの生き様を振り返る。

日記

こんにちは！akitoshigaです。

2019年の12月からエンジニアを始めて今月で5年が経ったのでこれまでの事を振り返ってみたいと思います。

2019年 エンジニアデビュー　五反田ソフトハウス編

自分はエンジニアとしての最初のキャリアを五反田のあるソフトハウスでスタートしました。

ちなみにその時の自分のプログラミング力はプロゲートのJavaをちょっとやったくらいです。

資格はITパスポートを持っていました。

当時未経験だった自分はもちろん会社を選べる立場ではなく、手当たり次第に選考を受けて運よく拾ってもらったのがこの会社でした。

その会社はパッケージ開発とSESを行っている会社で当時の社員数は10名ほどでした。

その会社の社長はコミュニケーション能力の高いエンジニアが欲しいと考えており、人柄採用で未経験から育て上げようという考えで自分を入社させてくれたのでした。

ちょうど人材を大幅に増やそうと計画していたようで、同じような未経験の同期が4名いました。しかし一年ほど後にはこの全員が退社することになります😇

ちなみに、自分は転職の準備としてスクールなどには行きませんでした。

理由は、この業界は経験年数を重視する傾向にあるのでスクールに通って半年から一年を費やすよりも早く業界で経験を積んだ方が将来に生きるだろうと考えたためです。

この判断については後に死ぬほど後悔することになります。

研修

入社してからは3ヶ月の研修があり社長から直々にJavaとSQLを学びました。

研修の目標がOracleの資格であるJava Silverの取得だったのですが、自分はJava Silverに加えてJava Goldの資格も取得しました。

Java Goldは実務経験が3年以上あるプログラマー向けの資格と聞いて、かなり誇らしかった思い出があります。

そんな中、研修が終わってSESの現場を決める面談が始まるのですが、ここで洗礼を受けます。

面談で多重下請け構造の現実を知る

面談のアポイントが決まり、待ち合わせ場所まで自社の営業さんと向かいました。

自社の営業さんと担当者らしき人が落ち合い何やらヒソヒソと話しています。

　『営業さんとこの人の会社のオフィスで面談なのかな〜』と考えていたところ、営業さんが「じゃあ頑張って！」という言葉と共に自分達を残して去っていきました。

状況がよく飲み込めない中その担当者さんと世間話などをしているとまた別の方がやってきます。その別の方と担当者さんがヒソヒソ話をした後担当者さんがも同じように去っていきます。

こんなやり取りが後もう一回あり、最後に来た担当者さんに連れられて喫茶店で面談をすることになります。

喫茶店で面談をするというのも自分にとっては衝撃でした。

聞いた業務内容が開発とは程遠かったのでなんと自分は初めての面談をその場で辞退してしまいました。

二つ目に面談を受けた時は、たらい回しにされることはなくオフィスの会議室での面談だったのですが、案件の内容がデプロイを専門で行うポジションでした。

手順書を見ながらにダブルチェックで手動運用をするという中々しんどい業務でした😇

その面談で印象に残っているのは一緒に面談を受けた他社の人です。

その人は開発経験が一年弱あるのにも関わらず、同じ業務の面談を受けていてなかなか厳しい業界だと思いました。

「開発」ってすごいハードルが高いんだなと現実を目の当たりにしました。

そういったこともあり、その時の自分は最初は開発とはかけ離れた現場に行くことに腹を括っていたのですが、最終的にその面談では誰も受け入れられませんでした。

コロナでSES案件がなくなる

当時コロナが流行り始め、その影響がSES業界にもで初めて、SESのエンジニアの受け入れが出来なくなる現場が続出しました。

その当時はリモートワークではなく出社が前提の働き方だったようで、SESの案件が完全になくなってしまいます。

社長から『給料払えないかも...』と言われました。

受託のパッケージソフトの開発をやる。Vimとの出会い

人材を遊ばせていてもしょうがないので、結局自分は自社が受託で開発しているパッケージソフトの案件をやることになりました。

といってもやっていることは開発というよりテスターに近くて、WinMergeで延々と修正後と修正前のファイルを見比べ修正箇所があればマージをするみたいな仕事でした。記憶が曖昧なのですが.NETフレームワークのUIの修正も行なっていた気がします。

案件の中でDBをOracleからPostgresに変更していたのですが、DBを使用している処理が抽象化されておらず全箇所OracleのドライバのAPI呼び出しをハードコーディングしていて他のエンジニアが一括置換で変更しているような今思えばしんどい現場でした。

ここから察しのつく方もいらっしゃるかもしれませんが、プロジェクトは炎上してました。

PMは自社の業界2年目の社員で、寝袋を持ち込んで週に何日かは会社に泊まっているような状況でした。その人はもちろん土日も出勤してました。

ここでめちゃくちゃ人生に影響を与えたのが、Vimと出会ったことです。

自社に出向していたSESのパートナーさんと仲良くなり、彼が自分にVimを布教してくれました。

彼の素早い操作でどんどんソースコードが編集されていく様がまるで魔法のように衝撃的だった事を覚えています。彼の洗練された:w + Enter捌きを今でも鮮明に覚えています。

彼の影響でVimの練習をし始めました。

Vimを使っているのといないのでは体感で50倍くらい生産性が違うので彼には感謝してもしきれません。この業界に入って最も感謝してる人の一人です。

退職

そんな感じでしばらく業務を行なっていました。

詳細は伏せますがその中で色々とこの会社のおかしい点を目の当たりにしていきます。

会社のキャッシュがショートしそうということがきっかけとなり結局半年ほどでその会社を退職してしまいます。

冒頭でも少し述べたように自分の退職を皮切りにその後同期が少しづつ退職して翌年には一人もいなくなってしまいました。

2020年  新橋SIer編

次に入ったのが新橋にあるSIerで、受託開発とSES（チーム単位）、あとは小規模な自社プロダクトの開発を行なっている会社でした。

その会社に入った理由は、その会社の社長とCTOのインタビュー記事をネットで見つけ会社の成り立ちに深く感銘を受けたのと、熱い企業理念に共感したからです。（熱い人が好き）

その会社は求人を出していなかったのですが、どうしても入りたくてダメ元で聞いてみたところ面接の場を用意してもらいました。そして、その場で社長と意気投合して拾ってもらいました。

入社初日に京都行きを宣告される

そして入社初日オリエンテーションがあったのですがそこで開発部長に「志賀くん、京都の現場行かない？」と、自社が抱えている京都のSES案件を打診されました。

入社前に地方の現場に行く可能性があることは伝えられていたのですが、入社初日に告げられるとは思いませんでした。

当時自分は実家を出て都内に引っ越したばっかりだったので、それなら最初に言って欲しかったなと思います😇

とはいえ、社内で技術力のあるリーダーがその京都の現場に常駐していてその人の近くで学べると後押しされた自分はその京都行きを承諾しました。

この選択が後の自分の選択に大きな影響をもたらすことになります。

京都出向

京都行きを告げられてから1週間後自分は京都に向かいました。

その日は真夏で最寄駅から現場までの道のりがもの凄く暑かった事を覚えています。

その現場はある製品を自社の工場で生産して自社のECで販売していました。

システムはECサイト、生産管理、業務アプリケーションに加えてハードウェアも取り扱うかなり大規模なものでした。

チームはリーダーを含め常駐しているメンバーと、首都圏からフルリモートで働いているメンバー半々くらいから構成されていました。

その現場に入ってすぐある機能の開発を任されたのですが、チームリーダから絶賛してもらえたのが物凄く嬉しかった記憶があります。

とても希望を持って臨んだ現場ですがその気分はすぐにぶち壊されることになりました。

PMの蒸発、闇堕ち

自分が出向してから程なくしてその現場のPMが蒸発しました。

その現場がかなりブラックな環境で、PMは元々体調が悪かったのですがある日無断欠勤してそのまま現場を退場することになってしまいます。

そのPMが抜けた穴を、東京にいるCTOの週3での京都出張と自分がPMOをやって埋めることになりました😇

自分がPMOに選ばれた理由は京都に常駐していてかつ一番適性がありそうだったからだそうです。

開発をやりたくて京都に来たのにこの選択が仇となってしまいこの時期は本当に未来に希望が見えなくてしんどかったです。

一番辛かった思い出が、自分がPMOの業務で忙殺されている中で隣でリーダーがフルリモートの社員に開発案件を通じて仕事を教えている場面に遭遇したことで、

自分はなんのために京都に来たのかと、その日の帰り道田んぼのど真ん中で咽び泣きました。ちなみにその社員はあるスクールの卒業生でした。

この件をきっかけに完全に闇落ちし、そこから自分は毎日夜中まで勉強して会社に行く生活を送るようになりました。

元々勉強はものすごくしていたのですが、生活のほぼ全てを仕事と勉強に捧げることになりました。

この当時の自分ははらわたが煮え繰り返るような怒りとコンプレックスのみをエネルギーとして生きていた暗黒の時代を生きていました。

開発がやりたすぎて色々やる

とにかく開発ができないかと、PMO業務の傍ら色々な手を尽くすようになりました。

ことあるごとに「それ志賀にやらせてください」とリーダーにお願いしたり、CTOに自分の勉強内容をアピールしたり、会社の推奨する資格を取ってみたり、会社のOSSにコントリビュートと考えられることはなんでもやったと思います。

最終的にはPMOの業務に加えて小規模な案件のリーダーをやったり、業務アプリやECの案件をやったりするようになっていました。

PMOの業務ではクラウド基盤の移行のベンダーコントロールをやって成功させたり、当時PMが蒸発して最悪だった受け入れ先との関係を修復したりしていました。

現場撤退、帰京

先述の通りこの現場はものすごいブラックな会社で、PMが蒸発する以前にも自社の社員はこの現場でかなり退職者を出していました。

PMが蒸発したことがきっかけでもうこれ以上被害を出したくないと考えた自社は、PMが蒸発してから一年後この現場からの撤退を決定してこれにより自分は東京に戻ることになりました。

東京に戻る頃には自分は京都が好きになっていました。

現場の喫煙所から屋外にあり、そこから見える山々が美しかった事を覚えています。

開発ができない日々が続き退職

東京に戻ってからもなかなか案件に恵まれず、開発ではない案件にアサインされることになりました。

その当時はなんとかコードを書こうと色々な手を尽くしテストをPythonで自動化してみたり調査をしてみたりしてました。

しかし、開発ができるかどうかはどれだけ自分が努力してもコントロールできないのだと悟り退職することを決めました。

会社としてはとても好きだったのですが、自分よりキャリアの浅い人が苦もなく開発現場にアサインされている中なぜか自分は開発の案件に恵まれずこの会社では苦い思い出となりました。

2022年  医療系HR企業編

転職活動を経て今の会社に辿り着きました。

この会社を選んだ理由としては、有名なメガベンチャーグループの会社で技術力が高そうだったのと、医療業界はITの整備が進んでおらず社会にインパクトを与えられる機会がたくさんあると当時の採用担当者に伺ったからです。

また、自分の身近に医療に携わる人間が多く縁を感じたのも理由の一つです。

この会社でようやくちゃんとした開発業務に携われることになりました。

入社してすぐ一人で新規事業の立ち上げを任され、未経験の技術でありながらもなんとか自力でリリースまで行うことができました。

入社した当社は任される仕事の大きさに正直かなり苦労して徹夜で仕事をする日もありました。

その上、自分が入社した半年後に同じチームの先輩が抜けて自身がメインの開発者となったので最初の方は色んな意味で刺激的でした。

ですが、こういった経験や自身が今までやってきた勉強が生きて現在ではテックリードの仕事や新人教育を任されたり、勉強会を主催して会社のエンジニアの技術力を向上させる施策を行うようになりました。

この5年を振り返って

やってよかったこと

中々希望の現場にアサインされないからといって腐らず少しでも自分の希望につながるアクションを取り続けたから今があると思っています。

勉強的な所では、キャリアの初めの方で『独習Git』を読んだのですが、あれでGitへの恐怖感が消えたのは結構よかったなと思っています。

あとVimはマジでやっててよかったなと思います。

やらなくてもよかったこと

自分の場合は性格上しょうがないのですが、インプットに偏りすぎてたなとすごく思います。

インプットによって受けた恩恵も数多くあるのですが、知識を先取りしすぎてせっかく書籍などを読んでも無駄な時間となっていたことも多かったかなと思います。

自分の咀嚼できるキャパシティには限界があるので。。。

今後やりたいこと

先述の通り、気になることが多すぎてこの5年はインプットばっかりしてました。

最近気づいたのですが、どれだけ学んでも学ぶことは尽きないのである程度折り合いをつけてアウトプットの比重を増やしていきたいと思います。

OSSへのコントリビュートや登壇などをたくさんやっていきたいなと思いました！

また、自分のキャリアの道が定まってきたのでそこに向けた活動も行っていきたいと思います。

英語の勉強も継続してやっていこうと思います。

これからエンジニアに挑戦しようと思っている方へ

個人的な経験に基けば、スクールに行った方が良いと思います。

この仕事に就けるか・うまくやれるかは結局本人の努力以上の変数はないのですが、長い目で見ればスクールに行った方が自分みたいに無駄な努力はしなくて済むのかなと思いました。

特定の言語の勉強ももちろん大事なのですが、普遍的な設計、コンピューターサイエンスの基礎は覚えておいて損はないと思います。

基礎的な部分の解像度が高いと、ある所で得た知識を他の領域で応用する力がつくと個人的には思っています。

また、プログラミングの勉強以前にそもそもの『問題の解決』について勉強してみると今後に生きるかなと思いました！

あとはコミュニティのミートアップに参加すると世界が広がります！初心者だからといって臆する必要はないです。みんな優しくしてくれると思います。

最後にVimは早くやればやるほどいいです。

まとめ

振り返ってみれば、我ながら苦労の多い道でしたが今を思えば苦労も無駄ではなかったのかなと思います。

特別優れたエンジニアではないですけどやっぱり自分にとってはこれが天職だと思っています。

なのでこれからも苦労していきます！！

今年1年の振り返りもしたいな〜

DevLOVE関西『「価値探索型のアジャイル開発」をはじめよう』に参加して

開発プロセス アジャイル ミートアップ

こんばんは。akitoshigaです。
来週から大学の試験が始まるので最近は鬼のようにレポートを書いています。

表題の通り、先日の11/5（火）にDevLOVE関西さんにお邪魔してきました！🙌
この日の回は、最近「アジャイルなプロダクトづくり」を出版された市谷聡啓さんのセッションが聞ける特別な回でした。
ちょうどその少し前にアジャイルなプロダクトづくり」を読んで感動した自分はこの日をとても楽しみにしていました。

そのセッションの内容が最高だったので自身のための整理も兼ねて以下に残そうと思います。

概要

このセッションでは、開発プロジェクトを進めていく上で起こる様々な問題をどう検知するかということから始まり、プロダクトの成果とは、何を指標とすべきなのか、価値の探索や仮説を立てる方法について説明していただきました。

見るべきものを見れているか

チームが開発プロジェクトを進める上での問題を検知できないのは何故なのか。
この原因は「見るべきものが見れていない」つまり問題の予兆を検知する仕組みが存在しないためである。

また、判断の指標が存在していたとしても、その指標を定めてから時間が経っており陳腐化していないかどうかにも注意が必要。

では、問題を検知するために具体的に何を見ていけば良いのか、それには以下の三つの視点が必要である。

  1. ユーザーの視点
  2. チームの視点
  3. プロダクトの視点

それぞれ、

  • ユーザーはプロダクトを利用することで必要な目的を果たせているか
  • チームは疲弊しておらずプロダクトを継続的に開発し続けられる状態か
  • プロダクトは健全であり技術的負債などによってデリバリーに時間がかかったりしていないか

これらを継続的に確認し、情報をアップデートしていくことが重要。

そしてプロダクトのアウトカム（成果）はこのユーザー・チーム・プロダクトが健康であり全てが充足した時に生まれる。
言い換えると、たとえユーザーが目的を果たしたとしても、チームもプロダクトも健全な状態になければ価値を提供しているとは言えないということになる。

ここで一つ疑問が生まれる。

収益が出ていれば良いのではないか？

プロダクトのアウトカムとは収益のことであり、収益を追求すべきではないのかという疑問が生まれるが、これは間違いである。

収益とはあくまでプロダクトの「結果」であり価値にはならない。

また、結果が出るのには時間がかかる。

「結果」の追求にのみチームを最適化すると、遅行指標による管理になってしまい金額が出るまでプロダクトに対する判断を下せなくなってしまう。

市谷さん曰く「バックミラーだけを見て運転しているようなもの」

チームやプロダクトに変化がなくてもプロダクトを取り巻くユーザーの状況は日々変わっていくので、絶えず価値を探索していくことが重要。

とはいえ、プロダクトを運営するのに売り上げは必要なので、収益はKPI、成果をOKRとしてそれぞれの指標を見ていく必要がある。

価値の探索をしようにもプロダクトの成果が曖昧なままでは探索のしようがないので、目標と評価指標を定める必要がある。

⁠探索の方法

ユーザー、チーム、プロダクトの視点で成果とは何かの仮説を立て、その仮説をもとにバックログを作成して実行に移す。

仮説を立てる時は書籍で紹介されているフレームワーク「仮説キャンバス」が非常に有効。

価値の探索活動も開発チケット同じように扱ってイテレーションの対象にする。

「成果」を誰かに決めてもらうだけの世界線は終わらせて、自分のハンドルは自分で握ること。
---

最後に

書籍を読んだ後だったので、このセッションを聞いてとても理解が深まりました。

他にも具体的な仮説の立て方なども紹介して頂きましたが、そちらについては書籍に詳しく解説されていたので、気になった方はぜひお手元にとってご覧ください🙌

市谷さん、DevLOVE関西さん本当にありがとうございました🙌

book.impress.co.jp

 

 

 

Rails Wayについて自分なりに考えてみる

Ruby on Rails

こんばんは。akitoshigaです。

先日参加したKaigi on Rails 2024で自分のRails力の至らなさを痛感したので、「Rails Way」について改めて自分なりに整理してまとめてみたいと思います。

 

最初に申し伝えとなりますが、この記事はKaigi on Rails 2024の以下のお二人の発表に影響を受けて書いたもので、その内容をかなり参考にさせていただいています🙏

Vladmir Dementyevさん『Rails Way or the highway』

speakerdeck.com

五十嵐邦明さん『Railsの仕組みを理解してモデルを上手に捉える』

speakerdeck.com

そのため、Kaigi on Rails 2024でこれらをご覧になった方は特に得るものがないかもしれません...🙏

前置きが長くなってしまいましたが以下本編です。

 

そもそも自分の何が至らなかったのか

振り返ってみると以下の3点につきると思いました。

  1. Rails Wayの重要性について認識していなかったこと
  2. Rails Wayの理解が浅かったこと
  3. Rails Wayに反した設計理論を持ち込んでいたこと

元々設計は好きで色々勉強はしてきたのですが、振り返ってみれば中途半端に知識があったからこそRails Wayを軽視していたように思います。

また、自分が初めて触れたRailsのアプリケーションがすでにリリースから数年経っており、成長に伴いRails Wayから外れていたものでした。

そのため、この状態からRails Wayを遵守しようという意識にならなかったのも要因の一つだと思います。

『Rails Way or the highway 』の以下の一節が非常に重要だと感じました。

Rails Wayとは

『Rails Way or the highway 』では以下のようにまとめられています。

これを踏まえ、Rails Wayを自分の言葉で以下のように解釈しました。

「RESTを前提にリソース(URL)設計・データモデル設計を正しく行い開発者の設計判断とコーディング量を減らし生産性を上げる」

この解釈に至るまでには、ピクスタさんが運営しているポッドキャストの『texta.fm』が大変参考になりました。

text.fmの第3回『3.Low-Code Development』の中でRailsの思想について概ね以下のように述べられていました。

・シンプルなルールを仮定することで全体の作りをシンプルにする

・シンプルにすることで考えることを減らす
・考えることが減ればコードの量も減り、かつ設計に悩む時間も減る

・コードの量と考えることが減れば生産性は上がる

この思想の代表的な例はRailsのModelの実装だと思います。

RailsのModelは基本的にエンティティになります。

ご存知の通りModelはActive Recordパターンによりデータベースのスキーマと密結合しておりCRUD処理の窓口にもなっています。

その他にも、コールバックやバリデーションなどの仕組みを駆使してアプリケーションにおける複数の役割をModelに持たせています。

この密結合な構造と引き換えにRailsはシンプルなレイヤーを保ちつつ設計判断のコストを減らしています。

そのため、Modelを特定のユースケースと結びつけて付随する処理の殆どをModelに実装するのがRails Wayに沿った設計になります。

一方、サービスなど新しいレイヤーを追加するのはRails Wayに反しているということになります。

 

そして、このModelを有効活用するためにはRESTを遵守したリソース(URL)設計とデータモデリングが必要になります。

先述のtexta.fmでリソース設計、データモデリングについて以下のように述べられています。

  • Railsは必要なデータは最新の物と割り切る事で殆どの事をデータのCRUDで表現可能
  • 殆どの事をデータのCRUDによって表現できるとリソース操作もパターン化が可能
  • パターン化できるとスキャフォールドと規約によるメタプロによって生産性が上がる
  • データモデリングとリソース設計が決まればコーディング自体はある程度導き出せる
  • そのためにはデータモデリングをしっかりやる必要がある

つまり、アプリケーションのユースケースをリソースとそのCRUD操作で表現できるようになれば、実装されるコードはスキャフォールドに近くなり非常にシンプルで生産性を高めることができます。

 

また、この他にもRailsは様々な規約を定めることで開発者のコード量・設計判断のコストを減らしています。

例えば、先ほどのModelはデータベースのテーブル名に基づく特定の規則に則ったクラス名にすることで、開発者がORマッピングの設定をすることなく特定のテーブルと紐づいたエンティティとして使用することができます。

 

以上がRailsの思想に則ったRails Wayを体現する方法だと知りました。

ただし、これには問題があります。

Rails Wayに沿ってどう拡張していくのか

先述の通り、Rails WayによってModelはユースケースと深く結びつくことになります。

アプリケーションが小規模なうちはこれで大丈夫なのですが、肥大化してModelが複数のユースケースと結びついた時にRails Wayが崩壊するという問題を抱えています。

これを回避するために以下の対応方法を取ることができます。

イベント型モデル

  • リソース系とイベント系のデータが一緒になっていないか？
  • イベントを見落としていないか？
  • イベント型モデルを発見することができればユースケースと紐づけることができる

フォームオブジェクト

  • パスワードの確認フォームなど、Modelと画面が1対1でなくなってきた時に使用する
  • ActiveModelのモジュールをincludeすることでバリデーションやコールバックなどを使うことができる

PORO(Plain Old Ruby Object)  

  • 責務がはっきりしなかったり、永続化の必要がなくてもオブジェクトとして扱いたい概念が出てきた時に検討する
  • Rails Wayからは外れそうになるためチーム内でのルールの共有などが必要

具体的なイベント型モデル、フォームオブジェクト、POROの詳細は初めに紹介した『Railsの仕組みを理解してモデルを上手に捉える』で解説されているので、気になる方は是非チェックしてみてください。

また『Rails Way or the highway 』ではRailsを独自の抽象化を定義しても以下の4層から外れないようにすることが重要だと述べられています。

まとめ

知ってしまえばRailsの思想は非常にシンプルですが、同時にモデリングの重要性といった本質的な奥深さも感じて以前よりRailsの事が好きになりました！

そして、自分もRails Wayに則した綺麗なアプリケーションを構築してみたいと思うようになりました🙌

今回自分なりにRails Wayについて考えてみましたが、自分の理解が及んでいないことも多分にあると思います。造詣の深い方がいらしたら是非この記事に関してフィードバックを貰えると嬉しいです🙌

 

その他参考にさせて頂いたもの 

Railsはおまかせ(Rails is omakase翻訳)

Ruby on Railsの正体と向き合い方

パーフェクトRuby on Rails【増補改訂版】

2024/11/03

読書感想文 日記

こんばんは。akitoshigaです。


最近自社の業務でAWSコンソールとTerraformをずっと触っているのですが普段あまりこういったことはやらないので新鮮で楽しいです。

 

プライベートでは英語の勉強を頑張り始めました。（今年ルーカスさんと出会ってからちょくちょくやってた）
mikanでDUO 3.0の単語を勉強しているのですが、難しすぎて泣きそうです。
文法はタロサックさんの動画をみて勉強しています。
www.youtube.com 👆めちゃおもろいです。

 

あとは、「データベース・リファクタリング」を読みました。

データベース・リファクタリング

振る舞いやデータの整合性を維持しながら、データベースをリファクタリングするための手法について解説された書籍です。

 

読んでみた率直な感想としては、手順さえしっかり踏めば手間はかかるけどデータベースもちゃんとリファクタしていけるんだなと思いました。

当たり前ですが、データベースはアプリケーションと違ってデータを永続化しているのでリファクタリングに対して心理的なハードルが上がってしまいますが、データベース構造の歪さをアプリケーションレイヤーで吸収したりせずこの本を参考に臆せずリファクタしていきたいなと思いました。

絶版のため値段は高いですが各リファクタリンングのトレードオフや注意事項も載っていたので買ってよかったなと思いました！おすすめです🙌

 

『アジャイルなプロダクトづくり』を読んで

読書感想文 アジャイル 開発プロセス

こんばんは。@akitoshigaです。
最近ふと「本質的な価値提供をするには個人の力だけ伸ばしていてはいけない」と感じて開発プロセスのことを勉強し始めました。

その一環で市谷聡啓さんの『アジャイルなプロダクトづくり』を読んだのですが、それがめちゃくちゃ良かったので感想文を書くことにしました。

どんな本？

平たく言うと仮説検証型アジャイル開発について書かれた本です。
プロダクトづくりにおける成果・価値とは何か、価値をどう探索するか、価値を提供するためにチーム・プロダクトはどうあるべきか、ということについて詳しく解説されています。
ある架空の開発現場を舞台にした物語パートとその解説パートで構成されています。

 

読んでみて

書籍の中で悪い例とされている内容に心あたりがありすぎて胸が苦しくなりました...😇

自分がプロダクト開発について漠然と課題感を持っていた所が言語化されていて腑に落ちたのと同時に、自身がいかにプロダクトについて関心がなかったかを痛感しました。

今までアジャイルについては表層的な知識しかなかったのですが、これからはこの書籍を参考に試行錯誤しながら本質的な価値を提供するために努力してみたいと思います。

 

勉強になった所

勉強になった所は山ほどあるのですが、その中でも特に勉強になった2点について紹介します。

 

1.『価値』を届けるために必要な3つの視点

KPIやOKRといった意図的に設定する目標を漫然と追いかけているだけではプロダクトとそれを手がけるチームとして『価値』を生み出せていない。

『価値』を生み出すには『持続的に活動できる状態』である必要がある。

『持続的に活動できる状態』はユーザー・チーム・プロダクトの3つの視点から判断できる。

1. ユーザーの視点

  • ユーザーの声を蔑ろにしていないか

2. チームの視点

  • 自身の役割に固執するあまりメンバー間で分断していないか
  • 「自分だけ良ければいい」という状態になっていないか

3. プロダクトの視点

  • 技術的負債に向き合っているか
  • 開発プロセスが単なるタスクマネジメントになっていないか

---

書籍の序盤で上記のように述べられているのですが、これが見事に悪い方に当てはまって辛かったです😇

人間は安定を求める生き物なので、日々の開発で一杯一杯になり次第に挑戦する気力を失ってしまいいたずらに時が経ってしまうということはあると思います。

市谷さんはそういった状況からチームを変えるのは難しいとおっしゃっており、これを打破するのがユーザーの声だと書籍で述べています。

加えて、この状態のチームはプロダクトに対する仮説が曖昧になっているので、仮説を立て直すことから始めるのが良いとも述べられています。

 

2.プロダクトの価値の探索における3つの罠

プロダクトを開発するときに、問題と解決策を定義する上で陥りがちな3つの罠がある。

 

1. 前提が問えていない罠

  • 答えありきでプロダクトをいきなり作り始めてしまう
  • チームがなぜか問題とその解決策を分かっている前提
  • 解くべき問題が適切かが問えていない状態

2. 顧客が正解の罠

  • 想定する顧客やユーザーをそのまま答えと捉えてしまう
  • 顧客の声を鵜呑みにしてしまう
  • 顧客の声に対して開発者は「正解を得た！」とバイアスが働いてしまう

3. 完成 = 本番の罠

  • プロダクトが完成したらいきなり本格的に展開してしまう
  • 形に見えるもの（理解しやすいもの）ができると「これが正解だったのか！」と思い違いを招く

--- 

これも当てはまりすぎて泣きました。

特に「顧客が正解の罠」には何度も引っかかっていて、この原因は自分の中で問題を正しく捉えられていなかったことに尽きるなと思いました。

自分が問題に対してかなり表層的に取り組んでいた事を痛感しました。

 

最後に

書籍では上記に対する解決法やプロダクトの課題設定・価値の探索方法について丁寧に解説されているので、少しでも気になった方は是非チェックしてみてください！オススメです🙌

book.impress.co.jp

 

おまけ

余談ですが、ちょうど今日こんなイベントを発見しました。

「価値探索型のアジャイル開発」をはじめよう - DevLOVE関西 | Doorkeeper

市谷さんが『アジャイルなプロダクトづくり』のエッセンスを踏まえながらプロダクトの「成果」や価値創出についてお話しくださった後、その内容について他の参加者の方とディスカッションするそうで天啓かと思いました。

もちろん参加します！DevLOVE関西のお名前はよく聞いていたのですが参加したことはないので今から楽しみです🙌

 

Kaigi on Rails 2024に参加してきました!

Ruby on Rails カンファレンス

こんにちは。@akitoshigaです。

先日の10/25に有明にて行われたKaigi on Rails 2024に自社の仲間たちと行ってきました!

現地に行ったのは初めてだったので、会場の熱気を肌で感じれてよかったです。

今回自社にスポンサー協賛をしてもらったのですが、自社は今までこういったカンファレンスにスポンサーをしたことがありませんでした。

自分の働きかけで今回それが実現したので感慨深かったです。

また、拙いですがノベルティも作成しました！

会場で見た他社さんのノベルティのクオリティの高さに圧倒されたので、次回はもっと気合いを入れたものを作りたいです。

 

Day2は自宅から参加してました！

 

2日間参加した感想としては、まず自分はRailsのこと何も知らないんだなということ。

Railsには2年半ほどお世話になっており自分の中ではある程度ちゃんと開発ができていると思っていましたが、Railsの良さを生かせてはいなかったと痛感しました。

Railsは自分が考えていたよりずっと奥深く、そして楽しいフレームワークだったのだなと認識を改めさせられました。

こういった場に足を運ぶのは知らないことを知れると言う点でもめちゃくちゃ価値があると思いました。

今日は自分が知りたいなと思ったトピックについて調べたり、他の人がお勧めしてくれた記事やスライドなどを見てたりしていました。

 

2つ目はRailsコミュニティの温かさ。

お話させていただいた人はみんな気さくでそしてRubyとRailsが大好きでした。

こういった方達のおかげでこの場があると言うことに感謝するとともに、自分も何らかの形で還元していきたいなと思いました。

 

実になる話が一つもなくて恐縮なのですが最高に楽しかったです！🙌

運営の皆さんには本当に感謝申し上げたいです。

セッションのレポートは自社のテックブログの方で公開する予定です🙌

Â