「ソフトウェア」の意味
プログラマー、あるいはシステムエンジニアとして働いていると、何気なく「ソフトウェア」という言葉を使います。「プログラム」「ソフトウェア」「アプリケーション」といった言葉はほとんど同じ意味合いで使われることが多いですが、どういう文脈の時に「ソフトウェア」という言葉を使うのでしょうか。
「ソフトウェア」は、「ハードウェア」の対比として生まれた言葉です。一般的に、物理的に存在する機械などの製品や、製品を構成する部品のことをハードウェアと呼びます。一方、ハードウェア上で動作するプログラムや、ハードウェアに保存されるデジタルデータのなどをソフトウェアと呼びます。
ハードウェアとソフトウェアは物理的に存在するか否かの違いがありますが、それがなぜ「ハード（硬い）」と「ソフト（柔らかい）」という対比になっているのでしょうか。通常、硬いから物理的に存在する、柔らかいから物理的に存在しない、とはならないでしょう。
「ハード」と「ソフト」の対比は、物理的に存在するか否かではなく、
固定されていて変更が難しい（固定性・ハード）か、
柔軟に変更ができる（可変性・ソフト）か
の対比になっています。
ウォーターフォールとアジャイル
ソフトウェアの開発手法にはウォーターフォール的な開発とアジャイル的な開発があります。
ウォーターフォール的な開発では、開発を「要件定義」「設計」「実装」「テスト」のようにフェーズ（工程）毎に分け、1つのフェーズが終わると次のフェーズに進む、という進め方をします。最初に要件を細かく決め、後から仕様変更が起きないように調整しながら開発を進めることが多いです。リリースは、全ての工程が終わって全機能の開発が一通り終わったタイミングでまとめてリリースすることが多いです。最初に全体の計画を立て、立てた計画をベースに進めていくことから、計画駆動開発と呼ばれたりもします。
一方、アジャイル的な開発では、顧客と積極的にコミュニケーションを取りながら、変化を受け入れ、細かくリリースとフィードバックを繰り返しながら顧客への価値を高めていきます。アジャイルでも計画は立てるものの、それはあくまでも全体像と現在地を把握することが目的であり、計画通り進めることに価値があるとは考えません。チーム単位での開発を行い、比較的短いスパンでのリリースを繰り返していく進め方が一般的です。
ウォーターフォールとアジャイルは根本的に考え方が異なるので、どちらの方が優れている・劣っている、というものではありませんが、ソフトウェアの最大の特徴が「柔軟に変更できる」ことだとすると、変化を受け入れて計画も柔軟に変更しながら進めるアジャイルの方が相性は良さそうです。
少なくとも、後から仕様変更が起きないことを前提にし、全ての開発が完了してからリリースするウォーターフォール的な開発手法は、ソフトウェアの強みを完全に封じ込めた開発手法であるため、ソフトウェア開発と相性が悪いことは間違いないでしょう。
自社サービスと受託におけるアジャイルの浸透具合
アジャイルに関する記事や書籍を読んでいると、日本では他の国に比べてまだまだアジャイルが浸透しておらず、ウォーターフォール的な開発現場も多いみたいです。私自身、開発者としての経験上、ウォーターフォール的な開発の方が割合として多いです。
ソフトウェアの特性を考えると、アジャイル的な進め方の方が相性は良さそうであるにも関わらず、なぜウォーターフォールの方が多いのでしょうか。
これに関しては様々な要因がありそうですが、アジャイルの浸透具合というのは、自社サービスや自社で内製しているソフトウェアを開発する場合と、受託として他社のソフトウェアを開発する場合で割合は大きく変わるような気がしています。
少なくとも、自社サービスや、自社で内製しているソフトウェアをウォーターフォール的な開発手法で進めるメリットはないので、自社でコントロールできる範囲が広い開発においてはさすがにアジャイル的な開発の方が多いのではないかと思います。
問題は受託として開発する場合。
特に、BtoBで顧客企業が使用するソフトウェアを受託で開発する場合、顧客の都合によってビジネスを進める必要があるので、ビジネス的な制約によってウォーターフォール的な開発になってしまうケースが多いのではないかと思います。
私の経験でも、自社サービスを開発している案件ではアジャイルが主流で、受託の開発ではウォーターフォールが主流でした。
アジャイルが浸透しない理由
受託においてアジャイルが浸透しない要因は色々と考えられますが、私は以下の３つの理由が大きく影響していると考えます。
- ソフトウェアに対する認識不足
- ソフトウェア開発に対する認識不足
- ビジネスとの相性
1. ソフトウェアに対する認識不足
最初に説明したように、ソフトウェアは柔軟に変更できることが特徴ですが、そのことを正しく認識していない人は多いように感じます。
エンジニア以外の人にソフトウェア開発の仕事を説明する際に、大量生産の製造業や建設業に例えて説明することが多々あります。ウォーターフォール的な開発手法をする場合は製造業や建設業と似ているため、ソフトウェアの知識がない人に対しても説明しやすいです。
ただ、製造業や建設業はそもそも物理的なもの（ハードウェア）に対するモノづくりの手法です。ハードウェアは作り始めてしまうと途中から変更するのが難しいため、最初に仕様を固めて計画に沿って進める方法は理にかなっていると言えるでしょう。
しかし、ハードウェアとソフトウェアは対比の関係にあります。
ハードウェアを作るための手法をそのままソフトウェアに適用しても、そもそも作るモノの特性が大きく異なるので、同じ手法が適切と言える根拠はありません。
2. ソフトウェア開発に対する認識不足
まず、業界・業種に関係なく、「プロジェクト」というのは今までにやったことがないことをやることに意味があるので、その時点で「不確実性」が少なからず含まれます。その中でも、ソフトウェア開発のプロジェクトは特に不確実性が高いものになります。
ソフトウェア開発では、比較的シンプルなアプリを開発する場合でも関連する複数のソフトウェアとの相性や連携を考えなければいけません。
- プログラミング言語
- ライブラリ
- フレームワーク
- OS
- DB
- APサーバー
- インフラ環境
などなど。
まず、複数の異なる技術を組み合わせること自体が、正しく動くのかどうかやってみないと分からない場合が多々あります。その上、これらの各要素にはそれぞれバージョンがあり、お互いのバージョンの組み合わせによってうまく動作しなくなったり、思わぬエラーが出たりします。使うツールの組み合わせが無数にある中で、それぞれのツールのバージョンによる差異なども考えると、世の中のソフトウェア開発案件において、全く同じ状況で同じ機能を開発するような案件はほぼなく、不確実なものが多く含まれる状況で開発をしなければいけません。
また、ソフトウェアはバージョンが高頻度でアップデートされます。頻繁に中身が更新されるうえに、物理的に目に見えないため、組み合わせた時にうまく動作するかどうかは実際に試してみないと分からないことが多いです。
そういった理由から、ソフトウェア開発のプロジェクトは開始した初期の段階では不確実性が高い状態であり、見積もりや計画の精度も振れ幅が大きい状態になります。プロジェクト開始時点での見積もりや計画は「全体像を把握するためのざっくりとした目安」くらいの意味しか持たないでしょう。
ソフトウェア開発と似ている仕事
ソフトウェアエンジニアの仕事は、試してみないと分からないことが多いという点では「研究職」の仕事に似ているなと思います。
また、ソフトウェア開発の仕事はエンジニア個人のスキルによって生産性や品質が大きく異なります。生産性や品質が個人の力量に大きく依存するという点では、「（職人技が必要な）モノづくりの職人」にも似ているなと思います。
研究者や職人という仕事は個人の知識やスキルによって生産性が大きく変わるという特性上、人を増やすことによる効率化が難しい仕事です。そして、研究職や職人技が必要なモノづくりと似ているソフトウェア開発の仕事もまた、人を増やして効率化することが難しい仕事と言えます。
最近はAIの進化によってその傾向がより顕著になりました。優秀なエンジニアはAIを活用することで生産性を何倍にも高めることが可能になり、人を増やして分業するよりも、優秀な人に優秀なAIツールを使わせた方が結果的に生産性が上がります。
このようなソフトウェアの特徴・ソフトウェア開発の特徴については、IT企業で働いている人でも正しい認識を持っていない人が多いなと感じます。
日本では大量生産の製造業における成功体験があり、おそらくその文化的な背景がソフトウェアに対する認識にも影響しているのだろうと思います。
人間は一度成功体験を味わうと、その手法を一般化して他のモノにも適用しようとする傾向があります。結果として、ソフトウェア開発に対しても製造業と同じような仕事の進め方をする文化が根付いているのだろうと思います。
ウォーターフォール的な考え方が根付いた結果、最初に作成した計画を絶対の約束と信じて仕事を進めたり、人月という単位で作業量を見積もり、人を増やして人海戦術によって効率化するといった手法がソフトウェア開発にも適用されています。
不確実性が高く、生産性が個人のスキルに大きく依存するような仕事で、最初の計画を絶対の約束にしてしまったり、人海戦術で効率化を図るのは良い方法とは言えないでしょう。（だからといってアジャイルにすれば全て解決する、という単純な話でもないわけですが。。）
少なくとも、自社サービスや内製して開発しているソフトウェアの場合、自社内にソフトウェアやソフトウェア開発に対する正しい認識を浸透させればアジャイル的な開発はしやすいかと思います。そのため、受託に比べればアジャイル的な開発をするハードルはまだ低いと言えるでしょう。
一方で受託開発の場合は、顧客企業に対してソフトウェアやソフトウェア開発に対する認識を説明して納得してもらう必要があるので、その分アジャイル的な開発を実践するハードルは高くなるでしょう。特に、顧客のITリテラシーが高くない場合、説明のハードルがより上がります。
その点、ウォーターフォール的な進め方は非IT企業の顧客でも比較的イメージがしやすいため、顧客への説明もしやすいです。
3. ビジネスとの相性
日本では多くの企業が年単位で予算を確保し、各部門に割り振ります。
そして、年単位で各部門が成果を達成することが求められます。
このような会社の仕組みを踏まえると、ソフトウェア開発を外部に委託する非IT企業の立場では、「このくらいの予算で、このくらいの期間で、このような機能を持つソフトウェアが欲しい」と依頼する方が簡単です。
一方で開発を受託する開発会社も、「こういうソフトウェアを、このくらいのスケジュールで、このくらいの金額で作ります」と見積もりを出す方が、顧客にも説明しやすい上、年単位の計画も立てやすいです。
ソフトウェアの特徴、そしてソフトウェア開発の特徴を素直に受け取め、アジャイル的な進め方をストレートに表現すると、以下のような感じでしょうか。
「ソフトウェア開発は不確実性が高いので、正確な計画や見積もりは難しいです。どのくらいかかるのかは実際にやってみないと分かりません。また、ソフトウェアは後からでも変更ができるので、作りながらフィードバックをもらって最適なソフトウェアを作っていきます。」
開発者目線だとこれが納得しやすい進め方ですが、この内容をこのまま顧客に説明してしまうと、「結局いつまでかかるの？いくらかかるの？どの機能までつくれるの？」と、疑問だらけになって信用は得られず、会社からの承認も得られないでしょう。
開発会社の社内でも、誰をどの案件にいつまでアサインするのか、といった調整の計画を立てるのが難しくなってしまいます。
結局、ソフトウェア開発としてのやりやすさではなく、ビジネスとしてのやりやすさ、顧客の理解しやすさを優先することで、ウォーターフォール的な開発になってしまう、というのが現実なのかなと思います。
お金とソフトウェア開発の相性
そもそも、ソフトウェア開発はビジネス（というかお金？）との相性があまり良くないとも感じます。
ある機能を開発する際に、不確実性が高いので、実際に作ってみないとどのくらいかかるのか正確に見積もりをするのが難しいという現実があります。なので、事前に見積もりをして顧客に提出している場合、想定よりも時間がかかって赤字になるか、想定よりも早く終わって多く稼ぐ（顧客からすれば若干ぼったくり気味）の状態になる場合が多いかと思います。
実際に開発してみたら見積もりよりも多くの時間がかかり、それでも納期を調整できなかった場合、人を増やしたり、開発者の時間外労働を増やして無理やり納期に間に合わせようとします。そうなると、開発コストは増えて赤字になり、開発者は体力的・精神的に疲れて集中力やモチベーションが低下し、その結果開発物の品質も落ち、「これは一体誰が幸せになるのだろう？」みたいな状況が生まれたりします。
一方、実際に開発したら見積もりの想定よりもかなり速く終わってしまった、という状況もあります。この場合、開発会社としてはスケジュールを巻いた分利益が増えて得した形になります。会社というのは利益を追求することも目的の一つなので、開発会社としては良いのかもしれないですが、仕事のあり方としてそれで良いのかは若干の疑問は残ります。
そもそも、開発にかかった時間でお金をもらうというのもあまりしっくりこないポイントだったりもします。たとえ開発に多くの時間がかかったとしても、顧客やユーザーが価値を感じないソフトウェアであれば、高額なお金をもらうのはどうかと思いますし、逆に開発期間が短かったとしても、提供できた価値が高ければ、見合った報酬が欲しいというのが本音です。
個人的には「お金」とか「契約」という概念をこの世からなくなることが一番の解決策なのでは？と思いますが、しばらくの間（というか、私が活きている間は）なくなる気配はなさそうです。
受託の是非
そもそも受託することが良いことなのかという話もあります。
日本は少子高齢化による人材不足が進んでいる割にはDXのようなデジタル活用があまり進んでおらず、早々に多くの企業がDX化をしないと結構大変なことになる予感はあります。
非IT企業が本気でDXを進めようと思うなら、自社でエンジニアを雇ってある程度裁量権を持たせたうえでアジャイル的に開発しながら内製化していくことがカギとなるでしょう。
その方が、スピード感を持って開発できるうえ、費用も外部に頼むより安く抑えられます。
そうなると、ソフトウェア開発を受託すること自体がDXを阻害する１つの要因とも考えられますが、ここを深掘りしてしまうと自分の存在意義も否定する形になりかねないので、一旦この辺りでストップします。
まとめ
- ソフトウェアはハードウェアの対比の言葉
- ソフトウェアは柔軟に変更できることが特徴
- ソフトウェア開発は、不確実性が高く、やってみないと分からないことが多い仕事
- ソフトウェア開発は、開発者のスキルによって生産性や品質が大きく異なる仕事
- ウォーターフォールは最初に決めた仕様と計画をベースに進め、最後にまとめてリリースする
- アジャイルは変化を受け入れ、細かいリリースとフィードバックを繰り返す
- ソフトウェアとソフトウェア開発の特徴を考えるとアジャイルの方が相性が良さそうだが、あんまり浸透してないらしい
- たぶん、自社サービス系では浸透してるけど、受託での浸透率が低そう
- たぶん、製造業での成功体験とか、文化的な背景が色々影響していそう
- お金とか無くなれば色々解決しそうだけど、ずっとありそう
考えれば考えるほど、ソフトウェア開発をビジネスとしてうまくやるのは相当難しいことなんだろうと思います。
まあでも、そもそも仕事はできないこととか難しいことをやることに意味があるとも思うので、そういう難しいことをうまくやろうと試行錯誤することが大事なんだとも思います。
生成AIサービスがたくさん出てきたことで、プログラミングのハードルは随分と低くなり、うまく使いこなせば生産性を何倍にも高めることができるようになってきました。
今後AIができることの幅はより広がっていくことでしょう。
そうなったときに、人間のエンジニアが最も力を注ぐべき場所は「顧客と協調してソフトウェア開発をうまくやること」になるんじゃないかと思います。
参考
Clean Agile
ソフトウェアの特徴の部分はこの本を参考にしました。
アジャイル誕生の背景とかも載っており、読み物として普通に面白かったです。
人が増えても速くならない〜変化を抱擁せよ〜
ソフトウェア開発の特徴の部分はこの本を参考にしました。
タイトルを含め、共感できる内容が非常に多かったです。
IT業界の人にも、そうでない人にもおすすめ。
ソフトウェアファースト
製造業関係の話とか、DX、内製化の話はこの本の影響が大きいです。
22世紀の資本主義
この世からお金という概念をなくすためのヒントが散りばめられている気がしたけど、経済周りのIQが2くらいしかない私にはまだ難しかったです。。