「ヒトもカネもない中小企業でも，やればできる」---菅雄一氏は関西のある企業のたった一人のシステム担当である。従業員約200人の製造業で，ほぼ独力でネットワークを引きサーバーを立て，社内向けのグループウエアや顧客向けのQ＆A情報検索システム，販売システムなどを構築してきた。 ミドルウエアとして使っているのは，すべてオープンソース・ソフトウエア。ハードウエアの代金と回線料を除けば，費用はほぼ菅氏の人件費だけだ。 最初はエラーの連続 菅氏がシステム内製を始めたのは，2000年に同社がインターネットに接続したことがきっかけだった。この時，インテグレータから提案されたサーバーの費用は，営業所や本社のパソコンの設定変更，ファイアウオールなどを含めて100万円以上。それを見た菅氏は「10万円のパソコンにLinuxを入れればもっと安くできるのに」と思った。 菅氏は思っただけでなく，実際に行動した。自前で

「ソフトウェア開発の匠」。このタイトルには、ソフトウェアエンジニアは現代の匠（たくみ）になるべきだという筆者の思いを表現している。現在のソフトウェア開発は、残念ながら多くの人が過去の職人気質（かたぎ）を捨て去り、サラリーマン化しすぎている。ビジネスの価値を高める最適なソフトウェア開発の姿について、自ら描くことをしていない。 しかし、ただ旧来の職人気質を取り戻すだけでは駄目なのである。ヨーロッパのマイスター（匠）のように尊敬されるためには、ビジネスを知り、ビジネス価値を高める職種になることが必要である。それが、ITエンジニアの目指すべき匠である。そのような人材像を「ソフトウェア開発の匠」とし、本連載では、そこに近づくための考え方や解決法を読者にお伝えできればと思う。 まず第1巻（連載第１～2回）では、現在のソフトウェア開発手法が未熟であることを、さまざまな問題を例に述べる。そして、これらの問

久しぶりに柔かそうな「ネタ」で始めたいと思います。 最近，ブログ界隈で「彼氏が××だった。別れたい」というコピペ改変が流行ってます。ちょうどこの連載のネタを考えている時に流行りを感じたので，「じゃあ，『彼氏がオープンソースやっていた。別れたい』でも書くかな」とtwitterでつぶやいていたら，「オープンソースには中毒性があるから，結構シリアスな問題かも」というコメントが来ました。確かにそう考えてみると，あながち単なるジョークでは済まないなということと，前回の話題とも関連があるので，あえてこのネタで考えてみたいと思います。 問題のコピペ元ネタ 件のコピペの元ネタは以下のように整理されてます。どうやら元はどこかの質問サイトのようですが，コピペとして整理されたものを転載します。 ■彼氏が軽自動車に乗ってた。別れたい… 軽だと信号待ちで並ばれた時なんか恥ずかしいｗｗ 下向いちゃうしｗｗ 男にはせめ

楽天証券でシステムトラブルが発生し、早朝のサービス開始から米国株式を除く全商品の新規発注と訂正注文、取消注文ができない状態となっている。同社によると11月11日午前10時時点で「原因の究明とサービス再開に全力を尽くしているが、復旧の見通しが立っていない」としている。 トラブルを起こしているのは、前日までのデータを処理する夜間バッチのシステムとみられる。通常夜間から未明にかけて処理が終了し、午前6時にサービスを再開する。これが何らかの原因で大幅に遅れ、いわゆる「バッチ処理の突き抜け」が起きている。 復旧に向けて一部サーバーを再起動するため、11日の午前中はサービスへのログインができなくなったり接続が切れる場合があるという。

http://anond.hatelabo.jp/20081108211610 読んでて思ったんだけどさ。 偽装請負の形もいろいろあるけど、一番の問題点はどう見ても労働者・従業員である一個人を「個人事業主への発注」として働かせ、派遣法違反逃れをしているところにあると思う。詳しく言うと労働者を個人事業主とみなし、所得税や社会保険（労災含む）の徴収の対象外になるところが問題。これ、肉体労働の世界においてはすっげー問題。業務中に大怪我をした場合、普通なら労災認定を受けるよな。だけど個人事業主だとそうはいかない。自分の身は自分で守るのが原則なので、普段から自分で民間の傷害保険などに入っておくしかない。ただ、これ問題発言かもしれないけどこの手の「ニセ個人事業主」の多くは労働者と事業主との明確な区別なんてついていない。「仕事中に怪我をしても労災があるさ」と思い続けたまま仕事をし、いざ怪我をしたらその時

