今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。

とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。

プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。

プログラミングは製造ではなく、設計である

いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。

ここが間違いのもとだ。ハードウェアと一緒にして考えない方がいい。

現代のソフトウェア開発における「プログラミング」は、製造ではなく、設計だと認識した方が良い。車で言えば、どういった構造の車にするのか設計をする部分に相当する。工場の生産ラインではない。

プログラミングとは、コンピュータにどのように動けば良いか指示をする設計図を描くことだと考えれば良い。設計図をソースコードで表現しているのだ。呪文に見えるソースコードは設計そのものを現したものだ。

アプリやウェブサイトのユーザインタフェースを設計するのと同じように、その中身であるプログラムも設計をしている。だから、設計図であるプログラムは一点モノになる。大量生産はできない。

コードを打ち込むことをコーディングと言うが、あれはただ手を動かしているだけだ。しかし、絵を描くのに、筆をはしらせるのと同じことで、描くことと筆を動かすことは不可分なように、コーディングもプログラミングの一部なのだ。

プログラミングが設計をすることだという認識を前提におけば、多くの誤解を解くことができるだろう。

プログラミングに完璧な見積もりなどありえない

設計（デザイン）という行為をしたことがあるならわかると思うが、手を動かせば終わりではない。完成品があって、それに向けて手を動かす前に、完成形が何か頭で考えないといけない。

画面などのユーザインタフェースの設計が終わっているのだから、考える必要などないのでは？と思うかもしれないが、それらは外からみた動きであって、内部の構造がどのように組み合わされているかは別の話だ。

プログラムの中は、いくつかの部品に分かれていて、組み合わされたり再利用したりして動いている。まるで精密機械のようなものだ。どのように分割すると見やすいのか、どう表現するとパフォーマンスが高くなるのか、それらを一つ一つ考えなければ作れない。まさしく設計という行為になる。

良い設計をするためには試行錯誤は欠かせない。もちろん知見と経験を備えた熟練のプログラマであれば、ときには一発でベストな設計ができるかもしれないが、それでも難しいことに違いはない。

ビルや家屋なら完成品のミニチュアを作って、確認した上で必要な材料や工数などを見積れるが、ソフトウェアでミニチュアを作ることはできない。仮にミニチュアを作れたなら、その時点で完成しているのと同じことなのだ。

どこかに試行錯誤の余地がある設計行為のプログラミングにおいて完璧な見積もりはできない。

プログラミングの生産性は人数に比例しない

設計することなのだから、大規模システムを開発するからといって、沢山の人手を一気に投入してもうまくはいかない。整合性が取れなくなるし、予見的に柔軟な基盤を作ることも難しい。大規模に必要なのは人数ではなく時間だ。

難しいソフトウェアを作るのに必要なのも、人手ではない。似たような技量のスキルの低い人たちを何百人と集めても、難しい仕様のソフトウェアを作ることは出来ない。必要なのは、優秀な人材だ。

プロジェクトの立ち上げ時にも、人手は要らない。スタートアップなら特に、最初に必要なのは量ではなく速度だ。速度を出すのに、遅い人たちが沢山いても速くは作れない。軽く作って試すことができないのは致命的だろう。

プロジェクトの終盤にも、人手は要らない。「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」、これがかの有名な「人月の神話」に書かれた「ブルックスの法則」だ。

そうは言っても、なんとかしなければいけないんだ！と言って、結局は人をつぎ込んでしまうプロジェクトも多く見てきたし、それをなんとかするのがマネジメントだと言うのもわかる。しかし、本当に前提を変えることはできないのだろうか？

未熟なプログラマが短期的に生産性を下げる

スキルの高いプログラマと、そうでないプログラマの生産性の差は、非常に大きい。むしろ、未熟なプログラマが作ることで、品質の低いプログラムが混ざり込むことのリスクが発生する。それを避けるために、熟達したプログラマがチェックをして、修正なり指摘なりをする必要がある。

そして、指摘をする位なら、最初から自分で作ったほうが速いといったケースが多々ある。読みにくいソースコードを読解するだけでも時間がかかるし、よくない設計の場合、全体から見直しをしないといけないことがあるからだ。むしろ、生産性を下げてしまいかねない。

もちろん、レビューという形で指摘を続けることで、未熟なプログラマたちがスキルアップすれば、長期的に見ればトータルで生産性は上がっていくだろう。そこには大いに意義はある。

