システムの「価値」をどう考えるのか？〜なんで人月換算基準がなくならないか、について - 急がば回れ、選ぶなら近道
「なんで人月換算基準がなくならないか」については、これは作る側での議論が非常に多いのですが、逆側から見た議論があまりにも少ないので、自分の考えを記録しておきます。そもそも、発注した側ではシステムの価値をどう見るのか？という議論があまりにもなさ過ぎの印象があります。いくら作る側が頑張っても、発注サイドで「いやだから、結局いくらかかったか内訳見せろ」という話になった途端に、残念ながら人月単価が登場するわけで、話は振り出しに戻ります。 まず一義的にはユーザーから見たシステム開発は投資になります。確かに、毎年作っているでしょう、という話もありますが、普通は数年に一回作っては動かして、メンテナンスにモードに移行させる、という形になります。投資として、通常はキャッシュ・アウトに相当するコストで資産を認識します。リースにすれば、定常的でしょうという話もありますが、オン・ブックになった途端に普通に取得原価
「納品のない受託開発」とは 〜 これからの時代にあったソフトウェア受託開発のビジネスモデル | Social Change!
昔は技術的に出来なかった為に運用でカバーしてきた慣習が残り続けているけれども、実は今の技術で考え直すともっと無駄なく簡単に出来ることって、多くの業界で起きているように思います。 もちろん、ソフトウェアの受託開発の世界でも起きています。ソフトウェア開発を生業とする私たちの会社で考えたのは、昔ながらの商習慣によって様々な問題を引き起こしているのは「納品」ではないか、ということでした。 この記事ではソフトウェアにおける「納品」のもたらす問題と、私たちの会社で解決している方法「納品のない受託開発」について書きました。（自社のウェブサイト用に書いた原稿をブログにしただけなので、それっぽい表現になってます。） 「納品」が引き起こしている問題 私たちソニックガーデンの受託開発では、一括委託を行っていません。ソフトウェア開発における「一括請負での受託開発」のビジネスモデルは、多くの問題を生み出してきたから
要件が確定しなかったことにつきベンダに責任がないとされた事例 東京地判平22.7.22（平20ワ16510号） - IT・システム判例メモ
ユーザがベンダに対し，ベンダが一方的に開発契約を解除したとして，損害賠償を求めたが棄却された事例。 事案の概要 ユーザＸは，ベンダＹに対し，平成14年9月18日に，Ｘの人材派遣業務に必要なシステムとして２つのシステムの開発を委託した（契約金額の合計は840万円）。 その後，Ｙは，9月25日にはソフトウェアの概要仕様を記載したシステム設計書を交付したが，Ｘは内容不十分であるとして記名押印を拒絶したためシステム設計書は確定しなかった。さらに，下請業者が交替するなどして，翌平成15年9月になってプロトタイプを作成するとともに再度ドキュメントを提出したが，Ｘは，やはり記名捺印を拒絶し，確定しなかった。その後もＹからはドキュメントが提出されているが，Ｘはやはり拒絶した。Ｙは，Ｘに対し「弊社は契約書の範囲内で最後まで誠意をもって開発を行います。」などと記載した書面を交付した。結局，平成16年9月になっ
契約ってのは意外と交渉の余地がない - プログラマーの脳みそ
株式会社マジカジャパンの羽生章洋が書いてるブログ:元請けにこだわる理由 - livedoor Blog（ブログ） 「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - yvsu pron. yas あたりの話。 自分は地方の零細の下請け会社なわけなんだけど、自分の判断で契約を行える自由を持っている。かといって、契約内容については、実はそれほど自由には決められないものだ。 というのは、こっちの話ではなく、相手側の話なのだ。中規模以上の会社と契約しようとすると、おおむね定型の契約方式のいずれかを選択、変更可能なのは一部の数字だけ、ということが多い。 フリーエンジニアになってぶち当たる壁 IT関連と言うのは独立が非常にしやすい。設備投資などがほかの業種に比べ圧倒的に少ないから、自分の技術力を買ってくださいと個別交渉することさえ出来るなら即刻独立することができる。 フリーの身に
基本設計の基礎
技術や製品の多様化，不十分な要件定義の増加，オフショア開発の進展などにより，基本設計の難易度がますます上がっている。一方で開発の現場では，新規開発案件において十分に時間をかけて基本設計を実施するケースのような，ITエンジニアが基本設計のスキルを磨くチャンスが減っている。そうした要因により，ITエンジニアの基本設計のスキル不足が叫ばれることも珍しくない。 そこでここでは，基本設計の基礎を解説する。Part1では，基本設計を取り巻く環境の変化を改めて示したうえで，基本設計とは何か，ITエンジニアが身に付けるべく基本設計のスキルとは何かを提示する。Part2とPart3ではそれぞれ，DOA（データ中心型アプローチ）とオブジェクト指向による基本設計の基本を解説する。さらにPart4では基本設計で用いるパターンを，Part5では基本設計フェーズのドキュメントのレビュー方法をそれぞれ取り上げる。 Pa
要求定義の方法論を知る【前編】：DOA型要件定義の実際
日本IBMのシステム開発プロジェクトで多くの実績を持つDOA（データ中心型アプローチ）型の要件定義手法を解説する。「いまさらDOAか」と思う読者もいるかもしれない。しかし，DOAはあらゆるプロジェクトに応用できる極めて基本的なアプローチである。基本をしっかりと押さえて欲しい。 「いつまでたってもユーザーインタフェースが決まらない」，「設計の段階で機能が追加され，開発範囲が膨れ上がった」，「テスト段階に入ってからも仕様変更が多発する」，「システム・テストの中盤でデータベースが変更され，すべてのテストをやり直さなければならない」…。システム開発ではこうした声があちこちのプロジェクトで聞かれる。なぜこのような状況がいつまでも改善できないのか。結論から言えば，これは要件定義のやり方にそもそもの問題がある。 本来システム開発プロジェクトでは，予算，期間，開発の優先順位に見合った最適なスコープ（開発範
トランザクションデータ（とマスターデータ）について思うところ - 急がば回れ、選ぶなら近道
業務系のデータ処理では、大きくはトランザクションとマスターに分かれる。 マスターデータは特に、モデルや制御の方法が何かと面倒くさいので、よく議論になる。「マスターデータの管理の手法」というセミナーまで定期的に普通に開かれることも多い。他方、トランザクションデータ（以下TXデータ）は、普通に受け渡しのデータなので、フラットにダラダラ書いておけばよい、という扱いが大抵になる。そもそもER志向でモデルを設計すると、ほとんどは図面はマスターで占められ、TXデータはやたらなんか大量のフィールドを持つ大きなクラスがあるわいね、という扱いも多い。 あと、設計の観点からいうと、ERベースだとマスター設計が花形になる。まぁわかりやすいし、設計作業がしやすい。マスターは「構造」になり、TXデータは「構造」になりにくい。設計者は「構造」が好きだ。良くできた設計は確かに堅牢で、一定の変化にも追随できる。ある種の「
小売業における個別原価法とシステムとその先に - 急がば回れ、選ぶなら近道
まず小売業の利益計算の基本的な会計処理は売価還元法になっている。ありとあらゆる原価法の中でもっともザルで、かつ、いい加減な方法の一つである。端的に言えば、一定のカテゴリーベースでの売価の総額と仕入の総額を総計して、原価率を算定して、その率をもって利益を算出する計算方法になる。また、基本的に棚卸法になるため、実際の棚卸を行い、原価計算期間終了時点での在庫金額を確定させないと、利益が算出されない仕組みである。 現場感覚でいうと、値入率（事前想定粗利率）から、実際のロス率を差し引いても、粗利率（事後達成粗利率）に一致しないため、直感に反するオペレーションになる。このため、数字にしっかりした人間であればあるほど、数字を信頼しないというモラルハザードな仕組みになっている。さらに、そもそも小売流通業の税前利益率は2-3%を達成できれば“優秀”であり、細かい利益率の管理が必須である。バイヤーレベルでは、
いわゆる仕様と業務例外について - 急がば回れ、選ぶなら近道
最近とにかく、移動が多いので、その中でちょいちょい考えたことをまとめておきます。まずは仕様の理解の仕方とか、業務例外とか、押さえておきましょうという視点から。別にこれが正解で必須というわけではないので、あくまで個人の経験をまとめただけです。 モデリングとか、なんというかそういう高尚な話ではなくて、実際に仕様をまとめるときに、現実的に落ちる穴を、経験的に書きます。大抵のプロジェクトでは、仕様が固まらずに、または手戻りが発生して酷くコストが膨らむということがやはり多いわけで。理屈はともかく自分の経験的な対策案です。 （なんというか、開発方法論や手法・ドキュメントのまとめ方は、なんとかBOKから始まって、アジャイルや押しくらまんじゅうやらでいくらでもであるのですが、その一方で丁寧な要求定義や設計それ自体ができる人材は、むしろ急激に減っているような印象すら受けます。海外からの翻訳や輸入はやたらと多
システム開発の王道を極める
| トップ扉 | 思考支援 . ネット革 . ＵＩ考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言？ | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 | ソフトウェアを中心としたシステム開発では、規模が大きくて複雑なほど、いろいろな技術が必要となる。高度な設計技術はもちろん、分析技術や管理技術などもだ。これらの技術を活用できれば、難易度の高い開発でも成功の可能性が高まる。本格的なシステム開発に役立つ技術を、活用ノウハウも含めて紹介する。 ・システム開発には様々な技術が必要 ・力ずくから
【連載】今さら聞けない RFPによる調達&提案ガイド | エンタープライズ | マイコミジャーナル
Copyright (C) Mainichi Communications Inc. All rights reserved. 掲載記事の無断転載を禁じます
沖縄・浦添市の内製回帰事例から学べること - GoTheDistance
内製回帰厨としては嬉しい事例が発表されていた。 asahi.com（朝日新聞社）：ＩＴシステム、市職員が作る 沖縄・浦添市、コスト削減 - 経済を読む - ビジネス・経済 ここまで思い切って内製に舵を切った事例はなかなか少ない。記者の眼 - 見積もり2億円のIP電話を820万円で構築した秋田県大館市から学べること：ITproという事例もあり、全国の行政機関で内製回帰事例が増えているのは喜ばしいことだと思います。 内製回帰事例を見ていて思うのは、自分たちでシステムを組んでいるが故に｢内製｣と｢外注｣の判断軸がとても明確になっていること。つまり、自分たちの業務を棚卸して、改善・再設計をじっくり行った上でシステム化するポイントがブレることなく抑えられている。何は無くとも、業務の棚卸がとても重要。 余計な手続きが減ればシステムはそれだけ安くなる。「なぜ、ここでその作業が必要か」。コンサルタント会社
ダウンロード | 株式会社データ総研
業務ナレッジを共有・継承するためのデータモデリング 待ったなしのレガシーシステム対応を前に急ぐべき人材の育成 先送りしてきたレガシーシステムの対応、特に業務仕様の可視化と共有をどうしていくべきかお悩みの方々に向けて、業務ナレッジ継承のためのデータモデリングとその有効性について、その概要をお示しします。 詳しく見る 「データ活用者のためのデータマネジメント」講演資料 マイナビ主催イベント「TECH+ Business Conference 2023 ミライへ紡ぐ変革 TECH+ データ活用 Week」での講演資料をダウンロードいただけます。 詳しく見る DX時代の重点課題！！マスタデータ管理を早急に実現せよ マスター統合セミナー 講演資料 2021年11月まで開催されていた第一版「DX時代の重点課題！！MDM（マスタデータ管理）を早急に実現せよ マスター統合/コード統一/MDMセミナー～統合
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
システム導入において知りたい、知っておきたい情報集！★ビーコネクト
「システム導入.com」は、システムを導入する側、システムを構築する側含めた システム導入において重要なポイント、情報を記載した情報サイトです。 また、コンテンツにおいては、実際のシステム導入の現場において提供している 全体タスク表やWBS、TRMなどのテンプレートや資料サンプルなどを掲載していき ますので、システム導入の際に是非活用ください。 【人気コンテンツ】 システム導入においてWBS（Work Breakdown Structure）による作業タスクのブレークダウンは 必要不可欠ですが、WBSのフォーム（雛形）やサンプルは意外とありません。 実は私も昔、探したのですが見つかりませんでした。そういったこともあり、現在、私の会社 で使っているWBSのフォーム（雛形）を掲載したのですが、とにかくこのコンテンツへのアクセス が多いです。 皆様のシステム導入、プロジェクト運営において有効活用
IEEE 1471 Websiteについて
ビューポイントを主題とした標準にIEEE 1471があります。 タイトルは “Recommended Practice for Architectural Description of Software-intensive Systems” で viewpoint という単語は含まれていません。viewpoint を用いたアーキテクチャ設計を行う場合、viewpoint をどのように決めれば良いかを検討確認する場合に役に立ちます。この標準は ISO に提案され国際標準への道を歩んでいます。 この IEEE 1471 の Website があります。 ANSI/IEEE Standard 1471 :: ISO/IEC 42010 現在 ISO/IEC JTC1/SC7 で国際標準に向けての作業が行われており、本家の IEEE でも検討グループが設けられています。
BABOK 2.0を読んでみよう - ＠IT情報マネジメント
ビジネスアナリストも基礎能力が大事 連載：BABOK 2.0を読んでみよう（6） 今回はビジネスアナリストに求められるスキルセットをまとめて定義した知識エリア「基礎コンピテンシ」やBABOK認定資格を紹介する
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マイコミジャーナル
ソフトウェアエンジニアのためのホームページ Presented by System Creates Inc.
IBM Developer
