富士通、30年の経験に基づく要件定義手法を「Tri-shaping」に体系化 | エンタープライズ | マイコミジャーナル
富士通は、業務プロセスの分析・改善提案とICTシステムの構築における要件定義手法を「Tri-shaping」として体系化し、発表した。4月からは、同社が手掛ける売上3億円以上のプロジェクトには原則適用するほか、2011年度上期より、富士通グループ向けに研修を実施する。また、2011年度下期からは、顧客向けに有償の研修サービスとして提供する予定。 今後の展開 富士通 システム生産技術本部 本部長 柴田徹氏 富士通 システム生産技術本部 本部長 柴田徹氏は、「お客様には、経営視点で業務プロセスを変えられる人がいない、業務視点でICTシステムを変えられる人がいないという問題がある。そこで弊社は、人に頼らないシステムによって改革力を上げるため、本製品をリリースした」と、今回、要件定義を体系化した背景を語った。 同社では2007年から上流工程の品質向上や形式品質の向上に、2009年からは内容品質の向
満足せる豚。眠たげなポチ。:「業務システム開発学科」開講
前エントリの続きで、「業務システム開発学科」の単元を挙げてみる。 これがないと作れないという要素をボトムアップ（上流・下流からいくとボトムではないけど）で挙げていったつもり。（「エンタープライズ・コンピューティング学科」は要らぬ誤解を招きそうなので、止めておく。） やりたいこと・やるべきことを決める (Why/Whom/What) 現状のヒアリング 理想形のヒアリング 目的の確認 誰が使うのか どのようなものを作るのか 計画を立てる (When/Where/Who/How much/How) スコープを決める 実現方法の検討 見積り スケジュールを決める 担当を決める 道具を知る (How) コンピュータサイエンスの基礎 (設計しテストするのもプログラミングの一部としてここに入る) ネットワークの基礎 コンピュータアーキテクチャの基礎 OS の基礎 RDB の基礎 アプリケーションのための
満足せる豚。眠たげなポチ。:「業務知識」は目的じゃない
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。 スーパークリエイターがSI業界で即戦力になれない理由 もう業務知識幻想は止めようよ。必要なのは課題を適切に設定する能力とその解決に向けてプロジェクトを円滑に進めるプロジェクト遂行能力。その最低限の基盤になるのがコンピュータサイエンスなり、プラットフォームの知識と経験でしょう。（自分も弱いのを棚に上げて言うけどさ。） 一番性質が悪いのが「業務知識」だと思うよ。この言葉も意外に確かなものを伝えていて、所詮知識なんだよね。別にそれを使って仕事をしたわけではないから、業務スキルではなく業務知識。 「業務知識」の意味するところっていうのは、『開発チームの一員としてドメインに精通している（少なくとも文化としての用語がわかり、それが
はてなブログ | 無料ブログを作成しよう
早春とフィルム写真 カラーネガフィルムとはなんとも不思議なメディアで、その季節の陽光だとか湿度が写真に乗ってくるような気がする。 冬の写真は暗くかさついているし春の写真は霞がかって見える。夏の写真は湿度100%に近い空間を貫いてくる強い太陽光がフィルムの乳剤面に記録されてい…
「トレードオフの概念は日本に無いのか」 三菱東京UFJ銀のシステム一本化報道に思う：NBonline(日経ビジネス オンライン)
「三菱東京UFJ銀行は5月12日、情報システムの一本化をいよいよ始めたが、大きなトラブルは無く、年末まで続く一本化作業はまずまずの滑り出しとなった」 こういう書き出しと論旨の一文を書いて公開したら、読者の皆様の多くは「テレビや新聞は、12日から13日にかけてシステム障害が発生と大々的に報じていたではないか」と首をひねるに違いない。「まずまずの滑り出し」と筆者が書きたいのは、システム全体を見渡すときちんと動いており、一部で発生した不具合を当日すぐに修復できたからだ。 筆者は4月23日付本欄で「失敗を期待するマスメディアを裏切って、三菱東京UFJ銀は一本化プロジェクトを成功させると確信している」（関連記事「失敗を待つマスメディアの監視下、システム一本化を始める三菱東京UFJ銀行」）と書いた。続く4月24日には、IT（情報技術）専門家向けウェブサイト「ITpro」のコラム欄に「この巨大システムは
開発抽象化レイヤ - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年4月11日 火曜 若い男が町にやってきた。彼は見かけも悪くないし、ちょっとは金も持っていた。 過去のことについてはあまり話したがらないが、血の通ってない大企業に長くいたらしいことは明らかだった。 彼は生まれつき人当たりが良く社交的で、自分に自信を持っていながら傲慢ではない。だから地元のプログラマーズ・カフェにある求職の掲示の中からちょっとした仕事を見つけるのは、彼には簡単なことだった。しかし保険データベースプロジェクトや、主婦向けの飾りだらけのWebページや、会計計算エンジンといったものには、やがて興味をなくしてしまった。 １年もたつと、彼の慎ましい生計を1年支えられるくらいの蓄えができた。それで贔屓にしてくれるアルザス人へのコンサルティング仕事の後、食料品店の上にある自分のアパートの陽の当たる部屋にコンピュータを据え付け、選りすぐったツ
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
満足せる豚。眠たげなポチ。:業務システム開発でドキュメントを作ることについて
職場でここ３〜４ヶ月の間、システム再構成のためのドキュメント化プロジェクトというのを進めてきた。その中で『ドキュメントを書く』ということに対する意識が随分自分の中で変化したので、メモしておく。 まずは経緯から。 そのシステムは、いわゆるレガシーなシステムで、十数年来の歴史を持つ。これまで基盤が多少変わることがあっても基本的にソフトウェアアーキテクチャ（どのような単位で機能をモジュール化するか、どのように機能を抽象化し変化に対して柔軟にするか）に変わりはなく、作った当初の設計にツギハギしてメンテナンスを続けていた。 元々は、一体何をすれば増員以外の手段で開発量を上げられるかということを議論していた。現行のアーキテクチャのままでは求められる開発期間とバージョンアップのサイクルに対して近い将来限界を迎えることが明白であったためだ。 今のアーキテクチャや設計に問題があり、メンテナンス性を大いに損ね
静的オブジェクト指向は設計者が苦労を背負込むシステム
2009-09-26 北陸Scala第1回開催 2009-04-04 第十四回java-ja勉強会 - 第1回チキチキ 地方巡業withひがやすを飲み会in富山開催 2009-03-20 わんくま大阪勉強会#28 「ジェネリクスを使おう！」 2008-11-08 わんくま富山勉強会#1 開催 2008-08-09 わんくま東京勉強会#23 「C#登場前夜」 2008-04-01 *で始まるタイトルはエイプリルフールネタです 2008-01-26 わんくま東京勉強会#16 「ライブプログラミング」 2007-12-08 わんくま名古屋勉強会#1 「わんくま初めてのJava」 2007-07-28 開店 みねこあさんのところで挙がっていた、 静的オブジェクト指向と動的オブジェクト指向の軽さについての話題から。 Javaは経済的事情をうまく捉えて普及した プログラミングの効率と経済で書いていると
チームリーダー日記 : 「グループ内で締め切りタイミングをずらす」ことの狙いと効用
各開発メンバーの 締め切りタイミングを ピッタリ一致はさせないでおく。 ■全員の締め切りが一致してる場合 全員が同時にピリピリしてきて、 チーム全体でのバッファが急速に無くなっていく。 で、どんな対処案も取れなくなって、ギューっとなっていく。 ┏━┳━┳━┳━┓ ┃空┃２┃14┃３┃ ┣━╋━╋━╋━┫ ┃12┃９┃15┃８┃ ┣━╋━╋━╋━┫ ┃１┃６┃７┃13┃ ┣━╋━╋━╋━┫ ┃11┃10┃５┃４┃ ┗━┻━┻━┻━┛ #空きが２つだと加速度的に楽になる。 こんな風に１箇所空いてて そのスペースを使って各マスを動かして 数字を並べるパズルがあります。 特にチームリーダとかを経験してる人は わかると思うけど、 何かしらの対処策を取ろうと思うなら 常にバッファを用意しますよね。 ☆その１ 一番難しい箇所は２番手の人に担当させ、 １番手の人はそこには投入しないで 含み益にしておく。
修正可能なシステム 番外編１ 出来る開発と出来ない開発の違い - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） ここで 「その体系から見ると、できる開発と出来ない開発がみえてくる」というのは、修正可能なシステムでかきます と書いたので、「修正可能なシステム」の番外編として、その「出来る開発と出来ない開発の違い」を書きたいと思います（なお、番外編１の１は、べつに、２、３と予定しているわけでなく、もし今後出てきたら、１、２と続けようと思っているだけです） ■情報処理の体系 まず、「その体系から見ると」の「その体系」から説明します。 それについては、情報処理試験ぐらいのお勉強のポイントの体系化の「理論の階層と細分化」に書いた、 これは、情報処理という概念の２つの側面をあらわす。 情報処理とは、情報（データ）を、処理（プロセスを動かす、プロセッシング）することといえる。 ってことに関連する。 つま
オンスケジュール＝崖っぷち - 極北データモデリング
転職して分かった、進捗管理という面白くない作業を楽しくやる方法について。 タイトなスケジュールを組んで、そこからの遅れをチェックするから、楽しくないし、遅れが隠蔽される。 ダルダルにゆるいスケジュールを組んで、1週間以上前倒しにできているかどうかをチェックすれば、みんな遅れていることを隠さないので早めに手が打てる。 タイトなスケジュール＆遅れチェックだと「2日遅れです」と言わなくてはならないところを、だるいスケジュール＆1週間前倒しチェックなら「3日前倒しです」と言えるので気分がいい。 情報量はどっちの言い方でも同じだから、気分のいい言葉を使えばよい。 だいたいオンスケジュールというのは崖っぷちに居るということで、カゼ引いたり障害発生したりしたら即遅れてしまうのだから、「オンスケです」という報告がよいニュースのわけがない。「前倒し」という名前を付けたバッファの減少傾向を見張って、オンスケジ
BeInteractive! [「これコミットして大丈夫なのかな...」と考える前にコミットして欲しい]
最近、「こんなのコミットしちゃっていいのかな...」とか「本当に勝手に修正しちゃって大丈夫なのかな...」とか悩んでいる人を見かけるのですが、そんな風に悩む前にコミットして欲しいと思います。良いとか悪いとか、使うとか使わないとか、それは周りの人やユーザーが決めれば良いと思います。コミットせずにしまい込んでしまったら、何かが起きる可能性はゼロです。 そうは言っても、あまりこういうのに慣れていない人にとっては、色々と不安もあるようなので、それを解消する為にちょっとまとめてみました。 コミットを恐れないで欲しい どうも、コミットを「かなり重大な儀式」のように感じている人が多い気がするのですが、もっと気軽に、言うなれば「Twitterで発言する」ぐらいの感じで捉えてもらいたいと思います。別にどんな小さなコミットでも良いし、何連続でコミットしようが、誰も咎めたりしません。 実際、僕も最近はA
伽藍とバザール
Eric S. Raymond 著 山形浩生 YAMAGATA Hiroo 訳 リンク、コピーは黙ってどうぞ。くわしくはこちらを見よ。 プロジェクト杉田玄白 正式参加作品。詳細は http://www.genpaku.org/ を参照のこと。 1999/07/30版、1999/08/16訳更新, 2000年5月2日更新 原文の最新版はhttp://www.catb.org/~esr/writings/cathedral-bazaar/にて各種フォーマットで入手可能。 翻訳の pdf 版はhttps://cruel.org/freeware/cathedral.pdfにある。 翻訳の PostScript 版 (tar+gzip圧縮）はhttps://cruel.org//freeware/cathedral.tgzにある。 第 2 部 「ノウアスフィアの開墾」 (Homesteadi
「ソフトウェアの部品化」が失敗する理由 ― ＠IT
経済産業省のとある外郭団体の委員をしている方と話をしていたら「我が国のソフトウェア産業を改革するためには、ソフトウェアの部品化を推進しなければならない」と話していた。うーん……ソフトウェアの部品化かぁ……。正直、頭をよぎったのは1980年代後半に国内のソフトウェア部品の集積を目指して立ち上げられたが、失敗した「Σ（シグマ）プロジェクト」だ。 Σプロジェクトから20年の歳月を経て同じコンセプトが出現するには理由がある。日本の輸出を支えている製造業で、製品におけるソフトウェアの比重が高まるに伴って、業界全体がソフトウェア・エンジニアの不足および、ソフトウェア関連の障害の多発に悩まされているからである。 外注先企業が作ったソフトウェア障害に悩まされている製造業の視点から見れば「なぜ、ソフトウェアはこんなにトラブルが出るのか？ 部品化して、それぞれの部品の品質チェックをもっと厳しくし、その上で再利
プログラム設計書の良い部分と悪い部分 - GeekFactory
設計書の定義は、おおよそ開発標準や慣例で決まっています。逆に言うと、設計書名やその中身を書くと社名がバレるかもしれません。だからみんな書きたがらないのでは。中でもプログラム設計書はベンダによる違いが大きく、結果的に技術力の差となることが多いです。 前回のエントリでは、プログラム設計書のすべてが不要と言っているわけではありません。 プログラム設計書には、良い部分もあります。内部設計では表現できない設計思想が書いてあるので、変更容易性が向上します。例えば、クラス図からは具体的にどんなデータを扱って処理しているのか読み取れます。そもそもの話ですがインタフェースが決まらないと分業ができませんので、他所と共有するメソッドは設計書に落ちている必要があります。小規模だと細かいメソッド名まで決めない場合もあるし、逆にprivateメソッドまで決めてから実装する場合もあります。 ただ、言語レベルの記述方法ま
yossy/AS3Unit - Spark project
AS3Unit (English is here) ソースコード / ライセンス / ドキュメント / ASDoc AS3Unit AS3UnitはActionScript?3.0上で単体テストを行うためのフレームワークで、JUnit4の移植です。ActionScript?3.0の新機能であるネームスペースを用いる事で、POJOによるテストケースの記述を可能にしました。 AS3Unitを用いる事で、効率よくテスト駆動開発を行うことが出来るようになります。 最新情報 2008.04.23 AS3Unit for Async 1.2 をリリースしました。 2008.04.15 AS3Unit 1.2 FlexSDK3 対応版をリリースしました。 2007.09.17 AS3Unit 1.2 をリリースしました。リリースノートはこちら 2007.04.04 AS3Unit 1.2-beta1 を
はてなブログ | 無料ブログを作成しよう
晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…
修正可能なシステム その２ 背景－修正のジレンマ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズ化してしまった？修正可能なシステム。 前回は、概要として、何をやるかについて書きました。 本来なら、その説明をするべきですが、その前に、どこが問題で、このような手順になっているのか？という背景の話をします。 ■データに関する修正をかける場合 問題は、データ構造に対して、削除、あるいは意味が変わったり、型が変わったりする修正で起こります。 （価格を、整数から実数へ、文字２バイトを１バイト、有効期間項目をなくすなど・・） この場合、修正後のプログラムを作るには、まず、データの構造を修正しないといけません。 とくに、データ構造に追加がある場合、追加しないと、プログラムが作れないので、追加します。そうすると、同時に項目を変えないといけない場合（つじつまが合わなくなるので）、削除や
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
チームリーダー日記 : コード量＝借入金の額