【開発カルチャー発信 vol.1】原価計算システム開発チームの開発理念を大公開!

こんにちは、キャディでバックエンドエンジニアをしている朱です。

この記事は CADDi Advent Calendar 22 日目の記事です。昨日は、高藤さんによる「tracing crateを利用したRustのlogging方法について」でした!

今回は、私が所属している原価計算システム開発チームの開発理念についてお話ししようと思います。 この記事を通してキャディの開発チームに息づくカルチャーの一端を感じ取っていただければ幸いです!

(タイトルを勝手に vol.1 としていますが、反響が良ければきっと企画化されるはずでしょう…)

[toc]

開発理念を定めた経緯

はじめに、私たちのチームで開発理念を定めるに至った経緯について簡単に触れておきます。

原価計算システム開発チームは現在、総勢9名(内 PM が1人、デザイナーが1人、残りがエンジニア)で社内で最大規模の開発チームです。

今年6月のプロダクトリリースを経て運用体制が一定周り始めたタイミングかつ、メンバーのアサイン変更や新たな仲間を迎えるにあたって、これまでのチームのスタンスを保つ/発展させていくために最低限の明文化を図ったというのが策定の背景です。

また、PM が他部署との兼任になったというのも理由の1つでした。

それまではユーザーとのコミュニケーションやそこから得られた示唆をもとにした意思決定は PM が主体となって行っていましたが、チームとして開発のスピードを落とさないためにも、なるべくエンジニア主導でのコミュニケーションや意思決定の比率を上げていく必要性がありました。明文化された理念は、こういった行動を取る際のある種の拠り所としても機能しています。

5つの理念

さて、ここからはチームに存在する5つの開発理念をそれぞれ深掘っていきたいと思います。

(社内外の)ユーザーからの信頼、期待値を毀損せず常に高めるべく努力すること

5つの中で最も重要かつ守るのが難しいのがこの一文だと感じています。 信頼、期待値というのは得てして積み上げるのは簡単ですが崩れ去るのは一瞬だからです。

プロダクトにとっての期待値の表れの1つに、ユーザーからの「こういう機能が欲しい!」という要望があります。 大前提として、いただいたフィードバックは全て資産であり、チームとしては可能な限り要望に答えてプロダクトをより使いやすくしたいと考えています。(5つ目の理念が正にそれを明文化したものです)

しかし、現実には開発リソースは有限なので中にはすぐには答えられない要望もあります。だからこそ、そのような要望をくれたユーザー1人ひとりにリスペクトを持って「なぜ今その機能の開発に取り組まないのか/いつになればその負は解消されるのか」を丁寧に説明するように心掛けています。

その上で、待望の機能をリリースした暁には Wow を届ける = 期待を上回る価値を提供して初めて、ユーザーからの信頼は保たれるのだと思うのです。

ユーザーに利便性を生むこと。利便性とはなにかをやらなくて良くなること

2つ目の理念は非常にシンプルで分かりやすいですね。

10X の矢本さんが同じような趣旨のツイートをされていましたが、弊社のような toB の領域でプロダクトを提供している会社では特に意識する必要がある考え方だと思っています。

我々が挑んでいる課題は必ずしもプロダクト(= ここでは狭義のプロダクトでシステムの意)だけでは解決し得ないものであり、両輪のもう片側である"ヒト"がより本質的な業務に時間を使えるようにするためにも、プロダクトは出来る限り「やらなくて済むこと」を増やすのに心血を注ぐべきなのだ、と解釈しています。

何かをリリースする、変える上での説明は丁寧すぎるレベルでやること

私たちが作っているのは社内のオペレーションで用いる業務システムであり、プロダクトの変更がすなわちオペレーションの変更に繋がります

もし、変更内容が社内に伝わりきらずにオペレーションが古いまま運用されてしまうと、我々にとってのエンドユーザーであるキャディの顧客・SPにまで間違った情報が渡ってしまうというリスクがあります。実際に、過去にはリリース内容の周知が不足していたことでバグの検知が遅くなり、顧客に間違った価格が流出しかけたという事象がありました。こうした背景を踏まえて、3つ目の理念は付け加えられています。

また、直近ではプロダクトの機能拡張によりステークホルダーが社内外に徐々に広がっており、今までよりも一層この理念を意識する必要が出てきています。長くなりがちなリリース内容をなるべくスムーズに認知してもらうための取り組みとして、告知文に絵文字を用いることで関心を持ってもらおうというUXライティング的な動きも草の根的に始まっています。

Quipu というのが原価計算システムの名前で、インカ帝国で使われたそろばんのようなものが由来です(実は本邦初公開!?)

