及川 卓也さんのソフトウェア・ファーストを読んだのでまとめと感想。
- ２章 IT・ネットの”20年戦争”に負けた日本の課題と光明
- ３章ソフトウェア・ファーストの実践に必要な変革
- 4章これからの「強い開発組織」を考える
- 5章ソフトウェア・ファーストなキャリアを築くには
- おわりに
２章 IT・ネットの”20年戦争”に負けた日本の課題と光明
おもちゃが産業全体に変化をもたらす
おもちゃと思われていたものが世界を変える。これが一つの法則です。そして、このおもちゃが産業全体に変化をもたらす時は、先行してコンシューマー側で普及していたことも忘れてはいけません。
マニアのおもちゃと思われていたパーソナルコンピューターやインターネット、クラウドなど、初めはおもちゃのような存在だったものが世界を変えた。
この部分を読んだ時にテクノロジーの進化のパターンについて書かれた『未来に先回りする思考法』を思い出しました。
タイムバンクなどのサービスを運営しているメタップスの社長の佐藤航陽の書籍です。『未来に先回りする思考法 無料試し読み版』もあるので興味がありましたらどうぞ。
(面白かった記憶はあるのですが、どんな内容だったのかは忘れました・・・)
正常性バイアス
客観的に見ると危機的な状況に陥っているにもかかわらず、目の前の状況を過小評価して「自分だけは大丈夫」と楽観視したり、都合の悪い情報を意図的に無視するなどしてしまう特性のことで、危機から脱する機会を失う原因にもなり得ます。
日本企業の多くは、この正常性バイアスによって過去の成功体験にとらわれ、モノづくりこそが日本の「正業」であり、ITは「虚業」という誤った認識を持ってしまったのではないでしょうか。
現在でもまだハード重視、ソフト軽視の考えが根強く残っているのかもしれない。
もちろん、ソフト重視、ハード軽視が正しい訳ではない。
本書では『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』の言葉が引用されています。
1.ハードウェアはソフトウェアのためにある
2.ソフトウェアはユーザーエクスペリエンスのためにある
3.ユーザーエクスペリエンスは人々の感情を満足させるためにある
ソフトウェア・ファーストというタイトルの本ですが、
正確にはソフトウェアの可能性を理解した上で、ユーザーの感情に訴えるプロダクト開発を目指す姿勢がソフトウェア・ファーストなのです。
あくまでユーザーを満足させることがゴールであることを忘れないようにしないといけないと改めて思いました。
『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』も今度読んでみたい。
現実に即していない情報セキュリティ
本当にセキュリティインシデントを避けるためというよりも、インシデントが発生した時に責任問題に発展しないための言い訳を用意しているように感じてしまいます。
取り組んでいる姿勢を見せることが重要なのではなく、本当に必要なセキュリティ対策を採ること、それが大事です。
言い訳の材料集め、チェックリストを埋めるだけのセキュリティ対策では根本解決になりません。
また、とにかく制限をすることも一時的には攻撃されにくくなるかもしれませんが、業務効率が下がり、抜け穴を使う社員が現れると悪化することもあります。
「Data is Oil」（データは石油）
近年「Data is Oil」（データは石油）という考え方がさまざまな産業に普及していますが、一つ目の懸念はデータへの期待が先行し過ぎている点です。
データの収集や前処理、蓄積にも莫大なコストがかかることを考えると、収集するデータの種類や用途を考えた上でデータを集める必要があります。そこまでやらなければ、原油は石油にはなりません。
データを活用していこうという心意気は良いのですが、周りがやっているから表面だけ真似をしようとすると痛い目をみるということのような気がします。
小さく始めて少しずつ学んでいくフェーズが必要そうですね。
３章ソフトウェア・ファーストの実践に必要な変革
上流だけでなく実装が重要
日本の大企業の経営陣とお話しする機会が増えてから、筆者はITシステムやソフトウェア開発の仕組みをお伝えする機会が増えました。その際「上流だけでなく実装が重要だ」とお伝えするのですが、徒労感に襲われることが多くあります。
少しでもソフトウェア開発の現場に接していたら簡単に伝わるであろうことが伝わらないのです。
私にとっても「上流だけでなく実装が重要だ」というのは当たり前だと感じられるのですが、今だに根強く発注側は上流だけ見れば良いという考えが強いようです。
今から5,6年前の2014年当たりからソフトウェアの内製化が重要、これから取り組んでいくと一部の会社が言い始めていた覚えがあります。
ここでしっかりと取り組み始めていた会社とそうでない会社で考え方の差、もしかしたら収益の差が出てきているのかもしれないですね。
自社製品を自ら使う
自社製品を自ら使う。これを経営陣が示し、自分たちが使えないものは世の中に出さないという強い意志を持つことが大事です。
自社製品なのにほとんど使ったことがない、使い方もわからないという状況はかなり深刻なように思います。これも上流だけみているために成果物への関心があまりない、持ちづらいというのが関係しているように思います。
上流で仕様だけ決め、その仕様があるかどうかのマルバツのみ確認するという現状があるのかもしれません。
中間管理職 経営と現場の板挟み
いわゆる中間管理職として、経営と現場の板挟みになりながら調整を繰り返しているだけではダメです。
会社の方針に沿った上で、現場の自由な発想を大事にして、より良いチームワークを生み出す。この役割を板挟みと感じるか、会社と個人を結ぶ重要なコネクターと感じるかは大きな違いです。
上と下の顔色を伺う形になったらダメ。
現場社員の全員が会社の方針を正しく理解できている訳ではないのでそこを理解してもらえるように、現場にわかる形で伝える、経営陣に現場の状況をわかる形で伝えるといった翻訳作業をしながら全体の生産性を上げる必要があると自分なりに理解した。
どこでも働ける人材
「どこでも働ける」人材が、能動的に所属する組織を選んで働いているという状況は、その組織を強くします。と同時に、その人材は常に「どこでも働き続けられる」だけの努力を怠りません。個人の強さが組織の強さとなります。一方で、組織は強くあり続け、強い個人を惹き付ける努力を怠らないようにしないと、社員は「どこでも働ける」のですぐに流出してしまいます。この個人と会社との緊張関係がお互いを強くするのです。
今後、人材の流動性が上がっていくと会社の魅力、部署の魅力が低いとどんどん他社や社内の他部署に流出していくと思う。
逆に魅力がある、魅力をちゃんと伝えることができている会社や部署は成長のスピードが高まっていく時代になるのかもしれない。
魅力があるのに自分たちが理解していない、伝えられていない部分も多くあると思うのでそこの言語化、共有ができるように他社や他部署のことを知る必要があると思いました。
創造性は制約を好む
制約条件を強くするという考え方は、先述したマリッサ・メイヤー氏が「創造性は制約を好む」（Creativity loves constraints）という言葉で頻繁に発信していました。
逆に、あえて制約条件を外して考えてみることも効果があります。予算に制限がないとしたら？エンジニアを多数採用できるとしたら？
創造性は制約がないほうが絶対いいじゃん！と思っていたので驚きました。
ここでは例としてクロームブックの構想時に「電源が完全にオフの状態から電源を入れて10秒でGmailにアクセスできる」というかなり厳しい制約をあえて自分たちに課して開発を行なったそうです。
地道な努力でなんとかなるレベルではない目標設定をすることで今までのやり方ではないやり方にせざるを得ない状態を作り、新しい発想を促す。
自由にすれば創造性は勝手に高まる、という訳ではなくて何かしら自由な発想を促すための仕組みというものが必要なのですね。
使われないプロダクトはゴミである
ソフトウェア・ファーストの実践では「使われないプロダクトはゴミである」という意識を持つ必要があります。
これはつらい。見ただけでお腹が痛くなりそうなワード。
実際そうなのかもしれないけどなかなか現実を直視できないものな気がします。
使われないプロダクトや機能には価値がないと肝に銘じ、プロダクトが開発者の自己満足の塊にならないように注意しなければなりません。
現実を歪めて理解して、これはこれで良かったんだ、みたいな納得をせずに次に活かさないとだめだよね、ということだと自分なりに理解した。
4S Speed, Stability, Security, Simplicity
開発のミッションとなるプロダクト原則は4Sと呼ばれ、当時から今に到るまで変わっていません。スピード(Speed)、安定性(Stability)、セキュリティ(Security)、単純さ(Simplicity)の4つのSから始める単語で示されるもので、今でもChromeのオープンソースプロジェクトであるChromium(クロミウム)のサイトに掲載されています。
ここでは会社やプロダクトのミッションステートメントの大切さを述べている部分の話。
チームメンバーを採用する時、プロダクトの方向性を確認するときにミッションステートメントへ立ち返り、進むべき道を決める。
自分の会社やプロダクトのミッションステートメントを覚えている人がどれだけいるのだろうか。
4章これからの「強い開発組織」を考える
コーディングしなくなってからが一人前
実装軽視が強い日本企業では、「コーディングしなくなってからが一人前」という考え方が根強く残っています。若手時代の数年間、実装経験を積んだ後は、設計やプロジェクト管理に移行するのが一般的なところも多いようです。しかし、技術は常に進化し続けており、１年前の「最新技術」もすぐに陳腐化してしまいます。そんな中で、10数年前に経験した実装の知識のまま、新しい手法を勉強もせずに過ごしていたら、現代的なエンジニアリング組織をマネジメントすることはできません。
『エンジニアのためのマネジメントキャリアパス』(オライリージャパン)という本は、米国に置けるソフトウェアエンジニアがマネジメントに進む際のガイドブックのような存在です。
この本でも、常にハンズオンのスキルを磨き続けること、すなわち実装フェーズの技術を学び続けることを推奨しています。それくらいコーディングへの理解が重要なのです。
今のソフトウェアの進化のスピードが早すぎるのがこの問題を引き起こしているのかもしれないと思った。
昔はもしかしたら過去に習得した技術を10年以上使い続けることができたが、今では数年で陳腐化してしまうのでその知識が害になる(その知識が今でもベストな方法だと勘違いしてしまっていると害になる)のかもしれない。
数年でも実装経験があるのとないのでは大きな違いがあるが、自分が当時身につけた技術手法は陳腐化しているかもしれないと理解した上で経験を活かす必要があると思います。
『エンジニアのためのマネジメントキャリアパス』も読んでみたい。
メンバーのことをあまり知らないマネジャー
蛇足になりますが、マネジャー陣が順位付けのためのデータを持ち合わせていない、つまり、メンバーのことをあまり知らないということが発覚する場合があります。このような組織は評価制度について議論する前に、プロダクトの開発体制がそもそもおかしい可能性があります。メンバーの業務や実績を把握していないということです。まずはその改善から取り組みましょう。
ここではマネジャーが悪い、というのではなく開発体制がおかしいという主張です。上手くマネジメントできていない時にマネジャー個人が悪い、能力不足という場合もありますが、そうではなく体制として上手く回らないものとなっていることもあると思うのでそこを考える必要がありそうです。
リファラル採用は自社の魅力を測るリトマス試験紙
よく「リファラル採用を積極的に進めたいが、社員が紹介してくれない」という悩みを聞きますが、そういう時は理由を詳しくヒアリングしてみましょう。知人を誘えない理由を深堀りして聞いていくと、「給与が安い」「開発環境が今ひとつ」などの回答が出てきます。これは、実はその人自身も今の職場に満足していない可能性があることを示唆しています。リファラル採用は自社の魅力を測るリトマス試験紙でもあるのです。
確かに現状満足できていない職場に友人を紹介したいとはあまり思いません、たとえ紹介料が高くても。
魅力のある職場は良い人が入りやすくなり、さらにより良くなり、魅力の低い職場は悪化するというスパイラルが働きそうです。
自分の職場がどうなのかマネジャーにはわからない場合もあると思うのでリトマス試験紙としてリファラル採用をやってみるのも良いかもしれません。
厳格な勤怠管理
無意味なほどに厳格な勤怠管理など、定量的なデータに依存する人事評価は多くの場合、マネジャーが楽をするためです。楽をするというと言い過ぎかもしれませんが、定性的なデータが多くなる、社員の成果そのものを見なくても評価ができるようにしているというようなことことはないでしょうか。
多くのマネジャーは常に忙しいので自分が楽になり、かつ定量的に判断できるというのはとても魅力的に見えるかもしれません。
低い評価を付けるための材料として定量的なデータを使うようにマネジャーがなるとそれに嫌気がした優秀な部下はいなくなり、その管理方法を逆手にとって定量化されたデータでは悪くならないようにだけする部下が現れたりと良くない部分が少しずつ表面化しそうな気がします。
5章ソフトウェア・ファーストなキャリアを築くには
作り手の気持ちを理解する
短期間プログラミングを学んだだけで、ソフトウェア開発を語れるほど、この世界は甘いものではありません。たまに、昔に少しソフトウェア開発に携わったことがあるだけで、経験者であるように振る舞ってしまう人がいますが、そのような人は間違いなく嫌われます。
作り手の気持ちを理解するためにプログラミングを学ぶことは良いことです。
しかし、少し学んだだけでわかった気になるのはもっと嫌われるかもしれません。
プログラミング言語の勉強は、あくまでプログラミングの奥深さを知るためにやってみる。このくらいの感覚で始めてみましょう。
どこまで勉強しても実際に開発している人には敵いませんし、知識としてあるのと実際に開発するのはまた別だったりします。
どこまでやれば十分という指標もないと思いますし、相手と適切にコミュニケーションが取れるようになるという目的に応じて判断する必要があると思いました。
おわりに
デジタル・トランスフォーメーションを解説した書籍はすでに多く存在します。その中に筆者も参考にさせていただくような良書も多くあるのですが、どうにも綺麗な話に終始しているようにも感じます。
類書にない形で実践的にしようと思うあまり、つい刺激的な表現を用いたり、現状維持に対してチャレンジするような内容になった箇所もあったかと思います。それも、当たり障りのない内容や表現で、皆様の日常の読書体験で終わるのではなく、今日からの行動変容につながるきっかけになればと思ってのことでした。もし、本書の内容で傷ついたり、不快に思われるような方がいらっしゃいましたら、すべての責任は筆者にあります。最後になりますが、心よりお詫び申しあげます。
私も読んでいて心に刺さるような部分が多くあり何度も立ち止まって考えさせられたのですが、及川さんのこういった気持ちがあってのことだったようです。
DXという言葉を使って心地の良い事ばかり言う人たちもいますが、及川さんは現状に危機感を感じているからこそこのような形での表現になったのだと思います。
「Nothing Ventured, Nothing Gained」(挑まなければ、得られない)
本質を追求しながら常に挑戦し続けることを忘れないようにしていただければと思います。
Twitter アカウント
