昨今の流れとして、システム開発における標準表記モデルである、とされるＵＭＬ...]]> Fri, 08 Feb 2008 16:02:01 +0900 http://japan.cnet.com/blog/ochikobore/2008/01/31/entry_25004685/ システム開発作業において作成され、整理されたビジネスルールがまとめられて、

業務ルール集(ビジネスルールブック)

として活用されるようになれば、ビジネスの観点からも、とても意味のあるものになる。

 それでは「業務ルール（ビジネスルール）を管理する」とは具体的に

http://japan.cnet.com/blog/ochikobore/2007/12/07/entry_25002701/

　においてビジネスルールとは、業務ルールの事であると書いた。

...]]> Tue, 08 Jan 2008 15:10:00 +0900 http://japan.cnet.com/blog/ochikobore/2007/12/28/entry_25003513/ 確実にいえることはどんな悲惨な状況に置かれようとも、
　システム担当になった（任命された）
　もしくは開発プロジェクトのリーダーになった以上、
　結果を出さなくてはならない。

　つまり開発プロジェクトを“成功”＊に導きかなくてはならない。

＊　この場合の“成功”とはプロジェクト終了時、自分が生き残り、
　　かつ動くコンピュー...]]> Fri, 28 Dec 2007 18:07:00 +0900 http://japan.cnet.com/blog/ochikobore/2007/12/20/entry_25003217/

http://japan.cnet.com/blog/ochikobore/2007/12/19...]]> Thu, 20 Dec 2007 11:30:00 +0900 http://japan.cnet.com/blog/ochikobore/2007/12/19/entry_25003167/ ”落ちこぼれ”SE、システム屋とは？

　弱小ユーザーにおいて、昔前職でプログラマーとして働いた事がある、
　もしくは他の社員よりはパソコンが得意なばかりに
　システム開発プロジェクトのリーダーを任命された者、
　心ならずもシステム担当者にさせられた者。

　当然、最新技術をバリバリ使いこなすにはほど遠く、
　又、習得する機会も...]]> Wed, 19 Dec 2007 09:37:37 +0900 http://japan.cnet.com/blog/ochikobore/2007/12/14/entry_25003025/ 弱小ユーザーとは？　自分なりに定義してみたい。

「弱小ユーザー」とは

　→「ビジネスにおいて最大手ではなく、中堅以下。所謂中小企業が多い。
　　　当然システムに対しての能力は高くないし、ＳＩベンダーに対して
　　　力がある訳ではない。」

　　　一般的には中小企業が多い。

　一般的に、弱小ユーザーのオーナーは情報システ...]]> Fri, 14 Dec 2007 15:00:00 +0900 http://japan.cnet.com/blog/ochikobore/2007/12/07/entry_25002701/ それでは、まず最初にわかりやすいモデリングを行う上で

一見遠回りに思われるかもしれないが、実は業務上の取り決めを

明確にする為に重要な役割を持つ

　　 “ビジネスルール”（業務ルール）　　

　　についてふれてみたい。

“わかりやすいモデリング”こそが

システム開発、上流工程を成功に
導く鍵である。

では“わかりやすいモデリング”とはどのようなものだろうか？

“わかりやすいモデリング”ではまず、業務上の取り決め...]]> Mon, 26 Nov 2007 12:30:00 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/22/entry_25002019/

“わかりやすいモデリング”では、自然言語と図をうまく組み合わせて成果物を作成してゆく

それでは何故、自然言語だけでは駄目なのだろうか？
自然言語は、特に同じ言語を話す...]]> Thu, 22 Nov 2007 10:50:01 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/20/entry_25001907/ システム開発、特に上流工程を成功に導くには

　オーナー及びエンドユーザーが理解しやすい形で
　コミュニケーションをとっておく必要がある.

　では、具体的には、どのような手段、手法を使えば良いだろうか？

　おそらく難しいシステム屋の言語や、

　自然言語のみに頼るようでは
　成功の確率は激減するだろう。
　お互...]]> Tue, 20 Nov 2007 08:55:31 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/16/entry_25001738/ 現在、システム開発プロジェクトの失敗の要因

として大きいのが
　　　　　　（いや業務を遂行していく上でもかな)
　コミュニケーションの乖離だ。

　　　システム屋と業務屋、

　　　　という分け方だけでなく
　　　ベンダーとユーザー、
　

Fri, 16 Nov 2007 16:46:23 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/15/entry_25001681/ 本稿の基本的なスタンスを書いておきたい。

自分は、

どんな高尚な理論を持つ技術でもわからなければ、

できなければ意味がない、
　　　　　　　　　　　と思っている。

