“バカ・マジメ”をメンバーに入れるな！
プロジェクトの成否はメンバー選定で大部分が決まると言っても過言ではない。そんなメンバー人選で決して選んでは人種がいるという……。今回はチームメンバー人選に関する法則を紹介する。 この法則は、チームメンバー人選に関する法則である。オペレーションズリサーチの初期の名著にあったと記憶している。 将兵は「リコウかバカ」「マジメとズボラ」に区分できるが、 “リコウ・ズボラ”は将校にせよ “リコウ・マジメ”は下士官にせよ “バカ・ズボラ”は炊事当番にせよ “バカ・マジメ”は絶対にメンバーに入れてはならない！ というのだ。 情報システムの開発や保守にかかわる費用は、ブルックスの法則により、規模の指数乗に比例して増大する。それに対して、情報システムの効果はパレートの法則により、機能（規模）の対数に比例して増大するだけである。このことから、上図に示すように「利益＝効果?費用」が最大になる規模が最適規模だと言
「契約もアジャイルに」、中堅SIerの新たな挑戦 － ＠IT
2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方
プログラマーの成長を考えないSIerの仮説は間違っている - 達人プログラマーを目指して
Java EEや.NETはCOBOLやVB6よりも本当に生産性が高いか？ - 達人プログラマーを目指してのコメントで 熟練者も居ることは理解しているが、開発をする上で熟練者ばかりを集めることはできない。このため初心者側にレベルを合わせざるを得ない。 というコメントをいただきましたけれど、これは実に典型的なSIer（の上司）の考え方ですね。SIerの仮説と呼んでもよいくらいですね。とにかく、この仮説の前提となっているのは プログラマーのスキルレベルは一定で成長しない プログラマーは容易に交換可能なリソースである プログラマーは単純労働者である というモデルです。とにかく、この仮説がはびこっているから、いまだにSIerのフレームワークは「初心者側にレベルを合わせざるを得ない」という思い込みで作られていることが多いのでしょう。 COBOL（の初期の）時代ならまだしも、少なくとも現在の開発環境にお
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ - Masatomo Nakano Blog
2002年、当時設立したばかりの会社に入り、何もない状態から、コンテンツとシステムを作り続け8年が経った。日々、試行錯誤しながら、それなりに会社も大きくなり、まだ、大成功とは言えないけど、それなりにうまくやってきたつもりだ。 しかしながら、その8年という短くはない時間の中で、色々な課題や問題が発生し、その時々正しい選択をしてきたつもりだったけど、反省点も多い。もう一度スタートアップに参加するとしたら、やり直したいところや、もっと早くこうしていれば良かったというところがたくさんある。 そんなわけで、次の挑戦のときに忘れないように、また、もしかして誰かの参考くらいになればと思い、メモっておくことにした。1 まず、反省点の前に、何をやっているのかというのを簡単に。 ビジネスとしては、英語e-learningのWebサービス(ネットを使った英語のお勉強)をASPな形で、企業や大学などに提供している
内製開発を考えているSI技術者が知っておくべき内製アンチパターン - aike’s blog
数年前から、ゼネコン的なSIerの業態に構造的な限界を感じ社内のエンジニアによる自社開発（内製）を見直す動きが見られます。自分の場合も少し前にSI企業を辞めて今は内製をしていますし、知り合いの技術者にも何人かそのような転職をした人がいます。しかし、彼らの話を聞くと良いことばかりではないようです。 そんなわけで、今回は内製に潜むアンチパターンをまとめてみました。なお、ここでは一般向けプロダクト開発ではなく、社内向け業務システムの開発を想定しています。 ■そこは異業種ですよ 内製ということは、ほとんどの場合その会社はシステム開発会社ではなく、異業種に転職することになります。そのため想像以上に開発の常識が通じないことにとまどう技術者も多いようです。SIのとき、システム開発に理解がないゆえに無茶を言う顧客にあたった経験があるかと思いますが、自分以外の社員が全員そのような人であるおそれもあります。
どうしてプログラマがPMになりたくないのか - GoTheDistance
SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな
経営者が「役に立たない情報システム」を作らせる：日経ビジネスオンライン
谷島 宣之 日経BP総研 一貫してビジネスとテクノロジーの関わりについて執筆。1985年から日経コンピュータ記者。2009年1月から編集長。2015年から日経BP総研 上席研究員。 この著者の記事を見る
TDD談義への反応に対する雑感（テスト駆動開発を取り巻く誤解等） - 千里霧中
先日、twitter上でTDDに関する談義があったのだけれど、気になったのがそれに対するテストや品質の方々の反応。特にTDDの戒めである「品質保証を目的としていない」という書き込みに対してネガティブな反応が多かったのが気になった。 開発経験もあり定義や概念の扱いに注意深い方々なので誤解の可能性はないと思うが、結構問題が入り組んでいるように感じたので、今回テストエンジニアと開発者の視点の差異を焦点にして一部の論点を整理したいと思う。 開発者のいう品質保証の定義 まずTDD談義で開発者が「品質保証のためのテスト」「品質管理のためのテスト」などと呼んでいるテストの定義は、乱れや不統一感も多少あるけど、基本的にKent Beckや和田さんが使われているQAテストの定義によるもの（http://gihyo.jp/dev/serial/01/tdd/0003）。 この定義で「品質保証のための単体テスト
「技術者の楽園」を作ろうとして、現実逃避するIT企業が多い気がする - やまもといちろうBLOG（ブログ）
経営者が技術者というのは、別に構わない。むしろ、納品物が技術の結晶であるとか、システムそのものであるとか、製品知識が技術と直結している、一品もののビジネスであるなら、合理的なんだろうと思う。 一応、私としては「日本の技術やサービスはガラパゴス化している」とか「パラダイス鎖国である」というのはあまり賛成しない。じゃあドイツは？ スペインは？ イタリアは？ おのおのの国がおのおのの国民性のなかで社会風土の結実として経済システムを持っている以上、”世界標準”とやらと異なっていて当然だと思うからだ。 ただ、技術の独自性や革新性を求めることを社風にするまではいいけれど、採算性の絶対に取れない自己満足気味のプロジェクトや、野放図な開発計画を社員技術者に認めるだけでなく、経営者として考えるべき合理性すら棚に上げて、自分のやりたいようにグダグダな運営をするのは、正直どうなんだろう。 周辺も問題で、彼（彼女
システム開発に欠かせない契約の基礎知識まとめ - GoTheDistance
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
ke-tai.org 携帯プログラミング情報
2013/6/1に第四回札幌MySQL勉強会開催を行います Tweet 2013/5/20 月曜日 matsui Posted in お知らせ | No Comments » イベントの告知です。 2013年6月1日に、第四回札幌MySQL勉強会が開催されます。 日時: 2013/06/01 14:00 ～ 18:00 場所: 株式会社インフィニットループ （札幌市中央区北1条東1丁目6-5 札幌イーストスクエア 6F） イベントの詳細についてはこちらの公式サイトからご覧下さい。 → 札幌MySQL勉強会公式サイト 今回も第三回と同じく、セミナー形式ではなく個人個人が好きに勉強をしようという会です。 最後に成果発表の時間を設けますので、差し支えなければ簡単な発表をして頂ければと思います。 今回は「MySQL5.6を体験してみよう！」をテーマに、MySQL5.6のサーバを用意する予定です。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
