ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ | Social Change!
私たちソニックガーデンでは、「プログラマを一生の仕事にする」ということを一つのビジョンにしています。 このブログではよく書いていますが、私たちの考えるプログラマとは、ただコンピュータに文字を打ち込むだけの仕事ではなく、ソフトウェアそのものの企画から、関連するすべての設計、そしてコーディングと、動かすための運用までの、ソフトウェアエンジニアリングのすべてを行う仕事です。 それらは「何をするか」という観点からプログラマの仕事を表したものですが、より抽象的に考えると、プログラマの仕事は何か、そして何を目指すことで「一生の仕事にする」ことができるのか、この記事では考えてみました。 Employees hand rolling cigars in a cigar factory: Ybor City, Florida / State Library and Archives of Florida プ
人月の神話を再読した。2013-02-03 - 未来のいつか/hyoshiokの日記
何度読んでもその度に発見がある。 大阪出張のおり、行きの新幹線（帰りは大抵へべれけで寝ているので本は読めない）でぱらぱらめくってみた。 再読するきっかけは、大槻さんからご著書を頂いたからである。「ソフトウェア開発はなぜ難しいか」では、「人月の神話」を題材に、普遍的な問題を改めて平易に解説する。多くの注と参考文献の説明がついていて、初心者にとって便利な読書ガイドにもなっている。 「人月の神話」の歴史的背景を言えば1960年代はメインフレームの時代だ。コンピュータ業界はIBMに支配されていた。支配という言葉はちょっときつすぎるように若い人は思うかもしれないが、圧倒的な存在感をIBMは持っていた。 大規模ソフトウェア開発の本質的な困難さというのが、OS/360の開発によって認識されはじめた。まだソフトウェア工学と言う概念も確立していなかった。 OSという極めて複雑で大規模なソフトウェアをどのよう
最近の開発現場はギャグとしか思えない - rabbit2goのブログ
知人とコソコソと世間話。最近の開発現場は面白いことが多過ぎるという点で意見が一致してしまう。その一例。 人の入れ替わりが激しくて技術やノウハウが蓄積しない。忙しくなるとスキルよりも経験よりも頭数を揃えることを主目的にやたらと人を集めるものの、プロジェクトが終わると直ぐさま関係を切ってしまうので継続的な蓄積が何も残らない。 コンプライアンスの掛け声の下、関係者以外にも情報が見えてしまうホワイトボードやRedmineによる情報共有はご法度。セキュリティ対策も厳しくなる一方なので、ソフトをダウンロードしてパソコンに入れるだけで、正義感の塊のような監視委員から直ぐさま電話がかかってくる。 行き当たりばったりの対策を取り続けているので、何か問題が有ってもブレーンストーミングで出てきたようなアイデア案ばかりが続く。根本原因を探ることをしないし、そもそもそんな追求を行うスキルすら無い。 人月単価に惹かれ
その受託開発案件はいいのか悪いのかチェックリスト：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
受託がいいとか、悪いとか罠だとかいう議論がある。 ぼくはそんな単純な議論ではないと思う。 いい受託と悪い受託がある。 ポイントはたった４つだ。 難しくない。全部そろってる必要もない。 ただ、ひとつも揃ってない案件はやる必要もない。 (1)時間を犠牲にするほど単価がいいか？ (2)お金以外で得られるノウハウ・スキル・実績はなにかあるか？ (3)価格の決定権のあるキーマンとのパスがあるか？ (4)担当者がトラブルメイカーでないか? 長期的に最も大事なのは(2)だ。ぼくはネットのことを何も知らないで、ネットの仕事を請けた。元々組み込みエンジニアだったからだ。最初なんか、phpもSQL触ったこともないのにイントラwebの仕事を請け、java触ったことないのにiアプリの仕事を取ってきていたし、SEOの仕事を取ってきた帰り道に本屋でSEO入門の本を買ってたくらいだった。おかげで、超短期的にそのノウハウ
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
まとめ：なぜ人月見積がダメか - Zerobase Journal
社団法人日本情報システム・ユーザー協会(JUAS)発行の『ソフトウェアメトリックス調査2007』を取り寄せて読んでみましたよ。SI関係の人は必読ですよね。私はいままで知らずに損していました。 そんなこともあり、年の瀬でもあり、今回の記事では表題の件「なぜ人月見積がダメか」について、現時点での総括をします。 人月見積方式の弊害に対する言論 「ユーザー企業は出席をとるな」，日本IBMの大歳社長が提言：ITpro (2001/08/31) 「日本の商慣習でぜひとも変えて欲しいのは，ユーザー企業が我々の技術者の出席をとることだ。出席をとられると我々は開発の生産性を挙げようとする努力をしなくなる。1000人でできる仕事を500人でやってのけると，売り上げが半分になってしまうからだ。技術者の頭数ではなく，成果物について対価を払っていただける商慣習に変えていくよう，広く呼びかけたい」。日本IBMの大歳卓
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
