ID | 大項目 中項目 |
小項目(課題要素) | 必要となる知識と行動 | できるという状態 | 技術補足(言語・FWなど) |
---|---|---|---|---|---|
801 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
1. Gitでのバージョン管理の目的を説明できる | Gitを利用する目的とバージョン管理の意義を理解する。 | 変更履歴の追跡・復元ができる環境を構築できる。 | |
802 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
2. コミットとは何か、どのような単位で行うべきかを理解している | コミットの粒度と役割を理解する。 | 小さく意味のある単位でコミットできる。 | |
803 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
3. add/commit/pushの基本操作ができる | add/commit/pushの基本操作を理解する。 | 日常的にGitを安全に操作できる。 | |
804 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
4. ローカルリポジトリとリモートリポジトリの違いを理解している | ローカルとリモートのリポジトリ構造を理解する。 | push/pullを通じて同期管理ができる。 | |
805 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
5. コミットメッセージの書き方に一貫性を持たせられる | コミットメッセージの命名規則を理解する。 | チーム共通ルールでメッセージを残せる。 | |
806 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
6. diffとlogコマンドで変更履歴を追える | diff/logコマンドの利用方法を理解する。 | 変更履歴を確認・分析できる。 | |
807 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
7. gitignoreファイルの役割と使い方を理解している | gitignoreの目的と記法を理解する。 | 不要なファイルを除外設定できる。 | |
808 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
8. ファイルの競合を解消できる | 競合の発生原因と解消手順を理解する。 | マージコンフリクトを安全に解消できる。 | |
809 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
9. RevertとResetの違いと使い方を説明できる | RevertとResetの違いを理解する。 | 履歴の巻き戻しを安全に行える。 | |
810 | プロジェクトとチーム開発 バージョン管理の基本(Gitの概念) |
10. Gitの操作に対して安心感を持って使える | Git操作の仕組みを理解し安心して扱う。 | トラブル時も冷静にリカバリできる。 | |
811 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
11. ブランチの意味と活用方法を理解している | ブランチの目的と仕組みを理解する。 | 複数人開発で安全にブランチを運用できる。 | |
812 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
12. main/developブランチの役割を区別できる | mainとdevelopの使い分けを理解する。 | 安定版と開発版を明確に区別できる。 | |
813 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
13. フィーチャーブランチでの開発ができる | フィーチャーブランチ開発の手法を理解する。 | 機能単位で独立した開発ができる。 | |
814 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
14. Git Flowの流れ(feature→develop→release→main)を理解している | Git Flowの流れを理解する。 | リリースプロセスをルール化して運用できる。 | |
815 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
15. トピックブランチの命名規則をチームで統一できる | トピックブランチの命名規則を理解する。 | チーム内で一貫性のあるブランチ命名ができる。 | |
816 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
16. リリース管理におけるタグの使い方を理解している | タグの役割を理解する。 | リリースバージョンをタグで管理できる。 | |
817 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
17. コンフリクトの発生しにくいブランチ戦略を設計できる | 競合を減らすブランチ戦略を理解する。 | 効率的なマージフローを設計できる。 | |
818 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
18. ブランチの削除・保守を行える | 不要ブランチの整理と管理を理解する。 | 古いブランチを安全に削除・統合できる。 | |
819 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
19. 短期・長期開発でブランチ構成を使い分けられる | 短期・長期開発のブランチ構成の違いを理解する。 | プロジェクト規模に応じた構成を選択できる。 | |
820 | プロジェクトとチーム開発 ブランチ戦略(Git Flowなど) |
20. チームの成長に応じてブランチ戦略を見直せる | チーム成長とともに戦略を更新する意義を理解する。 | 運用に合わせてブランチモデルを改善できる。 | |
821 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
21. コードレビューの目的(品質向上・知識共有)を理解している | コードレビューの目的を理解する。 | 品質と知識共有を意識したレビューができる。 | |
822 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
22. レビュー対象の粒度(1PR=1目的)を意識できる | レビュー粒度の重要性を理解する。 | 1PR=1目的のレビュー単位を保てる。 | |
823 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
23. 他人のコードを読み、意図を読み取る力がある | 他人のコードを読む観察力を養う。 | 意図を理解した上で改善提案できる。 | |
824 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
24. 指摘コメントに対して敬意をもって対応できる | レビュー対応時の姿勢を理解する。 | 建設的な受け答えができる。 | |
825 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
25. 指摘のしかたに配慮し、建設的な言葉を使える | 指摘コメントの伝え方を理解する。 | 攻撃的でないレビューコメントを実践できる。 | |
826 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
26. 処理の正確さだけでなく、可読性や保守性にも目を向けられる | 可読性・保守性を重視した評価観点を理解する。 | 動作だけでなく品質もレビューできる。 | |
827 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
27. 「なぜそう書いたのか」をレビュー時に伝えられる | 意図説明の重要性を理解する。 | なぜその実装にしたのかを伝えられる。 | |
828 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
28. 提案と質問を分けたレビューができる | 提案と質問の違いを理解する。 | 相手を尊重したレビューができる。 | |
829 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
29. レビュー依頼のタイミングと伝え方を工夫できる | レビュー依頼のタイミングを理解する。 | 効率よく依頼・返信を行える。 | |
830 | プロジェクトとチーム開発 コードレビューのやり方・され方 |
30. レビュー文化をチームで継続する意識がある | レビュー文化の継続意義を理解する。 | チーム全体でレビューを習慣化できる。 | |
831 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
31. タスクをチケット単位で分割して管理できる | チケット単位でタスクを分割する重要性を理解する。 | 作業単位を明確に管理できる。 | |
832 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
32. タイトルと説明文から目的が読み取れるチケットを作成できる | 目的が明確なチケット記述の方法を理解する。 | タイトルと説明で意図を伝えられる。 | |
833 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
33. ステータス(ToDo/Doing/Done)を適切に更新できる | タスクステータス管理を理解する。 | ToDo/Doing/Doneを適切に更新できる。 | |
834 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
34. タスクの見積もり(時間・工数)を意識して記述できる | 見積もりと工数管理の基本を理解する。 | 現実的な作業時間を算出できる。 | |
835 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
35. チケットに添付すべき情報(仕様・URLなど)を明示できる | 付随情報の記録を理解する。 | チケットに必要情報を整理して登録できる。 | |
836 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
36. タスクの依存関係や順序を整理して登録できる | タスク依存関係の設計を理解する。 | 作業順序を明確に設定できる。 | |
837 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
37. リマインダーや期限をチケットに設定できる | リマインダーと期限管理の役割を理解する。 | 期日を守るための設定を行える。 | |
838 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
38. コメントで進捗や懸念点を共有できる | コメントによる共有の価値を理解する。 | 進捗や懸念を記録・共有できる。 | |
839 | プロジェクトとチーム開発 タスク管理とチケット文化(Jira/Trelloなど) |
39. 作業完了後のふりかえりメモを残せる | 作業後の振り返りを理解する。 | 改善点を次タスクに活かせる。 | |
840 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
40. チケット管理がチームの認識共有手段であると理解している | チケット管理の役割を理解する。 | チーム認識を統一する手段として運用できる。 | |
841 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
41. スクラムの基本概念(スプリント/PO/レビュー)を説明できる | スクラムの基本概念を理解する。 | スプリント単位でチーム開発を運用できる。 | |
842 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
42. デイリースクラム(朝会)の目的と進行方法を理解している | デイリースクラムの目的を理解する。 | 短時間で進捗共有を行える。 | |
843 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
43. タスクの見積もりにストーリーポイントを使える | ストーリーポイントによる見積もりを理解する。 | 相対評価による計画を立てられる。 | |
844 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
44. スプリントの計画・開始・終了をリズムよく行える | スプリント計画と振り返りの流れを理解する。 | 計画・実行・評価のサイクルを維持できる。 | |
845 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
45. バーンダウンチャートで進捗を可視化できる | バーンダウンチャートの活用方法を理解する。 | 進捗を可視化してリスクを把握できる。 | |
846 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
46. カンバンでのWIP制限(同時作業制限)を理解している | カンバンのWIP制限を理解する。 | 作業の詰まりを防ぐ運用ができる。 | |
847 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
47. ボトルネックを発見しチームで共有できる | ボトルネック検知の重要性を理解する。 | 問題箇所を共有・改善できる。 | |
848 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
48. 開発のペースや生産性を定期的に見直せる | チームの生産性指標の見直しを理解する。 | 定期的に開発プロセスを改善できる。 | |
849 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
49. スクラムマスターやPOの役割を理解している | スクラムマスター・POの役割を理解する。 | それぞれの責務を果たせる。 | |
850 | プロジェクトとチーム開発 スクラム・カンバンなどの開発手法 |
50. アジャイルとウォーターフォールの違いを説明できる | アジャイルとウォーターフォールの違いを理解する。 | プロジェクト特性に合わせた開発手法を選べる。 | |
851 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
51. チャットやIssueでの報告・相談をこまめに行える | チャットやIssueでの報連相の重要性を理解する。 | 小まめな情報共有を行える。 | |
852 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
52. わかりにくい箇所を明文化して共有できる | 明文化の重要性を理解する。 | 不明点を文書化して共有できる。 | |
853 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
53. 共有知識をチーム内Wikiなどにまとめられる | チーム内Wiki等の活用を理解する。 | 知識を体系的に残せる。 | |
854 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
54. 日報やふりかえりを通して学びを発信できる | 日報や振り返りを通じた学び共有を理解する。 | 改善をチームに還元できる。 | |
855 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
55. 会話だけに頼らず、書き残す習慣がある | 記録文化の価値を理解する。 | 口頭依存せず情報を残せる。 | |
856 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
56. やりとりのテンポと頻度に配慮できる | コミュニケーションのテンポと頻度の重要性を理解する。 | 相手に配慮した発信ができる。 | |
857 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
57. 相手のスキルや経験に応じた言葉を使える | 相手の理解度に応じた言葉選びを理解する。 | 伝わる説明を行える。 | |
858 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
58. 感情に頼らず、事実ベースでの対話ができる | 事実ベースの対話を理解する。 | 感情的にならずに建設的議論ができる。 | |
859 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
59. 相手の意見を尊重しつつ、必要な修正提案を出せる | 相手意見の尊重と提案姿勢を理解する。 | 対話で合意形成を進められる。 | |
860 | プロジェクトとチーム開発 コミュニケーションと共有文化 |
60. チームとしての前提・ルールを明文化できる | チームルールの明文化の意義を理解する。 | チーム共通規約を整備できる。 | |
861 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
61. Pull Requestに目的や背景を記述できる | PRに目的・背景を記載する意義を理解する。 | レビューしやすいPRを提出できる。 | |
862 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
62. 差分が適切な粒度(小さすぎず大きすぎず)である | 差分粒度の適正化を理解する。 | 適切な単位でPRを作成できる。 | |
863 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
63. レビュー対象外のファイルを含めないよう管理できる | 不要ファイルを含めない管理を理解する。 | 差分を整理してレビュー負担を減らせる。 | |
864 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
64. PRのタイトル・説明文で内容が伝わるよう工夫できる | PRタイトル・説明文の工夫を理解する。 | 内容を明確に伝えるPRを作成できる。 | |
865 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
65. WIP(作業中)とReadyを使い分けられる | WIPとReadyの違いを理解する。 | レビュー準備状態を明確にできる。 | |
866 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
66. 承認・差し戻し・修正のやりとりを円滑に行える | 承認・差戻し・修正の流れを理解する。 | レビュー過程を円滑に進行できる。 | |
867 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
67. PRの中で技術的議論を行い、合意形成できる | PR上での技術議論の進め方を理解する。 | 合意形成を促す建設的コメントを行える。 | |
868 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
68. マージ後の影響(デグレード等)を意識してチェックできる | マージ後の影響範囲確認を理解する。 | デグレードを防ぐ確認を実施できる。 | |
869 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
69. PRを放置せず、定期的にレビューできる | PRレビューの頻度維持を理解する。 | 放置せず迅速な対応を行える。 | |
870 | プロジェクトとチーム開発 Pull Requestとマージ運用 |
70. PRのテンプレートやルールをチームで整備できる | PRテンプレート運用の価値を理解する。 | チーム共通ルールを整備できる。 | |
871 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
71. READMEにセットアップ手順を記述できる | READMEの基本構成を理解する。 | セットアップ手順を誰でも再現できるよう記述できる。 | |
872 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
72. プロジェクトの目的や技術構成を明記できる | プロジェクト概要記述の重要性を理解する。 | 目的・構成を明確に説明できる。 | |
873 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
73. 設定ファイルや環境変数の説明をドキュメント化できる | 環境変数と設定ファイルの説明方法を理解する。 | 環境構築ドキュメントを整備できる。 | |
874 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
74. 仕様書・設計書などのリンクを集約できる | 関連ドキュメントの集約方法を理解する。 | 設計書・仕様書への導線を整理できる。 | |
875 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
75. 外部APIやライブラリの使い方をチーム内で共有できる | 外部APIやライブラリ共有の重要性を理解する。 | チームメンバーが再利用できる資料を整備できる。 | |
876 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
76. よくある質問(FAQ)をWiki化しておける | FAQやTipsの整理意義を理解する。 | よくある質問をWiki化できる。 | |
877 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
77. 書いたドキュメントを更新する意識を持てる | ドキュメント更新の必要性を理解する。 | 古い情報を定期的に見直せる。 | |
878 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
78. ドキュメントに変更履歴を残せる | 変更履歴管理を理解する。 | 更新記録をドキュメント内に残せる。 | |
879 | プロジェクトとチーム開発 ドキュメント管理(README/Wiki等) |
79. 誰でも参照・編集しやすいドキュメント構成を設計できる | 閲覧・編集性を意識した構成を理解する。 | 誰でも使いやすいドキュメント設計ができる。 | |
880 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
80. ドキュメントを書くことの価値を説明できる | ドキュメントを書く価値を理解する。 | 文章で知識共有の重要性を説明できる。 | |
881 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
81. チームに必要な役割(開発/設計/検証/調整)を把握している | チーム内の役割構成を理解する。 | 自他の役割を把握し協力できる。 | |
882 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
82. 自分の立ち位置と責任範囲を意識できる | 自身の責任範囲を理解する。 | 担当タスクを自律的に遂行できる。 | |
883 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
83. チームメンバーの得意/不得意を把握している | メンバーの得意分野を把握する。 | 強みを活かしたタスク配分ができる。 | |
884 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
84. 誰にどんな相談をすべきか判断できる | 相談・報告先を理解する。 | 課題発生時に適切にエスカレーションできる。 | |
885 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
85. リーダーやマネージャーの視点に立った提案ができる | 上位者視点の重要性を理解する。 | 全体最適を意識した提案ができる。 | |
886 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
86. メンターやレビュー役としてサポートができる | メンター・レビュー担当の責務を理解する。 | 後進指導・技術レビューができる。 | |
887 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
87. 不在時の対応引き継ぎを適切に行える | 引き継ぎ手順の重要性を理解する。 | 業務継続性を保つ引き継ぎができる。 | |
888 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
88. 役割ごとの情報共有の流れを設計できる | 各役割間の情報共有手段を明確に設計する重要性を理解する。 | チーム内外の役割ごとに適した情報共有フローを設計できる。 | |
889 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
89. チーム構成に応じた開発フローを調整できる | チーム構成や人数に応じて開発プロセスを調整する考え方を理解する。 | 小規模・大規模の構成に応じてフローを最適化できる。 | |
890 | プロジェクトとチーム開発 チームの役割理解(リーダー・レビュワー) |
90. チームの士気や関係性に配慮した動きができる | チームの心理的安全性と関係性の重要性を理解する。 | 士気を下げない働き方・言動を実践できる。 | |
891 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
91. 開発に必要なツールを自分で構築できる(エディタ/Gitなど) | エディタ・Git等の開発ツールを自力で構築できる知識を持つ。 | 自分専用の快適な開発環境を構築・維持できる。 | |
892 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
92. VPNやSSH接続を使ってリモート作業環境を整えられる | VPNやSSH接続などリモートアクセスの仕組みを理解する。 | 安全なリモート開発環境を自分で構築できる。 | |
893 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
93. 複数人で同一環境を再現できるDocker環境を整備できる | Dockerなどの仮想環境を利用して同一環境を再現する意義を理解する。 | 複数人で同一環境を再現できるDocker構成を整備できる。 | |
894 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
94. テレワークでも情報が滞らないチャット・タスク連携ができる | チャット・タスク管理ツールを連携して使う効果を理解する。 | テレワークでも情報が滞らない仕組みを運用できる。 | |
895 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
95. リモート開発時のセキュリティリスクを理解して対策できる | リモート開発に伴うセキュリティリスク(情報漏えい・端末管理等)を理解する。 | VPN・権限・ログ管理を活用して安全対策を実装できる。 | |
896 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
96. 通信状況に応じた作業・レビューの工夫ができる | 通信環境が不安定な場合の作業工夫を理解する。 | 通信制限下でもレビュー・作業を継続できる方法を提案できる。 | |
897 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
97. フルリモートでの進捗報告・相談の仕組みを提案できる | 進捗報告・相談をリモート環境で円滑に行う仕組みを理解する。 | フルリモートでも進捗共有の仕組みを設計できる。 | |
898 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
98. オンライン会議でのファシリテーションができる | オンライン会議での発言構造・進行役割を理解する。 | 会議のファシリテーションを円滑に行える。 | |
899 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
99. リモート環境下でもチームの一体感を醸成できる | リモートでも一体感を作るためのコミュニケーション工夫を理解する。 | オンラインでもチームの士気を維持・向上できる。 | |
900 | プロジェクトとチーム開発 リモート開発環境の整備とルール |
100. 自律的に作業を進め、相談や報告のバランスを保てる | 自律的に作業を進めつつ報告・相談のバランスを保つ重要性を理解する。 | リモート環境下でも主体的に動き、必要な連携を怠らない働き方ができる。 |