変わらないと思っていたことと、実際に変わったこと

この記事は横浜北部ソフトウェアエンジニアの集い Advent Calendar 2025の19日目の記事として執筆しました。 盛大に遅刻してしまい申し訳ありません・・・。

今回はYokohama North Meetup #11「LT忘年会2025」で発表した内容をブログ向けにリライトした内容でお送りしたいと思います。

ソフトウェアエンジニアに転職してもう8年となりますが、ふとこれまでを振り返って「変わらないと思っていたこと」は、だいたい変わるなと実感したため、これまで起きたこととこれから起きる変化についてどう向き合うかアウトプットしてみました。

転職したてのころに思い描いていたこと

ソフトウェア開発者として働き始めた頃、毎日が変化に富んでいて刺激的で、とてもモチベーションが高かったのを覚えています。 書くコードも、覚える技術も、すべてが新鮮でした。

「分からないことがある＝成長の余地がある」
そう思えるだけのエネルギーがあり、常に前に進めていた実感があります。

その中で、自分で「これはこの先も変わらないだろう」と思っていたものがありました。

• コードを書くことは、ずっと楽しいはず
• 体力は気合でなんとかなる
  • ずっと目標にしていた仕事に就くことができていてハイだった
  • 仕事上のストレスも少なく、疲れをそこまで感じていなかったので夜遅くまで勉強や作業をしていた
• スキルを積み上げていけば、将来は自然と明るくなる
• 自分はずっと「実装する人」でい続ける
  • とにかく手を動かすことが楽しいのでこれからも続けていける
  • 転職も成功したし、これからの人生はきっとうまくいくという全能感

当時の自分にとって、それらは疑う余地のない前提でした。

---

少しずつ見えてきた、別の側面と最初の壁

しばらく経つと、景色が少し変わってきました。

• 学ぶべきことが減らないどころか、むしろ増えていく
  • 実装などで自力で解消できない問題にぶつかるたび焦る
  • もちろん周りのメンバーや上司も頼っていたが、もっと自走したいという気持ちがあった
• 自分の現在地が分かりにくくなる
  • 成長具合やスキルレベルなどが計りづらかった
• 悩みが増え、体力の消耗を感じるようになった
• 将来について、漠然とした不安がよぎる

「何かがおかしい」というほどではないけれど、以前のような軽やかさは確実に薄れていました。

これは特定の出来事が原因というより、「時間の経過とともに、仕事や自分自身をより俯瞰的に捉えるようになった」 という感覚に近いです。

環境が変わると、見えるものも変わる

最初にソフトウェアエンジニアとして働いていた会社はとても良い環境で、未経験の自分を受け入れて頂いたことにも多大な恩を感じていました。しかし、「他の世界(他社)のことも知ってみたい」「コードを書くだけじゃなく中〜大規模チームで開発する経験を身につけたい」という理由で転職に踏み切りました。

環境が一新し、さらに違う技術を身につける機会が増えて「出来ること増えた！まだまだやれるじゃん自分！」という自信も湧き、キャリアがスタートした頃の前向きさが次第に戻ってきました。 しかし、その高揚感は持続せず、複数チームで大きなプロダクトを開発する組織でまた新たな悩みが生まれます。

• 信頼している人の退職、新メンバーとの関係構築
• 在籍メンバーもポジションが変わったりして関係性が変わる

自分の成長以上に事業や組織の変化が目まぐるしく、適応していくことに四苦八苦したこともあります。

コロナによって強いられた「強制的変化」によるストレス

そして、新型コロナの感染拡大に伴い働き方が一気に非対面中心へと切り替わりました。
「選択した変化」以上に、ほぼ強制的に訪れた変化がもたらしたネガティブ要素は計り知れないものでした。

仕事の仕方がフルリモートに切り替わることで - ちょっとした相談がしづらくなる
- 相手の状況や感情が文面だけで読み取りにくくなる
- 雑談や偶発的な会話が減る
といった影響がすぐに現れました。

