参考資料

バージョン202104→202506の変更点

約1分で読めます

主な変更点

読み取りにくい文章を校正
意味を明瞭にするためにより具体化
時代に合わない表現や既に当たり前の内容を現状に合わせて変更

46件 · 保存時点の資料

変更前: 組織のガイドラインが存在しない、もしくはガイドラインが存在していても例外が常態化している。
変更後: スパン・オブ・コントロールを守るための組織のガイドラインが存在しない、もしくはガイドラインが存在していても例外が常態化している。
変更理由: 具体化

変更前: 従業員は自身のパソコンへの自由なソフトウェアのインストールを過度に制限されている。
変更後: 開発マシンにソフトウェアをインストールするには煩雑な申請が必要で、過度に制限されている。
変更理由: 具体化

変更前: 社内ナレッジの管理のために、大多数の従業員が気軽にwebベースの文書が作成できる、Wikiサービス等を導入しているか。
変更後: 社内ナレッジの管理のために、社内統一のドキュメント管理サービスを導入し、構造化されているか。
変更理由: 環境変化

変更前: 各部門は、自部門の仕事をメールベースあるいはチャットなどフロー情報を扱うツールではなく、ストック情報を扱うチケットツールベースで受け取る環境があるか。
変更後: 他部門にタスクを依頼する際に、メールやチャットをただ単に送るのではなく、直接的あるいは自動的にチケットツールなどでストック情報として管理できるようになっている。
変更理由: 環境変化

変更前: 採用したい人材の基準を明確化したJob Description（求人票）が存在し、現場エンジニアとともに表現を見直すためのワークフローが整備されていて、直近一ヶ月以内に更新されているか。
変更後: 採用したい人材の基準を明確化したJob Description（求人票）が存在し、現場エンジニアとともに30日程度の間隔で見直し、更新しているか。
変更理由: 継続的に更新されていることを確認する文章に変更

変更前: 「募集職種：Webエンジニア」のように曖昧な表現しかされておらず、どのようなスキルやキャリアが求められているのかの解像度が低い。
変更後: 全社的に固定された採用プロセスに従うことが重視されており、候補者状況に合わせた採用プロセスの変更調整が一日以内にできない。
変更理由: 5-4と重複のため新指標追加

変更前: 古いバージョンのOSやブラウザでしか動作しないツールが使われている。
変更後: サポート切れの古いバージョンのOSやブラウザでしか動作しないツールが使われている。
変更理由: 元のクライテリアは選定基準によってはBADではないため文章変更

変更前: セキュリティの意思決定は、定期的に行われているリスクアセスメントにともない、リスクとリターンを定量的に評価した上で行われているか。
変更後: セキュリティの意思決定は、定期的に行われている金銭的価値に換算されたリスクアセスメントにともない、費用対効果を定量的に評価した上で行われているか。
変更理由: 文章構成

変更前: 管理・監視できない領域のITサービスの利用が行われていること(シャドウIT)に対して対策が打てていない。
変更後: 管理・監視できない領域のITサービス・デバイスの利用が行われていること(シャドウIT)に対して対策が打てていない。
変更理由: 説明追加

変更前: データ集計・可視化等のためのBIツールを導入しており、エンジニア以外でも使うことができているか。
変更後: データ集計・可視化等のためのBIツールを導入しており、事業活動に関わる全ての人が適切な役割に応じて使うことができているか。
変更理由: 文章校正

変更前: CRM(顧客管理システム)、SFA(営業支援システム)を導入しており、お問い合わせや行動履歴を把握できているか。
変更後: CRM(顧客管理システム)、SFA(営業支援システム)を導入するなどして、デジタルデータとしてお問い合わせや行動履歴を把握できているか。
変更理由: 手段を非限定化

変更前: カスタマーサポートなど顧客接点となるスタッフから、課題の吸い上げができていない。
変更後: カスタマーサポートなど顧客接点となるスタッフから、課題の吸い上げができていない。または、ごく一部の顧客の課題しか吸い上げられていない。
変更理由: 説明追加

変更前: デザインシステムを用いて、デザイナーの介在なしにフロントエンド開発の５割以上が達成できている。
変更後: デザインシステムの整備されたUIライブラリを用いて、機能の仮説検証が半数以上できている。
変更理由: デザインシステムの本質的な要素に近づける形へ

変更前: プロダクトに関わるUIパーツは、動作するライブラリとしてまとめられているか。
変更後: デザインシステムの目的と具体的な設計情報を含めたドキュメントと、動作するUIライブラリの両方が整備されているか。
変更理由: デザインシステムの本質的な要素に近づける形へ

