プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
80年代のAppleに学ぶUIの部品化とガイドライン ― ＠IT
インタラクションデザインパターン（1） 80年代のAppleに学ぶUIの部品化とガイドライン ソシオメディア 上野 学 2007/2/7 インタラクションデザインパターンのプロローグとして、その原則や秩序の歴史を見てみよう。20年前のAppleはどのように質の高いアプリケーション開発を目指していたか デザインが優れていれば、道具はより楽しいものになり、利用者はより生産的になるはずです。道具のデザインというものは大昔から私たち人間が取り組んできたことですが、近年急激にデジタルデバイスが多様化したことによって、インタラクティブな道具をデザインするための方法論は技術の進歩に追い付くことができなくなっています。利便性を高めるはずの新技術が使い方を複雑化する要因となり、利用者の混乱は増すばかりです。 最近私は携帯電話を買い替えたのですが、同じメーカーの3年前の機種と比べて、著しく使い勝手が悪くなって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
単体テスト計画書 （1） ― 表紙・目次・第1部・第1章
必修講座100 ＜ ITpro SkillUP ： ITpro
プロジェクト管理者の道具箱
