🙋♂️
【参加レポート】TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜
Findyさんが主催するイベント「TechBrew in 東京 〜mtx2sさんと考えるコード品質とビジネスインパクト〜」にブログライティング枠で参加してきました！当日のお話の内容を感想を含めて記事にしたいと思います！
会場はFreeeさんのオフィスで開催されました！
まずはYuki ShimizuさんのLTから
お話しされていた内容はこんな感じです！
- Freeeはかなりのプロダクト数がある
- それを用いて統合型経営プラットフォームを目指す
- ただの会計ソフト、プロダクト数の増加だけではない
- 全てのプロダクトがシームレスにつながるプラットフォーム
- デザインシステムのvibs
- 目指せドリームチーム
続いてメイン！松本 成幸(@mtx2s)さん！
-
PJはBiz ⇒ Devの順で降りてくる
- 計画を立てねば
- 見積もりせねば
-
Dev ⇒ Biz
- 見積もり
- 計画
- PJ
-
計画はBizとDevの中間地点
-
成功の評価基準
- 価値提供によるアウトカム
-
計画通りとは
- 顧客満足につながること
-
計画通りに進むとは？
- プロジェクト実行時には様々な困難が降りかかってくるがそれを乗り越えて計画通りに進めること
-
価値提供とは
- 要件通りに作成したものがそれが価値につながるとは限らない
- 仮説検証をして顧客に満足してもらえてこそ価値
-
価値提供の遅れはビジネスに直接影響を与える
-
コード品質がビジネスに与える影響
- コード品質の低さは開発時間の長さにつながる、長くなる
- 見積もりを困難にさせる
- 欠陥が多いとプランニングを困難にさせる
- コード品質の低さは開発時間の長さにつながる、長くなる
-
コード品質高ければ開発速度を上げることつながる
- 予測可能性が低くなる
- 計画の妥当性が低くなる
-
欠陥多いと？
- プロジェクトと関係ない欠陥が見つかると計画の遅延につながる
-
開発時間が長いと予定日までに期待する価値のレベルに到達できない
- 実験の試行回数が少なくなるから
-
対策の実例
- コードが秘伝のタレ状態で保守性が低くなっている
- テストコードなしの手動テストで運用
- 理解が難しいコードになっている
- コードが影響し合っていて変更しにくい
- コードが秘伝のタレ状態で保守性が低くなっている
-
テストコードを書いてコード品質を高める
- 自然とリファクタリングが進み、バグ修正も行える
-
コード品質への意識を高める
- 文化としてテストコードを書くことを実践する
- テストコードを書くことを評価軸に取り入れた
- 書くようになった！
-
テストカバレッジを自己目的化させない
-
テストコード設計の経験不足を補う
- ペアプロ推奨
-
実施結果はとしては及第点
Freee 友井(@t_mario_y)さんによるLT！
- 品質向上は開発エンジニアから煙たがられる？
- 作法の押し付けになってしまっていないのか
- Freeeでは開発チームから感謝されている
- 新機能開発前にその機能を開発するための技術的負債を検出する
- 標準化
- 社内専用で利用しているmiddlewareがたくさんある
- 品質チームが社内標準の使い勝手に対して敏感であり続ける
- ChgangeLogを読み切れる頻度でbump upすることを意識
- 古くなりすぎないうちにアップデート
- ChgangeLogを読み切れる頻度でbump upすることを意識
- 対応に関して
- クラインアントはエンジニア
- 質問が来たら即レス
- チーム内で回答を奪い合うくらい
- 向き合い方
- 品質と速度はトレードオフではない！
- 個人レベルで品質向上に没頭しているか？
- by 情熱プログラマー
写真を撮り忘れました。。。。
当日スライド！
ラストはmkitahara（@mikity01985）さんによるLT！
- リファクタリング要望が通らない！
- なぜ？
- なぜ品質改善タスクが進まない？
- 変化が怖い
- ビジネスが止まるのが怖い
- 終わりが見えない
- Bizへの共有方法
- コード品質は劣化する
- ゴールを決める
- タイムボックスを決める
- 定期実行
- 必要箇所だけ実行
- 品質指標はビジネスによる
- Too muchにならないこと
- Bizへの共有
- 他の施策との優先順位を決めて共有する
また写真をとりわすれました。。。。
当日スライド！！！！
感想
初めてこのようなイベントに参加しましたがとても学びが多く、時には共感できるようなお話もあり楽しかったです！
また機会があれば参加したいです！次はLTしたい！！！！
Discussion