ITエンジニアとして時間に対して対価を頂くということへの違和感がありませんか？
本当は自らが生み出した付加価値に対して対価を頂きたいたいですよね。
本記事では、それを実現した倉貫さんの『「納品」をなくせばうまくいく』を紹介します。本記事を読むと価値の源泉や付加価値ベースの働き方へのシフトを妨げる要因が分かります 。
目次
30代SIer勤めの私が本書を手に取った背景と期待
私は30代のSIer勤めのいわゆるSE
プロフィールにも記載しておりますが、私は某メーカー系SIerに１０年以上つとめているSEです。本記事を執筆している最中にどうやら私は、空間と時間から自由になってプロフェッショナルな生き方をしたいのだと解ってきました。
話は戻りますが、最初の数年は開発がメインで、このころは利益のことには相当無頓着でした。
時間に対して対価を頂くということへの違和感
近頃はビジネスに近いところで働いています。 現在は社内工数を積み上げて算出した原価を元に売価を設定していますが、このビジネスモデルではどうしても”時間を売っている”ように見えてしまいます。
同じ１時間でも人によってアウトプットに質が異なりますし、同一人物であってもコンディション次第で大きく異なります。
こうなるとどうしてもサボる人が増えてきます。正しく頑張った人が報われるべきです。
本当は付加価値に対して対価を頂きたい
コロナのおかげでリモートワークが普及し空間的な自由度は増してきましたが、時間的にはまだまだ不自由です。
このビジネスモデルは、そもそもスケール出来るビジネスではありません。
であるならば、付加価値に対して対価を頂くべきではないかと思っています。
じゃあどうすれば？を知りたい
このような想いがあり本書『「納品」をなくせばうまくいく』を手に取りました。
読む前の本書への期待は以下の２点です。
- ITエンジニアの時間以外の価値の源泉を知りたい
- 付加価値ベースの働き方へのシフトを妨げる要因を知りたい
本書の概要
本書について（著者・出版社・発行年）
著者
倉貫 義人（くらぬき よしひと）
大手SIerにて経験を積んだのち、社内ベンチャーを立ち上げる。2011年にMBOを行い、株式会社ソニックガーデンを設立。月額定額＆成果契約で顧問サービスを提供する「納品のない受託開発」を展開。全社員リモートワーク、オフィスの撤廃、管理のない会社経営など新しい取り組みも行っている。著書に『ザッソウ 結果を出すチームの習慣』『管理ゼロで成果はあがる』『「納品」をなくせばうまくいく』など。
株式会社ソニックガーデンHP
出版社・発行年
出版社：日本実業出版社
発行年：2014年 ※HTML 5が普及する直前くらいです。
本書の目次
- はじめに
- １章：常識をくつがえす「納品のたい受託開発」とは
- ２章：時代が「納品のない受託開発」を求めている
- ３章：顧客から見た「納品のない受託開発」の進め方
- ４章：事例に見る「納品のない受託開発」
- ５章：「納品のない受託開発」を支える技術とマネジメント
- ６章：エンジニアがナレッジワーカーになる日
- ７章：「納品のない受託開発」をオープン化する
- おわりに
著者が目指す理想
ゴーイングコンサーン（事業継続）を前提とする企業を、ソフトウェア・エンジニアリングを担当する「人」によってサポートしていく。それを個人としてではなく、私たちが会社として契約した上でサポートしていくのです
「納品」をなくせばうまくいく 第一章
「私はそもそもソフトウェア開発とは、誰にでもできるものではないと思っています」とも言っています。本書にも記載されますが、「属人性の排除」より「人を大事にする」カルチャーです。
エンジニア出身とししてプログラマーに対する理想が描かれております。
- プログラマを一生の仕事にする、高みを目指し続ける。
- 企画段階から、開発はもちろんのこと、運用までのライフサイクルの全てを受け持つ 。
- 毎月のように新しい機能が登場し、どんどんバージョンアップしていくのが当たり前になる。
- 顧客企業の真のパートナーとして価値を提供し続ける。
- エンジニアとしての努力が、そのまま自社のビジネスの結果の仕組みに結びつく。
私もこんなエンジニアになりたいと思いました。
なぜ、納品のない受託開発か？
一括請負というビジネスモデルそのものに問題がある。一括請負の中心にある「納品」をなくすことで、すべての問題を解決出来ると考えた、とのことです。
本書を読んで解ったこと
「ITエンジニアの時間以外の価値の源泉を知りたい 」という問いに対して
ソフトウェアは完成した時点では価値を生まず、使い続ける中で価値を生みます。
「顧客がイメージしたものを開発して納品する」という関係性の場合
- 付加価値はソフトウェアの完成
- 価値の源泉は時間
「企画から参画し運用後も継続的な機能強化を実現する」という関係性の場合
- 付加価値はソフトウェアを通じて生み出したビジネス価値
- 価値の源泉はエンジニアとしての総合力
「付加価値ベースの働き方へのシフトを妨げる要因を知りたい」という問いに対して
一括請負の場合
- 顧客との関係性：顧客がイメージしたものを開発して納品する
- 完成責任：負う
- 付加価値：ソフトウェアの完成、完成リスク、計画通りに進めるマネジメント力
- 顧客が支払う費用：計画を実行するための費用
- 顧客に提供するもの：完成品
従来の一括請負型は、要件定義で具体化したソフトウェアの完成リスクを負うというビジネスモデルになっています。この構造を変えない限り付加価値ベースにはシフト出来ないのです。
本書の著者である倉貫さんが運営するソニックガーデン（納品のない受託開発）の場合
- 顧客との関係性：企画から参画し運用後も継続的な機能強化を実現する
- 完成責任：負わない（つまり納品しない）
- 付加価値：エンジニアがソフトウェアを通じて生み出すビジネス価値
- 顧客が支払う費用：月額定額
- 顧客に提供するもの：定額内で出来る範囲で何でもするサービス
顧客が「エンジニアがソフトウェアを通じて生み出すビジネス価値」に対して価値を見出し対価を支払っているのです。
本書での気づき
これからは人を大事にしなくてはいけない
誰でも出来るものへの価値は低下していきます。人を大事にするカルチャーを醸成しなくてはいけないと思いました。
ビジネスモデルそのものの問題も考えるべき
この本にも記載があったのですが、方法論・テクノロジー・マネジメント手法ではなくビジネスモデルに問題がある場合もあるということです。
現在のビジネスが上手く行っていないときはビジネスモデルそのものの構造的な問題についても考慮すべきだとということですね。
変革時は新しいビジネスモデルだけ考えれば良いわけではない
ビジネスモデルを転換する際には、ビジネスモデルだけでなく、「導入の方法論、ジョブディスクリプション、カルチャー、育成方法、採用方法」まで思慮を巡らさなくてはいけないですね。
まとめ
本記事では、倉貫 義人さんの『「納品」をなくせばうまくいく』を紹介しました。
重要なポイントは以下の２点です
- エンジニアの付加価値は顧客との関係性次第である。
- 付加価値はビジネスモデルに依存する。
ご参考になりましたら twitter をフォローして SNS でシェアして頂ければ幸いです。