joinsure recordチームの開発体制

こんにちは。

justInCaseTechnologies の web frontend engineer の kondei です。

当社は今 "joinsure" という SaaS 型保険システムを開発中です。

チームは Systems of Record, Systems of Engagement という区分を参考にして大きく "record" と "engagement" に区分しています。

そのうちの契約管理などの部分を担当する record チームの最近の開発体制についてご紹介します。

アジャイル × スクラム開発

導入まで

joinsure 以前の開発はハッキリ言って「なんちゃってアジャイル」な部分があり、明確なフレームワークに沿っていませんでした。

それによってミーティングが少なかったり機動力があったりするというメリットはありましたが、感じていたデメリットとしては、以下のようなものがあります。

  • タスクを頼んだと思っていた人と、頼まれたと思っていない人の認識の齟齬があることがある
  • しばらく経つと、誰がボールを持っているのか、何によって待ち状態になっているのか分からないことがある
  • 期間も進捗も分からないことがある
  • ゴールが明確でないときがある

joinsure プロジェクトが明確に立ち上がるとき、開発体制をどうするかコアメンバーで議論しました。

そのとき草案としては既存のオリジナル体制の発展型が提案されており、ウォーターフォール型となんちゃってアジャイルの混ざりあったような状態が想定に入っていましたが、 「既知のプラクティスであるアジャイル × スクラム開発手法に従った方が良い」という議論の結果、導入が決定されました。

他の手法ではなくこれを選んだ理由としては、以下の通りです。

導入にあたって

導入にあたっては、まず

をチームメンバー全員で読むことでマインドセットと方法の認識合わせをしました。

ツールは BizDev, PdM, designer, engineer全員で YouTrack を使用しています。

また、アジャイルの流儀の 1 つである、インセプションデッキを作成しました。

最近では「何を諦めるのかはっきりさせる」ページの優先度調整が現実に合わせて更新されたりして、全員の方向合わせに有効活用されています。

インセプションデッキ

実践してみての工夫

  • プロジェクト状況に応じて適宜イベントのタイムボックスを調整しています(スプリント期間を 2 週間 → 1 週間 → 2 週間で調整したり、内容が減ってきたらミーティングを短くしたり)
  • スプリントレトロスペクティブは KPT 法で実施しており、なるべく改善案・next action を決めるようにしています
  • 社内ドキュメントに「スクラムを始めるときに読んでおくと良いもの」というページを作って、参考文献をまとめています
  • Slack にアジャイルスクラムの話をするためのチャンネルを作っています

効果

導入によって、以下の効果があったと感じています。

  • スプリントの導入によってゴールが明確に共有されるようになった
  • 誰が何をしているのかわかるようになった
  • 短い締切の繰り返しが生まれることによって、意欲が向上した
  • デイリーやスプリントプランニングによって、計画の見直しがしやすくなった
  • engagement チームの開発にも導入されて、会社全体として IT 開発の素地が整った
  • 良い開発体制を持ったことで、採用上も訴求力が上がった
  • 各チームを超えた会社全体の体制として「大規模スクラム(LeSS )」を見据えることができるようになった

DDD

ドメインコンテキストマップ

ドメインコンテキストマップ

幅広い保険業務を扱う SaaS の開発のために、BizDev がドメインコンテキストマップを作成して、大まかな区分けと依存関係を認識共有しています。

また、個人的に良いと思うところは、このマップに対し、バックエンドのサービス区分・フロントエンドの機能区分をほぼ一致させることができていることです。

ドメインモデル図

ドメインモデル図

ドメインモデル図をクラス図の形式で書き、ドメイン知識のメモ書きを付記して、PdM とエンジニアで共同管理しています。

目的としては、全員のビジネスの想定を揃えることと、バックエンドのドメイン層実装のために使います。

変更があるときは随時議論したり、スプリントレビューで全員に共有されています。

アクティビティ図

アクティビティ図

同様にPdMがアクティビティ図を使ってシステム間に跨ったビジネスのフローを定義・管理しています。

状態遷移図

状態遷移図

「契約」「請求」など、状態がある概念に対しては状態遷移図を作って状態とイベントを定義しています。

