システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
アジャイルに限らず開発手法の議論は不毛になりやすい理由 - GoTheDistance
アジャイル開発に対する論争が盛り上がってるので、僕も便乗しまーす。新野さん、秀逸なまとめありがとうございました。 「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ － Publickey 僕も２年半前にアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceという記事を書きました。アジャイル開発ってかなり牧歌的なので、内部ならまだしても外部の仕事を請けてキチンと回すのは難しいのではと書いたら、多くの方が「そりゃそうよ」と反応してくれました。その頃から、これを"ケツカッチン"な仕事で行うのは困難だと感じておりました。コミュニケーションが密に取れないと動けないじゃん。 議論の軸をもっかい振り直すと、アジャイルが確約出来る内容はあくまで人材育成・組織風土形成という不定形なサービスでしかないんじゃないでしょうか？ アジャイルな組織になりたいから
人月を超えるエンジニアリングの未来 - GoTheDistance
ご無沙汰してしまっているmark-wadaさんより問題提起を頂いたので、最近話題になった「超高速開発」と絡めて書いていきます。 もしSIerのエンジニアがジョブズのスピーチを聞いたら（１） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（２） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（３） - Wadit Blog. もしSIerのエンジニアがジョブズのスピーチを聞いたら（４） - Wadit Blog. 僕のエントリに対する和田さんのご指摘をまとめると、ソフトウェアを作るにあたっては上流と下流の断絶があるのはマイナスなのは理解できるし、コードを書く時にはその断絶があると望むものを作ることは出来ないのも確か。だが、システムを作る時にはそもそもレイヤーをもう１つ上に上げるべき。スクラッチでコードを書く必然性など無い
受託開発は本当にオワコンか？ SI業界の未来を前向きに考える
Webサービス全盛の今こそ、エンジニアリングについて本気で語るイベント、「これからのエンジニアリングの話をしよう」第1回レポート。未来の受託業界を担うベンチャー企業のエンジニアが集まってパネルディスカッションを行った。 「Webサービスは格好いい」「SIオワコン」本当に？ 「Webサービスが盛り上がっていて、“クリエイティブで楽しい”“華やか”というイメージがある。一方、受託開発は“地味でオワコン”という風潮があるが、本当のところはどうなのか？」 2012年1月19日、ベンチャーカフェが主催するイベント「これからのエンジニアリングの話をしよう」で、このような質問が投げ掛けられた。 本イベントは、「Webサービス全盛の今こそ、エンジニアリングについて本気で語る場が欲しい」というエンジニアの声によって生まれた。さまざまな切り口で「受託開発の未来を考える」シリーズイベントで、全5回を予定している
SIは面白くないけどエンタープライズは面白い - きしだのはてな
ここんところ、SIという業態はもうダメという話になってます。 で、エンタープライズ(=企業向けシステム)というのは、SIという業態で開発されるので、エンタープライズ=SIという前提で、企業向けシステムは面白くないという話になっています。 そこから、企業向けアプリは面白くないからサービスを作りましょう、という流れになって、GREEやDeNAなどに人材が流れてます。 実際は、サービスや企業向けというアプリケーションの種類と、SIや内製、パッケージという構築側の業態は独立なので、別に語るべきです。 たとえば、このインタビューを見ると、ゲーム業界もSI化していて、面白くなくなっていそうなことが伺えます。 稲船敬二氏は，何を思い，何を考え，何を目指してカプコンを辞めていくのか。渦中の氏に直撃インタビュー また、GREEやDeNAが提供するゲームは急激に大規模化していて、おそらくSI形態での開発が増え
エンタープライズ開発者が負け組として軽蔑される日本のSI業界って - 達人プログラマーを目指して
本ブログの記事に対して多くの皆さんからいただいた意見を総合すると、技術力のあるトッププログラマーにとって現状の日本のSI業界での仕事というのは、働き甲斐のない、魅力の少ない仕事として認識されているという残念な事実を思い知らされます。 オブジェクト指向の基本すらいまだにきちんと使いこなせない開発の現場 技術について勉強した知識をほとんど活用できないし評価もされない 無駄なドキュメント作成などに対する膨大な単純作業を強いられる いわゆる3K職場と言われるような過酷な労働と低い賃金 20年以上も前の仕事の進め方からあまり進歩が見られない 多重下請け構造によりユーザーに直接価値を提案するような仕事が難しい 多くの業務アプリケーション開発現場における体験を通して、以上のようなことが語られているということを考えれば、「業務アプリケーションのプログラマーは負け組だ」という意見が出てくることも当然のことか
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
受託開発が抱える本質的な非効率性に関する考察 - GeekFactory
受託開発が抱える本質的な非効率性について考えました。ここで挙げたことはどの開発プロセスでも発生しうる問題と思います。 外注のオーバーヘッド 契約に係るコスト。 限られた場所や時間で質疑応答を行うことによる損失 情報の伝達コストは「機会」により決まる。拠点の違い、限られた時間、組織の壁により機会は減り、伝達コストは高くなる。 打合せや質問票を中心に質疑応答を行うため、情報の伝達コストが高くなる。 発注側の縦割り部門、受託側の下請け構造により、情報の伝達コストが高くなる。 決定に要する時間が長くなる。 開発者が業務プロセスを学習するコスト 前提として、どんな要件でも学習コストは必ず発生する。 過去に学習した知識を再利用できるとは限らない。受託側に業務スペシャリストが存在するとは限らない。 発注側から業務に関する説明を受ける機会（＝教育）が十分にないため、極めて非効率な学習にならざるを得ない。
今年35歳になるので、エンジニアの35歳定年説というやつについて書くぞ - developer’s delight
エンジニア35歳定年説。IT業界で働く人なら一度は聞いたことがある言葉なのではないかとおもいます。誰が言い出したのか知りませんが、この言葉は非常にタチが悪く、言葉だけが一人歩きしていて多くの人が「35歳くらいになると能力・体力の低下により新しい技術についていけなくなり、引退を余儀なくされる」という解釈をしているようです。しまいには妙な拡大解釈でこのようなエントリまで書かれる状況です。僕の認識をどんぴしゃで書いてくれているエントリがないので、自分の経験を少し書いてみたいとおもいます。僕が「エンジニアは35歳が定年」という言葉を初めて聞いたのは、新卒で就職したソフトウェア開発会社でした。僕が就職したのは、法人顧客のための業務システムを開発している、いわゆるSIをやっている会社でした。ある日、会社の先輩に「この業界、エンジニアで飯を食っていけるのは35歳までだから、よく将来のこと考えておいたほう
「デスマーチとブラックの事例募集」
かっぱ @kwappa 【募集】あなたのデスマーチ・ブラック会社体験と、そこから得たもの・失ったもの。ハッシュタグ #tobe09 もしくは D kwappa までお願いします。キョーレツなヤツ、お待ちしてます。 2010-01-31 22:44:09 閉門中 @kwy8791 甘い話かも知れないですが、連日18時にレビュー開始、ノンストップで終電タイムでお開き。去り際にお客様が「続きは明日朝イチで、それまでに指摘事項直しておいてくださいね」と言うのがありました。お客様も自社もブラックでは無いと思ってますが、デスな体験でした #tobe09 2010-01-31 22:51:12 かっぱ @kwappa 募集したので私の例。自社の上司と社長・客の社長の3人に取り囲まれて、初見のシステム(strutsで約1000アクション)を「明日の朝までにローカルにテスト環境を作ってモバイル対応の工数出せ
第20回 「1人月150万円」が「年収1800万円」ではない理由
経営者にとって、情報システムは頭痛の種になりがちだ。業務に必須だが投資に見合った効果が出るとは限らない。ほかの設備投資に比べて専門的で難解でもある。 野村総合研究所で約20年間勤務した後に、人材派遣大手スタッフサービスのCIO（最高情報責任者）を務め急成長を支えた著者が、ベンダーとユーザー両方の視点から、“システム屋”の思考回路と、上手な付き合い方を説く。 前回は、「偽装請負」を含むIT（情報技術）業界の多重取引構造について指摘しました。もう少し具体的に見てみましょう。 システム開発に関する契約は、ユーザー企業と元請け企業の間でも、元請け企業と下請け企業の間でも、請負契約であることがほとんどです。つまり委託と受託の関係です。作業範囲や成果物を明確にして、「その範囲をやってもらう」「○○を納品してもらう」といった主旨の契約です。 しかし見積書などをよく見てみると、「○○作業××人月分」といっ
株式会社マジカジャパンの羽生章洋が書いてるブログ:ソフトウェアとシステム - livedoor Blog（ブログ）
私どもの仕事はSI（システムインテグレータ）です。システムを作るのが仕事です。その一環としてソフトウェアを作っています。 最近はSI業界も自動車業界との比較が引き合いに出されることが多いのでそれに乗っかってみると、良いエンジンや良いシャーシなどを作るというのと、良い自動車を作るというのをごちゃ混ぜにしている感を受けるのです。 もちろん良い自動車を作るに際して、良いエンジンは必要です。ですがそれぞれの良い部品群を漫然と集めさえすれば良い自動車になるのかというと、それは全く別の話です。そもそもどういう自動車にするのかという方針・企画・ポリシー・フィロソフィのようなものが必要です。 ＃ エンジンだけでも十分ひとつのシステムではありますが、 ＃ それはRDBMSだけでもひとつのシステムであるという話になってしまって ＃ 拡散するので、最終成果物としてのシステムということで話を進めます。 同様に、業
capsctrldays - erase_render_results で render をキャンセル , 人月の価格調査 , 給与とコストで人月計算 , あなたの会社を潰さない最後の戦略..
1 erase_render_results で render をキャンセル ビジネスロジックが複雑になってきたのでafter_filterでいろいろフィルタリングするようにして、問題があったら RecordNotFound を raise するようにしたところ、render2回やっちゃダメって言われたので、「erase_render_results」をつけた。こんなのあったんだーというメモ。 class ApplicationController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, :with => :record_not_found protected def record_not_found erase_render_results # コレ render :file => File.j
株式会社マジカジャパンの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ）
ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 このような事例があったりします。 ということは、逆に言うと弊社のようなオーダーメイドの業務システムを作っているソフトウェア会社は困ってしまうわけです。自分たちで出来るからお前らイラネ、ってことになってしまいかねません。 では、私たちは本当に無価値になってしまうのかというと、そこはまた違うと考えています。プロとして提供できる価値というものを考えていくことで、生き残っていけると考えています。逆に言うと、従来通りのままで大丈夫などと考えていると厳しい時代であるともいえます。端的に言うと、作る作業と手間に対しての対価を頂くのではない、別の収益構造を模索していく必要があるのでしょう。 そもそも作ること自体に対価をもらうのを前提とするならば、OSSな
あいまいな要件定義は問題，ビジネスモデルの変革が必要
システム開発契約やソフトウエア開発を巡るトラブルに詳しい弁護士として知られる。数多くのトラブル案件にかかわった経験を基に、要件定義の重要性を指摘する。要件定義の支援を専門に手掛けるコンサルタントの育成と開発プロセスの透明度向上で要件定義の質を高めることが、システムに関するトラブルを減らすために有効だと明言する。 システム関連のトラブルが、訴訟に発展するケースが増えています。 一般的に、システム関連のトラブルの争点は、いくつかに分類することができます。 契約が成立したかどうかという契約の正否に関するものが一つ。それから追加契約したかどうかあいまいなままに、ずるずる仕様を変更してしまって結局、きちんと契約していたかどうかで争うものがあります。 このほかに、開発したソフトウエア開発の品質の問題、あるいは成果物の著作権の帰属、第三者の知的財産権を侵害しているかどうか、といったことがよく争点になりま
第23回 システム開発の“丸投げ”が命取りに
現行システムの維持・保守業務に加えて，新たなシステム開発案件に追われている情報システム部は多い。むしろほとんどの情報システム部は，途切れることのない開発案件の消化に明け暮れている。忙しさに加えて，リストラや慢性的な要員不足が理由で，開発案件のほとんどを外部企業にアウトソーシングするケースも増えている。外注化は有効な選択肢の一つだが，“丸投げ”になってしまっては，情報システムのみならず，企業の存亡にかかわりかねない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 空調機器製造販売会社のB社では，全国の支店網をこれまで以上に地域密着型にして，ビジネスの活性化と同時に独立採算を徹底することになった。この方針の実施に合わせて新しい業務処理に適した販売管
「SIerを選ぶ理由」NSSOLと日立情報の「導入後サービス」，FJBの「機能」が大きく上昇
日経マーケット・アクセスが企業情報システムの担当者（ITpro Researchモニター登録者）を対象に行った2008年10月調査で，「今後利用したい」という回答を得たシステム・インテグレーター（SIer）に対する「利用したい理由」を分析した。11月20日付け記事での得票数上位7社に続き，今日の記事では得票数30以上45以下の8社（日本ユニシス，NECソフト，NTT-ME，富士通ビジネスシステム（FJB），日立電子サービス（電サ），住商情報システム（SCS），日立情報システムズ，新日鉄ソリューションズ（NSSOL））についての結果を紹介する。なお，この15社に含まれなかった今回の利用意向率上位10社（11月17日付け記事参照）は，いずれも「今後利用したい」とし『利用したい理由』を1つ以上選んだ有効回答が20票未満と少数だったため，参考値としても紹介はしない。 「過去の実績」や「企業規模」「
「SIerを選ぶ理由」大塚の「提案」が上昇，CTCは「提案」上がるも「機能」が低下
日経マーケット・アクセスが企業情報システムの担当者（ITpro Researchモニター登録者）を対象に行った2008年10月調査で，「今後利用したい」という回答を得たSIer（11月17日付け記事参照）に対する「利用したい理由」を，得票数46以上の7社（大塚商会，キヤノンマーケティングジャパン（キヤノンMJ），NTTデータ，NECフィールディング（Fielding），伊藤忠テクノソリューションズ（CTC），富士通エフサス（Fsas），野村総合研究所（NRI））について分析した。なお，ベンダーに対する「利用したい理由」の分析は，11月18日付け記事と11月19日付け記事で紹介している。 SIerを選ぶ理由で「提案」と「ブランド」が上昇 今回の調査で30人以上の回答者から「今後利用したい」とされ，『利用したい理由』を1つ以上選ばれたSIer15社（下の「■調査概要」参照）の単純平均で見ると，
株式会社マジカジャパンの羽生章洋が書いてるブログ:ギョイゾー！の裏側 - livedoor Blog（ブログ）
今日は少し技術的な話です。スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています。そして工程別に担当が分かれています。 ブリスタを使っての打ち合わせが完了したら、ブリスタから設計情報を出力してスタロジの中でファクトリと呼んでいる所謂工場のライン的なチームにそれを回します。すると、プロジェクトごとの段取り替えなど含めておよそ20〜30分程度で実際に納品可能なシステムが一式出来上がります。 ・正規化されたデータベース ・追加・更新・削除の一連の処理 ・権限によるアクセスコントロール ・ワークフロー ・多様な検索 ・検索結果のCSVダウンロード ・入力支援のためのポップアップするマスタ検索画面など ・各種仕様書 およそ業務システムとして必要な一式が完成します。これは画面数やテーブル数などの規模には左右されません。工場となっているサーバのメモリ容量などの物理的成約で作業時間が決まり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。