本当に価値があるのは「引き算」ができるひと

同業のSIerの人にはぜひ読んでほしいですが、仕事をする上で必要な考え方としては、どんな役割を担っている人にも考えてほしいことです。

TL;DR

本当に価値があるのは「引き算」ができるひと

本記事における「引き算」とは

引き算とは、なんとも意識高い系な言葉ですね!

私は日頃SIerでプログラムを書いているので、プログラム→システムの順に見ていきましょう。

Javaの引き算

lastValue = radicalValue - lostValue;

プログラムの引き算

プログラムを開発するとき、何かの機能を作るために必要なライブラリやフレームワークが見つからないとき、それを自作することがあります。 いわゆる技術的負債といわれるものですね。きらいな人も多いでしょう。

また、使用できそうなライブラリやフレームワークが「今後将来サポート・バージョンアップされていくのか不安なもの」「あまり多くの人が利用しておらず、安定性や信頼性の面で不安なもの」という場合も、自作することがあると思います。これは「負債」になるのでしょうか?

私は「負債」という扱いにはならないと思います。

第三者のライブラリやフレームワークに依存すると、その把握や維持・管理のコスト、上記の不安が的中するリスクが発生します。システムが継続・エンハンスされている間は、ずっとそのコストがかかり続けます。運用・保守担当者が入れ替わる場合は、新規の学習コストがかかります。

この判断は、将来的に発生し得るコスト・リスクを「引き算」したといえますね。


ただ、自分たちのプログラム能力が足りず、自作するのに膨大な学習時間・工数が必要だったり、それを同様に維持・管理するための膨大な教材作成が必要となるのであれば、そのほうがコスト・リスクが大きくなる場合があります。

そのときは、自分たちで作るコスト・リスクを「引き算」して、ライブラリ・フレームワークに依存しましょう。

システムの引き算

私と同じようにシステムを開発したことのある人ならやったことあると思いますが、 「この機能は年に1回しか使わないから、便利機能などはつけずに少ない工数で実現する」というのも、「引き算」です。

作って無駄になるものは、作らなくていい、ということですね。

あれ?

……ちょっと待ってください、なんでその機能が無駄だとわかるんでしょうか?


”機能”ということは、その機能が何かしらの役割・作業を担うということです。

会社の業務を行うシステムに新しい機能を持たせれば、システムを使って仕事をする社員の手間を減らすことができます。

ある機能を作ることにより、作業時間が10分短縮されます。その機能を作るのに10万円かかります。

でも、同じ10万円をかけて短縮された(システムを使う会社が、10万円をはたいて買った)10分でも、社員ウン百人の毎営業日 x 10分ならまだしも、社員1人の年1回 x 10分では、ぜんぜん釣り合いとれませんよね。