また、オフィスで働いていた頃よりも誰かと並走している感覚が薄れ、「手応えのなさ」や「孤独感」がじわじわと積み重なっていくのを感じました。

画面越しのコミュニケーションは効率的な一方で、「今これを聞いていいのか」「自分の理解は合っているんだっけ？」といった小さな迷いが積み重なっていきました。以前は自然にできていたことが意識しないと成立しなくなり、滅入ってしまう日々が増えました。

今でこそハイブリッド型勤務を実践することでリモートワーク・対面コミュニケーションの恩恵を享受できていますが、当時はなるべく人と会うのを避けようという雰囲気が社会全体を包んでいましたし、未知の感染症との戦いはいつ続くのか・自分は健康に過ごし続けられるのかという不安も重くのしかかっていました。

今振り返ると、これは個人の問題というより、急激に変わった働き方に、心と認知が追いつくまでの調整期間だったのだと思います。

「変わらない」は前提にしない

ここ数年で、「変わらないと思っていたものほど、実は変わっていく」という事実に直面しました。 自分の考え方や社会情勢、人の立場など、思った以上にこの社会は変数で溢れており、それを確信しました。

• 働き方は、大きな外的要因をきっかけに一変した
• コミュニケーションの取り方も再設計が必要になった
• 生成AIの登場で、職種と職域が再定義を迫られ「コードを書く」ことの意味も変化した

どれも、個人の努力やキャリアの計画とは無関係に起こりました。

変化に対して、どう向き合うか

環境の変化そのものはコントロールできません。でも、どう向き合うか・変化をどう捉えるかは選べます。 変わっていくことを「強風」と例えるなら、絶対に折れることのない大木になることは難しくとも、大きく曲ったりはすれどしなやかに受け流すことができる竹のような心持ちでいようと考えるようになりました。

• 悩みや不安を隠さない
• 感謝は正面から伝える
• 記録を残し、前提を共有する

というオープンコミュニケーションを意識的に実践すること、これは非対面でも対面問わずますます重要になりました。

また、スキルと役割についても

• 職種を固定的に捉えすぎない
• これまでの専門性を軸に、隣接領域へ踏み出す（越境する）
• 学び直し（アンラーニング）を恐れない

という柔軟さを身につけることを目標にしています。

組織との関わり方については、自分が目指すキャリアの位置に固執するのではなく、

• 人や役職が変わっても揺れにくい立ち位置を意識する
• 「今いる場所で何を提供できるか」に集中する

ことで多少の変化を受け入れて前に進めるようになりました。

変わり続ける前提で、働く

常に同じだろうと思っていたことに対して変化が起きると、自分の中で築いていた前提のようなものが崩れるような感覚に飲み込まれ苦しくなります。

一方で、

変わることを前提に、自分も少しずつ更新していく

自分の現在位置を把握し、向かう道を自分で決める

そう考えるようになってからは、不安や違和感も「次の調整ポイント」として受け取れるようになりました。

---

この文章が、同じように変化の途中にいる誰かの視点を少しだけ楽にできたら嬉しいです。

フルリモートワークを続ける上で業務以外で実践していること

COVID-19の影響で現職も全社員が原則自宅でのリモートワークを推奨されており、緊急事態宣言の発令1週間前から連続して3ヶ月間、在宅で毎日仕事をしている。その中で、個人的に心身を整えるために実践している取り組みについていくつか紹介します。

決まった時間に寝て、出社していた頃と同じ時間に起きる

だいたい就寝が0時半〜1時半の間で、起きるのは8時〜8時半の間と決めている（平日のみ。週末や休日は遅寝遅起きになることも）。よくフルフレックスやリモート勤務になると始業ギリギリまで寝ている、という人の話を聞くが、不自由なく段階的に出社できるようになった時に体内時計のリズムが崩れると困るのでとりあえず以前と同じ睡眠のタイミングを保ち、最低でも7時間は眠るようにしている。これだけで体調を崩す要因をだいぶ減らすことができている気がする。

