Clo dCloud Spiralのの取取りり組組みみcloud-spiral.enpit.jp/wp-content/uploads/61e90235d... · チケット駆動開発 MVCモデルの理解と各層の実装 MongoDB

分野・地域を越えた実践的情報教育協働ネットワーク

Clo d Spiralの取り組みCloud Spiralの取り組み中村匡秀† 井垣宏‡ 佐伯幸郎† 柗本真佑†

楠本真二‡ 上原邦昭† 井上克郎‡†神戸大学大学院システム情報学研究科

‡大阪大学大学院情報科学研究科

Cloud Specialist Program Initiative for Reality‐based Advanced Learning


カリキュラムの基本方針

前期合宿前半合宿後半後期

受講生：修士課程１年，個人で数100行のプログラミング経験

クラウド開発基礎(下記演習と合わせて

10日×4コマ@中之島センター)

クラウド基礎PBL(1W)

クラウド開発応用(1W)

クラウド発展PBL(3回の対面講義と

分散開発)@中之島センター) )

クラウド開発演習

クラウドを利用したアジャイル開発(Scrum)の学習－チームでどのように作るか（チームビルディング）－プロセス・プロダクト品質を意識したScrum開発

継続的イグレシ

クラウドを利用したプロダクトの学習－クラウドを使って何ができるか－チームでクラウドを使った問題解決をする

－継続的インテグレーション

分野・地域を越えた実践的情報教育協働ネットワーク22


クラウド開発基礎及びクラウド基礎PBL(事前知識学習及び合宿前半）

クラウド環境を利用した

DaaS(Desk top as a Service)を利用した開発

ScrumScrum＋チケット駆動開発クラウド環境を利用した

開発手法

Scrum Master

QADにもとづくプロジェクト管理

Quality(プロダクト・プロセス品質)

CIツール(jenkins)を利用した継続的統合とテスト可視化

チケットシステムと版管理システム(svn)を利用したタスク管理

Product Owner

2種類のバーンダウンチャート

スプリント計画

Assignment(タスク割り当て，知識伝達)

Delivery(納期計画)

振り返り（KPT）

チケット駆動開発

MVCモデルの理解と各層の実装

MongoDB

Webアプリケーションフレームワーク(DWR)の利用

スプリントレビュー

概要設計書(ドメインモデルクチケット駆動開発

チケットシステム(Trac)

タスクの記録，抽出

Java，JavaScriptによるアプリケーション実装

MongoDB

アプリケーションサーバ

概要設計書(ドメインモデル，ク

ラス図，シーケンス図，ロバストネス図)の書き方，読み方

詳細設計書の読み方(ロバスト

ネス図クラス図シーケンス

ファシリテーションスキル

プレゼンテーションテスト技法

単体テストカバレッジ

アプリケションサバ(Tomcat)

チームビルディング

ネス図，クラス図，シーケンス図，javadoc，DB仕様書，テス

ト仕様等)


単体テスト，カバレッジ

結合テストWebアプリケーション開発

会議の進め方，議事録のまとめ方

© Cloud Spiral partners 2013 3


クラウド基礎PBL期間：8/22~26ただし開発期間はの日間

クラウド基礎PBL

ただし，開発期間は22~25の4日間受講生は最寄りのビジネスホテルに期間中泊まり込み

場所：大阪大学中之島センター場所：大阪大学中之島センタ会場は9:00~21:00まで利用可能

受講生：49名本大学受講生が参加西日本9大学の受講生が参加

スキル等にバラつきありただし，全員が事前知識講義受講済みただし，全員が事前知識講義受講済み

プロダクトとプロセス詳細設計書は教員が作成し，与えた


何をどのようなステップで開発するか，プロセスをどうするかは基本的なルール以外は受講生が策定し，実施した



クラウド基礎PBLへのScrum適用開発時間は固定し，計画・振り返りに余裕をもたせた

クラウド基礎PBLへのScrum適用

スプリント計画(任意)振り返り(KPT)（19時まで)

成果物：class A種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H

成果物：class B種類：実装着手時刻：13:00終了時刻：14:00見積時間：0 5H

成果物：class C種類：実装着手時刻：13:00終了時刻：14:00

成果物：class D種類：実装着手時刻：13:00終了時刻 14 00

成果物：class E種類：単体テスト着手時刻：

プロダクトバックログスプリントバックログ

総時間：1.0H担当者：受講生Xスプリント：UC[Login]

見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

終了時刻 14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login

終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login

着手時刻：終了時刻：見積時間：0.5H総時間：担当者：スプリント：UC[Logi

成果物：class A種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：

成果物：class B種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生X

成果物：class C種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生X

成果物：class D種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H

成果物：class E種類：単体テスト着手時刻：13:00終了時刻：14:00見積時間：0.5H

成果物：class A種類：実装着手時刻：13:00終了時刻：14:00見積時間：0 5H

成果物：class B種類：実装着手時刻：13:00終了時刻：14:00

成果物：class C種類：実装着手時刻：13:00終了時刻 00

成果物：class D種類：実装着手時刻：13:00成果物：class E種類：単体テスト成果物：class A種類実装成果物：class B

スプリント（）

スプリント（1日)成果物：class A種類：実装着手時刻 13 00成果物：class B種類：実装成果物：class C種類実装成果物：class D

スプリント：UC[Login]スプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]



