社内利用ツールを2020年らしいプロセスで作ってみる(Vue.js + Electron + SQLite3) Day1

# はじめに

社内システムが異常に使いにくく、フィードバックは社内で大量に出ているものの作ってすぐだし情シスもリソースないしということなので、アンチパターンながら、自分の部署だけで使う手元ツールを休暇を利用して作ってみることにしました。

ざっくり何が欲しいのかというと、業務システムを開発する組織で、要員管理、案件管理、収益管理などの目線で部署やチームの計画を立てるためのツールです。
表計算ソフトに近い表中心のシンプルなUIで、何を見て何を決めるかのノウハウが少しだけ詰まったような軽量なツールを目指して作りますので、特にSIerのみなさん生暖かく見守ってください。

# 開発のためのお供（参考書籍）

### 開発の進め方

【日経BP】[.NETのエンタープライズアプリケーションアーキテクチャ](https://shop.nikkeibp.co.jp/front/commodity/0000/P98480/)

ドメイン駆動設計をはじめとして、アーキテクトなら読んでおけ的な本だと聞きました。
アーキテクトを目指している訳ではないものの、せっかくゼロから作るならイマドキな知識は入れておきたいなと。

ざーっとだけ一通り読んで、あとは使いたいときに辞書的に使います。
エリック本は過去に読もうとして早々に諦めたので、開発中心で書かれていて助かりました。

### Webデザイン

【BNN】[超明快　Webユーザビリティ　ユーザーに「考えさせない」デザインの法則](http://www.bnn.co.jp/books/8161/)

Webデザインやユーザビリティ関連に興味が出たときに買って読んでいた本です。
本屋でWebデザイン関係の本をみていたのですが、パラパラめくった感じが読みやすそうで買いました。
「考えさせない」という論旨がはっきりしていてブレていないので、好きな本です。

# 大まかな開発の流れ

1. ツール作成の目的と動作環境を検討する -> [Day1](#ツール作成の目的と動作環境を検討する)
* アーキテクチャをいったん検討する -> [Day1](#アーキテクチャをいったん検討する)
* ユースケースを洗い出す -> [Day2](https://qiita.com/takeout44/items/4135a9bb3d3e7c705cb1)
* 画面イメージのスケッチを作成する -> [Day2](https://qiita.com/takeout44/items/4135a9bb3d3e7c705cb1)
* ドメインモデルを検討する（用語の定義、振る舞いの定義）
* ユースケース、画面イメージのワイヤーフレーム、ドメインモデルを何周か見直す
* 当初決めた目的が果たせるか利用者目線を検証する(コンセプトの検証)
* 単純なCRUDアプリでアーキテクチャを検証する(実現方式の検証)
* コアになるユースケース1本だけプロトタイプ作成(MVP)
* 本格的に準備して開発を始める(テスト駆動のイテレーション開始)

お供に選んだ書籍の、特に以下の部分を参考にしました。
第5章　ドメインアーキテクチャの発見
第6章　プレゼンテーション層
第7章　伝説のビジネス層
第8章　ドメインモデルの紹介

個人的に弱かったデザイン分野の用語の抜粋、理解

* スケッチ: アイディアを書き留めるために描かれる手書きの図
* ワイヤーフレーム: 機能、レイアウト、ナビゲーション、情報に焦点を合わせた、よりハイレベルなスケッチ
* モックアップ: 実際のルック&フィールに配慮し、サンプルのUIを貼り付けたワイヤーフレーム
* プロトタイプ: バックエンドなしorテスト用のダミーのバックエンドでビューと既存データで実装したフロントエンド

今回はクライアントPCでスタンドアロンで動くものが完成形なので、プロトタイプはDBがモックなくらいということですかね。

# 開発日記(Day0)

お供に選んだ開発の進め方の書籍にざっと目を通しながら、ちゃんと勉強していなかったDDDについてふんふんなるほどなるほどとなる時間を取りました。

前から作りたくて少しずつ練っているサービス開発と、今回のツール作成と、実利が近い方がいいと思い後者を選択しました。

# 開発日記(Day1)

休暇のはずながら午前は社用（事務処理の類）もあって、お昼過ぎくらいから記事を書きながら本格開始しました。

## ツール作成の目的と動作環境を検討する

### 目的

現行システム（今回は社内システム）では何が出来ないか。何がしたいか。何はしなくていいか。

現行システムへの不満としては、一番は何を登録/参照するのがどの画面なのか分かりにくいのと遅いという使い勝手の面なのですが、機能面で改めて考えると、登録と参照が切り離されていて、計画立案のような登録するべきデータを計数を見ながら考えるというユースケースで使える機能がない点でした。
要員、案件、執務スペースなどの前提条件を準備して、各案件への要員アサインをフレキシブルに変更しながら、収益や必要座席数などの計数を可視化して、計画を立てたい。また、今後も計画は見直すことになるので、計画内容は保存したい。

やらなくていいのは、リッチなアニメーションやきっちりとした入力制御、マーケティングやタスク管理の観点も排除します。

将来的には社内システムと連携できるようなCSVファイルexportも出来たらいいでしょうが、かなり先ですね。

### 動作環境

制約や条件として、どんなものがあるか。

いわゆる古い体質の大企業での社内システムを補うツールとしたいため、以下の条件になりました。

* 配置先はサーバーではなくWindowsのクライアントPCで完結する
* インストール不要でスタンドアロンで動作する（GitHubからzip取得や自宅PCからのメール持ち込み）
* 同じツールを複数人でデータ共有しながら利用可能
* データ保存先はツール利用者が選択可能（共有フォルダへの配置も想定）
* 初回起動含めて動作時のインターネット接続は不可

## アーキテクチャをいったん検討する

### アプリ開発言語

インストール不要のスタンドアロンアプリということで、.NETアプリか、Electronか、React Nativeあたりが選択肢のようです。

C#で.NETで作るのが本に沿っていけそうでいいのですが、友人から格安で譲り受けた2011年くらいのMacBookAirで開発しておりSSD容量的にVisualStudioがしんどくて、昔Xamarinを触ってみるのにインストールしたもののアンインストール済だったりするので外します。
Reactはちょっと独特なところあるという情報も見かけていて、最初はAngularやVueがいいのかなということでVue.jsベースのElectronでやってみます。

### データ永続化方法

またデータの保存先については、ElectronについてGoogle先生に教えてもらったところ、画面サイズなどの設定はユーザーディレクトリのJSONで保存して、トランザクションを意識した処理をしたい業務データはスタンドアロンで使えるDBMSであるSQLite3がよさそうと判断しました。

これでDBも含めて実行ファイルの入ったフォルダを配置したらスタンドアロンで動きそうですね。

### アプリケーション構成

構成としては、ヘキサゴナルアーキテクチャを採用して、当然ドメイン駆動設計を意識して進めます。

## (横道)開発ツール事情を下調べ

これから開発を進めるに当たって、せっかくの自由な環境なので2020年らしい開発ツールを使った開発を目指します。
いろいろ試して感想も書けると自分だけでなく誰かのためになりますし。

### UML(ユースケース図、クラス図)

draw.io、PlantUML、Astah professionalあたりがメジャーな選択肢のようです。

今回の開発環境はインターネット接続可能なので、以下の記事を参考にしてdraw.ioをGitHubと連携させる方針にします。Diffの見え方が美しい。。

【企業技術ブログ】[図を継続的に管理するためのベストプラクティス](http://developer.wonderpla.net/entry/blog/engineer/diagram_best_practice/)

【個人運営サイト】[超便利フリーUMLツール「draw.io」でユースケース図を作成する方法](https://medium-company.com/%E3%83%A6%E3%83%BC%E3%82%B9%E3%82%B1%E3%83%BC%E3%82%B9%E5%9B%B3/)

PlantUMLをVSCodeでリアルタイムプレビューする環境は構築済なのですが、マシンスペックのせいかプレビューに時差があってサクサクと書けなかったので、新しい試みをします。
インターネット接続なし環境ではPlantUMLは本当に便利で、業務システム開発の案件ではよくお世話になっています。
また、今の現場はAstah professionalを購入予定で、こちらもcommunityの頃からいい製品ですよね。

### 画面スケッチ

これは紙とペンですね。書きやすいボールペン買います。

### 画面ワイヤーフレーム〜プロトタイプ

この分野は、ツールによって守備範囲がいろいろあるようですね。
主要そうだと思ったのは、Figma、Adobe XD、Sketchあたりです。

今回は一番勢いがありそうなFigmaを試してみます。
バージョン管理を備えていて、GitHubとは連携しないのかな？触りながら見てみることにします。
以下のブログをみる限り、Figma単体でGitの知識がなくてもバージョン管理出来るのがメリットとして書かれていそうに見えます。ちゃんと読んで触ったら情報アップデートします。

【企業ブログ】[Using Figma designs to build the Octicons icon library](https://github.blog/2018-04-12-driving-changes-from-designs/)

### コードエディタ、IDE

以前も使っていて世間に情報も多いVisualStudioCodeを使います。
今はエディタとIDEの垣根ってかなり低いですよね。
他で主要そうだと思ったのは、VisualStudio、Atomあたりでしょうか。
業務システム開発の分野ではまだまだEclipseをよく聞きますが、インターネットなし前提だといいのかもしれません。

## (横道)GitHubでリポジトリ作成時のライセンスについて知る

【GitHub公式】[適切なライセンスを選択する](https://help.github.com/ja/github/creating-cloning-and-archiving-repositories/licensing-a-repository#choosing-the-right-license)

なんとなく雰囲気は掴めたものの自信がなく、ここも見てみました。

【Qiita】[githubでライセンスを設定する](https://qiita.com/shibukk/items/67ad0a5eda5a94e5c032)

今回はどちらの説明でもしっくりくるGPLにしよう！

## ユースケースを洗い出す

このあたりから本格的に本で学んだことを実践していきます。Day2に続く予定。