今年はチャレンジしましたか

公開日時： 2007/12/27 11:30
著者： 草木生（そうもくしょう）

ようやくDOA（データ中心アプローチ）を捨てられたんだと思う。
捨てようと思ってから４年。

考え方そのものも変えなくてはならなかったが、ようやく頭の中もオブジェクト指向に
なってきたような気がする。
そして、DOAの本当の良さも分かったと思う。

捨てることが得ることだと誰かが言っていた。
本当にそう思う。

来年は大きなオブジェクト指向開発をサポートする。
嬉しい年になるだろう。

開発者の逼迫−主にJAVA

公開日時： 2007/04/22 10:14
著者： 草木生（そうもくしょう）

ここのところ、１月半ばから４月初めまで例によってプロジェクト異動、未経験業界の学習で更新をする暇はなかった。

一応昨年末で、今年から始まる２年、数十億の開発の前始末は目処がついたので、今年の案件を探していた。
当初は、大規模DWHなどに行くような予定もあったが、結局新事業立上げのサポートで落ち着いた。長ければ２年ほどのお付き合いになるだろう。

それにしても、まだまだ知らない業界がある。
ブルー・オーシャンはどこだろうか。

開発者不足

昨年夏くらいから、今年の人手を調達するべく裏で動いていたが、本当にいない。
web2.0なんて望んではいないが、せめてJAVAのコーダが沢山欲しい。
モデリングをできる人もだ。
プロジェクトの中で育てられれば好いが、そんなに上手くはいかない。

人が少ないのは、相変わらず生産性が低いのか。
そうではなくて、集中だ。
同じ業界の人に聞いても答えは同じ、「できる人は手放さない。」
そりゃそうだ。
今は、コーダなりプロマネの指名が通るようになってきている。

今年も苦しい開発がそこら中で続くだろう。
オフショア、SOA、ＳａａＳ、発展の年になるが、日本人技術者は従来型の開発で疲れていくだけかも知れない。

全てのプロジェクトはユニークである

公開日時： 2006/08/21 11:25
著者： 草木生（そうもくしょう）

体裁を気にしている、と書いたら、携帯では見られたもんじゃないです、とのコメントが付いて少し驚いた。
webはPCだけで見るものではないのだと、あらためて気付いた次第である。
だからといって、携帯のための体裁を考慮しようとは考えないが。

相手、もしくは自分の端末に合わせた体裁を動的に整えてくれるブラウザなり、アプリサーバは誰かが考えているのだろう。ニーズでも良い、シーズでも良いので作ってくれることを願っているだけである。欲しければ自分で作れば好い。

話を戻して、当たり前だが、プロジェクトはユニークであるからこそ知恵が問われる。
ＩＴ業界にエンジニアリングがあるとすれば、その知恵がメソドロジであろう。
その知恵たる所以が、開発成果物を入れるリポジトリとの連動である。
進捗では、リポジトリ上のオブジェクトが埋められていくのが理想であるが、そうならないのが現実であり、終了しても埋められていないことが往々にしてある。

ただ、今後は検索技術のように、あるものを検索して関連を後付けできるようになることが予想され、リポジトリは再考を迫られると思われる。
設計、コーディングした開発成果物を格納していくのがリポジトリであり、メソドロジ毎に付属しているメタモデルである。
これがエンジニアリングとしての到達点だと考えてきたが、前述のように再考を迫られている。

業務システムの開発成果物、運用（改修）対象が画面、帳票、DB、コード、関数などであれば必ず管理される必要がある。
現在の開発では、プロジェクト進捗を管理するソフトウェアは利活用されておらず、基本はリリース管理と称して商用環境とほぼ同等の総合テスト環境を保持し、そこをもって構成管理としていれば上等であろう。

MSプロジェクトのスケジュール表に、イナズマ線を入れることが進捗管理だと思われては困る。成果物のバージョン管理をしてこそ進捗管理である。