見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

終了時刻見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

種類単体テ着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

成果物：class B種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

成果物：class C種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

成果物：class D種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

成果物：class E種類：単体テスト着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[Login]

開発(10:30~17:00)

開発メンバ顧客(教員)

レビュー（15分）着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：

[ ]

種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：

種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生X

成果物：class D種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生X

成果物：class E種類：単体テスト着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H

分野・地域を越えた実践的情報教育協働ネットワーク© Cloud Spiral partners 2013

Scrum Masterインクリメント

Product Owner Product Owner

5

UC[Login]スプリント：UC[Login]スプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]

総時間担当者：受講生Xスプリント：UC[Login]


プロジェクト目標の策定Quality

守るべきプロダクト品質の定義

プロジェクト目標の策定

スプリントレビューで評価

守るべきプロセス品質の定義（後述）

タスクごとの完了の定義を明記タスクごとの完了の定義を明記

プロセスの記録を必須とする

Assignmentタスクが適切に分担されているかを示す指標

各自が分担するタスクの量や種類がメンバー間で均等であること

特定の開発者に特定のタスクが集中することを避ける特定の開発者に特定のタスクが集中することを避ける

Specialist ではなく Generalist (多能工）を

Deliveryが進


計画通りに開発が進められているか



守るべきプロセスの定義

DoD(Definition of Done)を教員が策定し，提示


提示

例：例：レビュー

チェックリスト

必要に応じて更新される

バグ修正

ソースコード

NG任意の状態から発生する可能性あり

作成(ソースコード)

コーディング規約

実装計画書

サンプルコード

レビュー報告書 Doneレビュー

OK

NG 生する可能性あり( )

作成（単体テスト）

単体テストコードwith

単体テスト項目表

単体テスト計画書

ルール（一部抜粋）：• PR1. 作成（ソースコード）or バグ修正(ソースコード)‐>レビューの順に連続して実施されたタスクにおいて，

各種仕様書


PR1. 作成（ソスコド）or バグ修正(ソスコド) >レビュの順に連続して実施されたタスクにおいて，各タスクの担当者は異なっていなければならない

• PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，コンパイル可能でかつすべての単体テストが正常に通る状態で成果物をリポジトリにコミットすること 7


定量的なフィードバック定量的なフィドバック

分野・地域を越えた実践的情報教育協働ネットワーク© Cloud Spiral partners 2013 8


合宿前半(8/19~23): 受講生による総合評価評価中央値

平均値

4

5合宿の有益さ

合宿内容に対する理解度合い

合宿全般（コンテンツ，講師，自己評

価）に関する総合評価講師に関する総合評価

合宿を実施するにあたり，事前の授

業（4月～7月）の内容は十分でした…

1

2

3合宿における実施内容の事前理解

度合い

合宿前にどの程度予習をしたか合宿中の講師からのアドバイスの有

合宿中の講師からのフィードバック内

容

0合宿前にどの程度予習をしたか

合宿への参加度合い（積極性）説明や質問の回答における適切さ

（分かりやすさ）

益さ

合宿における自己総合評価

合宿の時間配分合宿内容に関する総合評価

講師のスキルや知識


合宿内容と期待した内容の差異合宿におけるコンテンツ評価

9




Assignment

タスクが適切に分担されているかを示す指標

Assignment


各自が分担するタスクの量や種類がメンバー間で均等であること均等であること

特定の開発者に特定のタスクが集中することを避けるを避ける

Specialist ではなく Generalist (多能工）をp (



Scrumフレームワーク以下のフレームワークを8/22~26に実施したPBLに適用した

Scrumフレムワク

適用したスプリント計画

振り返り(KPT)


( )

スプリント

スプリント（1~4W)

開発開発メンバ顧客レビュー




12


enPiT(Education Network for Practical I f i T h l i )Information Technologies)

分野・地域を越えた実践的情報教育協働ネットワーク13© Cloud Spiral partners 2013


Project‐based Learning*Project based Learning• 有期性がある

• 価値の創造に繋がる開発体験を伴う

ンテンツ主体

価値の創造に繋がる開発体験を伴う

• 教員による統制された管理・支援を伴う

コンテンツ主体

何を開発するか教員が決めプロジェ

開発対象は学生が決めるがプロセス

プロセス(プロジェクトマネジメント）主体

員が決め，プロジェクトマネジメントも教員が行う

決めるが，プロセスは教員が管理する

トマネジメント）主体何を開発するか教員が決め，プロセスは学生が管理する

開発対象もプロセスも学生が管理する


は学生が管理するHadj Batita, “A model for an innovative project‐based learning management system for engineering education,” CALIE'2001 ‐ Computer Aided Learning in Engineering Education, 2001

© Cloud Spiral partners 2013


Scrum

アジャイルソフトウェア開発フレームワーク

Scrum

アジャイルソフトウア開発フレムワク

決まっているのは枠だけで方法論ではない

アジイルソフトウア開発の多く( 6%)でアジャイルソフトウェア開発の多く(76%)でScrumが利用されている

短期間での実施を前提としたPBLに向いているいる

向いていない点もいくつか有りVi i O “St t f Agil D l t” d t d b t J l 22 d d


Vision One, “State of Agile Development” conducted between July 22nd and November 1st, 2011.

15


Scrum＋PBLの良いポイント

スプリントの時間は常に決まっている残業前業が

Scrum＋PBLの良いポイント

残業を前提としないため，授業時間が決まっているPBLに向いている

スプリント終了時にデモが実行できることが前提とスプリント終了時にデモが実行できることが前提となっている動作するアプリケーションを教員が確認できるため，最後になて何もできなかたということが無いなって何もできなかったということが無い

自己組織化全員が何をすべきかを認識し多能工として開発に貢献す全員が何をすべきかを認識し，多能工として開発に貢献することが求められるため，PMや特定の開発者に負荷が集中しにくい



Scrum＋PBLの難しいポイント

スプリントの時間は常に決まっている

Scrum＋PBLの難しいポイント

残業を前提としないため，時間が足りない

スプリント終了時にデモが実行できることが前提とスプリント終了時にデモが実行できることが前提となっている

時間の限られたPBLでは，デモが実行できるところまで到時間の限られたPBLでは，デモが実行できるところまで到達しないスプリントがありうる

自己組織化自己組織化

Scrum Masterや各メンバが何をすれば良いかわからない



スプリントレビュー要件の緩和

プロダクトバックログの粒度をできる限り小

スプリントレビュ要件の緩和

プロダクトバックログの粒度をできる限り小さくした

ただしデモができるレベルでただしデモができるレベルで

必ずしも毎日デモが実施できなくとも良いものとした



自己組織化：プジクト目標の策定Quality

プ質義

プロジェクト目標の策定

守るべきプロダクト品質の定義スプリントレビューで評価守るべきプロセス品質の定義（後述）守るべきプロセス品質の定義（後述）タスクごとの完了の定義を明記プロセスの記録を必須とする必須

AssignmentAssignment制約を守れているか（後述）

Delivery計画通りに開発が進められているか



Assignment


Assignment


各自が分担するタスクの量や種類がメンバー間で均等であること均等であること

特定の開発者に特定のタスクが集中することを避けるを避ける

Specialist ではなく Generalist (多能工）をp (



Assignment制約の例

必須制約

作成（）全開発期終了時各担

Assignment制約の例

作成（ソース）：全開発期間終了時，各メンバのタスク担当数がチームの平均値*1.2～0.8以内に収まること

作成（単体テスト）：全開発期間終了時各メンバのタス作成（単体テスト）：全開発期間終了時，各メンバのタスク担当数がチームの平均値*1.2～0.8以内に収まること

レビュー：全開発期間終了時，各メンバのタスク担当数がチムの平均値*1 2～0 8以内に収まることがチームの平均値*1.2～0.8以内に収まること

Optional制約作成（結合テスト）を各開発者がそれぞれ1回以上実施結合テストを各開発者がそれぞれ1回以上実施全開発者が全種類のファイル(*.java, *.html, *.xml)を1回以上作成・編集すること各開発者がcontroller, model, viewの各パッケージに含まれるコンポーネントそれぞれ1つ以上を対象とした作成(ソース)を実施すること各開発者が各パケジに含まれるポネトそれぞれ以上を対


各開発者がcontroller, model, viewの各パッケージに含まれるコンポーネントそれぞれ1つ以上を対象とした作成(単体テスト)を実施すること




DoD(Definition of Done)を教員が策定し，提示


提示

例：例：レビュー

チェックリスト

必要に応じて更新される

バグ修正

ソースコード

NG任意の状態から発生する可能性あり

作成(ソースコード)

コーディング規約

実装計画書

サンプルコード

レビュー報告書 Doneレビュー

OK

NG 生する可能性あり( )

作成（単体テスト）

単体テストコードwith

単体テスト項目表

単体テスト計画書

ルール：• PR1. 作成（ソースコード）or バグ修正(ソースコード)‐>レビューの順に連続して実施されたタスクにおいて，

各種仕様書


PR1. 作成（ソスコド）or バグ修正(ソスコド) >レビュの順に連続して実施されたタスクにおいて，各タスクの担当者は異なっていなければならない

• PR3. 作成（ソースコード）or バグ修正（ソースコード）完了時には，コンパイル可能でかつすべての単体テストが正常に通る状態で成果物をリポジトリにコミットすること 22


プロジェクト目標における課題

チームの目標と守るべきプロセスが明確に

プロジェクト目標における課題

チムの目標と守るべきプロセスが明確になることで，Scrum Master等の作業内容が（少し）明らかになった（少し）明らかになった

プロジェクトの現状把握，改善

現状を把握する手段が無い

客観的に確認できる手段がなければ，どうして客観的に確認できる手段がなければ，どうしても適当かつ曖昧になる

教員も評価できない


教員も評価できない


そこで・・・23


チケット駆動開発(TiDD)チケット駆動開発(TiDD)– タスクの決定，割り当て，実行といった開発の進捗をチケットに対する操作と組み合わせて行う開発手法

• チケット

– 開発者が行ったタスク内容が記録されるもの

作成

成果物：class A種類：実装着手時刻

成果物：class A種類：実装着手時刻

成果物：class A種類：実装着手時刻 13 00

成果物：class A種類：実装着手時刻 13 00受講生A

作成着手時刻：終了時刻：見積時間：総時間：

着手時刻：終了時刻：見積時間：総時間：

着手時刻：13:00終了時刻：見積時間：0.5H総時間：

着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H

現状の把握やプロセスの振り返りに非常に有用割り当て

着手受講生X

総時間担当者：

マイルストーン：UC01

総時間担当者：受講生Xマイルストーン：UC01

総時間担当者：受講生Xマイルストーン：UC01

総時間 1.0H担当者：受講生Xスプリント：UC[Login]

非常に有用


チケット終了

* 小川明彦, 阪井誠, "チケット駆動開発," 翔泳社, 2012.24


Scrum＋PBL＋TiDD以下のフレームワークにチケット駆動開発を導入した

Scrum＋PBL＋TiDD

スプリント計画(任意)振り返り(KPT)（19時まで)


スプリント（）

スプリント（1日)

開発(10:30~17:00)

開発メンバ顧客(教員)

レビュー（15分）

分野・地域を越えた実践的情報教育協働ネットワーク© Cloud Spiral partners 2013© Cloud Spiral partners 2013



25


スプリント計画へのTiDD導入

スプリントバックログ＝チケット群

スプリント計画へのTiDD導入

スプリント計画時にチケット作成

スプリント計画(任意)

成果物：class A種類：実装着手時刻：13:00終了時刻：14:00

成果物：class B種類：実装着手時刻：13:00成果物：class C種類：実装着手時刻：13 00成果物：class D種類：実装成果物：class E種類単体テストスプリント計画(任意) 終了時刻：14:00

見積時間：0.5H総時間：1.0H担当者：受講生X

終了時刻：14:00見積時間：0.5H総時間：1.0H担当者：受講生X


種類実装着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1 0H

種類：単体テスト着手時刻：終了時刻：見積時間：0.5H

スプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]


見積時間 0.5H総時間：担当者：

スプリント：UC[Login]


[ g ]UC[Login]

チケットによりスプリントバーンダウンチャートの


チケットにより，スプリントバンダウンチャトの自動生成が可能

26


開発へのTiDDの導入

開発と連動してチケットを操作する

開発へのTiDDの導入

成果物：class A種成果物：class B

開発

種類：実装着手時刻：13:00終了時刻：14:00見積時間：0 5H

成果物：class B種類：実装着手時刻：13:00終了時刻：14:00見積時間


成果物：class D種類：実装着手時刻：13:00成果物：class E種類：単体テスト着手時刻：13:00開発

(10:30~17:00)開発メンバ

Product Owner

見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：UC[L i ]

見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：




現状把握が可能となる

Scrum Master

Product Owner UC[Login]スプリント：UC[Login]スプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]