朝は起きたらすぐに散歩に出かける

ちょうどゴミ出しのタイミングで部屋の外に出るので、そのついでに20〜30分かけて近所の人通りの少ない道や川沿いをウォーキングしている。土砂降りでもない限り、ちょっと暑い日でも保冷剤を首に巻いて、人があまりいないタイミングではマスクを少し外して熱中症にならない程度に体を動かす。 運動不足を解消したいという動機もあるけれど、日光に浴びることによってビタミンDが生成されるので、それが気分の不調や免疫力を保つのに役立ってくれると聞いて実行している。あとは夏本番に向けての熱中症対策として暑熱順化の一環。

熱中症対策 「暑熱順化」で暑さに負けない体づくり - ウェザーニュース

それにしても、緊急事態宣言発令中は川沿いをノーマスクでジョギングする人が多くてヒヤヒヤさせられた。最近はめっきり減ったけど。

健康ステッパーで30分くらい有酸素運動をする

これも運動不足解消の一環。ステッパーは全社的にリモートワークに移行したタイミングでネットで購入した。こういうのって自分の親世代くらいの人が部屋で使うものだと思い込んでいたけど、いざ軽いジョギングくらいの強度で20分ほどやってみるとダラダラ汗が出てくる。基本的に毎日、業務が終わって退勤の打刻を押した後にやっている。あまり遅い時間にやるとギシギシと音が響いて下の階に迷惑がかかりそうなので、20時までにはこの運動を終わらせている。 ステッパーを踏んでいる間は本を読もうが動画を見ようが自由なので、時間を効果的に使いながら体を動かせて結構お得感がある。

ぬるめのお湯に20分ほど浸かる

ほぼ毎日湯船にお湯を貼ってリラックスタイムに充てている。入浴も暑熱順化と安眠の効果があるので、家にユニットバスしかない人にも週2 - 3回は実践するのをおすすめしたい。シャワーで済ますよりも血行もよくなる。

きちんと感染対策をすればそろそろ銭湯やサウナにも行ってよさそうだけど、まだあまり踏ん切りがつかない。

もずくやめかぶなどの海藻類、青魚を食べる

海藻類には感染症の重症化であるサイトカインストームを抑える働きがあるらしい。本当かどうかは詳しくはわからない。 ただ、スーパーでも小分けにしてパックで売られていてそのまま食べられるし、これから夏に向けて酢の物を摂取して夏バテに強い体を作りたいと思って食べている。 青魚はいわしやサバなど、缶詰やレトルトで簡単に調理して食べることができ、欠乏しがちなビタミンDを多く含むので自炊がめんどくさい僕のような人間にとっては貴重なタンパク源だ。ただ毎日食べ続けているとアレルギーを発症する恐れもあるので、週に何回まで、と上限を決めた方がよさそう。

React の軽量なルーティングライブラリ「Navi」を試してみる

We Are JavaScripters!【執筆初心者歓迎】 Advent Calendar 2018 の12日目の記事です。大遅刻してしまいました。 WeJSは聞く側で参加したことはあるのですが登壇したことはまだ無いので来年はLT枠で出場したいです。

Navi について

github.com

Navi は React で使える軽量なルーターで、SEOが必要な大規模な静的サイトの構築に適したライブラリとして開発されています。作者は東京在住の James K. Nelson さん。先日の東京Node学園祭でご本人の登壇を聞いて存在を知りました。React のルーターは React-Router が有名ですが、使っていてちょっとつらみがあったので他の手段があるならぜひ試してみたいな、と思い GitHub の Readme を読みながら試してみました。

Getting Started

Create React App を使ってプロジェクトの雛形を作成してからNaviを導入してみます。Jamesさん本人も Create React App との組み合わせが強力、と押しているので早速それにならってチュートリアルを読みながらデモを動かしてみましょう。

インストール