これは以下の役に立っています。

  • PdM とエンジニアで明確に認識を合わせること
  • バックエンドもフロントエンドも状態変更操作や用語を正確に図に従って実装すること
  • 状態遷移に伴う UX や用語の改善議論

また、これを作る文化が根づいたことで、メンバーが仕様定義の時点で「これは状態遷移がある概念かどうか。状態とイベントを定義した方が要件定義しやすいかどうか」という判断ができるようになったと感じています。

bitemporal data model

保険の業務では契約やお金の絡むイベントを厳密に扱う必要があったり、特定の日時のデータを出力する必要があったりします。

つまり「データによっては任意時点のイベント・状態を後から復元できる必要がある。どう保持するか?」という課題があります。

それに対して、チームメンバー主導で bitemporal data (model)というデータモデルの導入が提案され、ハンズオンが開催されてチームで勉強して、バックエンドのデータモデルに導入されました。

参考文献

OpenAPI, スキーマ駆動の API 開発

APIスキーマから自動生成したドキュメント

joinsure 以前の API 開発と利用では以下のペインがありました。

  • API 定義が手動生成になっており、ドキュメントの更新漏れ等が発生する
  • API ドキュメントと実装の差分がわからない、検知できない
  • クライアント側の API モデル(型)とコードが手動生成になっていて乖離やコーディングコストで開発効率が悪いので、自動生成したい
  • API 定義がサーバーサイド主導になっており、クライアントサイドが API に対する議論への参画がしづらいことを、スキーマファーストで解決したい

それに対して OpenAPI のスキーマ駆動開発と、コードとドキュメントの自動生成を導入し、ペインがほぼ解消できました。

参考文献

https://logmi.jp/tech/articles/324190

ADR(Architecture Decision Record)

技術選定の議論と理由を残すため、バックエンド・webフロントエンド共に技術選定ドキュメントに ADR が導入されています。

ADRをレビューフローに乗せることで合意を得る意思決定プロセスが明確になり、リポジトリに残ることで新入社員も経緯を追いやすくなります。

参考文献

デザイン開発における Figma の活用

デザイン面の開発は Figma を活用し、以下の流れとなっています。

  1. BizDev, PdM がワイヤーフレームを作成し、デザイナーとブラッシュアップ(場合によってはエンジニアとも議論)
  2. デザイナーがワイヤーフレームから実装用デザインを作成し、BizDev, PdM, フロントエンドエンジニアとブラッシュアップ
  3. フロントエンドエンジニアが実装

ワイヤーフレーム

実装用デザイン

これによって以下の効果がありました。

  • PdMの意図するUXから乖離しにくい
  • UX改善や変更の議論が活発になった

デザイン開発におけるコンポーネント指向開発

これまでの課題として、複数のプロダクトで同じようなデザイン定義とその実装が再作成されている状態がありました。

それを解決する手法として、デザインの時点でコンポーネント指向で定義し、実装もコンポーネント単位で再利用できるものを作っています。

コンポーネント指向デザイン

また、最近では Chromatic というサービスを導入してコンポーネントのVisual Regression Testで差分の検知をできるようにして、品質を高めています。

チームのエンジニア全員でエンジニア採用に関わる状態

エンジニア採用において、人事メンバー主導で数ヶ月前に「スクラム採用」という手法が導入されました。

エンジニア採用のために「採用 weekly」や「転職ドラフトもくもく会」などの定期イベントが設定され、基本的にエンジニアメンバー全員が候補者を探して判断するようになり、開発上求める人員の話・採用活動上の課題・面談や面接やツール利用方法の改善点などが議論されるようになりました。

これによって採用という業務が「人事や一部の人だけが関わるもの、通常メンバーにとって新入社員はいつの間にか降ってくるもの」というような状況から、「チームで一緒に働きたい人を主体的に見つけて判断し、やり方自体を改善していく」という状況に変わりました。

開発体制がスクラム化したこともあり、人事面もスクラム要素が取り入れられたのは相性がよい体制と感じています。

終わりに

justInCaseTechnologiesでは常に現状の改善を進めており、新たな開発メンバーも募集しています。