変更前: UIデザイナーが作成したデザインをソースコードに自動的に反映するためにツールを利用しているか。
変更後: オンラインコラボレーションに対応しているUIデザインツールを、プロダクト組織で共通して利用しているか。
変更理由: 重要なのはオンラインコラボレーションなので、ソースコードの記述を削除

変更前: プロダクトに関わるUIパーツには、OOUIなどの抽象的な情報設計に基づいた共通のポリシーがあり、それらがドキュメント化されているか。
変更後: プロダクト特有のUIコンセプトが一貫した情報設計に基づいており、ドキュメント化されているか。
変更理由: 手段を非限定化

変更前: フロントエンド開発とバックエンドが密結合しており、APIモックサーバーなどを用いて、バックエンド開発と並行して開発をすすめることができない。
変更後: デザインシステムにUXライティングについてのガイドラインが存在しない。
変更理由: API駆動開発で語っている項目なので、UXライティングの項目を追加

変更前: 各プラットフォーム（iOS/Android/Web）などで過度に統一の体験を設計しようとしすぎてしまい、それぞれの流儀にそぐわないUIとなってしまっている。
変更後: デザインシステムが存在するのにもかかわらず、関係者のアドホックな意思決定によってデザインの一貫性が損なわれている。
変更理由: 環境変化により、別観点の指標を追加

変更前: 各画面やパーツごとに組み込まれた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素がガイドラインに組み込まれていない。
変更後: デザインシステムにマイクロインタラクション（ユーザーの行動に応じた細やかなアニメーションや音、振動、トランジションといった動きのあるUI要素）が組み込まれていない。
変更理由: 具体化

変更前: 事業に必要なUI/UXデザインの過半数を内製化できているか。
変更後: 事業に必要なデザイン業務の過半数を内製化できているか。
変更理由: 非限定化

変更前: 内製のデザイン組織を持ち、ガイドラインなどを用いて、内製化すべきことと外部の専門家集団を活用することを明確にしているか。
変更後: サービスデザイナー、UI/UXデザイナー、グラフィックデザイナーなどの明確な役割と専門性を認識した上で、ジョブディスクリプションが定義されているか。
変更理由: 内製と外注について検討する余地を残しつつ、より本質的な文章へ修正

変更前: 重要機能のタスク成功率/タスク実施時間/学習効率などを計測しているか。
変更後: プロダクトチーム自身が顧客の業務や活動を再現する環境が整備されていて、習慣的にユーザビリティを体感して気づきを得ているか
変更理由: 7-1と意味合いが近いので、別観点の指標を追加

変更前: 実際のリリース後も入力エラーやタスク時間などを計測しているか。
変更後: プロダクトのリリース後も入力エラーやタスク時間などを計測しているか。
変更理由: 具体化

変更前: 幹部人材に対して、プロダクトマネジメントのスキルについての継続的な学習機会を提供できているか。
変更後: プロダクトチームやプロダクトの意思決定に関わる人に向けて、プロダクトマネジメントのスキルについての継続的な学習機会を提供できているか。
変更理由: 具体化

変更前: 明文化されているコードレビューガイドラインが存在するか。
変更後: 静的解析だけでは発見できないレビュー観点を生成AIを用いたツールやサービスによってレビュー・修正提案を自動化しているか。
変更理由: 生成AIについての観点を追加

変更前: コードレビューガイドラインを満たさないコードを自動的に検出・補正する各種Linterやフォーマッタなどのツール群を整備しており、ソースコードを変更する誰もが使うことができるか。
変更後: リポジトリ共通のコードルールに準拠したコードにするため、指摘点を自動的に検出・補正するLinterやフォーマッタなどのツール群を整備しているか。
変更理由: コードレビューガイドラインとコードルールについて明確に分類

変更前: コードレビューガイドラインは１年以上メンテナンスされておらず、形骸化している。
変更後: コードレビューガイドラインが些細な記述上のルールにとどまり、品質特性（保守性や拡張性など）に資する項目が十分に書かれていない。
変更理由: コードレビューガイドラインとコードルールについて明確に分類

変更前: テスト自体が複雑になって、長期間メンテナンスされていない。
変更後: たまに失敗するような不安定な動作をする自動テスト（フレーキーテスト）が増え、自動テストの結果が信頼できなくなっている。
変更理由: 具体化

変更前: 自動テストが失敗したまま、そのコードが本番デプロイされることを許容している。
変更後: アイスクリームコーン型のテスト（手動テストやE2Eテストの比重が大きい）になっており、テストの実行時間、保守工数などが増大している。
変更理由: 自動テストが増えてきたことによるアンチパターンを追加