リリースした後はリアルタイムにユーザーのそばでフォローすること。そして自分たちの目と耳で課題を見つけること

3つ目とも関連しますが、リリース時の周知の徹底だけでなくリリース後のフォローも大切な要素です。 これを実践するために、私たちのチームでは週に一度ユーザーの業務を見学する会を行っています

見学会では、原価計算システムとその他の業務システムを用いた一連のオペレーションの様子を画面で共有してもらい、主にUX面での課題がないかを観察しています。やはり実際にプロダクトが使われているのを目にすると、思いもよらぬところで躓いてしまったり本来不要なはずの作業を繰り返してしまっていたり、当初のUX設計では考慮できていなかった点があぶり出されることが多いです。

このように一次情報を絶えず取得できる仕組みがあるのは開発側としては願ったり叶ったりの状態ですが、ユーザーにとっては負担にもなり得る取り組みを受け入れてもらっているのは、ひとえに日頃の信頼関係が築けているからこそだと思っています。

加えて、大きなリリースがあった場合はアドホックに説明会を開いたり、課題がないか個別でヒアリングしたり、サポート体制には積極的に工数を割くようにしています

もらったフィードバックすべてに感謝しリスペクトをもって扱うこと。そして基本なるはやで対応すること。しかし、そのまま鵜呑みにして対応するのではなく、本質的に必要な対応を行うこと

最後の理念もユーザーからのフィードバックにまつわるものです。 フィードバックに対するチームのスタンスについては先述した通りなので、ここではもう少し具体的な話をしようと思います。

試しに直近1ヶ月のユーザーからのフィードバック件数を数えてみたところ、平均すると週に6-7件ほど要望が来ていることが分かりました。これは対ユーザー数比率で言うと全体の約3割の方が週に一度はフィードバックをくださっている計算になります。

また解決までのリードタイムについては、いただいた要望の内軽微な修正でUX向上が図れるものの多くは次のSprintでの解消を、中期的に取り組む必要があるものについても長くて1ヶ月程度のスパンで解消してきています。(中にはいち新機能として開発が必要になる要望も含まれるので、さすがにそれは本腰を入れて長期的に対応します)

では、ユーザーの要望を取り入れ続けていわゆるキメラ的な開発を続けているのか?と言われると、そうではないと思っています。実際にユーザーの本質的な課題を特定して解決した事例として、先月行ったとある機能を廃止した事例を取り上げてみましょう。

原価計算システムには入力した諸々のデータを確定させ以降は編集できなくする、いわゆる「ロック機能」が存在しました。これは機能を設計した当初には製造業のバリューチェーンウォーターフォール的に捉えていたために、後工程にデータを受け渡す際には情報を確定させることで不確実性を下げることを意図したものでした。

しかし、蓋を空けてみると実際のオペレーションではロックを行ったあとにも情報を修正することは度々行われており、本来はよりアジャイル的な情報の扱いができるUXを指向すべきだったことが明らかになります。もちろん、ロック後にもデータを修正できる手段としてバージョン管理の機能もセットで提供していたのですが、キャディとして取り扱う案件の規模が拡大するにつれて修正にかかるインタラクションコストが無視できないものになってきました。

ユーザーからはバージョンアップにかかる手間を削減できないか?という問い合わせが繰り返し寄せられましたが、チームで「元々この機能で解決したかった課題は何なんだっけ?」と議論を重ね、結果としてロックのタイミングの後倒しと改修が完了するまでの一時的な機能の停止を決定しました。

以上のように、UXを毀損しているようなケースではたとえそれが時間をかけて開発した機能だとしても躊躇なく捨てる意思決定が出来ることが「本質的に必要な対応」なのだと考えています。

一緒にチームのカルチャーを育んでいく仲間を募集中!

いかがだったでしょうか?冒頭でも述べましたが、この記事を読んでキャディの開発チームのカルチャーに興味を持っていただけた方が少しでもいらっしゃれば嬉しい限りです。

今回取り上げた開発理念はまだまだ発展途上のもので、これからも既存のチームメンバーや今後キャディにJoinしてくださる皆さまの手によって育まれていくものだと思っています。控えめに言っても最高のチームが集まっているので、まずは話しを聞いてみたいという方も Twitter などで気軽にご連絡いただければ幸いです!

明日はそんな原価計算システム開発チームの高橋さんによる「React + Neo4j によるコストモデル可視化の取り組み紹介」です。お楽しみに!


キャディではエンジニア・デザイナー・PMなど幅広い職種の皆さまを募集しています! エンジニア採用サイトはこちらからどうぞ!