iOSチームから見た、FiNC Technologiesの変化 -2019振り返りiOS編-

taktem
FiNC Tech Blog
Published in
10 min readJan 10, 2020

こんにちは、FiNC TechnologiesのiOSチーム西村(@taktem_com)です。

無事に今年も仕事のスタートを切り、初日は弊社社員での初詣にも行ってきましたが、なかなか新年の切り替わりというものも実感しづらいものですね。

ということで去年やってきたことを振り返っているのですが、2018年後期に社名をFiNC Technologiesに変更したということもあり、2019年は会社として技術領域により注力することが出来るようになりました。

今日はその中でも、iOSチームからの視点で、会社としての注力する部分の変化や、開発フローの改善を行ってきた話などをやっていきたいと思います。

FiNC Technologiesとして

去年はアプリ関連のチーム再編成もあり、職種毎の横串の連携は残しつつも、ドメイン毎のチームとして企画から最終アウトプットまで密に協力し、独立した小チームの集合体として動けるようになりました。

各ドメインチーム毎にミッションを持ち、出てきた技術課題を今度はエンジニアチームの定例や普段の会話の中で解決していくというように、組織としてのバランス感が強くなったと実感しています。

と組織的な話もしつつ、会社が技術にフォーカスしたことでiOSチームとしての目線で一番嬉しかったのは、やはりこの話題です。

初try! Swift 2019スポンサー

一昨年以前は諸事情により断念しましたが、去年はついに初のスポンサーとして参加することができました。
しかも、プラチナスポンサー枠で、ブース位置もベストポジションを確保することができ、この贅沢な配置で何をやろうかと、参加メンバーで盛り上がっていたのを覚えています。

結果的には、FiNCアプリ内でも配信しているコンテンツを実際に体験してもらう場として、参加賞付きのストレッチタイムを提供することにしました。

このような感じで、弊社ブースの前だけ全身を伸ばして動き回る、ある種異様な場として目立つこととなり、狙い以上の集客効果を得ることができました。

また、ブースのみではなく、オープニングアクトとして、弊社の本職のトレーナーにも協力してもらい、参加者全員で朝のストレッチの時間(弊社ではウェルネスタイムと呼んでいます)として会場をジャックさせていただき、大好評をいただくこともできました。

2020年もまた、スポンサーとして参加させていただく予定ですので、是非ブースにお立ち寄りください。

iOSチームの改善施策

iOSという枠組みのチームとしては、去年までは社員ひとり & 業務委託の方々と一緒にチームを組んでやっていましたが、今年は社員が2名加わってくれたというのが一番の変化だなと思っています。

それまでは業務委託の方が多いということもあって、チームがいわゆるシニア勢のチームで構成されており、また、人数も今よりは少なかったため、良くも悪くもアドリブでこなしていたようなところがありました。

ある程度の少人数のチームだとそれでもお互いの動きも見えるし成立すると思うのですが、この規模のプロダクトを作っていくためにスケーラブルなチーム体制を強化していく必要がありました。

細かいところだと色々チャレンジしている事はありましたが、その中でも特に印象に残っているものを2つご紹介したいと思います。

テストハンズオン

現在は、テストコードが無いと不安を感じるという文化が出来ていますが、年始の時点ではまだ正直各自の感覚値で書いたり書かなかったりという状態でした。

また、古いコードになるほどテストカバレッジが低く、今度メンテナンスしていくためにはここもテスタブルな構造に落とし込んでいく必要があるという危機感もあります。

テストコードの書き方においても、「書いたほうが良いとは思いつつ、具体的にどう書いてよいか迷う」のような声もあり、一定期間週次でテストハンズオンの時間を確保するようにしました。

ここでの目的は、直接的にアプリのプロジェクトのテストを充実させることではなく、テストを書く目的と観点を一致させ、開発効率とプロジェクトのメンテナンス性を向上させることに焦点を当てています。

主に行ったことは

  • 「なぜテストが必要か」の前提の読み合わせ
  • 基本的なテストの書き方を既存コードをなぞりながら復習
  • 既存コードを材料に、テストが無いコードへの導入

のようなものです。

この時点では、具体的なテスト方法も大事ですが、まず「なぜ必要か」という観点で納得感を持つことを重視しています。

手法だけを学習しても、実際に普段の開発の中で自然に意識できなければ効果も無いので、まずは予習として他社事例や参考記事などを読み合わせたあとに、具体的にコードに落とし込むという順番で行っています。

既存コードに対しては、まだテストがない部分はもちろんですが、既存テストを改良したい部分も含めてピックアップし、モブプロ的に行ったやりかたが最終的には盛り上がりました。

新規開発中の機能に対してどうテストを行うかについても活発に意見交換ができたことはもちろん素晴らしかったのですが、とあるチームメンバーがピックアップしてきた既存コードをテーマとして取り上げた時に面白い効果がありました。

