システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
その受託開発案件はいいのか悪いのかチェックリスト：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
受託がいいとか、悪いとか罠だとかいう議論がある。 ぼくはそんな単純な議論ではないと思う。 いい受託と悪い受託がある。 ポイントはたった４つだ。 難しくない。全部そろってる必要もない。 ただ、ひとつも揃ってない案件はやる必要もない。 (1)時間を犠牲にするほど単価がいいか？ (2)お金以外で得られるノウハウ・スキル・実績はなにかあるか？ (3)価格の決定権のあるキーマンとのパスがあるか？ (4)担当者がトラブルメイカーでないか? 長期的に最も大事なのは(2)だ。ぼくはネットのことを何も知らないで、ネットの仕事を請けた。元々組み込みエンジニアだったからだ。最初なんか、phpもSQL触ったこともないのにイントラwebの仕事を請け、java触ったことないのにiアプリの仕事を取ってきていたし、SEOの仕事を取ってきた帰り道に本屋でSEO入門の本を買ってたくらいだった。おかげで、超短期的にそのノウハウ
終わるSIerの底辺を見てきた - ミッションたぶんPossible
ご挨拶 今月の第二日曜日は3月11日でした。言わずと知れた、あの「3.11 東日本大震災」から丸一年が経過した日です。改めまして、当時亡くなられた方々のご冥福をお祈り申し上げます。また、被災され現在も不便な暮らしを強いられている大勢の方々にお見舞い申し上げます。一日も早く元通りの日常が送れるようになることを願って止みません。 3.11の14:46、オレは代休で自宅にいるところにあの大地震がやってきました。自身が立つこともままならないような衝撃の中、不安定なテレビ台とPC棚をなんとか抑えて揺れが収まるのを必死で耐えたのは、今でも鮮明に思い出すことができます。それもあって我が家の被害は全くなく、妹も職場の方の好意で車で送って貰え、日付が変わった頃に無事帰宅できました。都内では翌日昼を過ぎても帰宅できなかった人が多かった中、我々は非常に運が良かったと思います。 はじめに さて、オレにとって、この
年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う- 日経コンピュータReport：ITpro
次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省は「年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した（図）。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット（現TIS）が、契約を履行できなかった。 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」（厚労省年金局）。一方、システム基盤設計の進行は遅れた
[SIer]ベンチャーカフェ｢SIerでのキャリアパスを考える｣に参加した - ギークに憧れて
f:id:hotchemi:20120310224509j:image 前回に引き続き､凝りもせずベンチャーカフェのこれからの「エンジニアリング」の話をしように参加してきた｡言い訳をしておくと､今回はスタッフとしての参加だったので勤労義務を果たしてる｡概要第2回：SIerでのキャリアパスを考える 〜ここにいても大丈夫？SIerのメリット・デメリット〜第2回では、「SI業界の現状をしっかり把握して、自分の現在位置を知ること」がテーマとなります。何かと不安が多いSI業界で働き続けると、どんなキャリアパスが待っているのでしょうか？そのメリットとデメリットは？会場はオラクル青山センター｡めちゃ綺麗だし真顔…｡ f:id:hotchemi:20120310131622j:image 登壇したのは､ISIDのひがやすおさん､ジンガジャパンの山岡広幸さん､GoTheDistanceで有名なござ先輩こと湯
SI屋さんとSIと、直近の課題について。 - 急がば回れ、選ぶなら近道
某セッションでちょっとしゃべったことをつらつらと。SIの現状と近い将来について思うところをまとめておきます。自分自身の立ち位置も確認していくという意味で。 結論的にいうと、SI自体は必要とされていますが、SI屋さんのビジネスモデルは成立しないという状況になるので、旧来の「SI屋さんの方法」ではうまくいきません。なので、別のやり方でSIをどうやっていくか？という議論が必要になりますね、という話です。 まずSI事業は人月稼働で商売をしています。スタート地点はそうではなかったのですが、一旦大きな人数を抱えると、食わせる必要があるため、より大きな仕事を取る羽目になります。要は稼働させる事、それ自体が目的になります。稼働を維持させる事で、収入を確保する事ができ、確保された収入で稼働のための人員を維持できる。そもそもそういう循環をベースに組織の目的が、「結果として」形成されてしまっています。 副作用と
5年後に後悔しないJavaプログラムの書き方 - L'eclat des jours(2009-07-02)
_ 5年後に後悔しないJavaプログラムの書き方 ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。 とにかく、ファクトリメソッドパターンを使うこと。 これは本当に重要。しかも簡単でありながら効果は絶大。 だめな例。 public class FooBar { private Connection conn; ... protected void setup() { ... conn = DriverManager.getConnection(url); ... } urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかな
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
新しいソフトウエア開発手法
マーチン・フォウラー チーフサイエンティスト , ThoughtWorks 過去数年にわたり、「ライトな」ソフトウエア開発手法が急速に関心を集めつつある。それらは、官僚制に対する解毒剤とも、ハッキングのライセンスとも見なされているが、ソフトウエア関係者全ての興味をかきたてている。このエッセイで、私は「ライトな」開発手法の単に「軽い」側面だけでなく適応的な性質や人間中心主義に着目しながら、それらが流行る理由について掘り下げてみたい。また、この系統のプロセスに対してサマリーとリファレンスを提供し、この踏み出されてまもない道を行くべきかどうかを選択するために、考慮すべき要因について考えてみたい。 開発手法ゼロから、重量級の手法へ、そして「ライトな」手法へ 予見的手法 対 適応的手法 デザインとモノ作りを分割する だいたい仕様を予見できたことがない 予測は絶対に不可能なんだろうか? 予見不可能なプ
【中級】無駄なく確実にテストする I 単体テスト
図5●静的解析の効果は高い<BR>静的解析とは，プログラムを実行せずにソースコードの内容をチェックする作業。バグを生みやすいコーディングはしていないか，可読性や保守性が下がるコーディングはしていないか，などの観点から解析する。コーディング終了時にレビューとして実施することも多い。レビュアのスキルが高ければ，メモリー・リークやマルチ・スレッドのバグも発見できるなど，より効果が高まる テストの最初に位置する「単体テスト」（モジュール・テスト，ユニット・テスト）は，すべてのシステムで実施されるべき基本的なテストである。実装された関数やメソッド（以下，プログラム）の内部構造のバグを取る。通常，コンパイルした直後に実施され，デバッガなどを用いるケースもあるため，プログラマ自身が実施することも多い＊2。後工程になるほどバグの修復コストが高くなることを肝に銘じて取り組みたい。単体テストで実施するテストに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT 勉強会カレンダー検索
Martin Fowler's Bliki in Japanese - FrontPage