create-react-app navi-demo cd navi-demo

Navi のパッケージは npm に登録された react-navi navi の二つからなるので、両方インストールします。

npm i --save react-navi navi

インストールが完了したらsrc直下にpageというディレクトリを作成します。

cd src && mkdir page

ルーティングの作成

次に、page/index.js を作成します。ここにサイトマップとそのルーティングを以下のように書きます。 ルーティングにはcreateSwitchを、ページコンテンツの生成にはcreatePageというAPIがそれぞれ用いられます。 createSwitchの中に paths という名前のオブジェクトを生成します。paths オブジェクトはネストしており、もう一段階下にサイトのURLを相対パスをキーとして登録し、中身にcreatePageというコンポーネントを登録します。

// pages/index.js
import { createPage, createSwitch } from 'navi'
import * as React from 'react'
import { NavLink } from 'react-navi'

export default createSwitch({
  paths: {
    '/': createPage({
      title: "Navi",
      content:
        <div>
          <h2>Navi</h2>
          <p>A router/loader for React</p>
          <nav><NavLink href='/hello'>Hello</NavLink></nav>
        </div>
    }),
    '/hello': createPage({
      title: "Hello",
      getContent: () => import('./hello.js')
    }),
  }
})

createPageの中身はtitle (ブラウザに表示するページタイトル)とcontent に分かれます。contentについてはJSXをベタ書きしたり、getContent関数で外部ファイルを読み込んだり、JSONを記述することもできます。上記の例ではサイトのindex('/')のcontentはJSXがベタ書きされていて、helloというページへのルーティングの中は外部ファイルをimportしていますね。 それでは同階層にある hello.js の中身をみてみましょう。

// pages/hello.js
import * as React from 'react'
import { NavLink } from 'react-navi'

export default function Hello() {
  return(
    <div>
      <h2>Hello</h2>
      <p>This is demo.</p>
    </div>
  )
}

一見するとごく普通の React の Functional Component が読み込まれているように見えますがここに Navi のミソがあります。 pages/index.jsでは<NavLink>というオブジェクトを介して/referenceへのリンクが貼られています。

Naviでは、<NavLink>へ登録されたリンクへジャンプすると一度中身が空のページをレンダリングし、そこへPromiseとして定義されたオブジェクトを非同期的に読み込んでルーティングを実現する仕組みになっています。

ルーティングの流れ

1. <NavLink>オブジェクトに登録されたリンクをクリックする
2. リンクに遷移すると同時に空白のページをレンダリング
3. pages/index.jsで定義されたルーティングと対応するPromiseコンポーネントを読み込み、ローディングが完了するまで待機。
4. Promiseが解決(ローディングが完了)されたらコンテンツとしてレンダリング

Navigationオブジェクトの作成

Navi による強力なルーティングの仕組みを利用するためには、src直下のindex.jsにNavigationという Navi の根幹をなすオブジェクトを作成する必要があります。NavigationオブジェクトはcreateBrowserNavigation()という API を用いて以下のように作成します。

// index.js
import * as React from 'react'
import * as ReactDOM from 'react-dom'
import { createBrowserNavigation } from 'navi'
import pages from './pages'
import App from './App'

async function main() {
  let navigation = createBrowserNavigation({ pages })

  // Wait until async content is ready, or has failed.
  await navigation.steady()

  ReactDOM.render(
    <App navigation={navigation} />,
    document.getElementById('root')
  );
}

// Start the app
main()

main()関数をasyncで定義し、その中でcreateBrowserNavigation()を./pages直下のコンポーネントとをまるごとラップする形で呼び出します。navigationに内包されたPromiseオブジェクトが解決されるとsteady()が実行されて非同期的に各ルーティングのコンテンツをレンダリングする仕組み、という解釈でいいのかな。

Appを定義する