この記事で少しでも働くイメージが湧いたら嬉しいです!

ご応募お待ちしています。

Server-Side Kotlin Meetup vol.2へ登壇しました

こんにちは、justInCaseTechnorogiesでバックエンドエンジニアをしている宮田です。
先日開催されたServer-Side Kotlin Meetup vol.2へ「jackson-module-kotlinを読もう!」というタイトルで登壇してきました。
資料はこちらです。

speakerdeck.com

Server-Side Kotlin Meetupについて

Server-Side Kotlin Meetupsmartroundマネーフォワード、及びjustInCaseが中心となって開催している、サーバーサイドKotlinに特化した勉強会です。
運営企業に加え、様々な有名企業所属エンジニアやOSSコントリビュータも登壇する勉強会となっています。

第3回は6月16日開催予定で、弊社からは吉本が登壇予定です。
コアな技術的発表からサーバーサイドKotlinの導入話まで幅広い発表が聞ける勉強会となっておりますので是非ご参加ください!

server-side-kotlin-meetup.connpass.com

二部として登壇者や参加者とコミュニケーションの取れる懇親会も有りますのでそちらも是非!!

Tech Team Journalにて、対談記事を掲載いただきました

こんばんは、justInCaseTechnologies CTO の大畑です

Tech Team Journal にて、株式会社デジタルハーツ CTO 城倉氏との対談記事を掲載いただきました。

ttj.paiza.jp

色々と書いていただきましたが、当社の魅力としては以下な感じです ✨

  • レガシーなイメージの保険業界だが、モダンな技術・手法を積極的に取り入れている
  • 優秀なメンバーが集っており、チーム主体で提案・意思決定している
  • 事業と開発が一体となったスクラムで、プロダクトを作っている

当社にご興味を持っていただけた方は、まずはお話できると嬉しいです 😄

TwitterMeety でも、お気軽にご連絡ください!

もちろん、転職意欲がなくても大丈夫です

justincase.jp

Vercel Enterprise 導入しました

こんにちは。justInCaseTechnologiesのwebフロントエンドエンジニアのkondeiです

この度、当社は Vercel Pro から Enterpriseプランへと変更しました

差分は Pricing – Vercel の表にある通りです

これから検討している方に参考になりそうな情報としては、

  • 契約締結に向けたメールのやり取りについて、こちらからは日本語で書いて送信できた
  • 日本語ができる方によるサポートを受けれている
  • Onboarding Support (Training sessions and shared Slack channel with a dedicated Customer Success Manager.) とあるように、slackによるサポートがある
    • ただし詳細は契約内容による

があります

また、メンバーのohataさんと協力して作った導入申請書の一部を公開します(サービス比較など、不完全な部分も多いですが)

要点としては、メンバーを増やせるということ、SLAがあるということがポイントでした

こういう作業で個人的に印象が深かったのは、非エンジニアに対して必要性が分かりやすい稟議を出すために、工数をどれくらい削減するか見積もるという視点が得られたことでした

導入したいサービス・ツール

概要

  • 現状、Webフロントエンド ホスティングサービスとして、Vercelを利用している。
  • 現状のProプランは、10人までしか使えない。
  • Webフロントエンドエンジニアの増強に伴い、Enterpriseプラン変更をしたい。

導入の目的・解決したい課題

Webフロントエンド エンジニアの生産性の向上

  • AWSエンジニアに頼らず自律して開発を進められる or (AWS特有の)インフラ管理・キャッチアップの工数を減らす
    • Preview を提供するための、デプロイ管理する工数を削減できる
      • 各案件・商品に対して、Preview を迅速・並行して提供することで、社内外の確認を円滑に実施できる
      • Next.js の開発元として安定している、管理・構築が不要
    • Webフロントエンドエンジニアが使いやすい、ドメイン管理機能がある
    • Webフロントエンドエンジニアが使いやすい、アクセス保護機能がある
      • AWSLambdaなどで、Basic認証の実装・連携が不要
      • EnterpriseだとSSO Protectionも選べて、チームの大規模化に伴うパスワード共有の煩雑さを解消しやすい
    • Webフロントエンドエンジニアが使いやすい、サーバーレスファンクション機能がある
      • AWS Lambda のキャッチアップ、構築・運用、管理工数が不要
      • ちょっとしたAPIを実装できる
      • 横断的に挟みたい処理を実装できるnext.jsのmiddlewareがvercelだとサーバーレスファンクションに乗るので楽に利用できる
  • web frontendフレームワーク最大シェアのNext.jsの開発元としてその機能を完璧にサポートし、継続的により良い機能を取り入れられる
  • 分離されたインフラでさらなるビルド速度、実行キュー待ちの削減

