日々の雑記

〜エンジニア(弱・悪)がエンジニア(強・善)になるまでの軌跡〜

Developers Summit 2019に行った感想

11/30に↓のイベントに行ってきました!振り返りも兼ねて感想書いてみたいと思います。 event.shoeisha.jp

全体を通した感想

今回のイベントテーマは「これが私の戦い方」でした!
筆者は技術的な内容よりよりキャリアと言ったエモいセッションを中心に聞きました。
共感できる内容や実践するための方法などすごく参考になる話ばかりで幸せな時間で、セッションを通して自身の戦い方を考える良い機会になりました!
登壇者の方・運営の方ありがとうございます!

⏬セッションの中で紹介された本です。要チェックです👀

イベントに参加して考えたこと

自分の中で腑に落ちた戦い方としては「ユーザーのことを考えて課題を解決する」です。

技術よりも人に対して価値を提供することに重みを置こうと考えています。
ぶっちゃけ筆者はプログラミングはすごく得意ではありません。やりたいし興味もあるけど、すごく興味がある...!と言われると自信は無いです。 (技術力が無いのにエンジニアとしてどうしよう...と思っていた部分もあったり)
でもモノづくりは好きだし、課題を解決して人に価値を出すことに対して、すごくやりがいを感じますし何より楽しいです。
もちろん技術を軽視するつもりはありません。価値を提供するにも技術力は絶対に必要です。
なのでしばらくは「ユーザーのことを考えて課題を解決する」ために技術力を中心に成長していきます!

セッション別の感想

全部書くと時間もかかるので、箇条書きにして筆者が印象に残ったことを簡単に書き連ねます。(ちょっと書きすぎたかもしれない)

C-1 オープンな技術力の伸ばし方

  • オープンソースソフトウェアの醍醐味はオープンであること。書き方を学ぶことなど出来る
  • 技術力が高いだけではなく、組織の力にスケールさせる働き方が求められる
  • 登壇・運営をすることで話しかけてもらえる状態にする
  • 履歴書・ポートフォリオは転職関係なく作っておくべき

B-3 20代でマネジメントにチャレンジするということ

  • マネジメント=組織をエンジニアリングする
  • FBしやすい若いうちにマネジメントをやると、いっぱい失敗できる
  • 全体最適(会社都合)を考えるようになる。会社側の人間として批判されることを覚悟しておく
  • 課題を解決しても辞める人は辞める。組織の持続性を考える。
  • 優しいだけだと組織を腐らせてしまう
  • 変化を起こせた時、一人ひとりが成長しているのを感じた時が楽しい
  • 組織の課題は対話で乗り越える。本音を見出していく

C-4 システムリニューアルをやってみた

  • システムリニューアルの方針
    • ビッグバンリリース
    • 見積もり期間:3ヶ月
  • 実際には
    • 4ヶ月たっても進捗は5割
    • 歴史的背景から対応した特例コード対応。リバースエンジニアリング
    • 計画見直し。技術的負債は後で回収する方針に
  • 振り返って
    • 自動化、ドキュメント整備に成功。
    • 最終的には7ヶ月の開発期間。
    • 大きな不具合はなかった。
    • 計画の見直しが遅かった。技術的負債は今も全て回収できていない。
      • 見積もり用の期間を1ヶ月とったらちがっていたかも

A-5 打算的エンジニアの成長戦略 ~人より得意な部分で勝負する!~

  • 打算的=損失を最小化いして利益を最大化する
  • 得意にこだわって転職した
    • 得意を活かせる場所
    • 得意を伸ばせる
    • 得意を増やせる
      • あえて募集が具体的すぎないところの方が挑戦できそうと思った
  • 転職すると実績、信頼はリセットされる
    • 早く実績を作る必要がある
      • チームの価値観を把握し何を重要視しているかを知る
      • 他の人ができない/しないことを狙う
      • それを自分の経験で活かせることはないか検討する

B-6 CloudNativeな監視とは? 今日から始める監視

かめとねことペンギンで三竦みなのかな

  • 今回はマイクロサービスに重みを持つ
  • 従来はWeb3層アーキテクチャ。各コンポーネントを追うことでオペレーションしやすかった。
  • 今はマイクロサービス。複雑化してオペレーションしづらい。全てのコンポーネントを追うのは現実的ではない。
  • 可観測性(Observability)を向上する
    • モニタリング
    • アナリティクス

今までのモニタリングは想定された障害に対するアラート。 分散システムでは障害が発生するのか予測することが不可能。再現性も不明確。 後からデバッグできるように全てのコンポーネントを観測する。 これらを観測するのが可観測性。

  • elemetry
    • 可観測性を実現するツールに求められる要素
      1. Logging コンポーネントに対するイベントを記録。ex)grafana loki
      2. metrics 定量的に数値として計測。
      3. tracing リクエストに対するイベント。 ex) jaeger
    • 課題
      • telemetry全部をデバッグするソリューションが存在しない
        • 時間で見るしかない
      • 構築運用コストが高い

A-7 新卒一年目でサーバーサイド開発あるあるを踏み抜いてきた話

  • 闇深
  • 教訓
    • 単体テストを書くこと
      • 初めは工数がかかるかもしれないが、負債とならず運用が簡単
    • テストとドキュメントを整備して退職すること

A-9 プロダクトオーナーシップのすゝめ。

  • 自分たちで考えプロダクトを設計した経験がない中で、3年目で新規機能を担当
  • チーム内で違う視点で話している
    • 何を作る、どう実現、どうやって作る
  • 視点を揃えるためにデザイン思考を実践
    • ユーザーの本当の課題を発見する
    • プロトタイピングのワークショップ
      • 物事を視覚化して、議論が発散しない/偏らないようになる
  • プロダクトオーナーシップ
    • 何を作るかを明確化した
    • 課題を解決してユーザにつかってもらうこと
  • ユーザーの体験をよりよくすることを考え続けること。また、それを楽しむこと。

A-10 エンジニア×〇〇 ~職種を「越境」して希少性を出すキャリア~

  • アイスブレイクとしてストレッチからスタート
  • 命題:技術にもマネジメントにも尖った強みがない人はエンジニアとして活躍できないのか?
  • エンジニアの典型的キャリアパス
    • 技術かマネジメントどちらに進むか
  • なぜ希少性がでた理由
    • 最低限のエンジニアスキル
    • 人にわかりやすく伝えるスキル
    • クライアントとのコミュニケーションが苦じゃない
  • エンジニアリングのスキルを持ったまま別の職種に手を出すと希少価値が出てくる
    • 事業上の価値を出せていれば技術力やマネジメントスキルがなくとも評価される
  • エンジニア×○○
    • 職種を掛け合わすことで希少性が出せる
  • エンジニアリングの民主化が広がっている
    • エンジニアリング=不確実性の高い状態から、低い状態に効率よく移すその過程で行う全てのこと。*1
    • プロダクト開発以外でも不確実性が大きくなってきた
    • 課題をテクノロジーで解決するためのコストが低くなった
  • 新しい役割を切り開く方法
    • ベンチャーに飛び込んで手を上げる
    • ITベンダーに入ってから事業会社に転職する

懇親会

ただの懇親会なく、"交流をBoostする"ワークショップがありました!
内容は簡単で、近くの人とグループを作ってイベントを振り返って自分の意見を簡単に発表するというもの。

自分の意見を2回話す機会があることで、1回目より2回目の方がうまく話せることができました。 つまるところ、改善とアウトプットすることで考えをより自分に落としこむことができました。
一人だとやらないので、強制力が働くアウトプットもいいものです。

*1:エンジアリング組織論への招待より