ただ前述のように後付けでの管理も、既に現状のリソース（ソースコード、テーブルスキーマ）を入れて、関係性を取るツールからできないことではない。

システムを作るということ

公開日時： 2008/02/03 14:27
著者： 草木生（そうもくしょう）

社会保障カードなるものが出てきた。

制度疲労から、いや、制度そのものがまともに設計されておらず、屋上屋を重ねる結果となっている年金制度の解決策がこれだそうだ。
システムには仕組みという意味もあるが、壊れた仕組み・制度をコンピュータ上に組み直せるはずもない。

カードは紛失するし、盗難に遭う、毀損する。
頻繁に利用する方達はデジタルにやや乗り遅れた人たちである。
ハンディキャップも相当数いると考えられる。
ステークホルダと利用シーン、配布などの送付手段（そもそも配布するものなのか？）が十分に考察されているとは思えない。

原点に戻れば、個人の特定をどうするかという課題が出てくる。
社会保障番号なり、IDは必要だが配布する必要性はない。
もう少しスマートな生体認証ができれば、バックオフィスの問題となる。

システムへのエントリーが課題だ。

しかし、今回の年金問題は公務員共済には生じていない。
当事者意識のない公務員に年金問題を解決しようという意思も、熱意もないのが今回の年金問題の原因である。
彼らの仕事の評価指標に、国民へのサービス拡充、というモノは無さそうである。

どんなに民間が知恵を絞っても、公務員として評価されない仕事はしない。
虚しいのはそのせいである。

システム屋のプロスキル

公開日時： 2007/10/03 14:06
著者： 草木生（そうもくしょう）

残念ながら今回も編集部からの督促で書いている。
前回はいつ書いたか忘れるほど前である。

相変わらず、システムの作りに関して書かせてもらう。

業務システム開発は、乱暴に言えば、デコンポジション（分解→分析）とコンポジション（再組立・実装）からなるが、私が担当しているのは、デコンポジションである。
スキルパスでは、良く、コンポジション→デコンポジションとされるようだが、私の場合は当てはまらなかった。全く実装でのスキルが身に付かず、分析への転進で生き長らえてきたからだ。

このコンポジション→デコンポジションという考え方は、
(株)永和システムマネジメント 平鍋 健児氏が簡単に説明してくれている。

分析モデル→<設計>→設計モデル
↑　　　　　　　　↓
<分析>　　　　　　<実装>
↑　　　　　　　　↓
問題→<テスト>←　解

左下の問題からスタートして時計回りに進むのである。
そして、左を上流といったり、デザイン工程としたりするのである。
右が実装であり、下流とも称される。
SE、システムエンジニアはどちらを担当しているかというと、会社によって違うらしい（笑）。

双方を経験して思うところに、両者共通のスキルとしての「抽象化の扱い」がある。
分析は、現実の業務を抽象化することであり、その抽象化概念を実装するためにはコーディングという、抽象化の極地の技法を使う。

今の私の専門である左側の分析におけるスキルとして、ヒアリング能力を追加しなければならない。
ユーザ・業務のプロと会話して抽象化していくには、適切な質問を行い、回答を理解して確認できるというヒアリング能力が必要なのである。
もしくは、翻訳力か。

システム＝問題とすれば、実装は解に至るプロセスを記述するところにある。
これは、異なる事象から類似の原因を類推して、ユーザとともに確認作業を行うことに他ならない。

非常に抽象的な書き方になったが、メタモデルを扱っているとこうなるらしい。
機会があれば、ヒアリング能力の身に付け方を書いてみたいと思う。

さすが、放置国家ニッポン！

公開日時： 2007/06/16 16:20
著者： 草木生（そうもくしょう）

社会保険庁の年金システムは、見事としか言いようのないシステムである。
名寄せの仕組みがない個人台帳管理システムというのは凄い。

