ソフトウェア開発の歴史

#はじめに
これよんでてソフトウェアの歴史面白かったのでまとめてみました。

#ソフトウェア開発の歴史
##オペレーターとしての開発者

• 最初はENIACのバーディスクが開発者？としての仕事、（数学者、ハードウェアエンジニアでハードは作った）
• 18000の真空管と40枚のコントロールパネルのダイヤルを変更して、配線する仕事だった
• ハードウェアエンジニアが問題がおきたら解決していたみたい
• このころのソフトウェア開発者は管理と操作がメインだった

##ソフトウェアエンジニアリングのはじまり

• 1961にNASAに協力した、マーガレット・ハミルトンが「ソフトウェア工学」という言葉を生んだ、リアルタイムで宇宙飛行士に警告を送るため、「Priority Display」(なんかBIOSとかと関係してるぽい)の概念が生まれた。
• ハミルトンはソフトウェア工学に品質保証の考えを加えた、
  • 全てのコンポーネントでのデバッグ（デバッグ）
  • コンポーネントの結合前のそれぞれのコンポーネントのテスト（単体テスト）
  • 結合テスト
• 1969アポロ11号の際、月着陸船の誘導ソフトウェアは扱いきれない計算をしなければいけなかった（当時のコンピュータの能力では限界だった）。そこでハミルトンのチームはソフトウェアの動作を手動で上書きできるようにプログラムした。ニール・アームストロング船長は月着陸の際に手動制御を使い着陸することができた。のちに手動切り替えの機能がきわめて重要だったことが判明した。

##ソフトウェアの課題

• １９６０年代ハードの入手のしやすさから、ソフトウェアの課題がいくつかでてきた、１９６８のNATOソフトウェア工学カンファレンスでいくつかの課題が出た
  • 成功の定義とその計測方法（システムが要件通りに動けば成功でないの？ただあとから仕様がかわるのが基本だから成功の定義がむずいのかも）
  • 大きな投資を必要としながら、実現可能性が不透明な複雑なシステムの構築（オブジェクト指向をとりいれてから改善したのでは？）
  • 納期と仕様を満たすシステムの構築（開発手法だったり、顧客がシステム開発の考えを理解できてるかのよりそう？）
  • 特定の製品を作る業者に対する経済的圧力の実行（？IBMとかのこと？）

##proprietary software 独占所有ソフトウェアと標準化

• 1964までソフトとハードは顧客の要件を満たしているだけで、標準化されていなかった。そのため互換性もなかった
• 1964IBMが「System/360」というビジネス・科学・ファミリの幅広い範囲向けのfamily computerを発表した
  • ここでの目標は、製品開発、製造、サービス、サポートにかかるコストの削減
  • 必要におうじて顧客がアップグレードできること
  • System/360は市場を支配するコンピュータになった（標準化はできた？）
• 1960年代末まではコンピュータは購入でなくリースするものだった、理由として当時のハードは高価だったから、ソフトウェアのサービスは料金に含まれていた（リース契約の）。ソフトウェアのソースコードは広く提供されていた。（無料で！！）
• 1969反トラスト法違反でIBMは訴追された。製品のソフトとハードを切り離すべきだと。
• そしてIBMはメインフレームハードウェアのためのソフトウェアに別料金を徴収するようにした。これは業界にインパクトを与えた
• これがソフトウェアに対する見方をかえ、ソフトウェアそれ自体が金銭的に価値のあるものになった。そしてオープンに提供されなくなった。

##ネットワークの時代

• 1979トムとジムによりUsenet（世界初の分散ディスカッションプラットフォーム）ができた。
• UsenetはUUCP(Unix to Unix Copy)：ファイル転送の際に、自動的に他のコンピュータを呼び出し、ファイルの変更を探して、他のコンピュータにコピーするという単純なシェルスクリプトから始まった。UsenetはUSENIXというUnixのユーザグループがあった。
• Usenetは企業や大学間の情報共有を目的として作られたが、このころ企業はまだ経営方法の詳細は「秘密のソース」のため、公開されなかった。
• システムは複雑かしていきソフトウェアエンジニアにも専門の職種ができてきた
• システム管理者は手作業で行う定常運用業務の手順をドキュメントで残すようになった。
• TQM（総合的品質管理）から「根本原因分析」のアイデアを取り入れるようになった。
• 根本原因分析はリスク削減につながりメリットもあったが、結果的にエンジニアが対処しないといけないエントロピー（複雑性てきな？）の量が増えた。

##コミュニティのはじまり