　では,どうするか

　?わかるようにする
　?わかる表現を使用する。　

　　　　　　　　のどちらかしかないだろう。

...]]> Thu, 15 Nov 2007 13:41:29 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/14/entry_25001635/ 「コンピテンシー」という言葉を自分なりの言葉で置き直すと

　「できる人の行動」

　　　もしくは

「できる人を観察し行動を分析したもの」
　という事になる。（違ったらすいません。）

　「できる人」を真似て行動に移すというのは、

とてもいい事だと思うが、
　（とても冷たいようだが）

全ての人に...]]> Wed, 14 Nov 2007 12:22:32 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/13/entry_25001583/ 上流工程は開発プロジェクトの成否を左右する

まさに「頑張り処」

　　　　だと思う。

では、具体的にどのような事に気をつければ良いだろうか。

　　

「現場の人間は

Tue, 13 Nov 2007 13:16:43 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/12/entry_25001515/ 確実に言える事は、

上流工程はどのように悲惨な状況に置かれようとも、
歯を食いしばってでもしっかりやる必要がある、

という事だ。

厳しい状況に置かれている”落ちこぼれ”システム屋

であろうとも・・・...]]> Mon, 12 Nov 2007 11:15:16 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/09/entry_25001384/ 上流工程を成功に導くポイントの２番目

　【業務のプロ】について

  http://japan.cnet.com/blog/ochikobore/2007/11/08/entry_25001324/<...]]> Fri, 09 Nov 2007 08:54:20 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/08/entry_25001324/ 上流工程を成功に導く為に、自分なりに思いついた事を

以下にあげる。

　まず、【要件について】

上流工程を成功させるポイントは要件をうまく

整理する事だ。　（当たり前の話だが・・）

　要件とは、
　何を作るべきか、を明確にし、具体的な項目として
　整理されたもの、
　　　　　を指す。

<...]]> Thu, 08 Nov 2007 08:57:42 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/07/entry_25001253/ ＩＴ基盤の整備について、私見を述べさせていただく。

まず、どうであろうと、今後のＩＴ基盤をどうすべきか
については、自社の人間が中心になって脳味噌から
血が吹き出る位に考えに考えて決めていく以外にない。

その際、最初にやらなければならないのは

日経コンピュータより抜粋

「古いシステムを支えられる人材は少なくなる。 Wed, 07 Nov 2007 09:08:31 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/05/entry_25001087/ 巷では「勝ち組」「負け組」等、収入格差が開きつつある
現状に対する議論がなされている。

ＩＴ業界に目をむけてみると、
大手ＳＩｅｒや外資系に勤務しているマネージャークラス

年収　○千万円から○億円で能力給の比率が高い　

　　　　　　　　　　の人間もいる一方

弱小ベンダー（いわゆる下請け）

　　　　　　　...]]> Mon, 05 Nov 2007 08:54:15 +0900 http://japan.cnet.com/blog/ochikobore/2007/11/02/entry_25000910/ 上流工程においてやっておかなければいけない事がある。

当たり前かもしれないが、使えるコスト、投資効果を明確に

しておこうという事だ。

そして開発終了時には、できる限り費用対効果を金額ベースで

検証にしよう。
（これも当たり前っていえば当たり前だが）

それが、あとあとになって、
実際の投資を行うオーナーに...]]> Fri, 02 Nov 2007 13:25:54 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/31/post_eab8/ 実際に地獄を見かけた元１ユーザーとして、
経験談を述べさせてもらうと、

　
ベンダーの力を借りようともあくまで
ユーザーが主体的に業務分析に参画し、
かつ自分達が理解し、納得できる成果物を
きちんと仕上げる、又は仕上げさせるべきだ。

当たり前の事だと思われるが、

世の中ではきちんと認識されていない。<...]]> Wed, 31 Oct 2007 08:34:42 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/30/post_0351/ 先日、コンサルタントに関する笑えない話として
　同一ベンダーのコンサルタントと開発部隊が
　もめてシステム開発プロジェクトが暗礁に
　乗り上げかけた事を書いた。

　http://rblog-ent....]]> Tue, 30 Oct 2007 14:30:06 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/26/post_bd6a/ 悩んでいたユーザーは、ここはベンダーの主張を信じる事にして、
業務分析をベンダーのコンサルタント部隊と行う事にした。

作業はエンドユーザーにヒアリングを実施したり、

といった月並みなものであった。

成果物を見てみると、きれいなフォーマットに

一応は整理されてまとめられてはいた。

正直なところ、かなり抽象的かなとは...]]> Fri, 26 Oct 2007 08:44:49 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/25/1_6e90/ 業務分析に関して、私が実際に経験した

