ポートフォリオを作成しよう！
ここまでみなさんには開発をしていただくにあたって、知識を身につけていただきました！
次はその知識を生かしていくために、ポートフォリオ制作をしていただきます！
なぜポートフォリオを作成するのか？
プログラミングを学ぶ目的のひとつに、「自分のスキルを形にする」という目標があります。その第一歩がポートフォリオの作成です。
ポートフォリオとは、自分で作ったWebアプリケーションやWebサイトをまとめた作品集のこと。
これは、企業やクライアントに自分の技術をアピールするための強力な武器になります。
ポートフォリオを作成するメリット
✅ 開発の流れを体験できる
企画 → 設計 → 実装 → テスト → 公開 という一連の流れを経験することで、実務に近いスキルが身につきます。
✅ 自分の技術レベルを客観的に把握できる
何が得意で何が苦手かが明確になり、次に学ぶべきことが見えてきます。
✅ SESアサインの際、強力なアピール材料になる
実績として提示できるため、未経験でもやる気と努力を示すことができ、面談や面接で有利に働きます。
何を作るか決めよう！
次にどんなテーマでポートフォリオを作成したら良いかを話していきます！
どんなことを意識するべきか？
ポートフォリオを作るときは、自分のやりたいことと見る人（企業や面接官）の視点の両方を意識しましょう！
- 自分が作っていて楽しいと思えるもの
- 現実に存在しそうなサービスをベースに考える
- 「誰の」「どんな課題を」解決するのかを意識する
- アピールしたい技術要素（LaravelでAPI連携したい・JSで動きのあるUIを作りたい 等）を意識する
テーマの具体例
自分なりの工夫や独自性を出すとよりOK！
| テーマ | 内容 | アピールできる技術 |
| タスク管理アプリ | ToDo管理、進捗、優先度など | 認証・CRUD・ソート・バリデーション |
| 書籍レビューサイト | 書籍を検索＆レビュー投稿 | 外部API連携・ユーザー管理・評価機能 |
| 日記アプリ | 日記を投稿・タグ管理 | ログイン・WYSIWYGエディタ・検索 |
| 料理レシピ投稿サイト | レシピ投稿・検索・いいね | 画像アップロード・レコメンド機能 |
| スケジュール共有アプリ | チームで予定を共有 | カレンダーUI・ユーザー紐付け・非公開設定 |
| ポートフォリオ管理アプリ | 自分の成果物を登録＆表示 | フロント演出・DB設計・SEO対策 |
特にアイデアがない場合は、以下のテーマからどれかを選んで作成してください。
作成物：①ゲーム紹介会員ページ
②店の予約管理システム
③書籍紹介サイト及び購入ページ
④古本売買マッチングサービス
開発の流れ
開発は、ただコーディングするだけではなく、計画・設計・開発・テスト・公開という工程を順に行っていきます。
また、開発手法にもいくつか種類があります。
開発手法の基本
ウォーターフォール開発（Waterfall Model）
■ 概要
ウォーターフォール開発は、「上から下へ水が流れるように」一つひとつの工程を順番に進めていく開発手法です。
要件定義 → 設計 → 実装 → テスト → リリースという流れで、前の工程が完了してから次の工程に進みます。
各工程は原則として一度完了してから次に進むため、開発の初期段階で仕様や要件をできる限り詳細に定めます。
この方法では、基本的にお客様が実際に動くシステムを見るのは開発の最終段階になることが多く、途中で仕様を変更するのは難しくなります。そのため、大規模なシステムや、要件が明確で変更の少ないプロジェクトに向いています。
■ 特徴
- 計画重視：開発前にしっかりと設計・計画を立てる
- 変更に弱い：途中で仕様変更があると全体に影響が出やすい
- 進捗が分かりやすい：段階ごとに成果物があるため、管理がしやすい
- 大規模・長期のプロジェクトに向いている
■ 向いているケース
- 要件が明確で変更が少ない案件
- 官公庁や受託開発など、文書ベースでの合意が必要な場合
アジャイル
■ 概要
アジャイル開発は、短い期間で繰り返し開発（イテレーション）を行いながら進める手法です。
要件や仕様を最初にすべて決めるのではなく、小さな単位（機能や画面など）ごとに計画・開発・テスト・レビューを繰り返しながら進めていきます。
お客様と相談しながら1つ1つの機能を確認・改善していくため、柔軟に仕様変更に対応でき、完成度を高めやすいのが特徴です。要件が変わりやすいプロジェクトや、ユーザーのフィードバックを活かしたい開発に向いています。
■ 特徴
- 柔軟性が高い：仕様変更に強く、都度対応しやすい
- 段階的に価値を提供：最初から完璧を目指すのではなく、徐々に完成度を高めていく
- ユーザーとの対話が多い：頻繁な確認・フィードバックをもとに改善していく
- 小規模・スピード感のある開発に向いている
■ 向いているケース
- 要件がまだ固まっていない、または変更が多いプロジェクト
- スタートアップやWebサービスなどスピードを重視する現場
💡補足：ハイブリッド型開発
最近では、ウォーターフォールとアジャイルのいいとこ取りをした「ハイブリッド型」も増えています。
要件定義や基本設計まではウォーターフォール的に進めて、実装やテストはアジャイル的に対応することで、柔軟性と安定性の両立を図っています。
開発ドキュメントの役割と重要性について
「仕様書」は、Webサービスやアプリを開発するうえで、開発者にとっての“設計図”のような役割を果たす資料です。
どこにどんな機能を持たせるのか、どこからどこへ遷移するのかなど、プロダクトの「あるべき姿」をまとめたもので、開発の要となる非常に重要な工程です。
企画者やディレクターを目指す方にとっては、ぜひとも身につけておきたい知識のひとつです。
一方、「設計書」は、仕様書に書かれた内容をもとに、どのように実現するかを具体的に明示した資料です。
設計書では、制作工程や実装方法を開発者の視点で整理していきます。
システム開発においては、開発前の準備段階でいくつかの設計・仕様ドキュメントを作成します。
これらの資料は、関係者全体で共通認識を持つために重要であり、品質の高いシステムを効率的に開発するための土台となります。
以下に、それぞれのドキュメントの概要・役割・記載内容について詳しく説明します。
🔸開発前のドキュメント
| ドキュメント名 | 内容・役割 |
|---|---|
| 要件定義書 | 作る目的・ターゲット・必要な機能を洗い出す |
| 機能仕様書 | 実装する機能の詳細を記載（何をどうするか） |
🔸 画面設計・UI関連
| ドキュメント名 | 内容・役割 |
|---|---|
| 画面仕様書 | 画面構成・入力項目・画面遷移をまとめる |
| └ ワイヤーフレーム | レイアウトを簡易的に図示したもの |
| └ 画面遷移図 | 画面同士の移動パターンを整理 |
| 詳細仕様書 | 画面や機能の具体的な動作条件などを記載 |
| 画面詳細設計 | UIの状態遷移、API連携、バリデーションなど実装レベルまで落とし込む |
🔸 システム設計
| ドキュメント名 | 内容・役割 |
|---|---|
| 基本設計書 | 機能の概要・外部とのやり取り・UIの設計など |
| 詳細設計書 | 内部構造や処理ロジック、データフローの設計 |
| データベース設計 | ER図、テーブル設計、リレーションなど |
要件定義書
要件定義書は、開発における出発点となるドキュメントです。
主に「なぜこのシステムを作るのか」「ユーザーがどんな課題を抱えていて、何を求めているのか」といった、背景や目的、ユーザーのニーズを明確にします。
また、プロジェクトにおいて最低限必要な機能や条件を整理し、関係者の間で「ゴールはここです」という共通認識を作るために不可欠です。
記載内容としては以下のような項目が含まれます。
- 非機能要件（セキュリティ、レスポンシブ対応、パフォーマンスなど）
- 開発の背景と目的
- 想定ユーザーや使用シーン
- システムに求められる機能（例：ログイン、検索、帳票出力など）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 |
要件定義書（あくまで例のサンプルです） 2022年0X月XX日 １・目的 本ドキュメントは売り上げ管理と経理システムの自動連携を実現させるシステム開発に関する要件定義書になります。 ２・概要 ■システム方式・構成 システム構成は次の通りです。なお、新たなハードウェア導入は予定していません。 ・アプリケーションサーバー 自動連携設定を行う画面、連携結果を表示する画面を提供します。 ・データベースサーバー 既存の社内サーバーです。 ・経理システム 現在経理部で使われている経理システムおよび専用のワークステーションです。 ３・用語定義 ・経理システム 社内で用いている経理システム○○のことを指します。 ・社内システム 社内で用いられている共通システムを指します。 ・バッチ 定期的に自動実行されるシステムを指します。 ・ログ ここではバッチシステムによって出力される処理結果を指します。 ４・業務要件 ■現状のフロー 現状のフローは次のようになっています。 ⅰ．経理担当者がシステム開発部門に売り上げ出力を依頼 ⅱ．システム開発部門が売り上げデータをCSV出力して、メールで送信 ⅲ．経理担当者がCSVをExcelで開いて編集 ⅳ．経理担当者が経理システムへログイン ⅴ．経理システムのインポート機能でCSVデータを取り込み ５・構築後のフロー システム構築後、フローは次のようになります。 ⅰ経理担当者が専用画面にて自動取り込みに関して設定 ⅱバッチシステムが自動処理後、経理担当者にメールで完了を通知 ⅲ経理担当者が経理システムへログイン ⅳ取り込み未確定データを確認後、経理システムにて確定処理を実行 ６・利用者一覧 経理担当者 ７・規模 2人月（エンジニア1人×2）の予定です。 ８・機能要件 ■画面 ・バッチ処理設定画面 バッチの有効または無効、頻度、処理完了後に送信するメールアドレスを設定する画面です。 ・バッチ処理結果一覧画面 バッチ処理の履歴一覧を確認する画面です。 ・バッチ処理結果詳細画面 ある時に行われたバッチ処理の結果を確認する画面です。 ９・権限 ・バッチ処理設定は経理担当者のみ可能とします。 ・バッチ処理結果は経理担当者および経理システム担当者のみ閲覧可能とします。 １０・帳票 本システムでは以下のメールおよび帳票が出力されます。 ・バッチ処理結果メール ・バッチ処理結果詳細レポート １１・情報・データ 本システムでは以下のデータが作成されます。 ・経理システムに取り込める形での売り上げデータのエクスポートデータ CSVデータで一時出力されます。処理後、削除されます。 ・経理システムへのインポートログデータ 経理システムへのインポート処理に関する詳細なログデータがデータベースに保存されます。 ・経理システムへの未確定インポートデータ 経理システムへは未確定データとしてインポートされます。その内容を経理担当者が確認後、取り込み処理を確定します。 １２・外部インタフェース ・メール 経理担当者へのバッチ処理完了を通知します。 ・Slack バッチ処理が失敗した時にシステム管理者グループへ通知されます。 ・CSV処理 経理システムへ接続してAPIを通じてインポート処理を実行します。 １３・データフロー 本システムのデータ処理は次のようになります。 ⅰバッチシステムが売り上げマスターより対象となるデータを抽出 ⅱバッチシステムが抽出したデータを経理システムへ取り込めるように加工 ⅲバッチシステムが経理システムへ接続 ⅳバッチシステムが経理システムへデータを送出 ⅴバッチシステムがログをログテーブルに記述 ⅵバッチシステムが経理担当者へバッチ処理完了のメールを送信 ⅶバッチシステムが対象の売り上げマスターデータへインポート完了のフラグ立て １４・非機能要件 ・互換性 過去システムとの互換性は維持されます。なお経理システムのバージョンは12.0.0を対象としています。マイナーアップデートは問題ないと思われますが、メジャーアップデートのタイミングでAPIが変更される可能性はあります。 １５・スケジュール 日付 内容 省略 １６・予算 省略 |
※わからない用語は調べて確認しておきましょう！
機能仕様書
機能仕様書では、要件定義でまとめた「やりたいこと」を、どんな機能で、どう実現するかを整理します。
ここでは、機能ごとの処理内容や画面上の動作、入力条件、制限事項などを具体的に記載していきます。
この資料は、開発者やテスト担当者が「この機能はこう動く」と正確に理解するための基盤となるものであり、仕様の認識齟齬を防ぐためにも非常に重要です。
記載項目の例
- エラー時の挙動や制限
- 機能名称（例：顧客検索）
- 処理概要
- 入力・出力情報
- ユーザーの操作に応じた挙動（ボタン押下時の処理など）
画面仕様書
画面仕様書では、各画面にどのような要素があり、それらがどう動くかを記述します。
特にフロントエンド開発やデザイン工程では、UI/UXを意識した情報設計が重要となるため、この資料の精度が全体の使いやすさを大きく左右します。
視覚的な理解を助けるために、ワイヤーフレーム（画面の構成図）や画面遷移図（どの画面からどこへ遷移するか）を合わせて作成するのが一般的です。
記載項目の例
- ユーザーアクションに対する遷移先や挙動
- 画面名称（例：ログイン画面、顧客登録画面）
- 表示する項目（例：入力フォーム、ボタン、メッセージ）
- 各部品のレイアウトや制御
ワイヤーフレーム(画面設計)とは？
ワイヤーフレームとは、画面のレイアウトや構成をざっくりと描いた設計図のことです。
ボタンや入力欄、メニューなどが「どこに」「どんな風に」配置されるかを視覚的に整理するために使います。
【目的】
・画面の構成を関係者で共有する
・実装前にUIのイメージを固めておく
【ポイント】
・デザインより構成重視（色や装飾は省略することが多い）
・ペーパープロトタイプや手書きでもOK
ツール例：「Figma」や「Adobe XD」、軽くなら「Excalidraw」「draw.io」など
画面遷移図とは？
画面遷移図は、どの画面からどの画面へ移動するのか（遷移するのか）を線でつないで示した図です。
アプリやWebサービスで、ユーザーがどのように操作してページを移動するかを可視化します。
【目的】
・ユーザーの操作フローを明確にする
・開発者やデザイナーが画面構成の全体像をつかむ
【ポイント】
・「ログイン画面 → ホーム画面 → 設定画面」といった流れを矢印で表す
・モーダルやポップアップの遷移も記載すると親切
ツール例：draw.io、Cacoo、Lucidchart など
図として見せたい場合は矢印付きのフローチャートで OK！
詳細仕様書
詳細仕様書は、機能仕様書をより細かく分解し、実装に必要な具体的な条件や処理内容を記載する資料です。
入力値の制約やエラーハンドリングの方法、外部サービスとの連携仕様など、開発者が迷わずに実装できるレベルの情報が求められます。
たとえば、「ボタンを押すと何が起きるか」「処理結果をどう返すか」といった機能ごとの仕様が明記されるため、プログラマーと設計者との認識のズレを防ぐ重要なドキュメントです。
例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 |
チャット概要 ・チャットとは ・画面遷移図 ◆チャット ・ギルド内のコミュニティツールとして テキストチャットによるやりとりができる。 入力はフリー入力（NGワードあり） ソロの場合や、不特定多数との交流としては利用できない。 【チャットの使用制限】 チャットは常に使用可能ではなく、以下の条件下で使用可能 ・ギルドに所属している ギルドに所属している時に限り、ギルド内のチャットを行うことができる。 ギルド内チャットはどのシーンでも利用可能。 ・NGワード 一定の単語または文字に関してNGワード設定がされており、 NGワードを入力した際、該当文字を伏字表示（XXXX）する。 【チャットの併用】 ギルドチャット、チーム内チャットのどちらも利用可能な場合、 チャットを切り替えて利用することができる。 【チャットの使用方法】 チャットの使用方法についてはCS版及びPC版で異なる。 CS及びPC版はそれぞれ指定のキーを入力することでチャットウインドウを開くことができる。 文字入力の方法については、PC版はキーボードによる入力 CS版、モバイル版はキーボードまたはソフトウェアキーボードによる入力となる。 文字の表示可能数は全角40文字（仮）まで。 【チャットの表示】 チャットは常に表示されず、チャット受信時画面左端にアイコンが表示される。 チャットウインドウを開くことでメッセージを確認できる。 上記について、ギルドチャット等の種類は問わない。 【チャットログ機能】 チャットは最大100件（仮）までログを確認することができる。 【初回利用時】 チャットの初回利用時（メッセージ入力の時のみ）にチャット利用の規約について 同意確認を行う。 同意しない限り、入力はできない。（受信は可能） 同意後、2回目以降の確認（同意確認の画面表示）は行わない。 【入力禁止ワード（NGワード）のパターン別対応】 基本仕様： 入力禁止ワードが文章内にあった場合、該当箇所をXXXXといった形で 伏字に変換する。 伏字に変換するにあたり、該当文字が完全一致する場合のみ対応する。 例）あいうえおかきくけこ ⇒「うえお」がNGワードだった場合 ⇒あいXXXかきくけこ となる。 NGワードがスペースまたは・で区切られている場合の対応： スペース及び・を削除した形で文章のチェックを行い、 該当箇所がある場合は伏字に変換する。 例）う え お ⇒「うえお」がNGワードだった場合 ⇒う え お を うえお に変換しチェック ⇒「うえお」がNGワードに一致するので、 X X X となる。 ※判定はスペース及び半角スペースのみ対応する。 別の文字や句読点が入った場合は無視する。 例）う◆え◆お や う、え、おの場合はスルー 大文字小文字の混在する場合の対応： 小文字を大文字に変化した形で文章のチェックを行い、 該当箇所がある場合は伏字に変換する。 例）うぇお ⇒「うえお」がNGワードだった場合 ⇒うぇお を うえお に変換しチェック ⇒「うえお」がNGワードに一致するので、 XXX となる。 漢字が混在する場合の対応： 判別するためには膨大な量の辞書データベースが必要となるのでスルーする 例）上お ⇒「うえお」がNGワードだった場合 ⇒上 を 「うえ」と読むか「ジョウ」と読むか判定できないので 上お のままで表示する。 漢字の読みが複数ある場合の対応： 読みを考慮した漢字のひらがな文章化には複雑なアルゴリズムと 膨大な量の辞書データベースが必要なるので読みに関わらずNGワードに指定された 漢字または熟語が採用された場合は伏字に変換する。 |
システムのフロー参考図
画面詳細設計
画面詳細設計は、実際のUIを構成する各パーツの動きや制御条件を明確に定義する資料です。
画面仕様書（ワイヤーフレームや遷移図）では大まかな構成や動きを示しますが、画面詳細設計ではどの入力項目にどんなバリデーションをかけるのか、各ボタンの動作条件、表示／非表示の条件など、より細かい振る舞いを記載します。
実装の最終段階で必要になるケースが多く、特にフロントエンド開発やテスト設計において重要な役割を持っています。
基本設計書
基本設計書は、システム全体の構成や技術的な方針を決める設計書です。
使用する言語やフレームワーク、サーバ構成、外部システムとの連携方法など、技術面の「全体像」をここで定義します。
データベース構成についても、ER図（エンティティ・リレーション図）を用いて、テーブル間の関係やデータ構造を視覚的に示します。
主な記載内容
- 権限・認証に関する設計方針
- 使用技術やインフラ構成（例：AWS、Laravel、MySQL など）
- システム構成図（フロント／バックエンド、外部API との接続など）
- DB設計（ER図、テーブル定義）
詳細設計書
詳細設計書では、基本設計で決定したシステム構成をもとに、実際の処理フローやロジック、細かな挙動を定義していきます。
ここでは各機能の処理手順や分岐条件、使う関数・アルゴリズム、外部ライブラリなど、実装時に必要な情報を具体的に記載します。
この資料があることで、開発者が迷わずコーディングでき、またテストケースを作る際にも役立ちます。
記載内容の例
- 処理フロー（フローチャートやシーケンス図）
- 入力・出力パラメータの仕様
- データの取得・更新の詳細な手順
- 例外処理やエラー時の挙動
- 使用するツール・ライブラリ
データベース設計
データベースにはテーブル定義を表現するシステムテーブルがあることが多く、SQLを抽出することで得ることが多いです。しかし、構築するシステムの要件・仕様を理解していなければ、そもそもデータベース上で用意するべきテーブルの種類やカラムを定義できないです。まずはどのような要件の、どのようなシステムを構築するのかをしっかりと理解し、そのうえで、要件定義書や外部設計書などをもとに情報を整理することが必要になります。
データベース定義書 例1 会員マスター
テスト設計（参考）
テスト設計とは、システム開発のテスト工程で行うテストの目的や内容を決定することです。 テストの対象となるシステム・ソフトウェアに対して、テストをする機能や内容を明確に設計します。
テスト仕様 例
仕様書を書く注意点
1. 誰が読んでも理解できるように書く
- 読む人はエンジニアだけとは限りません（ディレクター、デザイナー、クライアントなども見る可能性あり）。
- 専門用語は必要に応じて補足をつける or わかりやすい表現に言い換える。
🔸NG例：「リクエストヘッダーにトークンを含めて…」
🔹OK例：「ログイン中のユーザー情報を確認するために、通信の際に“トークン”という鍵を送信します。」
2. あいまいな表現を避ける
- 「だいたい」「場合によって」「基本的には」などの曖昧表現はトラブルの元。
- 具体的な条件・数値・フローを明記する。
🔸NG：「エラーが起きた場合は適宜対応する」
🔹OK：「エラーが起きた場合は、ステータスコード500を返し、エラーメッセージを画面上に表示する」
3. 矛盾や抜け漏れがないかチェックする
- フロー図や画面遷移図と内容が一致しているか。
- 登場する機能や項目が、どこかで「突然出てきてないか」確認する。
4. 最新状態に保つ（アップデートを忘れずに）
- 実装中や仕様変更が入ったとき、古いまま放置すると混乱の原因に。
- 更新日を明記する or バージョン管理するのがおすすめ。
5. 図や表を活用する
- テキストだけでは伝わりにくい仕様（画面遷移、条件分岐など）は図や表で見える化。
- ワイヤーフレームやフローチャートなども有効！
6. 「なぜこの仕様にしたのか」の背景も書くとGood
- 特にレビューや実装の際、開発者や他メンバーが判断に迷ったときに助けになります。
課題① テーマを決めて、要件定義書を作成しよう！
上記のサンプルをテーマを決めて、要件定義書を作成して提出してください！
※余裕があれば機能仕様書も作成してみましょう！
提出方法はDiscordへファイルを添付する形で問題ございません。
雛形を使用しても、個人で用意してもOKです！
課題② 画面・設計ドキュメントをまとめて作成しよう！
要件をもとに、仕様・設計を整理して開発準備を整えよう！
作成したら提出してください！
※完璧な仕様書を目指す必要はありません。
画面イメージ、機能のロジックや動きなどが整理されていればOKです！
仕様書・設計書のフォーマットは自由ですが、誰が見てもロジックが理解できるよう、わかりやすく伝えることを意識してください。
作成のヒント
✏️ 作成のヒント
- 画面仕様書を作成しよう
→ どんな画面が必要か？ざっくりレイアウトやUIのイメージを書いてみよう。 - 必要な情報を洗い出そう
→ 画面に表示する内容や、ユーザーが入力する情報など、出すもの・使うものを整理しよう。 - 画面の遷移図を描こう
→ ユーザーがどの画面からどの画面へ移動するのか、フローを図で示すとわかりやすい。 - 機能・ロジックを整理しよう
→ ボタンを押すと何が起きる？条件分岐は？必要な処理を具体的に書き出そう。 - 必要なデータベース設計をしよう
→ ユーザー情報やデータを管理する必要があるなら、テーブル設計も行ってみよう（例：カラム名・型・制約など）。
課題③ ポートフォリオを完成させよう！
完成したポートフォリオをGitHubにpushして、提出してください。
※途中でレビューが必要なときや“こういう機能にしたいけどどうしたらいいかわからない”などありましたら、遠慮なく質問してください！
■ポートフォリオ作成時に重要なポイント
- 作品のクオリティ・システム・デザインは可能な限り高めてください。
・見た目の美しさや使いやすさはもちろん、機能面も重視します。 - バグなく動作し、セキュリティ面にも配慮された作品にしてください。
・フォームバリデーションやSQLインジェクション対策など、基本的な対策をお願いします。 - コーディング規約を守り、可読性・保守性の高いコードを心がけてください。
・適切なコメントの記載や、フォルダ・ファイル構成も含めて、他人が読んでも分かりやすいようにしてください。 - 他者に見せる／公開することを前提として完成させてください。
・実際に企業の選考などに提出できるクオリティを目指します。 - 見た目だけのLP（ランディングページ）ではなく、動きのあるWebアプリを作成してください。
・API連携、セッション管理、自動処理、ログイン認証などを含んだ構成としてください。 - 作品に応じて、以下のような構成が求められる場合があります。
・管理画面の作成
・API連携によるクライアントアプリの開発（スマホアプリ等）
※おすすめのテーマ例：
- 会員サイト
- 検索サイト
- EC（販売）サイト
- 予約管理サイト など
■補足事項
- 開発を始める前に、Laravel一式をGitHubにアップしてください。
→ 作業差分の確認・レビューのために必要です。 - 進捗ごとにGitHubへこまめにプッシュしてください。
→ 完成したページ単位でレビューを行います。
課題・復習用検索キーワード
| 検索例 |
| 🔍promiアイミツ 基本設計書 |
| 🔍金融 設計書 テンプレ システム開発 |
| 🔍システム開発 要件定義 テンプレート |
| 🔍システム開発 詳細設計書 テンプレート |
| 🔍ウォーターフォール開発とアジャイル開発 |