「自ら修羅の道を作り、修羅場を楽しみ、自内外に変化を起こし続ける」(『ソフトウェアファースト』読書感想)

2020/05/13 2020/05/16

「ソフトウェア・ファーストあらゆるビジネスを一変させる最強戦略」を読みました。

以下は、私の感想です。
本書の内容そのものでもありませんし、もちろん著者さんの意図もなにもないです。
ただの私の感想です。

一言感想

自ら修羅の道を作り、修羅場を楽しみ、自内外に変化を起こし続ける

10Xを目指す

途中で出てきた「10x」の考えにもあるように、「1.x倍の目標」は、今のやり方うあ仕組みの延長をいくつか考えて目標に向かう。
でも、「10倍の目標」はやりかたも仕組みも全部、今までの発想では10倍にはならない。
そこで新しいやり方、アイデア、運用、仕組みが生まれたり、外部からもってくる、そのために学び経験し成長する。

本書「ソフトウェアファースト」では、冒頭でも書いてたように、すべては手段であり、ソフトウェアファーストという考え方。
ただし、この考え方でビジネスを実践していくには、常に考え抜き続ける執念が必要。
ただのメソッド、ロジックとして受け取るんではなく、自分のキャリアへの考え方の変化から、組織としての考え方の変化にまでつなげていければ、文字通り「最強戦略」になるんだろうなあ。

でも、自分にできるのか、と問われると、一言感想に書いたように、
自分はこれぐらいやらないと、自分も成長しないし、外の変化も起こせない。
自分自身の世界を変えないと、外の世界を変えることなんかできない。
と最後まで読んでて思いました。
著者さんも最後に、「いつも修羅場があり楽しんできた」と書いておられました。

SaaSへ

音楽業界の話からSaaSへ。
所有から利用に変わった代表的なものが、音楽産業。
レコードからCD、CDからデジタルファイル、サブスクリプションサービスとしての聴き放題。
聴きたそうなジャンルやプレイリストのレコメンド。
まさに所有から利用、資産からサービスへの変遷。

そして、今はライブ体験までもがデジタルサービス化している。
これは今はやむおえず発生しているように見えるけど、確実に浸透するし、無店舗型ライブハウス的プラットフォームとして定着すると私は考えています。
今、これをやるかやらないか。

まさに今、「強いものが生き残るんじゃない、変わるものが生き残る」という現実が、顕著にリアルに次々と目の前にうつしだされていく気がします。

DevOpsへ

開発は運用までが仕事だった。
運用は開発が終わってからが仕事だった。

サービスがスタートしてはじめて、多用的で具体的なニーズが、観察によって浮き彫りになる。
ユーザーのニーズの本質を知るには、聞くよりもモニタリングの方が正確な情報が得られるし、何よりもユーザーが口や文字で表現できない潜在ニーズが得られる。
悪意も意識もなくユーザーは嘘をつく。これ本当ですね。

私は開発SIer→情シス→インストラクターと来たのですが、SI時代に、「発注担当者は嘘をつく」し、誰かからプロジェクトを引き継いただときは「引き継ぎは嘘」で、「ドキュメントに真実はない」と早い段階で気づいたので、環境調査はソースコードレベルで全部調査してました。
このときの経験が役に立って、情シス時代も入社時にドキュメントは索引レベルで使って、基本はソースコードと生データを確認してました。
そしてドキュメントはやっぱり微妙に違う、と思いながら仕事してました。
それを開発ベンダーに指摘したことで、ソースを読んだことが契約違反だとやいや言われたこともありました。

話が少しそれましたが、開発と運用のプロセスが分かれていると、変更コストが増大になりなかなか変更ができない。
結果、ニーズを知ることができても、次のバージョン(位置づけは別製品)の開発に加えることになる。
そしてリリースするころには、そのサービスは競合に先にリリースされた二番煎じとなってしまう。

また、現場の課題解決であれば、その課題を解決するころには、すでに新しい課題が生まれていて、一生追いつくことのないモグラ叩きになる。
追いつくことのできないモグラ叩きになるから、「モグラ叩きはダメ」、「部分最適化はだめ」、「叩かなくてもよくする方法を考えなければならない」となる。
もちろんそれができれば何よりですが、それが完全にできるひとは予知能力か何かを持っている人だと思います。
なので、開発と運用のプロセスを分けずに、運用し観測しながら、開発を繰り返す。

毎日リリースしているサービスも世の中に多々ある。
サービスを提供しながら成長させる。
今のZoomがまさに顕著な例かと思います。
Zoomが指摘された様々な要望を「次期バージョンで改善する」と言って、1年も放置したらどうなるでしょうか。
誰もそんなサービスは使わなくなるのではないでしょうか。

プレスリリーストリガー

Amazonはプレスリリースを先に作ってそこからプロジェクトを開始する。という有名な話があります。
これとあわせて、インセプションデッキも紹介されていました。
インセプションデッキは勉強会とかでたまに聞いたことがあったぐらいで、やったことはありませんでした。

ちょうど、社内で企画したいことがあって、翌週に関係部門と初の打ち合わせがあったので、インセプションデッキ作ってみました。
「我々はなぜここにいるのか」や「エレベーターピッチ」、「パッケージデザイン」がまさに「プレスリリース」で、自分がなぜこれを企画して、何を目的として、どのように自社の強みを活かしたいと考えているのか、が明確に伝えられたと思います。

このやり方いいですね。
これからも使います。

内製や経営層のITリテラシーなどなど

経営層のITリテラシーは高いほうがいいというか、「俺わからんから」とか言われてしまうときついですよね。
ソフトウェアファーストのためのエンジニアファーストも組織として取り組まないとできないです。
雇い入れた「専門家の意思」、社外の「コンサルの意思」ではなくて「組織の意思」が必要なんですよね。

そして、内製開発したほうが、正しく速い開発ができるのはまったくの同意です。

このあたりを読んでて思ったのですが、この本に書かれているような思考を持っていない経営層の方々が、この本を手にすることがあるのかどうか。
なんとかして届いてほしい。

Connecting The Dots

スティーブジョブズさんのConnecting The Dotsの話。

アルファベットを綺麗に書く技術が、アップルでのmacの開発時の美しいフォントを持つことに結びついたらしい。
なので、専門性は大切だけど、他のことはやらない、じゃダメ。

これまでDB、OS、ソフトウェア、言語に拘らず、依頼されればなんでもやってきたつもりです。
専門外の技術を扱う時、隣にいたエンジニアとかは、「それは自分の仕事じゃない」という顔をしていた人もいました。
そうするとその人は次からはそのような仕事にはアサインされずに、得意な技術にアサインされる。
中には、「できません。」という人もいたり、勉強もせずにやろうとして、結果できない人もいた。

割と昔から、「できるできない」ではなく「やるかやらないか」だと思ってたので、基本ご依頼されればやってきた。

その結果、新しく触れる技術を本番環境でリリースして、発生する課題に取り組む、という経験ができた。
これは、機会がなければ絶対にできない経験でした。
断っていたら絶対に得られなかった。

依頼に応え続ける。
これがキャリアを磨き続ける近道と信じています。

最後までお読みいただきましてありがとうございました！

【PR】「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル改訂第2版」という本を書きました。

【PR】「AWS認定資格試験テキスト AWS認定クラウドプラクティショナー改訂第2版」という本を書きました。

【PR】「ポケットスタディ AWS認定デベロッパーアソシエイト」という本を書きました。

【PR】「要点整理から攻略するAWS認定ソリューションアーキテクト-アソシエイト」という本を書きました。

【PR】「AWSではじめるLinux入門ガイド」という本を書きました。