笑えないジョークのような話を以下に披露する。

業務分析の重要性は認識しながらも

　　　政治的な問題（？）

で苦悩するユーザーにベンダーの

　「業務分析をちゃんとやっておかないと

　あとで大変です。

　きちんとリソースを投入すると

　ＸＸ円かかり...]]> Thu, 25 Oct 2007 08:45:44 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/24/post_e615/ あくまで業務は経営とリンクしていなければ意味がない。

当然、業務を支える情報システムも同様である。

オーナーの考えを中心に置き、

ユーザー、エンドユーザーの納得し、

満足する形をつくる事を目指す方が良い。

例えオーナーの意識が低い場合でも、

様々な断片のような考えをつなぎ合わせて

　　　　　　“...]]> Wed, 24 Oct 2007 12:04:38 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/23/post_44da/ 上流工程において、一番ウエートを占める作業が

                       「業務分析」

            &nb...]]> Tue, 23 Oct 2007 08:42:05 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/22/post_3fec/ 「論理モデルと物理モデルの内容が乖離していると

モデルの保守は極めて難しくなる」
　
事を頭に入れて、よほどの物理的な要件以外は

１つのモデルの作成・維持（開発・保守）に努めるべきだ。

と書いた。

では、どうすればよいだろうか？

論理モデルの範疇を少し広げて解釈すればよい。

本来の論理モデ...]]> Mon, 22 Oct 2007 13:46:17 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/18/post_c657/ 別の視点から考えると、

下流工程における成果物（物理モデル）は
あくまで論理モデルを実装する為の、
最低限の物理要件及び詳細設計
の追加程度にしておいた方が良いという事になる。

ハードウエア環境も昔とは違ってデータベース、ＣＰＵ、ネットワーク
どれをとっても実装の為に論理モデルを「くずす」必要がない程に
性能の向上...]]> Thu, 18 Oct 2007 08:47:43 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/17/post_1b5b/ 上流工程の成果物＝論理モデル　

実装技術に左右されないモデルを作る事により、
保守フェーズでも有効である、とされている。

論理モデルと物理モデルの内容が
乖離している場合に、
物理モデル（実際に動いているシステムの仕様）が
変更されていく課程の中で実際には直接実装に

影響を及ぼさない論理モデルまで保守、変更 Wed, 17 Oct 2007 09:13:35 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/16/post_7efd/ 上流工程において何を作るべきかという方向性を明確にした上で
業務を分析し、論理モデルを作っていこう、

とここまで書き進めてきたが、

一般論としては今まで書いてきた通りであるし、自分もそう思っているの

であるが、懸念材料がない訳ではない。

懸念材料とは、２つのモデルの作成・維持が果たして実現可能であるか
どうかという点...]]> Tue, 16 Oct 2007 08:41:19 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/15/post_44ca/ 論理モデルを作成する開発工程を上流工程、
物理モデルを作成する開発工程以降を下流工程
と位置付けると

論理モデルとは上流工程のアウトプットであり、
物理モデル（＋α）とは下流工程のアウトプットであるといえる。

いいかえれば論理モデルは下流工程のインプットに成り得ない

と話にならない。

よく業務分析・概要設計...]]> Mon, 15 Oct 2007 09:54:35 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/12/post_1b56/ 何を作るかを明確にした成果物を「論理モデル」、
どのように作るかを明確にした成果物を「物理モデル」

と定義してみた。

少し別の見方をすると、

論理モデルとは実装独立のモデルであり、
物理モデルとは実際の実装モデルである、

　　　　　　　　　　　とも言われている。

ビジネスシーンの変化に対応可能な仕組みを...]]> Fri, 12 Oct 2007 13:12:32 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/11/post_bc05/ ユーザーにとって良いシステムとは？

　・ビジネスが円滑に運営できる
　・ビジネスシーンの変化に迅速に対応できる　
　・長く使える
　事であろうと思われる。

良いシステムを開発する為には

どのように作るべきかを考える前に
何を作るべきかを明確にする

   事が重要だ。

<...]]> Thu, 11 Oct 2007 13:32:35 +0900 http://japan.cnet.com/blog/ochikobore/2007/10/08/post_9b78/ ちょっと、上流工程について、細かい話をさせて欲しい。

”上流工程”の定義は色々とあるし、各自の認識も

異なる部分も多いだろう。

　“上流工程”とは、

「論理モデル」を作成する工程である、
　ともいわれている。

ちなみに「モデル」とは現実世界を抽象化して表現したもの

を指す。
（例えばモデル...]]> Mon, 08 Oct 2007 14:13:30 +0900