Upgrade to Pro — share decks privately, control downloads, hide ads and more …

「開発優先」の中で取り組む組織的な新技術への挑戦/20230208_horiuchi_suzuki

 「開発優先」の中で取り組む組織的な新技術への挑戦/20230208_horiuchi_suzuki

「機能開発を優先しているためリファクタリングができない」この状態に陥っている方、多いのではないでしょうか。
サービス開発では立ち上げから売れ始めるまでの間、プロダクトマーケットフィットを目指して最短距離を走ることを求められます。
その中で行われる意思決定では必ずしもすべてが最適解を得られるわけではありません。また時を経るにつれて最適解が最適解でなくなることもあるでしょう。
「サービスがある程度軌道に乗り、開発体制も整ってきたらリファクタリングやリアーキテクトしたい」――しかしベテランエンジニアの方はそんなタイミングが訪れないと知っているはずです。
そんな厳しい現実を直視して、ラクスではどのような対応を取ってきたのかをご紹介しようと思います。

本発表では以下のような内容をお話しします。

・ラクスにおける取り組みの概要
・取り組みの立ち上がりから継続していくための仕組みづくり
・取り組み実施のサイクル
・自社で検討することのメリット

Rakus_Dev

March 08, 2023
Tweet

More Decks by Rakus_Dev

Other Decks in Technology