• interconnection network：相互接続ネットワークによりオンラインでの共有が可能になってくると、アイデアをじかに共有する（カンファレンスみたいのな）需要がでてきた。
• 1961にDECUS(digital equipment computer users society)ができた。主にDEC（1960年代にPDPシリーズとかだしたアメリカ企業）のコード書いたり、保守したりするプログラマが集まった。
• DECUS全米各地でローカルユーザグループを行い、それぞれのカンファレンスやイベントで論文やアイデアをあつめ、会報にして情報共有して組織の成長に役立てていた。
• USENIXのシステム管理者向けの分科会にSystem Administrators Group があって、その後SAGEとなり今日のLISA(Large Installation System Administrator)となった。USENIX はLISAを2016に解散すると発表した
• 企業とproprietary
  • 企業のproprietaryにはソフトウェア、プロセス、手法、給与構造、組織構造、顧客リストなどがある。
  • 企業が秘密として社内に留めようとする情報の範囲は、業界の文化の変化、知識と技術のcommodity（必需）化とコストの影響を受ける（留めるためのコストがあるのと、業界の成長によって秘密にする必要がなくなってくるてこと？）

##アプリケーションとWebの時代

• 1995Apache HTTPサーバが生まれた（イリノイ大学ん学部生ロバートが開発した、public dmainのNCSA HTTPデーモンが元になっている）。
• 誰でも最小限の設定でwebサーバをデプロイできるよになった
• ソースコードの閲覧、変更、配布を認めるオープンソースソフトウェアはproprietaryのクローズドソーリューションと競うことになった
• さまざまなLinuxディストリビューションが登場した。PHP,Perlなどのスクリプト言語がはやった。
• オープンソース運動によってLAMPスタック(Linux, Apache, MySQL, PHP)がウェブアプリケーション構築ソリューションとして広く普及した。
• システムが複雑かして、分野ごとの専門家が増えた結果、システムの維持に不可欠なサポートの職務に閉じ込められてしまっていることが多かった。

##ソフトウェア開発手法の発展

• 2001ソフトウェア開発に関する会合が行われAgileが生まれた。
• Agileは短いリリースサイクル、徹底的なテスト、プログラミングなどの特徴がある。１７人のソフトウェアエンジニアがユタ州のスノーバードに集まった。ソフトウェア開発はそれを作る人たちを中心におきながら、変化に適応できるようにすべきだという共通の価値観を表明した。
• Agile開発手法をまとめた「Crystal Clear」2004に下記のことが記載してある
  • 使えるコードを頻繁に届ける。大きなデプロイでなく、小さなデプロイを頻繁に行うようにする
  • ふりかえりによる改善。直近の仕事でうまくいったこと、いかなかったこと、を振り返り今後の仕事にいかす。
  • 開発者間の神道的なコミュニケーション。同じ部屋に開発者がいれば、情報は自然に流れ出して、知らず知らずのうちに伝わる、これを浸透という言葉で表現した。
• 2008マルセルがAgile System Administrator のメーリングリストを立ち上げた。

##open software と proprietary service オープンとクローズドなサービス

• オープンソースが増えるとツールの選択肢が増えた。値段も安くなった。AWSのようなハードを持たなくてもサーバをスケーリングできる仕組みもできて、すぐdefact standardになった
• Twitterもうまれた。2007SXSWでの通路のスクリーンにライブツイート

##Agile infrastructure

• Agile 2008 カンファレンスでパトリック・デボアがアジャイルとインフラについて講演した際、運用にスクラムを組み込むことを話した。
• Flickr（2005年にYahooに買収された）で開発devと運用opsが一緒に仕事をすることで、デプロイ数とは比べ物にならないほど効果的なインパクトがあった

##DevOpsの始まり

• 2009パトリック・デボアは開発者、システム管理者、ツール開発者、その他同じ分野で働く人が一同に会するローカルなカンファレンスをつくった。はじめてDevOpsDaysカンファレンスが開かれた。パトリックは次のようにコメントした「devとopsが一緒に仕事をするなんて、、しかし、今や日は広がりつつある」

##DevOpsの現状

• 2015Puppetが発行した「2015 State of DevOps Report」でDevOpsを実践している企業のパフォーマンスが高いことを示した。
• パフォーマンスの高い組織は、頻繁なデプロイ、エラーが少ない、エラーからの回復がはやい、社員が気持ちよく仕事をしている。といったことがあった。
• 2009年には１だったが2015年には22のカンファレンスが行われた。

##まとめ

• 歴史を振り返ると、人はプロセスでなく結果を重視する傾向があった。
• 特定の成果を強調しすぎると、すでに組織での限界にストレスを感じている人たちにさらにストレスを与える
• 文化とプロセスを重視すると、反復が尊ばれ、なぜどうように仕事をするのかを改善することが重視されるようになる。
• 重点が「何」から「なぜ」に移ると、仕事の持つ意味とその目的を確立する自由と信頼が与えられる。これは仕事の満足度にとって重要な要素である
• 仕事に夢中になれば特定の成果を達成することに集中しなくても、結果を大きく変えられる。
• 人は幸せで生産的になり、人類の次の飛躍を生み出せる
• DevOpsの導入で専門化を競い合うのでなく、互いの協力と強調を重視し、職種を越えて人とプロセスを重視するようになった。