９０年代後半、社会保険庁のシステムはＮＴＴの独自仕様マシン（ＤＩＰＳ）から国産の汎用機に乗り換えを行っており、この時の開発というか、移行ベンダがＨ製作所、Ｆ通、Ｎ電気であり、数百億円の開発費が投入されたと聞く。
ユーザインタフェース、機能もそのまま、ただマシンと言語を入れ替えただけと聞いた。

従って名寄せの仕組みを組み込んでいないとしたら、ベンダの責任でもあるはず。
また金を払おうというこの太っ腹。
のべ１万人以上も参画したプロジェクトなんだから、誰かが報告して欲しいよね。
この業界はホイッスルブロワーが少なすぎるかも知れない。

ちなみに、業務オペレーションが崩壊している現場にコンピュータシステムは何の解決ももたらさない。今回の対処療法を短期的に見たとしても意味のないアクションだろう。
そもそも、ヒモ付いていない個人データをどうするの？
きっちり状況を説明してもらいたい。

システム屋はサービス業

公開日時： 2007/05/16 02:18
著者： 草木生（そうもくしょう）

システム開発をやっていると、仕事をする場所が１年ごとに違うのは当たり前だと思う。
顧客も変わる。
当然だが、チームメンバも変わる。
私もそうなってから２０年近く続いていて、年俸制だったり、契約だったりするので残
業代はない。

カットオーバの日がお別れの日であったり、もっと前にお別れすることもある。
仕事ができなかったり、チームと肌が合わなければ首になるし、首にもする。
それが日常の光景である。

ユーザから考えてみれば、必要なときに必要なだけ利用するのがサービスであろう。
人であれ、マシンであれ、そうなのだ。
開発ベンダがその人を雇うのは、継続的にプロジェクトを取れるからかも知れない。
コンサルファームでもプロジェクト評価で辞める辞めないを決める。

教育も手取り足取りは無い。
学ぶのは本人であるから、好きなアプローチをプロジェクトの中で取れば良い。
プロマネやリーダだとメンバのロールを決めることで、学習のきっかけを与えること
がある。

消耗品になるかどうかは、本人の問題でしかない。

もちろん、開発屋ではなく運用系だと３年なり５年のスパンがあったりもするようであ
る。
しかし、開発屋は２年も同じところにいれば充分なのであろう。
それが普通の話である。

Windows Vistaには辿り着けず

公開日時： 2007/02/09 15:05
著者： 草木生（そうもくしょう）

企業システムのＸＰからの変更だが、これはまだまだできない。
いつもと同じで１年以上は様子を見ないと、無理だ。

それに、企業の情報化投資はクライアントＰＣには向かっていない。
税金の関係で、「持たない」がコンセプトになってきてる時代に、あれほどリッチなクライアントＰＣには経費をかけられない。
ペンと紙と電卓にそんなに金はかけられないのだ。
（ホワイトカラーの生産性の問題が隠れている）

このところの税制がリース資産も対象にしたため、レンタルが一般的になってきているし、それなりにクライアントにユーザアプリケーションが乗っている状況がある。
それを解消するには、企業情報システムはシンクライアントに向かい、ＡＳＰでの業務システムが増えてくるであろう。
Windows Vistaへの変更など、まともなベンダーなら提案しないであろうし。

ソフトウェアもご存知の通り、無形固定資産、税金の塊である。
何故税金をこれほど気にするかというと、キャッシュで払わなくてはならないからだ。
どこまでも追い駆けてくる税金との闘いが、企業には課せられているのだ。
キャッシュフローが有っての会社であり、節税を考えながら情報システムも作ってきた。

お役所が、例えば社会保険庁が何百億もかけてシステムを作っても、税金が来ないのとは違う。費用対効果とはそこまでシビアなんだよ。

まぁ、Windows Vistaに変えるくらいなら、この際だから、クライアントＯＳは「超漢字」にすべきではないかな、日本としては。

（皮肉にしておこう）

こちらは私も参加しているオープンメソドロジ

http://www.openthology.org/

リポジトリ

