Developers Summit 2021での学習事項

# はじめに
本記事は[こちら](https://event.shoeisha.jp/devsumi/20210218)のDevelopers Summit2021でセッションを聴講した際の学習事項をまとめることを目的としています。

# 聴講セッション
- 18-C-1 「スピード」と「品質」のスイッチング ～事業成長を支える生存戦略～
- 18-B-9 若手エンジニアの登竜門「Developers Boost 2020」優秀セッション再演！～U30エンジニアのための生存戦略とは？～
- 19-A-1 エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング/リアーキテクティング/リプレイス

# 学習事項
各セッションごとに学習事項を記載します。

## 18-C-1 「スピード」と「品質の」スイッチング~事業成長を支える生存戦略~

- フェーズを分けてスピード+品質を確保
- スピード重視、品質重視の業務を切り分ける
- スピード重視の業務
    - QRコード決済においての配送業務はスピード重視と捉える
    - NoCodeで配送業務の状況を可視化
    - 可視化したデータをもとに改善を図る(QRコード決済時の審査用資料の送付を早くするetc)
    - 店側が決済用QRコードを掲載したかは収集できない→配送数で代替
    - 上記の配送数をもとにツールを使って手間をかけずに収集+可視化
    - システム開発をあえてしないことで品質を重視しない業務のスピードを上げる
- 品質重視へのスイッチング
    - 形成期、混乱期から統一期に移るタイミングで品質重視にスイッチする必要がある
    - 配送業務における新規利用店舗割り出し作業を自動化
        - 理由は事業が大きくなるにつれ手作業によるミスが増えるため
    - 配送業務で必要な機能が増えており、その機能に応じて複雑な処理を手作業でする必要があり、さらにヒューマンエラーが増える
        - 処理が複雑になり、メンテが難しくなる。そしてミスのリスクが増える。ミスがないように運用でカバーする。さらに処理が複雑になるのスパイラルになってしまう
    - トラブルが増える一方で要求は高度化していく。つまりどんどんトラブルが増え、要求に応えられなくなってくる。→これがツール活用の限界
    - 再配送を含めて配送すべきリストが自動で生成されるシステムを開発→システムを評価することでリスク管理が可能になる
    - システム上のビジネスロジックを変更することで要求に応えて機能拡張することが容易に
    - 4カ月程度でシステムを開発し、従来の手作業の配送作業からスイッチ
- 事業の立ち上げフェーズから成長フェーズに移行する中のどのタイミングでシステムを用いた業務形態に移行するかが重要
    - ニーズ + リスク >= 開発リソースで考える
    - 事業成長にしたがって、ニーズが増え、ニーズに応える中でリスクも増える
    - 理想はニーズ + リスク = 開発リソースのタイミングでスイッチ
    - リスクは可視化しないと見えないため、リスクを可視化して考えることが重要
- リスクの言語化
    - 例：インパクト、リカバリ、コントロール、モニタリング
    - インパクト：問題発生時の影響の大きさ
    - リカバリ：問題の復旧が可能か
    - コントロール：制御が可能か。他の業者が絡む場合は制御できないことも多い
    - モニタリング：問題を検知可能か

### 所感
- 前提として品質が最重視されていない業務についてその業務をシステム化するかどうかの判断基準をニーズ+リスク>=開発リソースとするのはその通りであるなと感じた

## 18-B-9 若手エンジニアの登竜門「Developers Boost 2020」優秀セッション再演！～U30エンジニアのための生存戦略とは？～

### セクション①
- 好きなことを見つけ、インプット&アウトプットを繰り返すことで好きなことで世間的に認められるように
- Being(ありたい姿)を言語化
    - 自分の軸、行動指針になるため具体的であればあるほどGood
    - 判断がぶれなくなり、フィードバックが明確に、そして協力者が集う
- とにかくやってみる
    - トライすることでBeingを探す。
- スキルの棚卸
    - 現状を理解することが大切
    - スタート地点とゴール地点を考えるためには棚卸が必須
- 提供できる価値を明確化する
    - 成果が求められる
    - 自身の存在価値を明確にしないと相手にされない
- 完璧なロールモデル探しをやめる
    - ロールにとらわれず柔軟にスキルを学ぶことが重要
    - トレンドはすぐに変わるため完璧ロールモデルは探さない。
    - その時にあったスキル習得を意識する
- 攻めのアウトプット
    - アウトプットで認められ、やりたいことができるように
    - アウトプットをすれば、見てくれている人が必ずいる。継続が非常に大事
- 技術コミュニティを活用しまくる
    - 社内ではなく世間でのレベルを知れる
    - 発表内容は間違っていてもよいので、コミュニティでは強気で発信することが大事
- 断るという選択肢を持つ
    - やりたい仕事があるならアウトプットをし、一つの技術を極める
- Give&Take
    - 相手に対してのメリットを明確にする。これを持って交渉する
- 自分の強みを掛け算する
    - 得意なことを組み合わせる
- 戦略を実行した結果を分析し、戦略の改善へのFBとする

### セクション②
- プログラマー勉強方法
    - 知名度と価値は可換
    - アウトプット大事
- 見える形で成果をアウトプットすれば、いずれ知名度と自身の価値が上がる
- できるようになってからではいつになってもやらない
    - アウトプットへの障壁は先延ばしにしても下がっていかない
- 発表することで内容への責任が生まれ、知見がより身につく
    - その通りであると感じる。
- 継続の難しさ
    - ふりかえりを継続
    - 努力の継続はグラフ化やゲーム化が吉
    - 習慣の目標を限りなく小さくし、実施した習慣を記録してグラフ化
        - 可視化によってやる気が継続する
- 人間の特性を知る
    - 精神論ではなく、人間の特性を知ることでアプローチが変わる
    - 他人と比較すると幸福度が下がる。比較は過去の自分に対して行う
    - 悪いところに目が行きやすい
        - 良い点は意識的に探すことが大事。自分を振り返る際にもこれは大事
    - 「なんでこんなこともできないんだ」は禁句
    - 後知恵バイアス
        - 振り返って公開するのではなく、次はどうしようを考えることが大事

### セクション③

#### アウトプット駆動キャリア
- キャリアはアウトプットの積み重ね。なりたい姿から逆算してアウトプットする
- アウトプットの必要性
    - アウトプットするほうが学習効率UP
    - アウトプットしようと心がけるとインプット量が増える。情報に関するアンテナが増える
- 言語、距離、スキルの壁がなくなっていくので、中途半端なスキルでは太刀打ちできない
- アウトプットによって次のアウトプットの機会が訪れる
- アウトプットのWhatとHow
    - Whatの決め方
        - SNSやニュースで収集
        - Azureは日本では不人気なので強みになりやすいかも
    - How
        - まずやってみる。はじめは小さくてよい。LT→イベント登壇→カンファレンス登壇のように

### 所感
- 分かっていたことではあるがアウトプットは大事である
- アウトプットを継続するためには、限りなく小さな目標を立ててそれを達成できているかを確認し、振り返ることが効果的
- アウトプットにためらいは不要。まずはやってみることが非常に大事なので、自分もとりあえずやってみるを意識したい

## 19-A-1 エンジニアリングで負債を返済するための勘所 ― 事業特性にあわせたリファクタリング/リアーキテクティング/リプレイス

- 技術的負債が蓄積するとシステムとビジネスの乖離が生まれる
- リプレイスは上手くいかない
- リファクタリング以上リプレイス未満のアプローチがリアーキテクティング
- リファクタリングは新しいことをやるついでに取り組むのが吉
- 広告配信設定のデータの可読性を向上するためにリアーキテクティング
    - スキーマを手議するためにProtocolBuffersを利用
    - 徐々に新しい設定ファイルに移行
    - サービス一時的に止めていっぺんに移行ができない
        - 後方互換性がある状態を確保しつつ新しい設定ファイルに移行し、リアーキテクティングを実現
- レガシーシステムの一部を葬って小さくする。これも技術的負債に対する一種のアプローチ
- 直すまえにまずはそもそもいるのかを判断する。判断できるレベルはユーザーに影響をどれだけ与えるかで変わる。
- 就活支援サービスでのリプレイス
    - サービスの性質上、同じユーザーが年度をまたいで利用することがない
        - リプレイスによる影響が少ない。このような場合はリプレイスも現実味がある
- リファクタリングの必要性
    - 技術的負債を減らすリファクタリングの場合はボリューム感を意識する。
- 技術的負債の定量的評価
    - そもそものシステムとしてのスループットやパフォーマンスは一種の評価基準
    - きっかけは社内からの打ち上げであることが多い
    - システム+事業のスピードが落ちているときは技術的負債が足かせになっている可能性がある
- 技術的負債を解消するタイミング
    - 事業上で必要となる機能やニーズに応えるにあたって障害となる部分が技術的負債なので、そのタイミングでの解消が手堅い

### 所感
- レガシーシステムを削除することも技術的負債に対するアプローチである点は言われてみれば確かにそうである。何か技術的負債に対峙した際にはそもそも必要なのかは考えるようにしたい