SIerモデルが経年劣化してる。それはネットビジネスの遠くない未来 | F's Garage
以下の記事は本当だったと仮定した感想 SIはやめておけ 請負業において工数で見積もりをするのは当然のことだ。今のところ、それしか価値を計る方法はないし、価値を生むかわからない顧客の要望に答えるならば単価ｘ時間などの成果から外れた報酬をもらうのはエクセレントな方法論であろう。 システム構築のプロフェッショナルが、顧客のビジネスの成否から切り離してシステム開発を請け負う理想的な形だと思う。 しかし、作ったシステムが成熟した結果、社会全体の中で「何かを維持をする仕事」の方が大きくなったのだと思う。日本社会が成長しているうちは、システムを維持する仕事に対する経済への寄与が増大していくのだろうから、十分ビジネスとして成長したと思うが、日本社会が成長しなくなると、既存システムはそれ以上の売り上げをもたらさない可能性が高い。 つまり経済規模は大きいが、成長をもたらさない。そういうビジネスは、守りに入る。
SIはやめておけ
20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。 今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。 一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。 以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。 工数至上主義受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていない
Redmine で技術仕様書を書こう
はじめまして！ 株式会社 Aiming の土井です！ エンジニアをやっております！ 今回の開発者ブログでは、情報共有ツールとしての UML の活用方法について、現場での取り組みをご紹介させていただければと思います！ 技術仕様書の“図” どうやって書いてますか？ 株式会社 Aiming では、プロジェクトの Wiki やバグトラッキングに Redmine をメインに使っています。みなさんも既にご存知だったり、実際にバリバリ活用されていることとおもいます。 また、企画仕様書、技術仕様書などは Redmine の Wiki やエクセルに代表されるオフィススイート等を活用して作成しますが… 図の表現を求められるような仕様書を作る時に、どうやって作成しようか悩んだことはありませんか？ 標準ペイントソフトで頑張って作成 オフィススイートに含まれる、ドローツールを使って図を作成、画像吐き出し というケー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
