課題を立ててみよう
この COJT サイトは現在も開発途中であり、完成に終わりがあるわけではありません。
それこそがソフトウェア開発の本質とも言えます。
まずは、このサイトの目的 を確認し、その目的に対して「足りないこと」や「もっと良くできそうなこと」を自由に考えてみましょう。
ソフトウェア開発やチームでの議論に不慣れなうちは、深く悩み すぎず、思ったことを率直に書いてみることが大切です。
ただし、お互いの努力や立場に敬意を持ち、誰かの作業を否定するような言い方は控えましょう。
GitHub Issue を立てる
皆さんが感じた課題や提案を Issue（イシュー） として GitHub に投稿します。
実際の開発現場ではルールはさまざまですが、ここでは以下の項目を基本ルールとして明記してください。
- 課題のタイトル
- 何が課題だと感じたか
- あなたなりの解決策の一案
- 解決完了の定義（何ができたら完了か）
課題のタイトル
タイトルは、一覧を見ただけで「どんな課題なのか」が伝わるように心がけましょう。
例：
- （Poor）ナビゲーションについて
- （Better）ナビゲーションの主要メニューに足りない内容を追加
- （Good）ナビゲーションにコンセプトページへの導線を追加
1 は内容が曖昧で、何が課題なのかが伝わりません。
2 は「足りない内容」があることを示唆しており、議論のきっかけになります。
3 は「どんな対応をしたいか」まで踏み込んでおり、開発にすぐ移行できる具体性 があります。
何が課題なのか
「どのような点に違和感や改善の余地を感じたのか」を端的に説明しましょう。
解決策の一案
あなたの考えた解決方法があれば、ぜひ共有してください。
その案が最終案になる必要はありませんし、責任を負う必要もありません。
他のメンバーと議論するための出発点になることが大切です。
記述例：
- 解決案：メインメニューに「コンセプト」項目を追加する
- 理由：初めて訪れた人に、サイトの目的が伝わりにくいため
完了の定義（Doneの条件）
意外と忘れられがちですが、とても重要な項目です。
「何をもってこの課題が解決されたとみなすのか」をできるだけ具体的に書いてください。
例：
- コンセプトページへの導線がメニューに追加されたら完了
- ページ遷移しやすくなったとフィードバックが得られたら完了
連絡 事項は Issue ではなくツールで
Issue は「解決すべき課題」の記録のための機能です。
ただの連絡や雑談、確認事項はなるべく Slack などの別のコミュニケーションツールを使うようにしましょう。
最初の一歩として、課題を立てる
ソフトウェア開発では、次のようなステップが繰り返されます：
- どんな課題があるかを洗い出す
- 解決策を検討・議論する
- 合意のもと、対応方針が決定される
この「話し合い」と「記録」が残る場所が GitHub Issue です。
Issue を立てたら、プロジェクトページ を確認しましょう。
そこではカンバン形式で課題が一覧化されており、進捗管理や優先度の整理に活用できます。
GitHub はソースコードの管理だけでなく、開発の全体進行を支えるプラットフォームでもあります。
次のステップでは、立てられた Issue の中から「自分が取り組んでみたい課題」を選び、実際に開発へと進んでみましょう。