目次

• 目次
• 0. はじめに
• 1. レビューされる側だった頃の問題点
• 2. レビューと設計の関係性
  • 2.1 なぜレビューが必要なのか
  • 2.2 なぜ「設計」が関係するのか
• 3. コードレビュー指摘の傾向から学んだこと
  • 3.1. 様々な設計原則
  • 3.2. 設計指摘を具体的に理解する
  • 3.3. 設計指摘をものにするためには？
• 4. before / after で見る設計指摘の具体例
  • 4.1. SRP: 「責務が多い」と言われたケース
    • before: 1つのクラスに複数の責務がある
    • after: 責務ごとに分離する
  • 4.2. OCP: 「将来増えそう」と言われたケース
    • before: 条件分岐で処理を切り替えている
    • after: 振る舞いを分離する
  • 4.3. DRY: 「共通化できそう」と言われたケース
    • before: 同じコードが複数箇所にある
    • after 其ノ壱: 知識を一箇所に集約
    • after 其ノ弐: 処理を一箇所に集約
  • 4.4. before / after から学んだこと
• 5. 実装時に持つべき視点
• 6. 同じ立場の人たちへ
• 7. まとめ

続きを読む

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp

マネージャーの役割を一言で言うなら、私は「管理」ではなく “支援” だと思っています。 現場の専門性を信じ、意思決定の質を上げ、チームが成果を出しやすい状態をつくること。

この記事では、そのために私が意識している2つの視点を紹介します。

• コト（成果・意思決定）には解像度を上げる支援
• 人（成長・キャリア）には未来を描く支援

※前提として、最適な距離感はチームの成熟度・状況・業務特性で変わります。ここでは「私の経験ではこうすると機能しやすかった」という一例として読んでください

• うまくいっている“ように見えた”チームで、手戻りが起きた話
• コトの解像度を上げる＝「詰める」ではなく「迷いを減らす」
  • 1) “目的” をそろえる支援（何のためにやるのか）
  • 2) “事実” を共有しやすくする支援（いま何が起きているのか）
  • 3) “意思決定” を軽くする支援（決めるのが怖くない状態）
• 「現場を分かれ」ではなく「現場が強くなる」ための関わり方
• 人には「未来」を：日々のフィードバックを“支援”に変える
  • 未来が共有できると、指摘が「評価」ではなく「投資」になる
• 情報の流れを整える：支援が届きやすいチームにする
• AIで解像度を上げる（ただし守るべきものは守る）
• まとめ：解像度は、現場への敬意を形にする手段

続きを読む

こんにちは。 株式会社ラクスで、楽楽精算のプロダクトデザインチームのリーダーをしているimamuです。

ラクスでは現在、「ベストオブブリード」戦略から「統合型ベストオブブリード」戦略へ進化を目指し、製品開発を進めています。 www.rakus.co.jp www.rakus.co.jp

私たちプロダクトデザイン組織でも、デザインガイドラインの整備やUIリニューアルを行っています。 tech-blog.rakus.co.jp note.com

その一環として、UXライティングガイドラインについても共通化と各製品への浸透を目指して取り組んでいます。

でも実はこのライティングガイドライン、私たち自身が楽楽精算のプロダクト開発に関わる中で感じていた、ごく個人的な実務上の困りごとから生まれたものでした。

この記事では、現場の小さな課題感が、どのように事業戦略をプロダクトに落とす取り組みへと広がっていったのか、そのプロセスをご紹介します。

• 楽楽精算でぶつかった「言葉」の課題
• 楽楽精算ライティングガイドラインの立ち上げ
  • なぜライティングガイドラインなのか
  • ライティングガイドラインの判断基準
  • ライティングガイドラインで何が変わったか
• 共通ガイドラインへの進化
  • 製品戦略とライティングガイドライン
  • 共通化と浸透に向けた取り組み
  • 実務での活用状況
• おわりに

続きを読む

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp

以前は自社の戦略について書きましたが、今回は視点を変えてみます。

これまで大手・ベンチャー・外資など様々な企業で社内システムに触れてきたユーザーとしての経験、そして現在バックオフィス系SaaSに携わっている提供者としての知見。 これらを踏まえて、自分なりに整理してみました。

目次

• はじめに：SaaSの普及と、残された「巨大な壁」
• 第1章：前提となる「企業の基幹システム」4つのアーキテクチャ
  • 1. Fit to Standard（ERP一本足打法）
  • 2. Two-Tier ERP（2層構造：ERP × SaaS）
  • 3. Composable ERP（レゴブロック型）
  • 4. SaaS Unbundling（脱SaaS・完全内製回帰）
• 第2章：なぜ「SI」や「AI × BPO」だけでは届かないのか
  • SI（システムインテグレーション）の課題 ── 「要件定義」の壁
  • AI × BPOの課題 ── 「ブラックボックス化」の壁
• 第3章：現場を変える「専属シェフ」 ── Forward Deployed Engineer (FDE)
• 第4章：システムをつなぐ「万能翻訳機」 ── 中間システムとOntology
  • 「データ」に「意味」を与える (Ontology)
  • 異なる言語を翻訳する「万能翻訳機」
  • 第5章：AI時代の新しいアーキテクチャ ── 「自律的AI」への道
  • AIが「働く」ための地図
• おわりに：バックオフィス・プロダクトの解像度を高める

続きを読む