私のキャリアと計画的偶発性理論
※注: 今回は自分語りポエム回です
Xのタイムラインを眺めているとVTRyo(@3s_hv)さんのスライドが目に入りました。
こちらのスライドを拝見して自分のキャリアをふりかえるキッカケになりました。
今回は私のこれまでのキャリアと計画的偶発性理論について考えてみようと思います。
ふりかえってみると私のキャリアは失敗の連続でした。
大学を中退して就職活動をするも難航してやっとの思いで職についても、労働基準法に引っかかりそうなハードな企業を渡り歩くような具合でした。
その中でも自分が続けられそう(生存できそう)な職場で数年働いていました。
その職場は労働環境はハード(平均月残業時間3桁越え)でしたが、多くのことを経験できて学びもあったので続けていましたが、もっと自分が興味を持ってて適している業務内容がありそうだと常に思っていました。
しかし、これまで失敗続きだったのでまた失敗するのが怖くて動き出せずにいました。
数年その様な状況が続きましたが、5年前のコロナ禍や自身を取り巻く環境が変化して動かざるを得ない状況になりました。
同じような職種に移動する選択肢もありましたが、どうせ動くなら自分がもっと興味を持てて楽しいと思える方向に振り切ってみようと思いIT業界への転職を決めました。
この決断のおかげで5年前と今では取り巻く環境や感情も改善され、全く違うものになっています。
思い返してみると、この決断が私の計画性偶発性のはじまり、もしくは過去の点の積み重ねがIT業界へ舵を切るきっかけになったのかもしれません。
ここからは自分の気持ちや行動に明らかに変化が出ました。
失敗を恐れて動き出せずに毎日変わり映えの無い日々を送っていましたが、やったことない事にとりあえずチャレンジしてみる思考に変わりました。
また、これまでは、与えられた仕事をこなす、自分ができる範囲で、現在所属している職域でキャリアを築くという閉じた思考でしたが、
自分のキャリアを築く上で、やりたい仕事内容、ポジションなどの理想、ビジョンを設定し方向性を定めることでキャリア計画という概念が自分の中で生まれました。
この行動の変化と思考の変化が計画的偶発性を加速させ好循環を生み出したと感じています。
資料スライドにも取り上げられている、
好奇心、持続性、楽観性、冒険心、柔軟性
これらは自分の望むキャリアを築く上で重要な要素だと思います。
IT業界転職時の話に戻りますが、
IT業界に転職できたのも、その後現職に転職したのも偶然の積み重なりでした。
IT業界に転職できたのは当時Twitterで自身の転職活動模様を発信していたところ、投稿を見かけた方にリファラルで紹介いただきIT業界に入ることができました。
現職の入社もXでエージェントの方にお声がけいただいてのご縁でした。
これらの結果も、今までの投稿が及ぼした計画的偶発性だと思います。
計画的偶発性を生かしてキャリアに良い影響を与えるためには、
文字通りですがまずは自身の理想やありたい姿を計画して、それに向かってアクションを起こし、偶発性を高めていくのが良さそうだと感じています。
なぜあのプロジェクトは驚くほど早く進むのか
幾つかのプロジェクトに参加する中で、驚くほどトントン拍子に進むものもあれば、停滞感が強いものもあり、プロジェクトによって進行速度が全く違うと感じました。
会社の状況やプロジェクトが生まれた背景によるとは思いますが、スピード感あるプロジェクトの共通点が少し見えてきたので整理してみたいと思います。
1. 前例の有無
競合他社がすでに取り組んでいる前例があってその事業がうまく行っているとスピード感が増します。前例があると成功のイメージがつきやすいですし、目標がはっきり見えているので真っ直ぐ進むことができるからです。
逆に新規領域のプロジェクトになると手探りで進めなければいけないので、方向性やニーズを確認しながら進めることになります。
2.ステークホルダーの違い
プロジェクトに関わるステークホルダーの役職によっても進行が変わります。
役員クラスが関わっていたり、主導しているとスピード感が段違いです。
決定権を持っている方が近くにいると意思決定のスピードが早いからです。
3.お金になりそうか
企業が活動を続ける上では売り上げや収益がかなり重要です。
どんな素晴らしいプロダクトを作っても利益が発生しないと継続することができません。
多くの売り上げや利益の見込みがついていれば、プロジェクトの予算もつけやすいので積極的な動きが出ます。
4.メンバーの構成バランス
プロジェクトメンバーの役割のバランスも重要になります。
アイデアを出す企画側が少ないと作り始めるまでの準備に時間がかかったり、プロダクト開発を進める上での意思決定を待っている時間が発生してスピード感が落ちます。
システムの作り手である技術職の割合が少ないと、アイデアがあっても開発工数が十分に取れずユーザーに価値を届けるまでに時間がかかってしまいます。
5.プロダクトに対する熱量の高さ
プロジェクトに向き合う姿勢は、プロダクトに対する熱量の高さと切っても切り離せない物だと感じています。
メンバーが熱量高く持って取り組めれば、進捗も出やすくアイデアも多く提案されて改善サイクルが回ります。
逆に仕事だから半ば仕方なくやる様なスタンスだと、お互い他人任せになりやすく進行も停滞してチームの雰囲気も悪くなる悪循環に陥ります。
まとめ
プロジェクトの進行度合いは幾つかの条件が重なり合った結果だと感じます。
成功のイメージが描きやすい環境、意思決定の速さ、予算やメンバーの配置、そして関わる人たちの熱意。
どれか一つでも欠けていると足踏みしやすく、逆に噛み合った瞬間に一気に前に進む勢いが生まれます。
振り返ってみると、スピード感があるプロジェクトはそうした要素が整った状態で進行出来ていたのだと改めて思いました。
モバイルアプリ開発の挑戦と学び
先日、人生で初めて自分のモバイルアプリをリリースしました。
いつか自分のプロダクトを作ってユーザーに届けたいと思い続けていたのですが、ようやくその一歩を踏み出せました。
今回はその経緯から学びまでをふりかえってみます。
開発を始めたきっかけ
AI時代になり、エンジニアは開発だけでなくプロダクトを生み出す能力も必要になってくると日々感じています。
そんな中でモバイルアプリ開発コミュニティに参加して、同じコミュニティの参加者と2人でアプリを作ることになったのですが、リリース直前で相方が音信不通に...
相手の同意を得ずに一緒に作ったアプリをリリースする訳にもいかず、それならもう自分一人で全部0から作るしかないと考え、開発がスタートしました。
作るものをどう決めたか
まずは自分の身の回りのペインを解消できるようなプロダクトの方が開発のイメージがつきやすいと思いました。
AI技術も取り入れたいと思っていたので「AI x 身の回りのペイン解消」でアイデアを考えました。
技術スタックと開発プロセス
クライアントサイド Flutter
途中まで作ったアプリがFlutterで作っていたのと、ネットの情報や教材が充実していたので選びました。
バックエンド Firebase
Firestoreでデータ管理、Authenticationで認証、CloudFunctionsでコード作成
これがひとまとめで管理できるので採用しました。
開発プロセス
仕様をまとめたドキュメントをCursorに読み込ませて一気にバイブコーディングを試してみましたが、思い通りの結果が得られなかったり、バグが多くなってしまいました。
なので、仕様からタスクに分解して一つずつ方向性やバグが出ないか動作確認して作っていきました。
学んだこと
作り始めれば意外とできる
アプリリリースまでやり遂げられるか不安もありましたが、いざ始めてみると楽しくて夢中になっていて、いつの間にかリリースできちゃってました。
AI活用で工数削減
コーディング自体はバイブコーディングでそれなりの物を作ってくれます。
最終的には手直しが必要な箇所もありますが一から書くよりはだいぶ楽です。
最低限の機能でリリースを優先すべき
機能を充実させたり、デザインを凝りたくなる気持ちはあるけれど「まずは出す」が最優先です。コンセプトがしっかりしていれば後から機能追加や改善もできますからね。
リリースは開発以外も山盛り
利用規約やプライバシーポリシーの準備、ストア申請用のスクショ、Developer Programの登録なども意外と時間を取られました。
今後の展望
最低限の機能のリリースしたので、これからは機能を追加したり、プッシュ通知、広告配信なども取り入れたいと思っています。
少しずつ改善を積み重ねて「毎日使いたいアプリ」に育てていければいいなと思っています。
まとめ
今回の経験を通して、自分のプロダクトを世に公開するというのは本当に学びが多いと感じました。
AIのアシストもあり、コードを書くよりもプロダクトのアイデアをまとめたり、リリースまでの作業が時間がかかり大変でした。
もし私と同じようにいつか自分のアプリを出したいと思っている方がいたら、ぜひ小さくてもいいのでまずは形にしてみてください。
想像以上に学びと達成感がありますよ。
駆け出しエンジニア生存戦略
思い返せば5年ほど前になります。
私が異業種からエンジニアとしてのキャリアを目指した頃は、いわゆる駆け出しエンジニア全盛期でした。
当時はコロナ禍真っ只中。リモートで楽して稼げるエンジニア、という触れ込みでプログラミングスクールが雨後の筍の様に増え、怪しい広告もあちこちに流れていました。
私自身も大手プログラミングスクールに通って学んでいたのですが、同期の多くは残念ながら転職できなかったり、入社してもすぐに辞めてしまったり...
生き残れた人は少数派でした。
ではなぜ多くの人が脱落して行ってしまったか。逆になぜ自分はまだIT業界に身を置けているのか。
今回はこの違いについて自分なりに整理をしてみます。
目指した理由が現実的だった
「パソコン一つで楽にリモートで稼ぎたい」
このような理由でエンジニアを目指していた人の多くは早い段階で去っていきました。
説明するまでもなく、エンジニアは楽な仕事でもないし、稼げるとも限らないからです。
一方で、
前職でIT関連の仕事をしていたり、作りたい物やサービスがあって目指している人は比較的エンジニア転職を達成していました。
現実のエンジニア像をしっかりイメージ出来ているからこそ、理想と現実のギャップで折れることが少ないのだと思います。
仲間に助けられた
一人で学び続けたり、転職活動をするのは想像以上に難しいし、心が折れます。
私はTwitterやコミュニティで情報共有や切磋琢磨出来る仲間を作れたことが大きな支えになりました。
同じ様な状況の人と一緒に勉強し、時には励ましあったり、先輩エンジニアに実装や、転職についてのヒントをもらえたりする環境はとても大切です。
Twitterでのエンジニア転職の過程を発信していると、マサカリを投げられることもありましたが、それ以上に得るものは大きかったと思います。
差別化を意識した
当時はスクールの課題で作った「ECショップのクローン」がポートフォリオの定番でした。が、みんな同じようなものを出すので、評価する側は見飽きてしまう…。そんな時代でした。
- 成果物で差をつける
- 他の駆け出しがやらないような事をする
- 記述記事等で圧倒的なアウトプットの成果を残す
などの差別化が求められていました。
現在はAIにより、駆け出しレベルの実装能力はエンジニアで補える時代になってきているので、より差別化が重要視されていくと思います(もちろん基礎知識は必須ですが)
まとめ
- エンジニアを目指す理由が現実的だったこと
- 仲間に支えられたこと
- 少しでも差別化を意識したこと
この３つがエンジニアとしてキャリアを歩み始める上で重要なポイントだった様に思います。
当時は上手くいかない事も多くて不安でいっぱいでした。
仲間との繋がりがなければ今の自分はいなかったし、窮地を乗り越える過程で身につけた知識や振る舞いは後に活きています。
これからエンジニアを目指す方には、「一人で抱え込まず、仲間と交流しながら、自分なりの強みを見つけていくこと」をお勧めしたいです。
AIの台頭により環境が変わっても、この本質はきっと変わらないと思います。
記事が伸びている人の特徴を考えてみる
ブログ記事を書き始めてしばらく経ちある程度記事も増えてきたのですが、よく見られてPVが伸びる記事とあまり伸びない記事があります。
他に記事を書かれている人で、記事がバズって伸びている人や共感のコメントや反応が多い人はどの様な工夫をしているのだろう？と気になることが増えてきました。
単発でバズる記事を書かれる方や、継続して書いていて、しかも安定的に伸びている記事を書かれている方もいます。
今回は記事が伸びているなと感じる方々のブログや記事を参考にしながら伸びるブログの共通点を考えてみようと思います。
伸びている記事を書かれている方々
こにふぁーさん
自身の経験や会社などで起きた体験をまとめた記事をよく書かれている印象です。
雑記的なテーマでも読み手に「自分にも当てはまる」と思わせる共感ポイントが盛り込まれています。
あまり硬くなりすぎない文章の中に明日から実践できる小さなTipsが散りばめられていて、読みやすさと共感性が合わさりファンが増えやすいと感じました。
すてぃおさん
エンジニアや経営者向けに、自身の経験を踏まえたnoteを多く書かれています。
ニッチなテーマ（生成AI、開発組織の運営など）を深掘りしており、難しい内容でも図解や例え話で噛み砕いて説明しています。
現場でどう役立つかや、経営視点でどう判断すべきかといった具体的なところまで踏み込むことで、読者自身や組織に落とし込める状態まで情報が整理されています。
山さん
毎日noteを更新されているエンジニアの方です。
一記事一テーマで内容はエンジニアキャリアの中での気づきや、技術、キャリアについて自身の意見を述べています。毎日投稿ですが話題や切り口が都度変わり、サムネイルも統一感を持たせながらも毎回変えているので、読者を飽きさせない記事になっています。Xでの短い投稿の後に書いた記事を繋げているのをよく目にします。
共通点
有益な情報を提供している
読者にとって有益な情報や、自身が経験した出来事のプロセスを読みやすい様に丁寧にまとめています。
記事を読んだ人が学びを得たり、参考にしようと思える内容なので、拡散やリピートにつながっていると感じます。
ターゲットが明確
誰に向けて書いているかがはっきりしているのも特徴的です。
タイトルを読むだけでどの様な悩みを抱えている人に向けて書いているか分かるので、当てはまる人は読んでみようと思いますし、エンジニアだったり、マネージャー向けだったり対象者を絞った記事になっています。
書き続ける工夫や意味を自分の中で持っている
書きたいから書くというよりは、何のために書き続けるのかの目的が明確だと感じます。自身のブランディングのためだったり、思考の整理のためだったり理由を持っていると感じます。
計測している
読者の反応やPVなどを定期的に観測している記事を見かけたりします。
計測することで改善点を考慮しながら読まれる記事を分析してブラッシュアップしているからこそ伸びるのだと思います。
各自の特徴的なスタイルがある
文を読んでいると、〇〇さんっぽい言い回しだななどと思う時もあります。
特徴がある方が読んでくれるファンが付きやすいのかなと感じています。
情報が羅列されているだけの丁寧な文体はAIの出力と対して変わらないですからね。
これからはAIの出力した文章を読むことに疲れている人も増えてきそうなので、この辺りの差別化は重要になってきそうです。
まとめ
こうしてみると、伸びているブログには読者に役立つ情報と、継続の仕組み、ブランディングが共通しているように思います。
自分のブログでも、書きたいことを書くだけでなく
- 誰に読んで欲しいか
- 読んでくれた読者にどの様な情報が役立つか
- 自分のスタイルを確立させる
を意識して書けば読まれる記事に少し近づけそうです。
今後も試行錯誤しながら記事を書き続けていきたいと思います。
「説明が上手な人」と「下手な人」の差はどこにあるのか
説明のわかりやすさは人によってまるで違うと感じることがよくあります。
「この人の説明はいつもスッと頭に入ってくるな」
「うーん、最後まで聞いたけど結局何が言いたかったのかわからん...」
説明するという働きかけは同じなのに、この差は一体どこからくるのでしょうか？
自分の経験も踏まえて考えてみると、いくつかの要素浮かび上がってきたので書き出してみます。
前提から話し始める
説明が上手い人は、まず「前提」から話し始めてくれるんですよね。
「今回は〇〇の前提の上で話します」とか「これまでの事をおさらいすると〜」みたいな感じで。
これをしてくれると、聞いている側は「ああ、そういう前提の上での話ね」と頭が整理された状態で話を聞けます。
一度聞いたことがある内容でも、おさらいがあるだけで思い出しながら聞けるので安心できるんですよね。
逆に説明が下手な人はいきなり本題に入ってしまいがちです。
聴く側としては「どの話の続きだっけ？」と混乱しながら聴くことになります。
私も本題から急に入ってしまうことが多かったのですが、最近は前提やおさらいをまず最初に話してから本題に入る様に心がけています。
構造化により整理されている
説明が上手い人は、話の流れが整理されています。
いわゆる起承転結みたいな枠組みに沿って話が進んでいくので、聞いてる側は「今は背景の話だな」とか「次が結論だな」と予想ができるのでスッと理解ができるんです。
逆に説明が下手な人は話が行ったり来たりします。
途中で話が飛んで本筋とは別の補足説明を入れたり、時系列順に進まない事があります。
聞いてる側からすると、頭の中でパズルを組み立てる様にして理解する必要があるので結構しんどいです。
ちょうどいい情報量が計算されている
説明が上手い人は情報量をコントロールしながら会話を進めています。
説明が長すぎると情報の洪水を起こし、頭から流れていってしまいますし、短いと説明が足りずに理解できない事があります。
聞き手にとってちょうどいい情報量で設計することが重要です。
相手の反応を観察して調整している
これはめちゃくちゃ大事だと思うんですが、説明の上手い人は相手の表情や反応を見ながら話し方を変えています。
聞き手がポカーンとしてたらもう少し噛み砕いて説明しようとか、頷いていたら伝わっていると感じてそのまま説明を続けたり、退屈そうにしていたら説明を省略したり。
聞き手の状態を観察してその場でチューニングしているんですよね。
逆に説明が下手な人は、相手の目が虚になっていても気にせずひたすら自分のペースで話し続けます。聞いてる側としては何も頭に入っていない状態です...
まとめ
説明が上手い人の要素をまとめると次の4つです。
- 前提から話し始める
- 構造化により整理されている
- ちょうどいい情報量が計算されている
- 相手の反応を観察して調整している
要するに、相手が理解しやすいような設計で説明がされているかどうかです。
説明が下手な人は自分の話したいように話してしまい、上手な人は聞き手目線で説明しています。
1on1で意識していること
こんにちは、ITエンジニアのまさきちです。
最近出社日が増え、改めて対面コミュニケーションって大事だなと実感しております。
特にIT業界では定期的に上長との1on1を行い会社も多く、目標設定やキャリアの相談、普段できない話をする貴重な時間になっています。
ただ、せっかくの機会なのに上手く話せなかったり、時間を持て余してしまった、という経験がある方も多いのではないでしょうか？(私もそうでした)
今回は自分が失敗から学んで工夫してきた「1on1を有効に活用するためのTips」を紹介します。
何気ないコミュニケーションで関係性を築いておく
コミュニケーションを取るのが1on1の時のみだと、いざ話すとなった時に緊張してうまく話せないといった経験はありませんか？
上長と話す事に慣れれば自分の伝えたいことを伝えることが出来ます。
そのために普段から何気ないコミュニケーションを取っておくと良いでしょう。
出社時にすれ違った時に挨拶をしたり、積極的に話しかけて雑談をすると会話をすることに慣れるのでおすすめです。
事前に話したいことを整理しておく
1on1の機会と時間は限られているので、最大限有効に活用するために話したいことの整理をしておくのが望ましいです。
特にテーマのない定期的な1on1では、何を話そうか決まっていないとせっかく時間を取ってもらっても話すことがなくてすぐ終わってしまったり、世間話や雑談だけで終わってしまうので勿体ないです。
普段から上司に聞きたいことや、仕事での悩み、相談したいことをメモしておき、1on1前に整理しておくと有意義な時間を過ごせます。
目標設定や評価の時に1on1を組むことも多いと思いますが、目標設定はできるだけ細かく具体的に書いた方が評価する側も進捗を管理しやすいですし、評価される側も向かう方向性の確認や、上司からのフィードバックをもらいやすいので効率が良いです。
雑談からスタート
初手から本題に入るよりも、最初にアイスブレイクとして雑談から入る事をお勧めします。
始まりにたわいもない会話をすることで緊張がほぐれてお互いに本題が話しやすくなるからです。
過去の自分はいきなり本題から切り出す事も多かったのですが、自分の伝えたいことを思ったように話せなかったり、形式的なやり取りになってしまい、その後会話が弾まず不完全燃焼で終わってしまうこともありました。
アイスブレイクを取り入れて対話する準備時間を取った事で、自然と会話ができる様になりました。
お気持ちをやんわり表明する
1on1の場では、業務のことだったり、今後のキャリアの事だったり話題は様々ですが、普段よりも一歩踏み込んだ話ができる貴重な時間だと思っています。
その時に普段自分が考えている事だったり、思っていること、やっていきたい事をやんわりでも伝えると良いです。自分の中で思っているだけでは相手に伝わらないからです。
わざわざ1on1の時に言わなくても伝わっているだろうと思う事もあるかもしれませんが、自分の思っているより、自分の事は相手に伝わっていないです。
上司が自分のことを分かってくれないと感じている方は、事あるごとに自分の気持ちやスタンスを伝えましょう。
-----------------
以上になります。
最後まで読んでいただきありがとうございました。
