技術革新は何のためにあるのか？ - 急がば回れ、選ぶなら近道
技術革新は須く斬新的なものであるべし、という肩に力の入った信念の人は流してください。ちょっと、力の抜いた小ネタなので。 最近というかここ10年来、いわゆる業務系のシステムに関わっていてよく思うことではあります。特に最近、NoSQLやHadoopといった「新技術」が登場するにつけて強く感ることではあるのですが、なんというか、「こんな感じ」のことができます、というようなプロダクトアウト的でありながら、かつ、漠然とした抽象的な話が多すぎる気がします。要は、全般的に問題の設定が苦手だよなということです。 特定の技術の各論はともかく、まず、大上段に構えると、実はITでは一般の人が想像する以上にユーザーとベンダーで期待ギャップがあります。ユーザーから見ると、大抵は「こんなこともできないのか？」ということがごく普通にできません。一方、一般のTVとか報道とかは、スパコンや遺伝子やビッグデータや、なんやらか
開発プロジェクトのリカバリープラン - 勘と経験と読経
ソフトウェア開発プロジェクトでは、どんな開発方式をとっていたとしてもスケジュール等に遅れが発生することはある(それが人の御業である限り)。そんな時にはプロジェクトを立て直す(リカバリーする)ためのプランを立てて実行することになるが、これをリカバリープランと呼んでいる。リカバリープランを自分で立てることもあるし、人のリカバリープランを見ることもあるけれども、おさえておくべきポイントがあると思う。 科学的に取り組む。精神論で立ち向かわない。 単純にブラックであること以上に、精神論で状況に立ち向かうことは関係者に多大な迷惑をもたらす。サイコリバカリーはよくない。 利害関係者と状況を共有することができない。 「今やってます」という回答を繰り返す、いわゆる蕎麦屋の出前状況になってしまう。 何らかのタスクの終了を待っている人が見通しを立てられない。 利害関係者からの協力がやりにくい。 もし少しでも状況
B2Bベンチャーのススメ
こんにちは、堀(@jojihori)です。 最近、ここやここなどで、自分がシャノンに来てやったことについて振り返る機会があったので、ちょっと文章として書いてみようと思います。主にこれからB2Bの中でなんかやってみようとかそういうベンチャーに行ってみようとか思う人向けです。 ちょっぴり長いです。まったくもって技術ブログじゃないですね... ■Oracleからシャノンに 僕がシャノンに来たのは2005年末なのですが、前職ではOracleでアプリケーションサーバのエンジニアをしており、後半3,4年ぐらいはアプリケーションサーバ（アプリケーション開発支援ツールや、J2EEコンテナを担当してました）のメンテナンス部隊で日本を含めたアジアやヨーロッパ向けの障害解析やパッチのコードを書いたりしていました。 その時に、「こんなにWebサービスが流行っているのに、パッケージソフトなどは絶対なくなる。しかも、
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
その受託開発案件はいいのか悪いのかチェックリスト：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ
受託がいいとか、悪いとか罠だとかいう議論がある。 ぼくはそんな単純な議論ではないと思う。 いい受託と悪い受託がある。 ポイントはたった４つだ。 難しくない。全部そろってる必要もない。 ただ、ひとつも揃ってない案件はやる必要もない。 (1)時間を犠牲にするほど単価がいいか？ (2)お金以外で得られるノウハウ・スキル・実績はなにかあるか？ (3)価格の決定権のあるキーマンとのパスがあるか？ (4)担当者がトラブルメイカーでないか? 長期的に最も大事なのは(2)だ。ぼくはネットのことを何も知らないで、ネットの仕事を請けた。元々組み込みエンジニアだったからだ。最初なんか、phpもSQL触ったこともないのにイントラwebの仕事を請け、java触ったことないのにiアプリの仕事を取ってきていたし、SEOの仕事を取ってきた帰り道に本屋でSEO入門の本を買ってたくらいだった。おかげで、超短期的にそのノウハウ
システムを育てるカイゼン型開発のススメ〜SonicGardenでカイゼン型開発を行う理由 | Social Change!
日経SYSTEMS 2012年4月号の特集１が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
年金システム開発が1年以上停滞 受注企業がギブアップ、違約金を払う- 日経コンピュータReport：ITpro
次期年金システムの開発プロジェクトが、発注の失敗をきっかけに1年以上停滞していることが本誌の取材で明らかになった。設計作業を受注したIT企業の1社が役目を果たせず途中でギブアップし、再発注がなされないままの状態になっている。税と社会保障の一体改革をめぐる政治の混乱もあり、再開のメドは立っていない。 ストップしているのは、オープン化を目指す次期年金システムのプロジェクトだ。厚生労働省は「年金記録問題」が表面化した後、既に着手していた基本設計の一部をやり直す「補完工程」を3社に分割発注した（図）。3社のうちシステム基盤設計を3億8640万円で受注したユーフィット（現TIS）が、契約を履行できなかった。 アプリケーション設計を担当したNTTデータと工程管理支援を受注したTDCソフトウェアエンジニアリングは、それぞれ「契約どおりに作業を進めた」（厚労省年金局）。一方、システム基盤設計の進行は遅れた
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
ソフトウェア技術者軽視のシステム開発を続けるのはもう限界かもしれない - 達人プログラマーを目指して
つい先日、富士通がグループで抱える3万人ものSEを再教育して、職務転換を行う計画であるというニュースを知りました。 富士通の3万人SE職務転換大作戦は成功するのか？ - GoTheDistance 一つのシステムを複数の企業などが利用するクラウドサービスがこのまま普及すれば、顧客の要望を聞いて個別システムを作り込むＳＥは仕事がなくなり、余剰人員問題が顕在化するからだ。 クラウドの普及により、オーダーメイドでシステムをゼロから構築する必要がなくなり、そもそも顧客からの要件をまとめてシステムを設計するSEの仕事が不要になったり、基盤を構築、運用するエンジニアが不要になるということは、最近になってよく言われることであり、特に新しいことではありません。もちろん、クラウドの普及によって、これらの伝統的なSEの仕事が少なくなり、人員が余るという議論は間違いではないと思います。 ただし、一方でより本質的
システム開発のリ・デザイン ー 「スキニーなシステム開発」の真の狙い ー - オブログ
市谷です。 昨年12月に、スキニーなシステム開発のススメと題して、クラスメソッドさんと共催でセミナーを開催しました。 スキニーなシステム開発のススメ <永和システムマネジメント × クラスメソッド 共催セミナー> 永和システム、クラスメソッドが手を組む開発スキームの狙いは、両社互いの強みを活かすカタチを作ることで、システム提供の幅を広げることです。それは単に営業の幅を広げるためのものではありません。さらには、永和システムとクラスメソッドだけに限るような狭い話でもありません。広く多くの方々と、これからのシステム開発を模索していきたいと考えています。 これまでのSIでよくあったのが、どこか1社がユーザ企業に対してフロントに立ち、それ以外の関係企業がそのバックに周り、プロジェクトを統制するカタチです。その狙いは、ユーザー企業とのコミュニケーションパスとマネジメントを1本化することで、システム開発
プログラムの大海に溺れないために
システムの利用者にヒアリングしてもシステムのことが分からず、メンテナンスされたドキュメントもなく、最新のプログラムソースもない状況での、、 大規模な既存システムを調べるモデリング手法の紹介
工数見積もりで陥りやすい罠 - プログラマの思索
「ソフトウェア見積り」を読んだ後に「アジャイルな見積りと計画づくり」を読み直したら、とても理解しやすかった。 理解できたことをメモ。 間違っていたら後で直す。 ※追記：一部修正した。 ※追記：Velocityの計算方法を「塹壕よりScrumとXP」から参照するようにした。 【元ネタ】 Twitter / @akipii: 見積について色々考えている。1.0MD(人日)という単位は規模・出来高・工数という複数の意味を持ち混乱しやすいから、ソフトウェア開発の計画づくりに支障をきたしているのではないかという仮説を考えている。その考えを深めるとScrumのストーリーポイントはよく考えられた概念だと思う。 アジャイルサムライで一番難しくて面白い概念～Velocity: プログラマの思索 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 チームは加速するのか～Velocityの使い
オフェンシブな開発〜「納品しない受託開発」にみるソフトウェア受託開発の未来 | Social Change!
定期的にSI業界が終わったという話が出ますが、本当にそうでしょうか。終わるべきは一括発注・請負のディフェンシブなビジネスモデルです。受託はなくなることはありません。ソフトウェアの開発を、他の業界のアナロジーで考えるのではなく、正面から取り組んだビジネスモデルについて語っています。 ディフェンシブな開発 今から5年前に、SI業界における多くの問題の原因がそのビジネスモデルにあるという「ディフェンシブな開発〜SIビジネスの致命的欠陥」という記事を書きました。SIにおけるビジネスモデルは、発注者とベンダーはあらかじめ決めた金額と要件の中で納品と検収を目指すため、利益を出すためには双方がリスクを取らずに「守り」に入る必要があります。その結果、顧客にとって価値を産むかどうかよりも決められた要件通りに作られることを重視することになってしまいます。人月という単位であらかじめ決めるとなれば、単価の安い下請
小規模Webサービス向け安上がりシステム構成と開発フロー（怖話.jp） - Fjord, Inc(株式会社フィヨルド)
こちらのエントリーが大変参考になったので、僕らが作ってる怖話.jp（kowabana.jp）のシステム構成や開発方法についても公開していこうと思います。 怖話.jpはスマホ向けWebサービスなのでPC向けとはPVとかの傾向がちょっと違うかも知れません。 怖話.jpとは スマホで17,000話以上のサウンドノベル風の怖い話が閲覧・投稿できるサイト（アプリではありません）です。詳しくは下記エントリーを参照してください。 スマホでサウンドノベル風怖い話投稿サイト | FJORD, LLC（合同会社フィヨルド） 7月16日にRubyKaigi2011に合わせて無理矢理ベータテストオープンして、8月9日に正式オープンしましたので正式オープンからは１ヶ月経ってないまだまだのサイトです。開発期間は約１ヶ月ぐらいです。 サイト情報 （これAnalyticsを直接貼るのはどうやればいいんだろう？） 直近一ヶ
人材の流動化か囲い込みか: 住みたいところに住める俺
最近、日本のSI企業と仕事をする機会あった。 久々に衝撃的な体験だった。 とあるシステム案件の下請け的開発依頼だったのだが、 1.アーキテクチャがおかしい ビジネス系の人が直接実装担当のエンジニアに指示を出している。丸投げである。よってアーキテクチャが根本的におかしいのだが修正できない。 アーキテクト不在。 2.ドキュメントが無茶苦茶 基本なぜかエクセルで書いている。読みにくいことこの上ない。さらにバージョン管理が無茶苦茶である。ほとんど読んでも意味の無い古いドキュメントだらけで解読が非常に難しい。アプリのバージョン、開発環境などもドキュメント毎に違っている。ビルドするとドキュメントが自動生成されるなんてことは一切ない。 ドキュメント担当不在。 3.プロダクトのソース管理が無茶苦茶 ソース管理ソフトはつかっているものの、理解不能なブランチに分かれていて同等製品が複数派生している。修正に手間
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
Social Coding時代の幕開け
"費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた
レガシーシステム再生のアンチパターン
