ここのところ政治的なこととか、社会に関する勝手な思いに偏っていた気がするので、今回はソフトウェア屋さんとして今まで働いてきた中で感じていることを書きます。

その一つが会社で開発してきたソフトウェアを会社の資産として直接的、間接的にビジネスに活かすための考えです。

少し前に、「アーキテクチャ」について書きましたが、その時にもソフトウェアの資産化に触れました。

今回は技術的な視点というよりも、組織的な価値観やソフトウェアの本質を理解することの重要性という観点から書いてみたいと思います。

ソフトウェアは今やかなりの製品、サービスで「なくてはならない存在」になってますが、日本の製造業の中ではつい最近まではあまり重要視されていないものでした。

もしかしたら今でも深層部分ではまだ大事にされてないかもしれません。

日本の製造業はおそらく高度経済成長の時代に安いものを高品質に量産するための仕組みが発達し、それに最適な手段やルールが決められたんだと思います。

電気回路やメカを作るための手段についてはいろいろな工夫がされてきました。

例えば試作を繰り返してより高品質なものを作れるように、開発フェーズを定義し、それぞれのフェーズでやるべきことややってはいけないことなどをプロセスと共に決めていたりします。

ハードウェアはものを作るために結構お金が掛かります。メカ的なものを作るためにも型を作り、工場に製造ラインを作り、人を囲みこんで準備をしなくてはいけません。

また一度準備したら、そう簡単に変更することも難しいですし、またお金が掛かります。

それだけになるべく（多分絶対に）間違わないように作り上げなくてはトータルの製造コストが抑えられず、安くて良いものを作って儲けることができないのです。

エンジニアを育成するという観点でもハードウェアに関わる仕事ではちゃんとしていたと思います。

若いエンジニアは設計図を作ると、必ず出図する前にかなり時間をかけて先輩方にレビューをしてもらっていました。そういう場でエンジニアとしての技術やノウハウを教えてもらって組織に人材という資産や、設計図やプロセスとしての資産が蓄積されていたと思われます。

一方でソフトウェアに関してですが、なかなかそのような環境にはありませんでした。

私が若かった頃のことですが、まだソフトウェアエンジニアというジャンルの職種はありませんでした。まあ、ソフトウェアの仕事と言っても機器に組込まれた小さなコンピュータであるマイコンでボタン操作を検出したり、何かを動かすために制御したりするようなものが主な仕事でしたから、それらの電気回路を作る人たちが傍らで行うような扱いでした。

そのためある意味「動けばOK」的なソフトウェアの作り方になっていました。

その後日本でも情報工学という学部も大学にできたりして、ソフトウェアを専門に勉強して、それをメインの仕事にする人たちも増えました。ただ、日本の大手企業のメーカーはキヤノンのようなものを作る会社が多かったせいか、開発のプロセスやルールをソフトウェア用になかなかリニューアルできなかったと思います。

日本のソフトウェアの老舗はNECとか富士通とかがあるのでしょうけど、それらの企業でもおそらくソフトウェア開発に最適な環境や手法、仕組みだったのかは疑問です。

その１つの大きな理由は、世の中の開発企業が「ソフトウェアはお金がけずにいつでもどうにでもなる」と思っていた事があると思ってます。

ちょっと言い過ぎかもしれませんが、ハードウェア開発と違って、部品を調達したり在庫を持ったりする必要がほとんどなく、ソフトウェア開発は担当エンジニアが頑張ればなんとかなると思われていました。

ソフトウェア開発に必要なものは、「開発する人の工数のみ」という感じで考えていたのではないでしょうか。

そしてその開発者の工数は人件費として計上されている場合が多く、特に大きな会社では製品のコストとしてその人件費をカウントぜずに、間接費的な扱いにしている場合もあったと思います。

そうなると、ソフトウェア開発者がどんなに徹夜して働こうが、ソフトウェア開発のコストとしては計上されず、見えにくいものになっていました。

世の中的には「ITバブル」の頃のSEはブラックな職種で、過労死するぞ、という雰囲気の時です。

最近ではそんなことはほとんどなく、きちんと開発工数をソフトウェア開発のコストとして計上されているはずですが。

そしてそれに輪をかけて、「開発者ががむしゃらに頑張ればいくらでも工期短縮できる」とか「外注にできるだけ安く出せばコストが下がる」と考える仕事のやり方になっていました。

そうすると、あるソフトウェアの製品を考えたとき、その製品が予定の日程を守って期待を満た機能、性能を一定数満たしていればOKということだけを考えて目先の開発をひたすらこなすような開発になっていきます。

でもソフトウェアとは実は目に見えない部分の作りが結構物を言うのです。

以前にも書きましたが、戦略的に設計されたソフトウェアはその後の製品・サービスの改変や修復、機能追加などの際に無駄になる部分を減らすことができます。

それはその会社の資産として使えるのです。また、そのようなソフトウェアは後輩エンジニアが参照することで若いエンジニアの勉強にもなるでしょう。

ソフトウェア分野はまだまだ進化し続けているので、そのまま過去のものが役に立たないかもしれませんが、きちんとした仕事で作られたものは確実に参考になるものです。

開発プロセスやルールなども、ちゃんと失敗を重ねながらも試行錯誤して改善・最適化の道を辿っていれば、きっとその後の開発で役に立ちます。

そうやって企業や組織のソフトウェア開発に関する能力が向上していくのだと考えられます。

ソフトウェアを開発するために適した手法や判断基準は、明らかにハードウェアを開発する場合とは異なると思います。

しかし日本の企業はハード開発の価値観を現場でそれぞれが日程、コストを考慮した範囲で当てはめているだけでした。

ソフトウェアのコストを抑えるための手段が、開発する人の工数を抑えること、人の単価を抑えること、に重きを置くしかなかった価値観が、今のソフトウェアに弱い日本を造り上げてしまった気がしてます。

その間に、アメリカを中心とした世界のソフトウェア企業はソフトウェアの本質をよく理解し、コスト構造や製品・サービスのビジネスモデルまでもを再構築していました。

パソコンやモバイル機器が普及するにつれてソフトウェアの活躍する場が拡大するのに合わせて、開発手法やエンジニアの生産性向上に向けた仕組みを次々と編み出していきます。

そしてそれを現場で製品やサービスに果敢に取り入れていく企業が生き残り、またさらに拡大していく。

そんな価値観を業界全体として育ててきたのではないかと思います。

日本の会社では、新しい手法や技術は製品にはできれば取り入れたくないと考えてきました。

それは、新しいものはこなれていないため、何か問題が起きる可能性が高いと言う考えが根底にあります。

「新しい技術＝リスクが高い」となるのです。

確かに新しいものは心配な点は多いです。でもそれに早くから取組み、しかもプロダクトで実際に使うことでしか蓄積できないものがあることも事実です。

そう言うことが大きな企業を中心にやりにくい体質になっていたのも、ソフトウェアをソフトウェアの本質を理解せずにハードウェアに準えてプロダクトを作っていたからだと私は考えています。

これからはベンチャー企業のような小回りが効き守りより攻めが重要な企業が活発になってくることで変わってくると思います。

そして、そのような考えかたでソフトウェアを作れるようになっていけば、開発の生産性に関する考え方も変わっていき、目先のプロダクトさえ作れればOKという作り方から脱出していけるのではないでしょうか。

そうやってソフトウェアの資産も組織内に溜まっていくと思っています。

ぜひそんな開発が当たり前になるようにソフトウェア開発をマネジメントしていける人材を企業のトップにより多く取り入れていくことが今の日本企業に必要なことではないかと私は考えています。