公開日時： 2007/01/30 17:57
著者： 草木生（そうもくしょう）

MSが発売した久し振りのOSに付帯して、「家庭用中央リポジトリ」なる言葉が出てきた。
この意味がすんなりと理解できるものであろうか。

メソドロジとリポジトリは不可分

我々というか、メソドロジを扱うものにとってリポジトリは必須である。
メソドロジは最低でも開発の手順と成果物を扱う。
最近では、構成管理が代表的な呼び名であろう。
リポジトリは、システム開発の成果物を格納するシステム辞書・倉庫である。
従って、開発されたシステムは分解されて、いや、カテゴライズされ関係性を持ってリポジトリという倉庫に格納される。

格納のされ方は、例えば「販売管理」で検索をかければ、関係を持つテーブル・カラム・画面・プログラムまで引っ張り出せるのが理想である。
メソドロジを支えている土台のようなものであり、その構造を分からない限り、組換えは止めた方が良い。

そのプロジェクトのやり方もあるが、上記のようにテーブル・カラム・画面・プログラムまで入力されているのは稀である。
少なくとも、テーブル・カラムくらいは管理しているはずではある。
設計ドキュメントでも全文検索ができるが、運用に対して有効には成り得ないのが、「関係性を持って」の部分である。
インパクト分析ができないリポジトリでは意味が無い。

つまり、管理可能な部分まで開発ドキュメントを分解し、入力、管理する。
メソドロジはそれを司る。
要は、無意味な開発成果物を排除していることである。

リポジトリの語源

元々は、89年か90年くらいにＩＢＭ社が発表した「AD/Cycle」の中で提唱され、それまでのデータディクショナリなどの用語を拡張したものである。
その後は、ERPパッケージ、ETLツールなどにも必須の機能として付加されている。

今回の「家庭用中央リポジトリ」は、我々システム屋の「リポジトリ」とはまた違ったものである。
多分、「家庭用中央リポジトリ」には、コンテンツが動的に構築・蓄積されるところが違う点になるであろう。

本当に来るのか、２００７年問題

公開日時： 2007/01/04 11:25
著者： 草木生（そうもくしょう）

今年から入る基幹系システムの大規模再構築の地ならしが終わりつつある。
各プロジェクトマネジャに、コンセプト・標準化シナリオを引き渡していくのは、今月も半ば以降となる。
当然、リソース調達もベンダ各社に内示しているが、２００７年問題など聞かない。

繰り返される引継ぎ問題の一種でしかない

筆者がこの業界に入ってから、色々なシステムで同じ話を聞いてきた。
設計ドキュメントが無い、あの人がいなくなったらこのシステムは止まってしまう、当時の人がいないので分かりません、等々聞いてきた。
しかし、それでも大問題が起きたという話は聞かない。
なんとかなっている。

今はちょっとしたツールで、構成管理をできるし、インパクト分析もそこそこできる。
何を以て２００７年問題といったのか分からない。
プロジェクトマネジメントの話であるならば、今も昔もそれほど変わっていない。
むしろ現在の方がスマートに、チームワークで処している。

現場にも居ない年寄りの戯言を記事にしている方が問題なのだ。
現場は進化しているし、プロマネも沢山育っている。

むしろ、筆者の考える２００７年問題は、この業界の構造改革が進むかどうかだ。
各社本当の売上を計上せよ、、、これが実践されるか否かだろう。

プロセス・コンサルとコンテンツ・コンサルの違い

公開日時： 2006/12/25 11:25
著者： 草木生（そうもくしょう）

年末でもあり、某研究会の忘年会も先週あった。

その話の中で、いわゆる要求開発（≒要求分析）にはストーリー、シナリオを提供しなくてはならないかも知れないと提案した。
先週書いた、
メソドロジは、
２：６：２の内、６割の人間の底上げを可能にする
にかかるのであるが、単純にフェーズの定義・説明、そこに関わるスキル定義・説明、成果物定義・説明、では機能せず、シナリオレベルのノウハウを注意書きでも良いから提供した方が利用者の拡大、ひいてはプロジェクトの失敗が減るように思うからである。

