エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

"Go GLOBAL" meetupに参加してきました

エンジニアリンググループの冨岡です。

エムスリーでは去年ごろより海外ブランチとの連携をより強めています。私自身も去年はM3 USAに出張するなどして機運が高まっており、2/28に行われた以下のイベントに参加してきました。

go-global.connpass.com

会場は原宿と渋谷の間にあるSmartNewsさん。余裕のあるオシャレで広いスペースで、気持ちが良かったです。

f:id:jooohn:20190301104524j:plain

f:id:jooohn:20190301104541j:plain
地球くんのクッションがある

今回のテーマはスタートアップアクセラレータでした。AirbnbやStripeが参加していたY Combinatorが有名ですが、日本を含め世界各国に様々なアクセラレータがおり、スタートアップエコシステムの一端を担っているようです。

どの話も面白く、話に聞き入ってしまって写真をあまり撮っていなかったのですが、少しだけ紹介させていただきます。

続きを読む

小規模開発案件をJIRAカンバンボードで進捗管理する

エムスリーエンジニアリンググループ、リサーチビジネスの担当エンジニアの井口です。
これまで私達のチームでは開発案件の進捗管理は、規模に関係なくガントチャートで管理してきましたが、PDCAや業務改善などを始めとする小規模な開発案件に関しては、「JIRAカンバンボード」を使ってカンバン方式で管理するようにしました。
本記事では、導入の経緯・振り返り・JIRA設定内容(結構苦労したので...)を紹介したいと思います。

※ ちなみに、大規模開発に関してもスクラム開発に移行したので、たぶんチームメンバーが別記事で書くと思います。

f:id:rinoguchi:20190128185729p:plain
JIRAカンバンボード

導入の経緯

PDCA開発(サイト内のCTRやCVR向上などが目的)や業務改善開発(業務フローを効率化・自動化が目的)などの小規模な開発案件には、以下のような特徴があります。

  • 一つひとつの開発規模はせいぜい5人日程度
  • 案件をスピーディーに沢山実施したい
  • 各案件のスケジュールを厳密に管理することはあまり意味がない
  • 大半はビジネス的な納期がない(ごく稀に必達の納期がある案件もある)

これまで、私達のチームでは伝統的に開発案件の進捗管理をガントチャートで実施してきましたが、ちょっとスケジュールが押すだけで、後続作業や並列作業のスケジュール・アサインを見直す必要があり、管理コストが馬鹿になりませんでした。そこで、主に「管理コストを減らす」という目的でカンバン方式を導入することにしました。

導入にあたっての一番のハードルは「カンバン方式にすることでスケジュールをコミットできなくなる」という点でしたが、その点は、

  • 納期があるものはそれを明示し、最優先で開発するルールとする
  • 旧来の管理と並行してJIRAカンバンボードでの進捗管理をやってみて、問題ないことを本格運用前に検証する

という対応を行うことで関係者の理解を得ることができ、無事に導入にこぎつけることができました。

振り返り

やってみて、良かったと感じた点は以下です。

  • 無駄なスケジュール調整やアサイン調整が減り、管理コストが削減できた
  • 全案件の状況がぱっと見えるようになり、進捗確認がしやすくなった
  • 一部の納期がある案件をうまく優先対応することで、スケジュールが見えにくくなることもマイナスにはならなかった
  • 無理のないスケジュールで対応しやすい雰囲気となり、残業が減った(気がする)

逆に、ガントチャートによる進捗管理よりも悪くなったと感じる点は、おそらく一つもないと思います。

今後、更に改善するとしたら

  • スタックしている作業を皆で集中的に潰して全体スループットを上げる

という点に取り組まなくてはいけないと感じています。
(現状は、私達のチームでは職種がわかれているので、結構ハードルが高い)

具体的な設定内容&運用ルール

ここからは、実際に私達のチームのJIRA設定内容の一部を紹介します。
JIRAの設定は結構難しくて手探り感満載でしたので、実運用での設定例として、これからJIRAを使おうという方に参考にしていただければ嬉しいです。

プロジェクト
  • プロジェクトは課題をグルーピングするコンテナ的なもの
  • リリース管理をシステム単位で行うため、1プロジェクト=1システム
    • カンバンボード側で、複数システムの課題を一つのビューにまとめて表示
課題タイプ
  • 必要最低限の以下の4つの課題タイプを利用することとした

    課題タイプ 種別 説明
    タスク standard 通常の開発案件を管理する
    サブタスク sub-task タスクに対して何らかの子タスクを管理したい場合のみ利用する。あまり使わない
    本番バグ standard 本番環境で発生したバグを管理する
    開発中バグ sub-task QA中に発覚した開発中バグを、主タスクの子タスクとして管理する
ワークフロー
  • 基本的な開発の流れ(IA→実装→QA→リリース)に合わせて、下の図の通りに設定
    • どのステータスもすべてのステータスからトランジッションできるように
  • 4つの課題タイプに共通してこのワークフローを適用した
  • 「◯◯待ち」にトランジッションする際、各役職の責任者をアサインし、責任者がメンバーをアサインするという運用にすることで、調整工数を削減 f:id:rinoguchi:20190222185541p:plain
