ソフトウエア開発って日銭商売？
1960 年生まれ，独身フリー・プログラマの生態とは？ 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から，現在に至るまでの生活を振り返って，週1回のペースで公開していく予定です。プログラミングに興味がある人もない人も，フリー・プログラマを目指している人もそうでない人も，“華麗”とはほど遠い，フリー・プログラマの生活をちょっと覗いてみませんか。 ※ 記事は執筆時の情報に基づいており，現在では異なる場合があります。 世の中には，たった一人で仕上げるシステムもあれば，大勢のスタッフがよってたかって開発するシステムもある。だから，すべてを一緒くたにして論じるわけにはいかないと前置きしたうえでのお話である。 “はるか20年”ほど前，プログラム（あるいはシステム）は，大量生産の工業製品のように，「マニュアル通りに組み立てさえ
受託開発に「ボリュームディスカウント」は成立するのか？ - なからなLife
IT業界の慣習で、どうしても理解できないことがある。 それは 下請け発注先を整理縮小して、絞り込んだ企業へ発注を集中させる というものだ。 大手ベンダーなら少なからずやっているだろう。 絞り込んだ企業へ集中発注することでボリュームディスカウント効果引き出すことを狙ったものだ、という説明を聞いたことがある。 この手のものは、たいてい「購買部」主導で行われる。 現場は非常に不便だ。 案件の内容によって適した開発委託先は違ってくるし、会社公認「発注先リスト」に乗っていない企業への発注には、 リストへの追加申請自体がおそろしく負荷が高い。 それ以上に解らないのは、ボリュームディスカウントが成立する余地があるのか？ということだ。 製造業のように、大量発注を受けることで、コスト削減に寄与するものがあるのか？ 「ボリュームディスカウントってのは、大量生産方式によるコスト削減効果を、大量発注者に還元する」
［IT Service Forum］「ITベンダーの皆さん、その道の“プロ”になってください」、オリンパス北村部長
「何でもできます。死ぬ気でがんばります――。そんなITベンダーは要らない。その道の“プロ”をユーザー企業は求めている」。オリンパス IT改革推進部の北村正仁部長は、2008年11月26日に東京都内で開催された「IT Service Forum 2008」でこう訴えた。 同社は2002年から4年がかりで、ERP（統合基幹業務システム）パッケージをビッグバン導入した。プロジェクトの経験を振り返り北村部長は、「（ERPパッケージにかかわる）日本のITベンダーの常識は間違っている」と指摘する。 「ERPのベストプラクティスで業務改革を推進しましょう」「システムに業務を合わせてください」「品質が安定していて実績のある（最新ではない）バージョンを採用しましょう」「（開発日程が延び費用が増えると）最後まで死んでもやりきります」――。もし、この4つの決め台詞をITベンダーが言ったとしたら、「それはプロでは
第23回 システム開発の“丸投げ”が命取りに
現行システムの維持・保守業務に加えて，新たなシステム開発案件に追われている情報システム部は多い。むしろほとんどの情報システム部は，途切れることのない開発案件の消化に明け暮れている。忙しさに加えて，リストラや慢性的な要員不足が理由で，開発案件のほとんどを外部企業にアウトソーシングするケースも増えている。外注化は有効な選択肢の一つだが，“丸投げ”になってしまっては，情報システムのみならず，企業の存亡にかかわりかねない。 本記事は日経コンピュータの連載をほぼそのまま再掲したものです。初出から数年が経過しており現在とは状況が異なる部分もありますが，この記事で焦点を当てたITマネジメントの本質は今でも変わりません。 空調機器製造販売会社のB社では，全国の支店網をこれまで以上に地域密着型にして，ビジネスの活性化と同時に独立採算を徹底することになった。この方針の実施に合わせて新しい業務処理に適した販売管
株式会社マジカジャパンの羽生章洋が書いてるブログ:イベント三昧 - livedoor Blog（ブログ）
先週からイベントに出展など色々としてきました。その合間に来客が続いたりなど、空き時間が全くなく、PCに向かうのもままならない状態でした。そんな中で、色々と感じたりしたことがあります。 となりのブースは老夫妻による「かんきりくん」というものの展示だったのですが、そのあまりのなめらかな切り口に小さな子供からお年寄りまで、正に老若男女問わず「すごいねー」と感嘆して人だかりの山が続いていました。その横でスタロジのブースはずっと閑古鳥です。途中からパソコン無料相談という趣に変えたところ、数人の年配の方が筆王のバックアップはどうすればいいかなどを聞きに来られました。 夜の出展者同士の交流会ではメリヤス屋さんの社長さんに「御社（スタロジのことです）と違ってうちはものづくりの会社だから」と言われて、あーそうだよなー、と改めて痛感させられました。ソフトウェアはものづくりとは感じられないのだろうと思うのです。
来期のIT予算は2～3割カット、ITベンダーは何をなすべきか
2～3割の削減が相場だそうである。何のことかと言うと、ユーザー企業の来年度のIT予算のことだ。これは多くのユーザー企業のIT部門関係者による見立てだが、ITベンダーにとってはおそろしく厳しい数字だ。最近また「不採算プロジェクトの影響で・・・」なんて話も出てきており、SIなどの「ITサービス業」という産業が今のままで生き残れるか、正念場が近づいている。 欧米の金融の大クラッシュと、それに伴う世界的な株価の急落・・・まあ、ここまで派手な負のサプライズがあると、みんな必要以上に身構える。だから最初は「100年に一度の大不況」なんて大げさなと思っていたが、実体経済がつるべ落としのように悪くなると、「100年に一度」もリアリティを増してくる。ユーザー企業全体のIT予算が2～3割縮小するのもあり得ない話ではない。 現時点でIT投資にブレーキを踏みITコストの削減に乗り出しているのは、証券や自動車、通信
「納期に間に合わない！」の根本原因を探る － ＠IT自分戦略研究所
ソフトウェアを創造するエンジニア。しかし、その仕事は本当に「創造的」だろうか。仕事を創造的なものに変え、価値を生むための発想法を紹介する。 前回、自分の中に宝物が眠っていることを知った。どうすれば自分の宝物を掘り当てることができるだろうか。宝物探しの出発点は、身の回りに散在している問題を考えることだ。身近な問題を解決することができれば、その効果を直接獲得できるばかりでなく、解決策形成の体験を通じて、将来発生するであろう問題を解決するための応用力も獲得できる。 自分にとって身近な問題、自分のプロジェクトや自社が抱えている問題、あるいは自分のお客さまが抱えている問題に取り組むことから始めるといい。そして、問題解決のアイデアや提案を生み出し、自分だけでなく、プロジェクトチームにも、会社にも、そしてお客さまにも喜んでもらおう。 ■解決すべき問題をはっきりつかむ 前回挙げた、「身近な問題の例」を再掲
銀行系SIerからみた今回の経済問題 - novtan別館
３つの理由とかは入れないようにしようｗ 第一期 サブプライム問題発覚直後 そもそも発覚前の銀行の利益って爆益といってもいいほどあったはずなんだよね。みずほFGで6000億くらい？それが半分以上吹っ飛んだというのも当初はわからなかったんだけど。 キャッシュの大幅な減少は、投資の抑制に繋がる。本当は三菱東京UFJ銀行が統合作業を終わるところで他のメガバンクに人が移動したり、東京三菱UFJが統合の余波を駆って次のシステム投資を行うところのはずだったんだけど。MUFGは統合が終わるまで慎重に、という言い訳で投資を抑制。他のメガバンクも目玉のシステム投資をしなきゃならんので既存のメンテ方面に大きなしわ寄せ。 第二期 巨額損失発覚直後 サブプライムの問題が意外と大きかったことが判明した直後。 もうメンテの案件も削られまくり、単価下降の要請も出る始末。そんななか、いよいよMUFGの統合対応要員が余り始め
今度の不況でSI業界が悲惨な状況に陥りそうな３つの理由 - masayangの日記（ピスト通勤他
釣り 題名に「３つの理由」みたいに数字を入れるとアクセス数が上がると聞いた。 本当かな？ 本題 自分がこの業界で景気後退を経験するのはこれで3度目。 一回目は1990年前半のバブル崩壊後。 二回目は2000年のネットバブル崩壊後。 今回のは1990年前半のそれを、規模・深刻さ共に凌駕すると予想している。 理由(1): 空洞化 「上流＝付加価値の高い仕事」という概念は根強く、開発という「核となる」行程を安い外部に流すようになってしまった。 レバレッジ効果があるから収益向上につながってきた。 が、新たな仕事が来なくなるとレバレッジは逆転を始める。 つまり、外部依存率を下げつつ、利益率向上を目指すという苦痛が待っている。 →開発を忘れた人達には無理。 理由(2): 分業化 1990年代初頭の情報処理試験は「二種」「一種」「特種」しかなかった。 今はなんだよ... 情報処理試験の中の人達に雇用機会
SIでの工事進行基準、“ノリシロ”の扱いに見える根深い問題
久しぶりに工事進行基準の話。先日の情報サービス産業協会のセミナーを聴講していたら、講師がちょっとヤバイ話をしていた。それは、SIでのリスクを考慮して積んでおいた予備費、つまりノリシロの扱いだ。ヤバイというのは、下手をすると税務署ににらまれる恐れがあるということ。それも問題だが、この話はユーザー企業との関係を考えると結構根深い問題だ。 個々のSI案件のリスクを考慮して原価の見積もりの際にノリシロを付けるのは、ITベンダーにとって当然のビジネス行動。ユーザー企業が要件をまとめきれず、開発に向けてのまともな体制も作れないのなら、ITベンダー側のリスクは当然高まる。だから、ITベンダーはそのリスクを何らかの方法で計数化して、料金に上乗せしてユーザー企業に「お見積もり」を出す。 リスクはコストによってヘッジする。これはあらゆるビジネスの常識。ところが、まともな要件定義もせずシステム開発を丸投げしよう
株式会社マジカジャパンの羽生章洋が書いてるブログ:ギョイゾー！の裏側 - livedoor Blog（ブログ）
今日は少し技術的な話です。スタロジはいわゆるウォーターフォール型というスタイルで仕事をしています。そして工程別に担当が分かれています。 ブリスタを使っての打ち合わせが完了したら、ブリスタから設計情報を出力してスタロジの中でファクトリと呼んでいる所謂工場のライン的なチームにそれを回します。すると、プロジェクトごとの段取り替えなど含めておよそ20〜30分程度で実際に納品可能なシステムが一式出来上がります。 ・正規化されたデータベース ・追加・更新・削除の一連の処理 ・権限によるアクセスコントロール ・ワークフロー ・多様な検索 ・検索結果のCSVダウンロード ・入力支援のためのポップアップするマスタ検索画面など ・各種仕様書 およそ業務システムとして必要な一式が完成します。これは画面数やテーブル数などの規模には左右されません。工場となっているサーバのメモリ容量などの物理的成約で作業時間が決まり
はてなブログ | 無料ブログを作成しよう
晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…
下流プログラマ、IT業界を斬る － ＠IT自分戦略研究所
個人事業主という立場のプログラマ、後藤和彦氏による「下流から見たIT業界」がトップ3を独占した。特に「IT業界のシュールな現実」シリーズは、後藤氏の体験談を元にした、「笑えない」ソフトウェア開発現場の実態が描かれている。プログラマにはもちろん読んでもらいたいが、特に上流工程や企業の経営に携わる人に読んでもらいたいと考えている。「下流からはこう見えている」という1つの事実を受け止めてほしい。 5位の「ホスピタリティなプロジェクトを目指そう！」は、ぜひプロジェクトマネージャに読んでほしい。筆者の前川直也氏は、ホテルやデパートのコンシェルジュ、あるいはコンサートホールや美容院のレセプショニストを例に、「ホスピタリティ＝おもてなし」の考え方を提示している。サービス業において顧客のタイプは千差万別であり、1人1人に合わせた「おもてなし」が価値を持つ。この考え方を、プロジェクトマネジメントに応用しよう
サービスインに間に合わなかった原因は何だったのか？
プロセスを改善するということ 開発プロジェクトの現場では、大なり小なり必ず問題が存在する。それらの問題は最終的に低品質、予算超過、納期遅延などプロジェクトの失敗につながることもある。この状況を打開しようとさまざまな手を打っている企業は多いが、その打ち手は必ずしも大きな成果を挙げているとはいえない。 よくある要因の1つに、問題が顕在化した際に安易に個人や組織・ツールを原因と特定し、対策を講じようとすることが挙げられる。個人を原因として対策を施した場合、問題は解決したとしても組織には何も蓄積されない。そればかりか、人格否定など別の問題を発生させることもある。また、ツールおよび組織についていえば、そもそもなすべきことを効率的に実行するために組織は編成され、ツールは選定されるべきだ。なすべきことをきちんと分析せずに、組織やツールに対症療法を施しても、成果が出ない場合が多い。 そこで、なすべきこと、
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
［IT業界の弱者］半年さかのぼって値下げを強要
IT業界において常態化している理不尽な行いを，弱者の視点で書いていく。今回のテーマは「不当な値下げ要求」である。 システム構築プロジェクトにおいて，値下げを強要されるケースは少なくない。ITエンジニアの人月単価の引き下げや，発注金額全体の値下げといったケースが特に多い。 ソフトハウスを経営し，自身もSEとして働く鈴木邦夫さん（仮名）には，忘れたくても忘れられないプロジェクトがある。そのシステム構築プロジェクトでは，こんなことがあった。元請け会社のプロジェクト・マネージャ（PM）と話し合う際，体は正面に向けているものの，お互い首を横に向けて話した。顔を合わせるだけで気分が悪くなる思いだったからだ。 この元請け会社というのは，大手金融機関のシステム子会社である。親会社のシステムだけでなく，新たな顧客の開拓に力を入れる方針だったのか，そのシステム子会社は大きな案件のコンペに参加することになった。
今だから出来る業務システムを
先日、とある業務システムの事例が発表されていました。最先端を好むエンジニアに評判の良い最新技術を採用しての開発ということで大きく注目を集めたようです。その事例記事自体は普通の紹介記事なので、そこからあれこれと邪推するのもどうかと思うのですがいくつか気になるところがあり、それが日本の業務システムの問題の一部を体現している気がするので、ちょっと気になるところを書き連ねてみます。 その記事には画面のスクリーンショットが掲載されていました。見た瞬間に「未だに？」と感じてしまいました。どういうことかというと、画面の一番上がラジオボタンになっており、 ◎追加 ○更新 ○削除 と、まずは今から行う操作の種別を入力するようになっているのです。 これは「伝票入力する」という業務がそのまま残っているということになります。どういうことかというと、昔々というのはコンピュータが非常に高価な時代でした。そこでまずは入
規模見積もりの事前チェックリスト
規模見積もりにおける「事前チェックリスト」を右表に示した。各項目は，本文で示した落とし穴とは関係なく，見積もりを迅速かつ確実に進めるために事前に点検しておきたいものである（工数編とコスト編のチェックリストも同様）。「RFP（提案依頼書）を入手したか」や「RFPの記載内容に過剰な期待はないか」など，ベンダー視点の項目を除けば，立場を問わず利用できる。 各チェック項目には「FP法」や「LOC法」「画面/帳票」を示すアイコンがある。技法別に，関係する項目を表したものだ。30項目すべてをチェックしなくても，使う技法のアイコンがある項目のみをチェックすればよい。 規模見積もりの事前準備では，いかに「要件」を明確にするかがポイントとなる（7～28番）。規模見積もりの入力情報は要件だ。その要件に関する情報が不足していると，正しい規模を測定できない。 例えば，FP法や画面/帳票による規模見積もりでは“何を
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『はてなブログ | 無料ブログを作成しよう』へのコメント
『受託開発がつまらないなんて言わせない - GoTheDistance』へのコメント
