システム開発のゴール
システム業界で働くと、モヤモヤすることがたくさんある
ITリテラシーの低い人との認識の相違が、モヤモヤの原因だが、その認識の相違の最たるものが、ウォーターフォールモデルだと思う
一般的なシステム開発は、要件決めて、設計開発し、テスト、リリース、保守運用という、ウォーターフォールモデルに沿って行われる
ITに馴染みのない人にとって、この説明はとても腹落ちするらしく、多数問題点が指摘されながら、しぶとく生き残ってきた
WEBの世界でもウォーターフォールモデルは根付いている
特にプログラミングの経験がない人には、何の疑問もなく受け入れてもらえる
しかし、少しでもシステム開発の経験があれば違和感を抱く
ウォーターフォールの手法がまともにワークしていることはほぼ無い
原因はいくつかある
まず、ウォーターフォールの前提として、技術の基本を理解している人が設計を行わなければならないが、この世界では同じ開発が
再度行われることはない（もし同じものを作るとしたらコピペで完了する）
作ってみないとわからないことが多すぎる
つまりガチガチの汎用機でもない限り、ウォーターフォールなど無理なのである
さらに、仕様の複雑さがあげられる
今まで完璧な仕様書を見たことがあるだろうか
完璧な仕様書とはイコール、ソースコードだ
ソースコードに近いくらい細かく書かれた仕様書を見たことはある
しかし、ソースコードには及ばないし、何より無駄が多すぎる
現実世界を仮想の空間に再現する、システム開発において、とんでもなく複雑な、それらを文章で全て書き表すのは無理である
エッセンスを正確に伝えることさえ、難易度は高い
コンピュータの世界は日進月歩だ
ソフトウェアの開発技術は飛躍的に進歩した
何かを実現するために書かなくてはいけないソースコードの量は、減っている
今後、減ることはあっても増えることはない
さて、ソースコードの技術的な部分が極小になり、ほとんどが宣言的に表現されるようになると、プログラミングとはすなわち仕様を決めることである
仕様を決めることが最も重要であり、難易度も高い
スループットはどれくらいなのか、応答時間は何ミリ秒か、レコードは1対NかN対Nか、パラメータは状態を持つのか持たないのか
何もないところから、机上でそれらを見定めるのは、とてつもなく困難である
結局、作ってみないとわからない
作られたシステムこそが仕様書であり、要件定義書である
システムにデータを入力し、動かせば、何が起きているかは誰の目にも明らかになる
となると、システム開発のゴールは、はじめに決めた仕様を満たすものを作ることでは決してない
仕様を決めることでもない
前述したように、仕様を定めることなど不可能だからだ
それらしいシステムを早期に実現し、実際に関係者に使ってもらい、高速にフィードバックを行うサイクルを高速に回す
いわゆるDevOpsだ
継続的インテグレーション（CI）であり、継続的デリバリー（CD）である
そういったアジャイルな仕組みを作り上げることこそが最も重要であり、システム開発のゴールとなる
自動テストを組み込み、実装されたすべての機能が壊れることなく、新しい仕様を組み込んでいける仕組みを作り、その仕組みを維持することこそが最重要である
ウォーターフォールでいうと、全ての水が滝を落ち、穏やかな流れになったところが、実は開発のスタートといえる
この認識の相違は彼岸と此岸のごとくである
人月の神話を読んで、やはりわが社のシステムは寿命が近いと感じた
https://www.amazon.co.jp/dp/4621066080
かの有名な、「人月の神話」を購入して読んだので感想。
IBM/360という、プログラムを交換可能な画期的な汎用機の、OS開発のプロジェクトを率いた人が著者
IBM/360は1960年代に発売され、この本の初版は1974年に発行された
すべて1974年に書かれたわけではなく、有名な「銀の弾丸などない」は1986年に書かれた文書で、後の版で追加された。さらに1995年に追加された部分もあり、この本一冊でプログラミングの歴史を知ることができる
構造化プログラミングや、オブジェクト指向が、どういう経緯で広まっていったかがわかり興味深い
この本を読むときは、最初の版と後の版を分けて考えるべきだ
学術的には最初の版のほうが価値があるだろうが、実務的には後の版に書かれている内容に価値がある
最初の版（１６章まで）について
コンピュータの入出力にテープやプリンタを使ったり、一日に数時間、決められた時間だけコンピュータを占有してつかったりと、どこかで聞いた伝説のような話が繰り広げられる
しかし、本質はかわっていない、どころか、今も続いている風習の起源はもしかして、ここにあるのかもな、と考えさせられる部分がいくつもある
例えば、フローチャートをノイマン博士が導入し、根付いていったが、筆者は必要ないと思っているくだり、などその通りだと思う
そのほか、なるほどと思った点
・システムのリリースまでにかかる工数は、プログラム単体を作る工数の9倍
・人と月は交換できない、なぜならコミュニケーションコストと教育コストがかかるから
（ブルックスの法則：遅延しているソフトウェアプロジェクトに要員を追加するとさらに遅れる）
・アーキテクトが仕様を定めすぎると、開発者が創造性を発揮できない、ということはない。むしろ逆。制限があるほうが創造性を発揮できる
・プログラムのサイズが大きくなると開発工数は指数関数であがる（1.5乗）
・エントロピーが増大したシステムはやがて、修正を加えても改善につながらなくなる。一歩進んで一歩下がる
これは弊社のシステムの現状を適切に表現している
・銀の弾などない。ソフトウェア技術は進歩するが、システムの本質的な複雑さは変化しない
後ろの版（17章以降）について
20年が経過し、状況が変化した
商用パッケージソフトやコンポーネントの再利用については、著者はこれほど広まるとは思っていなかったらしい
なお実装段階の問題だが、コンポーネントは使いこなすためには学習コストが高い
パッケージを使うことで本質的な概念のレベルを上げることができると言っているが、パッケージソフトはある意味、銀の弾丸になっている気もする
要件決める段階で、いかにフルスクラッチで作らず、既存のものを使いまわすかという、フレームワークやオープンソースに精通しているかが勝負になっているということか
ブルックスは、メタプログラミングが本質を攻略する鍵であると述べているし、パッケージの中を隠ぺいするのが正しいとか、開発チームは執刀医を中心とした外科手術チームみたいなものが理想だと述べている
これが後のSOA（サービス志向アーキテクチャ）やマイクロサービスアーキテクチャにつながっていくのだろう
そして一番大事だと思ったのがここ
・プロジェクトにかかる月数は投入人月の立方根に比例する
月数 = 2.5 x （人月）^ 1/3
自分が不勉強なだけかもしれないが、初めて聞く話だ
今後の仕事に生かしていきたい
・コスト曲線は最適なスケジュールより長くなると上昇する
パーキンソンの法則的なものか
・コスト曲線は最適なスケジュールより短くなると急上昇する
長すぎも短すぎもよくない
論語と算盤は時代遅れなうえ間違っている
もうしばらくすると、一万円札の人物が渋沢栄一になるらしい
その流れで、私のまわりでも、渋沢栄一や、彼が書いた書物である「論語と算盤」が話題になることが増えている
つい先日も、会社の上司が、いま一番重要なのはこの本だ、と論語と算盤を読むようにすすめてきた
漢文の書き下しが多く、単語の意味が分からないことがままあり、何度か挫けそうになりつつ、すべて読み終わった
感想としては、渋沢栄一の今でいうブログであり、それほど絶賛するようなものではないと思う
個人的にいいなと思ったのは二か所で、一つ目は渋沢が江戸時代に船でナポレオン三世が統治するフランスのパリ万博に行った時の話
まだスエズ運河が開通しておらず、一部陸路を利用して55日かけてパリまでたどり着いた。パリにいる間に江戸時代は終わり、その後スエズ運河は開通し、渋沢の存命中にシベリア鉄道やパナマ運河も完成した
当たり前だが、江戸時代と現代は連続している
二つ目は、江戸時代を回想して、当時は士農工商の区別が厳格で教育程度が階層によって異なり、また鎖国のせいで海外から置いてかれていたというあたり
士農工商と鎖国については、最近否定されることもあるが、当時を生きていた人がそう言っているのだからそれなりの信ぴょう性はあるだろう
結局、個人の見解や作り話よりも事実のほうが面白いのだなと、妙なところが勉強になった
さて本の主旨について、全体を要約すると、まず渋沢栄一は迷信とか奇跡といった超常現象が嫌いで、宗教より哲学、それも東洋哲学である儒教で世の中をまとめたいと思っている
江戸時代に国学とされた朱子学は、儒学の教科書である論語を曲解しており、論語にある孔子の本来の教えに立ち返れば、富を増やすのは間違ったことではなく、商業や工業にもこれを適用できるとしている
渋沢の考え方は、宗教改革で、お金を稼ぐことは悪いことではなく、神の栄光を表すものだとしたカルバンのようだ
またこれからはキリスト教だとした前五千円札の新渡戸稲造や、脱亜入欧を主張した現一万円札の福沢諭吉とは異なる思想だ
渋沢は間違っている
まず、論語と算盤の中で儒教とキリスト教が対比されている箇所があるが、キリスト教は宗教であり、儒教は哲学なのだから、比較対象が間違っている
儒教と比較するべきは、古代ギリシャから連綿と続く西洋哲学や、道教など他の東洋哲学であろう
そして、儒教を日本の国学として採用するかについては、残念ながら現一万円札の諭吉先生のほうが正しい
儒教思想を推奨し論語をテキストとした文明はことごとく停滞した
明、李氏朝鮮、江戸幕府、はそろって、最初は調子がよかったが、最終的に社会の発展が止まり、閉塞感が漂い、崩壊した
令和のこの時代、日本でほとんど論語が読まれていないのは、朱子学と論語原理主義の差がどうとかではなくて、儒教思想の根本が誤っているからだ
渋沢は祖先や兄弟に従う「孝悌忠信」が重要だと言うが、これらを至上命題とすると、他人の目を過度に気にし、権威にいたずらに従う、為政者に都合のいい社会となる
明治時代以降も、教育勅語など、儒教的な価値観は細々と続いていたが、太平洋戦争で日本はアメリカに負け、儒教は完全に捨て去られた
代わりに入ってきたのが、長年にわたり世界を支配し、時の試練にも、数々の敵の挑戦にも耐え、現代社会や科学を発展させてきた、イギリスとアメリカの哲学である
自由と民主主義、そして、最大多数の最大幸福を合理的に求め、実証できることだけを信じる科学的な考え方だ
われわれは小学校からそういった教育をうけているし、グローバルスタンダードはそのような考え方だろう
渋沢は功利の思想だけでは、道徳が崩壊するというが、功利論を正しく理解していない
功利とは、自分の利だけを求めるのではなくて、全体の利を求めることだ
それを知ってなお自分の利だけを求める人がいるのが問題であれば、法律で縛るか、あるいは渋沢の嫌いな宗教を推進するべきだ
もちろん、道を歩いていたら武士に突然切り殺されるような、今よりははるかに教育程度の低かった当時の社会では、論語と算盤の主張する考えは役に立ったであろう
渋沢も本文中で、道徳は時代により変化するし、社会は進化すると述べている
進化レベルにより役に立つ思想も変化するのだから、つまり論語と算盤を現代社会で活用するのは時代遅れなうえ間違っている
経産省DXレポートを読んで日本のIT業界の将来に少し希望がわいてきた
経産省DXレポートなるものが世間を賑わせている。
DXとはデジタルトランスフォーメーションのことだ。
ソースはこちら
http://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
日本企業の既存システムはレガシー化（ブラックボックス化）している。
ユーザ企業の経営層はITに関心が無く、開発ベンダーとも上手くいってない。
このままだと2025年に日本は終わる。
対策として、不要なシステムは破棄し、業界共通の機能は共有システムとすべし。
ユーザ企業とベンダ企業が手を取り合い、クラウドにマイクロサービスを組み合わせた攻めのシステムをアジャイルで作りましょう。
今まで自分がふわっと考えていたり、下手な説目でまわりに上手く伝わらなかったことが、綺麗にまとまっていて、それを経産省という権威ある機関が発表してくれたことに、とてもうれしくなった。
特に、レガシーシステムを刷新する方法として、「マイクロサービスの活用」があがっているのがいい
「マイクロサービス化することによって細分化し、・・といったアプローチも考えられる」と控えめな表現ながら、国主導によるマイクロサービスが当たり前の世界の到来を予期させる。
われわれエンジニアは、「API/Web APIベースの疎結合構造によるモジュール化されたサービスの利用」に適応しなければならない。
また、アジャイル開発を前提とした契約について、「スクラムマスター等の構成員の権限・責任の明確化」「プロダクトオーナーが役割を全うしない場合の対応方法の明確化」などと書かれていて、なんと、これからはスクラム開発を前提とした契約を締結する時代になるかもしれない。
一点不満というか、心配なのは、診断スキームの構築とか、共通プラットフォームの構築まで経産省がやろうとしてるところだ。
共通プラットフォームなんて世界共通のものが出そろっているのに今更役所がどうしようというのか。
レポートの著者には大企業の役員の名前が並んでいるが、こういったメンバーでマイクロサービスやスクラム開発を推進すべきという結論に至ったのは素晴らしい。日本のIT業界もまだ完全には終わってない。