Vercelで、Webフロントエンドエンジニア or SRE の工数を、6時間/人月 以上 は 削減している

※ 削減できる工数に加え、そこから生み出すクリエイティブに、より価値がある

現状のプランのままだと、10人までしか使えない。

  • 現状10人利用しており、更にWebフロントエンジニアが数人入社する(やりくりが限界)
  • コミットのAuthorが Vercelのmemberである必要がある
  • デプロイ時の担当者がボトルネックor切り替え工数がかかる
  • 当社は自律したプロダクトチームを推進、MoveForwardでフルスタックな関わりを推奨している

Vercel 以外のものに移行するにも工数はかかるので、Vercelのプランを変更するのが良い。

事業継続・事故防止・損失回避

  • SLA 99.99% を保証する ( 現状のプランのままだと、SLAがない )
  • 各チームの然るべきメンバーが常に利用できる状態にしておくことで、万が一の対応にも備える。

導入にかかるコスト

費用

契約に関わるので秘匿

工数・スケジュール感

  • 導入そのものにコストは掛からない(プラン変更のみ)
  • Enterprise契約の締結なので、段取りに1-2ヶ月かかる
    • 英文契約書のレビュー・締結など
  • Webフロントエンドエンジニアがジョインする時期までにはプラン変更をしたい

検討した選択肢

要件・比較ポイント

  • Next.js 機能のサポート
  • サイトパフォーマンスの上げやすさ
  • 管理工数(CI/CD連携、ビルド など構築、そのキャッチアップ)
  • その他、生産性に寄与する機能

Vercel

Pros

Cons

  • コスト ○
    • コストパフォーマンスは有る
  • Amplify並の細かい設定はない
  • 複数環境ビルドには若干準備が必要

参考

serverless-nextjs を使ってAWSによしなに配置

Pros

  • next.js機能のサポート ○
  • サイトパフォーマンスの上げやすさ ○
    • Lambda@Edgeに配置されるので良いと思われるが、AWSの使い方による

Cons

  • 管理工数 ×
    • githubと連携してpreviewする方法などは不明
    • なんやかやで勉強と手間がかかることは間違いない
  • その他、生産性に寄与する機能 ×

参考

https://www.serverless.com/blog/serverless-nextjs/

https://qiita.com/fumiki/items/5f4408ce844520a922c2

AmplifyとかS3とかに配置

Pros

  • コスト

Cons

  • next.js機能のサポート ×
    • dynamic routingやSSRのような、staticで済まない機能が必要になった場合に対応できない
  • サイトパフォーマンスの上げやすさ△
    • AWSの使い方による
  • 管理工数 ×
    • Amplifyはビルドが保留のまま止まることがそこそこ多く不安定で支障が出ることがある
    • キャッチアップが難しい
  • その他、生産性に寄与する機能 ×
    • AWSとしてはある、キャッチアップなどが必要

参考

EC2にnode serverとして配置

Pros

  • Next.js 機能のサポート ○
    • SSR, ISRなどの基本機能は使えるがvercel + nextで楽に使えることが前提の機能は厳しいと思われる

Cons

  • 管理工数(CI/CD連携、ビルド など) ×
    • 仮想サーバー管理コストがかかるし、CI/CD を自前で頑張ることになる
  • その他、生産性に寄与する機能 ×

参考

netlify

Pros

  • Next.js 機能のサポート ○
  • 管理工数(CI/CD連携、ビルド など) ○
  • その他、生産性に寄与する機能 ○

Cons

参考

