2024年5月 TSKaigi参加レポート(今更)
はじめに
この記事は、以下のカンファレンスに参加してきた体験レポートです。
TSKaigiとは
「日本最大級のTypeScriptをテーマとした技術カンファレンス」です。
複数の登壇者が複数の部屋にてTypeScriptに関した発表を行い、参加者はその発表から学びを得て自身の技術力向上やエンジニアキャリアを豊かにするための時間にしていくことがこのカンファレンスの目的としてあるかと思います。
今回僕はこのカンファレンスに参加して、「自身の技術力向上」という面ではなく、「エンジニアキャリアを豊かにする」面の方が多く学びになったため、この観点でアウトプットしたいと思います。
（TypeScript全然関係ないです！すみません！！）
学び
大きな気づきを得られたことについて、3つ書きたいと思います。
※注記：文中で紹介している会社と個人とは直接関係ありません
1. 社内ベンチャー制度っていいね
TSKaigiでは登壇とは別に、オープンスペースでTSKaigiのスポンサーをしている様々な会社のブースが設けられており、各ブースにて会社独特のサービス紹介を行っていました。
その中で1番興味を引いたのが「Leverages」という会社のサービス説明でした。
Leveragesは業界を問わない様々な事業を手がける企業で、複数のグループ会社で事業を展開しています。そのLevragesの社内では職種関係なく新規事業のプレゼンテーションを行うことができる制度があり、認められた企画に関しては会社から資金提供を受け実現に向けて動いて良いという文化があると聞きました。
今回、ブースで説明されていた方は、その制度を使って新たにサービス開発を行なったPMとエンジニアの方2名でした。彼らが作られたサービスは「NALYSYS」という社員のモチベーション管理を行うためのサービスです。
※サービスの内容については割愛します。気になる方はこちらをご覧ください。
僕がこの社内ベンチャー制度の話から得た気づきは、会社で与えられた仕事だけをこなす働き方では大きな機会損失をしているのかもしれないということです。社内ベンチャー制度があったとしてもなかったとしても、自ら成長の機会をとりにいき実践に移すことは誰もが取り組める働きだと思いました。
自ら機会を掴みにいくと聞くと、リクルートの旧社訓「自ら機会を創り出し、機会によって自らを変えよ」という言葉を思い出します。
僕が所属する会社に関しても、このリクルートの社訓の視点が強いなと感じています。
個人が自分を更新していくことに重きを置いた評価制度や、挑戦を応援するような雰囲気があり、良い環境で仕事をさせてもらっています。特別、社内ベンチャー制度は設けられていないですが、実質あるようなもので、持ち込みすれば話は聞いてもらえるだろうなという感覚はあります。
インパクトが小さくても、何かしら、誰かに、貢献できる取り組みを自ら見つけて取り組んでいく機会を増やしていきたいと思いました。
今回の「Leverages」には、社内ベンチャー制度以外にも成長を促進するような文化や制度が多くありました。「働きがいのある会社」若手ランキング1位を5年連続取得している企業であることから、僕たちが学ぶべきことはまだまだたくさんあるかと思いました。
以下参考までに。
2. サービスは企業の思想を体現している
前項と同様、ブースにて「Helpfeel」という企業の話を聞いていました。
株式会社Helpfeelは、2007年に米国シリコンバレーで創業したSaaSスタートアップで、「Helpfeel」「Scrapbox」「Gyazo」の3つのプロダクトを主に提供しています。
プロダクトについては、Gyazoは聞いたことありましたが、社名のプロダクトであるHelpfeelは初耳でした。このプロダクトに所属するエンジニアが1番多くいるようです。
株式会社Helpfeelのビジョンは「テクノロジーの発明により、人の可能性を拡張する」であり、展開されている3つのサービスはどれもこのビジョンを体現するサービスになっているなと感じました。
そもそもサービスが生まれる経緯として、こうしたい！こうであってほしい！というビジョンから始まり、どうやって実現するかの具体化が起こり、結果としてサービスが生まれるという流れがあるためビジョンに沿ったサービスになるのは当然のことかもしれません。
（作る過程で、投資家や株主、その他社会の圧力によってビジョンを体現できないサービスになることもあるとは思いますがそれは別として）
このビジョンからサービスが生まれる話について、作り手のエンジニア側からの視点で思ったことは、可能な限りビジョンを念頭に置いて開発を進めていくことが大事になるなと思いました。
たた、理想的な話ではあると思います。あくまで可能な限り。
エンジニアとしては、個人の技術力向上、新しい技術を使って試してみたい好奇心、リファクタリングにより最適なコードを作れることの充実感、自分が作ったものを誰かに使ってもらう嬉しさ、などなど多くの願望があるかと思います。
個人のエンジニアとしての成長と好奇心を持って開発をすすめ、結果的に事業成長につながっているということは多分にあるかと思いますし、それが理想なのではないかとすら思います。
その上で、会社でのサービス開発は会社の思想あってこそなので、可能な限り理念を頭に置いておき、機能開発に取り組んでいくとより全体的な成長につながるんだろうなと感じました。
3. どの会社の企業理念（ミッション）も抽象度が限りなく高い。なぜ？
Leveragesをはじめとして、各スポンサー企業の企業理念を気になったので調べてみました！一部ですが、リスト化してみると以下の通りです。
これらどの会社の企業理念も抽象度が限りなく高いなと感じました。
僕が所属する会社にももちろんミッションがあります。
ただ、これまでは「抽象度が高すぎて自分ごとに落とし込むのが難しいものだ」程度の認識しかできていませんでした。
今回のTSKaigiでの経験と直近の体験をもとに、少し変化があったのでそのことについて書きます。
最近仕事で進めていたプロジェクトがあり、しばらくはそのプロジェクトをリリースして価値貢献するという目標で意識を持って取り組んでいました。しかし、一度本番リリースを終えたあと、自身のモチベーションが低下していることに気がつきました。
リリースが終えたとはいえ、まだまだ修正実装や追加機能実装のタスクがあるため気を抜くわけにはいかないのですが、何か気乗りがしないといった心境です。俗にいうモチベーションが低い状態になっていました。
この理由は何なんだろうかと考えていました。
モチベーションの高さがリリース前後で違う →これは正しそう
いや、そもそもモチベーションとは何なのか →ここを再認識する必要がある
モチベーションについては、気合を入れてやるぞ！というようなものではなく、目標に向かって自動的に引っ張られる力のことだと理解しています。
例えば会社の始業が8時からだったとして、会社まで通勤に1時間かかるのに朝7時あたりに起きたら、やる気がどうこういう前に出勤に向けて身体が動き出します。この場合出勤が目標値であり、そこに向かっていく心の動きがモチベーションだと認識しています。
この認識から考えるに、モチベーションが低くなっているのは到達したい目標値がなくなっている（あるいは当初の目標値を超えてしまった）からだという結論に至りました。
改善策として、高いところに再度目標を設定し直せばモチベーションは高まるのだろうと思います。そして立てた目標に再度到達した場合、また再度目標設定をすることになるかと思います。
この設定の仕方は悪くはないけど、気をつけたい点がひとつあることに気づきました。
長期的な目標設定が抜けやすいということです。
今回の僕の例で行くと、「特定のサービスをリリースすること」が目標値になっており、その先にどうしたいのかについてのビジョンは明確にありませんでした。短期的で具体的な目標ほど、モチベーションの消費期限が短いことを体感しました。
一方これが「＊＊社の業務効率を最大化し、社員の価値最大化に努める」のような抽象度が高い目標値になっていたとしたら、サービスリリースしたところでビジョンはまだ達成し終えていないためモチベーションが低下することはないだろうなと思いました。
この思考を突き詰めていくと、行き着くところ企業理念レベルの抽象度になるのだろうと気づきました。企業のビジョンの抽象度が限りなく高いのは、到底到達しきれないレベルの目標値を掲げてそこに向かう推進力を保ち続けるためなのだろうと。
仮に企業のビジョンが「＊＊サービスをリリースしてユーザー100万人を達成する」だとすると、100万人までいきそうな段階までは良くてもそこから先の未来はなさそう。
つまるところ、企業の理念は抽象度高いほど良い。そして個人の目標設定に関しては短期、中長期それぞれで持っておき、短期に関しては定期的に更新することを意識する、中長期に関してはビジョンと呼べるような美学を持っておくと良いのではないか、ということです。
おわり
以上、2024年5月に開催されたTSKaigiのレポートでした！！
プログラミングは一切出ていきていません！もうみなさん既にお腹いっぱいだと思うので別角度からアウトプットさせていただきました！（遅くなった言い訳）
何かの気づきになれば幸いです。
それではまた。
この記事が気に入ったらサポートをしてみませんか？