ソフトウェア開発にとって最大の阻害要因は納期 - 狐の王国
えっらそうに大規模開発を語るような立場じゃないんだけど、何かと話題のこのへんの記事を読んでいろいろと日ごろ思うところがふつふつとわいてきたので……。 Life is beautiful: 特許庁のシステム開発が破綻した本当の理由 Fumi's Travelblog: "費やした55億円、水の泡に 特許庁がシステム開発中断"って一体何だったのか、報告書を読んでみた 特許庁システムのことはそれなりに話題で、日本についてから何度も話にあがってきている。まあ不祥事だのなんだのって話もあるがそれはおいとくとしても、設計段階で60人体制ってだけでも多すぎるのに、増員で1300人体制とか……。設計を穴掘りかなにかと勘違いしてるとしか思えない対策でそりゃまあ破綻するよなあと。 それからね、中嶋さんの記事のコメント欄に書き込まれてた、よく言われる大規模開発でのこのへんの話。 SIerが開発を行う場合、この1
特許庁の基幹システムはなぜ失敗したのか。元内閣官房GPMO補佐官、萩本順三氏の述懐
特許庁が進めてきた基幹系システムの刷新プロジェクトが失敗に終わり、開発に投じた約55億円が無駄になってしまったことが、先週相次いで報じられました。 ［スクープ］特許庁、難航していた基幹系刷新を中止へ - ニュース：ITpro 朝日新聞デジタル：費やした５５億円、水の泡に 特許庁がシステム開発中断 - ビジネス・経済 このプロジェクトに「内閣官房GPMO（ガバメントプログラムマネジメントオフィス）補佐官」の肩書きで2009年まで民間から参加した萩本順三氏（現 匠BusinessPlace 代表取締役社長）がFacebook上で当時を述懐しつつ、失敗の要因を分析していました。今後、失敗プロジェクトを繰り返さないためにも、重要な発言として本人の許可をいただいてまとめました。 特許庁の情報部門に幾度も中止を迫った 萩本順三氏の発言の主要な部分を引用します。 内閣官房GPMO（ガバメントプログラムマ
alternative dvamp project 技術の空洞化
自称Javaが出来る人でも設計書をまともに書けない。先週は社内の諸事情からプログラミングをする機会を得た。 既にプロパーによってプログラム設計書は記載済で、製造工程以後を担当というもの。 早速プログラム設計書を見てみると…。会員No登録チェックメソッド(引数int型で会員番号)：戻り値はなしtry-catch宣言をする。try-catch宣言をする。try-catch宣言をする。Connection conn = new Connection();PreparedStatement pstm = new PreparedStatement();ResultSet rs = new ResultSet();DBに接続する。pstm = conn.prepareStatement(strSQL);pstm.setString(1, 会員番号);pstm.executeUpdate();conn
前向きなヒューマンエラー対策をしよう。 - Sacrificed & Exploited
SIerが仕切っている開発現場でありがちなのが、何かミスを犯すと、そのミスを防止するようにすごく手間がかかるチェックが追加されて、開発効率とモチベーションが下がるというダメなパターン。 たとえば、「今年度は申請書(EXCELシート)書いて上司の判子もらわないと svn commit すらできない職場で仕事することになりました。 - SiroKuro Page」とか。 これはプロセスマネジメントでもなんでもない、管理ごっこだ。管理したつもりになって自己満足しているに過ぎない！！ プロセスをマネジメントしたければプロセスを削れ: DESIGN IT! w/LOVE では、次のように述べられている。 プロセスマネジメントにありがちな間違いのひとつに、ミスを減らそうとして、そのチェックをするプロセスを増やしてしまうということがある。 もちろん、すべての場合にそれが間違いというわけではない。 そのチ
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
丸投げせず、自力でできる作業を探し出せ
サーバーソフトのバージョンアップ作業は、一般にコスト削減の余地が大きい。ベンダーに作業を丸投げにせず、自力でできる作業をあの手この手で探し出せば、予想外に大きな効果を得られる。今回紹介するアメリカンファミリー生命保険は1億円以上のコスト削減効果を得た。クラレも数千万円以上かかるERP（統合基幹業務システム）ソフトの移行作業を700万円で済ませた。外為どっとコムやエイチアールワンなどの秘策も紹介する。 本業に役立たないバージョンアップ作業は外注する、という企業も多いだろう。だがコストを抑制するためには、外部に委託するだけでなく、できる範囲で移行作業を自力で進めることも一考の余地がありそうだ。 丸投げ回避でコストを3分の2に 移行作業をできるだけ自力で進めるやり方によって、アメリカンファミリー生命保険（アフラック）は、日本オラクル製ERPパッケージ「Oracle E-Business Suit
SI開発で再利用が必要なのは部品ではなくチームだ。 - レベルエンター山本大のブログ
この半年、巨大なシステムの開発で学んだことの1つは、 SIという業態の中で再利用が必要なのは、部品ではなくチームであるということ。 チームに蓄積するノウハウや暗黙知こそ再利用するべきで、 案件の度に体制の伸縮を繰り返すやり方では、いくら部品化や共通化を進めたって効率もへったくれもあったもんじゃない。 部品の再利用は確かに可能で、非機能的な部品やフレームワークは活躍するんだけど、 ドメインオブジェクトのレベルでの再利用はやはり難しいし そもそも部品やフレームワークは使いどころを知っていて、設計や試験を省力化するところまでやってこそだと思う。 システム開発の工程の中で、製造工程はどう考えても一部分であって設計＋試験が圧倒的に長い。（保守期間はもっと長い） 設計や試験に効果を発揮するのは、部品よりもチームだ。 例えば、僕らの現場ではSOAにも取り組んでいて、権威と呼べるような人たちがその設計をや
みずほ情報総研：ソフトウェア・情報システムはいつ「壊れる」か
形あるものはいつか壊れる。パソコンなどのハードウェア製品を長期間利用していると、部品の一部や全部が何らかの理由で物理的に破損し、本来の機能が提供されなくなる。私たちは、できれば製品を長く使い続けたいと思い、壊れた部品を他の部品に交換し、同一機能を代替することで延命を試みようとする。安価に手に入れたのであれば諦めもつくが、高価な製品であればできるだけ長く使い続けようとするだろう。それでも主要な部品が壊れてしまう、または代替する部品在庫がなくなってしまうと、それが製品の寿命と割り切って、新しい製品を買い換えなければならない。 あるいは、利用者が、製品の実現価値がなくなったと判断した時点を製品寿命とする場合も考えられる。この場合、製品の物理的な状態に関係なく、利用者が目的や要求機能と製品の利用価値とを天秤にかけて要否を判断する。もっとも、このような利用者の目的・要求機能と製品が提供する機能との乖
無駄な詳細設計書を滅亡させるための処方箋 - aike’s blog
昔は「詳細設計書なんてアホなもん作ってもプログラミングには何の役にも立たないんだよふぁっきゅー！」と言い続けるのが、詳細設計書を滅亡させる手段だと思っていたけど、どうも事態はそんな簡単じゃぁないっぽい。 じゃあ一体どうすればいいのかってのはマッタク思いもつかない。まぁカンタンに無くなるもんだったらとっくの昔に滅びてるわけだしねぇ……もし、解消することが出来たら、ないし処方箋を思いつくことができたら、いつか blog に書きたいです。 詳細設計書が滅亡しない理由 - kagamihogeのblog SIerが作らされる詳細設計書（内部設計書とかプログラム設計書などと呼んだりもします）の評判は相変わらず悪いですね。このへんについては前からいろいろと考えてたことがあるので今回まとめてみます。コーディング時点で必要になる文書を極限まで減らしつつ、ウォーターフォール式の開発で納品物もきっちりそろえる
現状：オープンシステムが危ない
「オープンシステムは素晴らしいものに思えた。早く開発でき、拡張の自由度が高く、製品の価格自体も安いのでコストダウンもできる。だが実際に導入してみると、それまでメインフレームで培ってきた運用体制をたった半年で失った。あっという間だった」。合成ゴム製造大手の日本ゼオンの情報システムを開発・運用するジスインフォテクノの石橋健取締役は、1990年代半ばをこう振り返る。同社は現在、運用体制を10年越しで立て直している最中だ。 オープンシステムの輝きに隠された影の部分。それが今ユーザー企業を苦しめている（図1）。早く安く作れるというメリットは、運用のことまで意識しないままにオープンシステムを乱立させた。その結果、運用がままならない状況を生み出した。新技術を使えるというメリットはベンダーの開発競争の成果だが、それが製品や技術の短命化につながった。マルチベンダーの製品を組み合わせることで1社に縛られなくて
新人エンジニアとその先輩たちへ、OJTの前にこの本「ずっと受けたかったソフトウェアエンジニアリングの授業」を
新人エンジニアとその先輩たちへ、OJTの前にこの本「ずっと受けたかったソフトウェアエンジニアリングの授業」を 4月に新入社員として入社した新人エンジニアの方々は、早ければそろそろOJTという形で現場にやってきて、若手の先輩社員が新人の教育担当、あるいはOJTリーダーに任命される時期。 そんな新人エンジニアと教育担当におすすめしたい本を今回は紹介します。 プログラミングテクニックの解説は一切なし 一般にソフトウェアの開発は、顧客と相談して仕様を考え、それを外部仕様書、内部仕様書といったドキュメントに落とし込み、プログラミングを行い、ソースコードレビューやインスペクションを行い、単体テスト、結合テスト、運用テストといった工程を経て完成します。いわゆる「Vモデル」と呼ばれるものです。そしてこれらは1つのプロジェクトとしてマネジメントされます。 こうしてみると、ソフトウェア開発の中でプログラミング
ソフトウェア工業化と職人化が待ち受ける世界 - GeekFactory
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。 http://d.hatena.ne.jp/kwatch/20090204/1233769288 基本に立ち返って、ソフトウェア工学の目的とはなんだろう。それは「ソフトウェア開発が産業として安定成立する事」だろう。そこでこれを、大目的とする。 では、さらに考えて「産業として安定成立」するにはどうしたらいいだろうか。 大目的を成立させる為の、最低限の条件として考えられるのが、 ・条件１：成果物の品質安定 ・条件２：関連人材の安定
IT業界とSI業界の間にある深い溝 - GeekFactory
正確にはIT業界の部分集合がSI業界である。IT業界については、エンジニアの未来サミットで見たid:hyoshiok氏の資料がとても良くまとまっていたと思う。 一般には非SI業界が「IT業界」と認識されている節がある。IT業界を語る中でSI業界と非SI業界が一緒に出ることはほとんどないように思う。SIと非SIの間には深い溝がある。 SIは作ってナンボの世界。受注制で食いっぱぐれがない。SIが目指す方向は多くの凡人に簡単な仕事をさせてソフトウェアを作ることにある。プロセス改善のインセンティブと値切りの誘惑 - GeekFactoryでも書いたけど、品質のブレを抑える方向と単金を下げる方向に力が働く。その手段が標準化やオフショアである。 あまりにも内向きに仕事をしているのではないか。自分の作るシステムが顧客にどんな利益を生み出すか、考えたことのある人はどれぐらいいるだろう。それよりチープな人と
アジャイル開発向け顧客チェックリスト - GeekFactory
大企業, SIerただ僕が顧客ならば動くソフトウェアを確認しながらウチの業務プロセスにフィットするかを確かめながら進めたいと強く思うので、そのメリットを価値に変えるストーリーがあればいいと思うんだけど、自分たちの手でシステムを進化させる文化が根付いていない所には｢なにそれ？おいしいの？｣という響かない提案になると非常に思うので、やっぱ内製だろって思ってしまう今日この頃です。http://d.hatena.ne.jp/gothedistance/20100212/1265907956id:gothedistanceさんの釣り力には本当に感嘆します。タイトルにアジャイル開発とか入れておきながら、結論は内製で締めています。読者を流行語でget()して自分の論説にforward()するとは、実に素晴らしいエンターテイメントです。と、無茶いってごめんなさい。アジャイル開発の本質は顧客が主体性を持つこ
業務ソフトとiPhoneプラットホーム
業務ソフトプラットホームとしてみたiPhone iPhoneが大ブームとなり、このところはiPadの新発売でも注目を集めています。iPadの日本での発売がちょっと遅くなってがっかりですが、今か今かと待ち構えている人も多いでしょう。iPhoneそしてiPod touch、iPadとシリーズ化されるまでになったこれらの製品について、本稿ではまとめてiPhoneと呼び、機種に個別な話が出てくれば機種名で示すことにします。今回の最後の方では、iPhoneとiPadの違いについても少し触れます。 iPhoneが話題に上るポイントはたくさんありますが、携帯できるデバイスなのにパソコン並みのOSが入っているという点で、画面は小さくても従来の携帯電話のような制約された環境ではなくなった点があります。結果的に、パソコンOSにはないアプリケーションまで登場するなど新しい世界を切り開きました。 特に最近では、ゲ
他システムとの連携に関する要求の取りまとめ方
新たにシステムを導入する上で，必ず検討しなければならないことの一つが，既存の他のシステムとの連携の必要性である。例えば現行の基幹システムが導入から長い年数が経過し，その陳腐化への対応のために再構築（リプレース）を行う場合，再構築の範囲に入っていない周辺のシステムに注目する必要がある。基幹システムなどの場合は，他の周辺システムにデータを渡したり，その逆にデータを受け取ったりしているケースが多い。そのようなデータの受け渡しが行われている場合は，新システムにおいても当然そのデータ連携機能が必須となってくる。 これまで述べてきた技術要求と違って，他のシステムとの連携というのはほとんどの場合，発注側企業の固有の事情となる。そのため，RFPの段階であってもなるべく正確に要求を伝える必要がある。特に連携するシステムが複数ある場合などは，漏れがあったり，混同したりなどのミスがあるとベンダーの見積もりが大き
今そこにある「オープンレガシー」
保守できなくなり、塩漬けにしたままのオープンシステム---。いま“オープンレガシー”が情報システム部門を苦しめている。 「仕事の6割を保守切れソフトの更改だけに費やしている」。ある大手損害保険会社のシステム子会社でシステム基盤を開発保守するリーダーはこう打ち明ける。「2009年からIT投資の削減が要求が厳しくなり、開発リソースは限られている。一刻も早く整理して、新規開発にリソースを回さなければならない。ところが現状では、保守切れソフトに足を引っ張られている」と同氏は続ける。 この損保が抱えるオープンシステムは3000個。使われているOSとミドルウエアと運用手順を掛け合わせると140種類にも上る。同社はこれを今後10年で40種類まで減らしていくという。少なくともあと10年はオープンレガシーの呪縛から逃れられないという見方もできる。 オープンシステムのデメリットが重くのしかかる 1990年代か
第2回 Webアプリケーションが動作するための全体の仕組み | gihyo.jp
あらゆる企業の業務システムのWeb化が進み、専門性の高いWebアプリケーション技術者が求められています。今回は、Webアプリケーションがどのようなものなのか、そしてそれがどのような仕組みで動作しているのかを解説します。 Webシステムとは システムとは決められた目的、すなわち業務を実現する仕組みです。Webシステムはインターネットという通信技術を用いて実現されており、パソコンのWebブラウザを使って利用者とのやり取りをするのが一般的です。ここではWebシステムの動作原理を学ぶため、図1のような標準的なWebシステムを仮定して説明していきます。 図1 Webシステムの例 図1は、銀行の担当者が顧客の口座間の送金処理を行うシステムです。担当者は、パソコン上のWebブラウザ画面から送金業務のURL（Uniform Resource Locator）を入力します。URLとは、使用したいWebアプリ
釈明テンプレート - masayang's diary
修正の理由 ア 個別業績予想の修正の理由 （ア） 売上高の減少 売上高は、前回予想から約○○億円減少する見込みです。その内訳は次のとおりです。 ａ ○○システム開発の請負金を見直したこと等に伴い、当期に計上するシステム開発の売上高は約○○億円減少しました。 ｂ 国内システム開発で、リニューアル案件の受注が減少したことや、進行基準適用案件の進捗率が想定を下回ったこと等から、システム開発で約○○億円減少しました。 （イ） 営業利益、経常利益及び当期純利益の減少 当社は、YYYY年MM月に○○の○○から○○システムの開発を約○○億円で受注しました。 請負契約締結後に、設計責任を含む契約上の責任範囲等で発注者と見解の相違が明らかとなり、また、ユーザーインターフェースその他で設計変更及び追加開発等が発生し、これらの開発代金の確定について交渉を継続してきました。発注者との交渉は最終合意には至っていない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tdtshのブログ» システム開発・構築の方々はシステム運用を理解してあげてください