  |
はてなキーワード: ボトムアップとは
http://anond.hatelabo.jp/20150807092025
『とっても美味しいです！』
6畳程の小さな店に響き渡る様に叫んでしまったことがある。他のお客さんがいるのに。
そんな高給取りじゃないけど、一人暮らしだと全く困らないくらいの収入があって、都心にすんでて、女性にモテたいからちょっとこじゃれている店を廻って、dancyu読んだり、肉を美味しく焼くためにcooking for geeksとか読んでるとさ、なんとなく「美味しさ」って何かわかってきた。ような気がする。
好きな異性と一緒に食べると美味いっていうのは間違いないけど、間違いだよね。
セックスのことばかり考えてたらそりゃ味もわからなくなる。今目の前にある飯なんてどうでもいいんだもん。相手の女の子がどこに住んでで、何時終電で、今食べる場所から徒歩5分以内にちょっと薄暗いけれども気後れしない程度のBARがあって、そこからホテルまでどう移動するかを相手にストレスなく完遂することが重要だから、味なんてどうでもよくなってしまう。
そら何食べても”美味い”以外の感想ないよね。
冒頭の叫びは、創作フレンチのお店なんだけど、いままで食べたことがなかった旨味だった気がする。それが最初から最後まで綺麗に整えらていて、ストーリーがあって、ワインがべらぼうに美味しくなって、もう何食べてるかわからない状態だった。
そこのお店は食べログではそこまで評価が高くないから、その旨味、味付け、コスパが気に入らない方たちがいらっしゃったようだ。
だけど俺は連れて行く女の子を変えても、セックスできるか微妙な子を連れて行っても、全然そのお店の味は『とっても美味しい』。
んで、気に入って年に何回か食べに行く。
そこくらい美味しいお店がないか、探す。
そうすると、味覚がボトムアップしているのに気がついた。
今まで”そこそこ美味しい”と思っていたものが”あまり美味しくない”になる。
一番味覚のボトムアップを感じたことが、母親の料理がそんなに美味しいと思わなくなったことだった。
母親はどこかで料理の修行をしたことはないけど、高校生の頃から家族全員のご飯を作ってきた人らしく、俺が友人を家に連れてきて母親が食事を振る舞うと、全員もれなく絶賛していた。俺も美味いと思っていたし、他のお家で頂くご飯とか、彼女の手料理が自分の母親より美味しいと思ったことがなかった。
それが久しぶりに実家に帰る。母親嬉しい。ご飯張りきって作る。
なのに”美味しい”から、”そこそこ美味しい”になっていた。
表現としては、深みがないというか、ボディが弱いというか。
なんか食べてて物足りない気がした。
味が薄いということもないし、変な雑味があるわけでもないんだけどね。
安心の味付けで、懐かしいという感情は変わらないんだけど、口の中ではどうも『うぅん？』という、物足りなさを感じた。
その物足りなさを感じたとき。
『おいしい』がわかると思うと、俺は思う。
逆だよ。
メリットというのはお金がキチンと手に入ることで、デメリットは不安定さやコケた時の悲惨さ。
（ダメ出しだけだと何なので、後でそのアイデアに載る形の話は広げるけど、まずツッコミからね）
これを繰り返し、当たるまで続ける。当たったらキャッシュが入ってくるので、現場の単価を上げていき、人材を囲い込む。次作の制作。以下繰り返し
多分気がついてると思うけど、これ売れたの100本だった時、2万1600円だよね。
マイナス597万。一本目で潰れるところ多数だと思う。
600万円ｘ当たるまでの本数、延々と赤字が続く。
そもそも金払わないと動画も受け取れないので、「先に」金が必要になる。
で、資金はクラウドファンディングで募るって言ってる所に矛盾があるけど、
クラウドファンディングに出資する人達も216円払うの？
そうすると「クラウドファンディングに出資する素人」＋「それで出来たアニメを買う素人」を確保する必要がある。
ここまで行くと判るだろうけど、だったら知財を手放して、製作委員会方式で金だけ貰ったほうがメリットが大きい。
そもそも論として、邦画アニメ崩壊のXデーが近いっていうのは、散々言われてる通り単価が安いから。
キチンと賃金を確保した上で、やり方を考えるという、積み上げ式にならないといけない。
そうやって考えると、同じアイデアでも、真逆の考え方をしないといけない。
動画が12人月で111万「だから」アニメは崩壊するって言われてるわけだ。
原画マン候補の動画マンを2年、原画、何れは作監という流れに乗せる。
動画月産500枚は、20日働くなら日産25枚。1時間3枚を8時間延々と続けられる必要がある。
これって、アガリに近い状態で、原画に行けるぐらいの「継続して持続可能枚数の限界」に近い。
そうやって考えると、最初1年は月産250枚、2～3年目で500枚ってところで、平均で考えて350枚程度が基準。
さらにフリーランスなら最低でも年収300万という状態でないと継続して人が来ないだろう。
これをまず土台にして、積み上げないとダメ。
そうすると、アニメ1回分やって動画枚数3500枚なら、10人月の動画マンを「雇える」。
まともな雇用を生み出さないのであれば、ブラック一直線ゴールは崩壊だから解決しない。
単価715円、動画月産350枚で1人動画マン養成できると考えると、これを最低2年は継続しなきゃイカン。
新規の手法に全力で行けるところはないだろうから、月1回アニメってのはラインとしてはアリだと思う。
こうすると、月1回アニメ、動画3500枚、動画マン10人を養成できる。全24回、2年。
で、原画も月産50枚が継続限界値とすると、同じく月35枚程度を基準に考えるのが無難。
原画を雑に350枚（若しくは増えた分は単価から削る）とするなら、月10人原画マンを雇える。
で、以後面倒だから繰り返さないが、要は関わる人間全員が年収300万確保できるようにしないとイカンのよ。
まあ、4人とかちょっとどうかと思うが、新人育成の為と思って我慢してもらって月25万。
制作進行は、後で述べるクラウドファンディング周りの事務方も兼用な。
まあ、どう考えてもアニメにして声無しは厳しい。
アニメ(ーター)見本市で２人で回してるけど、うーん。無理じゃないか。
動画マン10人、原画マン10人、声優4人、その他5人。計29人。月725万
まだ人件費だけな。
機材家賃交通費諸経費諸々限界で月50万ってトコだろう。月775万。
クラウドファンディングだって無料じゃないから、手数料諸々込みで10%載せて、月850万は集めたい。
月850万を、2年間継続してクラウドファンディングで集め続けるんだぜ。
総計2億4百万。ここまで行けば、後続もついてくるし、関連グッズも売れるだろ。
要は、いかに金を集めるかがポイントで、それで「年収300万円の動画マンを雇う」のが全て。
関係者全員が年収300万円状態のプロジェクトなら、たぶんガンガン人が集まるからそこは心配しなくて良い。
サラッとクラウドファンディングとか書いてたけど、そこの「集金」がほとんど全てだよ。
でさ、この29人がまとまって頑張るために金を集めるっていうのは、まんまスポンサーを探してアニメ作るのと同じな。
そこが難しいし金出す側からすると旨味が無いから、製作委員会方式になったわけで。
逆に言えば、「新作アニメが月1回分見られれば500円出しても良い」ってヒトを1万7千人集められれば、行ける。
日本のアニメを崩壊させないために、2年越しのプロジェクトで月1回だけアニメの新作が見られます。
それに1万2千円出してくれるヒトを1万7千人集めてやっと、10人の動画マンを年収300万円で雇える。
しかもこれ概算で、たぶん手弁当でももっと金かかるんだよね。しかも儲けは関連グッズ頼み。
面白いかどうかもわからないアニメに、先に1万2千円出すやつを2万人近く集められるかな。
それでもすべての基礎になる動画マンはたったの10人しか雇えない。
どうよ、資金出してくれるトコ探すの難しいの判るだろ。
アニメを作るのが難しいんじゃないのよ、先立つモノが無いのよ。
（しかも、製作委員会側からすると、上の単価の1/3程度でいくらでも代わりの制作会社がいる現状よ）
要はインフレ進めて行きましょうって話だよね。
目新しい話じゃない、いまの政府もだいたい同じ方向だとおもうけど。うまくいってないだけで。
どっちかというと
最低賃金が枷になって人を雇えなかった分野、林業とか農業とかで雇用できるようになる。
街中でもいままで1人しか雇えなかったところが2人、3人雇えるようになる。
国全体でみれば相当なものになるだろう。
人件費を圧縮できるので、物価、サービス料金の低下も見込まれる。
いまでもエブリデイロープライスで1000円あれば3食賄うに充分だし、地方なら月3万で住む家も見つけられる。
働き口に困らない、わずかなりとも収入が途絶えないって前提があればチャレンジへの敷居も下がるだろう。
ボトムアップで社会の流動性が高まれば、それは利益率高い分野にも波及する。
問題としては
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
さいきんのゆとりは、と言われそうなので、三十代半ばと年齢を先に申告しておく。
試験にノートを持ち込めるわけでないし、教科書に書いてあることを黒板に写して、それをノートに写すなんてどうして？と思ってた。
流石に、大学では「データを残すために」紙に記録することにしたけれども、紙に書くことが理解の助けになるとか、記憶の助けになるとは思わない。
忘れてしまうことはノートやメモに残すけど、忘れてしまう前提だから残すのだ。
逆に、アウトプットのために、紙にかくことはとても有用だと思う。
文章を作る前、数式をたてる前、スライドを作る前、出来上がりのイメージを図にしてから始める。
あれをつくるためには、この順番で組み立てて、それぞれの部品はこうやって表現して、そのためにはあれが必要で、ということを考えるためには、紙とペンはとても有用だと思う。
学校教育では、アウトプットのための紙とペンの使い方をもう少し教えた方がいい。
と、ここまで書いておもったのだが、僕の思考は、まずはアウトラインを決めて、そこに合うように部品を嵌めこむ「トップダウン型」だ。
対して、学校教育は往々にして、知の積み重ね、「ボトムアップ型」だ。
たとえば、乗法の交換法則の証明を終えてはじめて、掛け算の順序問題から開放されるというように。
それはある意味では正しいと思うんだけどね。
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
今更だけどガッチャマンクラウズ見たので感じたことを書きたい。(ネタバレ注意)
このアニメは登場する主要なキャラクターがそれぞれに異なる正義観というかポリシーみたいなものを持っていて、それぞれがいわゆる典型的なヒーロー像を象徴していたように思う。
今回はそういった個々のキャラクターは置いておいて、大筋のストーリーから勝手にメッセージを読み取ってみる。
ガッチャマンクラウズには典型的な正義観を持った2つの陣営が登場する。それはガッチャマン陣営と爾乃美家累である。ガッチャマン陣営(はじめ除く)は各々の考え方の違いはあれど基本的には勧善懲悪的なスタンスである。一部の優秀な人間がその他多くの言ってしまえば愚かな民衆を導く必要があるという考え方を持っている。それに対して累はヒーローは社会に必要ではなく、民衆全体の働きかけによってより良い社会を実現しようと考えている。しかしこの理想は性善説的な考え方に大きく寄与している。
ここにはじめとカッツェといういわゆるジョーカー的な存在が登場する。2人はこれら2つの陣営にそれぞれの正義観に対する不備を突きつける。
はじめは何事に対しても先入観なくフラットに接し、自らの価値判断基準に則って行動することで今まで悪だと思っていた存在がそうでないこともあるということを突きつけた。一部の優秀な人間が舵取りを間違えたらあかんよねという事例である。カッツェは累に対してあえて困難な状況を作り出し、自らが与えた力を使わなくては結局民衆による正義など実現できないという矛盾を突きつける。更に後半はGALAXとNOTEを累から奪うことでクラウズを使って人間の性悪説的な側面を増幅させる。これは民衆による正義は結局易きに流れる為不可能と象徴的に示しているといえる。
はじめとカッツェによる引っ掻き回しによって2つの陣営共に自身の正義観を変容させていく。ガッチャマン陣営は清音を筆頭としてはじめを受け入れることで、一方的に先導するだけが正義ではないということを理解してく。累については人々の内発的な動機による助け合いではなく、社会の仕組みによって外発的に動機づけを行うことではじめて理想の社会が実現できると考えを改める。以前の累は多くの民衆に対して自身の正義観を押し付ける側面が少なからずあった。それはHUNDRED No.26 梅田 光一を説得する場面からも読み取ることができる。人々が内に秘める助け合いの精神を信じていた結果としてそのような正義の押し付けにつながっていたといえる。それが最終的には各個人の考えを矯正するという発想をやめ、システムとして人を誘導するという発想に至る。「立川市で何をするかはみんなの自由」という発言は、人の性善説的な側面を無批判に信じて出たものではなく、民衆を正しく先導する覚悟を決めての発言であったんだと思う。
インターネットの普及、ソーシャルネットワークの出現によって今まで以上に群衆の声、力が大きくなってきた社会は、特定のリーダーが多くの群衆を先導するには複雑すぎる。そういった状況の中で現代社会はどうあるべきか？それがこの作品を通して伝えたいテーマであると思う。
恐らくあのラストで表現したいことというのは、「荒らし」をするような人たちは規制や否定ではなくならないということ。（殺さない・殺せない）自分たちが世界の楽しみ方（ゲーミフィケーション等）をみせることでしか、変えることができないということではないでしょうか。
世界をポジティブに捉え、行動したほうが合理的と思わせるような体験を見せることでしか、変わらないということを言いたかったのではないかと思います。
http://d.hatena.ne.jp/loki16185/20130929/1380428729
この疑問に対して作中での答えはゲーミフィケーションであり、人間が本質的に易きに流れる生き物であるならそれを肯定し、社会全体としてより良くなる方向にインセンティブを与えることでボトムアップに社会を運営していこう、という発想である。ガッチャマン陣営と累がはじめとカッツェにそれぞれ自分たちの正義観の不備をつきつけられ、互いに価値観を共有し合ったことでこのような発想に至ったと考えられる。
しかし、この考え方には未だ危険も潜んでいる。インセンティブを与える基準、いわゆる「いいこと」の評価関数の決め方次第では結局正義の押し付けになってしまう。この評価関数の決め方という部分まで踏み込んではじめてこれからの社会の正義のあり方という問題の答えになるのではないか？と感想を抱いた。
学生と知って一気に萎えたんだけどがんばるぼくえらい。うそ。書類待ちでひまなんだなう。
＞どういう設計が正しいと言えるのかよくわからないです。何を根拠にそういうことが言えてるのか。
絶対的に正しいことなんてねえよ。人生設計の正しさに根拠や保証が欲しいの？悪いけどそんなものないよ。
100万人が選択した人生だから正しいと思うのか？それって当事者意識薄くない？
誰かが答えを運んできてなんかくれないよ。お前が自分で探して自分で受け入れるしかない。
個人的に言えば、死ぬときに自分が幸せだったなーって思える人生が正しい設計だと思うよ。
んで、幸せとは何を考え続けるのが人生なんじゃねーのかなあ。と思う。
＞私はなんで親の勝手な設計図で子供が手順通りに成長すればそれが良しとされるのか、それを親が良しとするのかが理解できないです。
良しと判断してるのは誰？お前がイメージしてる「世間の人」が言ってるんだろ。手順通りに成長すればよしとはされないよ。てか手順ってなに？
設計図って何？そんなトップダウンのものなんてないよ。子育てはボトムアップでの積み重ねだと思うよ。
なにお前って、自分がセッティングした合コンがうまくいってカップル出来ても、ダメだ！修羅場がないからダメだ！って言うタイプなの？
親が良しとする理由を言ったんだよ。念のため。
＞えー。それはすごいですね。頑張ってください。
自分が納得出来ないならその根拠を言えよｗｗｗ自分だけ根拠求めといて自分は曖昧にするとかｗｗｗ
＞これね。ポケモンですか... 育成ゲームあるしそっちでいいんじゃないですかね。
本気で言ってるの？または現実とゲームを同一視するほど現実世界に居場所がないの？
おまえ設計図とかゲームとか”誰か”に作られたものを信じ過ぎだし、常に使用者だったり消費者の立場でしか物言えないのな。
子育てを育成ゲームと同等にしか考えられないのが若さなのか？はたまた単なる想像力の欠如か。
＞親のこと喜ばすのに子供作る他ないんですかね。
なんでこの文脈で他のこと書く必要あるんですかね。
＞あとセックスに関しては、気持ち良いですし快楽目的でならご自由にしてもらって構わないのです。
童貞乙ｗｗｗｗｗという煽りしかできないごめん。そこはかとない上から目線ありがとうございます。自由にさせていただいております。
多少書けるけど絶対に「プログラマです」とは名乗れないゼネラリストたちで構成されている会社。
そんな会社だと、プログラムでなるべく解決する（コードが業務プロセスを頑張っちゃう）ために頑張るよりも、
業務プロセス・開発プロセス全体で最適化するよう頑張った方が、
プログラムで頑張ろうとすると、
外注するのに設計しようにも結局学習コストがかかりすぎるとか、
外注が逃げるとか、
引き継ぎ先がいなくて死ぬとか、
そんな余計なことが多かった。
反復性・正確性が求められるものはプログラム化に適しているけれど、プログラムは解決の一手段だし、一分野にしか過ぎない。
ともすればプログラムのスペシャリストでないことに大きなコンプレックスを抱くけど、
生産物が割合ライトで公共性も低い（例えばエンタメ系スマホアプリ）だったら、
身の程わきまえて、他の業務パラメータも見て総合的に結果を最大化しようというシンプルな結論に至る。
オブジェクト指向の本を読むのも結構だけど、もっと大きな見地から比較して
ライトなフレームワークを選択して、ライトな開発プロセスでやる選択がもっと歓迎されていいと思う。
そして、アジャイルとかTDD/BDDとかももちろんいいんだけど、開発現場からのボトムアップ的な思想やツールでなく、
マネジメント視点や経営視点から自分たちがライト層として開発するなら、という発想がもっとあっていいと思う。
元プログラマが経営層になっての話は近年よく聞くけど、非プログラマが経営層でかつ開発もある程度やるよ、というスタイルもそれなりにあるのに。
こういう情報が出回りにくい理由は、そもそも人数が少ないか、文章に書く魅力/余裕がないか、文章化が難しいか、まだ分野的にこなれていないか、のどれか。
暇ができたらまとめたいなあ。。
その前に売上UP（白目）
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
http://ascii.jp/elem/000/000/643/643497/index-2.html
↓はその通りだと思う。
このような日本の新陳代謝とグローバル化の遅れの背景には、日本企業の組織特性がある。日本の製造業が戦後、高度成長したときは、欧米の技術をまねて、低賃金で生産することができた。
「首相の決断」により郵政民営化も、原発の上からヘリで水を撒く事も出来た。首相レベルの決定権は今も強大なものが有ると思う。
官僚が優秀であるとはいえ、ここを縦横無尽に使いこなせるような立場にある政治家など近頃では皆無に見えてしまう。
誤解を恐れずに言えば、なぜ決定権を持つ人間が決定できなくなってしまっているのかというのが、
現状の「女性の風潮」に逆らえない
婚活に勝ち残らなければならず、
村のようなコミュニティは破壊されたので一人で子育てせざるを得ず、
旦那の給料を【未来永劫として確固としたもの】に仕上げさせなければならないプレッシャーが有り、
ご近所様からも【ちょっと上の立ち位置を築かなければならぬ】プレッシャーすら有る中で、
まだ高度経済成長期に築かれた【幻想・成功神話】を再び旦那に具現してもらわなければ困るのであり、
ゆえに日本社会的に【挑戦】してもらっては困る世界が出来上がる。
（近所やら知り合いに偉そうに出来なくなるから）
「寝た子を起こさない」発想から「協力」というコミュニケーションとして高い次元へ進まなければ
今、勝ち組でも10年後に負け組と同一の立場に置かれてしまうかもしれないという算段を持って今後の方向を検討出来る場が欲しいと思う今日この頃でした。
協会や代表の発端について言えばボトムアップだったのかもしれないけど、
Jリーグに関して言えば、プロ化の主目的は「試合レベル向上による代表強化」だったし、
クラブも元々サッカーの文化があまりない所に町おこし目的で設立した例も多いから、
どちらかといえばトップダウン的に進められてきた部分のほうが大きいと思う。
スポーツ日本代表って、そもそもはまず最初に国内各地でプレイする競技者たちがいて、地域や国内でのスポーツ活動をとりまとめる協会みたいなのが生まれて、
そこから国内にいる強い選手が選出されて代表になって、みたいなボトムアップ的なもんだと思ってたんだけど、違うのかな？
つまり、身びいき感情とか我らが代表となるチームを作るとかそういうモチベーションから成立したというよりも、
海外に行かないとプレイできないってのは競技者にとって不便だしファンも観戦しにくいので国内スポーツ界があり、その頂点たる代表があるんじゃないのかな、と
アホな家庭やアホでなくても放任しきりな家庭にゲームがあると子供は際限なく勉強もせずゲームをするし、友達が家に上がりこんで何時間もゲームってのはあるんだよね。
特にゲーム以上の娯楽を見いだせない、はてなのみなさんが差別目線を隠そうともしない「低偏差値」な層に多い。
で、ゲーム自体が有害ではなくとも、そういう親の教育なり友人関係において不全である状況ってのを放置するのはよくないことだと思う。
パチンコ中毒も似たようなもんで、時間だけ浪費する分ゲームのほうがまだマシだとは思うけど、突き詰めれば違いはそこしかないと思う。
ボトムアップ的な目線で公教育なり高等教育の重要性を主張する人ってはてな内外でそれなりに見るけど、彼らの主張って自制心ある家庭とかが前提なんだわ。
つまり彼らは端から本当に底上げすべき家庭は無視している。
で、そういう家庭を底上げしてはじめてボトムアップと言えるんだけども、彼らはそれを放棄しているからやってることは不安商売のそれと同じ。
そういう形骸化した家庭を無視して、それなりに機能している家庭にばかり「底上げは大事ですよー」なんて声かけたって聞こえるわけねーだろばーか。
というわけで、僕個人としてはバカの底上げのために娯楽は規制すべきだという立場を取ります。
エリートで、みんなが嫌がる勉強さえ好きになれたり好奇心を持って取り組めるはてなーのみなさんに置かれましては、たかがゲームパチンコ規制されたぐらいで娯楽には事欠かないでしょうから、そういう悪平等を甘受いただきたいですね。
いや、「そこまで糞な環境の家庭はもう無視して構わんよ。自業自得。甘え」という立場のみなさんにまで強制はしません。
ただ、先に挙げた家庭モデルってのは、お受験のない学校ではごく当たり前のケースだってことは理解してください。まあ数にして全世帯の半数以上でしょうか。
中学校では、
また、情報高校を新設し、
C言語やエクセルVBAを通したさらなるプログラミングの奥深さ、また、情報学など、より高度な情報分野への学習をする。
まず、IT業界というのはそれ以外では喰っていけない、職人のようなものである。
しかし、そこに多くの人材がたかだか四年程度の情報科を出て、すぐ戦力に回される事態である。
それが僅かな人材で高度なことをするエリート的なものではないのが、問題だ。エリート的な少数精鋭なら、学部教育で間に合う。
そこで、ボトムアップをしなければならない。
小中9年間の教育は大変重要であり、その9年はとてつもなく長い。
その9年で少しずつ今の高校情報レベルまで押し上げ、高校からは完全に専門的な学習へ移行させるのだ。
教員は情報教員枠として小学校から専属の、必修の社会人経験を積んだPGやSE、SIerが受け持つ。
つまり現場のノウハウをもとに実用的な教育ができるということだ。
私の提案したプログラムじゃ駄目だろうが、必要なことであることは間違いないので、ぜひここを見ているカンリョーさんは検討いただきたい
参照URLが間違っていたので返信されていたことに気づかず，
気づいてそうか納得できないかーと思っていたら，こちらですでに納得していたんですね．
これまた参照URLが間違っていたので気づかず．．
すでに納得できたようなので特に返信することもないのですが，
質問の回答を書いてしまったので貼り付けておきます．
GTDについてはあんまり良く知らないのでなんとも言えませんが，
こんな風に書いているので，人生の目標をGTDで探すのは不適切なのでしょう．
http://bizmakoto.jp/bizid/articles/0812/31/news002.html
しかしデビッド・アレンさんはここで彼の経験に基づくアドバイスをしてくれています。それは「日々の仕事を片付けられないと、将来の目標など見えてこない」というものです。日々仕事に追われていたり、ストレスにさらされていると将来のビジョンは描きにくくなります。疲れた頭では自由に未来を創造することは難しいでしょう。日々の仕事をコントロールする術をまずは身につけることによってのみ、トップダウンのアプローチが可能になるのです。
将来の目標や価値観について考えをめぐらせることは悪いことではないですが、ボトムアップから始めたほうが結果的に自由な思考が可能になるかと思います。
やるとしたら，おそらく「人生の目標を探す」というプロジェクトを登録し，
次のアクションとして「○○を読む」「○○について考えをまとめる」とか登録するのではないかと．
具体的に将来の目標を考えるための手段としては他の方法を試すべきなのでしょう．
下記は目標達成可能性最大化を実践している知り合い（東大卒）から薦められた本です．
「２０代から始める」とあるので，受験勉強の邪魔にならない程度にどうぞ．
よく自己啓発系の本とかを読むと目標をたててそれに向かって行動することが重要だと書いてあります。成功者の本とか読んでも大体同じようなこと書いてあるし真理なんだと思うし、特に疑う余地はないと思っています。
僕も実際に中長期の目標を立てるということは以前からやっていたのだけれども、何かうまくいかないというか、なんで自分はこの目標を達成するためにがんばってるんだろうという気持ちがずっとありました。
そういったことをお皿を洗いながら考えたとき、ふとその理由を説明できるロジックにいきつきました。
それは、人が目標をたてるときに中長期の目標や、今日一日の目標、もしくは人生の指針とかも含めて色々あるけど、それらをボトムアップしていって最後にいきつくところは全部一緒なんではなかろうかということ。
結論からいうと、人の目標というのは「人生を楽しむ」というところにいきつくのではないかと思ったのです。
目標をボトムアップしていった結果これが最後にあるのではないかと。「なぜ人生を楽しみたいのか」という質問は存在しないのではないかということです（人生を楽しむことを諦めていたらそもそも目標とかたてないという見解です）。何を当たり前のことを思う方もいると思いますけど、以外とこれは気付いてなかったなと思いました。
これを説明するには、中長期の目標や願望を探してそれをボトムアップしていくとわかりやすいです。
例えば、僕は4年くらい前に社長になりたいという目標をたてました（このころは目標というよりは願望だったかもしれません）。でもそれ以上のところは何も考えてなかった。つまりなぜ社長になりたいのかという理由が説明できなかったんです。だから現実みもなくてあまりその目標に対して真摯になれなかったと思っています。
でも半年くらい前になぜそうなりたいかという理由を説明できないとダメだなということに気付いて、人生のビジョンというものを立てました。自分の人生はこうでありたいという指針です。それは中長期の目標や願望を元に考えます。僕なら、なぜ社長になりたいのかということです。もちろん願望はそれ一つではないですから、願望を洗い出して3つの人生のビジョンを立てました。
すべての目標はこれに向かってなければいけないし、行動もこれを基準にすることができます。で、さらにこれをボトムアップすると、それは「人生を楽しむ」というところにいきつくのえはないかと思ったのです。そしてそれはほとんどの人にとって同じなのではないだろうかと。何を楽しいと思うのは人それぞれ違うでしょうから、ここで例としてあげたビジョンというのは人によってかわってくると思います。
目標を持ってない人や、目標を立ててもいまいちしっくりこない人は、自分は何をもって楽しいと思うのか考えてみるといいかもしれません。僕は欲張りなので仕事もプライベートもどっちも楽しくして、さらに人から「この人はすごい！」と思われたいという願望があります。
人によっては家族が幸せであれば仕事はなんでもいいという人や、大企業の社長になって日本を牛耳りたいという願望の人もいると思います。それらのいきつく先はすべて「人生を楽しくする」ということに向かっているのがわかればすべての目標と行動を説明できるようにり、目標を達成するためのモチベーションになるのではないかと思います。
以下余談。
これを企業に当てはめるときにどうかと考えたときに、経営理念というのはここでいうビジョンに当たるのかなと思いました。例えば「よりよい製品をつくって社会を豊かにする」という経営理念があったときに、じゃあ何ために社会を豊かにしたいのか、という質問は成り立つと思うのです。その企業はなぜ活動を続けるのかという理由をもっと明確に説明できるようにならないといけないのかなと。でもそれはそれほど簡単じゃないのかな。それについては何かわかったらまたまとめたいと思います。
http://business.nikkeibp.co.jp/article/tech/20100330/213728/
先端の基礎科学ってのは収益を産み出す工学のボトムアップに必要不可欠な物だと思う。
上を目指さずに裾野は広がらないし、裾野が広がらなければより上を目指すことは出来なくなる。
様々な工業技術が発達した今の世の中で、発達したが故に頂上を見極めるのが難しい。
裾野しか知らない人間からすればそんなに高い頂上は要らないと思うかも知れないが
今の頂上を目指してきて、もっと上を目指しているからこそ裾野に大きな利益が生まれているのだ。
まあ、もっと簡単に言うと金稼げないとこなんていらないっていうなら大学も文学部や理学部なんて潰して
少しでも利益の出せる分野に人回した方がいいよね？
