プログラミング以上に大事なのに教えてもらえない【ソフトウェアエンジニアリング】
義務教育でのプログラミング開始やプログラミングスクールの勃興など、昨今は老若男女問わずプログラミングを学ぶ機運で盛り上がっています。
私は世間の風潮より少し早めにそういった分野を学んだITエンジニアのはしくれですが、昨今の学び直し教材の内容をみて危機感を抱く点があります。
それは
プログラミングよりも大事な【ソフトウェアエンジニアリング】を教えてもらえていないのではないか?
という点です。
プログラミングとソフトウェアエンジニアリングの違い
コンピュータ絡みの仕事をしている人ですら、いざ
「プログラミングとソフトウェアエンジニアリングの違いを説明せよ」
と言われると答えに困る人は少なくない気がします。
まずこの単語を説明するために、ソフトウェアやプログラムと言った、昨今ではよく聞く単語の意味を振り返ってみましょう。
・ソフトウェア or プログラム・・・コンピュータに特定のタスクを処理する命令を記述したモノ
これを踏まえると、プログラミングの意味を説明するのは比較的に簡単です。
・プログラミング・・・新しいソフトウェア（プログラム）を作成する方法
では、ソフトウェアエンジニアリングとは何か？
2021年に日本語版が発売されたばかりの本、Googleのソフトウェアエンジニアリングにはこんな説明がありました。
Google 社内でときに言われるのは、「ソフトウェアエンジニアリングとは時間で積分したプログ ラミングである」ということだ。
ソフトウェア開発に携わったことがある人なら、この一文とそれに続く本文の説明が物凄く刺さると思います。が、正直専門外の方に説明するには分かりにくそうです・・・
この表現方法を踏まえつつ、コンピュータを専門としない人も分かりやすく説明するならば、私はこう言い換えます。
・ソフトウェア or プログラム・・・コンピュータに特定のタスクを処理する命令を記述したモノ
・プログラミング・・・新しいソフトウェア（プログラム）を作成する方法
・ソフトウェアエンジニアリング・・・作成したソフトウェア（プログラム）を長期間稼働させるために必要な総合的知識
ここで「総合的」のワードを強調した理由は、ソフトウェアエンジニアリングで求められる分野は単純な技術的ノウハウだけでなくチームビルディングやチームコミュニケーションなど多岐に渡るから。
上記で引用した本の目次を見ると、ソフトウェアエンジニアリングで求められる知識の多様さを垣間見ることができます。
第1部 主題
1章 ソフトウェアエンジニアリングとは何か
第2部 文化
2章 チームでうまく仕事をするには
3章 知識共有
4章 公正のためのエンジニアリング
5章 チームリーダー入門
6章 スケールするリーダー
7章 エンジニアリング生産性の計測
第3部 プロセス
8章 スタイルガイドとルール
9章 コードレビュー
10章 ドキュメンテーション
11章 テスト概観
12章 ユニットテスト
13章 テストダブル
14章 大規模テスト
15章 廃止
第4部 ツール
16章 バージョンコントロールとブランチ管理
17章 Code Search
18章 ビルドシステムとビルド哲学
19章 GoogleのコードレビューツールCritique
20章 静的解析
21章 依存関係管理
22章 大規模変更
23章 継続的インテグレーション
24章 継続的デリバリー
25章 サービスとしてのコンピュート
「ソフトウェア」と言う言葉から連想されがちな技術・ツールの話だけではなく、チームコミュニケーションや組織ビルディング的な話など、人間的なカテゴリが多く含まれているのが分かりますね。
ITエンジニアの仕事に必須なソフトウェアエンジニアリング
ソフトウェアエンジニアリングを学ばず、プログラミングだけを学んでITエンジニアになれるのか？というと、現実的にはほぼNoです。
なぜか。それは
会社は存続するので、会社活動の基盤となるソフトウェアは作成するだけでなく持続させる必要がある。
それゆえ、会社に所属するITエンジニアにも、ソフトウェアを作成＆持続させる責務がある。
この責務を果たすための知識・技量こそがソフトウェアエンジニアリングの領域。
からに他なりません。
ただし、プログラミングを生かす場面の全てでソフトウェアエンジニアリングの知識が必要になるか？といえば、必ずしもそうとは限りません。
もっとも極端な例でいえば、
自分のパソコン上で行いたい、自分だけが楽するために自分だけしか使わないソフトウェアを作る
こんな用途なら、プログラミング知識だけでプログラムを書いて問題になることはほぼないでしょう。この状況下では、ほとんど使い捨てに近い「今回限りで動くプログラム」を書けば十分であることが多いからです。
仮に長時間稼働するソフトウェアが必要で、かつ自分の知識不足でせっかく作成したソフトが動かなくなったとしても、自分がちょっと困るだけで社会に問題を与えることはまずありません。
ここが、自分のためにプログラム（ソフトウェア）を書くことと、仕事として会社に必要なソフトウェアを書くことの大きな壁。
すでに大きなソフトウェアを構築維持している会社のITエンジニア求人なら、募集条件に
大規模なソフトウェアを運用する知識・経験がある方
と、ソフトウェアエンジニアリングそのものの単語は出さずとも、それ相当の知識を求めているパターンが普通です。
下手をすると「その要件は当たり前すぎるから書いてない」とのパターンも。
一方、創業して間もない会社であれば
とにかくシステムを作れる方募集
と言ってソフトウェアエンジニアリングの観点は不問にされる場合もあります。
が、その場合であっても、もし事業が継続できるほど売上が立ったときに
ソフトウェアエンジニアリングの観点を無視して初期プロダクトを構築したせいで、機能の追加改善がままならなくなってしまった…
などと初期の拙速な意思決定を後悔するパターンは、業界でひっじょーーーによく見る光景です。
（創業者自身に十分なエンジニアリング知識がない限り、むしろこの展開はほとんど不可避なレベル）
後になってソフトウェアエンジニアリングの知識がある人たちを雇い、地道にソフトウェアの改善を続ける必要があります。
運良く誰もソフトウェアエンジニアリングを気にかけない初期フェーズにプログラミングの知識だけで参画できたとしても、このフェーズの変化までにソフトウェアエンジニアリングのキャッチアップが出来なければ組織から求められる仕事の変化についていけなくなってしまいます。
「最初の頃に色々頑張って貰った方ではあるんだけど…」と。
ソフトウェアエンジニアリングが教えられないのは何か
これほど重要であるソフトウェアエンジニアリングの知識。
しかし冒頭に指摘した通り、プログラミングを学ぶ機運そのものに比べて、不気味なほどにソフトウェアエンジニアリングの教育については置き去りにされている感が否めません。
これはプログラミングや ITを学ぶ環境を取り巻く構造的な問題に起因していると考えています。
1. ソフトウェアエンジニアリングまで教える時間がない
記事タイトルに「プログラミング以上に大事な〜」などと書きましたが、ぶっちゃけプログラミングそのものだって大事です。
ソフトウェアエンジニアリングで探求する「長時間稼働するソフトウェアを作成するにはどうすればいいか」との課題設定は、結局はプログラミングの延長線上にある存在。
プログラミングの知識抜きに、良いソフトウェアエンジニアリングの技法を身につけられるなんてことはあり得ません。
そしてこのプログラミング自体、学ぶのに相当の時間がかかります。
一方で世に溢れるプログラミング的スクールといえば、数日から数週間、長くても数ヶ月の設定が多い。
特に仕事を辞めて日中通わないといけないコースの場合、期間が長引けば実質の受講コストが嵩むので受講生からすれば参加が躊躇われます。
スクール側としても受講生を集めるには授業時間を短く設定して「たったこれだけの期間でプログラミングができるようになる！」と宣伝したい、そんな事情があるのでしょう。
・・・とすると、そんな短い期間ではプログラミングを教えるのがやっと。
（あまりに期間が短すぎると、「それ、本当にプログラミングを教えたと言えるのか？？？」と疑問になるカリキュラムもしばしば見かけます。）
仮に
我々のスクールではプログラミングもソフトウェアエンジニアリングもきっちり学べます！
ただし受講期間は平日週5日8時間きっちり勉強した場合で4年間です！！！
などと主張するスクールがあったとしましょう。
間違いなくそのスクールに通えばITエンジニアに転職できるほどの実践的な能力が身につくと分かっていたとしても、このスクールに通える金銭的・時間的余裕がある人は相当の少数派になるはず。ビジネス的に難しい。
結果として、実社会からは需要のある知識だけれど、スクールで教えるにはビジネスが成り立たないので放置されてしまう。ソフトウェアエンジニアリングにはそんなジレンマがあります。
2. 大学教育で学ぶスキルと企業が求めるスキルの乖離
平日週5日8時間学ぶことを4年間続けられる環境があります。そう、大学です。専門学校なども同様ですね。
日本だと大人が学び直しとして大学に行く環境が整っておらず難しいです。でも、今から大学を選び、通う若い世代であれば、大学でコンピュータを学べば安泰・・・なのでしょうか？
ここにも罠があります。大学や専門学校で教えられるスキルと、企業や社会が求めているスキルに乖離があるのです。
私自身は情報系の大学でみっちりコンピュータサイエンスを学びました。母校は割と社会の変化に対応しつつ最新のカリキュラムに反映する努力をしていた方だと思います。
それでも、実社会が当時求めていたスキルと学校で教えるスキルとに10年ほどズレがあったのではないか・・・と、卒業して社会を知った今振り返るとこう感じざるを得ません。
かつ、競争環境の激しい企業経営の状況とも絡み合うソフトウェアエンジニアリングの知識は、この乖離の影響をモロに受けます。
そもそも大学側自身が、実社会の即戦力的な知識を教えることを拒否している面もあります。
IT業界の話ではなくモーター技術の世界の話ですが、こういった教育界の体制に業を煮やした日本電産の永守氏は
「企業の人材として役立つスキルを、大学では教えなくてけしからん！」
と、自身で学校経営を開始しました。
IT・ソフトウェアエンジニアリングの世界に限らず「企業が求める重要なスキルなのに、どこの学校でも教えてくれない」分野が存在していることを象徴する動きだと思います。
3. 本での独学や机上の講義だけで学ぶのが難しい
プログラミング学習中にソフトウェアエンジニアリングをも学ぶ大切さに気付いたとしましょう。
前項1,2で指摘したように、この分野を学校・スクールで提供しているところは少なく、講義で学ぶのが困難。
しかし、幸いなことに冒頭で紹介した本をはじめ、ソフトウェアエンジニアリングの知見を提供してくれる名著はたくさんあります。まずはこれらの本を読み込んで勉強するのはマストでしょう。
しかしここでも問題が。ソフトウェアエンジニアリングは
顧客にサービスを提供しつつ
他のメンバーと協調しながら
大規模なソフトウェアを長時間動かす
といった、実際に多くの企業で遭遇する場面で求められるスキルです。
一方で、企業以外の現場・・・例えば学校内や独学で学ぶ時にこのスキルを活用する場面は極めてまれ。
どんな分野にせよ、スキルを身につけるには
「教材などから理論を学ぶ」と「実際にスキルを実践する」
の両方をこなすことが不可欠。
プログラミング自体は独学でも学べるという主張もよく聞きます。
確かに、教材からプログラミング言語の知識を学び、実際にパソコンで書いて動かしてみる・・・と、理論と実践の両輪を回すことが可能でしょう。
でも、ソフトウェアエンジニアリングを実践で学ぶために、多人数で大規模なソフトウェアを実際に書き上げ、実際にサービスを提供しつつ長時間稼働できる実践の場を確保する・・・
ぶっちゃけ、そんなレベルまで独学でやりきれる人は、プログラミングの独学に成功する人のうち、さらに少数の人だけです。
まだ学生かつ関東近郊であれば
独学もしくは大学の講義でプログラミングを身につける
学生中に自社Webサービスを開発している企業のアルバイトや長期インターンの機会をゲットする
といったキャリアパスで、会社の業務を通じてソフトウェアエンジニアリングの実践を学ぶ機会が手に入れやすいです。
最近はフルリモートの普及やWeb系企業の地方都市進出で、土地の縛りが緩くなったのは本当に良いニュースだと思っています。
（私の時代は、上京した後に「自分が学んだ地方の大学と関東近郊の大学とでこんなに学びのチャンスが違うのか・・・」と気付いて、生まれた土地の違いで得られる機会の不平等に憤って一時期人生投げやりになったレベルでした。しくじり話終わり）
ただ企業が、こういった形でプログラミングを学んだだけの人を受け入れ、教育コストをかけてくれるのは学生のみ。
大人になって別キャリアからの転身を希望する場合だと「即戦力のみ未経験不可」のスタンスがほとんど。
大事なことなのに、実務がないと学べない。でも学生時代を除いて、実務に関わるチャンスが極めて難しい。
そんな詰み状況ゆえに、ソフトウェアエンジニアリングを学ぶのが極めて難しい状況になっています。
実は、この状況を回避し、未経験ながらソフトウェアエンジニアリングを実践で学ぶ機会があるとすれば、ネットの転職先としては不評なSIer/SESだったりするのですが・・・
このへんの是非を語り出すと別記事が何本も書けるレベルでややこしいので今回は割愛します。
ロー/ノーコード時代にソフトウェアエンジニアリングの重要性はむしろ上がる
学び直しの一環でプログラミングを選択する際の議論で
プログラミングを簡単にするローコード・ノーコード技術の発展で、従来のプログラミングスキルの価値は下がるのではないか
との指摘もあります。
私は、この指摘自体はある程度当たると思います。
昔はコードを書かないとできなかったようなことが、今後はコードを書かずともロー/ノーコードツールのおかげで出来るようになる分野が、着実に広がりました。
一方、ロー/ノーコードで作られたソフトウェアにもソフトウェアエンジニアリングが必要です。
これらのソフトウェアは使い捨てではなく、企業内部で従来の業務フローを人手から機械に置き換えるために使われることが多数。ソフトウェアが止まれば会社、引いては顧客にも影響が出ます。
これはまさに、ソフトウェアエンジニアリングで扱うべき性質のソフトウェアそのものです。
ただ、従来のプログラミングを学ぶ人たちでさえ身につけられないことが多いソフトウェアエンジニアリング。
ロー/ノーコードツールは、そのプログラミングさえ難しい人々がソフトウェアを作れるようにするためのツールです。
そのツールを使う人たちのうち、果たしてどれほどがソフトウェアエンジニアリングを踏まえてロー/ノーコードのソフトウェアを作るのか。
IT系記事には、そうして昨今企業に導入されたシステムが、今後動かなくなって混乱を巻き起こす可能性を指摘するものもあります。
「動かないソフトウェア」がこれまで以上にあふれる時代に
プログラミングスクールの隆盛やプログラミング教育の義務化。あるいはロー/ノーコードの進化。
今の時代はかつてないほど「プログラミングでソフトウェアを作る」ことが容易な時代になりました。
しかし一方で、「ソフトウェアを長期安定的に稼働させる」ための知識であるソフトウェアエンジニアリングを学ぶ環境は、プログラミングの敷居が下がったスピードに見合うほどには下がってるようには見えません。
ソフトウェアエンジニアリングの観点がないまま作られたので、数年ののちに動かなくなってしまって打ち捨てられるソフトウェア・・・もちろん、こういうものは今までにも大量に存在していました。
が、プログラミングとソフトウェアエンジニアリング知識普及のミスマッチから、「動かないソフトウェア」に直面してユーザーや社会が困るような機会は、これまで以上に増える予感がします。
とはいえ、まずプログラミングへの理解がなければソフトウェアエンジニアリングの重要性の理解も難しい。
社会のIT化に伴ってプログラミングの重要性が増すことは数十年前から指摘されていながら、日本でようやく義務教育として開始されたのはここ数年のことです。
それを踏まえると、ソフトウェアエンジニアリングを学ぶ重要性が社会的に認識されて学習環境が整うまで、また十年二十年といった時間が必要なのかもしれません。
最後まで読んで頂きありがとうございます！ いただいたサポートは記事を書く際の資料となる書籍や、現地調査に使うお金に使わせて頂きますm(_ _)m