しかし、未熟なプログラマをプロジェクトに入れるならば、そこまでを見越した上でなければ、レビューして教育する側のプログラマにとっては大きな負担となってしまうことは間違いない。

できるプログラマの中にはそうしたことを嫌う人も多い。人を育てるより、自分を育てたいのが職人の性分だからだ。

プログラムの品質は人を増やしても解決しない

オフショア開発をしたが、とても品質が悪かったので、さらに人をつぎ込んでなんとかリリースまで持っていった。そんな話を聞いたことがあるが、果たして本当に問題は解決したのだろうか。

たしかに人海戦術で、沢山の手動テストをすることで、仕様書と動きがあっているか違っているかの確認はできるだろうし、違っていれば修正をしていくことも出来るだろう。しかし、それは対処療法だ。

ソフトウェアが稼働してからも修正を続けて、その先もしばらくバージョンアップなりをしていきたいと考えているならば、その品質の高め方では、いずれ破綻するだろう。

ソフトウェアがどれだけ改修しやすい状態か、それを変更容易性と呼ぶ。変更容易性は、放っておくと改修や修正を続ければ続けるほど下がっていく。いずれは変更コストが高くなり過ぎて行き詰まり、塩漬けするかリプレースが待っている。

そうならないよう、変更容易性を下げないように維持していくことが肝になる。それは、熟練のプログラマが目を光らせていればこそ実現できる。油断して、品質の低いソースコードが混ざってしまうとアウトだ。

プログラムは誰が作っても同じにはならない

プログラムは設計という行為のアウトプットだとすれば、誰が書いても同じにはならない。不思議かもしれないが、まったく同じ画面で同じ動きをするプログラムでも、ソースコードは作る人によって違ってくる。

プログラミングは設計をすることなので、いくつもの意思決定の結果だ。どのように分割するか、データを保存するタイミングはどうするか、オープンソースのどの部品を使うのか、共通化して切り出すのはどの単位にするか、繰り返しの表現はどう書くか、ソースコードに現れるすべてに意思決定がなされているのだ。

その意思決定には、プログラミングする当人の経験や、それまで培った思想が反映される。そうした数限りなくある選択肢と意思決定の組み合わせは、誰がやっても同じ結果になる訳がない。

時にプログラマたちが「美しいソースコード」という表現をすることがあるが、それは素晴らしい意思決定の結果が、見えるようにわかりやすく伝わってくるからだ。シンプルに意図が伝わるものは美しい。

このことを知らなければ、プログラマは誰でも良いと考えてしまって採用などで失敗するだろう。

見た目が動くからといって完成ではない

見た目の動きを確認してもらうために、裏側はハリボテのように作って動かしてみるときがある。それは諸刃の剣で、早い段階で確認してもらえるが、一方で「そこまで出来てたら、もう完成したようなものだな」と思われてしまうことだ。

見た目で動いているからといって、ほぼ完成だと思うのは早計だ。

動きを確認するためだけに作る多くの場合は、中身は特定の操作にのみ対応するようにしか書かれていない。動きをそのまま書いているだけで、様々なパターンに対応するように書いてはいない。

実際に動くプログラムでは、たとえば入力される値に応じて、適切な処理をした上で出力をしている。実行するまで何が入力されるかわからないので、事前に網羅してデータを用意することはできない。だから、アルゴリズムやロジックを書くことになる。

ものすごく単純化して言えば、足し算のプログラムを作るとなったら、左辺と右辺の値に応じた結果のデータをすべて事前に用意しておく訳ではなく、左辺と右辺の数字を足すという処理（ロジック）をプログラムとして表現することになる。

見た目の確認をするための動きというのは、そうした処理を書かずに、決まった答えの数字だけ出すようにしているようなものなのだ。そう考えれば、そこから先が本当のプログラミングなのだ。簡単ではない。

ソフトウェアは動いただけでは足りない

では、動くプログラムさえ作れれば、それで良いかと言えば、そうではない。その時に動けば良いだけなら、それでも良いが、その先も暫く改修していくことを考えるなら、それでは足りない。

コピペで作りまくっていたとしたら、あとから絶対に後悔することになる。もしくは誰かのコピペを恨むことになる。10箇所のコピペがあれば、修正も10箇所しなければいけないし、きっと漏れてしまうだろう。

