システムにおける考えが変わった話

もともとスクラッチ派だった

自分は新卒の時から、Filemakerというソフトウェアを使って、ある程度の業務システムを自分で作成してきました。
要件定義さえしてしまえば、自分で自由に作成できる。
"既存の"業務をどう効率化していくか。
イメージでいえば、今１００かかっているものを、どうやってFilemakerを使って５０や３０にしていくか。手計算しているものを、計算式に置き換える。AのデータとBのデータの連携を手動でやっているなら自動化する。何かを転記しているのであれば、マスタを参照できるように組み込む、書類の出力もできるようにする、、、etc。
実際にこれで業務の効率化をできた事例はたくさんあるし、品質も上げてきた。ミスも減ったし、残業も減った。
この"原体験"がスクラッチってべ便利じゃん！自分で要件定義さえできれば、"既存"業務を効率的にできるし、"現場がやりたいこと"も実装してあげられる！
そんなことを１０年くらいやってきました。
業務システム、人事の基幹マスタ、人事評価システム、３６０度マルチサーベイのシステム、等々いろいろと自分で作成して、主に社内展開していました。しかもソフトウェア代だけで、開発費用は自分の人件費のみです。
これはこれですごく重要な経験だし、システムって便利でおもしろいな、と思うきっかけです。

以下、ざっくりな社歴です。今４社目。
１社目：基本システムは内製している会社
　⇒ここでFilemakerを覚えた

２社目：パッケージを追加開発しすぎて、半分スクラッチ、改修にも莫大なお金がかかって、誰も紐解けないカオスになっている業務基幹システムがあった。
人事のデータベースはエクセルと、古来のアクセスで超非効率だった
　⇒人事系システムは自分でFilemakerで一から作成して情報の集約と運用を固めた。
業務基幹システムは重すぎて誰も手を付けられず。。
　⇒結局パッケージだったら、外れる業務があったら別システムや改修でコスト払ったりシステムが増えたりするじゃん！パッケージ高いし、不便！

３社目：システム？何それ？エクセルと紙でいいじゃん！
　⇒人事系システムは２社目と同じように自分で作成。ワークフローや精算のシステムは要件がシンプルだったのでパッケージを導入。ただし、パッケージは現場からの要望や既存業務のスライドができないことがいくつかあった。

４社目：パッケージが入っており、それをどう使うか考えた。

パッケージもよいな、と思った理由

さて、ここで最初に立ち返ると、自分の原体験は「既存業務に合わせて自分でシステムを作ったら効率化できる。パッケージは企画要件がドはまりしないから柔軟性に欠ける」というものでした。
なので、自分で作っちゃったほうが楽じゃん！
ということ。

少し脱線します。2021年、３社目の時のとある人事の交流会で、自分が今までやってきた自社開発の人事マスタの話をアウトプットしました。
自分は意気揚々と今までやってきた「効率化」の話をしました。
会場からの質問などにも答えて、自分としては満足気に終わろうとしたのですが、何やら会場の反応が微妙な空気でした。そして、決定的なことが起きました。司会の方が「とは言っても今は、パッケージの導入が主流だし～～」のような締めくくりをしました。
なんでか、自分の中で、すごい憤怒の気持ちが芽生えたことをめちゃくちゃ鮮明に覚えています。ワシの意図と逆やんけ！と。

さて、話を戻します。パッケージが便利と思った理由は2つです。前者は色んな人が感じることと思います。
実は今freeeというパッケージを使って人事管理をしています。
使って思いました、めちゃくちゃ便利です。勤怠付けられる（シンプルだけど）、そこから給与計算もできる、法定調書も出せる、入退社手続きの書類も出せる。
使い始めのときは、例えば社会保険の加入手続きは、保険の仕組みとfreeeの仕組みがわからなかったので、自分で年金事務所のHPからエクセルダウンロードして、それに記入して年金事務所に持参していました（あー、アナログ、、、）。でもfreeeでは、書類が入力さえしてあれば出力できます。
しかも、設定すれば電子申請もできちゃいます！（これまだうまくできてないですが、、、）
ただし、できないことも多いです。
もともとは会計から始まったシステムだからか、勤怠の付け方はすごくシンプルです。世にある勤怠管理システムには劣ります。やりたいことができません。
人事マスタとしての役割も、自分が行いたい管理方法ではできません。
人事に紐づけて管理したい項目も管理できません。例えば評価情報など。（もしかしたらできるのか？追加でお金必要なのか？）

