私は「カラオケ(仮)」という個人サービスを作って運営してます。まあ、運営してますと言えるほどたいしたものではないし、アクセスもほぼゼロなんですけど、それはこの記事では本質ではないのでおいておきます。
メインのコンテンツは全国のカラオケボックス情報なんで、その収集と入力を行っているのですが、そのためのツールはGoogleスプレッドシートを使っています。サービスの根幹ですから、この入力のための専用ツールを開発してもよかったし、実際最初は作ろうと思っていたんですが、思いとどまったんです。それは「個人開発をはじめよう！クリエイター25人の実践エピソード」という本に載っていた事例を思い出したから。
そこの書いてあった話では、一人きりで、なおかつ余暇時間のみを使うというマンパワーが限られる個人サービス開発においてはいかに作らないかということが大切だと説かれていました。既存にあるものは利用できるモノは出来る限り利用し、限られたマンパワーはどうしても開発しなければならない作業にのみ投入すべきだと。だから管理画面は自作せずにGoogleスプレッドシートを使っているとのことでした。
まあ、考え方はいろいろだと思います。個人サービス開発は大抵の人にとっては趣味ですから、やりたいように好きなように作ればいいというのも正しいです。周辺ツールを作っているのが楽しければ、それでいいんですよね。ただ、そうしてマンパワーを違うところに費やしてしまうと、本来作りたかった個人サービスはいつまで経っても完成しません。個人サービスを完成させることが第一の目的なら、その目的の為にマンパワーを使うべきですよね。自分が楽しむのが第一の目的なら、周辺ツールを楽しく作って、メインのサービスはいつまでも完成しないというのでもいいんですが。
ということで私もそれに習って「カラオケ(仮)」では管理画面は自作せずに、Googleスプレッドシートを使いました。正直、機能的に実現できてなくて不便だなと思うことがないではありません。でも、今のところ致命的な問題は発生していないので、当面はこのままでいこうと思っています。
さて、ここまでは個人サービスの開発について述べてきました。こっから先はビジネスの、お仕事での話です。私は流しのプログラマをしているので、これまであちこちの現場を渡り歩いてきました。で、そのあちこちの現場ですが、管理画面を自作しているケースが実際には非常に多かったです。
そりゃ作りたくなる気持ちは分かります。Googleスプレッドシートなど、既存のツールを流用するのだと、どうしたって機能が不足します。Googleスプレッドシート自体が機能不足というのではなく、あくまでも汎用ツールなので個々の専用ケースで必要になる機能までは用意できないんですね。それならエンジニアが自作したらいいんじゃないかというのは分かります。その管理画面の使い勝手がビジネスの競争力の源泉であるなら、自作するのもありでしょう。でも、そうではないケースでも管理画面が自作されてる場合も多々見かけました。
実際、今時ならちょっとした管理画面を作るのってそんなに大変ではありません。rails newして数日程度かければ一通りの機能を実装できるでしょう。でも、あくまでも片手間で開発されたものなんですよね。開発工数が正規のスケジュールに組み込まれているわけではない。開発自体はスケジュールに組み込まれても、今後ずっと発生する保守工数までは見込まれていない。
一方で、管理画面が作られて現場で使われるようになるとどうなるか。細かい使い勝手の要望が次々にあがってきます。バグ報告だって当然あがってきます。ビジネスのスタイルが変わって、それに併せて管理画面の修正が必要になることもあるでしょう。でも保守工数を見込んでいませんから、エンジニアはそれらの対応をすることが出来ません。メインの業務の合間に少しずつ進めるしかありませんが、それではとても追いつきませんので、管理画面を使っている現場からは不満が出てきます。不満が気持ちだけの問題ならいいんですが、機能不足やバグの為に現場に余計な作業が発生していたりとか、ビジネスに支障がでてきてしまうことだってあります。実際、あちこちで見てきた管理画面はそういった状態に陥ってるモノが多数ありました。
こういう可能性を考えると、それくらいならすぐ作れるさといって自作してしまうのではなく、本当にそれが自作しなければならないのかは、慎重に検討しなければならないですよね。既存のツールでは絶対に無理なのか、既存ツールで間に合うようにビジネス側の要求を変更することだって検討するべきですよね。そうした検討のうえで管理画面を自作せざるを得なくなったとしたら、それはもう自社のビジネスの根幹を成すツールなわけですから、開発だけではなく保守の工数や人員もしっかりと予算をつけて配置すべきなんですよね。既存のスタッフがあいてる時間で対応しますっていうのはやめるべきですよね。
だから、いかに作らないかというのは、個人サービスでも大事ですが、マンパワーが豊富と思われるビジネスの現場でも同じことなんだと思います。会社では何人も何十人ものエンジニアがフルタイムで働いてはいますけど、だからって無間のエンジニアパワーがあるわけではない。既存の業務で手一杯で、新しい作業に割ける工数が余ってるわけではありませんからね。
さらに話を発展させて、最近流行りのDXについて。これもどこかでの受け売りなんで私の持論ってわけでもないし体験談でもないんですけどね。
これからはDXだといって業務のデジタル化を押し進めると言ってはいるけれど、実体としては既存の業務をそのままデジタル化してるケースも多いらしいですね。でもそれって意味ないですよね。本来ならデジタル上ではどういうフローで業務を行うべきか再設計するべきってことですよね。でも実際にはそこまで踏み込んでDXしてるわけではない。だからスキャナとかOCRとかがDXの本命みたいなことになってしまってる。まあそれが入り口ってのもわからないわけでもないし、手書き伝票のままよりはどんな形であろうともデジタル化されてる方がいいってのも事実ではあるんですけれども。
業務パッケージを導入するとき、自社の業務フローにあわせてパッケージをひたすらカスタマイズするってのも聞いたことがあります。つまり業務にシステムを合わせてる。「うちの会社のやり方は特殊だから」って自慢げに語ってますが、実際その特殊なやり方が果たして競争力の源泉になっているのか、ビジネスの本質を担っているのか。そこまでの分析がされているかどうかというと、多分されてないですよね。単に今までのやり方を変えるのが面倒なだけ。実際には業務をシステムに寄せていくことで業務自体を効率化できるんだろうと思います。まあ、業務パッケージが機能不足すぎてどうしようもないって可能性もゼロではないんですが、だったらその業務パッケージは導入せず、ほかのパッケージを探したらいいんですよね。