入社してから取り組んだ、細かい業務改善
この記事は Akerun Advent Calendar 2022 - Qiita の11日目の記事です。
今年の6月より入社しました、Web開発グループの小森と申します。 主にiOSアプリケーションの開発を担当しています。
この記事では、タイトルの通り、入社してから取り組んだ細かい改善について書きました。（SwiftUI関連の記事を書く予定でしたが、入社したてということもあり、SwiftUIについてはまた別の機会でかけたらと思います。）
プログラミングをして改善を行うようなハードルの高いものではなく、単純なツールの使い方や方針を少し見直す、取り組みやすそうな改善になるので、是非お立ち寄りいただければ幸いです。
(1)Slackのチャンネルの分割
業務のコミュニケーションツールとしてSlackを活用していますが、普段iOSチームでメインでやり取りをしているチャンネルに、SlackのGithubチャンネル連携によるの自動メッセージ（主にPRの作成/PRのコメントなど）も流れるような状態が続いていました。
PRの作成頻度によってはチャンネルで共有されたPR以外の内容を見落としやすそうな懸念があり、チャンネルを分割（新たにチャンネルを作り、そのチャンネルで必要な会話をするように移行）しました。
具体的に取り組んだこと
チャンネルを分割すること自体は特段難しくないですが、普段のチームのコミュニケーションのルールを大幅に変えることになるので、少々神経質ではありますが分割する上で下記のように行いました。
- 2つのチャンネルにどういった会話が期待されそうか方針を決める。その際検討していた方針は下記です。
- チャンネル名を決める
- 誰を招待するかを確認する
- 招待する方に、上記をテキストベースで共有する
- 実行
結果
チャンネルを分割したことで、チームメンバーからも使い勝手良さそうな前向きな意見が伺えたのでよかったです。具体的には下記のような効果を感じました。
- PR以外の普段の会話が埋もれそうな状況は発生しなくなった
- 受け取ったメンションを追いやすい
- 会話を後からたどりやすい
上記なpositiveな効果を感じた一方で、導入時にチャンネル名に起因した運用上の認識齟齬があったため、チャンネル名が適切かどうか（目的にあった理解しやすい名前かどうか）の確認はもう少し丁寧にやれたらと思います。
(2)プルリクエストのテンプレートを作成する
私が普段携わるGithubリポジトリには、多い時で5人のエンジニアが開発するという状況があり、プルリクエストのテンプレートがない状態がありました。PR作成者は各々で似たり寄ったりな独自のテンプレートを持っており、私自身も毎度コピペし、手間でした。
それに加えて、アプリの表示確認にPRに添付する画像サイズが、各人が出力したその大きさのままプルリクエストに添付される状況もみられ、レビュアーにとっては少々負担になりそうに見受けられました。
PRのテンプレートを作ることで、上記の問題の解消を試みました。
具体的に取り組んだこと
こちらに記載の通り、pull_request_template.md と言う名前のテンプレートを、対象リポジトリの .github 配下に作成します。
## 概要 ### 詳細 <!-- 概要で伝えきれない内容記載 --> ## リンク <!-- 資料 --> ## レイアウト | 改善前 ❌ | 改善後 ⭕️ | | ---- | ---- | | <img src="" width="240"> | <img src="" width="240"> | ### 動作 ## TODO
レビュアーが効率よくレビューできるように、下記の項目を追加しました。自明な箇所は省きます
- リンク : 修正の根拠 / 妥当性を理解する補足資料のリンク
- レイアウト : iOSアプリケーションの表示を変更した時の、改善前改善後のキャプチャ（改善前のキャプチャも添えることでレビュアーとしては変更箇所が認識しやすくなるので、改善前のキャプチャを項目として追加しました）
- 動画 : 挙動の変化のある場合の動画。レビューする際にローカルで確認する手間を省く
- TODO : そのPR自体に含まれても良さそうな修正だが、含めなかったもの
結果
こちらも基本的にはpositiveな効果が得られたように思います。
PR作成者視点
- 毎回ローカルから自分のテンプレートをコピペする必要がなくなった
- 項目の妥当性についてはそこまでフォーカスしなくて良く、項目を入力することに注力すればよくなった
PRレビュアー視点
- 対応者によって内容の文脈を切り替えなくて済む
- 画像サイズが大きなPRに直面することもなくなった
PRの画像については各人のローカルで毎度スクショを準備していただいているため、BitriseなどのCIツールを使って自動化できないのか、こちらの調査もしていきたいです。
(3)KPTのTryテンプレートの作成
私が所属するチームでは振り返りの方法として、KPTという振り返りのフレームワークをベースにした振り返りをしています。ツールはTrelloを使用して、オンラインで完結します。 巷で行われているKPTと大きく大差ないと思いますが、下記のようなフローで行なっています。
- 所定の時間で、Keep / Problemを記載
- Keep / Problem を各人で発表
- 2の内容をもとに必要に応じてTryを作成する
- 次の週のKPTでTryを確認
3のTryを作成する中で、Tryしたいことだけ記載されているカードが多く、どういった経緯でTryが記載されたのか、どうすればそのTryが達成することになるのか、後から見づらくなっている状況がありました。
その結果、先週発生したTryがどういう目的で作成されたものか分かりづらくなっており、4のタイミングで、このTryが何かを確認する会話が発生することが何度かありました。 効率よくイテレーションを回すには、もう少しTryに関する情報を記録して4における時間を減らせるように思うので、ここでもテンプレートに頼りました。
具体的に取り組んだこと
下記のようなTryのテンプレートを作成しました。
## Tryしたいこと ## モチベーション ## 具体的な次のアクション
項目は下記のようなものです。
- Tryしたいこと : 項目名の通り、やりたいことを簡潔にかく
- モチベーション : Tryしたい動機を書く。現状の説明なども必要に応じて記載
- 具体的な次のアクション : そのTryが達成するための完了アクション。Tryしたいことよりも詳細に踏み込んだ内容を記載。
結果
こちらはまだ導入したばかりなのでそこまで大きな効果を確認できてない状況はありますが、Tryに関する情報が増えたので、以前よりも4におけるTryを捌く時間が早くなりそうな予感がしています。まだ運用上チームに浸透してないところもあり、Tryで書くべき内容として多くないかの検討など、これから見ていきたいと思います。
感想
上記三つほど小さな改善に取り組み、特に大袈裟なことをせずとも改善できることは多分にあるなと感じました。入社時点では前の現場との違いを捉えやすくなっていることもあり、改善しても良さそうな部分に気付きやすいかもしれませんが、システムやツール等に長期で慣れすぎると問題点に気づきにくくなることもあると思います。
そうならないためにも、常日頃から問題意識や目的に合った使い方がなされているかなど、考える姿勢を持ちたいです。
お読みいただきありがとうございました!
株式会社フォトシンスでは、一緒にプロダクトを成長させる様々なレイヤのエンジニアを募集しています。 hrmos.co
Akerun Proにご興味のある方はこちらから akerun.com
