はじめに
記事読んでいただいてありがとうございます。
最初にお伝えしておきます、私は在籍している会社でCTOではないです。
ですので、CTO目線で見た開発とビジネス・経営の境界線を期待されていた方は、申し訳ないのですが、ページをそっ閉じしていただければと思います。
では、何故、この記事を書いているかというと、一介のエンジニアである私も、ビジネス・経営を知ること、積極的に関わることで、より良い開発ができると考えているからです。積極的にビジネス・経営へ関わりたいエンジニアの視点で、ビジネス・経営を知り積極的に関わるために何をすべきか、何故すべきか、まとめます。
良いプロダクトを作るために、ビジネス・経営を知ろう
私はどちらかというと、こちら寄りで、会社の仲間やチームの仲間とより良いプロダクトを作っていきたいと考えています。そのために、経営やビジネスについて知りたい、積極的に関わっていきたいと考えています。
良いプロダクトとは何か
私の他にも、エンジニアとして開発に従事していて、「良いプロダクトを作りたい!」と思う方はいらっしゃるのではないでしょうか。確認したいのですが、ここでいう「良いプロダクト」ってどういうプロダクトであると皆さんは思いますでしょうか。色々な軸がありますよね。良いプロダクトの条件をそれぞれ考えてみてください。
例えば、
- 売上を多く上げることができる
- 利益を多く上げることができる
- 多くのユーザに使ってもらえる
- ユーザに長く愛される
- システムを拡張・変更しやすい
- 技術革新がある
etc
他にも、様々な要素が上がることでしょう。
あなたの携わっているプロダクトは良いプロダクトですか
では、今、直接携わっているプロダクトについて、今上げた項目についてあてはまるか考えてみてください。
- 売上を多く上げることができているか
- 利益を多く上げることができているか
- 多くのユーザに使ってもらえているか
- ユーザに長く愛されているか
- システムを拡張・変更しやすいか
- 技術革新があるか
自分で考えた「良いプロダクト」の条件、全てにあてはまるという方、素晴らしい! 良いプロダクトを作られていますね。その素晴らしいプロダクトを更に良くするために、何が必要か考えてみてください。追加で、これができたら良いなとか、ここを改良したいなというところはないでしょうか。
自分で考えた「良いプロダクト」の条件、全てはあてはまらないという方、これから、良くしていきましょう。その際に、必ずしも、先にあげた「良いプロダクト」の条件を満たさなくても良いかもと思ったりしませんでしょうか。
例えば、
-
売上を多く上げることができているか、利益を多く上げることができているか
⇨ 売上や利益目的のプロダクトではなく、集客やプロモーションが目的であるため、売上や利益はあまり気にしなくて良い -
多くのユーザに使ってもらえているか
⇨ 特定ユーザ層にだけ刺さるプロダクトなので、そこまで多くにユーザに使ってもらわなくても良い -
ユーザに長く愛されているか、システムを拡張・変更しやすいか
⇨ 今、必要としているユーザにプロダクトが届けば良く、ユーザニーズも変化しやすいため、長く愛されなくても良いし、システムを拡張・変更する必要がない -
技術革新があるか
⇨ 既存の技術で十分で、十分にユーザに価値提供できるので、わざわざリスクもある技術革新に挑む必要がない
『良いプロダクトの条件なんて、プロダクトによって変わる、何を当たり前のことを書いているんだ』と思った方、まさしく、その通りだと思います。良いプロダクトの条件はプロダクトによって変わると私は思っています。
良いプロダクトを考えるためのインプット
では、具体的に、プロダクトによって変わる、良いプロダクトの条件を考えるためには、どういったインプットが必要でしょうか。思い浮かべてみてください。
- ユーザにどういった価値を提供すべきかを知る
- ユーザの求めていることを知る
- 市場調査、競合調査(マーケティングチーム)
- ヒアリング(営業チーム)
- ユーザの不満を知る
- クレイムやサポート内容(カスタマーサクセスチーム)
- ユーザの求めていることを知る
- ユーザにどうやって価値を提供すべきかを知る
- 会社の現状を知る
- 会社のリソース状況(経理チームや管理チーム、人事チーム)
- 他のプロダクトの状況(別事業部門)
- 会社が将来的に何をしたいか知る
- 事業戦略、経営戦略(経営戦略チーム)
- ミッション、ビジョン、バリュー(社長室、広報チーム)
- 会社の現状を知る
他にも色々ありますが、上記を知っている、理解しているからこそ、「プロダクトを更に良くするために、何が必要か」を考えられるし、「プロダクトによって変わる、良いプロダクトの条件」について考えることができるわけですよね。改めてみてみると、これらはまさしく、ビジネスや経営を知るということではないでしょうか。ビジネスや経営を知ることが、あなたがやりたい「良いプロダクトを作りたい!」に繋がっていくと思いませんか。
必要なインプットをどう得るか
『いやいや、今までそんなこと意識せずとも、自然にわかってたし。』とお思いの方、素晴らしいと思います。意識せずに知る、理解するあなたのセンスも素晴らしいですし、あなたがそこまで意識せずとも上記のインプットが得られるように動いてくださっている他チームの方も、どちらも素晴らしいです。ですが、あなたが意識的に、より積極的に上記のインプットを得た場合、今より更に「良いプロダクト」を作れるようになるのではないでしょうか。
また、上記に関して、全て、あなただけで行う必要はありません。他チームの方の動きを知り、わからないところ、疑問に感じたところを積極的に質問してみましょう。自分の仕事に興味を持たれたら大抵の方は嬉しいのではないでしょうか。忙しくて塩対応されるときもあるかもしれませんが、相手の都合を考えた上で、何故知りたいと思っているのかをちゃんと説明し、教えてもらいましょう。
情報収集自体も全て一人で行う必要はないと思っています。良いプロダクトを作りたいと思っているのはあなただけでしょうか。同じ開発チームの方とお話しして確認してみましょう。あなたと同じように良いプロダクトを作りたいと考えている人はいるのではないでしょうか。その方々と協力して、お互いにインプットを共有し、更には、チーム内で議論や話し合いをしてみると、より理解が深まると思います。また、チーム内で議論や話し合いをすることで、良いプロダクトの条件の中にも優先的に取り組まなければいけない項目があることに気づくのはないでしょうか。優先度が決まることで、今何をすべきか明確になり、より良いプロダクトにしていくための第一歩となるのではないでしょうか。
身近の人との取り組みの中で、更に勉強したい、スキルを身につけたいと考えたら、本や外部の勉強会に参加してみるのも良いでしょう。あなたが新しく身につけた知識やスキル、経験について、社内で共有することで、チーム全体、会社全体として、より良いプロダクを作ることができるようになるはずです。そうして、あなたが良いプロダクトを作るために、ビジネス・経営を知りたいと考え、行動した結果、会社全体に良い影響が生まれ、結果的に、あなたが一人で漠然と良いプロダクトを作りたいと思っているときより、良いプロダクトを作るための、自分や周りの環境が整っていきます。
自分のやりたいことをするために、ビジネス・経営を理解しよう
良いプロダクトもいいけど、私は私のやりたいことをしたい、そう考える人もいらっしゃることでしょう。当たり前ですが、そう考えることは別に悪いことではないですし、私も気持ちはわかります。ですが、そう考える方にこそ、ビジネス・経営に対する理解を深めていただきたいと思っています。ビジネス・経営に対する理解を深めることで、結果的に、自分のやりたいことができるからです。
あなたがやりたいこと、やった方が良いと思うこと、正しく伝わっていますか
あなたがやりたいこと、やった方が良いと思うことを実現した場合、ビジネス側や会社全体にどういう良い影響を与えらえるのか、整理してみましょう。整理するために、エンジニアが与えられる良い影響について、思いつくものを書き出してみました。
- 利益を増やす
- 売上を増やす
- 新しい売上の創出
- 例) 新しいプロダクトの開発、アップセル・クロスセルに関する機能の追加(レコメンドや、リピーター向け機能)、マネタイズの追加など
- 顧客獲得のサポート
- 例) マーケットツールの導入、営業支援ツールの導入、顧客エンゲージメントの改善など
- 新しい売上の創出
- コストを減らす
- 業務効率改善
- 例) ERP含めたシステム導入による効率化、外注化できるタスクの切り出しなど
- システムコスト削減
- 例) ダウンサイジング、アーキテクチャの見直し(オープン化・クラウド化・標準化・共通化)、開発コストの削減(リファクタリング、内製化)
- リソース調達コストの削減
- 例) 社外の知名度向上など
- 業務効率改善
- 売上を増やす
- 利益を減らさない
- リスクを減らす
- コンプライアンス対応
- 例) インボイス制度への対応システムの導入や、各種ハラスメントの社内通報窓口の設置など
- セキュリティ対応
- 例) セキュリティシステムの構築、第三者認証の取得、セキュリティに対する社内勉強会など
- 災害リスク対応
- 例) 災害からのシステム復旧計画の作成(BCPの一部)、安否確認システムの導入など
- コンプライアンス対応
- 売上を減らさない
- 顧客体験の向上
- UI/UXの改善、顧客エンゲージメントの改善、競合との差別化など
- マーケット施策のサポート
- アップセル・クロスセルに関する機能の追加(レコメンドや、リピーター向け機能)、データ分析ツールの導入など
- 顧客体験の向上
- コストを増やさない
- 業務コストの見直し
- 無駄な業務フローの見直し、外注化しているタスクのコスト見直しなど
- システムコストの見直し
- ランニングコストの見直し(社内ツールの見直し、サーバ費用の見直し)、不良債権のシステムのリプレイス
- 業務コストの見直し
- リスクを減らす
具体例は、他にもいくつか上がるかもしれませんが、上記でも実際に分類した通り、下の5つに集約されるはずです。
- 利益を増やす
- 売上を増やす
- コストを減らす
- 利益を減らさない
- リスクを減らす
- 売上を減らさない
- コストを増やさない
また、上記の5つに対して、私が分類したものでもそうですが、複数の良い影響が与えられるものもあります。あなたがやりたいこと、やった方が良いと思うことは、利益を増やすために行うのか、または、利益を減らさないために行うのかをまずは考えてみましょう。その上で、売上に関することか、コストに関することか、リスクに関することかを踏まえ、提案の際に、具体的に目的を説明できるようにしましょう。特にあなたの提案が技術に関することであれば、ビジネス側や経営層が理解するのが難しいことも多いです。そのため、ビジネス側や経営層が理解しやすい上記の整理の仕方で、あなたの提案は、どういう目的でやりたいのか、やった方が良いと思っているのか、共有してみてください。
マイナス面の影響をちゃんと検討できていますか
また、提案の前に改めて、マイナス面の影響がないか確認して見ましょう。利益を増やすための提案のはずなのに、コストがとても増えてしまったり、リスクがあったり、本来達成したいことの懸念になることがありませんか。あなたが事前に、その点も織り込んで、利益が増えると考えているのか、プラスの効果だけに目がいってしまい、マイナスの部分の検討をきちんとできていないかで、提案を受け取る側の印象は大きく変わります。上記の5つの分類、反対を考え、マイナスの部分があるのか、ないのか提案前に検討することも大事です。
- 利益を増やす ⇆ 利益を増やせない
- 売上を増やす ⇆ 売上が増えない
- コストを減らす ⇆ コストが減らない
- 利益を減らさない ⇆ 利益が減る
- リスクを減らす ⇆ リスクが減らない
- 売上を減らさない ⇆ 売上が減る
- コストを増やさない ⇆ コストが増える
例)
売上が増えるが、その分、コストも増える → 売上の増分とコストの増の割合によっては、ビジネス的には宜しくない
投資判断を理解しよう
あなたのやりたいこと、やった方が良いと思っていることを、ビジネス側、経営側が理解してくれても、すぐリソースの投入とはならない場合はあります。会社全体で見たときに、あなた以外にもやりたいことや、やった方が良いと思っていることがある人もいるはずです。それぞれ、会社にとって、メリットがある、ただ、全てを行うことはリソースの関係で難しいと考えた際に、どういった優先度でリソースを投入しようと、経営層は考えるでしょうか。
会社によっても、どの比較で決めるのかは異なってきます。昔から使われているものだと、投資利益率(ROI)や回収期間(PB)を比較する方法もありますし、最近見かけるものだと、内部利益率(IRR)、正味現在価値(NPV)を比較する方法もあります。ここでは計算方法も一応下記に整理しますが、これらのうち、何を重視するかは前述の通り、会社の財務状況や経営層の考え方によっても異なってきます。重要なこととしては、経営層が、決して恣意的に投資判断を決めているわけではないということです。そのため、あなたのやりたいこと、やった方が良いと思っていることを蔑ろにしているわけではなく、会社全体で考えてみた際に、会社の利益を最大化していくため、已む無く判断したのだと考えてみてください。
投資利益率(ROI)=(年々の税引後増分利益/総投資額)×100
回収期間(PB)=原投資額/年々のキャッシュフロー
正味現在価値(NPV)=キャッシュフローの現在価値合計-原投資額
ただし、n年後のキャッシュフローの現在価値(PV)=n年後のキャッシュフロー/(1+割引率)のn乗
内部利益率(IRR)は、上記のNPVが0となる割引率です
あなたがビジネス側や経営層に理解を示した上で、信頼関係を結べていたり、あなたの熱意が高い場合、直接、投資判断に至らなかった理由について、教えてくれることもあるかしれません。ただし、逆の立場になって考えてみてください。全く、自分の立場に理解を示さない人に対して、親切に説明しようという気になるでしょうか。そのため、少なくとも、ビジネス側や経営層の立場に立って、理解を示すことは大事ではないでしょうか。
目的から外れていないかを確認しよう
様々な指標を計算しても、十分投資に値するはずである、なのに、あなたのやりたいこと、やった方が良いと思っていることを認めてくれない場合には、あなたのやりたいこと、やった方が良いと思っていることが、会社の目的と外れていないかを確認しましょう。
会社では、ミッション、ビジョン、バリューを掲げていたりしませんか。あなたのやりたいこと、やった方が良いと思っていることはそこから外れてしまっていないでしょうか。残念ながら、大きく逸脱している場合、会社としては、あなたのやりたいこと、やった方が良いと思っていることを認めてくれない可能性が高いです。
あなたに、あなたのやりたいこと、やった方が良いと思っていることがあるのと同じように、会社も目的や実現したいことがあって成り立っています。会社に在籍するあなたも含めた社員が何を目的に、普段頑張っているのか、もう一度確認してみましょう。もし、決定的にそこが合わず、あなたは、自分のやりたいことがどうしてもやりたい場合、周りを変える努力をするか、他の環境へあなたが移るかを考えた方が良いかもしれません。
また、あなた自身がやりたい、やった方が良いとことに対して、いつしか、手段だったものが目的になっていたりすることはないでしょうか。私の場合だと、特定の技術を使うことが目的になってしまい、本来の目的から離れたこじつけた提案をしてしまうことが過去にはありました。大事なことですが、技術は目的を達成するための手段であって、技術自体を使うことが目的にならないようにしましょう。もちろん、初めから、新しい技術を使うことで、社外にアピールするという目的であれば、問題ないです。あくまでも、本来の目的から外れていないかを確認するようにしましょう。
最後に
いかがでしたでしょうか。
当初、記事を書く際は、ビジネスや経営に詳しいエンジニアが世の中で求められているという話を書こうかと思っていました。それ自体は、否定しません。時代の変遷とともに、エンジニアに求められる役割は増えてきました。同様に、ビジネス側にも、基本的なIT知識が必要とされています。そう考えると、いずれ、エンジニアとビジネス側の境界線は無くなるのではないかと思うこともあります。
ただし、それも可能性の一つであって、将来的な方向性はわからないですし、ニーズだけを意識して、自分のキャリアを考えるのは、少し寂しいと個人的には感じています。もちろん、ニーズを全く無視してキャリアを考えることが難しいのも事実ですので否定するつもりはありません。この記事では、それ以外の意義についても改めて考えてみたくなったのです、何故、自分は、ビジネス・経営について興味があるのか。
また、ビジネス・経営に限らず、他チームの立場に立って考えられるようにすることが、結果として、自分がやりたいことができることに繋がるのではないかなと個人的には考えています。そうすることで、自分にはない知識・スキルを互いに有効活用できるようになると思います。会社にも、チームにも色々な考え方の方がいて、それぞれ、見ている視点が異なる。だからこそ、協力しあって、自分一人では作ることができない良いプロダクトを作れるのではないでしょうか。