インクリメント

現状把握が可能となるスプリントバーンダウンチャートの自動更新Assignment状況の把握


Assignment状況の把握残タスクの可視化



振り返りへのTiDDの導入

振り返りのための判断基準の多くをチケット

振り返りへのTiDDの導入

振り返りのための判断基準の多くをチケットから取得できる

Assignment DoD成果物：class A種類：実装成果物：class B成果物 l CAssignment，DoD

客観的なデータに基づいて振り返りが可能となた

種類：実装着手時刻：13:00終了時刻：14:00見積時間：0.5H

成果物 class B種類：実装着手時刻：13:00終了時刻：14:00見積時間：0 5H


成果物：class D種類：実装着手時刻：13:00終了時刻 14 00

成果物：class E種類：単体テスト着手時刻：13:00

振り返りが可能となった振り返り(KPT)（19時まで)

見積総時間：1.0H担当者：受講生Xスプリント：UC[Login]

見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント：

終了時刻 00見積時間：0.5H総時間：1.0H担当者：受講生Xスプリント


着手時刻：13:00終了時刻：14:00見積時間：0.5H総時間：1.0H担当者受講生X（ 9時まで) UC[Login]スプリント

UC[Login]スプリント：UC[Login]担当者受講生

スプリント：UC[Login]担当者：受講生Xスプリント：UC[Login]