https://www.netlify.com/blog/2020/05/04/building-a-markdown-blog-with-next-9.4-and-netlify/

できるけどあえてnext.jsを開発してるところと違う会社のjamstackにする必要がない

セキュリティ・リスク

都合上内容は割愛

その他、リスク・注意事項

都合上内容は割愛

【開催報告】justInCase社内でGraphQLハッカソンを開催しました

justInCaseTechnologies、ソフトウェアエンジニアの小笠原です。

2022年1月7日に、社内で「GraphQLハッカソン」を開催しました。会社初の試みであり、準備期間も短かったのですが、概ね好評のうちに1日を終えることができました。

チームが成長し続けるための一つのアイデアとして、ここに共有させていただきます。

f:id:justInCaseTechnologies:20220107193333p:plain
ハッカソン集合写真

背景

justInCaseTechnologiesでは現在、保険業界特化SaaS「joinsure」の様々な機能を開発しています。

そうした中で適切な技術選定のためのインプットとすべく、チームでGraphQLについて学ぶ機会がほしい、という声がきっかけでした。

イベント内容

開催まで

ハッカソンを開こうというアイデア自体は2021年の9月ごろからありました。

f:id:justInCaseTechnologies:20220107190913p:plain
社内でGraphQLハッカソンを開くことについて、Slackの投稿

話が本格化したのは年末になってからです。私達はスクラムで開発を進めているのですが、年末年始にスプリント外の期間を設け、そこでハッカソンを開いてはどうか、というアイデアが生まれました。

そこからは急展開で、ハッカソンの形式・内定者への招待・社内での告知などが全て1〜2週間の内に行われました。

イベント当日

ハッカソンには、joinsure Engagementチームの1名を除く全員と、joinsure Recordチームの1名、さらに内定者が1名の合計6名が参加しました。

個人とチームどちらの参加にするか悩みましたが、2名1チームとして合計3チームを完全にランダムに作りました。これはコミュニケーション促進の面でも、審査時間の短縮の面でも良かったと思います。

朝9時に集合し、自己紹介とチーム分けのあとは17時までひたすら開発タイムでした。ちなみに、ミーティングやお客様対応がある人は途中で出たり入ったりが可能になっています。

開発形式はどのチームもペアプログラミングで、コミュニケーション手段は内定者がいることもありGoogle MeetのBreakout Roomを活用して行われました。

審査

17時の開発終了後、CTOやPdMも集まっての発表・審査タイムがありました。

面白かったのは、3チーム中2チームがTwitterライクなWebアプリを作ったことです。

f:id:justInCaseTechnologies:20220107192152p:plain
TwitterライクなWebアプリ

f:id:justInCaseTechnologies:20220107192308p:plain
TwitterライクなWebアプリ2

いずれもツイートやリプライ、ライクができる、1日で作ったとは思えないクオリティでした。

実はある意味合っていて、参加者の何名かは事前にボイラープレートを作っていました。勉強も目的なので、当然アリです!ちなみにボイラープレートはこちらです。

github.com

github.com

発表後は審査タイムがありました。ちなみに、審査基準は以下のとおりです。

  • 発見があったこと
    • GraphQLのドキュメントを深く読み、みんなが気づかなかった仕様を知っていること
    • エコシステムをよく調査し、便利なライブラリを見つけたこと
    • Engagementでの使用を見据えて、いい感じのユースケースを思いついていること
    • etc...
  • サービスがイケてること
    • 実際に動くこと

審査の結果、フルスタックのボイラープレートを自作して参戦したやる気モリモリのメンバー3月入社の内定者のチームが優勝しました!

作成したのはTwitterのクローンで、リプライやライクができるなど、本物そっくりでした。1日で作成したとは思えないクオリティでした👏

ふりかえり

ハッカソンの後はふりかえりを行いました。

1日を振り返って思いついたことを、FUN, DONE, LEARNのベン図に分類して記述していきました。

f:id:justInCaseTechnologies:20220107193139p:plain
FUN DONE LEARN

普段の開発とは違った環境で、集中できた&学びになった、という意見が多く寄せられました。実際に発表中は驚きの声やツールの紹介などの知見共有も多くあり、開発工数の1日を使ってイベントを開いた意味が十分あったと考えています。

