1. はじめに
こんにちは。PortalKey のしゃりです。
私はエンジニア未経験から独学でアプリを作り、弊社に転職して1年が経ちました。
そんな私の目下の不安は、将来が見えにくいということです。自分に似たモデルケースがあまりなく、自社のエンジニアは学生時代からのエンジニアです。少なからず見つけていたモデルケースも、AI の進歩が凄まじいことから宛にもならなくなってきました。
そんな中、Developers Summit 2025に参加してみたら、何をすべきかのヒントが得られた気がするので共有します。
2. 参加したセッション
特に話がおもしろく、さらにヒントだと思ったセッションを２つ紹介します。
1つ目はエンジニアとしての価値を上げる(AI時代でも維持する)方法です。
2つ目は企業の課題を解決した(している)実践談です。
2.1. 「AI 時代にも変わらぬ価値を発揮したい、インフラ・クラウドを切り口にユーザー価値と非機能案件に向き合ってエンジニアとしての地力を培う」(XTech5 社様)
1つ目、エンジニアとしての価値を上げる方法についてです。
ユーザー価値の 2 つの要素：有用性と保証
ユーザーの感じる価値は有用性と保証の２つだと紹介していました。
有用性とは機能要件であり、決定打ではない上にAIができるようになってきている部分とのことです。
つまり、率先して身に着けていくべきは保証能力です。
では、保証能力とはなんでしょう？
保証能力とは、信頼性、可用性、キャパシティ、パフォーマンス、セキュリティ、持続性のことであり、非機能要件に当たるとのこと。
これら保証能力を上げるための具体的なものが、………単語を聞き逃しました。
( ；∀；)ｽﾐﾏｾﾝ
設計力と言っていたような気もします…。
ただ、大雑把に言えば技術力は必要で、それは論理的判断(=知識)と、倫理的判断=(価値の認識)の両方から成っているということでした。
両方重要ではあるが、「価値の認識 = 誰にとって何がどのくらい重要か」であり、それは局所性が高く難易度が高めということでした。
例：課題解決のコストが同じでも、経済状況等で実行するかどうか変わる。
大企業ならやれるけど、小企業なら見送りがち。
登壇者はこれを1円の価値が企業で違うと表現していました。
また、登壇者の考えでは「エンジニアの持つべき責任は AI 時代でも変わらない」とのことでした。
その責任とは、説明責任、ユーザー、社会、未来に対する責任、倫理観を指すそうです。
地力の獲得方法
以上で紹介した、獲得が難しい 保証能力 = 価値の認識 をチームで獲得させる方法について書き起こします。
「平たく言うと、根性と執念」で獲得できるそうですが、
分類すると「場数を踏む、データと向き合って深く思考する、対話する、継続する」の4つとのことです。
考えられる手段としては3つあり、最良は定点観測会だそうです。
- 独学
- OffJT
- OJT で定点観測会：場数 ◎、思考 ◎、対話 ◎、継続 □
定点観測会
定点観測のパターンについては写真に任せますが、OODAで取り組むのが良いとのことでした。
ターンを早く回す。他人が1ターンやる間に自分達は3ターン回すとのことです。
また、大事なのはチーム内の価値観や経験の共有であり、技術的な深堀は別途設けた方が良いそうです。
 |
 |
 |
 |