これまでに定義した各種コンポーネントを<App>内に仕込めば静的サイトの構築がいよいよ完了です。ここで新たに、<NavProvider>と<NavRoute>というコンポーネントが登場します。これらの仕組みは React の Context APIに近いっぽい？ <NavProvider>が Context API の Provider で、<NavRoute>が Consumer という風に理解しています。

// App.js
import * as React from 'react'
import { NavLink, NavProvider, NavRoute } from 'react-navi'
import './App.css'

class App extends React.Component {
  render() {
    return (
      <NavProvider navigation={this.props.navigation}>
        <div className="App">
          <header className="App-header">
            <h1 className="App-title">
              <NavLink href='/'>Navi</NavLink>
            </h1>
          </header>
          <NavRoute />
        </div>
      </NavProvider>
    );
  }
}

src/index.jsで<App>に Navigationオブジェクトを props として渡していますね。Consumer にあたる<NavRoute />を記述することでルーティングに紐づいた各コンポーネントを非同期的にレンダリングしてくれます。

Navi

その他

その他、ローディングインジケータを表示したり存在しないページへのアクセスのハンドリングといった機能もありますが今回の記事ではその説明は省きます。

自分なりに英語のドキュメントを解釈しながらここまで説明してきましたが、より正確に理解するには公式のドキュメントを読みながら各自で動かしてみてください。 また公式チュートリアル動画が作られたようなので、より深くNaviを知りたい方はこちらを試聴してみてください。

www.youtube.com

【Laravel】Eloquent ORM で $model->save(); がうまくいかなかったときの解決法

Qiita Laravel#2 Advent Calender 21日目の記事です。 furuichi と申します。Laravel 歴は大体4ヶ月です。

こういうことをやりたいとき

Eloquent の Model を使ってDBのレコードを更新( $model->save(); )したい。Model と更新用のコードは以下のような感じ。

Model.php

class Something extends Model
{
    protected $table = 'something';

    public $timestamps = false;
}

ExampleController.php

public function store(Request $request) //post
{
        $something = new Something();
        $something->data = $request->data;
        $something->save();
}

チュートリアルによく似た方法で行なっているはずなのに、レコードが更新されなかった。save()の戻り値もTRUEだった。 「なぜ？」と思って公式のチュートリアルを読んでみたら以下のような一文が。

解決の手がかり

https://readouble.com/laravel/5.5/ja/eloquent.html

主キー

Eloquentは更にテーブルの主キーがidというカラム名であると想定しています。この規約をオーバーライドする場合は、protectedのprimaryKeyプロパティを定義してください。

Somethingと紐づいているテーブルの主キーを確認してみた。大文字で ID と設定されていた。どうやら小文字のidでないと思った通りに振舞ってくれないらしい。ということで Model のコードに主キーを以下のように追記した。

Model.php

class Something extends Model
{
    protected $table = 'something';
    // Eloquentの主キーは'id'というカラムを想定しているため、テーブル側で異なる場合は
    // このように指定しないといけない。
    protected $primaryKey = 'ID';

    public $timestamps = false;
}

これで、save()メソッドがうまく動いてくれてDBのレコードに更新をかけられるようになった。DBの主キーのカラム名には要注意です。

Laravel Eloquent ORM のモデルによく使うスコープをメソッドで登録する

Qiita Laravel Advent Calendar 2018 の18日目の記事となります。furuichiです。

クエリスコープ

Laravel の Eloquent ORM では、モデルに紐づけたメソッドを使うとDBからのデータの取得がらくらくできる。

例 モデル名::find(主キー)

$customer = Customer::find($customer_ID)

上のコードでは、$customer_IDを主キーとして持つレコードを Customer テーブルから取得できる。 これがクエリスコープという仕組みで、デフォルトで使えるメソッドとしてはfindが有名。そのほかにオリジナルでよく使うクエリをモデルに紐づけて登録することができる。

例 よく使うwhere句をモデルに紐づける場合

Customer->where('address' '=' $address)->get() のようなクエリを多用する時、いちいち同じコードを書いていると冗長になるので、クエリスコープとして登録すると短く書ける。

