たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
いつもカチンと来る消毒たん。 何故「多重下請け構造」がなくならないかというと、お前らが営業をサボってるからだよ!! 今回はまるっきり同意。 この業界で「仕事」してる人なら、多分首肯出来ることだろう。会社で安定して仕事を確保し、それを利益につなげる一番重要なものは、営業力だということを。 もちろんそういったのには「身の丈」ってのがあって、受注金額の6割以上のキャッシュフローがないと受けられない。だから、零細企業は… ってのは、まぁもっともな話だ。その辺のフローも何とかしてくれるのが元請けのありがたさで、リスクなんかも引き受けてくれたりして、とっても楽ちん。つまり、 面倒な営業活動をしなくていい 資金繰りを何とかしてくれる いろんなことの防波堤になってくれる ということで、元請け様々だ。こういった面倒を引き受けてくれるんだから、多少のピンハネなんてされて当然。逆に言えば、こういった能力がなかっ
先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出
はぶさんの日記にわが意を得たりという記述があったので、脊髄反射TB。 エンジニアはともすれば「正しさ」を追求します。他者に対する説明も、いかにそれが正しいかという観点で話をします。ですが正しいだけで他人の心に対して鈍感であっては、決して魅力的な存在にはなれないと私は感じます。 閉塞感を越えて 私はいわゆる｢スーツ｣という立場に立ってクライアントの所に向かいますが、まだまだこの「正しさ至上主義」から脱することが出来ません。コンサルタントというのも、エンジニアと同様に「如何にそれが正しいか」という観点で話をするのが基本です。御社にはこれが必要なんです、こうすべきなんです。その情熱をPowerpointを武器に伝えていく。正しさを追求することはエンジニアもコンサルタントも同じなのですが、その正しさがクライアントの「コンテキスト」に沿っていない場合が問題です。単なる押し売りになってしまいます。理屈
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
