技術負債を返却しようと挑んでいる最中と未来の話

この記事はmediba Advent Calendar 2018 ４日目の記事です。

おはようございます。
こんにちは。
こんばんわ。

創造部 新米部長 尾野です。

弊社の社員が運営メンバーとして参画している、
「BIT VALLEY -INSIDE-」というコミュニティにてお話させてもらった内容を中心に書き記します。

その時の模様は@samuraiRedさんにブログにしていただきました。

嬉しい限りです。
https://blog.samuraikatamaris.red/entry/20181025/1540437510

すごく良いコミュニティなので、よかったらイベントに参加してみてください。

Facebookページ

さて本題です。
きっとどのIT企業に於いても技術的負債ってあると思います。
　
無論、弊社にもあり〼
　

私が担当しているPJに於いても、大きな技術的負債があって、 単純に時間を費やして負債をゼロにするだけじゃﾓｯﾀｲﾅｲと思い・・・ 　

そんなお話です。

前提

  • PJ内のエンジニアの割合（2018/03当時）

    • フロントエンド：4人（クライアントサイド）
    • サーバーサイド：8人（PHP）

きっかけ

とはいえ技術負債駆動刷新じゃないんです。 　

PJチーム全体でのエンジニアリングチームの稼働バランスを見た時に、

  • フロントエンド：残業過多
  • サーバーサイド：ホワイト企業

のような状況でした。 　

UX/UIを起点に要件が発生するのは当然ですよね。
視認性を持つUIに対してユーザーは反応しますし、そこに対してカイゼンってなりますわそりゃ。 　

昨今、Webブラウザで出来る事はものすごく増えました。 　

Server Side Renderingに割く処理コストって、もっとWebブラウザに寄せたほうが体験も良くなるし、手元の端末に処理を寄せればサーバーリソース/コストも減らせるよね、と。 　
　

もっと手元に処理を寄せよう。
もっとユーザー接点を司るエンジニアを増やして、総体的にエンジニアとユーザーの距離を縮めよう。 　
　

そう、ブラウザが主戦場なんです by 社内のエンジニア 　
　

役割定義

ということで役割定義/技術スタックを大きく変えました。

  • Universal JavaScript化

    • ＝サーバーサイド/フロントの人員リソースの効率化 　

  • SPA/遷移先ページのprefetch/dynamic import/最適なSSR等による画面描画と遷移の体験を改善

    • ＝UX向上

今までありがとうPHP。僕はキミ（PHP）に多くの事を学びました。
　

ｻﾖﾅﾗPHP 僕は今TypeScriptに夢中です。
　

そして、１つのチームに責務を持ってもらって、チューニング出来た方が、 コミュニケーションコストも減らせるし、責務に集中出来るから良いよね

　
こんなイメージで分けました。

サーバーサイドの部分をWeb+Rest API（今回はGraphQLにしましたが）/Consoleに分離して、フロントとバックエンドに寄せて２層にしました。

責任分界と超概要構成

　
こんなイメージ

　
あ、そうです

バックエンドのバッチもPHPは辞めてGolangにしました。 知見は既にあったので概ね無問題でした。

　
責務範囲は

  • フロントエンド：ブラウザ＋サーバーWeb＋API（Backends For Frontends）
  • バックエンド：バッチとインフラ 　

とし、責任分界のIFはフロント側で設計する様にしました。
何かしらのstorageのschema依存ではなく、利用する側が利用意図に即した形で設計し、Provider側はデータ提供の為に作り込む、が正義だと
（Consumer Driven Contract的な）

学習コスト

個人）ひたすらコード書きました。
　　　↑↓
先陣チーム）実装基板を作る
　　　↑↓
PJチーム）モックを作る所からはじめ、定期的なティーチングを繰り返す

　
というのを繰り返しながら浸透を図りました。

開発Phaseにて

PJの途中（中盤〜後期）からではありますが、 eXtream Programming的なアプローチも取り入れる事にしました。

　
どうしても開発Phaseにおいてドライブ掛かるとPull Requestって溜まっちゃうんですよね。レビュー後回し
定期的に固定のレビュー時間を取っても進捗しないんですわやっぱり。

　
そして、属人的にコード書いちゃうままレビュー出来ずに問題を顕在化出来ない→品質が向上しないという負のスパイラルに陥ってしまうので・・・

3人1組にしてライブコーディングをする事にしました。

　
モブでもペアでもなく、ナビゲータ/ドライバで分けることもなく、スタック分界で接合点を話しながら進めていくスタイルを取りました。

　
こんなルールでやってます。

  • リーダー的な人がブランチ切る
  • セッション張る
  • みんながそこに参加

  • みんなでTODOリスト作る

    • 一人でやりきれるボリューム感

  • TODOリストをタイムボックス管理する

    • 例）1時間と決めて消化を確認する

VSCodeのLive Shareという機能、とても良いみたいです。
時間都合が合わせられない僕は参加出来てませんorz
とても楽しそうだし「効率あがった」という意見もいただきました。
羨ましいorz

今

これから試験Phaseに入っていきますが、ここも責務分離でﾜｯｼｮｲします。

  • 非機能班

    • パフォチュー＋リファクタ
    • 全体で言うとボリュームテストと例外テストもする

  • 機能班

    • バグチケ＋E2E＋リファクタ

みたいなイメージで進めようと考えてます。雑ですが明かせる範囲はｺｺﾏﾃﾞ

2019のいつか、きっと素敵な使い心地をまとったプロダクトが世の中に放出されます。

未来のお話

プロダクトを長い目で見た時にグロースしていく時期のほうが圧倒的に長いと思います（ケースバイケースですが）
バイモーダルITにおけるSoR/SoEのシフトチェンジってとても重要だなーと　

その上で、グロースPhaseにおいてはSoEにギアを入れ替え、しっかりとユーザーの反応を見ながら、ユーザーに求められる方向にプロダクトを成長させていけるプロセス/技術に変えていこうと考えてます。

技術は事業成長のために使うもんだと。

まだ言えませんが、まさにこれから大きな新サービスをMicroservicesで仕立てていく計画があったりなかったりします。

まだまだ挑戦しがいのあるサービス構想が沢山ある中で、ユーザー価値を中心に据えてモノづくりをしていける文化をこれから創っていこうとしてます。

そんな文化創りから携わりたいやっていき力の強いエンジニアを求めております。 　

では

1 note

  1. nekonyanko reblogged this from mediba-ce
  2. mediba-ce posted this