パッケージがよいと思った理由①
できないことも多いけど、だいたいの重要なことはできる

パッケージもよいな、と思った最大の理由

とはいっても、そりゃ例えば勤怠管理やワークフロー、人事のシステムはある程度業務が一般的に共通だし、パッケージのメリットは大きいと思います。
ただ！！
例えば、自社の営業活動における管理項目は、自社のビジネスに依存します。一般的なこともあるけど、営業現場や責任者、経営陣からの要望があり、管理項目や必要機能はおそらく各社で違うと思います。
顧客管理に受注を紐づけたい、商談履歴も管理したい、担当者も管理したいけど更新もできるようにしたい、ついでに過去の担当履歴もみたい、その顧客も見込みレベルを入れたい、何なら自動で入る？
見積もりは、定価表あるんだけど、定価か直前までわからないものもあるんだよね、etc。。。
きりないくらい要望が出てきます。
すべて叶えるパッケージは基本存在しません。
何かを捨てるか、パッケージに改修をいれて使う選択肢になると思います。
※これがシステム会社が儲かる仕組みなんでしょうが。。。

だったら自分で作ろうじゃないか！となっていたのが今までです。
自分のリソースの問題だけになります。
開発改修して、アジャイルで作成して作って改修してを繰り返していく。
これで完成に近づいていくのは良いことだと思います。
現場の要望をかなえることが、ミッションだと思っているので、これは重要なことなんだ！とも思っていました。

そんな話を、４社目の上長や他の会社の人と話してたら、
当たり前のようだけど、目からうろこの話がでてきました。

「わかるけど、別に現場の要望全部叶える必要ないでしょ。使わない機能あるし、思いつきも大半だよ」
「というか、パッケージでできないって言い切っちゃえばいいじゃん。できないっていうのは必ずしも悪ではないよ。全部かなえたい気持ちもわかるけど、我々もそんなにひまじゃない。」
「ってか、もうシステムに合わせた業務設計にさせよう。統制上もそれが効率的。わがまま言わせてもコストかかるだけだよ」

！！！！！！！！！！！！

考えたら当たり前のようなことでした。
でも自分の中では新鮮でした。
システムは万能ではなく、使い方なのは言うまでもありません。
そうか、パッケージで決まった要件の中で業務を考えさせればいいんだ。
パッケージで賄えないところは運用でカバーしよう。

上記を念頭に、
営業現場との打ち合わせで、パッケージでの業務設計をしようという話になりました。当然要望がわんさかでます。
しかし、心を鬼にして「パッケージの範囲外ですね。運用でカバーできます？無理なら諦めてほしいんです。改修できるかもですが、追加コストと時間かかりますけど、やりますか？」
「えー、そうなの？上長と相談してみます」
数日後・・・
「パッケージでできる範囲で設計しましょうか」

おぉ！意外にすんなり諦めてくれた！（良い意味で）

当然、会社として決定的な機能や要件は実装すべきです。
でもパッケージ外の大半は、付加的な管理であることが多く、よく検討したらいらないものも多いです。
まさに、パーキンソンの法則！人はあったらあっただけ使う。
今回でいうなら、できると思うからどこまでも要望言う

でも大半は悪く言えばわがままであることが多い（そうでないことも当然あるので、そこはバランスです）

パッケージがよいと思った最大の理由②
いわれている要件のうち、実はいらないものが多く、
パッケージで賄えるように業務運用を考えたほうが色んな意味で効率的

今は、IPOを目指して業務設計やルールを作っています。
当然、数字も伸ばさないといけないから、営業の要望は聞いてあげたいです。
でも、我々も限られたリソースしかないし、無駄（言い過ぎ？）なことに時間を割きたくありません。
少なくともＩＰＯまでは、パッケージを使いこなし、効率的で統制の取れた業務を作っていきたいものです。