皆さん初めまして

フロッグポッドの鈴木です！

フロッグポッドでは社外研修を受けさせてもらえます。

今回は、研修に参加して学んだ「チームでのシステム開発」のことについてお話ししようと思います。

僕が入社したタイミングが、新卒の方たちと重なっていたので、研修先には大勢の方たちが参加していました。

そこで座学研修やプログラミング研修等学ぶのですが、最後の二週間はチーム開発ということで、研修生で4～5名1チームに分かれシステム開発を行いました。

複数人でシステム開発する機会がなかったので、今回の研修でチーム開発の経験が出来て勉強になりました。

その時実際に行った作業は以下の通りです。

■チーム開発の流れ

1. チーム名決め
2. 作成するシステム決め
3. 役割決め
4. チームとしての目標設定
5. 個人目標設定
6. 要件定義
7. スケジュール作成
8. 設計
9. 実装
10. テスト
11. プレゼン準備

まずは作るシステムを決めます！

...といっても今回はあくまで研修で、期間も「2週間」と限りもあるので研修先から選択肢が3つ用意されていました。

僕たちのチームはその中から図書管理システムを作成することにしました。

作成するシステム：図書管理システム

目標：ローカル環境で実行しながらプレゼンをする

今回の記事では「6.要件定義」で作成したドキュメントについてご紹介させていただきたいと思います。

■作成したドキュメント一覧

• ユースケース図
• ユースケース記述
• ガントチャート
• 用語辞書
• テーブル設計書
• ER-図
• 画面レイアウト設計書
• 画面遷移図

こうして一覧で確認するとめちゃくちゃありますね...笑

一つ一つどういったものかご紹介します！

■ユースケース図

システムで出来ることを「ユーザー目線」でわかりやすく図にしたものです。

アクター（使用者や組織や外部システム）がどういったことができるのかを図に落とし込んでいきます。

例えば販売システムだと利用者は「商品を購入する」ことができ、販売者ができることは「商品を登録する」「売上を集計・閲覧」等といった情報を見て理解できるように作成していきます！

【例】

参照：ユースケース図の書き方 | 分かりやすく図解で解説 - ITを分かりやすく解説

このように図にまとめると誰がどういうことができるのか、できないのかがひと目見てわかりやすくなり、認識違い等のトラブル、修正の時間が減らせそうですね！

研修では全員で1枚作成してみて、粒度の確認をしてから分担して作業しました。

■ユースケース記述

ユースケース図がシンプルでわかりやすい図で作成したのに対して、ユースケース記述は文章でユースケース図の流れを記述していきます。

「概要」や「アクター」「前提条件」「事前条件」「事後条件」「基本フロー」「代替フロー」等の詳細な情報を

処理の流れに沿って確認できるように作成していきます。

【例】

参照：第97回：　ユースケーステスト（前編）｜Kouichi Akiyama｜note

どういう順番で処理が行われるのか、どういう状態だと利用できる（前提条件）かがユースケース図ではわからなかったですが、

ユースケース記述を作成することでより詳細な情報がわかるようになりましたね。

■ガントチャート

ガントチャートはExcelのような縦横の表をイメージしてみてください。

縦列には「システム開発にあたり必要なタスク」と「担当者名」「開始予定日」「終了予定日」「ステータス」等の情報

横列には「日付」「作業日程」を設定します。

Aというタスクは△△さんが3日かけて処理する予定というのがひと目でわかるので、

• 誰がどこを担当していて
• 今はなんの作業をしているのか
• 各タスクの進捗は順調なのか遅れているのか

をガントチャートを見れば確認できるようになります。

【例】

参照：ガントチャートって何ですか？：初めてのガントチャート（1） - ＠IT

■用語辞書

用語辞書は、使用している用語や類義語等とその意味を記載することで、第三者がシステムや用語をすぐ理解できるようにするのに役立ちます。

また単位等の情報を載せることでシステム内で単位がバラバラになったりしなくなり、全体で協調の取れたシステムを作成することができます。

• 顧客のことをなんと表現するのか？
• このコメントに書かれている記事ってどれを指すのだろう？
• 温度の単位は「度」？「℃」？

等々の情報の詳細をあらかじめまとめておくことで余計な修正作業や確認待ちの時間を減らすことができます。

■テーブル設計書

テーブル設計書では各データベースに、どのようなデータが入っているのかを記述します

• テーブル名
• カラム名（論理名：日本語での列名）
• カラム名（物理名：データベースに登録する英語の列名）
• NULL制約（項目の入力を必須にするか、入力なくても登録できるかを設定）
• データの型（値型なのか文字列型なのか等々の型を記述）
• 列制約
• 主キー、外部キー等の情報
• デフォルト値の情報　等々...

これらをExcel等を使用して作成していきます！

参照：テーブル定義書 - データベース研究室

■ER-図

ER図（Entity Relationship Diagram）は各データベースにはどんなカラム（列）があって、各データベース間のつながりはどうなっているのか（一対一、多対一や多対多等の情報）

主キーや外部キーはどれか？といった情報が確認できる図です。

ER-図では各項目のことは下記のように呼びます

• 各テーブルのことを「エンティティ」
• カラムは「アトリビュート」
• つながりを表す線を「リレーション」
• リレーションの詳細のことを「カーディナリティ」

【例】

参照：若手プログラマー必読！５分で理解できるER図の書き方５ステップ | NTTコミュニケーションズ 法人のお客さま

上記の画像はIE記法という書き方で書かれており、カーディナリティが鳥の足のような形になっているのですが

他にもIDEDF1X記法では●や♢を使用して各ER-図なんかもあります

■画面レイアウト設計書

画面ごとのレイアウトをざっくりと作成して、実際にコーディングする人が画面レイアウト設計書を見ながら実装できるようにするドキュメントです。

この画面には、ドロップボックスを置いて～～やテキストボックスを設置して～

リンクに飛ぶのはボタンなのか、リンクラベルなのか...といった情報を記述していきます。

また表示する選択肢の数や入力できる文字数の情報等も合わせて記述していきます。

参照：第5回　［画面編］見れば"わかる"「画面レイアウト」の作り方 | 日経クロステック（xTECH）

■画面遷移図

画面遷移図では、それぞれの画面の関係性を記述していきます。

どの画面からどの画面に遷移するのか、遷移先が複数ある場合はそういった情報も全て記述します。

例えば

登録画面→確認画面→（登録）完了画面

上記のような3画面があった時に画面遷移図を作成すると下記のような画面遷移図ができると思います。

参照：画面遷移図とは｜「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典

上記のような画面遷移図をシステム全体からみて作成していきます。

【例】

画面遷移図があれば各画面から遷移できる画面はどこなのか、どういう順序で画面が遷移していくのがわかりやすくなりますね！

はい！！ということでチーム開発中に作成したドキュメントの紹介は以上となります。

世の中に数あるドキュメントのほんの一部ではありますが、一度のチーム開発でこれだけのドキュメント作成をできたのはいい経験になったと思います。

以上フロッグポッド鈴木でした！