Transcript

  1. #RAKUSTechCon
    © 2023 Rakus Co.,Ltd

    「開発優先」の中で取り組む組
    織的な新技術への挑戦
    2023.2.8
    技術推進課
    堀内泰秀、鈴木勇

    View full-size slide

  2. #RAKUSTechCon
    2013年ラクス入社。
    北米向けサービス開発、国内向けサービス開発に携わり、
    スマホアプリ開発、AI機能開発などを主導し、新しい技術要素を積極的に導
    入してきた。
    2020年に技術推進課を新たに立ち上げ、技術検証、現場の技術課題解決
    支援など幅広いミッションにマネージャーとして取り組んでいる。
    堀内 泰秀(ほりうち やすひで)
    2

    View full-size slide

  3. #RAKUSTechCon
    大手SIer、小規模ベンチャーを経て、2013年ラクスに入社。
    楽楽明細の開発にサービス開始2ヶ月から参加。
    コードレビュー率100%と、社内にビアバッシュ文化の定着を達成。
    その後、楽楽労務のアーキテクチャ検討&初期開発担当を経て
    開発部門横断で技術検証や組織文化醸成などに携わる。
    2020年から現在の技術推進課に所属。
    ラクスガンプラ部の部長でもある。
    鈴木勇(すずきいさむ)
    3

    View full-size slide

  4. #RAKUSTechCon
    ラクス「技術推進課」とは
    技術で
    横断的に
    チャレンジする組織
    と覚えて帰ってください

    View full-size slide

  5. #RAKUSTechCon
    「開発優先」
    で新しい技術に
    チャレンジできない
    こんなお悩みありませんか?

    View full-size slide

  6. #RAKUSTechCon
    優先順位は大事
    新機能
    顧客
    要望
    CS
    要望
    新技術
    リファク

    自動化

    View full-size slide

  7. #RAKUSTechCon
    優先順位は大事。
    顧客
    要望
    CS
    要望
    新技術
    リファク

    自動化

    View full-size slide

  8. #RAKUSTechCon
    優先順位は大事、だけど。。。
    新機能
    新技術
    リファク

    自動化
    最優先でお願
    い!
    わ、わかりまし
    たー!

    View full-size slide

  9. #RAKUSTechCon
    新しい技術に
    チャレンジしないと
    どうなるのか

    View full-size slide

  10. #RAKUSTechCon
    性能
    時間
    技術進歩の「S字カーブ理論」
    技術開発の進展と性能の成長の関係を表す。
    性能は
    ・最初ゆっくり
    ・急激に早く
    ・そして徐々に遅くなる
    という理論

    View full-size slide

  11. #RAKUSTechCon
    性能
    時間
    従来の技術
    新技術
    技術進歩の「S字カーブ理論」

    View full-size slide

  12. #RAKUSTechCon
    性能
    時間
    技術進歩の「S字カーブ理論」

    View full-size slide

  13. #RAKUSTechCon
    開発速度
    時間
    ラクス開発組織の危機感
    ラクスの
    開発速度
    競合他社の
    開発速度

    View full-size slide

  14. #RAKUSTechCon
    ラクスのサービス開発のかねてからの課題
    ● 新しい技術を使おうとしても時間的に余裕がない
    ● 古い技術だらけになったら社内のエンジニアもやめていきそう
    ● 個人で使った経験があってもプロダクションレベルでの利用がないとリ
    スキーと判断されがち
    ● 実サービスでは問題が出ない限りコストメリットの見えない技術刷新の
    優先度低い

    View full-size slide

  15. #RAKUSTechCon
    ラクスのサービス開発のかねてからの課題
    ● 新しい技術を使おうとしても時間的に余裕がない
    ● 古い技術だらけになったら社内のエンジニアもやめていきそう
    ● 個人で使った経験があってもプロダクションレベルでの利用がないとリ
    スキーと判断されがち
    ● 実サービスでは問題が出ない限りコストメリットの見
    えない技術刷新の優先度低い

    View full-size slide

  16. #RAKUSTechCon
    似たような話
    「あとでクリーンにすればいいよ。先に市場に出さなければ!」
    開発者たちはそうやっていつもごまかす。
    だが、あとでクリーンにすることはない。
    市場からのプレッシャーは止まらないからだ。
    「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるという
    ことである。競合他社に追い抜かれないためには、
    これからも走り続けるしかない。
    Clean Architectureより引用

    View full-size slide

  17. #RAKUSTechCon
    似たような話
    「あとでクリーンにすればいいよ。先に市場に出さなければ!」
    開発者たちはそうやっていつもごまかす。
    だが、あとでクリーンにすることはない。
    市場からのプレッシャーは止まらないからだ。
    「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるという
    ことである。競合他社に追い抜かれないためには、
    これからも走り続けるしかない。
    Clean Architectureより引用

    View full-size slide

  18. #RAKUSTechCon
    コストメリットの見えない
    技術刷新の優先度低い

    View full-size slide

  19. #RAKUSTechCon
    これからも走り続けるしかない

    View full-size slide

  20. #RAKUSTechCon
    優先度上がってこないよね・・・

    View full-size slide

  21. #RAKUSTechCon
    じゃぁどうするのか?

    View full-size slide

  22. #RAKUSTechCon
    普段から少しずつ
    検証しておくしかない

    View full-size slide

  23. #RAKUSTechCon
    試行錯誤を繰り返しながら

    View full-size slide

  24. #RAKUSTechCon
    2020年「技術推進プロジェクト」誕生

    View full-size slide

  25. #RAKUSTechCon
    とはいえ
    自分たちだけ知ってても
    意味がない

    View full-size slide

  26. #RAKUSTechCon

    View full-size slide

  27. #RAKUSTechCon
    取り組みの立ち上がりから
    継続していくための仕組みづくり

    View full-size slide

  28. #RAKUSTechCon
    ● 2017年:前身となる「かみせんプロジェクト」発足
    ○ 「かみせん」=「開発の未来に先手を打つ」の略
    ○ 各開発チームを横断したプロジェクトで正式な組織ではなかった
    ● 2018年:新規サービス開発のためプロジェクト休止
    ● 2019年:プロジェクト再開
    ● 2020年:課として発足、「技術推進プロジェクト」に改名
    技術推進プロジェクト組織の変遷

    View full-size slide

  29. #RAKUSTechCon
    ● 2017年 プロジェクト初期
    ○ 各チームのベテランエンジニアを集めて複数テーマをまとめて検証
    ● 2019年 プロジェクト再開期
    ○ 中堅エンジニアを巻き込んでいかないと継続できないという観点から
    参加メンバーを若年化
    ○ 人数が多いとマネジメントコストが上がるので、少人数チーム( 3人)に分割
    ○ 1チームごとに1テーマに絞って検証を行い、負担を軽減
    ● 2020年 組織発足期~
    ○ 2, 3人の少人数チーム、 1チーム1テーマが成り立つとわかったのでスケール
    ○ 2020年は6チーム、2021年は7チームで実施
    検証チームの構成、規模

    View full-size slide

  30. #RAKUSTechCon
    1チーム1テーマで負荷を軽減したが、メイン業務との兼務は大変。
    リーダーはプレイングマネージャー的な動きを求められるので特に。
    ● リーダー
    ○ マネジメント(+検証ヘルプ)
    ● メンバー
    ○ 検証に専念
    と役割を分けて、メンバーを1人追加するパターンを検証予定。
    さらなる改善:検証チーム構成の見直し

    View full-size slide

  31. #RAKUSTechCon
    プロジェクト実施のサイクル

    View full-size slide

  32. #RAKUSTechCon
    プロジェクトのサイクル
    約8ヶ月間の準備期間
    ● テーマの必要性検討
    ● 人員の確保
    ○ 各部署との調整
    ○ 興味とテーマのマッチング

    View full-size slide

  33. #RAKUSTechCon
    ● 人員
    ○ テーマごとに2~3人
    ■ リーダー1人
    ● ベテランエンジニア
    ■ メンバー1~2人
    ● 3年目以降くらい
    ● 時間、期間
    ○ 週5時間
    ○ 半期もしくは通年
    ■ 3人 = 約2人月/半期
    ● 実施
    ○ チームごとに実施日を設定
    ○ 実施日に集まって検証
    調査の様子~上期の例
    ● 4~5月
    ○ 顔合わせ
    ○ テーマについて調査
    ● 6月
    ○ 検証詳細を計画
    ○ 検証環境の構築
    ● 7~8月
    ○ 検証実施
    ○ 成果発表準備
    ● 9月
    ○ 成果発表

    View full-size slide

  34. #RAKUSTechCon
    各テーマの検証成果は開発組織内に共有。
    要否の判断も期待しているので
    ● 導入したいもの
    ● 導入の必要がないもの
    の両方とも出てくる。
    検証成果について

    View full-size slide

  35. #RAKUSTechCon
    なぜ自社で検証しているのか?

    View full-size slide

  36. #RAKUSTechCon
    情報はあるがラクスの事情を考慮した情報はない。
    ● そこそこな規模&10年以上稼働するサービス複数
    ● オンプレミス環境も活用
    ● B2B中心なので技術選定は安定性重視
    ● B2Bサービスは法律に影響受けやすい
    ● サービスごとの所属エンジニア人数&スキルマップ
    ● 採算性重視
    ● などなど……
    世間には情報があふれているのになぜ自社検証?

    View full-size slide

  37. #RAKUSTechCon
    「ラクスで」使えるか?
    の検証は自分たちでやるしかない

    View full-size slide

  38. #RAKUSTechCon
    例えば「マイクロサービスアーキテクチャ」
    結論としては導入しないと判断した(2017年)。
    端的に言えば技術がターゲットとする規模の違い。
    流行りの技術が「使える」とは限らない
    GitHubですら後悔しているという
    ツイートが話題になっていた

    View full-size slide

  39. #RAKUSTechCon
    開発組織全体の位置付けとしてはサービスの「技術刷新の促進」
    サービスに反映されるまでは2~4年くらいを覚悟
    ● 大きな仕組み変更は年単位で計画している
    ● そもそも3年先の課題感を見越している
    確信持ってじっくりやるのが大事
    「使える」→「導入」までの間も長い

    View full-size slide

  40. #RAKUSTechCon
    たくさん検証していくとすぐに活用されるテーマも。
    一部は検証した翌年に活用されました。
    ● 「モバイルビルドプロセス改善」「MQ導入」(2020年検証)
    ○ それぞれ2021年に成果物をもとにサービスに導入された
    ● 「バンドルJSの肥大化対策」(2021年検証)
    ○ 2022年にサービスに導入され、副産物としてビルド時間も 1/9に短縮
    成果の活用までが早かった例

    View full-size slide

  41. #RAKUSTechCon
    継続は力なり

    View full-size slide

  42. #RAKUSTechCon
    ラクスでは……
    長寿サービスを衰退させないために
    3年以上
    前から先手を打って
    陳腐化を防ごうとしています。
    というお話でした。

    View full-size slide

  43. #RAKUSTechCon
    Thank you for your watching.
    🙂

    View full-size slide