「個別案件」ではプログラミングの可能性を生かせない - 設計者の発言
ソフト開発企業に所属するプログラマが十年一日のように「個別案件」を相手にしているというのは、マイケル･ジャクソンが盛り場あたりで毎晩「流し」で日銭を稼いでいるようなものだ。もったいない。そんなやり方ではマイケルやプログラミングの可能性がもたらすさまざまな効果を享受できない。 仮にあるソフト会社が「ロボットの振る舞いのカスタマイズサービス」を提供しているとしよう。顧客の要望がそれぞれ微妙に違うとすれば、彼らはまず個々の要望を様式化して、その内容をあるソフトウエアに読ませるだろう。そうすればそのソフトウエアが個々の要望にしたがってロボットを動かしてくれるからだ。そんなソフトウエア、すなわち「ハードウエアドライバ」をあらかじめプログラミングしておくのが、その事業で効率的に稼いでゆくための賢いやり方というものだ。 ところが、現在の「基幹業務支援システム開発事業」の分野では、あらかじめドライバをプロ
発注者ビューガイドラインに沿って開発すれば、システムは開発できるって、誰か証明した？ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） 昨日、発注者ビューガイドラインとＳｔｒｕｔｓのプログラムについて書いたので、一言 業界で、外部仕様について共通化する？ということで、発注者ビューガイドラインというのができた。 ところが、この発注者ビューガイドライン、はじめは、外部仕様についてまとめていたはずなのに、発注者ビューガイドラインの活用と拡張 ～機能要件の合意形成を目指して～において、１６ページで、「(2)要件定義工程における活用」っていう話で、 いやいや、要求仕様の機能要件に使えるねということになってきて、 じゃあ、あとは、非機能要件をきめれば・・・ということで 非機能要求グレード検討会が非機能要件を標準化？しようとしているが、 ちょっとまて、これ、もし、 発注者ビューガイドラインと、要件仕様の機能要件との間に不整合や
もうこういうのやめようよ... - masayang's diary
日経SYSTEMS実践セミナー 手戻りなしの要件定義テクニック 要件定義書の内容が不十分なまま設計作業に着手したところ，要件の追加や変更が相次ぎ，そのたびに手戻りが発生した──。システム構築に携わるITエンジニアであれば，誰しもこんな経験があるでしょう。手戻りにつながる仕様変更を防ぐには，要件定義をしっかりと行い，業務改善に役立つシステム要件を明確にし，構築時におけるユーザーからの協力体制を確保することが重要です。本セミナーでは，手戻りを起こさない要件定義の方法を徹底解説します。要件定義の経験が少ないITエンジニアでも実践しやすいように方法を分かりやすく解説するのに加えて，演習によって理解を深めていただくのですぐに現場で役立ちます。 要件定義が充分かどうかは作ってみないとわからないんだってば。 むしろ、要件定義が不充分であることを前提として、物事を進めるようにするべきなんだってば。 （株）
株式会社マジカジャパンの羽生章洋が書いてるブログ:key-valueはデータディクショナリの夢を見るか - livedoor Blog（ブログ）
今日はCouchDBの話というよりも、key-valueという形に基づいてのデータ構造設計を考えてみたときの与太話です。 DOA自体の説明はここでは端折ります（ERDレッスンをお読みくださいm(__)m）が、その考え方の中で非常に重要でありながらも実現に際して途轍もなく困難なものがあります。それがデータディクショナリです。 データディクショナリ（以下DD）とは、乱暴に要約するとシステム内で登場する全てのデータ項目に対して意味合い・意図をしっかりと定義して辞書のように統合し、利用者の間でぶれのない状態にしましょうというものです。そしてDDの作成においては、エリアス・ホモニム・シノニムの除去が重要になります。ホモニム・シノニムについてはhttp://www.atmarkit.co.jp/fbiz/cinvest/opinion/qa/qa13_2.htmlをご覧ください。ちなみにエリアスは別名
［IT業界の弱者］6億円を半額にしろととんでもない要求
金融機関のシステム子会社に勤める高山真一さん（仮名）は，親会社の基幹系システムをオープン化するプロジェクトに，価格交渉の担当者として参加していた。このプロジェクトでは，親会社の担当者による強硬な値下げ要求により，数十人ものITエンジニアが苦しまされた。 「機能追加分は払わない」 親会社のシステム企画部門に所属するこのプロジェクトの担当者から，システムの概要仕様書を提示された。その仕様書に基づいて見積もることを求められ，約3億円（本誌推定）と見積もった。悲劇の種はこの時点で既にまかれていた。後から考えれば，この概要仕様書は，どうやらユーザーへのヒアリングを十分に行わずに作成されたものだった。それに基づいて見積もった金額が基準となってしまい，その後の不当な値下げが要求される事態を招くことになった。 概算見積もりの後に機能を詳細に検討すると，概要仕様書にはない，必要な機能が次々と判明する。精査す
QCDより重要なもの - essence-s
QCD(品質、費用、納期)は指針の一つでしかない。 例えQCDが完璧であっても、結果として大失敗であるきともありえるし、その逆もありあえる。実際にそれらの実例もある。 誰にとって何が成功なのか、あるいは、社会を含んだ全体最適の視点からはなにをもって成功とすべきなのかもう一度、考え直す必要がある。 そもそもITシステムは、業務プロセスを支援するためにある。 業務プロセスは経営ビジョンを推し進めるための戦略をすすめるためにある。 その戦略が成功しなかったらITシステムの価値はない。 QCDしかクリアできないSIerは淘汰されて行くか、システム開発の契約モデルは変わっていかざるおえないだろう。 戦略からくるビジネスレベルのフィードバックが適切にイメージできて、なるべく細かい単位で反映、検証できることが重要なはずだ。
株式会社マジカジャパンの羽生章洋が書いてるブログ:インハウス時代のソフト会社 - livedoor Blog（ブログ）
ここ数年、OSS（オープンソースソフトウェア）関連で講演させていただくときに「インハウス（内製）が復権する時代の到来」ということをお話させて頂いてます。 このような事例があったりします。 ということは、逆に言うと弊社のようなオーダーメイドの業務システムを作っているソフトウェア会社は困ってしまうわけです。自分たちで出来るからお前らイラネ、ってことになってしまいかねません。 では、私たちは本当に無価値になってしまうのかというと、そこはまた違うと考えています。プロとして提供できる価値というものを考えていくことで、生き残っていけると考えています。逆に言うと、従来通りのままで大丈夫などと考えていると厳しい時代であるともいえます。端的に言うと、作る作業と手間に対しての対価を頂くのではない、別の収益構造を模索していく必要があるのでしょう。 そもそも作ること自体に対価をもらうのを前提とするならば、OSSな
パッケージインテグレーションとエコサイクル - GeekFactory
私はパッケージソリューションの企画手伝い and 開発 and 保守というお仕事をやっているので、お客様はいろんな業界に渡ります。官公庁であったり、銀行であったり、製造業であったりするわけです。得意分野のノウハウを価値として売っているため、お客様の業務内容に深く入り込むことはあまりありません。 http://d.hatena.ne.jp/int128/20090129/1233240746 昨日のエントリで上のように書いたものの、これではプロダクトを売っているように読めてしまいますね。私のところではプロダクト単体を売るのではなく、SIを行うことを前提にパッケージを売っています。基本的にはお客様の要件を実現することを優先します。 パッケージがお客様の要件を満たせない場合は、基本的には仕様の標準化を行ってパッケージに取り込みます。その仕様があまりにも特殊な場合はSI案件で個別にカスタマイズをし
システム内製化 (Commutative Weblog)
日経コンピュータの１０月１５日号によると、システム内製化を図る会社が段々出てきたという。もともと、システム外製化が流行ったのは、ＩＴ開発の人員を社内で抱えることが、人件費の点で負担になり、また、熟練した外部ＩＴ企業にアウトソースした方が効率的という意味だったと思う。 それでも、システム内製化が見直されてきたのは、次のような理由による： １．スピード感：システム内製化すると、プログラム・ロジックをよく知る人が社内にいることになる。すると、業務変更のための仕様態様で、プログラムを書き換えるのが容易である。それ以外にも、いちいち見積もりを取ったり、仕様の打ち合わせミーティングしたりという手間がいらないという利点である。このような手間を省けるのでクイックに対応できる、という次第である。 ２．スキルの留保：また、内製化すると、開発者のスキルを社内に蓄積することができる。 ３．社内業務の熟知：同様に、
システム内製が，日本の国力を底上げする
「最近，システムを自社で内製する企業が増えていない？」 2008年10月15日号の日経コンピュータで特集した「システム内製化 再び！～自社開発を強化する12社の決断」は，編集部内のある記者が発したこの一言が始まりだった。部内の記者や編集委員などから続々と「システム内製」の情報が集まってきた。かく言う筆者も内製回帰への兆しを感じていた。ベンダーの評判を聞いても“要領を得ない”ユーザーに最近連続して出会っていたからだ。例えば，以下のようなやり取りだ。 記者：ベンダーの提示するシステム開発のコストについて，妥当性の判断が難しいとの声を聞きます。どのように判断していますか？ A社：お役に立てなくてすみません。オープン化を機に内製にしました。社内の人件費が開発費で，ベンダーに支払うのはサーバーなどハードウエアの費用のみです。 このように内製に取り組むユーザー企業では，システム部門のプレゼンスが格段に
＃42 「内製化」と「クラウド化」が「社内ＳＥ」を金ぴかにする - 非線形ノート (IT×エンジニア×転職×経営)
商売柄、社内ＳＥや社内ＳＥになりたい人と接することが多い。特にインプレスキャリアでは彼等の転職相談に乗りながら、彼等を取り巻く環境をいろいろと考え込むことが多い。社内ＳＥは若くて何も知らない時は楽しくやれる。でも３０を超えるぐらいから自分のキャリアパスに不安や閉塞感を抱えはじめる。社内から受ける低い評価にも屈託があり、その上明確なキャリアパスが用意されておらず、途切れた線（パス）のままポツンと放置されているような感覚を持っているようだ。 面談後、他の職種を含めていろいろとスキルアップやキャリアアップの求人案件を紹介し応募してみるのだが「横滑り転職」以外は厳しいのが現実である。「なんとかならないかな」と二人して頭を抱え込んだこともある。社内ＳＥの存在そのものについてそれぞれの企業が再定義しなければ、この状況が変わるのは難しい。。。と思っていた。 しかし最近になって、どうやら世の中の技術、市場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITシステム内製支援サービス — metametaweb