参加セッション
- 価値をすばやく届けるための改善
- フロントエンドの潮流から見る需要と進化 〜これまでとこれからのフロントエンドの話〜
- ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること
- サバンナ便り〜自動テストに関する連載で得られた知見のまとめ〜
- 分岐を低減するinterface設計と発想の転換
- (ショートセッション)急成長を続けるAI×SaaSスタートアップで求められるエンジニアスキル
- (ショートセッション)ヌーラボってどんな会社？Backlogの開発現場をお話しします！
- (ショートセッション)数字を上げることが目的になっていませんか？～Four Keysによる開発生産性向上で陥った3つの失敗
メモ・感想
ショートセッションはスポンサー企業の製品紹介や会社紹介が多かったので割愛。
価値をすばやく届けるための改善
- アウトプット/アウトカム/インパクト という指標があり、仕事の価値を図る上ではアウトプットばかりを意識してはいけない。
- アウトプット・・・開発した機能数、タスク量
- アウトカム・・・顧客課題をどれだけ解決できたか(ここが重量)
- インパクト・・・組織に与えた影響
- アウトカムを決める要素は「問題設定力」「開発力」「チーム力」の掛け算。組織状況に応じてバランスよく力をつけていく必要がある。
- 「問題設定力」の改善
- アウトプットを目的化するのをやめる
- 解決すべき重要な課題にフォーカスする
- 作る前に仮設を検証する
- 作ったものは効果を計測する
- 失敗したら潔く捨てる
- 「開発力」の改善
- 技術に向き合う
- 作る量を減らしてでも技術力向上に投資をする。ペアプロ、モブプロ、個人学習
- テスト自動化
- 速度や品質低下の兆候に対処する
- クロスファンクショナルを実現する。特定の領域のみの知識だとチームとしても生産性が落ちる
- 「チーム力」の改善
- 避難文化からの脱却。心理的安全性を確保する
- チームの人数は１０人程度までとしコミュニケーションの複雑性を抑える
- 兼務をやめて、チームの認知負荷を下げる。担当領域を分担する
- ハイパフォーマンスチームを壊さない
- 「問題設定力」の改善
チームメンバーと一緒に聞くことができたので共通認識をもてた。現状、開発した機能のアウトカムを計測することがあまりできていないと感じた。複数プロジェクト、兼務することで生産性が下がるという話は開発、問合せを行き来していると全然集中できない状態からかなり納得した。
フロントエンドの潮流から見る需要と進化 〜これまでとこれからのフロントエンドの話〜
最近フロントエンドというものに興味を持ち始めたので楽しみにしていたが、正直全然話が分からなかった。泣
セッションには多くの人が参加していたのでわかる人には、興味深い話だったのかな・・・
まだまだ勉強することはたくさんあるし、社内だけをみているとトレンドにおいて行かれてしまうことを実感。
ウェブセキュリティの知識は普及しているか、徳丸本の著者が憂慮していること
ウェブセキュリティの知識学習時の注意、新技術との付き合い方が印象に残っている。
セキュリティ知識をネットで検索すると検索上位に出てくる記事は誰かのコピペ、または模倣して少し内容を書き換えた記事が多い(セキュリティに限った話ではないが)。知識豊富な人が書いた記事よりも、SEOに配慮したもの、広告料を払っている記事が上位となるため、検索して上位数記事を見るだけでは信用できないことが多い。疑いの目も持ちながら調べることが大切である。
また、AIを活用した検索はどうか？
最近話題のChatGPTにコーディングをさせると、セキュリティ面(XSS)が考慮されたコードを記述できるか、というのを実際にチャットしながら実演していた。「●●で●●なコードを書いて」というと、XSS対策ができていなかった。そこで追加で条件を与えていくとXSS対策ができているコードが返ってきた。AIにすべてを任せるのは危険だが、生産性向上には役立ちそうなのでうまく活用していきたい。
セキュリティ事故事例やDevSecOps事例の紹介、学習方法の話で紹介していた記事やサイト
架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策
DevSecOpsとは何か — 導入する組織が増加している理由
SPAセキュリティ入門
サバンナ便り〜自動テストに関する連載で得られた知見のまとめ〜
- 実装している中で学んだこと、疑問に思ったころ驚いたことについて学習用テストを書く。学習用のアノテーションをつけておけばいつでも捨てることができる
- 信頼性の高い自動テストを書く。誤検知(偽陽性)、見逃し(偽陰性)が多いと信頼性が低くなる。信頼不能性が1％に近接すると、テストは価値を失い始める。
- 自動テストとCIにフィットするテスト分類基準
- ユニットテストの分類は個人、組織によって定義が定まっていない現状(DB接続するテストはユニットテスト？？)
- test sizeは1プロセス完結がSmall、1マシーン完結がMedium、1マシーンで完結しないのがLarge
- Unitテストはtest sizeが大きくなるほどコスパが悪くなるのでやらない方がいい
- テストピラミッドにおいて[コスト/忠実性]と[速度/決定性]は反対の関係となる
- ピラミッド型になっていない場合はtest sizeをダウンさせるように取り組み、継続的に効率よく自動テストできる仕組みを目指す
分岐を低減するinterface設計と発想の転換
interface設計について、架空の防犯システムを用いて設計を実演。
- 目的単位で抽象化する
- システムは目的達成手段であり、要素のクラスも目的達成手段
- 目的/課題と達成手段はどちらもツリー構造かつ鏡合わせの関係となる
- 「作る」と「使う」を分ける
- if分岐だらけのようなよくないコードは「何を使うかを判断する分岐」と「実行ロジック」が混在している。
- 「作る」どの部品を使用するかの判断はFactoryやDIコンテナに任せる。部品選択を組み立ては作る側にカプセル化する
- 「使う」どの部品が使われているかは気にせず判断もしない。渡されたインスタンスをただ実行するだけ
- テクノロジーの本質は能力の拡大と縮小であり、同じ目的でも達成するための効率が格段に違う。interface設計可能な箇所は機能性向上の可能性を示唆している。
全体的な感想
今回初めてオフラインの技術イベントに参加した。技術力が追いついておらず深く理解まで及ばなかったセッションもあったが様々な技術領域の話を聞いて技術のトレンドや改めて大切なことを感じることができた。様々な領域の話をきいたり、他者のエンジニアと同じ空間でインプットすることでもっと勉強していきたいとモチベーションを上げることができたことが一番の収穫だと思った。
このようなイベントに参加させてもらえたことに感謝！また機会があったら参加したい！！