まとめ

チームで勉強する時間がほしい!という意見から始まり、この度業務時間を使ったハッカソンを開くことができました。

チームが成長するためには、先を見据えた勉強が絶対に必要です。忙しい開発と勉強とを両立するための手札の一つとして、ハッカソンを加えることができました。

最後に

justInCaseでは、保険SaaS「joinsure」を一緒に開発するメンバーを募集しています!

このブログの投稿を見て、良い組織だな、と思った方、まずはお話してみませんか?

こちらからご連絡お待ちしております🙏

justincase.jp

AWS DevDay Online 2021登壇のご報告

ソフトウェアエンジニアの @xhiroga です。

2021年9月39日、AWSの数多のカンファレンスで最も開発者に特化した AWS Dev Day Online Japanに登壇してきました。
資料はこちらです → [AWS CDK] 1,000+のCloudWatch Alarmsを自動生成する技術
感想を添えてご報告いたします。

TL;DR

  • 応援してくださった皆様に感謝
  • 登壇をネタに様々な人と繋がれた
  • これまでのAWS CDKに関するLTの集大成
  • Twitterの反響・よいアンケート結果

応援してくださった皆様に感謝

AWS Dev Day Online JapanはCFP制で、一般人気の高いセッションが採用される仕組みでした。
Twitterのお知り合いの皆様やそうでない方にも「見たい!」との反応をいただけたのが、今回の機会につながったと考えています。ありがとうございました!良いものをお届けできたでしょうか?

登壇をネタに様々な人と繋がれた

AWS CDKに関する登壇であったことから、周囲の知見のある方にレビューや練習を申し込ませていただきました。
コロナ禍のリモートワークの折、しばらくぶりのエンジニアの方と練習ついでに雑談もでき嬉しかったです。

また、資料レビューにはAWS CDKユーザーとして大先輩(とこれまで勝手に尊敬していた)のtmkさんにもご協力いただきました。本当にありがとうございました!
CDKアプリを我流で書いてきた自覚があったので、登壇前に客観的なご意見をいただけてとても安心しました。

これまでのAWS CDKに関するLTの集大成

実は今回初出のネタは多くなく、私のCDKに関するLTの集大成だったりします。
普段から気づいたことを細かく発信しており、それが今回の登壇につながったと感じております。

Twitterの反響・よいアンケート結果

登壇中・登壇後にTwitterで知らない方(でもCDK Loverの方)と繋がれるのが登壇の魅力だな、と思っています。
情報は発信する人に集まる、という言葉もありますしね。

登壇後しばらくして事務局からアンケートもいただき、詳細は共有できないものの(私だけで)累計数百人のオーディエンスがいたとのことでした。初めての数でびっくりしています。 (Startup Architecture of the Year 2019も 50~200人くらいだった気がするので(目測)、それよりも多い人数でした)

まとめ

いろんな方の応援のおかげで、得難い経験をさせてもらいました。
今後も社内で面白い取り組みをして発表していきたいので、その際はぜひご視聴・ご意見いただけると幸いです!

面白いSREの仕事をしたい!という方はこちらからご応募お願いします🙏

チケット管理ツール再考察 YouTrack vs ClickUP

ソフトウェアエンジニアの @xhiroga です。
保険SaaS joinsureのプロダクトを新規開発するにあたって、チケット管理ツールを再選定したので記録に残します。網羅的とは言い難いですが、多少なりともお役に立てば幸いです。

結論

  • YouTrack, ClickUpともにプロダクト開発に十分利用できる
  • YouTrackはデータ構造が、ClickUpはWebベースのUXが勝る
  • 複数人・複数チームでの開発ではYouTrackが、小規模開発ではClickUpが向いていると判断した

前提

joinsureの開発はスクラムで行っています。
したがって、BizDev, PdM, デザイナー, エンジニアの全関係者が同じボードを使えると望ましいです。例えば、「カスタマーサポートに寄せられたご意見の分析」「ユーザーストーリーからオブジェクトを抽出する」といった仕事もチケットで管理したい、というわけです。