クエリスコープの作り方・使い方

作り方

モデル名.php ファイルにメソッドを追加するだけ。上の Customer モデルを例にとって作成して見ましょう。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Customer extends Model
{
    protected $table = 'customer'; //参照するテーブル名

    public function scopeAddress($query, $address) //スコープのメソッド。
    {
        return $query->where('address', '=', $address);

    }
}

クエリスコープのメソッドは scopeXxx のようにscopeから始まるキャメルケースで命名します。第1引数に $query を、第2以降の引数に変数を指定します。

使い方

Controller など、任意の場所で以下のように使えます。

$address = '北海道';

$customer = Customer::address($address)->get();

scopeHoge という名前のメソッドの Hoge の部分を小文字から始める形で使います。 上のコードは、Customer->where('address' '=' '北海道')->get() というクエリを書いた時と同じ結果を取得できます。

というのを社内で共有したのですが、社内からこんあツッコミがありました。

例えば住所であれば、英語で "customer living in Hokkaido"

と表現することができますよね。その考えを反映させて、 スコープ名を $customer = Customer::livingIn('北海道'); にするとかどうでしょうか？ あくまで参考です。

このツッコミで、メソッドの命名を工夫すれば自然言語を読む感覚でクエリスコープを使えそうだな、と思いました。 上記の命名方法でクエリスコープを書き直すとこうなりますね。

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Customer extends Model
{
    protected $table = 'customer'; //参照するテーブル名

    public function scopeLivingIn($query, $address) //スコープのメソッド。
    {
        return $query->where('address', '=', $address);
    }
}

クエリスコープはより複雑な条件もメソッドとして登録できるので、頻繁に使うクエリはどんどんモデル配下のメソッドとして書いておくと全体のコードがスリムになるかもしれません。

何かに貢献したいエンジニアはGASを使うと手軽に実現できるかもしれない、という話

Google Apps Script Advent Calendar 2018 - Qiita の3日目を担当させていただきます。furuichiと申します。

作ったもの

「JSおじさん寺子屋」という Slack のチャンネルがあります。JSおじさんこと中西さんが1日に1つ出題する JavaScript のお題を参加者が codesandbox.io 上で解いていき、技術力の向上を目指していくオンライン道場です。 お題は Google Docs のスプレッドシート上で共有され、出題者は回答のURLをそれぞれ自分の欄に貼り付けていきます。 スプレッドシートに回答が貼り付けられた時、それがトリガーとなって回答者名、URL、何日目のお題に対する回答という内容が Slack のチャンネルに自動投稿される Bot を GAS で作成しました。コードについては今回は省略いたします。 寺子屋なのでBot名は「teraco」です。スプレッドシートと Slack の連携は GAS で作られるツールとしてはオーソドックスな内容ですが、チャンネル参加者の方には喜んでもらえたので作ってみてよかったなと思いました。

作成した経緯

まず、「JSおじさん寺子屋」の母体である「もくもく寺」について軽くご説明をしたいと思います。

もくもく寺

frontend-temple.connpass.com

フロントエンド・Railsなどの領域をテーマに、各自もくもく作業をする会です。connpass にコミュニティがあり、過去にはReact、Nuxt.js、Dockerなどのハンズオンも開催されました。先日の Docker ハンズオンでは私もスタッフとしてお手伝いさせていただきました。

オンライン上では Slack にワークスペースがあり、ほぼ毎日何かしらの話題が共有され意見交換が活発に行われています。JS, Rails 含め経験豊かな人たちが集まっていて眺めているだけでも勉強になるし、都内勤務ではない私も輪の中に入れてもらって色々とお世話になっています。もともと、Webエンジニアに転職する前からこのコミュニティに参加しており、ワナビー状態の私にも様々なお役立ち情報や技術のTipsなどを参加者の方々から教えていただけて転職の夢を叶えることができました。

JSおじさん寺子屋について