「日本で「キャリア選択援助計画」を終了させる。浮いた１億ドルの多くを日本での「Ｗｏｒｋｆｏｒｃｅ　Ａｃｔｉｏｎ」（＝リストラ）に使い、日本ＩＢＭの収益構造をより競争力のあるものにする。」 かねてから噂のあったIBMのリストラですが、現実におきてるようです。これは、景気後退局面に対するすばやい対応なのでしょうか。 直接の原因は、景気かもしれませんが、根本は、アメリカ流の株主至上主義じゃないかな。株主を大切にするのはもちろん重要なんだけど、株主のため、過度に短期の数字を良くみせようとするところにあるんじゃないかと思っています。これは、IBMに限った話じゃないけどね。 米IBMは、2005年にも欧州を中心に、1万〜1万3000人のリストラをやっています。 とはいえ、会社の業績が悪い訳ではない。米IBMの第一四半期決算は、1株あたり利益、売上高とも前年を上回っている。それでも、株主のため、飽くなき

内製回帰厨としては今回の日経コンピュータの特集は見逃せないので、もちろん買ってみた。 日経コンピュータ 2008年10月15日号 SI関連のエントリでは一貫として内製回帰すべしと言っているので、超間接的に今回の特集に寄与できたと自負しています。僕のブログは数百の企業ドメインからのアクセスがある。もちろん日経さんらしき所からも。というわけで、何かしらのヒントになったかもというかなってくれないかと思っていますw 内製化のメリットとは何か 内製化の最大のメリットは、ビジネスのPDCAを素早く回すことが出来るということに尽きます。これが出来て困る会社は、原則どこにもないでしょう。 今回の特集を読ませて頂いて、内製化のメリットはだいたいこのようなところだと思います。 システム化計画〜実装までのサイクルが早くなる システムのブラックボックス化を避けられる 開発工程での手戻りを少なくすることが出来る 使

日経平均は、7000円割れが目の前ですね。企業の業績の下方修正も相次いでいますが、これらの下方修正は、最近の急激な円高・株安の前に予想したものだと思うので、さらに追加の下方修正が入るのではないでしょうか。 厳しい景気後退の中、われらSI業界が、業績回復に向けて、効率的な開発の方向へ舵を取っているかというと残念ながらそうはなっていない(と思う)のが現状です。 これまでは、多少高くても、安心感やブランドにお客様は金を払ってくれた。そんなこともあって、開発の生産性よりは、生産性が多少低くても確実な開発が好まれました。 例えば、プログラムと一対一に対応するようなプログラム設計書は、書くだけ無駄。そんなものより、プログラムを書いたほうがはやいと私は思っています。しかし、汎用機時代から脈々と受け継がれてきた、そして時代にあっていないプログラム設計書が今でも使われているのは、過去にうまくいっていたことを

自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？　自社と外注先との間の契約がどのようになっているのかご存じですか？　それを目の当たりにしても同じことを言い続けられる自信はありますか？　そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？　それでいて業界を変えたいなどといいますか？ 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同

今は友人までの公開になっているので、リンクをクリックしても発言を読めません。このエントリを書いたときは誰でも読めたんだけどね。 勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃねーの？ 仕事は、一人ではできないので、いろんな人に支えられてやっています。そういう意味で、支えてくれる人なしには何もできないのは事実です。 で、だ。 自分はどうかといえば、おれは、ほとんど、一人で仕事をしているから、下請けとか関係ないです。うちの会社でどうかといえば、下請けに仕事を押し付けている人なんていないですよ。みんな仕事大変だからね。忙しいし。 で、だ。 誰に言っていてもいいんだけど、上記の言葉の裏には、コミュニティ活動は、暇だからできるみたいなニュアンスが感じられるんだけど(間違っていたらごめん)、コミュニティ活動ってかなり大変だよ。 例えば、この前、「ひがやすを飲み会」なんて

日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ

