こんにちは！
スピードリンクジャパン（以下SLJ）の奥野です！
本日はプロつくの一つ、「HubOfficer」（通称ハブオ）についての後編です🦐
「プロつく…？」な方は以下の記事も見てみて下さい♪

以前の記事でお話したように、ハブオでは営業課題の解決策として
取引先を一元管理できるアプリを開発することになりました。
（前回の記事はこちら↓）

最初に直面する「要件定義」

さて、いざ開発しようとするのですが、まず直面したのが要件定義。

そもそも開発における要件定義とは、ソフトウェアやシステムを開発する前に、「何を作るか」「何ができるようにするか」を明確にすることです。
例えば、家を建てる際に「どんな構造」「どこに何部屋作るのか」「キッチンやリビングはどこになるのか」などを決める作業です。

私たちは「案件管理をする」「案件を検索できるようにする」というやりたいことは決まってるし、要件定義とか楽勝でしょ！と思っていました。
しかし…あれ、全然進まない…。（笑）

私たちは「要件定義」というフェーズで具体的に何をすればいいかが全くわかっていませんでした。

困り果てた私たちは、とりあえずイメージを固めるために画面遷移図を作成しました。
各画面のデザインなども考え始め、各画面に必要な機能などをとにかく羅列。

大体イメージ決まったし、とりあえず、データベースの設計でもするか！と意気揚々とDB設計をし始めました。
（もはや要件定義フェーズであるということも忘れてました＞＜笑）

ルンルンで始まった「DB設計」

さっそく私たちはDB設計に着手しました。

DB設計とは、リレーショナルデータベースにおけるテーブルの分け方、それぞれのテーブルで持つ情報、列名などを決めることです。

図書館の蔵書管理システムで例えると、「利用者情報」「書籍情報」「貸出情報」などのテーブルが考えられます。
この場合は、それぞれに利用者IDや氏名、書籍IDやタイトル、貸出日などのデータを持ちます。
それぞれのテーブルは独立していますが、一部に共通した項目を持たせれば組み合わせることが可能です。
つまり、「〇〇という書籍の返却期限」や「〇〇さんが借りている本」などを調べることができます。

ということでDB設計を進めていたのですが、やはり何が正解かいまいち分からない。
「案件情報」といってもなんの情報が必要なのか？案件を提案したり受けたりするときは何を基準に判断しているのか？など、実際に使用するイメージがあまり湧いていなかったのです。

HELP!!

さすがに困り果てた私たちは我社の誇るベテランエンジニアに一度DB設計を見てもらうことに。

すると彼から「ユーザ視点での要素がない」という指摘をいただきました。
営業担当者が実際にこのシステムを使う際に「何の目的で」「どういう場面で」使うのか、
データを入れる作業は面倒ではないか？
今後の業務がこのシステムによって本当に楽になるのか？
それをもっと考えて欲しいと。まったく、その通りです。

また彼は一言「システムの選定はしたのかな？」と言いました。
私たちは困惑。「はぇ？(なんかパッケージ的なものを選ぶのかなぁ。そんなのあるのかなぁ。)｣「要件定義なら…軽くしましたけど…」

そう、彼はシステム設計はしたのかと聞いたのです。

システム設計とは、要件を満たすために最適なサーバ･言語･DBの選定、組み合わせの確定、セキュリティ面の検討などを行うことですが、私たちはこれをすっ飛ばしていたのです…！

要件定義も曖昧なのに、さらにシステム選定もしないで、DB設計！笑
なかなか機動力のある組織です😂

そりゃユーザ視点も何もないですね！

システム設計

今回の場合、極端に言えば「DBって使う必要ある？」というところから検討するべきだったのです。

それは後に出てくる「ApacheSolr（アパッチソーラー）」が関係してきます。なんとこれ、サーバなのにDBを使わずデータをそのまま保持できちゃう変わり種。だから極端な話、一般的なリレーショナルデータベースは使わなくてもシステムができてしまうのです。それでも、RDBにはそれの良さもあるので、使う？使わない？という議論になるわけです。

さて、システム設計は先程言ったようにシステムの全体像を決める作業です。
私たちはベテランエンジニアの意見を元に、以下を使うことにしました。

ファイルサーバ：GoogleDrive
Webサーバ：Apache(ApacheSolr)
APサーバ：Tomcat
DB：PostgresSQL
言語：Java

結局ApacheSolrとRDBを両方使うことにしました。
理由は、それぞれに検索の適性があるからです！！

そもそも全文検索とは

全文検索は、テキストデータの中から、キーワードを含む文や単語を高速・高精度に検索する技術です。RDBと明確に違う点は、指定した検索ワードの意味やニュアンスまで検索の対象にしてくれるところです！

例えば、「旅行」と検索した場合…

RDBのあいまい検索：「海外旅行」「旅行する」など、「旅行」が入る文字列が返ってくる
全文検索：「旅に出る」などの「旅行」のニュアンスを含む文字列が返ってくる

つまり、Googleの検索ってこと。👍

一方でRDBが得意とするのはより正確で厳密な検索。
先ほどの図書館の蔵書システムなどもRDBの得意分野になります。

例えば「8月に本を借りた全利用者」を調べたい場合…
RDBなら期待通りの結果が整然と出てくるでしょう。
もしApacheSolrだったら…「本を借りた友達がいる」とか、「8月に図書館に行った」みたいな情報もぜーんぶ出してくれるでしょう。

プロトタイプを作ろう

無事にシステム設計が完了したので、ApacheSolrの機能を体感するついでにプロトタイプを作り始めました。
これは最近の話。
それぞれのメンバーが自分なりに「案件を検索できる機能」を作成しています！

その後営業担当者に見てもらい、どんな機能が欲しいか？どんな情報を表示したいか？を決めていこうとしています。
いわゆる、アジャイル方式ですね。
まだまだ改善点はたくさんありますが、自分たちでやってみると、世の中のシステムに感動します。
こんなことまで考えているのか…と。

今後とも様々な視点を取り入れて精進していきます！！！

最後までご覧いただき、ありがとうございました〜＾＾