今更ながらFizz-Buzz問題ネタ．

http://itpro.nikkeibp.co.jp/article/COLUMN/20070508/270287/ 「無理なソフト開発」は常態 技術者が生き残る鍵は交渉力 なんだか恣意的なタイトルだな．

http://www.nikkeibp.co.jp/sj/column/a/79/

http://itpro.nikkeibp.co.jp/article/COLUMN/20070406/267645/答：失敗に終わる．*1 ここで，次のような疑問が浮かぶかもしれない。「IT業界のプロジェクトは，システムという目に見えない製品を単品生産する。決まった製品を大量生産する製造業界と比較し…

http://d.hatena.ne.jp/masayang/20070503/1178254276 ウォーターフォールな人達にAgile開発の話をしていていると、「なんか話が噛み合わないぞ」と思うときがある。ざっと思いつくのを挙げておくと

http://childdoc.exblog.jp/5505715 技術を共有して普遍化しておくこと。しかし難しいよな。機械に備え付けのマニュアルを読まない人たちに、当院ＮＩＣＵオリジナルのマニュアル作って読ませられるんだろうか。マニュアル作って読めじゃあダメなんだろうな…

http://www.geekpage.jp/blog/?id=2007/4/25 以下が駄目な「プログラマ」の特徴だそうです。小規模企業では以下のような人は「いらない」そうです。

http://itpro.nikkeibp.co.jp/article/COLUMN/20070419/268825/ http://itpro.nikkeibp.co.jp/article/COLUMN/20070423/269105/ やはり上流工程が大事ですね。 なぜか古い世代はそのように言う．

http://itpro.nikkeibp.co.jp/article/OPINION/20070418/268785/ その一方，ITベンダーも弱体化したユーザー企業のIT部門に不満を持っている。「システムの仕事はすべてお任せで，当事者意識がない」「システムに求める要件をきっちり決めてくれない」「製品…

http://www.crew.to/blog/archives/2007/04/se_1.html 今まで私はいろんなプロジェクトを行いました。正直に言うと、一つ残念なことを痛感しました。オフショア開発の前段階、日本国内のプロジェクトに問題が多いということです。時には、日本の担当"SE"の話…

http://itpro.nikkeibp.co.jp/article/OPINION/20070403/267259/ 企業の経営課題や業務課題を解決するシステムを企画できる“IT企画人材”。 それって要するにCIOの責任範囲だよね．

http://d.hatena.ne.jp/masayang/20070402/1175584867 ついでにメモ． で、冒頭からいきなりガツンと頭をやられた。厚紙をハサミでチョキチョキ切って、それをセロテープでペタペタとはりあわせて、建物の見本を作っている場面。モデリングだ。

http://d.hatena.ne.jp/JavaBlack/20070403/p2の続き．*1 http://blog.so-net.ne.jp/seiho_tandoku/2007-04-05 深読みして差し障りを感じるとすれば、それは単なる邪推かと思われます。 *1:まさか続くとは思わなかった

http://itpro.nikkeibp.co.jp/article/COLUMN/20070316/265470/ *1 現・京都大学大学院文学研究科教授 京都大学では「文学研究」でソフトウエア工学をやるのか？ 具体的に何を研究しているのかというと、ソフトウエア工学においては、システムのモデルをつく…

http://d.hatena.ne.jp/Isoparametric/20070330/1175212448

http://d.hatena.ne.jp/masayang/20070328/1175114317 http://www.ddj.com/dept/architect/198700466 メモ．

http://slashdot.jp/comments.pl?sid=355989&cid=1131783 うちの会社に入ったときにまず教えられたのは、大きなプロジェクトでは優秀なプログラマの影響は限定的であるというものでした。つまりプロジェクトが大きければ大きいほど個々人の力量の影響は限り…

http://slashdot.jp/comments.pl?sid=355989&cid=1131301 もう1つ別に大事なこととして常に力説されるのが個人の力量に頼ったプロジェクトはその個人の存在がリスクであるということです。つまり優秀な個人は存在そのものが危険で常に誰もがお互いの仕事を交…

http://slashdot.jp/comments.pl?sid=355989&cid=1130977 あくまでも外部の人間を利用して、ソフト開発の手法を編みだすということで、それが達成されればスーパプログラマなんて必要ないと思っているようです。

http://slashdot.jp/comments.pl?sid=355989&cid=1131554 UMLがあれば工程を自動化できるCASEのようなもので未来は明るい、と組み込み業界がその方向を決めている模様。 実際にそういう動きになっていますね。あれ(=UML)はあくまでもドキュメンテーションツ…

http://slashdot.jp/article.pl?sid=07/03/23/0947223昨日の続き． http://slashdot.jp/comments.pl?sid=355989&cid=1131593 また繰り返しますが優れたプログラマはリスクであり、評価されません。 プログラム等、誰でもできる低レベルな仕事だという定義が…

http://d.hatena.ne.jp/tonotonotono/20070217/1171683338

http://slashdot.jp/article.pl?sid=07/03/23/0947223 「日本のソフト業界はプログラマーを軽視した。能力のあるプログラマーにはいい報酬を支払い、品質や生産性を上げなければならないのに、そうしなかった。」ということで、「スーパープログラマーとでも…

http://blog.livedoor.jp/lalha/archives/50156986.html ．．．まあ心当たりが，ありすぎるからなあ．IT業界の構造的問題です．

http://blogs.itmedia.co.jp/knowledge/2007/03/post_d6ff.html そのうち、「情況把握力」、「ストレスコントロール力」の不足が、全職種平均に比較して目立っており、ニーズが高い能力といえる。

http://d.hatena.ne.jp/masayang/20070303/1172976645上のネタとも関連するけれど，Ruby on Railsの話． この構図が激変したのは、TSS端末（とそれを接続するネットワーク）の価格が下落したことにより、プログラマ一人一人にコーディング環境が提供されるよ…

http://d.hatena.ne.jp/ytqwerty/20070228/p1 いや……私今までUMLを馬鹿にしてたのですが、複数人で意識合わせをやるときの道具としては有効と気付きました……。ぐだぐだ個々について話すよか、名詞がクラス候補っ！という大抵の本に書いてある頭悪い常套句を…

http://d.hatena.ne.jp/masayang/20070302/1172860846 メモ．詳細はリンク先を見てもらうとして， オフショア開発はそれほど安くない。そして品質は悪化する。 Agile開発はコストと納期の改善もさることながら、品質向上という効果が大きい。 なるほど．体感…

http://d.hatena.ne.jp/genesis2/20070218 メモ．いや，まったくその通りなんですがね．．．orz

http://dain.cocolog-nifty.com/myblog/2007/02/post_ef85.html 渡辺千賀サマの「日本発のソフトが少ないのは日本人が英語が苦手だから」を読んでいるうちに、日本のプログラマダメダメ論になりそうなので、