エンジニアとは

Transcript

1. エンジニアとは
2. 会社に入る前のエンジニアの認識 • エンジニア＝黙々と一人でコードを書く人 2
3. 会社に入る前のエンジニアの認識 • エンジニア＝黙々と一人でコードを書く人 3
4. 会社に入る前のエンジニアの認識 エンジニアの本質的な仕事は 「問題を解決すること」 コードを書くのは、その手段の一つにすぎない 4
5. 会社に入る前のエンジニアの認識 • エンジニア＝黙々と一人でコードを書く人 • エンジニアの本質的な仕事は「問題を解決すること」コードを書くのは、その手段の一つにすぎな い • エンジニアの仕事とは o システム全体を理解し、活用方法を考える o チームと連携・コミュニケーションを大切にする o 問題を見つけ、改善を繰り返す o 技術やツールのトレンドを学び続ける o 価値を生み出す 5
6. できるエンジニアとは • 課題を自ら見つけ、解決に導ける • チームと協力して成果を出せる • 適切なコミュニケーションで信頼を築ける • 自分の担当と影響範囲を理解し、責任を持てる • スキルだけでなく「姿勢と行動」が評価される 6
7. できるエンジニアを想像できるか （市場価値） • 「言語やフレームワークを使えます」だけでは弱い • 大事なのは、どんな課題を解決し、どんな価値を生み出したか • 裁量のある仕事や主体的な貢献ができるかどうかが評価される • 「◦◦ができます」ではなく、「◦◦を使って何を成し遂げた か」 • スキルそのものよりも、スキルで何を生んだかが市場価値を決 める • 一緒に働く姿を想像できるエンジニアが強い 7
8. 成長とは • 成長には振り返りが欠かせない • 「やったことは最適だったか？ 他に良い方法は？」と考える • ときには「この進め方、逆に失敗しそう…？」と疑う視点も必 要 • フィードバックは待つだけでは得られない • 自分から聞きに行く姿勢が大事 • PRにコメントがない時でも、「もっと良いやり方あるかも？」 と考える習慣を持とう • 「受け身」ではなく、自分から学びにいく姿勢が成長を加速さ せる。 8
9. わからないままはダメ • 「わからない」は素直に認め、早めに質問することが信頼につ ながる • わからないことをそのままにする人（わかったふり）は「嘘を つく人」と同じくらい危険。信用を失う • ミーティングで内容が理解できないときは、その場で質問 or そ の場で調べる or 直後に確認を • 質問はマイナス評価ではなく、プラス評価になる • わからない”は成長の出発点。黙るより、聞くほうが信頼され る。 9
10. その不安、本当に気にするべき？ • 「聞いていいのかな？」と思ったら、聞いていいサイン • 自分には大ごと”でも、他人から見れば大したことないかもしれない • 自分の視点だけで考えすぎると、行動に移せなくなることがある • 実際は、「そんなに気にしなくていいのに」というケースがほとんど • 一度、自分を俯瞰して見る習慣を持とう • たとえば「先生と生徒」に置き換えるとわかりやすい： o 生徒：聞いていいのかな？迷惑じゃないかな？と悩む o 先生：「そんなの聞いてくれればいいのに」 • わからないことを放置されたり、嘘をつかれたりする方がずっと困る • 自分の視点に囚われず、客観的に見る癖をつけよう • “気にしすぎ”を疑ってみるのも、行動力の一部。 10
11. 1日一歩成長する意識を • 日進月歩とかあるが、１日１歩くらいできる • 毎日課題や、不明点をきちんと認識し、それの改善法や学ぶこ とを繰り返す • そのアプローチのやり方を自身にどんどん貯めていく • 「前に似たケースがあったな」と気づけると、対応が速くなる • 他の人の作業や改善も意識することで、学びの幅が広がる • 自分の経験＋他者の経験＝加速する成長 • 昨日より今日、今日より明日。1日1歩でも成長できれば、それ は確実な前進。 11
12. アピールしよう（成果は見せてなんぼ • 「伝えなければ、存在しないのと同じ。」成果は見せて初めて 評価される。 • フルリモートでは特に見えづらく、誤解されやすい • アピールがないと「何してるか分からない」と思われてしまう • アピール＝信頼構築の手段。自分を守ることにもつながる • 進捗が出ない時ほど、進捗や背景を伝えることが重要に。頑 張っているのに、何もしてないという評価になるのは勿体無い • 報告は信用、可視化は武器。アピールは誠実さの表れ。 12
13. なんでも即時対応 • 優先度は色々あるが、小さいタスクほど速攻で片付けよう • 即時対応すると、頼れる存在と認識されやすい。 oまたこの人に頼みたい。のような • 小さいタスクを抱えると、常に気になって集中できない • 小さいタスクは小さいからすぐ片付けられる • すぐやってくれる人は貴重、簡単なのに信頼・評価・チャンスを 得やすい 13
14. 他の人の動きを把握する • 他の人が何をしているかを知ることで、システム全体の理解が深まる • 他の人の進行状況を知っていれば、適切な人に質問・相談ができる • 「この前〇〇やってたよね？」という情報が、意外な場面で役に立つ • 自分のタスクに直接関係なくても、関心を持つことがチーム力につながる • 他者の動きに目を向けることで、視野が広がり、成長のヒントが得られる。 見渡す力も身につけよう 14
15. 表面的ではなく背景を理解して解決せよ • 言われたまま修正しても、問題の本質が解決できるとは限らな い • なぜその issue が起きたのか？ 背景を理解することが大切 • 背景を知れば、目的に合った、的確な対応ができる • 「この解決法は本当に適切なのか？」と疑問を持つ姿勢も必要 • ときには、issue 自体が的外れな可能性もあると考えよう • 必要に応じて関係者と意図をすり合わせる行動も忘れずに • 問題の原因ではなく“症状”だけを直していませんか？ 15
16. 担当箇所を見極めよう （本当に修正すべきなのはどこなのか？） • 指摘された内容が、自分のプロジェクトや担当範囲に属していると は限らない • 実は、別のチーム・プロジェクト・システム側の対応が正しいケー スもある • 無理にこちらで修正すると、責任があいまいになったり、逆に不整 合を生むことがある • 「一見こちらの問題に見えるが、本当にそうか？」というスコープ の見極めが重要 • 必要なら、範囲の切り分けや関係者への確認を行う習慣を持とう • 「とりあえずこっちで直しておく」は、将来的な負債になり得る 16
17. 「やる」と「やらない」を判断できるように • 実はやらなくていいことは意外と多い • タスクも「本当に必要か？」「削れないか？」を考えるクセを つけよう • “やらない判断”は、プロジェクトを守る判断でもある • システムの構造や優先順位を理解してるこそ、削る判断ができ る • 削る力こそ、プロジェクトを健全に保つ技術。価値のある選択 を • “やる”より、“やらない判断”がプロの仕事 17
18. 裁量をとりに行こう（チャンスを掴め） • 今の仕事に満足して止まっていては成長できない • 裁量は「振られるもの」でもあるが、「取りに行くもの」でもある • やれることをどんどん広げることで、自分の市場価値も上がる • ただし、勝手に導入を始めるのはNG。報連相は必須 • 属人化はリスク。チーム全体で触れる状態を意識しよう • 「ワクワクする」「興味ある」レベルの動機で十分。みんな最初は 未経験 • この人なら大丈夫そう。みたいな与信は必要 • 挑戦が、成長と裁量を引き寄せる。 18
19. 与信を確保する • 与信とは、「この人なら任せても大丈夫そう」と思われる信頼 感のこと • どうやって得るか o 成果を出せる人（タスク処理や速度だけでなく、価値を生む人） o できない・わからないことを正直に伝えられる誠実な人 o 状況を理解して、自律的に行動できる人 o困ったときに状況を共有し、相談できる人 ▪ 一人で抱え込むと、周囲は不安になり、次の依頼をためらうことも • → 「負荷をかけたくない」と思われ、チャンスが遠ざかる o 信頼は、コードの外側で築かれる。、安心して任せられることも強さ 19
20. テストやCIは、“信頼されるコード”を書くために必要な 習慣 • テストやCIは、「壊れないようにする」ためではなく、 • 「壊れてもすぐに気づける」ためにある • 自分も、他人も、意図せず壊すことはある。だから守る仕組みが必要 • テストがあることで、安心して変更し、進化させられる • 感覚がつかめないうちは、テストは多めでもいい。やりながら身につく • 「このコードはこう動くべき」という自分の意思表示でもある • AIも仕様を誤認・勝手に変える時代だからこそ、検証手段としてのテスト は欠かせない • テストが落ちたらNG。でも仕様が変わったなら、テストを変えるのも正 しい判断 • CIとテストがあってこそ、安心して挑戦できる。 20
21. 効率のカギは、“道具の使い方”にある • 初学者のうちは、ツールの最低限の機能で使いがち • でも実は、ちょっとした理解で何倍も効率よく使えるものが多 い • 気づかないまま時間をムダにしていても、自分では気づけない ことがほとんど • エディタ：ショートカットや拡張機能で、コーディングが数倍に • ターミナル：補完・履歴検索・git情報表示で、操作がぐっと快適に • 知らないまま使い続けるのは、時間を捨ててるのと同じ。効率 の差は、気づきの差。 21
22. アップデートしない自分は、古くなる • 閉じた環境では、得られる情報に限界がある oオフィスやプロジェクトの中だけでは、技術やトレンドの変化に気づ けない o情報収集は、一度やればいいものではなく、継続する習慣 o 現状維持＝価値が下がっていく時代 → 学びを止めれば、気づかぬうちに置いていかれる • まるで「弥生時代の日本」と「戦国時代の中国」のように o 日本が農耕を始めた頃、中国では鉄器・戦術・国家統治が進化してい た o 同じ時間を過ごしていても、情報の差で“時代の差”がつく 22
24. アップデートしない自分は、古くなる • 閉じた環境では、得られる情報に限界がある o オフィスやプロジェクトの中だけでは、技術やトレンドの変化に気づけない o 情報収集は、一度やればいいものではなく、継続する習慣 o 現状維持＝価値が下がっていく時代 → 学びを止めれば、気づかぬうちに置いていかれる • まるで「弥生時代の日本」と「戦国時代の中国」のように o 日本が農耕を始めた頃、中国では鉄器・戦術・国家統治が進化していた o 同じ時間を過ごしていても、情報の差で“時代の差”がつく • 情報をキャッチする方法 o SNS：エンジニア界隈の動き o 外部のエンジニアと話す / 登壇を聞く：リアルな現場の知見 o npm trends：ライブラリの人気・流行 o Googleトレンド：話題の移り変わり o GitHub：スター数、issue、更新頻度から活発度を確認 • トレンド＝すぐ使う必要はない • 業務では枯れた技術が基本。でも「選べる判断軸」は持っておくべき。 • 情報の差は、行動の差。拾う人だけが先に進める。 24
25. 相手の言葉をそのまま受け取るな • 表面的な要望＝本当に必要なこと、とは限らない • 相手の発言は、理想やイメージの断片にすぎないことが多い • 希望通りに作っても、目的や前提とズレて失敗するケースは珍しくない • 大切なのは、ヒアリングを通じて“本音”や“本質的なゴール”を引き出すこと • 例：夢の庭 vs 現実 o 「草木のある素敵な庭にしたい」でも実際には… • 虫が嫌いで窓が開けられない • 雑草の手入れが追いつかず、放置されてしまう • 結果、理想だったはずの庭がストレスの原因に o → “夢”を叶えるつもりが、現実は“失敗”になるケースもある • 大事なのは、「本当に必要なものは何か？」を一緒に考えること • ときには「それはやめた方がいいかもしれません」と提案を返す勇気も必要 • ただし、否定するだけでなく、なぜそう考えるかの背景を丁寧に伝える • 正しく聞いて、正しく疑う。それが本当の信頼につながる。 25
27. 常に課題を感じ、改善する意識を • タスクをこなすだけでは、成長も価値も生まれない • 「なんか使いづらい」「このコード、読みにくい」 o その“違和感”を放置せず、改善につなげることが重要 o自分や他人が使っていてつらいと感じる部分は、すでに課題のサイン o「過去の歴史があるから…」「誰かが作ったから仕方ない」 → そんな遠慮はいらない o改善のタイミングも“戦略的”に o 改善が早すぎると、逆に効率を下げるリスクもある ▪ ベストな改善方法が見えるまで、一時的に“負債”を許容する判断もアリ o 重要なのは、「現状を正しく認識した上で、いつどこから手をつけるか」を考えること • 課題に気づける人だけが、価値を積み上げられる。 27
28. ミスっても死なない。やり直しは成長の証 • かならず“正解”を選べなくてもいい • 最初から完璧な選択なんて、ほとんどできない • やってみないと分からないことのほうが圧倒的に多い • 実行して、失敗したと感じたら また挑戦するだけ o 「失敗しない」は重要じゃない o 「失敗から立て直せる」が、ずっと大事 o 失敗したら、「なぜうまくいかなかったか」がわかる o 失敗から得られる経験は大きい • 気づきと改善があるなら、それはすでに前進 • 失敗を恐れて止まるほうが、成長の機会を逃している • チームやシステムは、試行錯誤が前提で作られている • だからこそ、まずは動いてみることが求められる 28
29. 発想力と想像力を鍛える • 発想力・想像力は、エンジニアにとって重要な武器 • タスクを受けたときに「どんな改修が必要か」「どこに影響が出るか」を考えら れる力 • 解決の方法は一つではない。最適な手段を選べるかどうかが問われる • 発想力は経験と好奇心で鍛えられる • 普段使っているサービスや仕組みに「どう作ってるのか？」と興味を持つだけで も十分 • 日常のモノやアプリを「自分ならどう設計するか」と考えるクセをつける • 知識も発想の材料になる • 書籍・ブログ・他人のコードを通じて、引き出しを増やしておこう • 実際に使わなくても「こういうやり方もある」と知っているだけで強みになる • 考えるクセが、引き出しを増やす。 29
30. 文化は作る物。変える物 • 組織の文化は「与えられるもの」ではなく、「自分たちでつくるも の」 • 技術的な成果だけでなく、働き方や関わり方も文化を形づくる • 一人の行動・言葉・姿勢が、文化を変えるきっかけになる • 現状を鵜呑みにしないことが大切 o 「なんとなく続いていること」こそ、見直す価値がある o 不要な習慣や空気に気づけることが、最初の一歩 • より良い文化は、より良いチーム・環境を生み出す o 声を上げることが組織の改善につながる o 誰かの勇気が、全体を動かすこともある • 文化は、誰かじゃなく“自分たち”が作る。 30
31. 自分の現在を自覚する 自分のエンジニアとしての現在地を把握しよう 今できること、これからできるようにすべきことを見つめよう 能力が低い人ほど、自分を高く見積もりがちだ 経験が浅ければ、自分のレベルすら正しく測れない だからこそ、“自分を疑う視点”を持つ者が、成長を加速させる 視野を広げ、知識を深め、自分を見つめて、成長のその先へ進 もう 31
32. 32 転載元：https://biz.moneyforward.com/payroll/basic/63123/
33. おしまい 33