さらに言えば、バックオフィスではAsanaを使っており、これを統一したい思いもありました。

また、justInCaseは(主にWeb版のUXの悪さを理由として)過去にJiraからYouTrackに移ってきた経緯がありました。したがって、メンバーがストレスなく使えることは強く意識していました。

比較

YouTrackとClickUpを、それぞれ1年/半年利用して感じたPros/Consです。

YouTrack

Pros

  • データ構造が優れている。具体的には、プロジェクトとボードの関係性が1:1ではなく、1:Nである。
    • Jiraなどではどんなボードを見たいかを考えてからプロジェクトの単位を考える必要がありましたが、YouTrackではボードに表示するチケットが所属するプロジェクトをクエリで指定できます。プロジェクト設定で余計に悩むことが減り、ありがたいです。
  • 全体的に柔軟なカスタマイズが可能。プロジェクトに任意の型の属性を追加したり、ダッシュボードやレポートを作成したり、スプリントの期間を自由に指定できたり、等々。
  • JavaScriptライクな記述ができる、柔軟なワークフロー

Cons

  • 設定が柔軟すぎて、初心者がプロジェクトを設定すると何かしら間違いが起きる。
    • 例えば、権限の設定ミスでボードが見えなくなる事故が年に3回くらい起きる。
  • ちょっとしたサービス間連携にもスクリプトを書かされる。
    • いまどきSlack通知やGitHub連携はWeb画面からポチッと設定できて当然だが、(一部例外はあるが)JavaScriptを書かないといけない。
  • ネイティブアプリがありえないくらい使いづらい。もっさりしている上に必要なボタンが探しづらいUI/UX。

ClickUp

Pros

  • 開発者向けツールと一般的なタスク管理ツールのいいとこ取りといった印象
    • Web画面のUI/UXがよい。チケットの編集ひとつとっても、YouTrackに比べて表示が大きく、操作がしやすい。
    • 繰り返しタスクも作れるので、営業やバックオフィスの人にも使ってもらえるかも。
  • 2017年の創業だけあり、Webサービス間連携はコンソールからポチで可能。
  • ゲストを招待できる。例えば特定のボードに対して、社外の人に参照権限を渡すことが出来る。
  • 比較サイトでのレビューが圧倒的に良い
    • G2 Crowdでレビュー数が約100倍あり、レートもYouTrackに勝っている。
    • 単なる人気ではなく、開発者以外でも使える間口の広さが反映されていることは考慮すべき。

Cons

  • プロジェクトとボードが紐ついており、例えばチケットをスプリントに移動すると、元々どのプロジェクトに紐ついていたかわからなくなってしまう
    • これにより、プロジェクトをエピックやユーザーストーリーに見立てる運用ができなくて辛い。
  • 2021年現在、同時編集にバグがある。正確なことは不明だが、複数人で編集していると操作(チケットを完了にする、スプリントを閉じる、など)が何度やっても反映されないことがある
    • これがスクラムイベント中に多発するので本当に困る
  • チケット番号が数字ではないため、GitHubの機能でチケット番号をリンク化することができない。

評価

両方ともいいところと悪いところがハッキリしており、(いいとこ取りのツール出てこないかな...)と本当に思いました。笑
業務に差し支えるのはどちらかと考えると、複数人・複数チームでの開発ではClickUpの欠点(特にプロジェクトとボードの関係性とバグ)が問題になると考えています。比べると、YouTrackの欠点は運用でカバーできる範囲ですね。

結論

justInCaseでは久しぶり(1年ぶりは当社では久しぶりです)のチケット管理ツールの見直しでしたが、YouTrackを続投する、という結論にいたり、そのようにチームメンバー・他チームの皆さんにも共有した次第です。

一方、チケット管理ツールのような激戦区のSaaSでもこれだけ改善できるポイントがあるのだな、と、今回比較して少し意外な気持ちになりました。
ましてや保険業界のSaaSともなれば、改善すべきことは山積していますね!

justInCaseではツールへのこだわりのある素敵なメンバーを大募集しています。なにかのご縁ですので、ぜひ一度お話できれば幸いです🙏