「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
SW開発で火を噴くパターン - プログラマの思索
【1】SW開発ではいつも結合テスト以降で火を噴く。 設計、開発、単体テストまで順調であっても、結合テストから受入テストに至るまでに致命的な問題が発覚する。 例えば、下記のような問題がいつでもどこでも噴出するのではないか。 設計書には、複数の画面遷移による業務フローが考慮されていなかった。 業務のインターフェイスがシステムとして整合性が取れていなかった。 シナリオに従ってテストしたら、設計時には気付かなかった業務フローが見つかったり、想定しなかったデータが作られて、その対応が漏れていた。 つまり、設計漏れ。 実際に結合テスト環境で動かそうとすると、そもそも動かない。 実は、DB環境にViewやプロシージャがもれていた。 あるいは、帳票出力やPDF出力、バッチ処理などに必要なサードパーティのライブラリがテスト環境に無かった。 モジュールをビルドして、Webサーバーを再起動する作業が手順化されて
デザイナー：佐藤可士和さんの言葉からSIを考えてみた - Float on the flow
SIerってのも、デザイナーであるべきなんですよね。つい、お客さんのいいなりになって開発しがちですが。 ほんとうは、グランドデザインがないといけない。そうしないと軸がブレる。発言力のある現場ユーザの声に引きずられ、既存システムの焼き直しに終始したりとか。 ただ、「グランドデザインからやりましょうよ」と説得できる人がいない。なんでだろう。 グランドデザインの必要性を認識していないから？ わかってるけど自分にはできないと思っているから？ クライアントのトップに説得しないといけないけど腰が引けている？ お客さんがグランドデザインできると思っている？*1 SIerのコスト構造や会計制度、人事制度が「企画・戦略立案」みたいなフェーズに対応していない？ デザインってボトムアップで要求を拾っていって、トップダウンで意思決定していく必要がある。要求だけを単純に足していくとキマイラになってしまう。 でもSI
［IT業界の弱者］6億円を半額にしろととんでもない要求
金融機関のシステム子会社に勤める高山真一さん（仮名）は，親会社の基幹系システムをオープン化するプロジェクトに，価格交渉の担当者として参加していた。このプロジェクトでは，親会社の担当者による強硬な値下げ要求により，数十人ものITエンジニアが苦しまされた。 「機能追加分は払わない」 親会社のシステム企画部門に所属するこのプロジェクトの担当者から，システムの概要仕様書を提示された。その仕様書に基づいて見積もることを求められ，約3億円（本誌推定）と見積もった。悲劇の種はこの時点で既にまかれていた。後から考えれば，この概要仕様書は，どうやらユーザーへのヒアリングを十分に行わずに作成されたものだった。それに基づいて見積もった金額が基準となってしまい，その後の不当な値下げが要求される事態を招くことになった。 概算見積もりの後に機能を詳細に検討すると，概要仕様書にはない，必要な機能が次々と判明する。精査す
QCDより重要なもの - essence-s
QCD(品質、費用、納期)は指針の一つでしかない。 例えQCDが完璧であっても、結果として大失敗であるきともありえるし、その逆もありあえる。実際にそれらの実例もある。 誰にとって何が成功なのか、あるいは、社会を含んだ全体最適の視点からはなにをもって成功とすべきなのかもう一度、考え直す必要がある。 そもそもITシステムは、業務プロセスを支援するためにある。 業務プロセスは経営ビジョンを推し進めるための戦略をすすめるためにある。 その戦略が成功しなかったらITシステムの価値はない。 QCDしかクリアできないSIerは淘汰されて行くか、システム開発の契約モデルは変わっていかざるおえないだろう。 戦略からくるビジネスレベルのフィードバックが適切にイメージできて、なるべく細かい単位で反映、検証できることが重要なはずだ。
要件定義は上流工程か - Float on the flow
SIerのエンジニアになると「要件定義＝上流工程」って教えられます。 これは、Googleの検索結果からも一般的な傾向のようです。 要件定義 上流 の検索結果 約 181,000 件 要件定義 中流 の検索結果 約 4,320 件 要件定義 下流 の検索結果 約 33,800 件 *1 でも、これって本当でしょうか？ 確かにSIerのビジネスを考えれば、要件定義は上流です。RFPもらって、それに対する提案をするところからビジネスが始まります。 顧客に自社を選択していただいたら、そこからプロジェクトスタート。リプレース案件では「FS」とか「プレ要件定義」なんて言って、既存システムについての調査フェーズが入ることもありますが、だいたいは「要件定義」からスタートです。だから上流。 うん。そうだよね。 …で終わってしまったら、わざわざエントリを書いた意味が無い。 自分の問題意識は、「ほんとに要件定
株式会社マジカジャパンの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ）
ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 このような事例があったりします。 ということは、逆に言うと弊社のようなオーダーメイドの業務システムを作っているソフトウェア会社は困ってしまうわけです。自分たちで出来るからお前らイラネ、ってことになってしまいかねません。 では、私たちは本当に無価値になってしまうのかというと、そこはまた違うと考えています。プロとして提供できる価値というものを考えていくことで、生き残っていけると考えています。逆に言うと、従来通りのままで大丈夫などと考えていると厳しい時代であるともいえます。端的に言うと、作る作業と手間に対しての対価を頂くのではない、別の収益構造を模索していく必要があるのでしょう。 そもそも作ること自体に対価をもらうのを前提とするならば、OSSな
システム内製化 (Commutative Weblog)
日経コンピュータの１０月１５日号によると、システム内製化を図る会社が段々出てきたという。もともと、システム外製化が流行ったのは、ＩＴ開発の人員を社内で抱えることが、人件費の点で負担になり、また、熟練した外部ＩＴ企業にアウトソースした方が効率的という意味だったと思う。 それでも、システム内製化が見直されてきたのは、次のような理由による： １．スピード感：システム内製化すると、プログラム・ロジックをよく知る人が社内にいることになる。すると、業務変更のための仕様態様で、プログラムを書き換えるのが容易である。それ以外にも、いちいち見積もりを取ったり、仕様の打ち合わせミーティングしたりという手間がいらないという利点である。このような手間を省けるのでクイックに対応できる、という次第である。 ２．スキルの留保：また、内製化すると、開発者のスキルを社内に蓄積することができる。 ３．社内業務の熟知：同様に、
＃42 「内製化」と「クラウド化」が「社内ＳＥ」を金ぴかにする - 非線形ノート (IT×エンジニア×転職×経営)
商売柄、社内ＳＥや社内ＳＥになりたい人と接することが多い。特にインプレスキャリアでは彼等の転職相談に乗りながら、彼等を取り巻く環境をいろいろと考え込むことが多い。社内ＳＥは若くて何も知らない時は楽しくやれる。でも３０を超えるぐらいから自分のキャリアパスに不安や閉塞感を抱えはじめる。社内から受ける低い評価にも屈託があり、その上明確なキャリアパスが用意されておらず、途切れた線（パス）のままポツンと放置されているような感覚を持っているようだ。 面談後、他の職種を含めていろいろとスキルアップやキャリアアップの求人案件を紹介し応募してみるのだが「横滑り転職」以外は厳しいのが現実である。「なんとかならないかな」と二人して頭を抱え込んだこともある。社内ＳＥの存在そのものについてそれぞれの企業が再定義しなければ、この状況が変わるのは難しい。。。と思っていた。 しかし最近になって、どうやら世の中の技術、市場
調べれば調べるほど分からなくなる「クラウド」
2005年にGoogle Map/Google Earthが公開されたとき，コンシューマ・ユーザーはその斬新なUI（ユーザー・インタフェース）に衝撃を受けた。Ajaxをはじめとするリッチ・クライアント技術を使ったWebサイトや企業情報システムが続々登場してきた。しかし，その裏でサーバーの方もすごいことになっていた。 検索やECサイトなどのサービスを提供するために，GoogleやAmazon，Microsoftでは，数十万台単位のサーバーを運用するデータセンターを作り上げていた（関連記事：「「ゲイツ後」の世界」）。各社はメモリーやプロセスの分散技術やシステムの管理技術を駆使して，けた違いの数のサーバーを運用している。そのインフラをサービスとして公開し，誰もが様々なアプリケーションやミドルウエアを載せられるようにした。これがクラウド・コンピューティングの実体である。 よく「鶏が先か卵が先か」と
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITシステム内製支援サービス — metametaweb
サービス終了のお知らせ