  |
はてなキーワード: 仕様書とは
ボタンの位置が仕様の根幹にかかわるくらい重要なら、質問しにこいってことだよ。
せめて重要どあいについて何も考えずに、あほみたいに質問だけしにくんなってこと。
そんな時間ねーよ。必要があるなら、PG減らして仕様書作る人間を増員するわアホか。
細かい所はすべて自己判断しろ。もしくは粒度に応じて相談しろ。考えろ。空気嫁。
その程度のPGにも不備を指摘される程度の仕様書しか書けないのは駄目だろう。
というか、作ったあとで気づくってこともあるだろ。何？ そんなことも考えられない奴なの？
「できました！でも、ここの仕様だめだと思うんですよねｗ」
って言ってきたから、
それはそれで死んだ方がいい。
今回はそれを受け取って、ただ作るだけの作業者なら、
仕様書を書く人間が今より時間をかけて、外部発注に耐えうるレベルの精度高いものを出すか、
社内でコミュニケーションをとりあって、仕様書バグや認識違いを埋めていくかの違い。
仕様書どおりに作るしか能のないやつは、正直言っていらない。邪魔。外注のほうがまし。
というか、そんな人間に発注かけると、外注よりも金かかるから、死ね。
俺、PLディレクターだけど、手が足りない時はPGもやってんのね。できるから。
そんなときに、渡されるのは要件だけで、画面仕様とかは自分で作ってるわ。それでプログラム書いてるわ。
っていうか、要件すら自分で考えるわ。
お前らもそれやれ。ボタンのサイズとか位置程度で質問しにくんな。
「ここの文字って半角ですか？全角ですかぁ？」という質問を
もうなんていうか、かわいそうになったわ。
もう、そのくらいの歳で、その程度だと、死んだ方がましですわ。
たぶんだけど、「釣り合う天才」とかって考え方はしない方が精神衛生上良いよ。
あの人は、プログラマーとしては非凡だっただろうけど、むしろアーキテクトとして卓越してた。
そういう、スキルとしての評価ってのは、その他の行状から関係なくありうるよ。
でも、当然ソレとは関係なく、やらかした動機とか、やらかした結果ってのはある。
オッペンハイマーは天才だし、完璧に合法だし、当然罪には問われなかったけど、間違いなく原爆の父だよ。
でも、それが「原爆を生み出した」ことに釣り合う天才かってことは、考えても無駄だよ。
ヤツは天才だった、そして考え無しだった、
既にある技術を、知られていた方法で組み合わせるだけで、破滅的な結果になる。
ある程度の知識があれば結果は予想できるし、結構なアーキテクトならアイデアがあれば近いものは組めるし、そこそこのプログラマーが仕様書受け取りゃ実装できる。
でも、あの速度で全てを兼ね備えてたってのは、まあ最近はあんまり居ないよ。
そして、やらかしちゃった人も。
業界に破滅的な結果を与えた極悪人、考え無しの技術者、そういう評価で十分。
本当の意味でのマッドサイエンティストだったんだよ。
客だから（ｗ）なんでもいいよ。
仕様書間違ってても、話し合いながら何とかするし。
今までの客の中で困ったのは、機能ブロックAは１０ページ目ぐらいに書いてあるんだが、その特殊動作が１００ページ目ぐらいの機能の注釈に書いてあって、漏れたケースだ。
注釈的な細かい機能をまとめずにいろんな場所に書くのは辞めてくれ。
機能ブロックの実装しなきゃいけない機能一覧は その機能ブロックの説明の中にまとめてくれ。 他の機能ブロックの説明で機能ブロックAにこの機能を追加！とだけ書かれても困る。
わかる。
プロフェッショナルじゃないくせに、要件定義の段階で仕様書とか作ってきちゃったりするんだよな。
いきなり仕様書つくってきれ、これ作ってくださいとかって、
運用が始まってからの問題は、保守に入ってくれてれば、程度に応じて保守費用もらって修正するし、
保守にも入ってないし、追加予算もない、発注した時の仕様書にも書いてないなら、直せないで終了。
それが、下請法でもなんでも法律的に守られてる下請けのルール。
言い方変えれば、その辺でコツコツお金貰うのが下請けでは？ 人によっては発注したつもりという人もいるけど、つもりは文章になってないからダメです。という話で
それで裁判にまでなった仕事も世の中には沢山あるけど、 つもりだった・・・は大抵の場合 ナンクセだからな・・・営業さんに任せるに限る。
だからこの業界、ちゃんと文章を取りかわせって話になるけど、契約した仕様書に書いてある範囲で納めて、それ以後は追加料金なのはもういいかげん、当然だとお客さんに思ってほしい。
ある程度はそういう自体に備えて、バッファ持ってるけど、ある程度以上は無理。
この辺の特徴を求めててTypeScriptが近いということなら，今は亡きECMAScript4の仕様書とか眺めてみるとおもしろいにはおもしろいんじゃないかな．誰にも処理系作れねーよ！って（というか政治的な事情とかいろいろで）お蔵入りになったから実装ないけど．
お客さんと話してきた内容を人ごとのように聞いているのだが、
先日拾ったフルスタックエンジニアと何となく繋がったところがあったので
暇つぶしに書いとく。
DBの不備と拾いきれないぬるぽで正常系すら落ちまくるシステムへの不満と
画面の統一感がチグハグで分かりづらいという二点で、
そんなシステムをこの人数の規模(想定より遥かに多かったらしいw)でやられてたんですか？と
いう言葉までいただいてきた。
当然だよねーと思う。仕様書も統一されてなくて、画面のデザインガイドラインも一読しないまま
各工程で30%ずつ人員を入れ替えながら突き進んでしまったそうだから。
そのしわ寄せがプロジェクト後半になって鎮火のために投入された自分のようなところに来る訳で、
チームで古参と思われる人に画面仕様について片端から聞いても見事なたらい回し。
入力項目の不備について指摘したら、それjQueryのライブラリの仕様だから中に手を入れてまで直そうか
今の状況では微妙って回答を貰った後で、客先から同じ指摘→再テストの依頼が来たときはいらっとしたわ。
なんでこーんなことになってるんだろうって外野の目で見てると、分業しすぎたんだろうとは思う。
皆、JSPだったり、javascriptだったり、SQLだったり、どれか一つの言語しか出来ない感じで
フロントエンドすら、Ajaxとそれ以外(よくわかんないんだけどさ)で、二チームに別れてる感じ。
要するに、自分含めてスキルがしょぼいんだけど、そりゃ、画面のデザインもチグハグになるよねーっと思った。
フルスタックエンジニアのような、全てわかる器用貧乏で、でもチームリーダーとして仕切れるような人格者が
一人いれば、この状況はもっと違ってきたのかな、なんて。
フルスタックエンジニアがたくさんいれば、こんな分業制でわけわからない開発規模まで膨らんだプロジェクトの人数も
減らせたのかなぁ、なんて。
仕様の共通理解やそのためのツール(仕様書ね)に割くための工数もより少なくてすむわけで。
確かに、人数減らせばその分仕事も増加してブラック間違いなしなんだけど、
この状況を見ていたら、一つよりは二つ、二つよりは三つを持ったゼネラリスト的なスペシャリストがいらっしゃったら、
変われたのかもね。
まだ違和感がある。
モノを作るプロセスが分かれてる。
「こんなのが売れると思う」と言ってお金をもらっている人。企画の人間。
きつい言い方をすると、命令する側とされる側に分かれているように思う。
全体が見えてないのかもしれないけど、
なんで同じ立場のはずなのに命令されないといけないの？
「こんなのが売れると思う」そう思うなら自分で作ればいいじゃん。
なんで作れない人が作れる人に命令できるの？
作れない人が作れる人よりいいアイデアが出せる保証なんてないのに。
こういうと「ジョブズだって自分で作ってたわけじゃない」とか言われたりするけど
日本のメーカーでヒットと言えるようなものなんてここ何年も出てないでしょ。
それに創業者とかある意味自分でお金出してた人と企業に勤めてる企画じゃ立場も違う。
お金もらって「こんなの売れるかよ」って思うものを作らされるのなんて苦痛でしかない。
よく全体を見れる人が大事、とか言うけど、作れる人の方が大事なんじゃないの。
それを無理やりやるから、英語教育みたいに、テストの点数は高いのに英語が話せない。みたいな子供を大量に作ることになるんだろ。
弊害が大きすぎる。
しかも、一番怖いのは英語よりも、さらに正しいプログラミングを出来る人間は国内には少ないから、EXCELで仕様書を書くみたいな、クソ間違えた害悪なプログラミングを
一番大切な幼少期に教えかねないということだ。
才能が死んでしまう。 教えられもしないのに、無理やり、中途半端な知識でプログラムを教えるのは子供にとって害悪だ。 そもそも（地方で給料が安い）教育機関に転職するようなプログラマーが能力が高いわけがない。
優秀なプログラマーの給料は高いんだ。地方の教育機関には転職しない。 転職するのは間違った知識を持ったリストラされたプログラマーの可能性がたかい。害悪だ。
なんか、プログラマーというものを全くわかってない、教育方針だな。
10人ダメなプログラマーがいたら 一人のいいプログラマーが 会社を辞める。
義務教育からプログラミングをすることは、プログラマーとしては必須だが、それを国家がやったら、プログラマーが死滅する。
国家は無力だ。
英語教育を見てくれ、国内の英語が死滅しているだろ。 変な癖をプログラマーにつけることになる。
日本のプログラムは IT土方といわれていて EXCELで仕様書を書く みたいな クソプログラムが大多数を占めている。 そんな変な癖を 子供のプログラマーにつけさせるな。
プログラマーを絶滅させたいのか。大学レベルでもまともなプログラミングを教えられず、土方プログラマーを増やしているのに、小学校から出来るわけがないだろ。教員の数が足りなさすぎる。
あ、まず前提として、
はたして貴女を幸福にするかどうか、それはまた別問題だけれど。
ＩＴ系の超かしこい男なども多く、
多くっつーかIT系でないのにプログラミング大好き男っていうのは超かしこい学生（まぁこれは有望株）か研究者系なんか、
あとはまったくかしこくもないクセに頭いいつもりして「Lispやってます（ｷﾘｯ ハローワールドくらいですが」とか言っちゃうアホしかいないわけで、
したがって、釣り師たる女たちにとっては、
なかなかあなどれない釣り場です。
では、プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
まず最初に、その男がCOBOLのようなタイプのレガシーコードと
あとはC/C++、そして（TechEdに参加するほどではないけれど）VisualBasicが大好きな、
貴女はかれの目を見て、微笑みとともに質問など無視して、こう言いましょう、
「わたしが、仕様書を作ってあげる♪」
これこそまさに必殺の答えです。
そこでプログラミング大好き男が、えへへ、とやにさがったならば、
貴女は、ひそかに、「コピペ量産しやすい技術的ポイントを抑えた仕様書」あたりを
ひそかに練習しておきましょう。これで成功まちがいなしです。
しかし、ここでは、もう少しハイブロウな（？）いわゆるプログラミング好きの男の
落とし方をお伝えしましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
もしも貴女がそう答えたならば、
かれの貴女への恋心は、
２０％増量になるでしょう。
なぜって、Scalaは、
コンパイルは遅いながらも、そこがまた
ちょっぴりメモリを多く積めばいい富豪プログラミングみたいなふんいきをかもしだしていて。
質高くふるまっていて、なおかつ、
JVM上で動くくせにJavaが「やるやる」と言ったまま実装してなかったラムダ式と仮想拡張メソッド、型推論を実装した功績もあって。
したがってScalaこそは、
本来なんの接点もないまったく縁もゆかりもない別々の世界に生きている、
インタプリタ言語大好きな綺麗系ＯＬと、玉もあれば石も混じっている、そんなプログラミング大好き男たちが、
この世界で唯一（いいえ、JVM系列のJRuby、Clojure と並んで唯三）遭遇しうる場所です。
●
では、参考までに、危険な回答を挙げておきましょう。
プログラミング大好き男に「どの言語が好き？」と訊ねられたとき、
「MicrosoftのVisual Basic for Applicationが好き♪ 週３回は Excelでコーディングするの。」
特にOfficeは平凡ながら、ま、無難にまとめてあるものの、
しかし、「新UIのリボンUI！」「メトロUI対応！」とかなんとか無意味な自慢を吹聴し、
VBAはさらにプログラミングについての謬見を撒き散らした罪がありますから、プログラミング大好き男にとっては天敵なんです。
ティーガー戦車乗りのオットー・カリウスは「ティーガー乗りなら誰でも片側の履帯がはずれ僚車に牽引されて帰ってきた経験を持つはずだ」 って言ったけど
社内SEかSIerなら誰でもクソみたいな前任者が書いたクソみたいなExcel-VBAコードを直した経験があるはずなんです。
また、もしも貴女が「PHPが大好き♪ あたしが書いたPHPのWebサイトが、さくらサーバに７件あるよ♪」
と答えたとしても、同様の効果をもたらすでしょう、
なぜって、PHPは、１９９０年代にはWeb系を目指す人にとっては簡単で要件を満たすWebサイトが簡単に作れる輝きの道だったものの、
しかし２０００年代そうそうから、セキュリティ関係の問題で転落し、
いまや、あの貧弱な言語能力では、Rubyの魅力に遥かに及びません。
（注１）
「わたし、.NET FrameworkのC#が好き、フォームアプリでも書くけど、
最高に好きなのはASP.net♪ SQLServer連携も、ajax control toolkitもすっごくおいしいの。」
と、答えたとしたらどうでしょう？
なるほど、貴女の趣味は高く、
たしかに.NET Frameworkは、C# が cool であるのみならず、
.NET Framework上で動く F# や IronPythonやIronRuby、マネージJScriptも最高においしいんですけれど、
しかし、貴女の答えを聞いて、プログラミング大好き男はきっとおもうでしょう、
（なんだよ、MS信者な女だな、カネかかりそう）って。
（注２）
貴女が、プログラミングが大好きで、言語の名を挙げるにしても、
たとえば、JavaScript(node.js)ならば安心でしょう、
なぜならば、JavaScriptは、かけだしのプログラミング初心者にもマニアにもともに愛されるめずらしい言語で、
貴女がその名前を挙げても必ずしも、(jQueryがやっとの初心者と思われることはあっても)あなたがプログラミング言語おた宣言をしているとは受け取られないでしょう。
むしろ「へぇ。ちゃんとprototypeは使ってる？」と聞かれたら「当たり前じゃない。むしろnode.jsでいいMVCフレームワークが分からないんだけど…」と話を振ってみましょう。
男は嬉々として、３０個くらいのnode.jsのフレームワークを教えてくれることでしょう。（まぁどれもどれで帯に短し襷に長しなんですが）
あるいはRighno上で動かしたコードをnodeへ移植する話とか、CoffeeScript、甚だしきはClojureScriptを振ってみてもいいかもしれません。
しかし、たとえば、世界が（つーか竹内先生とポール・グレアムが）誇る超絶関数型言語の名作、Common Lispにせよ、
selfと書きまくることと海外で使われてることに定評のあるPythonにせよ、
バージョンアップごとに言語仕様が変わり、かなり素敵なものではあるもののobsolatedな罠にはまりやすいRubyにせよ、
まったく読めない$_だらけで頭悪い仕様をリセットしてPerl6にする（そしてまた全く読めない）Perlにせよ、
気さくなクジラ飛行机さんがふるまう素敵においしい日本語プログラミング言語のひまわり・なでしこにせよ、
基地外トリッキー言語の代表BrainFxck・Glass・Missa・WhiteSpaceにせよ、
ましてや貴女が、「Haskellが大好き♪ わたし、プロジェクト・オイラーの問題もうほとんどHaskellで、解いちゃった♪」
と答えたならば、どうでしょう？
これはかなり博打な答え方で、
なるほど、Haskellは、純粋関数型でありつつも副作用のある操作が行える超絶名言語ゆえ、
あなたがそう答えた瞬間、プログラミング大好き男がいきなり超笑顔になって、
「へぇ、やっぱりHaskellなら大抵の問題は４行以内くらいで解いちゃった？」とか言いながら
鼻の下がだら～んと伸びちゃう可能性もあるにはありますが、
しかし、逆に、（なんだよ、この女、プログラミングおたくかよ）とおもわれて、どん引きされる可能性もまた大です、
なぜって、必ずしもプログラミング大好き男がプログラミング大好き女を好きになるとは、限らないですから。
男たちは、女を導き高みへ引き上げてあげることが大好きゆえ、
もしも貴女が、「Haskellが大好き♪」なんて言ってしまうと、
そこにはもはや、男が貴女に圏論のモナドを教育する余地がまったく残されていません、
したがって貴女のその答えは、
プログラミング大好き男の貴女への夢を潰してしまうことに他なりません。
ま、ざっとそんな感じです、貴女の目にはプログラマーたちはバカでスケベで鈍感に見えるでしょうが、
しかし、ああ見せて、プログラマーはプログラマーで繊細で、おざなりに扱われると傷つきやすく、ローカル変数の名前一つにも気を使い、女と自分の将来に夢を持っています、
貴女の答え方ひとつで、プログラマーの貴女への夢は大きくふくらみもすれば、
一瞬で、しぼんでしまいもするでしょう。
●
では、スキットを繰り返しましょう。
「わたしは、JVM上のScalaが好き。
型推論もあるしラムダ式やクロージャもスクリプト言語みたいに書けるの、豊富な組み込みのコレクションメソッドはいつも便利だし、
XMLリテラルもCaseクラスによるパターンマッチもTraitベースのMixi-inも、大好き♪」
そして、その瞬間、プログラミング大好き男の目がらんらんと輝いたなら、
貴女はこう重ねましょう、
「それからね、いま、わたしが使ってみたいWebアーキテクチャは、
Play Framework、素敵なリアルタイム嗜好のアーキテクチャって噂を聞いたから。
あなたのお暇なときがあったら、わたしをPlayへ連れてって♪」
これでもう完璧です。
PlayFrameworkと、Play（遊ぶ・じゃれる）のダブルミーニングでかれの股間も刺激しちゃえます。
そうなったらこっちのもの、
デートの日には、ペアプロ用に Happy Hacking Keyboard をばっちり決めて、かわいい下着をつけて（注３）、
github.comの通販で売ってるoctcatのTシャツか、facebookの「いいね！」ボタンがムネのところにあるTシャツ、 あるいは初音ミク（ないし彼のお気に入りのアニメキャラ。北米ならMyLittlePonyで鉄板なんだけど）のコスプレを着てゆきましょう。
その日から、プログラミング大好き男は貴女の虜になるでしょう。
注１：
（と、書いたもののPHPの現状をよく知りません。グローバル変数だらけになるのとか旧ASPみたいなもんなのかなぁ。count($array); とか書くのアホと思うがpythonも同じだった）
（あと、マジで単機能とかTwitter連携とか診断メーカー的なのでもPHPで７つも作ってる女子居たら付き合いたい）
注２：
もっとも。objective-Cなんていう言語をやることに比べれば個人で行う程度なら金のかからない手法もなくはないのですが。
注３：
プログラマーにとっての「かわいい下着」と、女性にとっての「かわいい下着」の定義にずれがあるので注意。
半数くらいのプログラマーはしましまぱんつが可愛いと思ってる気がするので、妙齢の女性が着用するには抵抗あると思うが、ボーダー柄のコットンショーツ（ただしキャラ絵のは除く）とか、
過度でないていどにフリルがついたものがオススメ。また、色は、レッドだとプログラミング大好き男は引いてしまう（だってそれはコンパイルエラーのときの色だ）ので、薄ピンクかホワイト、薄ブルー、せめて黒（に差し色でピンクとか）あたりに留めたい。
補記：
元ネタ： http://tabelog.com/tokyo/A1301/A130101/13002457/dtlrvwlst/3464106/
補記２：
「プログラマー」か「プログラマ」かの問題については、特に意味は無いが前者を採用した。
補記３：
言うまでも無いけど、ネタです。
研究職希望だったが配属されたのは希望とは異なる情報システム部門だった。
SEではあるんだけど自分でコード書いて開発することが多かった。
Webシステムの担当になったんだけど、HTMLくらいは書いたことあるけど他は完全に素人って状態だったので最初のうちは覚えること多くて面白かった。それなりに勉強もした。仕事ってものにも興味がもてた。
だけど1年くらいしてからかな、すごく仕事がつまらなくなった。
社内のシステムは、テストコードなんて1行もないし、そもそも仕様書すら無くて担当者も代わって中身はブラックボックスだけど動いてるから放置してるとかそんなシステムがごろごろしてる、そんな感じだった。
まあそんな状況のシステム担当にされたらもう悲惨だよね。スパゲッティコード読みといて、テスト作って、仕様書整備して、それの繰り返し。全部我流でつくった。
そしたら数年すぎてた。
国内メーカーなんてもうあまり体力ないから社内システムにあまりリソース費やせるわけもなく、今のシステムを生きながらえることの要員でしか無くなってしまったんで、どこにやる気見出したら良いのかもよくわからん。
情シス部門がゆえにユーザーは他の部門だからそいつらのサポートもしなきゃならんのだけど、うちの会社のITレベルの低さも思い知った。
障害発生だ！情シス部門は何やってんだ！とかクレームくるけど、調べてみると単に操作間違ってるだけどかざらだし、何もしてないのにPC壊れた言ってくるとかそういうレベル。
もううんざりだよ。
勉強会とか行って例えばHTML5がどうのこうのって話があってですねって会社で話してみるじゃん、するとそんなのうちのシステムでは使わんねって一蹴。
悲しいね。そんなの続くとね、自分が持ってた技術的興味も薄れていくんだよね。
仕事じゃあまり面白いこと出来ないからせめて余暇でって思ってたけど、結局のところ一日の大半は仕事で埋まってるわけでなかなかこれはこれでモチベーションの維持が難しい。
で、先日あまりの胃の痛さで倒れた。
もう体もだめになってしまった。
転職を考えたことは当然あるんだけど、今まで我流でやってきたからスキルは低いし、何か大きな仕事をやってきたわけでもない。もうすぐ30だけど、世の中の30っていったらもっといい仕事出来てるイメージがある。
あと給料とか福利厚生の面では今の世の中の水準を考えると割りと良い方で、転職となるときっと待遇も悪くならざるを得ないよなあとか考えてしまって踏み切れない。
どうしたらいいのかね。
このまま座して死ぬのを待つだけなのか。
それは嫌なのに行動できない。
これがまさに社畜なんだろうなあって思うと泣けてくる。
新卒で入社して４年目、去年くらいから仕事の内容がエクセル設計書になってきた。仕様書の罫線とてにをはをチェックする毎日はあまりに無意味なので、今の仕事を辞めて海外で転職しようと思う。情報系の学部を出てるし、ここ２年で英語をみっちり勉強したし（TOEIC800）、ソフトウェアエンジニアとして４年の職歴があるし、問題はなさそう。日本は嫌いじゃないけど、この４年で日本のソフトウェア業界は反吐が出るほど嫌いになってしまった。何よりこのままエクセル仕様書とオフィスプロジェクトをいじくる日々をこれ以上続けてたら、プログラミングの勘が鈍ってそれこそ転職できなくなりそう。行くなら今でしょ。
いろいろ調べてみたところ、シンガポールと香港がよさそう。アメリカはそのうち働いてみたいしシリコンバレーに憧れはあるけど、英語力とビザ的な問題で難しそう。カナダとオーストラリアはもうちょっとだけ英語力が必要。ヨーロッパは景気悪くて仕事ない。先進国基準の給料がもらえるところ以外は検討してない。
プログラム:定義づけられた物事を進めていく妥当な手順・方法の決定、および物事・手順・方法の記述書
(コンピューター)プログラミング:コンピューターが進めていく物事を定義し、妥当な手順・方法を決定し、記述すること。
プログラミング = デザイニング union コーディング;
デザイニング:進めていく物事を定義し、妥当な手順・方法を決定すること。
コーディング:コンピューターが進めていく定義づけられた物事の決定された妥当な手順・方法を、記述すること。
CD(コーダー):コーディングする人。プログラマーとは限らない。
SE(システムス エンジニア):進めていくべき物事を定義する人。プログラマーとは限らない。
PM(プロジェクト マネージャー):(プログラマー)プログラマー。(コンピューター)プログラマーとは限らない。
※日本のソフトウェア業界ではSEが定義した物事を、何の工夫も無くそのまま記述するCDという体制となっている。
つまり「物事を進めていく手順・方法」が余りにも稚拙で、PGと呼べるSEやCDが居ない。
※「物事を進めていく手順・方法」の巧拙の例としては、
PG: (初項 + 最終項) x 項数 /2
というように、例えば巧拙の差は「上手い・エレガントな方法・アルゴリズム」だったりします。
・継続的に勉強できない(1週間で最低10時間は、何があっても勉強しましょう)
・論文・学術書が読めない。(コードはお堅い理論的に筋道立った文章の極致の一つです)
・100ページくらいなら一晩で修得してやろうという気合いが無い(一晩で仕様書読み込んで次の日から活かす必要があったりします)
・仕事のやり方に疑問を抱かない(楽するためにはどんな苦労も厭わず、常に最善を考えましょう)
・いつかはマネジメントをしたい(人を使うよりも、プログラム組んで仕事させた方が、安くて速くて正確ですよ)
※(笑)なマネジメント:下僕に進捗という数字を報告させて、自分の握っている進捗管理という方眼紙のマス目を埋める作業。
自身の雇い主にマス目の埋まり具合を報告する作業。
※ここで以下の1~4を6ヶ月がんばっても挫折する方は、「一山いくらのコーダー」にしかなれない可能性が高いため、
しがみついてしまうと、真っ当な技術者の足を引っ張ることになります。
・逐次実行、条件分岐、反復実行
・ポインタ ※最近、情報学科のくせに学部でポインタを教えない大学があり、そういうところは真っ当な大学ではございません。
1)O'REILLYの[amazon:C++実践プログラミング]を最初の「ポインタ」まで読んでください。
2)C++の実行環境をC99で整えてください。(環境の準備は自分で面倒を見てください)
3)ポインタを用いて、文字のLinkedListクラスを実装してください。
※LinkedListとは以下の仕様を満たすクラスとします。(C++でJavaのLinkedListを実装)
http://docs.oracle.com/javase/jp/6/api/java/util/LinkedList.html
4)LinkedListの入れ子でTree構造をつくり、再帰を用いて、全要素をコンソール出力するプログラムを作ってください。
5)4)をクリア出来た人は、この本を1年以内に全部読んでください。
ただし、C++は複雑怪奇な言語のため、これ以降は知識レベルの修得で構いません。
私は中3の時、STLやBoostどころかbooleanの無い時にこの本を9ヶ月で読んでおります。
※私が面接に出る場合は、当該内容のLinkedListやQuickSortの概要を直ぐさま説明できる人は、可能性有りと○を出します。
面接で「LinkedListを勉強してきました、直ぐさま説明できます」といって、「そんなの出来て当たり前だ」と言ってくれる会社は殆どございません。
大抵はポカーンとして意味不明という顔をする文系人事だったり、「そんな技能必要ない」というところが殆どです。
逆に「できて当然」と言ってくれる会社は、技術をしっかり学べる可能性大です。
★ここまでクリアした方は、「入門者」と呼んで差し支えございません。次は「初級者」への挑戦です。
※初級者になるためからは、べらぼうに学ぶべきことが広がります。
燎原の火のごとく。
※筆者の立場
Joelさんの「Javaスクールの危険」に賛同するので、ポインタ優先ということで。