１箇所直すのなら、その変更箇所は１箇所にしておくことで、改修は楽になる。あとから改修しやすいことを「保守性が高い」と言う。いかに保守性を高い状態に保っておくか、それが品質の鍵となる。

そのためには、ただ動いたことを確認するだけでは足りないということだ。外から見た動きを変えずに、中身の品質を高めることを、リファクタリングと呼ぶのだが、作ることとリファクタリングはセットなのだ。

品質は適当で良いのでサクッとチャチャっと作っちゃって欲しいという要望はやめたほうが良い。そのときは良くても、すぐにしっぺ返しを食らうし、それを食らうのは言った人でなくプログラマ自身なので、きっと嫌な顔をするだろう。

ソフトウェアは初期投資だけでは済まない

ソフトウェア開発にかかる予算として、最初のリリースまでは多く見積もっているが、その後についてはケチってしまいがちな計画を見かけるが、それで失敗するケースも多い。

ソフトウェアは動き出してから、必ず修正したい部分が出てくる。それは、ユーザが直接ふれる部分だから、問題があれば直さないとクレームか離脱に繋がるし、改善の効果が見込めるなら直したいものだ。

たとえば実際の飲食店をやるのだとしたら、店員の態度であったり、料理の質やメニューの内容や表記など、顧客が直接ふれる部分は改善していくはずだ。たとえ店構えや立地を変えることはできなくても。

ソフトウェアは、その店舗の建物の方ではなく、顧客との接点で改善していく部分にあたる。だから、初期投資だけして、ランニングコストに投資しないとしたら、それが実店舗なら失敗してしまうことになる。

店だってオープンしてからが勝負なはずだ。同じように、ソフトウェアもリリースしてからが勝負なのだ。そこから改善していけるかどうかなのだから、しっかり予算をとっておいて欲しいものだ。

事業とソフトウェアは分離することはできない

新しい事業を立ち上げようとする際に、事業そのものをしっかり考えた上で、あとはソフトウェアを作るんだと考えてしまいがちだが、それではソフトウェア開発に無理をさせてしまうことになりかねない。

事業を作るというのは、ソフトウェアを作ることに等しい。事業というのも概念であり、その概念の一部をプログラムとして実装したものがソフトウェアになる。ソフトウェアができることを知らないと事業も設計できない。

だから、事業とソフトウェアは同時に作っていくと良い。UberやAirbnbなど、ソフトウェアだけで完結しないようなビジネスであっても、むしろソフトウェアを中心にして事業が考えられている。

そうした事業を作り出そうとする際にベストな布陣は、起業家自身がプログラマであることだ。一人でビジネスとソフトウェアの両方を作るなら、もっとも効率よく市場からのフィードバックでサイクルを回すことができる。

それが難しければ、信頼できるプログラマをパートナーとして迎えるのだ。ビジネス側と開発側が対等な立場であることが、事業とソフトウェアを同時に作っていくポイントになるはずだ。

ただ作ることだけにモチベーションは湧かない

プログラミングは設計であり、プログラマというのは、とてもクリエイティブな仕事だということがわかってもらえたと思う。

そして、クリエイティブな仕事において、本人の作品へのモチベーションというのは、品質や完成度に大きく影響を与える。

言われたこと決まったことだけをする仕事ならば、品質のチェックも簡単だろう。しかし、マニュアル化できないような仕事の場合、細かく指示できないのだから、作る本人がどこまでモチベーション高く、こだわって作るか、にかかっている。

そのモチベーションは、報酬や権力で働かせる外部からの動機付け（外発的動機）よりも、自分の興味や関心で働く内面からの動機付け（内発的動機）の方が効果は、一般的には高くなる。

だから、作ろうとしているソフトウェアはどんなものでも良い訳でもないし、非常に限られた裁量の中だけで手を動かすだけでもダメだし、外注や業者なんて言われても頑張れない。

なぜ作るのか、作ることの意義は何か、自分の貢献は役に立つものか、そうしたことから共有されたほうが頑張れるはずだ。

＊ ＊ ＊

これからの経営者にとって、ソフトウェアは知らないものでは済まないし、気難しいプログラマとの付き合い方も考えていかねばならない。大変な時代なのかもしれない。本稿が、その一助になれば幸いだ。