Nintendo Switch用『モンスターハンターライズ』が発売されて2週間が経った。
今回の「モンハンライズ」は、前作のワールドと比べると、かなり難易度が易しいという印象だ。すでに現バージョン1.xでのハンターランク（HR）上限7に到達したハンターも多いのではないだろうか。私もHR7に到達して現段階でのラスボスも倒し、今は金冠周回と護石ガチャに勤しんでいるところだ。何はともあれ、早く次のバージョン2.xのダウンロードコンテンツが配信されて、HRの上限解放が来て欲しいものだ。
さて、今のところ私のハンター生活が落ち着いているので、この機会にモンハンライズのスキルシミュレータを自作してみようと思い立った。
そんなわけで、連載コラム形式で、モンハンライズのスキルシミュレータの開発についてを、順を追いながら紹介して行こうかと思っている。実践的なアプリケーション開発の知見的な情報として伝えることができれば、もしかしたらエンジニア歴の浅い人の役に立てるかもしれないし……そんな連載にできれば良いなぁ……。
ぶっちゃけ、自分の興味のあるモノを題材にして、さらに直接的に自分に恩恵のあるアプリケーションを作るのは、モチベーションが半端なく高まるんで、久々にとことん趣味に没頭したモノ作りをしてみようというのが本音である。まぁ、フレームワーク選定やシステム設計といった、プログラマーやコーダーが普段なかなか手が出しづらい（もしくはあまり好まない）フェーズのノウハウなども紹介できれば良いかと思っている。
全体設計 – Overall Design
まず、何かを開発するにあたって決めなければならないものがある。それは、「誰のために」「何を」「どのようにして」作るのかだ。これを決めるのが要件定義や基本設計と呼ばれるフェーズである。
要件定義は、つまるところ要求されている顧客のニーズを一覧化して可視化することだ。おおまかには、漠然としたすべての要望を「できる」「できない」で分類して、「できる」ことのみをインベントリ（目録）としてまとめる感じだ。このフェーズで策定された要件はシステム仕様のひな形となり、基本的には変更されないことが望ましいものである（開発方式によっては開発途中での仕様変更を許容する場合もある）。
業務として開発する場合、発注側のニーズを取りまとめたRFP（提案依頼書：Request For Proposal）をベースに、システムエンジニアの監修を受けながら費用感や納期、開発知見などのナレッジを盛り込んだ要件定義書を作成するのが目標となる。
その要件定義書から費用見積もりが行われ、受発注が確定するまでは営業ターンとなり、受注した時点で開発体制をキックオフし、アプリケーション全体の設計が行われる……というのが、ITシステム開発のオーソドックスな流れだ（まぁ、こんな風に理想的な流れで開発着手できるケースは稀だったりするのが実情なんだけどね……w）。
全体設計では、アプリケーションを稼働させるためのインフラ設計や、アプリケーション本体のフレームワーク／データベース選定、サブシステムとの連携の可否、ユーザーインターフェース（UI）や画面遷移の設計などなど、およそ開発するアプリケーションの骨格となる様々な設計が行われる。俗に基本設計とか外部設計とも呼ばれるこの設計フェーズで、どの程度まで成果物を作るかはプロジェクトの規模によってまちまちだが、経験則的にこのフェーズをないがしろにすると、完成度の低いアプリケーションしか出来上がらないことが多い。
一般論はさておき、今回は趣味のアプリケーションなので、業務用アプリとは違って、そこまで格式ばった厳密な設計はしない（というか、したくないw）。複数人で開発するものでもないし、テスト駆動開発とかやり始めると、途端に開発へのモチベーションが落ちるので（笑）、基本的にはウォーターフォール式の一本道な開発方式で良いかな……と（もし途中で仕様変更が必要になったら、アジャイル型に切り替えれば良いかな）。
というわけで、最初に決めておくべきなのは、アプリケーションの概要と、稼働環境の策定、採用する要素技術の選定ぐらいで十分だろう。
要件定義
今回のスキルシミュレータは、ユーザー（私）が欲しいモンハンライズのスキルを選択して、それが実現できる装備セットの候補を提示してくれるというアプリケーションだ。完成品は自分のブログ上にリリースして、WEBアプリケーションとして利用できるようにする。また、PCとスマホどちらでも利用できるUIにしたい。検索アルゴリズムはちょっと複雑になりそうなので、パフォーマンスを得るためにデータベース側のSQLに任せてしまおう。
──というような、要望をまとめると、
誰のために
- モンハンライズのプレイヤー（≒想定するペルソナとしては、とりあえず自分w）
- 基礎データを投入する管理者（これも自分）
何を
- PCとスマートフォンのどちらでも使える
- 多言語化に対応した
- パフォーマンスの良い
- スキルを検索して装備セット候補を提示してくれる機能
- 護石の登録機能
- ユーザー毎に検索結果をマイセットとして保存できる機能
- 個別にデータを追加・編集できる機能（管理者用）
- 複数データをCSVで一括登録する機能（管理者用）
どのようにして
- MySQLデータベースを利用
- 開発言語はPHP 8.x
- PHP側のフレームワークはなし
- フロントエンド側はVue.js+Vuetifyを利用
- 基本言語は日本語（データベースに登録する各種データの言語）
- 多言語化はvue-i18nを利用
- インフラは当サイト（
https://ka2.org）のWEBサーバ内 - ソース管理はGitで行う（BacklogにするかGitHubにするかは後ほど検討）
要件定義項目は、上記のようなインベントリになった。
いやはや、だいぶ緩い感じのインベントリだが、これは趣味的な小規模開発だから許されるのであって、業務用システムの要件定義書としてこんなのを見せたら確実に怒られるだろう。業務として要件定義を行う場合ならば、他に詳細な対応プラットフォームリストや、セキュリティに関する事項、運用・保守フェーズにおける要望、将来的に拡張を予定している機能、サービスリリースにおける制限や条件など、あらかじめ決めておいた方が良い項目は多い。可能な限りステークホルダーのニーズを聴取しまくって、全ての要望や提案を書き出し、精査して、できる限りスキのない作りにしておく必要があるのだ。なぜならば、この要件定義書こそが受注側の開発プロジェクトを発注側の無理難題から守るための切り札の一つになるからだ。
エンジニア（もしくはプロジェクト管理者）目線で言い換えると、設計フェーズは開発プロジェクトを様々なステークホルダーから防衛するための戦略的準備段階なのである。開発着手後や、テストフェーズ時に「あ、ここにはこういう機能を追加して欲しい」とか「このブラウザだと動かないので対応してください」など、要件定義書に仕様として策定されていない難易度の高い変更要望が発生した際に、「それは、今回の開発要件には含まれていないので、次のバージョンアップ等で対応しましょう」などと説得して、開発フェーズを混乱させる要素を排除していく交渉の有効な手札となりえるからだ。
今回はここまで。次回は、この要件定義をベースにしてデータベースの設計に取り掛かる。