Q: 適正レビューコンポーネント割合

100%

Q: 適正レビュコンポネント割合※最後のタスクがレビュー・結合テスト

になっているコンポーネント

80%

60%

20%

40%

0%

20%

C G


A B C D E F G H I



A: Assignment制約遵守状況

100%

A: Assignment制約遵守状況

80%

60%

20%

40%

0%

20%

C G


A B C D E F G H I



D: チケットあたりの見積誤差

40

D: チケットあたりの見積誤差

30

35

20

25 preSprintSprint1stSprint2nd

10

15p

Sprint3rdSprint4th

0

5

C G


A B C D E F G H I



D: 生産性（チケット数比）

4.5

D: 生産性（チケット数比）

3.5

4

2

2.5

3 preSprintSprint1stSprint2nd

1

1.5

2 pSprint3rdSprint4th

0

0.5

C G


A B C D E F G H I



定量的なフィードバック定量的なフィドバック



Assignment制約に関する受講生からのメント合宿にAssignment制約があったのが，プログラ

コメント合宿 g 制約があたが，グラ

ム未経験者としてはとてもありがたかったです．おかげで，未経験の状態から最後には人に教えおかげで，未経験の状態から最後には人に教えられるようになるところまでなりました．

Assignmentのお陰で開発議論ともにだんだんAssignmentのお陰で開発,議論ともに,だんだんと参加できた気になった

A i は救済措置のつなのかなとおAssignmentは救済措置の一つなのかなとおもった



まとめと今後の課題

まとめ＋＋

まとめと今後の課題

Scrum＋PBL＋TiDD短期間で実施されるPBLにおいて，作業負荷や得られる経験の偏り，プロセス軽視といった多くのPBLにおける課題が改善できた改善できたプロジェクトの定量的な評価が実施できた

今後の課題チケットの妥当性正確なデータをどこまで入力しているか漏れについては自動チェック可能

受講生の詳細な開発動向とチケットを比較しミスを自動検


受講生の詳細な開発動向とチケットを比較し，ミスを自動検出できるようにしたいある程度は自動化できた（後述） © Cloud Spiral partners 2013 35

Documents

Clo dCloud Spiralのの 取取 りり 組組 みみcloud-spiral.enpit.jp/wp-content/uploads/61e90235d... · チケット駆動開発 MVCモデルの理解と各層 の実装 MongoDB

Clo dCloud Spiralのの取取りり組組みみcloud-spiral.enpit.jp/wp-content/uploads/61e90235d... · チケット駆動開発 MVCモデルの理解と各層の実装 MongoDB