プロセス・コンサルとコンテンツ・コンサルの違い

やはり、プロトコルとして用語の相互理解が必要だろうと思われる。
開発現場のSE、システムエンジニア諸氏には嫌われるコンサルだが、少なくとも複数種類存在していることを知ってもらいたい。

プロセス・コンサル
・開発プロセス、課題解決のプロセスを支援する
現状分析、To-Beモデルのモデリング、体制なども含めてサポートするコンサルタント であり、プロマネの基本ノウハウ＋課題アプローチ・モデリングノウハウを持つ
いわゆる、ＲＦＰ作成から基本設計、外部設計くらいを担当するが、プロマネになった 場合はカットオーバーまで責任を持つこともある

コンテンツ・コンサル
・事業部の企画であるとか、企業の基幹システムの課題などを調査・報告する
その企業の現状と競合他社状況を分析、報告を出していく
報告書としては、分厚いものであり、発注するユーザ側にも１キロ一千万円くらいの
感覚があるらしい
現状ではインターネットの発達で苦しくなっている
独自の調査報告は、インターネットで70%程度は揃えられるようになってきており、
どこに独自色を出すかが難しくなっている

日米でのコンサルティングの違い

アメリカでは、コンサルティングがかなり軽いように思われる。
そのツールにある程度精通していると、あっという間にコンサルタントである。
それを日本に持ち込んでいるのが、外資系のソフトウェアベンダであろう。
日本では、ひょっとしたら何でもできるのがコンサルタントであり、まさに超人を期待されて始まるコンサルテーションもある。

ＩＴコンサルの定義付けは、まだ一般的な理解を得ていない。
筆者は、10年程度はシステムコンサルとしてやっていたと思われるが、それにも一般的な理解はない。
瑣末な職種なので、一般的な理解を今後も得ることは無いだろう。

ＩＴ業界の人材レベルは低い？

公開日時： 2006/12/21 20:13
著者： 草木生（そうもくしょう）

コンサルタントを始めたときに師匠に言われたのは、この業界のレベルの低下である。
８０年代初めまではオール４くらいの人材が入ってきたが、そこから後はせいぜいオール３くらいの人材だと言われたのである。
８０年代も半ばになると、この業界に入るのは親が止めていたくらいだから、頷けるものがある。
その頃と今の状況は似ている。
３Ｋ職場である。
相変わらずの徹夜で仕事をやっつけている。

就職氷河期といわれた頃、９０年代半ば以降はそれなりに優秀な人が入ってきたと思うが、最近の売り手市場ではまた見向きもされない業界となるかも知れない。
それに、人口の半分は女性だと思うがこの業界にはほとんどいない。

また、色々な大企業のシステム再構築にも携わってきたが、そこのシステム部門の人にも言われた事がある。
「この会社に入りたくて入ったが、システム部門には来たくなかった」である。

筆者が延々とメソドロジの話をするのは、頭が悪ければリファレンスモデルをもっと有効に使えということだ。
それにしてもこの業界には、頭が悪いという自覚が足りない。
自覚していれば、それなりに勉強もするだろうが、それすらしていない。
幸い？筆者は師匠から頭が悪いと言われたおかげで、ずっと学習中である。
５分間考えて分からなければ、分かっている人に聞くことができる。
理解するために本を選び、読むことをしている。

少し話は変わるが、パレートの法則というのがある。
「２割の人材が残り８割の人材を食わせている」という経験則である。
すなわち、利益の８割は２割の社員からもたらされるという。残りの社員のうち、６割は自分の給与分を稼ぐのが精一杯。最後の２割は自分の給料を稼ぐどころか利益の足をひっぱっているという。

メソドロジは、２：６：２の内、６割の人間の底上げを可能にする。
トップの２割にはそれほど必要ではないのだ。