プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
見えない「運用」 - 疲弊する運用現場 | Think IT（シンクイット）
インターネットのインフラ化と運用現場の疲弊 インターネットの急速な普及および発展により、インターネットを含むIT情報基盤は、社会基盤（インフラ）としての性格を色濃く帯びてきています。 しかし、これらのシステムやサービスを運用している現場では、メンバーに対する恒常的な高負荷、属人的な運用、トラブルの多発に悩まされるなど、事業継続面でのリスクを抱え、コストや効率面での課題に追われながらも、現場の個々人の過大な努力によって日々の運用を維持しているのが現状です。 なお、システムやサービスを「運用している現場」とは、例えば組織や企業において社内向け、対外向けなどを問わず「ユーザーや相手に対して何らかのサービスを提供している人たち」をイメージしています。 本連載では、従来であれば「現場ごとの個別事情に応じて、やり方が異なるため、標準化が難しい」と言われてきた「運用」について、「運用設計」という観点から
開発がうまくいくための５ヶ条 - 僕のススメ。
前の記事ではちょっとネガティブなことを書きすぎて、これじゃiPadもらえないと思うから今回はちょっとまじめに。僕が大規模開発をしてみて肌身を持って感じた重要だと思う５ヶ条をかいてみるお。 組み込みの大規模開発で僕が感じたことだから突っ込み大歓迎だお。 iPadほしいお 仕様書は簡潔にきちんとしたことを書く 仕様書書くのって非常にめんどくさい。面倒だからってないがしろにしてると非常に不安定なものが出来上がってしまうんだよね。仕様書で大事なことは簡潔で読み違いが無く分かりやすいものを目指すということ。僕の中で各仕様書に書かないといけないことをまとめると↓になる。 要件定義書（BI） 作成物が何を実現するものなのかを記載する。 基本設計書（BD） 作成物を機能単位にタスクで分割し、各タスクの外部IFを規定する。 機能設計書（FD） BDで分割したタスクを今度は機能部に分割する。ここで機能部ごとの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「技術的負債」に対する新しい見方
