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エントリーくらいまで耐えれるなら、実用性が高いので、現在、調整&経過観察中ですね。

まとめ

WorePressの業務システムを作って分かったことです。

  • 単機能のものなら簡単にでき、そこそこ複雑なものでもなんとかなる
  • テンプレートさえ組めば、他のシステムとの連携が容易
  • ウェブの技術だけでできる
  • 入力画面でのリレーションは弱く、エントリー同士の単純な繋ぎこみしかできない

以上。