日経ビジネス２０１３年１月１４日号の
２０３０年のモノ作り
で、一人でものづくりができるというものが書いてあった。
まあ、ソフトにおいては、現状そうなっているけど（アプリなんかが典型例）
そのうちハードも、そうなってくるんでしょうね。
情報処理の２月号
にある、デジタルファブリケーションなんかも、
試作機を作るのに、貢献していたりする。
今後は、特に、ロボットなんかは、そういうものが出てくるんじゃないかなと思う。
同人ロボット？
日経ビジネス２０１３年１月１４日号の
２０３０年のモノ作り
で、一人でものづくりができるというものが書いてあった。
まあ、ソフトにおいては、現状そうなっているけど（アプリなんかが典型例）
そのうちハードも、そうなってくるんでしょうね。
情報処理の２月号
にある、デジタルファブリケーションなんかも、
試作機を作るのに、貢献していたりする。
今後は、特に、ロボットなんかは、そういうものが出てくるんじゃないかなと思う。
同人ロボット？
博士号取得者の就職状況
http://www.slideshare.net/subhjap/ss-3247345
によると（以下太字は上記スライドより引用）
博士課程修了者の６２．９％（１万人）が就職者している
逆に言うと、３７．１％が無職・・・ヒッキー？
あ、ただこの数字・・・
産業別では「教育，学習支援業」が３３．７％，「医療，福祉業」２３．７％，「製造業」１６．３％等の順
（中略）
※専門的・技術的職業従事者とは「教員」２４．９％，「医師，歯科医師，獣医師，薬剤師」２２．０％，「科学研究者」２３．９％，「技術者」１７．５％等
ってことで、医学博士も入っているので（彼等は就職するだろうから）
高めに出ているかもしれない・・・
ちなみに
修士課程修了者の就職者は７４．８％（５万５千人）。就職率は７５．１％
シリーズ化してしまいつつある
情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
今日は、アカデミックで信じられているモデルと、
最近のソフト開発のモデルから、アジャイルの必要性までを書いてみる
昨日書いたとおり、
~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf
を参考にします
（以下、このＰＤＦを、「参考資料」として
「参考資料のＸシート目」という書き方をします。シートの下の番号をさします）
■大学では、下流工程でバグが発見されるほど、
修正工数が大きいというモデルを使っている。
これは、スパイラルモデルのバリー・ベーム（Barry Boehm）が提唱したモデル。
参考資料の４４シート目に、
「ソフトウェアが出荷されてしまってから問題を
見つけて直すと, 初期設計で行うのに較べて
100倍のコストがかかる (B. Boehm, 1987)」
と書かれていますけど、まさに、このモデルを基にしています。
ということは、初期工程で要求を出し切らなければなりません。
また、スパイラルモデルを採用して、できるだけ合意をとって、
安全に開発を進めていくという考え方になります。
つまり、できるだけ、手戻りをさけるわけです。
ウォーターフォールがこの典型例です。
■大学のモデルの前提
このモデルには、実は前提があります。
・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
・開発中に環境が変わらない
もし、環境が大幅に変わってしまったら、要求段階で決めたことが
実現できなくなるかもしれないので
・開発時に結果が見通せる
要求時点で、どうなるか判らないものを、要求固めろといわれても・・
ＣＯＢＯＬのような開発では、できることが決まっていたし、閉じた世界なので、
開発環境が大幅に変わることはありませんでした。
なので、このモデルを採用しても、問題なかったのでした。
このような状態であれば、開発目標を決めて、そこへ向かっていくという
参考資料 ４０シート目の「点ベース開発」も可能です。
■今、現実は・・・
・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
→いや、インターネットの混み具合とか、はっきりしないし・・
ハード的なものは、よくわからない
なので、インターネットがらみのモノは、作ってみないとわからない
ところが正直ある。
・開発中に環境が変わらない
いや、ＷｅｂＡＰＩとかは、先方の都合でよく変わる
オープンソースを使うと、バージョンによって、結構変わるよね
・開発時に結果が見通せる
ってことで、上２つの理由により、結果が見通せない。
このような場合、作ってみないとわからないのだから、要求仕様ですべてを
考えるのは無理で、リリース直前に決めたほうがいいことになる。
そして、リリース後も、環境の変化に追随しないといけない。
ってことで、目標を決めることができず、目標は変化させないといけない。
変化に対応できるように、生物界の多様性のように、多様なものをとりあえず
作っておき、そのときにあったものを使うということになる。
これが、参考資料の４１シート目セットベース開発
■実は、Boehmは、このあと、意見が変わっている
バリー・ベームとリチャード・ターナは、このあと、「リスク分析手法」を提案し、
アジャイルでいくか、ウォーターフォールでいくかの判断について書いている
（たしか、Balancing Agility and Disciplineだったかな
日本語訳はたしか、「アジャイルと規律」だとおもう）
で、アメリカでは、教科書が変わっている。
Roger S. PressmanのSoftware Engineering: A Practitioner's Approachでは、
（昔からの）ソフトウェアは死んだとして、アジャイル話がかなり書いてあるんだけど、
日本の大学が参考書として使っているのは、この本の古いバージョンの翻訳版で、
西先生とかが訳している
実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識
だとおもった。こっちには、そんなことが出ていない。
つまり、ソフトウェアを取り巻く環境が古くて、それって、アメリカでは
修正がかかってるんだけど、大学の先生は、今も使い続けちゃってるんですねえ・・・
そうすると、「要求はしっかり決めましょう」とか「ＭＤＡ」みたいなことが
できると思ってしまうわけです。
・・・かなり、差があるでしょ？
ただ、参考資料の４４シートの話は、こういう風な流れにはなっていない。
つまり、もう一つのお話がのこっているんだけど、それについては、またこんど。
情報処理における学会と産業界というのは、かなり距離がある。
したがって、２つの間に関連性がありながら、
学界的に「それは違う」と排除してしまい、
産業界的にも、学界的にも、豊かな研究分野・実践を
踏みにじってしまうことがある。
今日は、アカデミックで信じられているモデルと、
最近のソフト開発のモデルから、アジャイルの必要性までを書いてみる
昨日書いたとおり、
~ トヨタ カンバン方式に学ぶ ~
ITシステム開発・管理への適用と実践技法
2. リーン・ソフトウェア開発
http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf
を参考にします
（以下、このＰＤＦを、「参考資料」として
「参考資料のＸシート目」という書き方をします。シートの下の番号をさします）
■大学では、下流工程でバグが発見されるほど、
修正工数が大きいというモデルを使っている。
これは、スパイラルモデルのバリー・ベーム（Barry Boehm）が提唱したモデル。
参考資料の４４シート目に、
「ソフトウェアが出荷されてしまってから問題を
見つけて直すと, 初期設計で行うのに較べて
100倍のコストがかかる (B. Boehm, 1987)」
と書かれていますけど、まさに、このモデルを基にしています。
ということは、初期工程で要求を出し切らなければなりません。
また、スパイラルモデルを採用して、できるだけ合意をとって、
安全に開発を進めていくという考え方になります。
つまり、できるだけ、手戻りをさけるわけです。
ウォーターフォールがこの典型例です。
■大学のモデルの前提
このモデルには、実は前提があります。
・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
・開発中に環境が変わらない
もし、環境が大幅に変わってしまったら、要求段階で決めたことが
実現できなくなるかもしれないので
・開発時に結果が見通せる
要求時点で、どうなるか判らないものを、要求固めろといわれても・・
ＣＯＢＯＬのような開発では、できることが決まっていたし、閉じた世界なので、
開発環境が大幅に変わることはありませんでした。
なので、このモデルを採用しても、問題なかったのでした。
このような状態であれば、開発目標を決めて、そこへ向かっていくという
参考資料 ４０シート目の「点ベース開発」も可能です。
■今、現実は・・・
・下流工程の問題は、上流で（適切なコストを支払えば）見つけられる
→いや、インターネットの混み具合とか、はっきりしないし・・
ハード的なものは、よくわからない
なので、インターネットがらみのモノは、作ってみないとわからない
ところが正直ある。
・開発中に環境が変わらない
いや、ＷｅｂＡＰＩとかは、先方の都合でよく変わる
オープンソースを使うと、バージョンによって、結構変わるよね
・開発時に結果が見通せる
ってことで、上２つの理由により、結果が見通せない。
このような場合、作ってみないとわからないのだから、要求仕様ですべてを
考えるのは無理で、リリース直前に決めたほうがいいことになる。
そして、リリース後も、環境の変化に追随しないといけない。
ってことで、目標を決めることができず、目標は変化させないといけない。
変化に対応できるように、生物界の多様性のように、多様なものをとりあえず
作っておき、そのときにあったものを使うということになる。
これが、参考資料の４１シート目セットベース開発
■実は、Boehmは、このあと、意見が変わっている
バリー・ベームとリチャード・ターナは、このあと、「リスク分析手法」を提案し、
アジャイルでいくか、ウォーターフォールでいくかの判断について書いている
（たしか、Balancing Agility and Disciplineだったかな
日本語訳はたしか、「アジャイルと規律」だとおもう）
で、アメリカでは、教科書が変わっている。
Roger S. PressmanのSoftware Engineering: A Practitioner's Approachでは、
（昔からの）ソフトウェアは死んだとして、アジャイル話がかなり書いてあるんだけど、
日本の大学が参考書として使っているのは、この本の古いバージョンの翻訳版で、
西先生とかが訳している
実践ソフトウェアエンジニアリング-ソフトウェアプロフェッショナルのための基本知識
だとおもった。こっちには、そんなことが出ていない。
つまり、ソフトウェアを取り巻く環境が古くて、それって、アメリカでは
修正がかかってるんだけど、大学の先生は、今も使い続けちゃってるんですねえ・・・
そうすると、「要求はしっかり決めましょう」とか「ＭＤＡ」みたいなことが
できると思ってしまうわけです。
・・・かなり、差があるでしょ？
ただ、参考資料の４４シートの話は、こういう風な流れにはなっていない。
つまり、もう一つのお話がのこっているんだけど、それについては、またこんど。
アクセス
トータル
ランキング