寺子屋の発足はもくもく寺運営者のむろさんのこのツイートがきっかけでした。

JSもっと書けるようにならないと…

— 📸 (@murokaco) 2018年11月13日

寺子屋の詳細についてはむろさんのこちらの記事をご覧ください。

murokaco.hatenablog.com

私が作ろうと思った理由

チャンネル内でスプレッドシートが運用されることとなり、その流れで Slack に回答が自動連携される仕組みが欲しいな、という声が上がったので「GASなら多分実現できますよ」と自分からツール作成に名乗り出ました。最初は手探りでしたが、JSベースで書けることからネット上の知見を色々参考にすることで1週間で完成させることができました。

今年の春くらいからGASで何かを作ろう、と思ってはいたのですが何も思い浮かばず手をつけていない状態でした。また、お世話になっているコミュニティに対し、技術的な成果物で恩返しがしたいと思っていたので、ちょうどよいタイミングで自分の2つの目標を達成することができました。(余談ですが、このアドベントカレンダーに登録したタイミングでは何をやるかまだ決めていなかったので、ツールを作ることでここに書くネタを生み出すこともできて一石三鳥といった感じです)

GASでコミュニティに貢献するメリット

GASでのツール開発のメリットは、大掛かりな環境構築が必要ない点にあります。ブラウザ上のエディタからプロジェクトを開始することができ、運用フェーズに入っても Logger API を使うことで手軽に運用状況の監視が可能です。

tonari-it.com

唯一の難点としては ES2015 記法に対応していないことですが、旧来のJS記法に耐性や経験がある人にとっては些細な問題でしょうか。また、clasp などを使えばローカル環境で開発・テストも行えます。

qiita.com

また、自動投稿という形でスプレッドシートや Slack など業務ツール上で大きな力を発揮してくれるので、Webアプリに必要とされるようなUI設計に頭を悩ませずとも手軽に有用なものが作れます。エンジニアとして技術を使って人に価値を提供する上で、社内や所属コミュニティといった同業者同士の集まりの中でもそれを達成することは非常に意味があると考えています。GAS はミニマルな形でそういった価値創造が実現可能です。目に見える形で素早く何かを作って他者に貢献したい、という願望を持っている人にとってはうってつけのツールなので、ぜひ活用してみてください。

転職して1年が経った

10月中旬で、Web系のエンジニアとして転職してから1年が経った。仕事とは辛いことに耐え忍んでお金をもらうこと、という刷り込みから逃れられた体験はとても価値が大きかった。自分を自分で育てていくこと、得た知的資産を周囲に共有することで還元でき、さらに自分の価値が高められるのでいい業界(会社)に転職できたと思っている。 仕事内容や社風など色々と体験してみて嬉しいことがやはり多かった。1番嬉しいのは勉強したいという欲求に会社がサポートしてくれること。書籍購入代(紙媒体に限るけど)・社外勉強会への参加費用は全額負担してくれるのでたびたび利用させてもらっている。業務経験としてはほぼゼロだった自分を採用してくれたのは「機会を与えれば勝手に勉強して伸びていくだろう」という前のめりな姿勢を評価してのことじゃないか、と思っているのでこれからも勝手にどんどん伸びていきたい。

入社してからはしばらくはReact + Node.js + Firebase でサーバーレスSPAをフルスクラッチで作っていて、当初自主的に勉強していた Rails とはスキルセットがかなり違ったので色々と壁にぶつかったけど、お客さんと直で製品について話し合ったり上司から助け舟をもらって何とか壁を乗り越えることができて大変だったけど楽しかった。最近は JS から少し離れ PHP の各種 MVC フレームワークに触っていてまたスキルセットが大きく変わったのだけど、最初の案件(上記)の技術構成がなかなかトリッキーだったので下のレイヤ(RDBなど)に再入門している感じで刺激的ではある。わからないことが増え、それがまた少しずつわかっていくという面白さはこれからも続くだろうし、もっと色々なことをわかっていきたい。