（※本記事は去年の弊社のQiita アドベントカレンダーに投稿したものをリライトしたものになります。反響が嬉しすぎたので自社ブログにも載せて擦ります。） はじめに リンクアンドモチベーションで、エンジニアをしています、宮田と申します。 自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。 今回はその中で話したことを共有します。 公開するにあたって分かりやすさを重視して少し脚色していますが、大筋はリアルなものです。 見積もりに対する課題感 ぼく「約束は開発を遅らせるという記事を最近読んだのですが、その通りだと思ったのですよね。」 さて、チームの外に対して約束するために「この機能1ヶ月で出せるよね？」とプロダクトの人やマネージャーに聞かれたら。これは返事に悩む。「ラフで構わないから」って言われて伝えたら、それがコミットメントになってしまったのを過去に何度も見たことがあ

こんにちは、フロントエンドエンジニアの岡田です。 今Q（7月から9月期）は開発のメトリクスとしてリードタイムの改善に力を入れておりました。 今回取り組んだことをご紹介させていただければなと思います。 最初に結論 今回はリードタイムとデプロイ頻度を測定しました。 約2ヶ月の改善活動の結果、以下のような結果を得ることが出来ました。 ※この記事では主にリードタイムに触れたいと思います。 リードタイム デプロイ頻度 Before 12日 2回/週 After 2日 4回/週 ※リードタイムはfirst commitからdevelopブランチへのマージ時間を計測しております。 開発メトリクスとは？なぜ、開発メトリクスを測定したいのか？ 初めに 「開発メトリクス」 とは何かを定義したいです。 メトリクスの定義とは、さまざまな活動を定量化し、その定量化したデータを分かりやすく加工した指標とされており、「

はじめに はじめまして、リンクアンドモチベーションでプロダクトマネージャーを行っている原田です。 主に担当させていただいているのは、弊社サービスであるモチベーションクラウドの「新規顧客の獲得」をミッションとした開発組織です。 （具体的な業務は、過去に弊社野田が投稿したこちらの記事をご覧ください！！) 本記事では、私が所属しているチームが「タスク志向」から「ミッション志向」になるまでの道筋をご説明いたします。 そもそもの組織の変わるきっかけ モチベーションクラウドシリーズの開発組織は昨年の夏に、大きな組織編成が行われ、 これまでは「PJT単位でチーム編成が変わる」組織だったところから、「ミッション別でチーム編成が固定される」組織へと変わりました。 （詳しくは、過去に弊社有田が投稿したこちら記事をご覧ください！） それにより、これまでは「PJTの成功（リリース）のために頑張る」であったり、短い

こんにちは！リンクアンドモチベーション開発組織 広報担当の有田です。 今日は、開発組織の体制についてご紹介したいと思います！ モチベーションクラウドシリーズの開発は、2018年から内製化を進めてきました。 当時の開発はパートナーさんにお願いしており、社内のエンジニアは0名からのスタートでしたが、今では40名以上の開発メンバーが所属*1。 右肩上がりで組織規模が拡大しています。 開発メンバー 社員数推移 組織の拡大によって、できることが大きく増えた一方、連携の難易度が上がったり、メンバー一人ひとりの状況が見えづらくなったりと、不具合も出てきていました。 そこで、昨年2021年に、開発組織の体制を再編。 今日はその変遷も含めて、お伝えします！ これまでの体制 現在の体制 まとめ これまでの体制 2018年の内製化スタート時から2021年上期まで、開発組織は「職種別」でチームが分かれていました。

どうも、リンクアンドモチベーションの伊藤です。 モチベーションクラウドシリーズのエンジニアをしています。 新規サービス開発を行っている際に改めて「権限」をどう扱うべきか悩んだため、ここでまとめていきたいと思います。 結論から述べると、ロールベースアクセス制御(RBAC)を中心に、apiごとにpolicyを定義するようにしました。 前提 どう権限管理を設計していくか 要件や条件の整理 権限管理の実装 今後に関して 前提 設計を始める前に考えていたことはこんなことでした。 ユーザーにわかりやすい機能制限にしたい 開発者にもどうなっているかわかりやすくしたい 新規開発なので、拡張性も多少は意識したいが、工数もかけたくない 特に前に担当していたサービスでこの権限管理周りで苦労した経験があるので、開発者体験もできるだけ落とさないというのも重要視しようと思っていました。 どう権限管理を設計していくか