1人10分10万円ってことは、その人時給60万円ですね。ひゃっほう!(違う

つまり、その機能を作成しなかったのは、 損失 の大きさが

10万円のコスト > 10分のコスト

と判断し、10万円 - 10分の人件費 の差額損失を「引き算」したということになります。


さぁ、これで「引き算」の基礎共有ができたかと思いますので、ここから 本題 に移りたいと思います……

ここからが本当の

上にこう書いてます。

10万円をかけて短縮された(システムを使う会社が、10万円をはたいて買った)10分でも、社員ウン百人の毎営業日 x 10分ならまだしも、社員1人の年1回 x 10分では、ぜんぜん釣り合いとれませんよね。

ということは、暗に 損失 の大きさが

10万円のコスト < 社員ウン百人の毎営業日 x 10分のコスト

だと言っています。

さて、 本当にそうでしょうか?


さらに上にはこう書いています。

プログラムを開発するとき、何かの機能を作るために必要なライブラリやフレームワークが見つからないとき、それを自作することがあります。

そのときは、自分たちで作るコスト・リスクを「引き算」して、ライブラリ・フレームワークに依存しましょう。

もちろんプログラムを作るのであれば、どちらかを選ばないといけないですよね。そうしないとものができません。

さて、 本当にそれだけでいいのでしょうか?


プログラム→システムの順に見ていきましょう。

バック トゥ ザ:プログラムの引き算

技術的負債の程度により、作り方が決まりました。さぁ、開発を始めましょう。

開発にあたり、メンバーはいろいろなことを考えています。

(さぁ新しい技術でシステムを作るぞ!)

(また新しいの使うの?この前使ったやつみんな覚えてるからそれでええやん。)

(こっちのライブラリの方が使いやすいし昨日も実現できると思うんだけどなぁ)

(ふんぐるい むぐるうなふ くとぅるう るるいえ うがふなぐる ふたぐん)

実はこの時点で、大きな損失が発生しています。

メンバーのモチベーション 」の損失です。

メンバーのモチベーションの損失は、本当に大きな問題です。進捗悪化、品質低下、SAN値低下など、よくある問題は大体これが絡んでいます。

「メンバーのケアはマネージャーの仕事だから関係ないだろ!」と言う人もいると思いますが、違います。そこまで含めてのメンバーのケアです。メンバーが関わるすべてのものが、メンバーにモチベーション低下を発生させる可能性を含んでいます。

陥らないためには、お互いに 頭の中にあるものを言葉にできる機会 を、たくさん作ることがいいと思います。デイリーミーティング、定期的なKPTなど、仕事のルールから外れなくても機会は結構増やせます。


また、これまで「ライブラリ、フレームワークに依存する」「自作する」など挙げてきましたが、その機能を作らない という選択肢がないか、今一度考えてみてください。

システム開発と同時にBPRを行わない限り、ユーザーは新しいシステムがなくても仕事をすることができています。

新しい機能がシステムに追加されると、ユーザーはその使い方を覚えなければなりません。

この場合、開発をする私たちのコストバランスだけでなく、ユーザー側に予想だにしない 損失 が発生することがあります。

これも「引き算」の手段です。

バック トゥ ザ:システムの引き算

システムに仕事の役割を任せるということは、社員はその役割を担う必要がなくなります。

減った分だけ、楽になりますよね。

そしたら、今度はあれもシステムにやらせよう、これもシステムにやらせよう、となります。

一晩経てばあら不思議、システムの役割が「仕事を楽にするもの」という意識が会社全体に根付きます。いわゆる魔法の道具になります。

魔法の道具と思ってないよ!と言っているあの人も、もれなく魔法の道具だと思っています。

これにより、新たな損失が発生します。「自分たちの仕事を見直す文化」の損失です。

システムに対する考え方が根付いてしまうと、大抵の場合は上層部取っ替えくらいしか、対処の方法がなくなってしまいます。 上層部を取っ替えるまでに費やされた何ヶ月・何年のあいだは、仕事のやり方は見直されず、その間に継続的な改善が行われていた場合に比べて、空白の時間の損失が発生します。

会社間トラブルでよくある 売り上げ損失 とイコールです。

なんと、誰にも邪魔されないまま、自分たちの力で売り上げ損失を発生させることができるんです!やりましたね!


ということで、システムに機能をもたせる、持たせないという判断は、人件費などその時々の予算額だけでは判断できないということです。

陥らないためには、次のようなことを考えたほうがいいです。

「システムではなく、人が担わなければいけない仕事はないか」

「システムに任せることで、会社という人間の集団から失われてしまう文化はないか」

まとめ:本記事における「引き算」とは

ものをつくったり、仕事をしたりすると、今の社会にも未来の社会にも多種多様な 価値 がもたらされます。

私が思っている価値の例をならべると次のとおり。

  • もの
  • 資金
  • 文化

でも、これまで書いてきたような 損失 が増えると、もたらされるはずだった 本来の価値 が減ってしまいますよね。

「引き算」とは、 損失 から引く ことです。

損失 が減れば、価値が残ります。

本当に価値があるのは「引き算」ができるひと です。


僕はキメ顔でそう言った。