画面
  • 画面は、課題の作成・編集・表示する際のフィールドを管理するためのもの
  • 課題タイプ ✕ 作成・編集・表示のどの組み合わせも、基本的には同じフィールド(下図参照)を利用するようにした f:id:rinoguchi:20190222192118p:plain

  • 課題の分類には専用フィールドは設けず、「ラベル」を利用するスタンスにした

    • 同一課題に複数のラベルを設定できし、新たなラベルを追加するもの簡単
    • カンバンボード側のクイックフィルターを使いラベルで絞り込むと便利 f:id:rinoguchi:20190228184056p:plain
カンバンボード
    • カンバンボードの列=ワークフローステータスとした
    • 「かんばんバックログ」は有効化
      • 「バックログ」と「カンバンボード」を分離できるので、バックログの件数が多い場合には便利
  • スイムレーン
    • ベーススイムレーンを「クエリ」で設定すればそれなりに便利
    • でも、縦スクロールが発生して一覧性が悪いので、使うのをやめた
  • クイックフィルター
    • 「期限あり」「テクサポ」「Eng改善」「自分の課題」など、JQLで目的別にフィルターを作れる
    • 画面上部のボタンでフィルタを目的に応じてフィルタを適用する f:id:rinoguchi:20190301135736p:plain
  • カードの色
    • 進行上問題があると思われる課題の色を変える
      • 納期が3日以内のものは赤色
      • 同じステータス7日以上留まっている場合は黄色
    • 設定できるJQLは文字数制限があるので、複雑な条件の場合はフィルターとして別途保存して、JQL内ではフィルターを参照をする
      • 「カードの色」のJQL設定 f:id:rinoguchi:20190222205852p:plain
      • フィルター定義 f:id:rinoguchi:20190222210846p:plain
    • 定例MTGでは色が変わっているものだけを見る運用にして、確認工数を削減
      • 特に、納期がある案件に色がついていた場合は、最優先で対応

まとめ

いかがでしたでしょうか?この記事では、案件管理にJIRAカンバンボード導入した話を紹介させていただきました。参考にしていただけると嬉しいです。

  • PDCA・業務改善のような小規模な開発案件の管理には、カンバン方式がすごくマッチした
  • スケジュール管理やアサイン調整などの管理コストが削減できた
  • JIRAは設定はけっこう大変だけど、設定仕切ってしまえば使いやすかった

エンジニア募集

エムスリーでは自身で手を動かし、技術で医療の課題を解決するエンジニアを募集しています。
JIRAの設定もチーム毎に自分たちに最適な設定をそれぞれやっています。
この記事(or 他の記事も)を読んで興味を持った方はぜひ下記リンクよりご応募ください!

5年もののiOSアプリのフルSwift化が完了した話

こんにちは。エムスリー エンジニアリンググループの藤原です(※ 技術顧問の藤原さんとは別人です)。 医師・薬剤師向けプラットフォーム「m3.com」のiOSアプリの開発をしています。 メインはiOSですが、Androidやサーバーサイドを担当したりと色々とやっています。

iOS版「m3.com」アプリは2014年ファーストリリースで、フルObjective-Cで書かれていましたが、 2019年2月のリリースをもって、フルSwift化が完了しました。 今回はこれまでコツコツと実施してきた、Swift化周りの取り組みについてお話します。

f:id:m-fujiwara-m3:20190226123950j:plain

Swift = アマツバメ

(wokoti [CC BY-SA 2.0], ウィキメディア・コモンズより

続きを読む

サーバーレスでプライベートな STNS のバックエンド API を AWS で実現した話

お久しぶりです、エムスリーエンジニアリンググループ 兼 QLife エンジニアの園田です。

STNS という pam と連携可能な HTTP プロトコルを利用した Linux の認証機構があります。
通常は TOML でアカウント情報を管理するのですが、API のインターフェースが公開されているため、独自のバックエンドサーバーを構築して利用することも可能です。

https://stns.jp/images/stns-architecture.png

弊社 SRE の寺岡も独自のバックエンドを実装した記事を Qiita に投稿しています。

qiita.com

今回実装した STNS のバックエンドは、AWS の API Gateway + Lambda + DynamoDB で実現しました。
ただ、この構成もすでに既出記事がいくつかあり、そんなに珍しくもありません。

今回の実装のポイントは、API Gateway の Private エンドポイントで実装していて、特定の VPC や VPC エンドポイント経由でしか利用できないようにしていることです。

続きを読む

「入門 監視」を読んで見えてきた現状の課題と改善点

こんにちは、エンジニアリンググループ SREチームの高橋(@tshohe1)です。

「入門 監視」という本が各所で話題になっていますが、エムスリーのエンジニアリンググループでも予約購入していました!

www.oreilly.co.jp

監視というSREと非常に親和性の高いテーマの本だったこともあり、多くのSREメンバがこの本に目を通していたようです。 そこでぜひチーム内で感想を共有しようということになり、先日感想共有会が実施されました。

本記事ではそのときに挙がった感想を一部抜粋して公開したいと思います。

f:id:tshohe:20190225174145j:plain
モニターリザード

続きを読む