「古いコードに不安を感じてテストを追加したい」というモチベーションで、じゃぁここにテストを書いてみようか、という流れになったんですが、そのためにはまず古いコードを解きほぐしてテスタブルな状態にする必要があり、チーム全員で苦労した思い出があります。

特にサービス初期からある機能などは入り組んだコードになってしまっていて、まずテスト可能な状態にたどり着くまでの難易度が高いことが多いです。

これをどう分解していくべきか、本当はどういう構造にしていたら楽だったかなど、実際につらみを感じた部分に対してのアプローチを議論することで、「なぜテストが必要か」という部分に対しての納得感を強めるとても良いきっかけになりました。

既存コードに関してはまだ課題も残っていますが、新規開発時の生産性や、既存機能への改修時の考え方など、このハンズオン期間の前後でチームの会話が大きく変わったことを実感でき、やってよかった施策だと感じています。

PRレビューを振り返る

チームが拡大したことの弊害として、PRを出す基準や、レビュー時の観点の違いや守りたいレベルの差など、一時的に開発スピードが落ちた時期がありました。

そこで、Androidチームのメンバーにも協力してもらい、レビューで各メンバーが何を気にしているか、何に困っているかなどを細かく洗い出すことにしました。

この会の目的としては、大きく2つありました。

  1. レビューに対してのストレスを下げる
    コードレビューは品質を守るために大事なものですが、指摘から発展した議論が長くなると、修正に対するプレッシャーが強まったり、スケジュールへ影響しうるなど、ネガティブ要因が目立ってしまいます。
  2. その上で、レビューで担保すべき品質ラインを明確にする
    とは言え、PR時点でマージすべきでない不備などが見つかった場合は解決する必要があります。

実際に出た内容は、レビューの目的や守りたい品質ラインなど、ベースとなる部分は思ったよりも一致していて、実際の問題はそれとトレードオフになる要素とどう向き合っていくかという部分がメインでした。

具体要因をあげていくとそれだけで記事が一個かけそうなボリュームになってしまうので、いくつか抜粋して紹介します。

  • レビュー時点で指摘が入るべきものじゃないものがある
    手戻りが多い要因として、企画レビューとして仕様確定時に解決できたことや、コードを書く前に設計時に合意しておいた方が良いことが一定量あることに気づきました。
  • 議論が長引いたあとのマージタイミングに迷う
    指摘に対する修正をどこまでやるか、付随して出てきた問題も完全に解決するかなど、議論の収束が難しいPRに育ってしまう事例が少なからずありました。
    この問題に対しては、まずコメントの意図の伝え方やどこまでこのPRでやるべきかの伝え方の基準を定めました。
    また、コメントが一定以上往復しそうな場合は対面の会話やScrapBoxでの状況整理など、PRのコメントから一度離れ、そこだけを素早く集中して解決するようにしています。

他にもいろんなアイデアが活発に出され、レビューの流れがかなり改善されたように思います。

さらに、この議論によってレビューの意識自体も高まり、それまではレビューを遠慮していたメンバーも積極的にコメントしてくれるようになりました。
レビューを受けるストレス要因を解決したことで、レビューを行うことに対しての心理的安全性が保たれる結果となり、副次的にチーム全体のベースアップに繋がったという嬉しい結果になりました。

さいごに

振り返って思うこと

先日、長く一緒にやってきた古いメンバーと、この1年でチームに対する安心感がすごく増したというような話をしていました。

誤解のないように言っておくと、それ以前に一緒にやってきたチームメンバーもそれぞれに得意領域があり、今でも情報交換などしたり仲良くやっています。

振り返ってみると、新旧のチームの仲間と行ってきた様々な要素が形として残り、積み上がった結果としてチームの力が強化されてきたと感じているところです。

これからやっていきたいこと

FiNCアプリは規模も大きく、複雑化しないように注意深くメンテナンスしなくてはなりません。

その上で継続的に機能追加・改善を行っていくためには、横串の結束力をさらに強固にした上で、個々が独立してドメイン毎のチームを牽引できる必要があります。

まだまだ解決すべき課題は多く、背中を任せられる仲間を探しています。

複雑化しないための設計の話で盛り上がりたい、UI/UXの改善の議論を熱く交わしたい、そしてそれらを実行するために一致団結して具体的な解決の結果につなげたい。

というモチベーションを一緒に持てる方、そしてそれを楽しみながらやれそうと思ってくれる方、ぜひお話しましょう。

いろいろ真面目なことを書いてはいますが、普段の会話はゆるく雑多な感じなので、気構えずに気軽にお声掛けいただければと思っています。
とりあえずのランチでも、一杯飲みながら雑談するでもOKです。

--

--