OffJT
OffJT についてもちょこっと紹介
OffJT の一環としての読書会は「ぶっちゃけ AI に要約させて良い」とのことでした。
知識獲得よりも対話と議論を沢山やるべきだそうです。
(読書による知識獲得なら独学で十分だから？)
読書会というものをしたことがなかったのもあり、この視点は驚きでした。
登壇者の著作紹介 ↓ こちらは無料配布
2.2. DMM を支える決済基盤 技術的負債にどう立ち向かうか(DMM 社様)
2 つ目は、企業の課題を解決している実践談の紹介です。
これは、特化した武器を持つ新参者が結果を出すためのノウハウにも取れました。
つまり「企業が抱える課題を解決できるという価値を見出してもらった話」だと思っています。
前置き
駆け出しの私には課題の難解さが想像もつかないレベルでした。
-
決済基盤
10年以上のコード、決済手段の多さ、サービスの多さ、言語の多さ…
→ 技術的負債が多い -
登壇者：入社9か月前後
-
目標：3~5年を目途に負債解消
登壇者の取り組み方
登壇者の取り組み方として驚いたことが２つあります。
- 最初の3か月を1人でやっていた
3か月間もかけて現状の把握(と信頼関係の構築)をやっていたということでした。
その間に周囲を巻き込み、信頼を勝ち取っていったのだろうということは想像に難くありません。同時に、如何に組織と負債が大きいかも物語っていますね。 - 初期段階で既存コードを詳細に読まない
既存コードに価値は無いと考えていたそうです。僕なら人に聞きに行く前に可能な限り読み込んでしまいそうですが逆なんですね。確かに、既存の課題は既存メンバーから聞き取った方が早く全体像を掴める気がします。
- 時期別
- 2024年10月～： 大枠については一人で推進
- 情報収集
- 既存コードに価値は無いと考え、この時点では詳細に読まない
- 構造に着目し、to-beを考えていた
- たくさんの方々の協力は得ている
- 壁打ち、情報収集、意見交換、フィードバックなどなど
- 情報収集
- 2025年01月～： チームを立ち上げるべく人員の募集
- 既存チームの横に小さなチームを立ち上げる
- デファクトとなるモジュールを小さなチームで立ち上げる
- two pizza team より小さいチーム
- 今後: Enabling Team
- オーバーエンジニアリングになっていないか確認。運用できるのか？
- 2024年10月～： 大枠については一人で推進
- 考え方
- 非エンジニアへの伝え方
組織能力の向上が目的であることを説明
(技術的負債の変換は市場価値を高めない) - 都度、期待値とゴールを言語化
言語化の粒度はその時に必要なレベルまで - チーム
two pizza team：チームは個人の凸凹が組み合わさるのが大事
ダイナミックリチーミングへ挑戦する
AIの発展によってより柔軟なチームの構造を模索中
(AIがバディ化したことで個人の凹凸が丸くなったため)
- 非エンジニアへの伝え方
3. ブースでの交流
とある企業ブースの担当者のお話も興味深かったです。
私のように未経験から業界入りしたものの数年目(ぼかし)の今となっては何でもやるし、同日にあった React Tokyo で登壇するなんて話をしていただきました。
何をしていたらそこまで成長できたか質問したところ、興味を持ったことをとことんやってきた様子でした。
業務経験とその時の技術スタックを列挙してもらいましたが、技術の幅も数もありフルスタックの中でも色々やってきたんじゃないか？という印象でした。
モデルケースという意味では、一番参考にすべき人かもしれません。
4. おわりに
4.1. 得られたヒント
技術的には、機能要件の実装はできて当然で、付加価値を付けるために対話と議論も必要。そして、巻き込む力が決定的な強みになりそうな印象でした。IT業界に入って、やや特殊な業界だと思っていましたが、仕事で大事なことはどの業界でも共通なようにも感じました。
また、その時やることや興味を持ったことに取り組むべきという、ある種当たり前のことを大事にしていればちゃんと成長できることが分かりました。
自分は作りたいものができる→技術を探すという流れで何かやることが多いので、興味に取り組むために作りたいものをじゃんじゃん作っていこうとも思いました。
(最近だと、GASで麻雀点数計算&集計ツールや、AWS API gatewayとLambda, Go, shellでマイクラマルチサーバーの起動/停止 discord botを作りました。)
また、他の講演も含めて、組織作りや組織として個人を成長させる方法が度々紹介されていました。
それら１つ１つに「弊社でやってるのこれじゃね？」と思うことが多かったのはちょっと嬉しかったです。
4.2. 感想
イベント参加は直前までは怖かったのですが、楽しく参加し、得られるものもありました。
どのセッションも聞きやすかったですし、ブースは16個回りましたが大体歓迎していただきました。
次は技術中心のイベントにも参加してみたいです。
(名古屋県にはあまりないんですよね…。)
準備について
１点だけ準備不足を痛感したのでメモ。
普段通りのPCの使い方で臨んだら一瞬でバッテリーが切れてしまいました。
次回は不要アプリやWi-Fi、Bluetoothはスタートアップから外して停止にしておく、VScodeでメモを取るにしてもWSLは使わない等して準備を入念にしたいです。
Discussion