この本を手に取ったあなたは、きっと自社の現状に危機感を抱き、自分にできることを探している、つまり「ボーっと生きていらっしゃらない方」だと思います。本書では、多くの企業が関心を持ち始めた「ＩＴを駆使したイノベーション」や 「デジタル・トランスフォーメーション」といった変化の種を、単なる流行りや徒労で終わらせないための取り組みを記します。筆者が経験、見聞きしたことを基に、テクノロジー、組織改革、必要な人材、キャリア形成の面から具体的に紹介しています。
「ソフトウェアファースト」及川卓也 著
目次
ソフトウェア・ファーストとは
理化学機器メーカーで機械設計中心に製品開発に携わってきた私が、話題の「ソフトウェア・ファースト」をノンプログラマー目線で読んだ感想をまとめました。
この本は、ソフトウェアエンジニアやマネージャー、経営者クラスまでおすすめできる内容です。ソフトウェアファーストとは、
ソフトウェアの「可能性」と「限界」を知ったうえで、ソフトウェア、ITの力を主軸にして、これからの時代を生き抜くための、事業や組織を実現する思想のこと。
本書では、このソフトウェアファーストについて、その必要性や実現に向けた方法論について、わかりやすく解説されています。
著者の及川氏は、DEC、マイクロソフト、Google、と言った様々なIT企業で経験を積まれた方で現在は、テクノロジーにより企業や社会の変革を支援するTably株式会社を設立、代表取締役として活躍されています。
本のタイトルからは、とにかくソフトウェア万能！イェイ！みたいな印象を受ける方もいるかもしれませんが、そういう内容ではありません。ソフトウェアは強力なツールですが、すべてがソフトウェアで解決できる訳ではないし、そうすべきでもないと書いてあります。
「ソフトウェア・ファースト」とは、会社のビジョンやミッションを達成するための一“手段”であり、「ソフトウェア・ファースト」であることが組織の“目的”ではないということですね。
そのため、本書では「ソフトウェア・ファースト」を補完する概念として、ハードウェアとの関係性や、組織のミッション策定やエンジニアの採用方針、エンジニア（マネージャーも）のキャリア論までもカバーされています。
ソフトウェアのエンジニアはもちろん、私含め、ノンプログラマーな人や、現在あまりITやソフトウェアが活用されていない業種の人にとっても発見があると思います。いや、むしろ周囲との差別化を図るならば、そのようなソフトウェア未開拓の分野や職種の方こそ手に取るべき本かもしれません。以下に感想を述べます。
Devops / 開発と運用の接続
ソフトウェアの最大の特徴。それは後からでも、アップデートが容易なことだ。ハードウェアを伴う、機械や電気部品ではいったん出荷した製品の改修にはかなりのコストを要する。しかしソフトウェアならメール送付で事が済んでしまう。これは不具合時の対応としても優れた特徴だが、何よりも重要なのは販売した後での機能の拡張・追加が簡単なことであろう。(もちろんそういった拡張性を考慮した思想でソフトウェアが開発されていることが前提だが。)
しかもパッケージ販売していた従来のソフトウェアと異なり、現在主流になっているSaaS(wiki)の形態でユーザーが使っていれば、お客様に更新作業を強いることなく更新できる。メーカーである自分たちで管理するサーバー側のソフトウェアを更新すれば良いだけなのだ。
こうなってくると、開発フェーズと運用フェーズの垣根は低くなり、両者は一体化していく。これがDevopsという思想であり、開発してリリースしたものを運用しながら、逐次、改善、修正、新機能の開発と追加を行うことができるようになる。より早く市場に投入し、利益を得ながら市場からのフィードバックを得て、製品の改良を行うことができるこの手法はとても魅力的だ。
私が担当する装置においても、ソフトウェアの不具合や新機能の追加のため、ソフトウェアの更新ディスクを配布することはある。しかしちゃんと適用してくれるお客様は非常に少ないのが実情だ。ときにサービス作業などで、装置ユーザーの元を訪問すると、ほったらかしにされた更新ディスクをよく目にする。そういう時はお客様に機能を紹介して自分で更新するわけだが、すべてのお客様を訪問してカバーしているわけではない。新しいソフトウェアをもれなく簡単に提供できる点。これはSaaSとしてソフトウェアを提供する大きなメリットと感じた。
機能の拡張を容易に行うことができるソフトウェアの特徴を考えると、ハードウェア設計の視点も当然変わってくる。すなわちハードウェアはなるべく素直で信頼性の高い、素直な系とし、応用的、拡張的な機能はソフトウェアにより達成する。素性のよいメカや電気系をハードウェアとして用意し、その特性をソフトウェアを使用して最大限に活かす思想だ。
従来は処理速度の問題により、ハードウェアによる制御に頼らざるを得なかった面もあったが、PCの処理速度が向上した現在、どのように装置の性能を引き出すか、ソフトウェアに負う部分はますます増えていくだろう。
自分たちの仕事の成れの果てを見るべし
またSaaS形態で提供しているソフトウェアなら、顧客のアクセス状況や機能の利用状況などサービスの利用状態に関するデータを得ることができる。これも優れた特徴だ。
私見だが、技術者は、自分達が開発されたものが現場においてどのように使用されているのかを常に意識し知ろうとしなければならないと考えている。そこを怠れば独りよがりの製品開発となってしまう。社内でどう考えて作ろうと、お客様に使われない機能や、お客様が使いこなせない機能などは無駄なのである。そういった無駄な開発を防ぐために、これらのデータは助けとなるだろう。
もちろんサーバー上で収集できるデータだけで十分ではないはずだ。エンドユーザーと直に対話して得られる情報の重要性は今も変わらない。しかし、技術の進歩により、情報収集の選択肢が増えることは良いことだ。
技術者はエンドユーザーの現場を時には訪れ、自分の仕事の成れの果てを見なければならない。本題とは外れるが、私自身の個人的な経験を紹介しよう。
我が家で数年間使用してきた洗濯機が水漏れするようになった。メーカーのサービスマンにみてもらうと、排水管が破れていることが分かった。部品を交換しすぐに修理は終わったが、問題はなぜ配水管が壊れたか、である。そのサービスマン曰く、洗濯機の設置の際、配管を設計上予期しない箇所に結束バンドで固定したことが原因と言う。
洗濯機を量販店で買うときに、料金を払えば設置まで行ってくれるサービスがある。私も量販店の作業員に設置をお願いした。しかしそういった作業員は各社の洗濯機について十分に教育を受けているわけではない。彼らは設置の際に良かれと思って、配管をタイラップで固定するのだが、その結果、固定された箇所に繰り返し振動が加えられて 何年か経過した後に 配管が破損するのだ。しかし、設置した作業員は自分の作業が原因となり、数年後に故障を生んでいるとは夢にも思わないだろう。
修理に来ていたサービスマンはそのときこう言っていた。
「自分たちの仕事の成れの果てを見ないとね」
この言葉は、設計者、開発者としての自分への戒めとして以来心にとどめている。
自分のキャリア：プロダクトマネージャーの発見
最後にこの本を読んで個人的に最も重要な発見、それは「プロダクトマネジャー」と言う職種のこと。恥ずかしながら今まで知らなかったのだ。プロダクトマネジャーとは何者か。この本の中では、エンジニア、エンジニアリングマネジャーと並び、以下のように説明されている。
プロダクトマネジャーは「ミニCEO」と呼ばれることがあると記しました。この呼称が示すように、プロダクトマネジャーとはプロダクトの仕様から機能開発、運用に至るまで全体の価値を高めることを職務とする「製品責任者」です。プロダクト開発はエンジニアリング組織だけでなく法務、マーケティング、広報、営業、サポートなど多岐にわたる組織が連携しながら進んでいきます。これらを一つのプロダクトチームと見立てて、組織横断的にチーム運営していくことが求められます。
「ソフトウェアファースト」及川卓也 著
これを読んだ時、自分が今の職場でやろうとしていたこと、あるいは一部やってきたことは、まさしくプロダクトマネジャーの仕事だったとはたと気づいた。
言語や知識、概念は、我々が日々生きる世界で体験する経験を解釈する際の道具であり、その豊富さや扱い方の巧みさによって、世界を見るときの立体感や分解能が変わる。私に欠けていた「プロダクトマネジャー」という職種の概念を新たに知ったことによって、私の職場との向き合い方は大きく変わる予感がある。
製品の開発を任されるようになってからは、特に誰から言われたわけでもなく、その製品のビジネス上の価値に注目して行なってきた。だから技術的性能だけでなく、製造原価や工数、その製品によりどのように利益を生むことができるか、にむしろ注目していた。例え技術的にはチープであっても、それがユーザーにとって役立つものであれば良いと考えてきた。開発サイドだけでなく、営業展開や、製造現場にもできる限り配慮は行なって開発を進めてきたつもりだ。
時には納入した客先でお客様から厳しい意見をいただくときもあった。そんな時は、自分が組織のどんな立場であるかは関係なく、社名を背負った人間として、組織の代表者として真摯に対応してきた自負がある。
そんなあれや、これやを行う役割は自分の中でははっきりと明文化されていなかった。それがプロダクトマネジャーと言う言葉で焦点を結び、視界がクリアになったのだ。
今まで、仕事をしていく上で、組織に不満を感じていたことがある。それは自分たちの活動の、根本としての拠り所となる製品や企業のビジョン、ミッションが曖昧で十分に示されていないことである。自分たちはこの事業を通じて、世の中にどのような価値を提供していくのか、なぜ我々は企業として活動しているのか、という大元が数年前から全社的に見失なわれているように感じながら働いていた。
そこを不満に感じる一方で、そういった「ビジョン」や「ミッション」は経営陣が示すべきものであるとも思っていた。しかし「ソフトウェアファースト」にはこう記されていた。
「ただ、ソフトウェア・ファーストを実践していく過程でミッションを再確認し、抽象度が高すぎると気付いたとしても、その時点で会社が掲げる企業理念を変更するのはそう簡単にはできません。それができる経営トップが変革に意欲を示していたとしても、コングロマリット化した全事業に影響を与えるような理念を掲げ直すのは難しいでしょう。このような場合は、担当者が直接関係する事業やプロダクトだけでもミッションを再定義するのをお薦めします。」
「ソフトウェアファースト」及川卓也 著
全社的なものはさておき、なるほど、プロダクトマネージャーなら、少なくとも自分の担当製品のそれは決めたっていいんだ。というか、それがプロダクトマネジャーの最重要な仕事なんだ。そして、そこを洞察できるのは、よく考えてみたら自分しかいないかもしれない。さらに言えば、自分はミッションを、ビジョンを自分で決めることを本心では望んでいたのではないかな。
またこうも思った。結局自分はままならない現状を他人のせいにして、傍観していただけではないのか、と。
いっとき、この会社で働くことについて、疑問を感じた時期もあった。しかし今は底を脱した感がある。せっかくこのようなポジションにいるのだから、どこまで頑張れるか分からないが、この役割を真剣にやってみよう、とそう思えた。