普段読まない雑誌を眺めていてふと目に留まったのが、この記事でした。 あまりの悲惨さに他人事とは思えず、身震いしてしまいました。しかしながら、大小を問わず似たようなことは、いつ何処でも起きているのでしょう、たぶん。自分がこのようなことに係わらないようにするために、メモ書きします。 果たして、問題はどこにあったのでしょうか？　一体誰が悪いのでしょうか？ 見かけた記事というのはコレです。 日経コンピュータ 2008/08/15号　ニュース SPECIAL REPORT 日本ＩＢＭを下請けが提訴へ　七十七銀の案件で追加費用を得られず経営破綻 『日本IBMからシステム開発を受注した地方ベンダーが、IBMに追加費用の支払いを求める訴訟を準備していることがわかった。開発規模が見積もりの7.5 倍に膨らんで4億円弱の予算超過となったこの下請けベンダーは、7月に民事再生法の決定通知を受けている。　「日本IB

そもそも「ブログに書きたいことを書かない」ようになって久しい私が、こんなことをあんまりブログに書くのは変に感じられるかも知れません。 それこそ、mixi 日記とかにコッソリ書こうかと思ってましたが、やっぱりそういうのは良くない気がしたので、ここに書きます。 先日出させていただきました、「エンジニアの未来サミット」ですが、まとめの時に、ひとこと「残糞感」という表現で締め括って、その語感の酷さ故に会場を沸かせてしまいました。 今考えると、近い言葉では「消化不良」という慣用句があるにもかかわらず、私の中では「ウンコが腸内に大量に残って、出てこない」感じでした。 当初は参加した感想なんぞを…と思っていたのですが、どうも論争を避けるとキレイゴトしか並べられない、ありきたりのつまらない…というか、客観的に自分を見られていないエントリになって、その残糞感が自分の中で消化しきれなくなってしまいそうで、言葉

筆者が現役技術者だった頃はプログラミングは創造的で非常に楽しいものだった。サービス開始直前の相当な忙しさは今も昔も変わらないが、少なくともモチベーション溢れるエンジニア達の姿があった。40年近くの間に何が変わってしまったのか。わが国に定着する「ウォーターフォール(waterfall)型」の開発スタイルに、その一因を探ってみる。 浜口さんが、ウォーターフォールの問題点を指摘している。そして、反復型開発のマイクロソフト版である同期安定化型も今後は検討すべきだとしている。 一方の同期安定化型に話を戻す。こちらは、ソフトウエアをスモールチーム（３?８人）で開発できる単位に分割し、各チームが同時並行的に設計・コーディングを行っていくスタイルである。毎日あるいは一定の期間ごとに、各チームの生産物を統合してテストを行い、品質の安定化を図っていく。 わが国の市場の大半を占める企業向けの個別システムに対して

プログラミングファースト開発と最初に聞いて、ソフト開発の手順としては当たり前過ぎて、最初は何が新しいのかさっぱり分からなかったんだけど、肝は如何に受託開発でそれを貫徹するかの交渉術や契約形態にありそうだということに合点がいった。人月に代わる値付けの方法、機能や品質に応じた対価を得る手法として、パッケージ販売やSaaSといった共通化と利用者拡大の他に、相対取引での値付けにも新たな道は広がるのだろうか。 実は世の大半の名だたるソフトウェアに厳密な仕様書などないし、受託開発でも設計書と呼ばれているものがコードと同期している可能性はかなり低い。これはソフトにとって役に立つこと、問題を起こさないことが、仕様書通りに動くことよりずっと重視されてきた結果であって、みんな心のどこかで気掛かりではあるけれども、マクロ的には合理的なトレードオフの結果であって必ずしも悪い話ではない。 恐らくプログラミング・ファ

ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

「日本IT業界は日本の他の他業種に比べ、賃金など労働条件面では恵まれている」 みんな(自分も含む)泥という言葉に惑わされて、迷走した気がする。もともとのIPAの討論会の目的は、「IT業界はネガティブなイメージがあるけど本当はどうなのか」って話だった(と思う)のにね。 泥カンの開催目的が、IT業界のイメージアップであり、ポジティブキャンペーンであることは、すばらしいことだと思う。良い面を伝えることは重要。ただし、過剰演出が問題。 2年目で仕事の全体を把握できる 下積み期間はほとんどない やりたいことが直ぐ(人によって違うけど1,2,3年目)にできる 即戦力を取ってるベンチャーならありえると思うけど、新卒で入って上記の事が満たされることはまずないと思う。過剰演出は、誤解を生むし、マイナスに作用することもある。 hayamiz: @natsutan 「東大出ると大企業入れるから泥のように働かなく