変更前: 各APIに対して、ネットワークを経由したE2E(ステージング・本番どちらに対するE2Eテストかは問わない)のテストが存在しておらず、死活監視ができていない。
変更後: 各APIに対して、ネットワークを経由した死活監視が存在しておらず、サービスの稼働状況をリアルタイムで把握できていない。
変更理由: 手段を非限定化

変更前: APIがバージョン管理されておらず、破壊的な変更が利用者から検知できない。
変更後: APIがバージョン管理されていないため、並行開発や段階的なリリースが困難な状態になっている。
変更理由: 文章校正

変更前: APMのためのSaaSやツールが導入され、ユーザーからみた応答速度などについて、要因ごとの影響度を定常的に分析できる状態になっているか。
変更後: システムに起こった障害や異変などを再現できるための情報がアプリケーションのログ、メトリクス、トレースを通じて出力され分析できるようになっている。（オブザーバビリティ）
変更理由: APMからオブザーバビリティへ観点を変更

変更前: フォルトインジェクションテストや、カオスエンジニアリング等の仕組みを導入することで、重大事故につながりうるシステムの欠陥を早期に発見するための試みをおこなっているか。
変更後: プロアクティブな本番系への負荷テストやフォルトインジェクションテスト、リカバリテストなどのシステムの不確定要因への耐障害性を上げていく試みをおこなっているか。
変更理由: 手段を非限定化

変更前: 定常的に発生しているサービス上の警告を問題ないものとして無視したり、ログ自体を出さないようにしている。
変更後: 定常的に発生しているサービス上の警告を問題ないものとして無視したり、ログを意図的に出力しないようにする慣習が存在する。
変更理由: 文章校正

変更前: ソースコード中に、漏洩してはならない情報がハードコーディングされている。（それらを分離して管理するようなツールまたは仕組みを導入しているか）
変更後: ソースコード中に、漏洩してはならない情報がハードコーディングされている。(それらを分離かつ暗号化して管理するようなツールまたは仕組みを導入していない)
変更理由: 文章校正

変更前: インセプションデッキまたはプロジェクト憲章を作成し、チームの存在理由についてチーム全員が把握しているか。
変更後: インセプションデッキまたはプロジェクト憲章などを作成し、チームの存在理由についてチーム全員が把握しているか。
変更理由: 手段を非限定化

変更前: 新しくチームに参画するメンバー用のオンボーディング・デック（チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集）が存在するか。
変更後: 新しくチームに参画するメンバー用のオンボーディング・デック（チームの一員として働き始めるための、価値観・実務・スキル・相互理解のための明文化されたドキュメント集）などが存在するか。
変更理由: 手段を非限定化

変更前: 1年以上チームのやることが変わっておらず、チームメンバーも固定されている。
変更後: 1年以上チームのやることがルーチン化しているなど変わっておらず、チームメンバーも固定されている。
変更理由: 詳細化

変更前: チームメンバーの心理的安全性を測る指標があり、定期的に計測しているか。
変更後: チームの心理的安全性を測る指標があり、定期的に計測しているか。
変更理由: 文章校正

変更前: チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」が存在するか。
変更後: チームのタスクに関して、「完成(完了)の定義(Definition of DONE)」などが存在し、自律的に管理できているか。
変更理由: 手段を非限定化

変更前: 仮説的な目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。
変更後: 目標に対して、うまくいかなかった際にチームとして「学んだこと」を言語化・他チームへ公開・学習しているか。
変更理由: 文章校正

変更前: 目標が定量的でなく、第三者からみて達成度合いが不明確なものになっている。
変更後: 定量目標が無く、客観的に達成度合いが不明確なものになっている。
変更理由: 文章校正

変更前: チームのベロシティを把握しており、その分散値の変化を計測しているか。
変更後: チームのベロシティを把握しており、変化を計測し安定しているかどうかを確認できているか。
変更理由: 文章校正

変更前: 相対見積もりの基準となる要件（ユーザーストーリー）が存在し、定期的にアップデートしているか。
変更後: 相対見積もりの基準となるタスクが存在し、定期的にアップデートの判断をしているか。
変更理由: 定期的な判断をすることが重要であるため

変更前: 相対見積もりによって得られたベロシティの数値自体を、生産性の指標にしており、数値的なコミットメントや改善が要求されている。
変更後: ベロシティをチームの安定性を測る指標にするのではなく、生産性の指標にしている。
変更理由: 文章校正

変更前: チームのバリューストリームマッピングを作成し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。
変更後: チームのバリューストリームを可視化し、繰り返しボトルネックを把握しながら自動化と学習を繰り返しているか。
変更理由: 手段を非限定化