WordPressで業務システムを作ってみた。

こんにちは。最近、ドローンパイロットを目指している藤中です。
ネクストページではホームページのCMSとして、WordPressを取り扱っています。
今回、WordPressで売上管理、予算管理の業務アプリを作って、半年間運用してみたので、ブログにしてみました。

なぜWordPressなのか

去年まで、営業計画と売上管理をExcelで行ってきたのですが、以下のような欠点がありました。

営業（計画）と売上（結果）のファイルが別で全体を把握しにくい
お客様ごと、案件（プロジェクト）ごとの工数（予算消化状況）がわからない

また、必要な条件は以下のものでした。

複数拠点で同時に使えるクラウド型で、マルチユーザー対応であること
現実的な速度で動作すること
開発・運用コストが安いこと
簡単に使えること

そして、もうひとつ重要なポイントは「私が作る」ことでした。社内のエンジニアはお客様からの仕事で忙しいし、依頼するならそれなりの仕様書を用意し、コスト管理をしないといけない。私が空いた時間を使って作れば、開発・仕様の作り込みを同時に行えて、ラクだし楽しいな、というわけです。
当初、Salesforce、kintoneなどのクラウド型DB、CRMを検討していました。各社、営業の方にも頑張っていただき、現実的な価格でご提案いただきました。
ただ、今回、実現したい業務は5テーブル程度のシンプルなシステムだったので、それらのサービスは、少々高機能すぎるとも感じていました。
次に検討したのが、パッケージDBです。特に、FileMakerなら、クラウドサービスもあり、敷居が低い印象。いいんだけど、開発ノウハウを蓄積しても、お客様の仕事には活かせない。
なんとなく、決め手に欠ける中、もんもんとした日々を過ごし、「せっかく作るなら、プログラムの勉強も兼ねて、Pythonで開発…」などと、身の丈に合わないことも考えておりました。そして、Amazonのクラウド開発環境を申し込んだと同時に、「あれ、CMSでいけんじゃね」というアイデアに行きつきました。

CMS（WordPressなど）での業務システム開発のメリット

入力画面は開発の必要がなく、表示部だけ作ればいい
最初からクラウド型で、マルチユーザー対応
運用コストはサーバー利用料のみ、ってかサーバーは既に契約しているのでタダ
開発に行き詰まったら、社内の優秀なエンジニアに教えてもらえるし、手伝ってもらえる

まさに、今年前半の思い付きランキングナンバー1のアイデアでした。
懸念点は以下の通り。

事例が少ない
シンプルなDBではないので、実用的な速度がでるのか
テーブル間のリレーショナル（繋ぎ）ができるのか

ちなみに、よく勘違いされるのですが、ネクストページはシステム開発屋さんと違って、プログラムをゴリゴリ書いている会社ではありません。
社内のエンジニアは、主にブラウザでの表示部分（フロントエンド）と、CMSの実装が得意で、PHP、SQLでの開発は、たまにお受けする程度です。
私は、WordPressなら触ったことがあったので、さっそくサンプルを作ってみました。カスタム投稿で、お客様と案件を入力できるようにし、Advanced Custam Fieldプラグインでリレーションさせただけの簡単なものでした。
それでも、日曜プログラマーの私には、それなりの難易度で、作るのに3日程度かかったかもしれません。
それを見せながら、社内エンジニアのはまちゃんに相談。
私「こんなの作ってみたんだけど」
はまちゃん「WordPressなんですね。一応、テーブル間、連携してますね」
私「エントリーが増えてきたらちゃんと動くかしら？」
はまちゃん「う～ん、これに日報が入るなら、もっとシンプルじゃないと動作速度がでないかもしれないですね。お客様やめて、案件だけじゃダメなんですか？」
私「お客様ごとの集計もしたいから」
みたいなやりとりがあったと思います。
結局、動作速度は実装してみないとわからないということになり、私がコツコツ開発を進めることにしました。

開発フェーズ

開発にあたって、あきらめた機能もあって、それは期またぎの集計機能でした。当初の構想では、数年間分の分析もできるよう、マルチブログなどでの実装も考えていたのですが、1年で10,000エントリーくらいになりそうなので、ず～っと使うシステムではなく、単年で新たなCMSを立てる仕様に縮小しました。
開発は主に東京出張中に行いました。東京事務所は神戸のように人数が多くないため、声をかけられる機会も少なく、出張前に、神戸の仕事をだいたい終わらせてくるため、時間を作りやすかったのです。
そして、東京には優秀なエンジニアの谷がいます。
私「谷君、ここのループはどうやって書けばいいの？」
谷「あ～、ここはこうですね」
私「ここのループは？」
谷「こうですね」
私「このループは？」
谷「そこは、こうですね」
ループのことばかり聞いていましたが、システムは徐々に完成に近づいていきました。たっぷり1人月（20人日）程度かけたかもしれません。それでも、1月くらいから開発を初めて、4月くらいにはリーダー職以上限定で動作テストを行うことがきました。
ソフト名は、WordPressとMG研修の用語「MQ」をお借りして、「WPMQ」と名付けました。
私としては、これで、個人やチームの数字が分析がしやすくなるぞ！　と自信満々のリリースでした。
期待していた反応は「数字まる見え～、すご～い」とか「プログラマーでもないのに、こんなの一人で作るなんて、社長って~~ヒマなんですね~~勉強してるんですね」みたいなものでしが、実際の社員さんの反応はイマイチ。
突然謎のソフトが目の前に現れ、
「ん？　何のソフト？」
「使い方わからん」
でした。
とくに「マニュアル作ってください」というのが多かったため、しぶしぶマニュアルを作ったら、自分たちで、もっと詳しい別のマニュアル作っていたので、「そんなら、最初から俺に言うなよ～」みたいなこともありました（笑）

運用開始

6月に入り運用を開始すると様々な問題が出てきます。
「前期請求済みの仕事はどうやっていれたらいいの」
といった、運用で解決していったこともあったのですが、みんなで数年にわたり受講しているMG研修の知識が使えず、上手く数字を入力できない人もたくさんいました。
バグもひとつずつ、つぶしていきました。一度、間違って国家予算並みの売り上げが入力されており、グラフがばかになっていたこともありました。
「こんな機能が欲しい」といった前向きな要望は嬉しいもので、当初はがんばって対応していましたが、最近は、私が飽きちゃったので（ヒドイ）、今はそ～っとしています。

動作速度

WordPressのDBは、プレーンなDBではないこともあり、日々、使用していると動作速度が落ちてきます。現在、3,000エントリー程度となっており、特定画面の表示が20秒以上かかるようになってしまいました。3,000エントリーというと、それほど多いわけではないので、コードの見直しで、もう少し動作速度が稼げるかもしれません。
元々、速いと言われているPHP7を使用しており、不要エントリー（リビジョン）を削除するなど、ケアは行っています。10,000エントリーくらいまで耐えられるなら、実用性が高いので、現在、調整＆経過観察中ですね。