Quantcast
Channel: IT勉強宴会blog
Viewing all 87 articles
Browse latest View live

スケジューリング学会 合同シンポジュウム

$
0
0

初めて静岡県の浜松で開催しました。最初わざわざ静岡まで来て下さる方がどれだけいらっしゃるか心配だったのですが40名ほどの方にお越しいただきました。場所の設定や配布物など静岡大学の八巻先生には大変お世話になりました。この場をお借りしてお礼申し上げます。

会場費用はスケジューリング学会プロジェクト&プログラム・アナリシス研究部会から出して頂きました。ありがとうございました。

2次会は19名3次会は9名4次会・5次会は5名で3時ごろまで飲んでました(笑) 浜松は夜中でも多くの若者がいて大変活気があります。しかも女性2~3人のグループを多く見ました。街としてほどよい大きさなのでしょう。街全体が安全で活気があります。
最後は「ジョセフィーヌ」というワインバー(?)で「醍醐のしずく」という珍しい生酒を飲ませてもらいました。あまりに美味しいので一本追加。その時だされたチーズも半端なく美味しかった!ママさんの話も面白くて、浜松の奥深さを垣間見ました。
ジョセフィーヌに行くためにもう一度浜松で開催してもいいかも(笑)

 <今回の勉強会資料>
    ※もしうまく開かない場合は次の場所から探して下さい:http://www.onas.asia/home/benkyoenkai/doc
求む!上流工程技術者(佐野)
3D-CADデータの一気通貫とIT活用でものづくり力向上を!(関さん)
製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~(佐藤さん)

<動画>

求む!上流工程技術者(佐野)
3D-CADデータの一気通貫とIT活用でものづくり力向上を!(関さん)
製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~(佐藤さん)

<求む!上流工程技術者>

セールスフォース・ドットコム 佐野初夫

2008年にiPhoneを使いだしてから社内の情報が社内より早く伝わる事に驚きました。今まで情報格差が商売のネタだったのすがこれからはそういう商売は出来ない。下流の実装技術は英語が堪能なインドや中国の技術者には勝てません。若い技術者は下流の実装技術よりも上流工程の技術を勉強して欲しいと考えて関西IT勉強宴会を始めました。

過去21回の全タイトルです。それぞれ全部資料がダウンロード出来ますし、私の詳細なブログで内容が読めます。興味のあるタイトルがあればアクセスしてみて下さい。
http://www.onas.asia/home/benkyoenkai/doc

エンタープライズ向けのノンプログラミングツールを一覧しました。これだけあると壮観です。どのツールも実績があって発表されていますから優劣はありません。御自分に向いたツールを極めるのが良いと思います。ただ、それぞれのツールに向いた設計が必要です。それを勉強するためには、実用で使えるようなサンプルを見る事が近道です。

実用に耐えるサンプルが公開されているかどうかを一覧にしてみました。GeneXusのマーケットプレイスは粒度の小さなツールだけです。業務パッケージはそれぞれのSI会社が自ら販売されているようです。セールスフォースAppExchangeというマーケットプレイスで大小様々なパッケージがあります。富士通さんのERPパッケージであるグロービアもセールスフォースの基盤の上で動いています。Wagbyはサンプルとして複数業務が公開されています。XEAD Driverは生産管理をこれから発表して頂きますが、すでに販売管理を無料で公開されています。

<『仕様書で動く生産管理システム』の開発事例報告>

ディービーコンセプト 渡辺幸三さん

基幹システムを手に入れる方法は、家を買う時と同じく3つの方法があります。まず1つは業者に全部を委託して作ってもらう方法です。2つ目は建売り住宅を買う、3つ目はモデルハウスで検討する方法です。それぞれメリットデメリットがあります。

一般的なデザインだが必要に応じて改修したい時には、モデルを使いましょうこのXEAD Driverは実用になるモデルがあり、それを簡単に改修することが出来ます。

モデルシステムというためには、3つの条件があると考えます。
 ・基本設計書(ER図・業務フロー・業務マニュアル)が公開されていること
 ・仕様書が公開されていること
 ・カスタマイズが容易であること

今日は、次の3つについてモデルを見ながら解説します。フィーチャー・オプション(FO)、BOM、MRP&在庫推移監視方式の3つです。
一般公開は夏ごろの予定ですが、世界初の「仕様書がそのまま動く生産管理システム」をみてもらいながら説明します。

1.フィーチャー・オプション

 フューチャー・オプションではありません。フィーチャーです。フィーチャー:featureとは、顔の造作(目・鼻・口・耳・額・あごなどの一つ)の事です。モンタージュを想像して欲しいのですが、目や鼻などのフィーチャーを入れ替えることで様々な顔を作りだします。フィーチャー・オプションは、ある品目がどういうサイズや色を取りうるかを定義するものです。

 これは自動車業界で使われだしたと言われています。品番の爆発を防ぎます。これがないと部品表がとんでもない数になります。実際に見てみましょう。

品目マスタ  内部品目No     {品目コード}
       00001 ・・・ A12345P

 品目の一次識別である「内部品目No」はユーザの目に触れない不変の項目です。品目コードなどのナチュラルキーをテーブルの一次識別にしない方が良いのでこうする事が多いです。ナチュラルキーはめったにないでしょうが、変更される可能性があるからです。そのため一意制約をつけた属性項目としています。



 色やサイズなど色々あるオプションをフィーチャーとして登録すると、ようやくフィーチャーマスクを使えます。

FOマスク   ID             マスタ区分は、選択かオミットか
       A12345P-SSRED
       A12345P-*****

 *はワイルドカードとして使います。ある部品がサイズもカラーも関係なく使われるものなら、FOマスクは「A12345P-*****」になります。サイズSSでカラーがREDでだけ使われる時は「A12345P-SSRED」です。

2.BOM

 ある製品を作る時にどういう部品を使用するかが部品表、BOMです。作りたい製品数量を入れると、どの工程でどれだけの材料が必要かを出力します。その展開はBOMプロセッサと呼んでいます。それも仕様書だけで書けます。




3.在庫推移監視方式

 品目と倉庫を指定されると、在庫がわかります。その在庫がどの取引から増減したかを受け払いとして日付別に入っています。



 これは将来の日別の在庫数をリアルタイムに計算出来る方式です。MRPというのは、在庫推移をオンデマンドで指定された時に計算します。またMRPは在庫が足らない時に勧告オーダーを出してくれますが、出来るわけがないような勧告をだすので使い物にならない事が多いです。MRPに絶望して、在庫推移監視方式に辿り着きました。コンピュータがやる分野と人間がやる分野の分業です。

 MRPはなかなかうまく運用出来ないそうです。欠品はなくなるのですが、余剰在庫が減らないそうです。在庫推移監視方式は余剰も監視する事が出来ます。


<3D-CADデータの一気通貫とIT活用でものづくり力向上を!>

関ものづくり研究所 関伸一さん

一人完結型の生産方式をリーダーとして創りました。車が趣味で昨日独車のクリーンディーゼルが納車されました。品質は素晴らしいです。バイクは昨年買ったのが78台目でした。モットーは、「明るく楽しい職場からしか良い物は生まれない」この言葉だけはゆずれません。

1.ものづくりりの要素と資格

絶対的に最優先なのは「S:安全」、次に「E:環境」に配慮して初めて物を作る資格があります。次に「Q:品質」が売る資格です。一万個に一個の不良品でもそれを買った人には100%の不良率です。本田宋一郎氏は120%の品質と言ってます。

その後に「C:価格」や「D:納期」があります。これが競争する資格です。でも、安ければ良いという事ではありません。最近の日本の製造業の品質は少し心配になります。

2.日本のものづくり

腕時計の台数で、95%が日本製です。素晴らしい。でも・・金額ベースでは85%はスイスの機械式時計なのです。それだけ安い日本製の腕時計が1日に5秒狂ったら怒られます。高いスイス製の時計は1日に30秒狂っても何も言われない。

「お客様の立場に立ったQCD」をもう一度考えて欲しい。ここ15年で日本の自動車の品質は完全にヨーロッパに置いて行かれた。高い?フォルクスワーゲンは145万円です。軽自動車程度の値段で圧倒的な品質です。

さて、日本のものづくりはどうするのでしょう?

日本の現場で日本の雇用を守りながら、「高くてもいい、お願いだから売ってくれ」と世界に言わせる製品開発を考えて欲しい。
TPD:Total Product Development(全社的製品開発)」が重要だと考えています。設計開発部門はクリエイティビティに特化した作業だけをさせる。製造部門や購買部門など全部門で製品を作り出すという取り組みが大切です。緩衝材は今や落下衝撃シュミレータがあるのだから耐Gだけ設計に聞けば物流で決めればよい。

3.ライン生産から一人完結セル生産への変革

 ベルトコンベアの流れ作業は非人間的な作業です。基本的に「遅れ」しか伝播しない。作業が早い人がいても、一番遅い人に律速される。残業は半強制。トイレも行きにくい。

一人完結セル生産に変革させた。問題点は3つあり、それをデジタルで解決した。
問題1:熟練工の養成が難しい
 暇な時に練習を兼ねて初めての製品の製造に回す
問題2:品質のばらつきは許されない  =>フロントローディング
 作業マニュアルを徹底的にわかりやすく(3D-CAD)
 ポカヨケで、不良品を作れなくする。最終検査をなくし単一工程で品質を保証する。
 例:ネジを自動的にトレイに出し、ネジの数をドライバーでカウント
問題3:高価な検査機械を人数分用意するの?
 30人に1台、スペシャルショップ(SP)に置いた。画面が「SPに行ってね」と言う

4.デジタルセル生産による変化

 作業者に時間的ノルマはない → やる気に依存 → 継続的改善
 ※明るく楽しい職場であれば実力をフルに発揮してくれる =>ES向上

 何分で終わったかを出して欲しいと80%に言われた。
  →終了後3秒だけ表示した → 自分の記録を自宅のエクセルにいれて管理

<製造業のプロジェクトにおけるボトルネック ~BOM/部品表の問題~>

日揮(株) 佐藤知一さん

1.日本の製造業の位置づけ

 BOM部品表入門を8年前に書いた。当初はERPの技術者のために部品表の設定を教える本にするつもりでした。書き進めるうちに180度変わって、BOMのデータを外部コード体系や外部パッケージに依存すべきでないという本になった。広い意味でのBOMは、日本の製造業の「すりあわせ的統合のかなめ」になるものだから。

 GDPに占める製造業の割合は、20%を切っている
 製造業で働く就業者数=1030万人(全就業者数は6230万人)
 製造業の従業員あたりIT費用は43.9万円(全産業平均は58万円)
  →製造業は流通よりも業種が多いのにIT費用が75%なのはおかしい
  →きっと、やりたい人、出来る人がいないからではないか

 製造業とITとか握手するかなめが部品表だと考えています

2.製造業の簡単な説明

 (業務の)三層モデル
   全社レベル   :生産・販売・在庫管理  製品単位、月週単位
   工場管理者レベル:生産スケジューリング、進捗、部品単位、週日単位
   製造現場レベル :製造オーダ、購買オーダ 部品/ロット、日時分単位
 これらを伝票で回すが、管理の仕組みが追い付いていない。

 共通するボトルネック = BOM/部品表

3.部品表の問題

 設計部品表(E-BOM)と製造部品表(M-BOM)がかい離している。ひとつの会社でBOMが40もあったところがあり、それを統一するためにすごいお金をかけた。

 BOMの表現形式には4種類ある。
 サマリー型/ストラクチャー型/シングルレベル/マトリクス型
 MRPはストラクチャー型BOMを90度傾けたもの。一番右の製品が何月何日に欲しいと言えば、どの部品が何日に必要かを計算する。IBMが60年代終わりごろに思いついた

 ただし、BOMの設定は難しくて予定通りいかない
(1)設計変更でBOMが変わる時どうするの?
(2)サプライヤーの供給部品の仕様が変わる時の対応は?
(3)材料ン公購買単位がKGで消費単位が個数の時は?
(4)中間部品(中間製品)はどこまで登録するべき?
(5)返品や、製造現場の使用残はどう扱う?
(6)試作品のBOMは登録すべきか?
(7)製品にオプションやバリエーションが多数ある時、その数だけBOMを作る?
(8)法押す材料や副資材も登録するのか?
(9)リードタイムの設定は?安全在庫の設定は??

 これらを解決するためにいくつかのノウハウがある(本参照)

4.EーBOMとM-BOMの乖離

 設計部品表を製造部品表に毎回コピーしている会社もある。ITで統一出来るという人もいる。どれも正しいとは思うがそうできない企業もあると思う。

 私の主張は、
マテリアルマスタは統一すべきだが、BOMは何個あっても構わない
広い意味でのBOMは全部門と関係がある情報のハブになっていると考えています。

 企業の全体図を俯瞰すると、どこにどういうBOMがあるかがわかるはず。その全体像から考えないとわからないはず。

5.マテリアルの統一

 物を売ったり買ったりできるものは3種類
 ・マテリアル  在庫できる  所有権の移転
 ・サービス   在庫出来ない 利用権の許諾
 ・情報   在庫出来る/出来ない 利用権の許諾

 同じものか違うものか?
  (岩手山の牛乳と十勝産の牛乳は同じ物?違う物?)
  ※物自体の属性では決まらない。キーとなる属性が同じかどうか
  ※つまり、主人公はマテリアルではなく使用目的である

 意味なしコードのすすめ
  アリストテレス的「実在論」から、ソシュール的な「唯名論」への転換
 BOMの「責任部署」を決める
  クロスファンクショナルなプロジェクトチーム体制がお薦め

6.某巨大工場プラントの例

 一番大変な配管は4000種類、数十万点が必要。設計が終わってから発注すると間に合わない。そのため、設計前に発注します。次の表が徐々に右下に行くのを見ていると、どこでネックになっているかがわかります。

             モデル入力  ISO図発行  Spool図発行
  REQ発行(引合)   xx%              xx%          xx%
  PO発行(発注)     xx%              xx%          xx%
  IA発行(製造)      xx%              xx%          xx%
  現場到着             xx%              xx%          xx%←溶接済み

 この配管コードを統一するのに11年かかりました。マテリアルマスタの統一は言うほど簡単ではありません。

<所感>


渡辺さんが佐藤さんと飲まれる時に誘ってもらったのが今回開催のきっかけです。新大阪の定番たけうまでした。佐藤さんが横浜ですので「大阪と横浜の間をとって静岡」といわれ即答でOKしました。メンバが来て頂けるか直前まで心配でしたが、関西IT勉強宴会から20名以上、スケジューリング学会から20名弱と、過去22回で最高の人数でした。

まず佐野は実装技術より上流工程を大切にしようという話。渡辺さんは生産管理の設計に必須の概念を説明しながらも上流工程について語って下さいました。
関さんは初めてお会いしたのですが、偶然なのかどうなのか上流工程というキーワードでそろいました。ただ関さんは製造現場の改善に取り組まれているだけあってリアリティがありました。そして最後の佐藤さんは、「製造業とITとが握手するかなめが部品表」というキーワードで、我々ITと製造現場のベクトルをひとつにして良い情報システムをつくりましょうというエールを送って下さいました。

途中で佐藤さんもおっしゃっていましたが、製造業のシステムは100社あれば100社違います。それを苦労してSAPなどで統一する企業が多いのですが、それが日本の製造業を弱くしている根本原因ではないかと考えています。情報システムは企業自身の神経細胞だという認識をもって、人任せにせず自ら作り上げるべきです。私が入社したころのメーカーさんは、ソフト会社を上手く使いながら自らの業務を構築されていました。

コンピュータ技術者の人数比について、最近よく言われます。米国はユーザ企業に70%の技術者が居て、ITベンダーに30%。日本はITベンダーに70%が居るという話です。色々な経緯があると思います。「コアコンピタンスでない分野は外出しする」とか「アウトソーシング」「戦略的互恵関係」とか。良く考えると米国企業が持ちこんだ概念を日経コンピュータが増幅させて、それに踊らされた企業も多いでしょう。

こういう、現場とITの出会いの場をこれからも作っていきたいと感じました。これからも応援よろしくお願いします。

以上


知的書評合戦ビブリオバトル!

$
0
0
偶然、「ビブリオバトル」(文芸新書)を読んで面白そうでしたので、やってみました。すごく面白かったです。「人を通して本を知る、本を通して人を知る」というのはこういう事かと実感出来ました。

ところが、課題もありました。次回やる事があればこれらを改善した形で行いたいと思います。
・そもそもこの内容では初めての人が来にくい
 →今回1人だけ来てくれましたが、他は常連ばかりでした。
・質問タイムはその気になれば何時間でも出来る
 →そもそも技術が好きな人の集まりでしたので語る語る・・(笑)
・同票になった時のルールがない
 →今回2冊が同票になり、決選投票でも同票になりました
・違うジャンルの本を較べられない
 →今回、技術書とマネージメントの2種類が出ました
・電子書籍で読んだ人が紹介しにくい
 →一人はわざわざ買って持ってきてくれました

 事前に申告して下さった方は5名だったのですが、急に阪井さんと小川さんが発表して下さる事になり、7冊になりました。フラッシュの電子あみだくじ(笑)で順番を決めました。
http://mwsoft.jp/programming/webtools/random_chooser_amida.html

 急にお願いしたお二人はみごとに最後にまわりました。電子あみだくじやるな~。

5分を計測するタイマーもフラッシュの物にしました。
http://scienthrough.qee.jp/biblio/bibliotimer.html

 両ソフトの作者のかた、ありがとうございました。それでは始まりはじまり

<山本さん>

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?
ITプロジェクトは失敗し、納期が遅れるのが当然というイメージがあります。この本はプロジェクトが遅れないための簡単で画期的な方法を提示しています。それに登場人物数名の問題意識、課題がストリー形式で説明され解決されるので面白いです。
 あるタスクが90%の確率で終わるのが外部スケジュールで、50%の確率が内部スケジュールです。その差がバッファになりスケジュールの最後に置きます。
これを読むたびにクリティカルチェイン・プロジェクトマネージメント手法の創造に立ちあう事が出来ます。

<久保さん>

ジェネレーティブ・プログラミング

電子BOOKで読んだのですが、今回紙の本を買いました。通勤で読むにはがっつりしています。設計作業と実装作業を結びつける方法が書かれたものです。
プログラムの自動生成には限界があります。この本では、仕様(設計情報)を記述することで生成的(ジェネレーティブ)にコードを作り出そうという理論と実践が記述されています。渡辺さんのXEAD DRIVERはまさしくこれだと思います。
ITの歴史に必ず残る本です。



<野村さん>

テクノロジストの条件
ドラッガー本です。プロフェッショナルの条件が爆発的に売れた中で発売された4冊目。あまり注目されませんでした。資本主義が「ブルジョアジーと労働者の対立」という視点から、社会主義が出てきましたが、産業革命で圧倒的に生産性が高まり社会主義の必要性がなくなりました。この本は、Management of Technology(MOT)という視点でテクノロジー(技術)が文明に果たしてきた役割が歴史的に書かれています。



<杉本さん>

奇跡の経営

皆さん管理される事は好きですか?これはブラジルで大成功した経営者の驚くべき経営手法を説明したものです。まず、コントロールはいらない。コントロールするという事は人を信用しないという事だからです。それに方針や戦略もいらない。大人だからみんな、自分がやる事わかっているよねという事です。さぼる人が出てきてもいい。クビにすると他の人が疑心暗鬼になるからです。
ある意味アジャイルの組織論とも通じる方法論だと思います。



<佐野>

MBAアカウンティング

システム設計には会計の知識が必要だと今までも言ってました。簿記の試験は何の役にも立ちません。経営的な視点がないからです。この本は貸借対照表や損益計算書を経営的な視点で学ぶ事が出来る本です。今まで改定3版まで出ていてすべて持っています。それは法律が変わっても専門書を読む時間がないためこの本をベースに勉強しているためです。最新の3版では2006年の会社法改正や内部統制が追記されています。
これを読むと、経営者と会話する知識を得る事が出来ます。




<阪井さん>

アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント

Aster、昔のJUDEというツールを作る会社の平鍋さんと、スクラムを作った野中先生の対談集です。帯に「日本生まれ米国育ちのスクラム」と書いてありますが、それが嘘である事が本に書かれています。野中先生は、トヨタ方式を拡張した生産の手法について実績値を入れた論文を書いていました。サザーランドがアジャイルをすすめていてうまくいかず、野中先生の論文をみつけて進めた方法論なのです。
そういう歴史的な事が詳しく書かれた本です。




<小川さん>

反復型ソフトウェア開発

マイクロソフトの技術者が書かれた本です。開発プロセスを支援するツールについて具体的に書かれています。ソース管理(SCM)、ビルド管理(CI)、障害管理(BTS)という三種の神器について詳しく説明されています。例えば、複数のソースをマージするとサブバージョンでトラブルことが良くありますが、実はマージにはいくつかの種類があり、どれをどういう時に使うかが良く理解出来ます。
実践でやっていた事を体系的に整理させてくれた本です。






------------------------------------
 さて、皆さんはどの本が「一番読んでみたい」と思われましたか?ここで1人1票の投票をしたのですが、すぐには決まらないということで5分間休憩しました。

推薦図書のタイトルを良く見ると、技術書と経営書にまっぷたつに分かれています。その分野の違う本をどちらが選ぶのは難しいという声が多くあがりました。「それぞれの中なら選べるけど」という声でした。そういえば、このビブリオバトルが生まれたのは京大の研究室でどの本で研究するのが良いかを決めるのに持ち合ったことだと本に書いてありました。この勉強宴会はまだ方向性が決まっているので良いのですが、ノンジャンルのビブリオバトルは面白くないと感じました。次回やるとしても来年ですが、次はもう少し範囲を絞ってやりたいと思います。

 また、最後の反復型ソフトウェア開発という言葉について少し議論がありました。オープンソースやパッケージの開発のように、ずっと開発が続くソフトウェアについてのツールの話なら理解しやすいと思います。ところが業務向けのソフトウェアも実はこまめにバージョンアップを繰り返し「変化をみこす」必要があるのです。プロジェクトの定義が「目標と期限がある業務」であれば、ソフトウェア開発はプロジェクトではないのかも知れないという発言までありました。

 今回発表していただいた本は、どれも1冊あたり2時間・3時間語っても時間が足りないほど面白く示唆に富み勉強になるものばかりです。特に読んだ事のある人は「質問」と手を挙げながら質問でなく自分なりの書評を述べ出すという面白さ。
 1冊10分発表20分質疑くらいで、事前にちゃんとプレゼン資料を作って本のエッセンスを説明し議論するという方式でもこの勉強宴会なら充分に成り立つと思いました。

さて、投票です、タカタカタカタカタカ・・・・
------------------------------------
 投票になりました。一冊ずつ手を挙げてもらうと、次の2タイトルが同点になりました。
・ テクノロジストの条件
・ MBAアカウンティング
ビブリオバトルの公式ルールでも同点の時にどうするかのルールがありません。しかたないのでこの2つに絞って決選投票したところ・・・・またしても同点(笑)
この2つを2013年度関西IT宴会 チャンプ本と決めました。

参加して頂いたみなさま、ありがとうございました

ITエンジニアのゼロから始める英語勉強法

$
0
0
ITエンジニアのゼロから始める英語勉強法」の著者が大阪に来られると連絡がありましたので、急遽開催しました。募集開始が一週間前でしたので数名しか集まらないかと心配していましたが、実際には総勢で17名も集まってもらえました。牛尾さんをはじめ集まっていただいた方には感謝しています。ありがとうございました!

参加者の大半は初めての方でした。「一度牛尾さんとお会いしたかった」とコメントをいただいた方もいらっしゃいました。さすがにアジャイル王子(笑)。ちなみに牛尾さんのあだ名がアジャイル王子だそうです。この本も本人は「アジャイル王子の華麗なる勉強法」としたかったそうですが、出版社に華麗に却下されたようです。彼とは1999年ごろに同じプロジェクトで仕事をした事がありそれ以降の知り合いです。そういえば、私が今勤めている会社が誕生した頃だとしみじみ・・・ NECの中でも相当尖がっている感じでした(笑)

2次会は珍しく5名と少人数でしたので、とっておきのお店に案内しました。分厚いタンステーキだとか岩牡蠣、雲丹の箱盛りだとかおなかいっぱい食べて4000円ALL。素晴らしいコスパでした。そして3次会は3名で2:00ごろまで。月曜から何をしてるんだか。サラリーマンとは思えませんね。会社には内緒だよ(笑)

<今回の勉強会資料>
外部サーバに置かれています
http://www.slideshare.net/TsuyoshiUshio/it-23717991

<動画>90分あります。70分くらいからの実地の発音練習は是非見てください。
http://youtu.be/F5d6GXoX0tA

<ITエンジニアの ゼロから始める英語勉強法(ペラペラ実践編)>
匠Business Place、シンプルアーキテクト 牛尾 剛さん

1.この本を書いたわけ

メソッドが大好きな人間です。ひょうんな事から8ヶ月間で米国で開かれるAgile2011のワークショップの講師をすることになり必死で英語を勉強しました。そこで感じたのは本になるくらいですからどれも素晴らしい学習法ですが、その「前提条件」を伝えてくれていないということ。基本的に小さなころから英語が好きな方が書かれていますから、学生留学の経験があったり、外大だとか膨大な学習時間をかけても苦にならないかたが書いています。私は英語もしゃべれず、語彙もほとんどない状態でしたからそういう学習法は役に立ちませんでした。

そこで、「英語を身につける力を身につける」という事を目的に本を書きました。英語を勉強する目的もゴールも現状もバラバラです。ある人にとって有用な勉強法もある人には向かないということが多くあります。しかもGOALは変化します。MOVING TARGETに追従出来るような勉強法が必要です。

最悪なのはいきなり英会話スクールに行くことです。英会話学校は素晴らしいのですがそこに行く前に素振りだとか筋トレが必要なのです。

2.Baby Learning

様々な勉強法を調べた結果、「いけてる」勉強法はほぼこれだとわかりました。赤ちゃんが言葉を習得するとおりの方法です。それはたった3つのことをしているだけです。
(1)英語脳を作る
英語で考えて、英語で反応出来る反射神経を鍛えることです。筋トレです。
(2)レスポンシブルボキャブラリ
死んだ語彙をいくら覚えても無駄。頭で考えず反応出来る語彙を増やします。
(3)戦略変更とフィードバック
飽きたり、苦痛になったり、効果が弱くなったと感じたら勉強法を変えます

今回はペラペラになる方法を中心に説明します。それは実は簡単です。「レベル別大量インプット」すればすぐになれます。インターネットや書籍や、音声CDなどを1日1~2時間はインプットし続けます。そうすることでまず聞き取りが出来るようになります。英語脳がない状態で英会話学校に行っても得られるものは限られるでしょう。

(1)サウンドファーストの原則
(2)ダイレクト理解の原則
(3)スピーキング中心原則
この中で、ペラペラには(3)スピーキング中心原則が最重要です。というのは6歳ごろまでに言語環境に応じて音声帯域が固定化されてしまうからです。英語は日本語よりも音声帯域が広いために、日本人は耳は聞いているのに脳が拒否するという状態がおこります。それを解消するためにまずはレベルに応じた英語CDを大量に聞き、聞き取れるようになってから同じ音を発音してみます。それを録音すればずれていることがわかるはずです。意味はわからなくて良いので、耳から入った音をそのまま発音出来ることが重要です。

(4)コンテキスト理解の原則
(5)選択と集中の原則
次は多読です。英語の絵本をレベル分けしてくれているページがあります。
http://mums-english.com/
レベル1は1ページに単語1つとか1文とかです。出来る限り日本語で考えずにコンテキスト(状況)から単語を覚えることが重要です。

3.実践練習

この学習法で学んでいるグループが東京にありそこで教えていると1つ苦しんでいるポイントがわかりました。それは録音が恥ずかしいことです。私はロックのボーカリストですので録音は慣れていますが、確かに最初自分の声を聞くのが恥ずかしかったり嫌だったりしたことを思い出しました。

そういう人でも、少しほめると「なんだこれで良いのか」という気持ちが楽になるとわかりました。そこで今日も少しの時間ですが実際に練習したいと思います。

SPACE は「ス」・「プ」・「エイ」・「ス」 と基本の発音が詰まっています。日本語は母音を大きく発音しますが、子音と母音をほぼ同じ大きさで発音することがコツです。発音をiPhoneで録音して聞いてみてください。

なお最後に、「英語がペラペラになる」ことと「英語力」との間には何の関係もありません。そのことは注意してください(爆笑)

<所感>
ITではありませんでしたが、大変面白かったです。このメソッドの入り口まで経験できるセミナーなら有料でも受けたいと思う人は多いように思いました。




クラウドビジネスの実態とエコシステムとしてのセールスフォース概要

$
0
0
<クラウドビジネスの実態とエコシステムとしてのセールスフォース概要>

 この勉強会は、ほぼ毎月やっていますが前回は7/1でしたから実質ほぼ2カ月ぶりの開催でした。ほぼ常連さんばかり。初めての方は2名だけでした。

 珍しい事に、3時の最終までお付き合い頂いた方が5名でした。2次会は13名でした。
なお諸般の事情により今回の資料は公開しませんのでご了承ください。

<エコシステムとしてのセールスフォース概要>

セールスフォース・ドットコム 佐野 初夫

1.SaaSとしてのセールスフォース

 昨年はプラットフォーム(PaaS)としてのセールスフォースを説明しました。データモデリングさえ出来ていればクリックだけで簡単にテーブルや画面、レポートを作成出来る事をデモを交えて見て頂きました。

 今回はパッケージというかソフトウェア(SaaS)としての機能を見てもらいます。セールスフォースのライセンスには営業支援機能で利用される「Sales Cloud」とコールセンター業務の「Service Cloud」があります。

 営業支援に関してはYouTubeで動画もありますのでご興味があればそれをご覧ください。
http://www.youtube.com/watch?v=5rnFzMDtMUc
ここではコールセンター(インバウンド)について説明します。セールスフォースの中で問合せを管理する業務を「ケース」と呼びます。

(1)問合せの受け付け
 多岐にわたる接触ポイント(コンタクトポイント)から問い合わせを受け付けます。
 ・電話(CTI連携機能-着信電話番号から情報を自動表示)
 ・WEB(Web To ケース機能)
 ・メール(Mail To ケース機能)
 ・Facebook/Twitter(Salesforce for Twitter)
Facebookからの問い合わせ対応機能は数年前までありませんでしたが、バージョンアップなどで追加された機能です。このように、SaaSとしてのSalesforceを使用する大きなメリットのひとつが無償で機能アップするという事です。

(2)問合せ解決プロセス
 ・問い合わせ内容によって自動で担当を割り当てます。
  →例えば国や地域、それに製品別など条件を指定し対応するキューに割当てます。
   キューには複数の担当が登録されていて、最初に引き受けた方が担当します
 ・お客様との契約条件に従ってサポートレベル(SLA)を確認します
 ・過去のソリューションで近いものがないか検索します。自動検索も出来ます。
 ・ケース画面の中から電話をかけたりメールを出したり出来ます
 ・対応が難しい時は上位部署にエスカレーションします
  →上位部署は担当が自動割り当てされてこのプロセスを繰り返します

(3)セルフサービス
 過去に同じような問い合わせが合った時、ナレッジとして公開する機能があります。
 ・ポータル機能(お客様がログインして情報を見る)
 ・一般公開(お客様はログインせず検索する事が出来ます)

2.エコ体系としてのセールスフォース

 セールスフォースの基盤の周りには多くのビジネスがあります。そのひとつがアップエクスチェンジというアプリケーションのマーケットです。アップルストアのセールスフォース版だと思って下さい。
https://appexchangejp.salesforce.com/

 有償無償の様々なアプリケーションが登録されています。ここではその一つとして、地図連携「Orkney GeoGraph」をお見せします。セールスフォースの中にある住所を独自のデータベースから緯度経度に変換し(ジオコーディング)、GoogleMap上に表示します。
https://appexchangejp.salesforce.com/listingDetail?listingId=a0N30000009wvDNEAY
中身を見てみたい方は、このURLから「デモを見る」で動画再生、「テストドライブを利用」で実際の画面を触る事が出来ます。

<マーケティングのためのセールスフォース>

株式会社フィナンシャル・インスティチュート  山本 愛緒さん

1.セールスフォースの利用
 9年前に大阪駅前第一ビルの1.5坪の事務所で始めたコンサル会社です。社長の意向で数多くの新しいツールを使ってお客様にアプローチしています。「銀行との付き合い方」というメールマガジンは大変多くの読者がおられます。

 メルマガや講演会などをセールスフォースのキャンペーンとして登録し、そこに申し込んで下さった方をリード(見込み客)に登録します。そのキャンペーンから例えばコンサルタント契約などにどれだけつなげる事が出来たか(ROI)を一気通貫で見えるのはセールスフォースくらいだと思います。

2.シナジーリード
 メールマガジンとして他社のツールも使っていたのですが、何故かスパムにはいっていたりしてその対応だけでバタバタしていました。そこでシナジーリードを使いだしました。
https://appexchangejp.salesforce.com/listingDetail?listingId=a0N30000003JJEREA4
 ※このURLから動画再生およびテストドライブ利用が可能です

 このツールを使うと、簡単な操作でメルマガを配信出来ます。そこのURLをどなたがクリックされたかがわかり、セールスフォースの中に情報が取り込まれます。WEBサイトに特定の文字を書いておくと、どなたがどの画面をご覧になったかがわかります。WEBでの広告を打った時にどの広告が一番効いているのかが一目瞭然になります。

<クラウドビジネスの実態>

サムライステム株式会社 社長 田畑 昌平さん

1.独立までの経緯

 大学を中退して数年米国に渡り、1990年にケン・システムコンサルタントに入社。堀内一先生のDOA(データモデリング)を学びました。その後2000年にマジックソフトウェアというdbMagicを作っている会社に移り、T字形ERをユダヤ人と一緒に勉強しました。
 そこで学んだのはユダヤ人は天才だという事でした。日本人とユダヤ人とのギャップを強く感じました。その後も紆余曲折あり、2010年に独立しました。

2.セールスフォースを選んだ理由
 自分はイノベータでなくアーリーアダプターだという認識の上で、既にエコポイントなどで世間の認知度が上がっていたセールスフォースを選びました。お客様を幸せにしたいという気持ちと、セールスフォースの社会貢献に感銘を受けたのがきっかけです。Power of Us活動としてNPO法人には無償でシステム設定を行うなどの活動を行っています。

 お客さまとしては、ほとんどが数十人までの規模です。システム部を持っておられないのでコンピュータ全般の相談役としても動いています。システム化が初めての会社が多いので導入セミナーとして2時間で次の事をお話します。ほとんどの会社は理解してもらえます。
 ・漏れなく、ダブリなく整理すること(MECE)
 ・重複は良くないこと(One Fact is One Place)
 ・事象は事物(資源)とその関連で成り立っている事(ER)
   →リソースとイベント
   →関係は3つに整理(主従・参照・レコードタイプ)

3.SalesCloudを中心とした導入支援業務
 提案書のひな形をもって、ユーザ視点で導入について説明します。一般的な導入支援なら、3週間で百万円未満の金額で完了します。必要に応じてサポートサービスも提案します。
 また、戦略的システムの場合は1業種1社しか受けない事も約束しています。

<所感>

今回は本当にほとんど事前準備せず開催しました。私の話は仕事でやっているプレゼンのショートバージョンです。セールスフォースは年3回のバージョンアップがあります。この10月にもまた変わりますからこのブログには変わらないと思われるところだけ載せました。

 山本さんには急にお願いしたところ快く受けて頂きました。結果的に山本さんのお話が一番リアリティがあって皆さんの役に立てたのではないかと思います。

 田畑さんがDOAをルーツに持つ方だと知らずに依頼しましたので驚きました。実際に参加者の1名とは昔会っておられたようです。世間は狭いですね。セールスフォースがDOAツールであるという確信を得ました。実際にお客様に出す提案書やら金額なども赤裸々に語って頂きました。ありがとうございました。

以上

仕様書で駆動される生産管理システムの開発事例

$
0
0
 ついにXEAD Driverで動く生産管理システムを公開されました。その記念講演でした。

 場所はいつもの通りシナジーマーケティングさんに無償で会議室をお借りしました。本当にありがたいと思っています。梅田界隈で、20名程度の会議室を貸して頂ける企業がありましたらお声をおかけ下さい。

 今回は、初めての方が4名で総勢18名でした。2次会は12名、3次会は8名で2:30ごろまで飲んでいました。こういうお題の時はずっと開発だとか設計の話が続くので良いですね。

<仕様書で駆動される生産管理システムの開発事例>
デービーコンセプト 渡辺幸三さん

1.レファレンスモデルの開発

 2003年に独立しました。前職ではDelphiでモデリングツールを作っていました。その仕様としてレファレンスモデルを公開しようと思っていました。というのは、システムを毎回一から作る事が大変設計効率が悪く嫌だったからです。図書館の建物の設計図面ならネットを探せばあるのに図書館システムの設計書はありません。こんなことをやっているとこの業界はいつまでも保育園レベルだという問題意識がありました。

 設計はその当時から「業務」「データ」「機能」をとらえて設計していました。今ではそれを三要素分析法と呼んでいます。前職で社内の標準にしたかったのですが残念ながらプロセス指向で設計する人が多くて上手く使ってもらえませんでした。

 独立したのをきっかけに、このモデリングツールをjavaで作り替えました。
XEAD Modelerです。
ここに来てくれている久保さんに手伝ってもらいオープンソースにも出来ました。ほぼ同時に、本当に業務で使える卸売業の販売管理システムの基本設計を公開しました。その後生産管理システムなど数業務公開しました。

2.レファレンスシステムの開発

 基本設計だけではそれが本当に動くかどうかの確認(フィジビリティ確認)が出来ません。それをするためには実際に動かしてみる事が早道です。実際に作ってみようとしましたが、いまさらjavaでちまちま作るのも違うと考えました。JavaFXは少し惹かれたのですがOracleに買収されてから方向性が変わってしまいあきらめました。

 そのころ偶然RhinoというJava上でJavaScriptを動かすエンジンが広がりました。それを使うことにしました。三要素分析法はデータモデルのテーブル構造の位相(トポロジー)でほぼ画面(パネル)が決まってしまうという特徴があります。それを利用して8つのタイプを定義すると仕様書がそのまま動く仕掛けを作りました。
XEAD Driverです。

稼働するための仕様を入力するためのXEAD Editorも作りました。このEditorはぱっとみるとModelerと似ていて区別出来ないかも知れません。

 XEAD Modelerは基本設計を記述するツールですから、ER図を表示させたりDFD(の最上位のコンテキストダイヤグラム)を書いたりする機能があります。Editorは詳細仕様を記述したりJavaScriptでロジックを書く機能があります。今のところこの2つを一緒にする気はありませんが、Modelerで作った基本設計をEditorにインポートする機能はあります。



3.実案件への適用

 過去の経験から最大公約数で「ありそうな」システム設計を行っても使えるかはわかりません。実案件に適用することで毎回新たな気付きがあります。今回公開した生産管理システムは、東京の案件で実際に使えるように作り替えています。仕様を公開する時には「誰向けか」「そういう会社がどれくらいあるか」を意識する事が重要だと思います。

 例えば、ロット管理が不要な生産管理システムがあるとは前職では考えたこともありませんでしたが、中小のメーカーでは手間が大きすぎるのだとわかりました。恐らく前職は生産管理が得意な会社でしたので、多少大きかったり難しかったりするシステムを主に作っていたのだと思います。
ロットのトレースが出来なければ困るだろうと思いましたが、製造実績を入れる時に材料ロットを摘要に入力したり、出荷実績でも適用に製品ロットを入力すれば紙管理で十分です。品質管理は生産管理ステムとは別の仕掛けで行うのが合理的だそうです。そのような要件が出てきても、簡単に仕様変更出来るのがXEAD Driverの大きな特徴です。

4.新しい開発ビジネスのためのリソース

 このXEAD Modeler/Editor/Driverを元々は自分が楽になるためのツールとして作りました。今はサポートを重視しています。ソフト関連の個人事業主(技術者)が自分のノウハウを公開するためにぜひ使って欲しいと思います。営業活動です。

5.レファレンスモデル概説

 生産管理システムの肝となる「フィーチャーオプション」と「BOM」「在庫推移監視方式」については3月の勉強宴会で語りました。
2013-03-30(月)第22回関西IT勉強宴会 <『仕様書で動く生産管理システム』の開発事例報告>

CONCEPTWARE/生産管理
として無償で公開していますので、実際に触ってみて下さい。ここでは、図面情報について見てもらいます。品目ごとに図面No.があります。図面も次々にバージョンが変わります。それだけでなく同じ図面から設計変更(設変)が数多く生まれます。そのコントロールにフィーチャーオプションが上手く使えました。

 実際の仕様変更のデモを行います。XEAD Modelerで品質管理という2つのテーブルを追加しました。それをEditorでインポートします。Editorを見ると2つのテーブルに何やらエラーマークが点いています。それはまだデータベースのテーブルがないというワーニングです。ボタンを押してテーブルを作るとエラーがなくなりました。

 XEAD Editorは動く時のデータベースのメタデータをチェックしてテーブルや項目の同期が合っているかのチェックを自動的に行っています。

<所感>

今回は、XEADの歴史を解説された後、生産管理システムの実装を簡単に説明されました。在庫推移監視システムだとか、フィーチャーオプションだとかという肝になる考え方は何度聞いても自分で使えるようになるまでは相当遠いものです。私自身何度も聞いていながら「マスク区分ってなんでしたっけ?」と恥ずかしい質問をしてしまいました(選択かオミットかです)。

 Modelerはそれなりに使いこなしている方は多く居るだろうと思います。私自身もER図を書くためのツールとして利用させて頂いています。でもDriverを使いこなしている人はまだまだ少数でしょう。「これさえ読めばDriverが使える」という書籍か雑誌連載かを期待しています。

XEAD初心者の会:XEAD Driverインストール

$
0
0
XEADのインストールに困っているという声を頂いて、急遽開催しました。

この勉強宴会の原点に戻ったような充実した会でした。木曜日で直前の募集で、阪急伊丹という誰にも土地勘のない場所にもかかわらず8名に集まってもらいました。久しぶりにビールで乾杯!から開始し、そして1時間ほど経過したとき、ようやく参加者全員のXEAD Driverが奇跡的にも無事動きました。

プロジェクターとwifiが使い放題のお店っていいですね~WIFIを使えないノートパソコンの方にはUSBで回すなどチームワークの勝利でした。

ここまで到達すればもうあとは飲み会に移行(笑) マスターが特別に用意してくれていた越乃寒梅「純米吟醸」を惜しげもなく飲み干し、マスターの奥様が大きなお鍋一杯作ってくださったおでんをまさかの完食(美味しかったですね!)。多分3杯くらいお代わりした人がいるはず(笑)

伊丹の地酒だとか冷酒だとか焼酎たとかノートPCを開いたままの飲み会、しかも8名ですから全員で話が出来るぎりぎりの大きさでした。最後までこの店で飲んで帰りましたから、スナックに1軒行くより安いです。こういうマニアックな勉強宴会の時にはまたお世話になろうと思いました。


<XEAD Driverのインストール>

 エルゴ 下山吉洋さん

資料はすべて、XEADのソースと同じくgithubに公開されています。
このblogで興味がある部分は、同じタイトルのPDFをダウンロードして見て下さい。

1.XEAD Driver インストール.pdf
SUNがOracleに買収されたために、javaの構成が少しわかりにくくなっています。また、Windows7になってからセキュリティの考え方が変わりました。それらのためXEAD Driverはインストールに失敗する人が続出しています。次の(1)~(4)で解決します。

(1)javaのインストール
Oracleの「Java SE Dvelopment kit 7」(JDK7)のサイトから、Windows x86をダウンロードしてインストールします。
インストールに成功すると、JavaDB(Derby)がインストール出来ています。ところが、XEADが想定しているJavaDBの場所とは違う場所にインストールされます。恐らく今なら次の場所。
「C:\Program Files\Java\jdk1.7.0_45\db」(バージョンにより_45は異なる)
後でこのパスが必要になります。

普通にgoogleで「javaダウンロード」と検索すると、
が出てきます。この中をいくら探してもJDK7は存在しません。これをインストールしてしまった方は、一度アンインストールして上記JDK7をインストールするか、追加でJavaDB(Dreby)をインストールするか決めてください。

(1)-2.JavaDB(Dervy)のインストール
JDK7をインストールした方はこの手順は不要ですので、(2)に移ってください。
ここのapachのサイトから「Latest Official Releases」をダウンロードします。
http://db.apache.org/derby/derby_downloads.html
zipを解凍して、次の場所に置けばbatをファイル修正しなくてもDriverは動きます。
「C:\Program Files\Sun\JavaDB」

(2)XEAD Driverのダウンロードとインストール

(3)XEAD DriverのStartDatabase.bat修正
「C:\Program Files\Xead\Driver\StartDatabase.bat」を開き、JavaDBのインストールパスを必要なら修正します。
rem path="C:\Program Files\Sun\JavaDB\bin";%PATH%
path="C:\Program Files\Java\jdk1.7.0_45\db\bin";%PATH%

(4)DBの開始へ権限付与★重要
スタートメニューから「XEAD Driver」→「DBの開始」を右クリックし、プロパティから「詳細設定」ボタンをクリックします。
「管理者として実行」をチェックしてOKを押します。

2.その他情報
資料の最後に参考資料として、2つのリンクがあります
「JavaDBのテーブルをPostgreSQLに移行する手順」
「XEAD Drvier の使い方(参照・親子・派生関係)」
どちらも細かくて難しいですが、一部の方には参考になると思います。


<三要素分析法とデータモデリングの入り口>

 セールスフォース・ドットコム 佐野初夫

皆さんがWIFIの準備などをしている間、15分ほどで渡辺さんの三要素分析法の立ち位置についてお話させていただきました。

1.いわゆるER図の世界的流れ
http://itref.fc2web.com/technology/entity_relationship_diagram.html
Perter Chen がER図の元祖といわれています
・記法として一番有名なのはIDEF1Xですので覚えたほうがよい
・ジェームズ・マーティンのIE記法に三要素分析法は影響を受けてます

2.日本的なDOAのモデリング手法
http://www.doaplus.com/html/doc/doa_text03_20050714.pdf
THモデル。椿・穂高というお二人が作られた手法。上記PerterChenと同じ学会で発表したので同時発生と言えます。
T字形ER手法。いまは進化してTMとなり「DOAじゃない」と宣言されてます。

この日本的なDOAの2手法と世界的標準のIDEF1Xの表記の読み替えハンドブックがあります。表記といいながらも実態分析まで踏み込んで読み替えていますので、データモデリングの良い教科書として利用することも出来ます。
http://www.doaplus.com/html/doc/bun01_20071203_Handbook.pdf

 ・三要素分析法。「データモデル」は「業務モデル」「機能モデル」と同時並行して作るものという考え方。それぞれ少しずつ修正しながら作りこんでいくためにWORDなどでバラバラに書くと関連の整合性を取るのが大変。そのために作られたのがXEAD Modelerです。

3.三要素分析法

XEAD Modeler、XEAD Driverはよくも悪くも三要素分析法で設計した結果を記述するものです。そのため実際に使うためには三要素分析法を知ったほうが使いやすいです。

・業務モデルの特徴
いわゆる業務フローの詳細版ですが、「こういう条件になるとこうしなさい」というアクションツリーという形式で整理するのが特徴です。
・機能モデルの特徴
いわゆる画面・帳票のことです。これを同時に設計するというのは奇異に思われるかも知れませんが、他の方法でも実際にはどういう読み方をするのかは意識しながら設計します。T字形ERなら「アクセスパス」と呼んでいます。「どう使われるかもわからないでデータモデルを設計することは出来ない」というのは王様は裸って叫ぶのと近いかも知れません。
・データモデル
1:Nの関係について、参照関係と親子関係を明確に分けて管理されるのは他の手法との大きな違いです。(余談ですが、セールスフォースは明確に分けています。実装を意識すると分けざるを得ないのかも知れません)

あと、渡辺さんが公開されている、実際に業務で利用可能な仕様(ConceptWare)を読むときはぜひサブシステムを意識して見て下さい。テーブルはサブシステムに属しています。XEAD Modelerでデータモデルを表示させてグレーになっているテーブルは他のサブシステムのものです。CRUDを考えるときに、他のサブシステムに属するテーブルはRは出来ますが、CUDは許していません。

たとえば、CONCEPTWARE/販売管理をModelerで開くと、在庫残高データ管理の中に、倉庫在庫テーブルを持っています。受注・出荷データ管理や、発注・入荷データ管理から倉庫在庫テーブルを更新しないのは不思議だと思いませんか?ぜひ確かめて見て下さい。
なお、このCONCEPTWARE/販売管理の一部分をTH法で描いた資料があります。私は三要素分析法の方がわかりやすいですが、TH法に慣れておられる方は参考にしてください。
http://www.doaplus.com/html/doc/bun03_20071029_TH.pdf

<所感>

あまり勉強会勉強会した回ではありませんでしたが、質問されて答えたものなどを総合して書きました。実際には佐野が先にお話したのですが、今回の開催趣旨から考えて下山さんの話を先にしました。
佐野のリンク先は「プログラマの思索」のblogを参考にさせていただきました。ありがとうございました。
http://forza.cocolog-nifty.com/blog/2011/01/post-f6b6.html



以上

ドメイン駆動設計を知ろう

$
0
0
 今回は人数が多くなりそうでしたので、いつもお借りしている会議室でなく株式会社インターネットイニシアティブさまの会議室を無料でお借りしました。対応して頂いたのは、株式会社ストラトスフィアさまでした。ソフト制御できるネットワーク機器(SDN)の会社です。ありがとうございました。

 予想通り、過去3年の最高人数でした。40名定員で40名に登録頂きました。2次会の忘年会も遅れてこられた方2名を入れて21名でした。



3次会はいきつけの北新地の会員制ラウンジに16名。女の子の居るラウンジに16名で入る客ってどうなの(笑) 先客の2名は驚いて帰られました。その後は貸し切り状態でこのありさまでした(笑)



 この勉強会をどうして知ったのか何名かに伺うと、発表者の久保さんの関係や常連者に誘われたという方が多かったです。人と人とのつながりで広がって行くのはありがたいです。是非宣伝して下さい。さて、テーマは「ドメイン駆動設計を知ろう」です。エリック・エヴァンスの著書がベースですが、開催の告知文にちょっと挑戦的に次のように書きました。
---------------------
「ドメイン」とは「アプリケーションが対象とする業務領域」の事です。業務アプリケーションを設計する時、「プレゼンテーション層」「ドメイン層」「データソース層」と分けることは普通にされると思います。その根本になるのがドメインです。この分類は渡辺幸三氏の 三要素分析法 と通じるものがあります。

 プレゼンテーション層:機能構成
 ドメイン層:     業務構成
 データソース層:   データ構成

WEBアプリケーションを作成するときの「MVC」という実装に近い分類と較べると相当本質をついているのだと思います。
---------------------

 ところが、この勉強宴会を通じて、これが誤っていることが分かりました。正しくはこういうマッピングでした。「ドメイン」の意味は「業務領域」なのに、業務でなく機能構成が正解でした。なぜそうなるかは後藤さんの発表でご理解下さい。
---------------------
 プレゼンテーション層:業務構成
 ドメイン層:     機能構成
 データソース層:   データ構成
---------------------

<今回の勉強宴会資料>

1.第1回~第27回までの勉強宴会のタイトル一覧
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2013-12-13_sano.pdf
2.ドメイン駆動設計を知ろう
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2013-12-13_kubogoto.pdf

<ドメイン駆動設計を知ろう>
インクス株式会社 代表 後藤 秀宣さん

1.ドメイン駆動設計とは

 ドメイン駆動設計は、特別な開発方法論や分析手法ではありません。皆さんが普段されている事を「ドメイン」という視点でまとめたものだと考えると理解しやすいです。ドメインとは、「知識、影響、または活動の領域」だと書いてあります。そのドメインに関する問題を解決するものがソフトウェアです。開発のすべてをカバーする概念ではなく、他の手法と相互補完しながら使う物です。



 この本は、フレームワークと語彙についてパターンによって示そうとしています。
・フレームワーク ・・・ 設計上の意思決定のためのフレームワーク
・語彙          ・・・ ドメイン設計を議論するための語彙(ユーザと開発者共通語彙)

<主要パターン>(ページは日本語版のドメイン駆動設計)
(1) 構成要素(P.61)
(2) しなやかな設計(P.247)
(3) コンテキスト(P.342)
(4) 蒸留(P.405)
(5) 大規模な構造(P.445)

 そしてそのどのパターンにも中心に「ユビキタス言語」と「モデル駆動設計」があります。つまりドメイン駆動設計の根幹はこの2つです。
ユビキタス言語  ・・・ ユーザから設計者まで共通の言葉を作りましょう
モデル駆動設計 ・・・ MDAなどで誤解があった。モデルと実装が一致するもの
 ※但し、ドメイン知識を持ったドメインエキスパートは、モデルには関わらない



 この本では、例示としてオブジェクト指向設計のパターンとして示してあります。例えばprolog言語で同様のものを作ってもドメイン駆動開発になると書いてあります。

2.モデルとは

 モデルとは、意図的に選び抜かれた知識の体系です。対象として「分析モデル」「設計モデル」「実装モデル」がありますが、それらに共通のモデルだけがモデル駆動設計の対象になります。なぜなら、「モデルと実装が一致しなければならない」という制約があるためです。

 なお、PoEAA(Patterns of Enterprise Application Architecture)の中で、マーチンファウラーもドメインモデルという言葉を使っています。ドメイン駆動設計で言うドメインモデルと較べると、狭義で限定的に使っていますので混同しないよう注意が必要です。

 モデルを構成する要素は、「データ」と「機能」です。データにはエンティティや値オブジェクト等々があり、機能にはサービスやファクトリ、リポジトリなどを持ちます。これらのモデルと実装がイコールであるという事がドメイン駆動設計の真髄です。



<議論に当っての整理>
株式会社アイテマン 代表 久保 敦啓さん

 今から議論の時間を約一時間ほど取っていますが、今の説明だけだと発散する可能性がありますので、視座を与えるために整理してきました。

 まずはドメイン特化言語(DSL)とドメイン駆動設計との関係を図示しました。DSLを使えるドメインユーザは直接DSLスクリプトを記述して解決ドメインモデルを作ってしまうのだろうと思われます。

 最後に、「ジェネレーティブプログラミング」との関係です。ドメイン工学があるドメイン領域の深い知識を元にして汎用的な実装を行います。個別の業務要求はアプリケーション工学の領域として、要求を分析して個別の実装を行います。例えば、渡辺さんのXEAD Driverを作るのがドメイン工学です。個別ユーザの要求に応じて必要な部分だけをアプリケーション工学に従ってカスタマイズするイメージです。



<Q&A その他>
1.UMLとDDDの関係は?

 UMLは汎用的に何でも出来る手法です。DDDはそれを限定的に使っています。

2.外部設計の時、お客さまと用語を合わすために用語辞書を作ることがありますが、それとユビキタス言語はどう違うのでしょう?

 業務の言葉の定義を明確にするという意味ではほぼ同じ概念だと思います。ユビキタス言語は技術側の言葉をビジネス用語にする事も含みます。

3.モデル=実装なら実装しない業務範囲はDDDの対象外でしょうか?

 必ず実装する所だけを対象にしてモデルを作り、徐々に範囲を広げる事で業務で使える大きさにまで広げるというイメージです。

<所感>

 DDDを誤解していたことが良く分かり目から鱗がたくさん落ちた勉強宴会でした。まずは実装しない範囲はモデルにしないという「制約」。業務をモデル化することなんて考えていないと言う事がある意味ショックでした。その理由がリーン開発にあるとは驚きました。

 DDDは、オブジェクト指向を前提としているのだと誤解していました。実は皆さんがわかりやすいようにオブジェクト指向で「例示」しているのですね。ドメイン駆動設計をググるとたくさん出てきますが、半分以上は「DDDはオブジェクト指向のパターンです」と書いてありますが、誤解しているのでしょうね。

 個人的には「ジェネレーティブプログラミング」との関係をもっと深掘りしたいと思いますが、参加者の興味からずれそうなので遠慮しました。機会があればジェネレーティブプログラミングもやりましょうか。

 最後に、佐野が次のように説明しました。
「会社の基幹システムを設計する時に、営業マン一人ひとりの横について営業マンの動きを設計する事なんてしません。100人いれば100人違うからです。DOAでは普通、管理レベルだけを対象として設計します。管理レベルとは報告書だとか管理レポートだとか経営視点で管理するために必要な情報です。会計や帳簿システムにつながります。」
この話は、TMの佐藤正美さんのセミナーで教わった事です。教わったというより無意識に行っていたことに言葉を与えてもらったと言う方が正確です。正確には佐藤さん自身の解説があります。
http://www.sdi-net.co.jp/blackbook-05.htm

 これはポパー哲学の第3世界を「モデル」と考えたという話ですが、そこまでいくと私にはついて行けません。興味がある方はぜひ佐藤さんのセミナーを受講して直接薫陶を受けて下さい。2014年1月後半に東京で安い2日間コースが予定されています。大阪でもたまにされます。
http://www.sdi-net.co.jp/seminar-modeling.htm

------------------
参加者のblog(私が気付いた分だけです)
【ソフトウェアさかば】
ドメイン駆動設計と業務分析の違い - 第28回 関西IT勉強宴会 -
【プログラマの思索】
ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想

以上

ジェネレーティブ・プログラミングの世界

$
0
0
2014-02-15(土)第29回IT勉強宴会in名古屋 ジェネレーティブ・プログラミングの世界

 約三年間、ほぼ毎回エルゴの下山さんが名古屋から通ってくださるので一度名古屋でやりたいと思っていました。約2年前の第15回DAMA日本支部について語ってくださった松本さんのFacebookつながりで名古屋経済大学の中西先生を知り、無料で場所をお借りできるということで今回の開催になりました。スタッフの皆様、本当にお世話になりました。

 また、ついでなので勉強会の名称から「関西」をはずしました。ということで無料でプロジェクター完備の会議室をお借り出来るなら、どこでもお伺いしますのでお声をおかけください。

 テーマは「ジェネレーティブ・プログラミングの世界」です。案内に書いた通り同名の本が出ていますが、分厚くて内容も難しいので読み切った人もそう多いとは思えません。またこの本は一つのドメインに限定してプログラミングパターンに紙面の大半を使っていますが、そういう枝葉末節でなく本筋のDSLだとかフィーチャーモデルを対象としました。そのためどれだけ集まってくださるのか不安でしたが、40名弱もの方にお集まりいただきました。半数程度が大阪からきて下さっていました。ありがとうございます。

 2次会は近くの「世界の山ちゃん」にしました。さすがに本場は美味しくて安かったです。3次会は少数有志が「台湾にもない台湾ラーメン」を食べに味仙本店まで行きました。別働隊は女性のいる店に直接向かって4時まで飲んでいたとか風邪を引いたとか様々な噂を聞きました。名古屋の夜も楽しく更けていきました。

 この勉強会をなぜ知ったかを数名に尋ねました。スタッフでもあるPHPメンターズの後藤さん経由の方が多くおられました。驚いたのは、IT勉強会カレンダーを見たという方。ここはメールを出さないと載せてもらえないので、たまに忘れるのです。今回偶然メールしてよかったと思いました。

<今回の勉強宴会資料>

1.IT勉強宴会 開催のご挨拶
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_1_sano.pdf

2.ジェネレーティブ・プログラミングの世界
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_2_kubo.pdf

3.帳票・フォームの自動生成
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_3_nakanishi.pdf

4.データマッピングフレームワーク Rmenu
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_4_1_shimoji.pdf
デモサイト、ソースコード他、構築方法のご案内
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_4_2_shimoyama.pdf

5.超高速開発ツール-Wagby-のご紹介
http://wagby.com/wdn7/
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_5_nie.pdf

6.「仕様書駆動」のための開発基盤 XEAD Driver
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_6_watanabe.pdf

番外:新世代DOA-ネーミング
http://www.onas.asia/home/benkyoenkai/doc/Kansai-IT-Benkyoenkai_2014-02-15_9_sugimoto.pdf


<IT勉強宴会 開催のご挨拶>
(株)セールスフォース・ドットコム 佐野初夫

 2010年から開始したこの上流工程勉強会も今回29回目になる。当初は飲みながら勉強しようというのが主旨だったが、今は普通の勉強会のようになっている。過去28回のタイトルを一覧した。詳細なブログがあるので、興味のありそうなネタを読んで欲しい。

<ジェネレーティブ・プログラミングの世界>
(株)アイテマン 代表 久保 敦啓さん

(1)従来開発との違い
 従来の開発は、ドメイン(≒業務領域)知識を仕様書に書き、それを開発者がソースコードに変換していた。ジェネレーティブ・プログラミングでは開発者は「解決ドメインモデル」からあらかじめジェネレータを作成しておく。ドメインエキスパートはドメイン知識を使ってDSLを記述し、ジェネレータに入力することで実行可能モデルを作る。ジェネレータの対象外の処理についてはオプションとしてプログラミングすることもある。

(2)ドメイン
 問題ドメイン=問題領域、アプリケーションドメイン、問題空間
  ユーザ(ドメインエキスパート含む)の活動領域
 解決ドメイン=解決領域、解決空間
  ソフトウェアにかかわる人間(主に開発者)の活動領域
 ドメインモデル
  問題ドメインのドメイン知識を入力とし、解決ドメインにおいて構成された抽象
 ドメイン特化言語DSL:Domain Specific Languages)
  ドメイン知識をユーザーのニーズに合わせた詳細レベルで記述するための言語

(3)ジェネレーター
 DSLで記述されたドメイン知識を解決ドメインモデルの組み合わせに変換するプログラム

★資料に大量の用語集と参考文献をつけて下さっています。

<帳票・フォームの自動生成>
名古屋経済大学 経営学部教授 中西昌武先生

(1)経歴
 元々社会統計解析データベースを研究していた。要件を出すユーザと開発側とのキャズム(深い溝)を感じたこともあり、大学を辞めてコンサル会社に勤めた。その後また大学に戻った。

(2)帳票のパターン
 帳票のパターンを数式で表せることに気付いた。TH法やT字形ER手法は帳表を集めて、その構造を調査してDB化を行う。それとは逆に、DBが先に与えられると、帳票のパターンが限定できるはずと考えた。
   帳票   → DB構造
   DB構造 → 帳票パターン

・エンティティ(テーブル)からエンティティをどう参照するかのパターンを考える
・グラフ理論を使うと、5つのエンティティで最大50パターンしかない
・実際の帳表生成ツールの中には20パターンほどしか生成していない例があって、放置はユーザのためにならないが、理論的には全パターンが自動生成可能である
 ※詳細は資料をご覧ください

<データマッピングフレームワーク Rmenu>
下地忠史さん

(1)アプリケーションの基本は項目移送
 データに着目して自動的に項目移送を行うフレームワーク。基本は次の2つの動作を行う。
・画面(ブラウザ)で入力したデータをDBに格納する
・DBから取得したデータを画面・帳表に出力する

 JsonはRubyプログラム内に取り込むとハッシュオブジェクト(配列)になるため項目名称が不明でも項目移送が可能。SQLの結果セットもハッシュオブジェクトに格納される。

またJsonの項目名(Key)には日本語が使用可能なので格段に可読性が向上する。

(2)アプリケーションの階層と役割
・アプリケーションプログラム
  ブラウザ側(JS)はSMVC(SPEC/MODEL/VIEW/CONTROLER)モデル
  ※SMVCは下地さんの造語です。Jsonで記述した内部DSLをSPECと呼んでいます
 サーバ側(Ruby)はMVC2モデル
  ※Smalltalk-80で提唱されたMVCでなく、WEBアプリのサーバサイドモデル
・Json(外部DSL)
 項目移送を自動的に行うために定義する言語
・Rmenuフレームワーク
 SQL発行(Sequel)、並列分散処理(Rinda)、オブジェクト通信(dRuby)
 PDF作成(Prawn) などを使用している
  ※詳細なメッセージシーケンスを説明されていますので資料をご覧ください

<デモサイト、ソースコード他、構築方法のご案内>
ergo 下山吉洋さん
 期間限定デモサイト:http://ii-care.com/
  ※トップページにある、事業所コード/ID/PWを控えてログインしてください
 フレームワークのソースコードや構築手順書:http://rmenu.onas.asia
 春日井市でソフト会社をやっていますのでrmenu、xeadなどご相談下さい

<超高速開発ツール-Wagby-のご紹介>
(株)ジャスミンソフト 代表 贄 良則さん

(1)超高速開発コミュニティ
https://www.x-rad.jp/
 2013.3の日経コンピュータの特集から「超高速開発」という名前を使い、コミュニティを作った。特集は、この業界の労働集約型からの脱出を図るために、プロジェクトマネージメントや生産性向上などが重要だとあった。ツールももう少し頑張っても良いのではないかと考えている。
 オープンにするために「コミュニティ」にした。ツールベンダーだけでなくユーザ企業の情報交換の場として活動している。

(2)Wagby
 沖縄のソフト会社。4~5人だけでツール開発している。Java+Tomcatの構成で、10年前に作った。外部に営業を行いだして7年になる。

 そもそも、「モデル」とはデータの構成ふるまい制約で成り立っている。それらを全部自動生成しようとして昔のCASEは失敗したのだと考えている。Wagbyは、ふるまい、特にテーブルをまたがるふるまいはプログラミングで記述することにした。
<方針>
 ・よくある業務要件は、ルールにして選んでもらう(テキストに出力)
 ・ないルールは自動生成できない(プログラミング)
 ・非機能要件は最初から作りこむ(ユーザ管理、統計、ログ)
 ・htmlなので比率画面にすることで画面を自動調整する
  (レスポンシブルデザインの言葉がなかったときからやってる)

 長年お客様にご利用いただいていますから、様々な要望をお聞きして対応している。
・再見積りしたときに自動的に枝番(XXX-002)を振る機能
・メニューのどこに居るかを示す「パンくずリスト(breadcrumb list)」
 ※童話「ヘンゼルとグレーテル」で迷子防止にパンくずを置いた事に由来
・画面の段組み機能
等々

(3)アーキテクチャ
 当初STRUTSを使っていたが、EndOfLifeになったためSpring MVCに載せ替えた。JavaEEとどちらが良いか最後まで迷ったが間に合わず、実績のあるSpringにした。
フロント側のJavaScriptライブラリーはDojoツールキットを使っている。いまどき何故JQueryじゃないのだとお叱りを受けることもあるが、出自がIBMなのでUIフレームワークとして使い勝手が良い。

 Model←→Controller←→Service ←→ DAO ←→ Helper ←→ Meta

 Metaはテーブルにどういう項目があるかなどのメタ情報のこと。

 DAOはHibernate。最近のはやりの「汎用DAO」を使っている。プログラムの自動生成と言っているが、このDAOを継承するので極端にコード量が少ないクラスが出来るだけ。SQLも書いていない。クライテリアコンバータに任せている。

 Serviceはトランザクションの事。Springは@Transactionのアノテーションを書くだけでトランザクション制御をしてくれる。JavaEEも7になって出来るようになった。

(4)カスタマイズ方法
 サーバー側は、「GenerationGapパターン」を使っている。つまり、自動生成するのはスーパークラスのみとし、それはカスタマイズさせない。カスタマイズは、スーパークラスを継承して必要なメソッドだけオーバーライドしてもらう。それだけでは上手くいかないので、Springの機能と組み合わせてよい感じになった。インスタンスはNewせず、SpringからGetBeanしている。Springはオブジェクト生成の時に、カスタマイズクラスがあればそこから生成してくれる機能を持っている。

 ブラウザ(UI)のJavaScript側は残念ながら上書きになる。REST APIを充実させることによって、ブラウザのUIでなくネイティブアプリで対応してもらおうとしている。

 DSLはKey Value形式というかプロパティ形式としている。マニュアルに載せてある。

※贄さんのジャスミンソフト日記に当勉強宴会の印象などがアップされています。

<「仕様書駆動」のための開発基盤 XEAD Driver>
(有)ディービーコンセプト 渡辺幸三さん

(1)問題提起
 「仕様書プログラミング」とは、文書の仕様書を元にしてプログラムを作る手法。2020年までに絶滅した・・・ということになってほしい。設計ミスや仕様変更に伴うコストが半端なく大きい。

アジャイラーが仕様書より動くコードを優先することは理解出来る。ある種のソフトウエアには合っているが、業務システムはダメ。業務システムは、仕様書が大変重要です。なぜなら、長い間に人が変わりながら保守されるものだから。
解決方法は、仕様書は書きそれがそのまま動くという「仕様書駆動」になる。

(2)「仕様書で動くシステム」を作る
 1)データ処理機能をパターン化する
  画面(パネル)や帳表など必要なパターンを定義します
 2)パターン毎に仕様情報を様式化する
  XEADはXML形式でテキストで出来ています。これがDSLです。
  本格的な生産管理システムを無償公開しています。テキストなのでたった2MBです
 3)仕様情報の編集ツールを開発する
  業務システム開発におけるCADツールに相当する
 4)仕様情報の翻訳ツールを開発する
 5)仕様書を編集してシステムを起動する
 6)出来に満足してビールを飲む

(3)XEAD Driver 生産管理システムの説明

 省略します

<所感>

 大変面白かったです。まずは久保さんが、
  1998年の「マルチパラダイムデザイン
  2000年の「ジェネレーティブプログラミング
  2003年の「エリック・エヴァンスのドメイン駆動設計
という一連の文献を要領よく整理して解説してくれました。前回のDDDに参加していなかった方にも今回のIT勉強宴会の主旨、位置づけが理解されたと思います。

 次に名古屋経済大学の中西先生が長年研究されていた帳表の自動生成理論について説明されました。業務システムの設計という分野はアカデミックから取り残されているように感じていましたので、心強く感じました。

 そして各ツールがどうジェネレーティブ・プログラミングを実現しているのかの解説です。3つのツールを横並びで説明されると、その理論ベースとなっている開発方法論が透けて見えるような気がしました。どなたもデータモデリングが原型になっています。おそらく業務システム、そういうと大きすぎるなら「自律的帳簿組織アーキテクチャ」(杉本さん命名)というジャンルでくくることが出来るでしょう。

 この名称は、IT勉強宴会の準備段階の議論の中で生まれました。事前にどういう議論がなされたかはGoogleGroupの次のスレッドをご覧ください。
・帳簿組織とは
  https://groups.google.com/forum/#!topic/kwansaiit/pHpC3aQR6mQ
・関連クラスとDOA
 https://groups.google.com/forum/#!topic/kwansaiit/mtE70vdSJ3U
・ジェネレーティブプログラミング、ドメイン駆動設計、MVC、DCI が統合された James O. Coplien 氏の世界
 https://groups.google.com/forum/#!topic/kwansaiit/YsPr-26EbYo

 勉強宴会が終わってからもしばらく議論は続きました。参加は次のアドレスに空メールを送るだけです。退会も簡単です。
KwansaiIt+subscribe@googlegroups.com
 ※+は1バイトのプラスの文字です

 このIT勉強宴会は上流工程と言っても、広い意味で帳簿組織以外の業務やシステムは対象にしていません。その事を強く感じました。

以上

【ソフトを他人に作らせる日本、自分で作る米国】を語ろう

$
0
0
2014-03-06(木)第30回IT勉強宴会in新大阪 【 ソフトを他人に作らせる日本、自分で作る米国】を語ろう。案内はこちら

著者の谷島さんとは偶然Facebookでつながっていました。昨年秋に本を出されたので大阪に来られる時に勉強会に来て欲しいとお願いしていたところ、急遽実現しました。当日東京に戻られるという事でしたので、新大阪の住友電工情報システム様の会議室を貸していただきました。大変面白い会になりました。本当にありがとうございました。

25名ほど集まって頂きました。

6人が10分ずつコメントし谷島さんのコメントと質疑応答。結果21:00ぎりぎりに終わりタクシーで新大阪駅に。無事21:20の最終の新幹線に乗られたとお電話を頂きました。そのころ有志11名は近くの居酒屋さんで焼酎の一升瓶を開けていました。くつろぎ庵という居酒屋、安くて美味しくてお酒の種類も豊富でまた来たいと思います。後で聞くと住友電工情報システムのメンバも常連だとか。閉店で追い出されたあと新地に繰り出した人も・・・(笑)

<今回の勉強宴会資料>

1.佐野(@hatsanhat)の感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0601_sano.pdf

2.SRA阪井誠(@sakaba37)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0602_sakai.pdf

3.fusion_place 杉本啓(@sugimoto_kei)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0603_sugimoto.pdf

4.某ユーザ企業 情シス屋さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0604_jyosysya.pdf

5.あきぴー(@akipii)さんの感想
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-03-0605_akipi.pdf

<出版の目的と背景>

日経BP 谷島宣之さん

今は、研究員という立場になっています。記者は35歳までと言われていました。実際に気力体力が最高潮なのはその辺りまでだと実感します。過去の経験の蓄積はありますから改めて取材しなくても書ける事も多いのですが、それが正しい記者の姿とは思っていません。

1985年に日経コンピュータの記者になり、コンピュータによる業務システムを取材しました。代表作と言われているのが「動かないコンピュータ」シリーズです。取材先から叱られたり、こんな事を書くと業界に良くないなどと言われながらも続けました。
取材をする中で、コンピュータを知らない経営者にも、ほんのいくつかを知って欲しいと思うようになりました。そこで、2002年から日経ビジネスオンライン(当時は日経ビジネスエクスプレス)に連載を始めました。今も続いているそのコラムを中心にまとめ直したのが本書です。

途中、グランドデザインのところで、福田恆存(つねあり)の話を書きました。30年ほど前若いころから大変好きな評論家ですので一度書きたいと思っていました。

<本の感想や想い>

(1)セールスフォース 佐野初夫の感想
 28年間日本のIT企業にいて、外資系に転職して2年です。外資系に入って驚いた事がこの本の中に散見されました。特に気付くのは、外資系では新しいやり方が出てくる時には必ずプロセスが同時に示される事です。本書(P.58)に日本企業が新製品を作ったから意見を欲しいと言われた外資系日本法人の社長が単純な4つの事を尋ねると答えられなかったというエピソードが出てきます。

「どういう顧客セグメントに売りますか?」「売るためのシナリオは?」「シナリオ通り行っている事をどういう指標で確認しますか?」「上手くいかなかったときのバックアッププランは?」

もちろん個々の営業マンがアレンジしますが、外資系企業では基本プロセスは上から指示されます。セールスフォースというツールもそういうプロセスがある事を前提としていますので、日本企業に提案する時はプロセスを作る所からお話することにしています。

 日本では会社内部のシステムの話を他社と話する事が出来ません。そのために会社の中に入っていると他社がどうやっているのかを知る機会が極端に制限されています。コンサル会社やソフト会社はその情報格差で上手く立ち回って商売をしています。この勉強宴会のような【場】をNDAを結んだ会員制にするなどすればお役に立てるのではないかと考えています。

(2)SRA阪井誠(@sakaba37)さんの感想
http://sakaba.cocolog-nifty.com/sakaba/2014/03/post-1cef.html

 IT技術者の人数に関して、米国は7割が一般企業にいて、日本は7割がIT企業にいると言う記述があります(P.12)。米国の情報システム部門の人数は日本の10倍とも書かれています(p.13)。それを時系列に整理して考えてみました。

 そもそもソフトウエアエンジニアリングには、米国国防省(DoD)系と航空宇宙局(NASA)系の流れがあります。軍事も宇宙開発も予算が減ってきたので一般企業に流れたという側面があるでしょう。また、2000年前後にはインドをはじめとするオフショア開発が盛んになりました。米国のIT企業にオフショアを入れるとこの数字が正しいのでしょうか。

 日本のソフトウエアは米国と較べて5~10年遅れていると言われていますが、実際は日本の方法論をマネされている事も多いです。ただ、アメリカは標準化とアピールが上手いです。米国のCMM(能力成熟度モデル)に対抗してヨーロッパはSPICE(プロセスモデル)を標準化しました。そのためCMMI(能力成熟度モデル統合)になった時にSPICEの要素を入れて単純な段階でなくなりました。それを参考に強みを生かし独自性を出す事も必要だと思います。

 これからは、科学、工学、技術の統合の時代になると思います。

(3)fusion_place 杉本啓(@sugimoto_kei)さんの感想
 コンピュータ以前の時代では、「仕事の仕組み」は仕事をする人が作ってきました。ところがコンピュータを前提とした仕組みは難しすぎるため、仕事をする人と仕組みを作る人が分離しました。そうするとお互いにぎくしゃくするようになりました。
・仕事をする人:自分の仕事の道具に対するオーナーシップを失っている。
  思った通りに出来ていない
・IT専門家: 自分の作品に対するオーナーシップを失っている。
  「仕事をする人」が言った通りに作っただけ

 ITを情報の情報の整理・管理・利用に 関する技術(m-IT)と電子的情報処理及び通信に 関する技術(e-IT)に分離させてはどうでしょうか。そしてe-ITには単なるプログラミングだけでなく、EXCELのようなツールを整備します。例えば、業務領域に特化したドメイン特化プラットフォーム(DSP)が整備されると内製化も楽になります。例えば計数管理業務についてはfusion_placeというDSPを使えば問題領域だけに特化した構築が出来ます。

 「仕事のプロ」、「仕組みづくりのプロ」、「道具作りのプロ」の役割を明確にすることで協働作業が可能になると考えています。

(4)住友電工情報システム 谷本收さんの感想
 住友電気工業という会社は、そもそも何でも自分で作る会社です。生産管理システムも自作しています。電線・光ファイバー・アンテナや工具素材など多種多様なものを作っていますのでそれぞれに異なるシステムが必要です。そのために基本的な仕掛けに関して共通部品を作り、その上で構築しました。それが楽々フレームワークです。

 谷島さんは当社の事をご存じですので、内製企業の話になった時に当社も書いて下さるかと期待したのですが、書かれてなくて残念に思いました。

 2007年に住友電装を子会社化しました。そこは自動車のワイヤーハーネスを作っている企業です。この業界は早くからグローバル化しているとともに、技術革新が速いため次々に新しいシステムが必要になります。手作りする時間を節約するために多少高くついても外から買っています。

 今も、新しい言葉が次々に現れますが、どう解釈するかの判断が難しいことがあります。日経さんには方向づけにも期待したいと思います。

(5)某企業 情シス屋さんの感想
 ユーザ企業の情報システム部の部長です。この本は「どちらが良いと言ってるわけではない」とは言われながらも「何故内製出来ないのだ」と叱られているのだと思って読みました。私の部には、手作りをするための部も設けています。私が若いころに最初から最後まで一人でやらせてもらった経験が今の自分を作っているのだと思います。そのため若い人たちには全行程を一人でやってもらうようにしています。

 ソフト会社の方は、システム構築というと設計から開発だと考えると思いますが、実際にはそれらはほんの小さな部分です。企画から立案し、利害調整を行ったりデータ移行やマスタセットなど雑多な作業が数多くあります。ドラマはそういう所にこそあります

 ところが若い人の多くは、リスクを恐れるためなのか自分で作るよりも外部から調達しようとする傾向があります。「内製でやりたい」という”情シス屋”を増やしたいと思っています。そのためにどう動機づけすればよいのかを試行錯誤しています。

(6)あきぴー(@akipii)さんの感想
http://forza.cocolog-nifty.com/blog/2014/03/30itit-c132.html

 日本のユーザ企業内のIT分野の問題(課題)として3点を強く考えています。まず、「ロールが多すぎる」事。最終決定者が誰なのか曖昧で、会議で議論しても意見がまとまりません。次に「開発プロセスがIT化されていない」事。重要なプロセスはEXCELで管理している事が実態です。最後に「ERPが陳腐化しやすい」事。5年経つと必ずリプレース作業が発生して手間がかかります。

 設計手法は色々ありますが、最も重要なのは現在のシステムからリバースエンジニアリングする作業じゃないかと思います。その時にはUMLは役に立たないので、DOAが有用ではないかと考えています。

<感想に関するコメントと質疑応答>

・テーマは日本と米国の違いです。どちらが良いという事ではありません。決定的な違いはありますが、良い部分があるなら普通に学べば良いだけです。
・一番の違いはConceptual Skill(概念化能力)の違いかなと思います。米国は抽象的な話でも延々と議論します。日本人は何故何故のように、下に向かって深堀することは得意ですが、上に向かって複雑な事象を概念化する事は弱いと思います。
・そのスキルが強いのは一神教だからかも知れません。

・プロセスを明確にするというのは、労働者の流動性の問題だと思います。「Bさんがいなくなればどうするの?」という危機感は日本より米国の方が強いです。
・IT技術者の日米比較は他の方からも日経がちゃんと調査して欲しいと言われています。
・コンピュータの発明は戦争の弾道計算です。それ以降もコンピュータの進化は軍事的なものが中心ですから厳しさが違うのかも知れません。
・杉本さんの話は原稿が書けるほどだと感じました。
・Conceptualといっても一番重要なツールは言葉です。超高速開発という言葉も、何をメリットとするのかが明確でなければ意味がありません。
・昔、イノベーターと言われている7名に「あなたはどうして成功出来たのでしょう?」と聞いていくという企画をしました。すると全員が「若いころ全行程を経験させてもらった」と異口同音に仰るので原稿をどう書くか困った事があります。企画して設計して製造して販売ルートを探して値決めして販売してという全行程を経験するとビジネス全体の感が働くようになるのかも知れません。
・インテグリティという言葉は、ドラッガーの翻訳者の上田さんは「真摯さ」と訳されましたが、データのインテグリティという言葉もあるように一貫性・完全性というニュアンスもあります。日本語にすると騎士道とか武士道が近いのかも知れません。
・日本は20年もすれば間違いなく人口が減少します。ITスキル以前に人数が足りなくなります。そのため企業はIT技術者を雇うことになるだろうと考えています。

<所感>

多少無茶な企画かとも思いましたが、発表者は皆さん知り合いですので何の心配もしませんでした。想像以上に面白い会になりました。約3時間でしたが、倍の時間があっても良かったほどでした。谷島さんには初めてお会いしました。遠慮がちに訥々と語られる口調に味があって楽しかったです。

 情シス屋さんのお話は特に面白く感じました。私がこの勉強宴会を続けているのも若いSEさんが、情シス屋になるきっかけになって欲しいという気持ちがあります。ただ、ユーザ企業は明文化されていない(出来ない)守秘義務の壁を感じている方が多いため気軽に参加されないのが残念です。この情シス屋さんが匿名希望なのもその表れでしょう。昔ベストセラーになった、バカの壁なのだと思いますが、大企業になればなるほど厳しくなっているのも事実です。

 守秘義務の問題だけでなく、自社のシステムが恥ずかしいと思っている企業も多いです。ご自分の会社のシステム内容を話せば、どの企業も似たような悩みがあることがわかるでしょうし、恐らく内製化へのきっかけにしやすいと思います。でも日本では当面難しいでしょう。

以上

システム開発に関わる法令

$
0
0
 最近この勉強宴会の常連になって下さっている、けんじ@淀川区さんから「いつも勉強させてもらっているので、たまには私が経験をお話しましょう か」と申し出て下さり企画した会でした。前回初めて参加していただいた川端さんに無理をお願いして、外部勉強会で初めて話すお二人で発表して頂きました。

 川端さんはお子さんがロボットコンテストの日本代表に選ばれたので4月末にお子さんと一緒に米国での世界大会に参加されていました。そのためこの時期まで開催を延ばしました。日本代表とはすごい快挙ですね。おめでとうございます。

  直前まで8名ほどの参加申し込みだったので2次会も8名で予約していました。ラスト2日ほどで15名に増えてしまい、しかも30分も早く終わってしまった ので宴会の場所を変更するのにバタバタしてしまいました。申し訳ありません。ま、結局いつものメンバで3時ごろまで飲んでました。
 

<今回の勉強宴会資料>

.けんじ@淀川さん「法律をネタに要件定義」
 http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyo-Enkai_2014-05-16_kenji.pdf

2.ビジネスブレイン太田昭和 川端さん「とんでも契約に騙されるな」
 http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyo-Enkai_2014-05-16_kawabata.pdf


 <法律をネタに要件定義>

けんじ@淀川さん

会 社名を出すと色々問題があるかも知れませんので匿名とさせていただきます。会社全体としては大きいのですが、私の工場は中小企業の製造工場です。20年近 く製造現場にいましたが、パソコンが詳しかったため急に「I社コンピュータが使えなくなるのでシステムを作って欲しい」と無茶ブリされました。最新仕様書 はなく、作った人も既におられませんでした。

色々ヒヤリングすると現場の方は「現状維持」しか考えていない事がわかりました。もっと広くヒヤリングしていくと、目の前の小さな改善を訴える方がおられたので、その方の要件を実現したところ使えないシステムだと言われました。

ちょうどそのころJ-SOXという監査の波があり、それを勉強したところ今までの業務の流れではまずい部分が多くあることがわかりました。増強された監査部と協力して(監査部の後ろにひっついて)監査と言う視点で要件を整理する事が出来ました。

法律を勉強していくと、J-SOXだけでなくいくつもの法律で気をつけないといけない事があり、それを改善する事で「受注・売上、発注・検収、設計・生産管理」のシステムを作る事が出来ました。

 <とんでも契約に騙されるな>

ビジネスブレイン太田昭和 川端悦子さん

 「ト ンデモ”IT契約”に騙されるな」という日経コンピュータ編の本を参考にして、システム開発で「もめやすいポイント」について見て行きたいと思います。 ちょっとビブリオバトルにようになりますがご容赦下さい。この本は富士通(9年)→野村総研(8.5年)と技術者の経験を得られてから司法試験に合格され て弁護士になったという異色の経歴の方がかかれています。

自己紹介ですが、モットーは【やらずに後悔するよりは、とにかくやってみる】、今注力していることは(高校生の息子より先に)【女子大生になる】ことです。今は単科生として通っていますが、来年春に入学したいと思っています。

 ま ず、いま”トンデモ契約”が問題になる理由は次のように考えています。かつては発注者(ユーザ企業)側も開発の経験があり、何か問題があれば「いっしょに 泥をかぶる」という覚悟がありました。それが今は自社で作らない風潮になり「モノを買う感覚での発注」になっています。そういう感覚でシステムを発注する 事は大変危険です。この本はユーザ視点で書かれていますが、ベンダー側からみても「もめるポイント」に気付くというメリットがあります。

請負契約は納品責任があり義務については比較的わかりやすいですが、準委任について何の責任もないと誤解されている方がおられます。準委任は善良な管理者の義務(善管注意義務)といって普通よりも高い義務が求めれてます。それで問題となるケースも多いです。

(事例1)細切れ契約で、本番直後なのに損害賠償を請求出来ない
契約書にこう書かれている場合、基本設計のミスが本番後に判明しても損害賠償出来ない事があります。
「この請求は、帰責事由の直接の原因となった個別契約の成果物の検収完了日から6カ月が経過した後は行う事が出来ない」
IT業界で多段階契約が推奨されるようになったことに乗じてこういう契約が増えました。

(事例2)損害賠償額が「スズメの涙」
「帰責自由の直接の原因となった個別契約の委託料を限度とする」と書いてあると、全体で1億円のお金がかかり数億円の損害があったとしても、基本設計1千万円の限度額になります。

 (判決事例) 発注者の協力義務 VS ベンダの専門家責任
要件定義が完遂しないままプロジェクト頓挫。
ベンダの主張:要件肥大化、要件変更を繰り返した、要件定義に必要な資料をもらえなかった
 ユーザの主張:肥大化/変更は当然、出来る限り資料はだした
判決: ほぼユーザの主張に沿った判決が出ています

 万一の訴訟の危険性に備えて、リスク対応の工夫(リスクプランニング) と 履行円滑化の工夫(パフォーマンスプランニング)のバランスを上手くとった契約書が重要になります。さらに事前にお客さまと「十分にぎっておく(コン:ジェンシープラン作成)」ことが肝要です。

 <所感>

 色々な経験をされている方が多くおられますので、さまざまな意見が出て楽しかったです。この判決の事例などは典型的な「プロジェクトあるある」なので、そういう中でどう立ち回るかがこの業界で生き残るノウハウなのでしょう。
私も個人的には、お客様がそのシステム開発について当事者意識がない事が問題だとは思いますが、ベンダー側に技術力がない事がプロジェクト途中で初めてわかる事もあります。本来の契約典型としての「請負契約」はこの業界には適さないのだと思います。

なお、法律的な変化についてのアンテナを高くしようという事で経営戦略のフレームワークを少しお話しました。ググれば多くの情報がありますので、キーワードだけ書いておきます。
マクロ環境分析:PEST
業界 マクロ分析:ファイブフォース
業界 ミクロ分析:3C
自社 売り手視点:4P
自社: バリューチェーン
自社: SWOT

以上

モデルとは何か

$
0
0
実に楽しかったです。会議室をお貸し頂いたテラスカイの皆さま、特にセッティングと後片付けをお手伝い頂いた方々に感謝致します。

初めての東京開催でした。集客を心配していましたが、何と募集2日でほぼ満席。10名ほどの補欠登録までして頂きました。椅子を増やして頂き全員にお越し頂きました。佐藤正美さんはマスコミにほとんど出られませんので知らない技術者も多いかも知れませんが、今でも熱狂的なファンが多くおられます。

ネットで偶然佐藤さんの名前を見つけて来て下さった方もいらっしゃいました。大阪等からも常連者が10名近く来て頂いていました本当にありがとうございました。2次会はなんだか秘密基地のような所で座る場所がないほどの人数でワイワイやりました。3次会は1:30ごろまで飲んでました。最後まで付き合ってくれたのは大阪(および岐阜・名古屋)から来てくれたいつもの常連さんでした(笑)

<今回の勉強宴会資料>
1.株式会社テラスカイ 今岡純二さんの資料
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-06-26_imaoka.pdf

2.株式会社SDI 佐藤正美さんの資料
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-06-26_sato.pdf


<Salesforceにおけるモデルドリブン開発>

株式会社テラスカイ 今岡純二さん

1.セールスフォースについて


 当社テラスカイは100名ほどの会社規模で、セールスフォースをはじめとするクラウドを専業として導入・開発を行っています。セールスフォースは生産性5倍と言われます。各種調査会社の結果でもほぼ5倍の生産性が出ていますのでこの数字は客観的なものではあります。ただし、標準的な画面や機能を使えば抜群の生産性が出ますが、リッチな画面などプログラム開発してしまうと一般の言語とそれ程生産性は変わりません。

2.メタモデルについて


セールスフォースはマルチテナントのクラウドシステムです。内部のメタ構造は単純化されています。まず<メタデータテーブル>として、利用者が定義したオブジェクト(=テーブル)と項目名が格納されています。<データテーブル>として全ユーザのデータが一つのところに格納されます。処理を高速化するためのインデックスなど<ピポットテーブル>もあります。この単純化された構造の中で、あらゆる組織(ユーザ企業=テナント)の異なるデータを扱いつつ一定のパフォーマンスを確保しています。




 ところが、ひとりの開発者の視点から見ると単なるRDBに見えます。ただしPrimaryKeyはセールスフォースが勝手に付番します(オブジェクトキーに近い)



3.データモデルについて

セールスフォースで開発する時にはデータモデリングが大変重要です。それは主に3つの意味があると思っています。まずオブジェクト関連(ER)によってユーザインターフェースが決まってきます。次に良くないモデリングでは生産性が悪くなります。また保守性も悪くなります。
 デモを見てもらいます。
(1)注文ヘッダオブジェクトを新規に作成する手順
(2)テキストエディタのメタモデルで注文明細を作りデプロイする手順
(3)SkyVisualEditorを用いて注文のヘッダ+複数明細を一画面に出す手順
 ※これはセールスフォース標準で行う時にはプログラムが必要です


TerraSky Tech Blog
http://blog.terrasky.co.jp/blog/
もご覧ください。

<モデルとは何か(論理的意味論として)>

株式会社SDI 佐藤正美さん

1.モデルを考えだしたきっかけ

私は80年初頭、日本にRDBを持ち込んだ技術者の一人です。東京で大きなプロジェクトを行っている時に、社長のビル・トッテンに「大阪でトラブっているから行ってくれ」と言われて3日間の予定で行きました。何もわからず行ったのでお客様に状況を教えてほしいと言うと「CPUを80%削減してくれ」と言われました。無茶な話ですが、設計を見ると問題点がわかりましたので2日で60%削減まで出来ました。お客さまも喜んで接待してくれました。
 飲みながらお客様に言われたのは、従来のファイルと内部構造が違うのなら運転の仕方が違うのだろう。それは理解できるが、内部構造を知ってまで使いたくない。それに向いた設計の仕方があるはずだ。

 それからRDBに向いたモデルの方法を考えました。それまで数学などやったことがなかったのですが、40歳代は数学の勉強に費やしました。私のモデルは数学の技術を使っているだけです。数学と言っても、数学基礎論(現代集合論)という分野です。特にゲーデル、チューリング、フォン・ノイマンが重要です。ゲーデルの完全性定理は簡単ですが不完全性定理が基礎になっています。

 数学的基礎論は大きく4つの分野で出来ています。
(1)集合論  (2)関数論 (3)モデル論 (4)証明論
「モデルとは何か?」を語って欲しいというお題をもらいましたが、私の方法は単に数学の技術を使っているだけですから改めてモデルとは何かを定義出来ません。ちなみに昔はT字形ERと呼んでいましたが、今はTMと呼んでいます。数学の世界ではTMはチューリングマシーンの省略形ですが、Theory of Modelsの略として命名しました。

2.モデルについて

それでもあえてモデルとは何かを考えると、【理論式】の事になるのかと思います。集合Xのすべての元が集合Yの1つの元に対応しているとき、この対応を写像または関数と呼びます。y=f(x)を理論式と呼びます。これに対して、理論によらないで実験したデータに合うように作った関係式を実験式と呼びます。

 さて、モデルの構成です。TMは論理的意味論という手法を使っています。まず事業過程から事業がどう営まれているか(現実事態)を見ます。事業過程は人から人に情報を申し送りすれば成り立ちます。その申し送りしている情報をいかに正確に持ってくるか。これが大変重要です。
 FormalなものもInformalなものもあります。同じ会社なら文脈で解釈出来る事も、文脈がわからない我々には最初から正確な意味がわかるわけありません。そのためざくっとエンティティを取ります。
 ※エンティティという言葉は正確じゃないので変えたいのですが反対されています

(1)集める
 主題(何について言っているか)と条件(その属性)を集めます。主題は番号やコードがあるものです。「区分コード」は主題でなく条件とします。
(2)並べる
 構造をとり、正確な意味を取ります。 並べると足らない物がわかるので再度「集める」に戻るという行ったり来たりしてL-真(論理的に正しい)を作ります。
 この時にはand/or/notしか使いません。「どんな天才でも論理規則を破る事は出来ない」と言う通り100%これとこれは関係あり、100%関係ないと証明できまでやります。【関係の網羅性】=文脈から再度集合を作り関連を見ます。
 同じ現実からL-真は何通りでも書けます。例えば1→3という関連を見出した時、1+1+1でも1×3でもL-真です。それが文脈的にどちらが正しいかを次に確認します。
(3)現実との一致(値の充足)
 実際に値を入れてみて、現実と一致するかを見ます。これをF-真(事実的に正しい)と呼びます。F-真は一つしかありません。【制約束縛の網羅性】(これはロジックではチェック出来ません)

 

 論理的意味論では、構文論が先で意味論が後です。

3.タルスキの真理原則

文「p」が真であるのは、事態pと一致したとき、そしてその時に限る。という原則は当たり前のようですが、大変重要な原則です。
※(佐野注)この頁の[補遺]を見るとこの文の深さが少し理解出来ると思います
http://www.sdi-net.co.jp/sdi_328.htm

4.関係Rと関数f

関係 R(a,b):aはbに対して関係Rである
  →対称性  (a,b) = (b,a)  (aはbの恋人である)
   非対称性 (a,b) ≠ (b,a)  (aはbの父親である)
 関数 f(a,b,c)
  →全順序 大小関係などで並べる事が出来る
   半順序 なんらかの(辞書的配列など)並べ方がある。値の大小関係ではない。

 集合を作った時の全順序と半順序をどう判断するかで一年悩みました。事業過程は(情報の伝達で成り立つため)イベント主体です。そのため日付が帰属するものをイベント(全順序)とみなし、それ以外をリソース(半順序)としました。
※リソースと言う言葉を変えたいと思っています。案を募集中です。

 モデルを読む時は箱でなく一歩下がって線を読みます。論理で作れば読めます。技術者が自分の想いで勝手に書かれると読む事は出来ません。

5.簡単な例でモデルを作る手順
 (詳細は省略しますが、資料を見て下さい)
 ・セットで作ってクラスで整える。
 ・多値関数(クラスを入れる)・・・ファンクタ(関数の関数)を使う
 ・区分コードは右(条件)に置く
 ・得意先かつ仕入先はセットでない
 ・任意入力は現実にはあるが、形式的構造に持ち込まないこと
  何故ならnullの4値論理(Yes/No/unknow/undefine)を意識することになるから
 ・L-真がF-真なのかはお客様に考えてもらう。
  例えばこの3つの例を書いてどれが正しいのかを示してもらいF-真を取る
 
 

<所感>

発表していただいたお二人とも時間ぴったりで流石に手慣れておられました。今岡さんのデモはプログラムに詳しい人には驚きの内容だったようです。テーブル構造をテキストエディターからapiを用いでセールスフォースに登録出来たり、テラスカイさんのツールで作ったプログラムソースをapiで登録してコンパイルしたりが目の前で実行される内容でした。

佐藤さんのモデル論というかTMの基礎になっている理論は、今世間で流行っているドメイン駆動設計とはかけ離れて数学的な構造でした。若い方々にも参考になったと思います。

実は準備段階でTM大好きな方から個人的にメールを頂いていました。
<佐藤さんの仕事の仕方は、コンサル先のSEを指導し、彼らが「普通に仕上げる」ので
あまり成果が喧伝されないし、「彼らが普通にこなす」ので保守の仕事も基本無いという損なやり方です。>

興味があれば、早稲田大学のオープンカレッジやセミナーなどに行ってみて下さい。

以上



「受注生産」のためのシステム開発ライブ<第33回IT勉強宴会in大阪>

$
0
0
ブログをアップするのがこれだけ遅れたのは初めてです。サラリーマンが月曜にやるのは出来るだけ避けようと思いました。m(__)m

さて、流石に渡辺さんの集客力はすごくて有料で借りた大きな部屋が満員でした。スタッフ含めて40名近い人数でした。お越しいただいた皆様、本当にありがとうございました。

2次会は、初めての場所「ガソリンスタンド居酒屋 堺筋本町給油所」で20名でした。

レギュラー(クリアアサヒ)飲み放題で1500円でした。ハイオク(ドライ)は別料金。軽油(チューハイ)も飲めました(笑) 30cmほどもある大きなピザが500円。どの料理も美味しかったですね。もう一度行きたいです。


<今回の勉強宴会資料>

1.佐野初夫の資料
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-07-28_sano.pdf

※渡辺さんはXEAD Modelerで説明されましたので資料はありません

<生産管理システムオーバービュー>

株式会社セールスフォース・ドットコム 佐野初夫

1.生産管理について

 今日は受注生産管理システムのお話です。最近の若い方はおそらく生産管理システムの用語をご存じないと思いますので、我々がどういう事を考えてシステム化してきたかをお話します。勉強するきっかけになって欲しいと思います。バブルがはじけてからはこういう話をするコンサルタントも少なくなりました。
  受注生産に徹すれば利益はついてくるという書籍を参考図書に挙げましたので読んでいただいたことを前提にお話しします。

【生産モデルの一般分類】
 混流生産(トヨタ)、断続生産(タクト生産)、見越生産/受注生産  etc
【製造業の一般的分類】
 ディスクリート型(組立型) ←→ プロセス型
CODP(Customer Order Decapling Point)分類】
 DTO/ETO/MTO/ATO/CTO/MTS
  デルはBTO(Build To Order)と呼びますが、一般用語はATOだそうです。
【生産管理システムの変遷(グローバル)】
 MRP → MRPⅡ → APS
【生産管理システムの変遷(日本)】
 製番管理 → 追番管理 → セル生産方式(デジタル屋台) → JIT

 2001年に「ザ・ゴール ― 企業の究極の目的とは何か」の日本語訳が出ました。そこには従来の工程ごとの生産性を考えるのではなくスループット会計、つまり会社として売り上げを最大化することを全員考えるなど多くの提言を行っています。TOCもその一つです。ネック工程の生産性を最大化することを最優先する考え方です。

【TOC(制約条件理論)】
 ドラム・バッファー・ロープとは?
  ※資料を見てください


<【「受注生産」のためのシステム開発ライブ>

有限会社ディービーコンセプト 渡辺幸三さん

1.CONCEPTWARE生産管理システム

 ある製造業の方から、CONCEPTWARE生産管理が難しすぎると言われました。一般の組立中小企業ではあそこまでの管理は不要だという事です。つまり多くのメーカーは在庫管理もいらない、もしかすると工程管理すらいらない。部品表(BOM)もいらない。

 では、何がいるのか?

 受注生産としての仕様をきっちり管理したい。手書きでは間違いもあれば読めないこともある。作ってから間違っているという事態を避けたいだけだという事でした。

2.CONCEPTWARE受注生産システム

 そういう意見を聞いて、SIMPLEにしました。このシンプルなところから必要な機能は各社が自分で追加する。そう考えて作っています。

 ロット管理をやめました。私は製薬会社の生産管理の経験があるため、ロットでのトレース管理は必須だと思っていましたが、そうではありませんでした。一年に1度か2度、何かあった時にトレース出来ればよいだけだそうです。そのため適用欄にどの材料ロットを使ったかなどをメモとして記入します。

 品目マスター。このシステムの心臓部です。受注生産品だけでなく一般品もあると考えました。資材もここに登録されます。

 受注生産品マスター。品目ではなく独自の概念で仕様を表します。ここで登録されている範囲の仕様で受注生産を行います。受注生産ですから在庫は持ちません。2つの構成で仕様を表します。
(1) 受注生産品仕様構成
 Aタイプなら、長さ・幅・色はどの範囲で許すかを定義します。バリデーション(妥当性確認)項目だけでなく、導出項目も定義出来ます。それぞれ、式を登録することが出来ます。この件については、渡辺さんのブログに詳しく書かれていますのでご覧ください。

(2) 受注生産品標準材料
 Aタイプなら、この材料がこの程度必要というマスタです。ただ、「受注生産品仕様構成」は何度も参照され続けますが、これは注文に最初コピーした後は自由に変更出来るようになっています。調整区分として「客から支給される」「製番で発注する」なども指定できます。

 業務プロセスとしては、注文を登録した後、その内容を印刷してお客様に確認してから生産を開始するというイメージになります。

3.実装デモンストレーション

 XEAD Modelerの「一般仕入」をXEAD Editorに取り込み、詳細設計要素を少し加えると画面が立ち上がり業務レコードを登録するというデモ。

4.参加者の所感etc

・鋼板メーカーでは幅は決まっていて長さだけを指定して切って納品します
・色について、「大日本印刷の何番」という登録が必要です
・式の登録については昔はEVALを使っていましたが危険なので最近は式言語を使います
 (JavaScriptも出来る範囲が大きいので危険だと思われます)
・このモデルはコンテキスト(前提条件)が必要ではないでしょうか
・検査証を一緒に納品する業界があります。標準材料に入れれば対応出来ると思います

<所感>

今回は、「従来の生産管理を分かっている人には面白い」という内容になってしまいました。

まだ完成していないシステムのコンセプトの説明でしたので、詳細を説明するよりは大きな概念の説明でした。受注生産の仕様をメタ情報として定義するという仕掛けです。通常設計情報はCADなどの情報を含めてPDM( Product Data Management)というシステムで管理します。その情報の中から「完成品を定義する最低限の仕様」を定義するというシステムです。こんなシステムは私も聞いたことがありませんでしたので興味深かったです。

若い人が多く来ていただいたのでもう少しゆっくり説明した方が良かったかも知れませんが、私が理解することに集中してしまいましたので、その余裕はありませんでした。このメタ定義でどの範囲まで定義出来ているのかは私には把握出来ませんでした。

完成した時には再度詳細を説明してもらおうと思います。ぜひお越しくださいね。

以上

IT技術者が必要とする連結会計の知識<第34回IT勉強宴会in大阪>

$
0
0
20140926(金) 18:30から開催しました。申し込み案内はこちら

 初めてお借りする場所でした。「ヒルトン」だけみて間違ってヒルトンホテルに行きそうになった方から電話をいただいたりしながらも満員でした。ありがとうございました。完全に満席だと40名以上入る会議室を無料で貸していただけて本当にありがとうございました。「うちの会社も貸せるよ」という企業の方がいらっしゃればぜひお声をおかけ下さい。

 さて、勉強宴会はすごく面白くためになりました。特に会計のプロの常識と素人(私)の感覚のずれが露呈された所が素晴らしかったですね。恐らく後々「300円はどこに行った問題」と語り続けられるでしょう(笑) ただ、今回も残念ながらブログでは上手く伝わらないと思います。資料をじっくり読まれて内容を理解されてから再読されると少しは伝わるかも知れません。可能であれば次回以降ぜひ現場にご参加ください。

 2次会はいつもの白木屋西梅田店さんに18名でおじゃましました。いつもより30分早い20:45にスタートして「終電に間に合わないので・・」と抜ける方を見送りながら23:45まで、3時間。飲み放題で一人2,333円でした。いつも安く飲ませて頂きありがとうございます。

 3次会は今回は少なく4名で新地へ。帰ったのは3時ごろでした。

<今回の勉強宴会資料>

1.IT技術者が必要とする 連結会計の知識

<IT技術者が必要とする 連結会計の知識>

(株)フュージョンズ  杉本 啓さん

(1).連結会計にからめた自己紹介
 アンダーセン(現アクセンチュア)に17年いて会計・経営管理領域の制度設計・業務改革を中心にコンサルティングしていました。Hyperionという会計ソフト(2007年にOracleが買収)の日本語化や日本版連結会計モジュールを開発しました。

 日本も国際化・グローバル化の波を受けて2000年に会計ビッグバンが起こりました。グローバルスタンダードとして投資家からの客観的な情報開示を目指して様々な新基準が順次設定されています。そこでの重要な変更点は個別優先から連結優先への転換でした。

 会計の世界ではAccounting Entityという言葉が重要です。データモデルの世界でエンティティというとテーブルなどのデータのまとまりの事をいいますが、会計では「企業実体」と訳します。企業のグループ全体で最適化した活動をしているのなら、その企業集団(企業グループ)全体を実体としてみないと評価出来ないという考えです。

2003年に独立し、コンサルティングをしながら、経営管理基盤ソフトウェア「fusion_place」を開発・販売・導入支援しています。

 なお、これから「連結パッケージ」という言葉が出ますが、これはソフトウエアの事ではなくて連結決算をするための基礎情報の事をこう呼びます。

(2).連結会計の基本

1) 会社間取引・債権債務消去:「右手から左手に移しただけの取引はなかった事にする

 メーカとしての親会社と、100%子会社の販売子会社があるとします。
 A.親会社が200円で仕入れて、子会社に500円で売ります(利益300円)
 B.子会社はそれを600円で売ります(利益100円)
単純に合算すると売上は500+600=1100円になりますが、500円の売上は右手と左手の取引ですのでなかったことになって(企業実体とすると)600円の売上になります。原価は200円ですから利益は合算と同じ値の400円です。これはわかりやすいと思います。

2) 未実現利益消去:「売れてないなら利益はゼロにする

 上の例で1で終わったときを考えます。親会社は200円で仕入れて500円で売りましたので利益は300円です。一方子会社は500円で仕入れましたがまだ売れていないので商品(在庫棚卸)が500円になります。
 この時、親会社が計上した300円の利益は企業実体からみるとまだ実現出来ていないものですので未実現利益と呼びます。これの相手方勘定は子会社の商品ですから商品が500-300=200になります。

3) 少数株主持分の区分表示:「少数株主分の利益は連結してはダメ

 上の例(A,B)で子会社の株式の40%が外部出資の時、日本では利益だけに「少数株主損益」という費用項目を立てて▲40円(100*40%)とします。相手方勘定は留保利益になります。なお日本の税法では個別会計の利益に対して課税しますのでこれらはすべて税引き後だと考えてください。「連結納税」という言葉もありますが、日本ではまだ親子会社間の利益・損失を繰り延べして払い過ぎた税金を相殺出来る程度しか効力がありません。
(2012年3月期にソニーが「繰り延べ税金資産」を取り崩したのはこれです)

◆この範囲で個別に様々な質問があり一つ一つ丁寧に答えてくださいました。面白かったものだけ記載します。
・子会社との取引を後で相殺するのですからそれだけ勘定科目を分けては?
→決算時点まで、どの会社が連結対象かが決まらない問題があります。合理化することはまだ可能だとは思いますが、それ以前に「誰がどんな形で記録/報告に責任を持つのか」を考えることが重要です。

・海外子会社などで決算時期が違うときはどうするのですか?
→「期ずれ」と呼びます。本社決算に合わせて仮締めするところ、3か月違うならシフトさせて合算するところなどいくつかのパターンがあります。国際的には親子会社で決算月を合わせることが推奨されています。中国のように12月決算にすることが法律で決まっている国もあり問題があります。

・子会社の商品を500-300=200円とするという事でしたが、300円はどこから?
→子会社側の棚卸学500円はわかりますが、それが200円だという事は親にまでさかのぼらないとわかりません。実際には子会社側に仕入先別の在庫金額を出させ親会社が売った商品については粗利率を掛けて求めます。つまり200円という答えが先にあり、差し引きして300円を求めています。(粗利率は商品群ごとに細かく設定することもあります)
※「300円はどこへ行った問題」


◆連結会計が必要な理由

「企業実態の読み替え」「少数株主持ち分の認識」というたった2つの原則が有機的にからみあって複雑になっています。海外子会社などでは為替や移動タイミングなど考える要素は多いです。



(3).会計報告と会計基準


1) 会計基準というのは財務報告の基準

もし会計士さんが「会計基準上、業務はこうです」と断言された時には気を付けた方が良いです。会計基準は経理業務の基準ではありません。仕訳方法すら決まっていませんし複式簿記すら決まっていないはずです。
最終的に投資家をまどわさないかという基準から
 会社が判断して、会計士が監査する
というルールになっています。会社が判断した会計基準を担保するためにどういう業務処理や会計記録も持つことが良いのかは業務/エンジニアリングの課題です。

2) 会計帳簿 ≠ 会計報告

例えば、帳簿上の企業実体と会計報告上の企業実体が一致していない例のひとつです。本支店でも事業部別会計(管理会計)でも様々な理由で分離しています。昔SAPの導入コンサルもやっていたので、たまに「SAPのGLを入れたのですが管理会計が出来ません」と言われることがあります。当たり前ですね。この事をわかっておられないのです。
この傾向は、現代ではますます強くなってきています。

3) 会計報告と会計基準



日本では法人税申告と法人決算報告という基本の2つが日本基準に決められてしまっていますのでIFRSなど国際基準を導入することが難しいです。その方法は3つ考えらえます。
一つは、全世界にある子会社側全部でIFRS対応の決算させてから連結する方法。これは子会社側の手間が相当かかりますからよほどガバナンスが効いた会社でないと無理でしょう。その2は子会社は国独自の決算をさせて、親会社側で連結するときにIFRS対応する方法です。恐らくこれが多いですが正確性に欠けます。折衷案は子会社側で各国基準の決算後にIFRSへの修正をさせてから報告させることです。

(4).連結会計システムの設計

財務会計/管理会計を考えるときにも連結会計が関係してきます。連結しない限りビジネスの実態を示せないような企業では毎月の管理会計帳表でも連結結果を表示していることがあります。
その時「財管一致」をどこまでやるのかという事が問題になってきます。


<所感>

いつもより多少レベルが高かったかも知れませんが、大変面白かったと思います。連結会計についてはタッチする人が限られていますので経験した事のある方はほとんどいないでしょう。もっと細かくテクニカルなものかと想像していましたが、たった2つの理由から出てきたものだとは知りませんでした。こんな事は本を読んでも書いていませんので大変貴重な会だったと思います。

単体の簿記については同じ杉本さんが3年前にこの勉強宴会で行ってくれました。「SEのための帳簿知識入門」
をご覧ください。希望があれば再度企画しても良いと思います。

以上

企業情報システムの再開発手法<第35回IT勉強宴会in大阪>

$
0
0
20141029(水) 18:30から開催しました。申し込み案内はこちら

 今回は有名人シリーズ(?)としてITイノベーションの中山さんにお越し頂きました。中山さんは企業システム内部のデータモデラーとして活躍されていました。テーマは「40歳前の若い人たちでもローリスクで基幹システムを新しく開発出来る方法」です。JAC リクルートメントの井上さんのお話も含めて大変面白い内容でした。恐らく40歳前後の技術者の方には人生設計においても大変役に立つ内容だったと思います。

 全部で30名弱にお越し頂きました。本当にありがとうございます。毎回書いてますが、出来る限り現場に参加して下さい。ブログでお伝えしていますが、100分の1も伝わっていない自信があります。開催案内はメーリングリストに必ず流します。http://www.onas.asia/home/benkyoenkai

 2次会は、前回が席替えしにくいほど狭かったので、今回は同じビルのB2でやってみました。でもやはり狭かったので次回また探します(←調査不足すみません)
3次会は8名ほどで新地に繰り出しました。いつものラウンジが「同時多発テロ状態」でカウンターの中にまでお客さんが立つほどの超満員でしたので、あまり長居出来ず失礼しました。0時半後にお開きになりました。

 今回は水曜日でしたのでこの程度が命に別条なくて良いかと思いました。

<今回の勉強宴会資料>
1.IT技術者のキャリア形成術
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyo-Enkai_2014-10-29_Inoue.pdf

2.企業情報システムの再開発手法
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyo-Enkai_2014-10-29_Nakayama2.pdf
 ※リンク修正しました:20141104

<IT技術者のキャリア形成術>

(株)JACリクルートメント 井上登紀子さん

(1).会社自己紹介

日本人がロンドンで創業した会社です。ロンドンの駐在員など日系人の紹介会社です。つぎに金融が盛んになったシンガポールに支社ができ、日本は3番目に設立されました。今では日本が一番大きくなっています。人材紹介会社としては、リクルートさん、インテリジェンスさんに次いで売上規模は3位です。ただ、当社は転職支援しか行っていません。

 ファーム型コンサルタントと呼びますが、いわゆるヘッドハント型のコンサルタントが400人居るという規模は世界でも例がないほど大きいです。年間で12,000人ほどの人生をお世話しています。

(2).人材募集企業と転職希望者の視点の違い

私たちは1人のコンサルタントが、募集企業と転職者の両方から話を聞きますので、市場の動向や人材の流れが良く分かります。就職相談会は良くやるのですが、今日はそこでは絶対にお話し出来ない話をします。まだ転職を希望されていない方に聞いて欲しい内容です。今からのお話はサラリーマン限定です。起業された方には当たりません。

 募集企業には、なぜ人材が欲しいのか・どういうスキルを求めているのか・何の仕事をしてもらうのかなどを聞きます。転職希望者には、何が出来るのか・何をやりたいのか・なぜ転職したいのかなどを聞きます。実はこれらの希望をマッチさせるのは大変難しいのです。

 (転職者視点)       (企業視点)
1) 夢や希望を追求したい→それって儲かるの?あなたの夢につきあう暇はない
2) 資格を生かした仕事 →まずは実務経験でしょう。
 (資格は確かに特急券ですが、乗車券がなければ乗れないのです。残念)
3) 嫌な状況を変えたい →うちも同じかもしれない。怖くて手が出せない
4) 新たなチャレンジ  →その歳でチャレンジされても何年役立てるの?

 ところが、これらもタイミングさえ合えば転職出来ます。
1) 夢や希望を追求したい→ちょうど当社としてもやってみたかった内容です
2) 資格を生かした仕事 →人材を育成しようとしていました

(3).転職についてのあれこれ

1929年の世界恐慌で、ポジションとスキルのアンマッチが問題になったと言われています。そのために個人でキャリアを積むという発想が生まれました。日本では、年齢の10の位+1の転職数では多いと言われています。例えば30代なら4回では多いです。

 転職市場で有利になるためには、「専門性」が重要です。若ければまだ意欲を見てくれますが、30代・40代になるとどういう専門分野でどういう成果を残したかを問われます。専門性と言ってもニッチな話ではなく、「私は何屋です」と言えるかどうかです。

 青色線はよくある転職先です。赤色破線は失敗パターンです(資料P.11)。


 ・SIer PMからCIOはCIOという職の募集が来る事がほとんどありません。
 ・PM→社内SEは給料が60%になることが多いです。

(4).キャリア形成術

100社不採用であっても、100社「自分に合わない会社がわかった」とプラスにみるべきです。転職には1社あれば良いのです。ただ、ネットなどの情報を見るよりもキャリアのプロに相談する事で自分の価値を客観的にみて欲しいと思います。

 転職するたびに年収が下がる事が一般的です。転職したい切迫した事情があるとゆっくり探す事が出来ず妥協してしまうことになりもったいないです。そういう例を多く見てきました。

<企業情報システムの再開発手法>

(株)アイ・ティ・イノベーション 中山嘉之さん

(1).自己紹介など

横浜に住んでいますが、生まれは大阪です(半年だけですが)。タイトルを再構築でなく再開発としたのには理由があります。大阪でも梅田など大きく変わろうとしていると聞いています。東京なら渋谷が再開発されています。情報システムは1970年代に多く導入されて約40年経ちます。梅田や渋谷と同じく再開発に入る時期です

 私は協和発酵という会社に入り最初2年は四日市コンビナートで経理をやっていました。会社の伝統として仕事を覚えるためにまず経理に配属させたようです。そこでゴム印で仕訳を覚えました。貸し借りを身体で覚えました。これが後々重要でした。あの頃はまともなネットワークもありませんから間接部門が現場に常駐する事が当たり前でした。

 あるプロジェクトに呼ばれて東京に戻りました。多数のコンサルタントが入り開発手法もしっかりしたものを使おうとしていたのですが上手くいかず1人を残して全員が契約打ち切りになりました。その残った1人がDOA理論を考えた椿正明さんでした。そのころ既にTH法はありましたが、Plan-DB手法はまだ出来ていませんでした。椿さんと一緒にデータ構造を整備する日々を送りました。

 2013年に他の企業の情報システムのお手伝いをするために転職しました。数えると30年間で約13個のシステムをやっていました。

(2).システムの炎上と課題

最近、情報システムは炎上することがあります。炎上するためには燃料が必要です。炎上の燃料はお金です。出来そうにないシステムにどれだけお金をかけても炎上が大きくなるだけで本当に必要なものは出来ません。

 企業内の情報システムの流れを私は次のように見ています。1980年代はコストダウンが命題でした。当社でもこのころ経理部に150人いましたが、2010年では25名です。1990年台はWindowsなどのスピードアップでした。ネットワークが整備されたので現場に居る必要はなくなりました。2000年代はエンロン事件などが発生したためガバナンスが重要になりERPで縛る事が流行りました。2010年代は今ですが、ビジネスのROIに貢献する事が求められています。

 2010年型の新システムに再開発が必要ですが、課題が数多くあります。

・ERPが足かせ。メンテナンスが自力では無理
 (三井金属は社内でメンテし外販までやっているが例外です)
・数億円とか何十億とか途方もない費用が燃料となって炎上している。
 (小国の国家予算に匹敵する金額。平和利用に使って欲しい)
・18,000人月とかの規模になると、コミュニケーションロスがひどい
 (ピラミッドをかくと2/3はマネージメントになる)
・RFPにHOW(どう作るか)を書かずWHAT(何が欲しいか)を書く誤った風潮
 (「当社に最適な提案」なんて自分たちに分からないのに出てくるわけない)
・ITプロジェクトの「トリアージ」が必要という声すら聞こえる
 (もう既にプロジェクトマネージャの問題ではなくなっている

(3).ITアーキテクチャ

アーキテクチャもストラクチャもどちらも「構造」と訳します。ではどう違うのかというと、アーキテクチャは「意図した構造」です。システムをバラバラに作っていると、たった3つのDB×6システムとしても大変なスパゲッティ状態になります



<ITアーキテクチャ設計>
仕事はデータで行います。そこが整理出来てないとダメです。

1)EA(Enterprise Architecture)もビジネスありきです。どういうコストで何をしたいかの整理が重要です。
2)若い時はITと経営は関係ないものと感じていました。ところが徐々に時代やビジネスの方向が重要だと気付いてきました。例えば近々M&Aする予定の部署のシステムを構築するのを避けたいなら経営の動向を知ることが必要です
3)あるべき姿をMODEL(=Blue-Print)として提示します。
 ※建築と違い「形」がないのでモデルで描画します
 ※コンサルはここで逃げてしまう事が多いです
4)現状とどうつなげるのかのプロセスを明示する→1)に戻る
 ※金だけでは行けない。出来る限り短期で成果を出す

 アーキテクトには、経営学の基礎(財務会計、SCM、マーケティング、統計学、HRなどのセオリー)が一通り理解出来ている事を求められます。最近、エンタープライズアジャイルという言葉が流行っています。アジャイルは小さな部分に採用するのは良いのですが、これらの基礎がなく適用することは無理です。内海アジャイルならリスクは少ないですが、外海に出るなら海図が必要です。旧システムから新システムに引き継ぐものはデータです。変わりやすいプロセスではなくデータを軸に海図を書きます。

 人体システムというのは大変良く出来たアーキテクチャです。臓器のバックアップもあります。2つある臓器もあれば、無くなった時に別の臓器が代替機能を持つものもあります。

(4).基幹系システムの再開発のポイント

 最近、データを有効活用をしたいというニーズが大きくなっています。そのため鎖国状態のERPだけではだめという風潮になっています。またERPの密結合では部分的な移行が出来ないため高リスクな再開発になってしまいます。

 企業システムで一番重要なのはデータの流れを止めない事です。血液の流れを止めずに心臓を手術するのに人工心臓を用います。企業システムでもデータの流れを止めないためのバイパス・システムが必須です。

 EAの中のAA(Apprication Architecture)やTA(Technical Architecture)は時代に従って滅茶苦茶変わりますがDA(Data Architecture)は変わりません。

(5).目指すアーキテクチャ

1) MDH(Master Data-Hub)
 各システムで使っている共通マスタを一元管理します。そのまま使うのではなく各システムとMDHの間のデータ変換は問題ありません。新規開発は絶対にMDHからマスタを連携させます。



2) TDH(Transaction Data-Hub)
 トランザクションは難しいです。使われ方を良くみると、トランザクションはどれも似ている事に気付くはずです。5W1Hを中心に、スキーマ定義を汎化・統一すればテーブルを一つにすることも可能です。私は前職のとき人事トランザクションまで統一しようとしましたが、それは諦めました。

3) TDHを介して他システムと疎結合連携しながら順次再構築&リリースする
 緩やかなシステム近代化手法です。テスト範囲はTDHをシステム境界として独立させると、本番システムとの新旧データ比較が出来ます。新旧が完全に一致するまでは旧システムを正として並行RUNします。テスト完了後旧→新に切り替えて旧を消します。最悪旧システムを残しておいてもかまいません。

 企業システムは永久に移行が続いているという姿が正解なのかも知れません。


<所感>
どちらも大変面白かったです。本当にありがとうございました。井上さんの話からは目の前の仕事を頑張るだけでなく一歩引いて自らのキャリアを客観的にみる大切さを学びました(私は年齢的に遅すぎますが・・)。中山さんからは独自のData-Hub理論の根っこを教わりました。椿正明さんから10年ほど前にもう少し抽象化したData-Hubの話を伺った事があるのでそれを補足する意味でもわかりやすかったです。中山さんの手法にご興味があればご自身のブログをご覧ください。

そしてほとんど偶然ですがお二人の話が呼応しているように感じました。中山さんは基幹システムの再開発についてのアーキテクトは社内で養成すべきだと言う考え方です。社内の技術者が描く絵を外部メンバが実装するというイメージです。その社内技術者を最適に配置できるように調整しているのが井上さんです。

2次会のお酒の上の妄想ですが、再開発を考えている企業に対して、最適なスキルを持つメンバ数名をセットで就職させるというビジネスモデルがあれば幸せになる企業が多く居るかも知れないと話をしていました。再開発が完了すれば再度人材会社に登録して次の企業に売り込みます。そのユーザ企業が気に入った人は再登録しなければ良いのです。

このモデルを成り立たせるためには登録者のビジネスマンとしての再教育が大変かも知れません。ITの技術者であっても、ISO9001やCMMIすら知らない人も居るでしょうが、それらを知らなければ大企業のシステム開発は出来ません。本当に高い技術力を持っている人は上の顔を見て仕事をする事を嫌いますからコミュニケーションギャップになる可能性も高いでしょう。とは言えこれが実現すれば「ソフトを他人に作らせる日本」から脱却出来るかも知れません。

以上

ITよろず相談会<第36回IT勉強宴会in大阪 >

$
0
0
20141121(金) 19:00から開催しました。申し込み案内はこちら

楽しかったですね。約13人が会社の枠を超えて意見を交換しあいました。ただ、まとまったテーマがなかったのでブログとしてはほとんど書けませんが、後日の参考になりそうな部分だけメモしておきます。1次会が終わったのは23時を回ってました。その後4名がタクシーで新地に繰り出して議論の続きをしていました。

10年ほど前にオブジェクト指向分析が大変流行りました。オブジェクト指向はプログラムの概念なのですがそれを無理やり業務分析にまで使おうという方法論でした。それを推進している人々は実はデータモデリングも深くまで理解されている人々でした。ただ、データモデリングという素養がなくそれらの方法論に触れた若い方は災難でした。業務分析の本質が理解出来ないために小さくて見通しのきくシステムしか構築出来ない技術者が増えてしまいました。

業務分析を意識しだすのは30歳前後ですから、今40歳までの技術者でデータモデリングの重要さを理解されている方がどれだけ居るのでしょうか。若い人に知ってもらうためには、アイドル(シンボル)が必要でしょう。DAMAにも頑張ってほしいですしデータ総研にもより一層の広がりを期待したいです。・・・・なんてことを新地で会話していました(笑)

<質問その1:勉強宴会のWEBサイトについて>

過去に多くの勉強宴会がありブログも資料もあるのですが、探しにくい。どうすれば良いのでしょう?
1.拡散のしやすさを考えるとSNSをもっと使うべき
2.ONAS.ASIAのURLがださい
3.まずは龍の絵を含めて分かりやすいページにすべき
 →龍のゆるきゃらを作る? 名称は「ITドラゴン」(笑)

<質問その2:技術者不足で仕事が多くあるのは本当?>

何名かの方のお話を聞くと、確かに仕事は増えているようです。ただし大阪は単価が安すぎるようです。私は最近セールスフォース関連の仕事しかしていませんが、その分野のパートナーと比べると半額程度になっているようです。

<質問その3:セールスフォース関連のお話し>

いますごく流行っている話題について色々。マーケティングオートメーション、iBeaconやら無料のセールスフォースの有効活用、スマホにつけるICカードリーダの用途、AnalityCloudなどなど
私がデモしたソフトは無料でダウンロード可能です。iOS用はこちら

<所感>

ホワイトボードもプロジェクターもなく進行しましたので、話が収束せずごめんなさい。このお店の壁は白いのでプロジェクターと延長コードを持ち込めば昔ながらの飲みながらの勉強宴会が可能かも知れません。
同じ会社の方は1人もいなかったと思います。こういう意見交流は大変貴重です。人数もこの程度なら多すぎず良かったと思います。1名転職して東京に行かれる方がおられました。益々のご活躍を祈念いたします。

以上






年忘れLT宴会<第37回IT勉強宴会in大阪 >

$
0
0
20141212(金) 19:00から開催しました。申し込み案内はこちら

 今回は忘年会ネタとして【年忘れLT宴会】を開催しました。前回は完全に飲み会でしたが今回は比較的初期の勉強宴会の雰囲気があり一層楽しかったです。昔はもう少し突っ込みが厳しかったとは思いますが。

 LTはご存じの通りライトニングトークです。ただネタ的に重い物も多くて時間オーバーについては適当に進行しました。「これはライトニングトークではありませんね」という批判も頂きましたがまあ大目に見て下さい。3時間でプロジェクターが使えて飲み放題で4,000円は安いと思いました。料理も美味しかったです。来年の忘年会でも使うかも。また良いところがあれば教えて下さい。

 その後3名がおねぇちゃんのお店に消えて8名がいつものラウンジ。その後3名も合流して朝3時ごろまで飲んでました。最後ラーメンを食べて帰りました。

 今回は8名の方にお願いしました。下山さんと杉本さんの資料2つだけを公開します。他の方の発表は会社的な問題が出る可能性がありますのでテーマと私の印象だけを報告します。

<今回の勉強宴会資料>
02.SALESFORCEのデータモデルをXEADで解析する
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-12-12_02_shimoyama.pdf

06.適用期間付きデータはなぜ難しいか
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-12-12_06__Sugimoto.pdf

07.URLルーティング
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2014-12-12_07__Kubo.pdf

<01:クラウドの未来予想図>(株)セールスフォース・ドットコム 佐野初夫

クラウドの説明は4年前の12月にこの勉強宴会でお話していました。その時の解説通りに現状が進んでいる事を説明し、基幹系クラウドの歴史と現状、そして今後どうなるかの予測をお話しました。
 おまけとしてAaaSからZaaSまでの中でYとZ以外はすべて網羅されている事と、その2つについては「Yome As a Service」と「Zangyo As a Service」があったことをお話しました。

<02:SALESFORCEのデータモデルをXEADで解析する【資料あり】> エルゴ 下山吉洋さん

あるお客様からセールスフォースのデータを抜き出したいという依頼があり、その作業手順をまとめてくれました。セールスフォースには全データをエキスポートする機能が標準でありますので、それでエキスポートしたCSVファイルをPostgreSQLへ一旦インポートしXEAD EditorでそのPostgreSQLにつなぎスキーマ定義を解析してXEAD Modelerに取り込むという手順。DDL文の生成rubyスクリプトなどをGithubページで公開されています。

<03:登紀子の予測>(株)JACリクルートメント 井上登紀子さん

関西の人材募集の状況から見て今年(2014年)がどういう年だったのかと、その背景から考えて2015年はどういう年になるかを大胆に予測してくれました。2017年からさらに状況がかわるという点は参加者との間で多少やりとりがありましたが全員納得されていたようです。

<04:Salesforce名寄せプロジェクト> (株)フィナンシャル・インスティチュート 山本愛緒さん

セールスフォースにはお客様のメールアドレスを格納するテーブルとして「リード(見込客)」と「取引先責任者(顧客)」があります。会社でバラバラに登録していると両方にはいってしまっているお客様が多数あり、それを名寄せした苦労話をしてくれました。

<05:X-Projects with CCPM>(株)アスタリスク 野村昌由

割り込みが多発するプロジェクトで「高速にリスケが出来る」ツールが必要になりX-Projectが発足しました。ExcelとRedmineで作っていました。その後「ERPM(Everyday Rescheduling Project Management)」というブログを発見。CCPM(Criticaal Chain Project Management)という流行の管理手法と全く同じだと書いてあった。
 ということでそれを実装してみたというお話。詳細はブログで。ダウンロードも可能
http://www.asteriskweb.jp/blog/archives/7267
 これがCCPMとは(少なくとも佐野は)認めないと突っ込んでおきました(笑)

<06:適用期間付きデータはなぜ難しいか【資料あり】> (株)フュージョンズ 杉本啓さん

これはデータモデルとして大変面白いというか有意義な話でしたが、5分でやるのはもったいなさすぎました。1時間以上欲しい内容でした。
 適用期間を持ったデータをJOINすると行が増える事があります。
例えば得意先と営業部署のマスタがあり、両方に適用期間(From/To)があるとJOINすると行が増えてしまいます。

それをFrom/Toでなく適用期間に含まれる最小期間ごとの省略形だと考えると辻褄があいます。


この難しさの原因は、「2月から3月において担当営業部署はYである」という命題表現には「2月から2月において担当営業部署はYである」という命題が隠れているためです。つまり存在しないタプルが存在するかのように強いられる事が原因です。

※資料に述語表現という言葉が出てきますが、「値を受け取ってから真か偽かが決まるもの」を述語といいます。上の例で2月の場合と3月の場合で真偽が異なるため命題表現でなく述語表現になっていることがわかります。

<07:URLルーティング【資料あり】> PHPメンターズ 久保敦啓さん(MakeGood作成者)

昔のURLはたとえば「http://hoge.com/hoge.php?id=123&text=y」というものでした。ところが最近はそういうベタなものは少なくなり「http://hoge.com/benkyoenkai」というものになっています。これを「意図を持ったURL」とよぶ事があります。それにより検索エンジンに対して有利になったり覚えやすくなったりします。
それがフレームワークの中でどう処理されているか。昔は「ページコントローラー」で処理をしていましたが、最近は「フロントコントローラー」が処理をします。Symfonyの例で説明してくれました。

<08:データモデルは 観察結果ではない>デービーコンセプト 渡辺幸三さん

若いころ設計したシステムを最近見る機会がありました。今見ても実に上手く設計していると思いますが、お客様と話をすると運用が面倒だと言われました。業務を観察し、そのままいくら上手に設計したとしても良い設計とは限りません。
「データモデルは、解釈され、妥協され、そして、創造されるもの」

<所感>

今年最後のIT勉強宴会も無事終了しました。半数ほどの方には多少無理やりお願いしましたが、面白く発表して下さってありがとうございました。
「こういう話題を聞きたい」というリクエストも受け付けますので是非希望をお聞かせ下さい。来年もよろしくお願いします。

以上

中小企業の社長は何を考えているか<第38回IT勉強宴会in大阪>

$
0
0
2014.01.09 18:30~開催しました。募集案内はこちら

JAC Recruitment大阪支社さんの会議室をお借りしました。素晴らしい環境を毎度ありがとうございます。助かっています。今回は現役コンサルタントさんにお願いしました。最初は「ITが全くわからないので」と辞退されたのですが半ば無理にお願いしてよかったです。素晴らしい内容でした!

本編が面白いと飲み会も盛り上がります。2次会は15名で11時過ぎまで。3次会は5名で3時まで、4次会は4名+ラウンジの女性2名でした。帰ったのは5時ごろでした(苦笑)

<今回の勉強会資料>
コンサルタントとは
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2015-01-09_sano.pdf

中小企業の社長は何を考えているか (New:2015.01.17)
http://www.onas.asia/home/benkyoenkai/doc/IT-Benkyoenkai_2015-01-09_nishikawa.pdf

<コンサルタントとは>

(株)セールスフォース・ドットコム 佐野初夫

講師の西川さん到着までの時間つなぎにコンサルティングって何をする仕事なのかをお話しします。会計士や弁護士が顧問を行うところからコンサルティングが発生しました。

テイラーの「科学的管理法」がコンサルティングの発祥と言われていますが、今のコンサルティングのおおもとはポーターでしょう。ポーターが唱えたファイブフォース3つの基本戦略を武器に「戦略コンサルティング」という分野が広がりました。ただ、ポーターは自社の強みというよりは業界や他社との競争優位性ばかりを前に押し出しましたので、コンサルを受けている会社としては不満がありました。そこで出てきたのが「コア・コンピタンス」という考え方です。企業自体の能力で戦略を決めるという話でしたので大変流行りました。

その後、自社の中の部門間の壁を取り払おうというBPR(ビジネス・プロセス・リエンジニアリング)が出ました。企業というのは結局は「人」で動かしています。複数の部門のキーマンを一堂に集めて課題を出すというコンサルティングは大成功しました。というのは解決策が重要なのではなく部門間で会話することが重要だったのです。ただ、BPRを推し進めると非効率な部門も見えてきます。GEのジャックウエルチが10万人解雇したという話も伝わってきてリストラに結びつけた負のイメージもありました。このBPRを複数の会社間に推し進めたのがSCM(サプライ・チェーン・マネージメント)です。

そして今はBSC(バランス・スコア・カード)が全盛です。企業のビジョンや目標を明確にして、それを実現するためのKPI(キー・パフォーマンス・インディケーター)を数字で表そうという仕掛けです。KPIは各社員にまで落とすと目標管理制度などにつながります。

ところが数字だけで評価してしまうと裏技を使って数字だけを良くするという社員の動きが出てきてしまい結果的に会社の業績が悪くなるという事があります。それらを赤裸々に書いたのが「申し訳ない、御社をつぶしたのは私です。」という本です。興味があればお読みください。

<中小企業の社長は何を考えているか>

(株)フィナンシャル・インスティチュート 西川佳徳さん

1.当社の紹介

事業再生コンサルティングとか会社再生コンサルティングという名称を聞くと、何だか倒産間近の会社を立て直す事が仕事のように感じると思います。セミナーなどを開いても「参加すると会社が危ないとみられるのではないか」と心配されることもあります。

もちろんそういうご相談にも乗りますが、それだけでなくどんな中小企業でも同じように持たれている悩み-資金繰り-に関してお役に立つことが仕事です。「成長は再生の連続」だとお話ししています。資金に余裕のある大手は別として中小企業は一つの主要製品で勝負していることが多いです。製品ライフサイクルでみて衰退期に入る前に次の製品を開発します。それを繰り返す事が理想です。ところが衰退期に入って売り上げが下がっている状態で新製品開発への投資が必要になります。手持ち資金がショートすることが多く、銀行などで借金することになります。

当社の社長、川北英貴は昔銀行員として中小企業向け融資業務を行っていました。その時「もっと上手く説明すれば貸しやすいのに残念だ」と感じ中小企業向けにアドバイスを行いました。その後独立して中小企業のお手伝いをする会社を立ち上げたのが当社です。

2.中小企業の社長は何を考えているか?

会社の数を見ると、中小企業庁の資料では日本の企業の99.7%である420万社が中小企業です。その中の87%が小規模企業です。(小規模企業とは製造業だと従業員20名以下、商業・サービス業だと5名以下の会社)
そして中小企業のうち約80%が赤字だと言われています。つまりいずれ資金不足になるという心配をしながら会社運営をされているという事です。

私の感覚ですが、中小企業の社長の頭の中の50%は「資金繰り」30%が「売上向上」、そして「社内調整」と「その他」が10%です。資金繰りについて言えば、従業員に給与を支払えるのか、売掛を回収出来るのか、借金を返済できるのかなどをいつも考えています。売上向上については、自社の売り物が本当は何かのかを正確に把握されている社長は少ないのです。

3.資金繰りと損益

コンサルティングをしている中で次の図が一番重要だと考えています。ひとつは資金繰りの話で、もうひとつは損益の話です。この例でいうと左側は利益が90円出ていますが右側は損失が80円です。この図をみて難しいと思われる方はいないと思います。左は100円で仕入れて200円で売る例、右は200円で売ることを約束した後に仕入れようとしたところ仕入金額が250円に上がってしまっていた例です。両方とも手持ち資金がなく銀行から借り入れてます。


信じられないかも知れませんが多くの社長がどこかで混同して判断されています。ずっと資金繰りの事を考えておられますので目の前の支払いのために原価割れした金額で工事を受けてしまうというのは混同した例です。

4.システム投資の話

中小企業で余裕資金を持っているところは少ないです。そのためソフトウエア投資は銀行借入などで資金調達することになります。社長としては資金繰りのことを考えていますから、「そのシステムで会社がどう良くなるの?」だけが関心事です。ところが話を聞いても言葉が良くわからない、つまり共感できないという事態になります。



昔ある会社にホームページ制作会社がきました。社長はわからないのでコンピュータに強い女性に対応させて提案書まで出来ました。そのプレゼンがあるので同席して欲しいと社長から依頼がありました。プレゼンは用語が難しくてわからなかったのですがどうやらこのホームページを作れば新規顧客が増えると言っている事はわかりました。終わってから社長に「どう思う?」と言われましたのでこう答えました。

1).新規顧客の事しか言っていない
売上向上には新規顧客だけでなく過去に買ってもらった顧客、既存顧客に対するアプローチがあります。
2).見込み客発掘の事しか言っていない
売上に結びつくには、「見込み客発掘」→「追い客」→「成約」→「リピーター」というプロセスがあるはずですが、これは見込み客発掘だけの話です。見込み客がどれだけ増えてもその後のプロセスがないと売上に結びつきません。

結局その社長は提案を縮小して1/10程度の最低限のホームページを立てたそうです。

「誰もいない山の中で一番大きな木に雷が落ちました。されどういう音がするでしょう?」

様々な答えがあると思いますが、私の答えは「音はしない」です。空気が振動するでしょうが、人がいなければ聞いている人もいません。これと同じくどんな素晴らしい提案であったとしても共感してもらえなければ意味はありません。

コンピュータの事は門外漢ですが、次の3点が気になっています
(1)中小企業を理解していない
 ・中小企業の競争優位性は例外事項への対応力です。
   →安易に集中と選択させるようなシステムは競争優位をなくします
 ・賢い社長はお金を残します(コスト負担を嫌います)
 ・経営者の覚悟を知らない(従業員と社長の関係は平行線)
(2)業務を理解していない
 ・非効率な業務をそのままシステム化する無駄(御用聞きのシステム会社)
 ・学問通りにはいかない(製品原価に社員賃金を含まず販管費にする意味)
  →含んでしまうと異なるラインの手伝いに行くと原価高になりぎくしゃくする
 ・現場を知らない提案は百害あって一利なし(数値管理に惑わされている)
(3)運用するのは人であることを忘れている
 ・抵抗勢力を説得せず導入しても使われない
 ・システム化しても人的エラーは発生する
 ・強い会社はオフラインの作業に重きを置いている(現場力の強化)

5.こんなシステム技術者を求む

(1)経営者と共通言語を持っている
 ・数字で語れるか。%でなく絶対額。提案は細かくなりがち
(2)会社の仕事全般を理解している(理解に努める)
 ・食品業をやるならハサップ(HACCP
http://ja.wikipedia.org/wiki/HACCP
  )を知っているのが常識
(3)システムの費用対効果を明確に提示出来る
(4)進捗を適宜報告する
(5)導入後に社員教育をしてくれる

6.質疑応答というか参加者の意見表明

・業務を理解していないのは客。提示してくれないと作れない
 ・費用対効果(ROI)を提示しやすいものとしにくいものがある
  システム費用は高いので真面目に計算すると回収出来ない
 ・とはいえ、業務上必要なシステムについて社長はどうしたいのか?
   →恐らくEXCLEで出来ると思っている
 ・進捗会議に社長はじめキーマンが出なくなる事が多い
 ・教育するためにはその費用を払ってもらう必要がある

<所感>

すごく面白くためになったと思います。参加者はラッキーでした。
社員教育や運用の話も出ましたが、システムは導入費用を払ったら終わりだという事になりません。システムの要件はユーザ企業自体が決めるものだという話など我々技術者の常識は中小企業の社長さんの非常識なのかも知れないと感じました。社長さんにもわかるようなシステム導入の概説書が必要なのかも知れません。

以上

競演モデリング発表会<第39回IT勉強宴会in大阪>

$
0
0
20150220(金) 18:30から開催しました。申し込み案内はこちら

今回は面白いネタでした。40人を超える方にご参加いただきました。ありがとうございました。また毎回無料で会議室をお貸し頂いているJAC Recruitment様には毎回感謝しております。本当にありがとうございます。

1人30分というのは丁度良い感じですので、どなたか続いてされませんか?

今回は飛び入りで住友電工情報システムの池田さんが乱入(笑)されて楽々フレームワークの概要を説明してくれました。T字形ERのモデルをTER-MINEの楽々連携版で入力するとそのまま楽々に渡す事が出来ます。テーブル関連などから自動的に画面を生成する方法論はXEAD Driverそのものです。DOAという設計手法を作られた椿正明さんは「実装独立」を強く主張されていましたが、DOAを使っている人には実装と隣り合わせにある事は自明だったのです。

2次会は前回も利用した魚民でした。広くて座席移動がしやすくて、しかも安いので相当気に入っています。北の方にお住まいの数名が新大阪で飲むと言って帰られました。その後4名がいつものラウンジ。今回は超有名な唐揚げやお寿司などを持ちこんでちょっと宴会チックになってました。帰ったのは4時ごろでした。

<今回の勉強宴会資料>
1.花束問題のしおり
http://www.benkyoenkai.org/2015/02/blog-post.html

2.鳥谷部さんハンドノート(佐野抜粋版)
https://drive.google.com/open?id=0BykMR9FfFyLOcC1aQ0FpZjcxNlE&authuser=0

3.鳥谷部さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLORTdEc0QtVFNBY0U&authuser=0

4.渡辺さんのデータモデル
https://drive.google.com/open?id=0BykMR9FfFyLOY21zTXVjYTE4dDA&authuser=0

(参考)SlideShareに公開された鳥谷部さんのハンドノート全文
http://www.slideshare.net/satoshitoriyabe9/ss-43628500

<01:方法論としてのT字形ERの説明>

システムズ・デザイン(株)鳥谷部 聡さん

 珍しい名字ですが、父親が青森出身です。青森に行くと方言が強くて言葉がわかりません。それどころか青森の中でも北と南で言葉が通じない事もあるそうです。

 1993年に外資系アパレルに居ました。当時のボスが様々な本を読んだ後、「これが一番わかりやすい」からとT字形ER手法の本を持ってきました。自分で本を買って勉強した後、佐藤さんに来て頂いて手伝ってもらい、3年半かけて一緒に基幹システムを再構築しました。
 様々な方法論がありますが、もし議論が出来ないのなら宗教と同じです。議論のベースにしてもらうために、ハンドノートにまとめました。今から紹介するのはT字形ER手法をきっかけとはしていますが、私の考えです。必ずしも佐藤正美さんの方法と同じではありませんのでその点誤認識下さい。また、今日はあえてT字形ER手法の範囲でお話します。現在はTM1.3と呼ばれています。

※佐野註:セクション1~5はハンドノート抜粋版のセクションに対応しています

セクション1:

T字形ER手法でのモデルは単語-イディオムを重視します。単語を厳格に定義することからスタートします。(青森県のように言葉が通じない時は辞書作りからスタート)

セクション2:

ヘッダー/明細の関係はスーパーセットとして整理します。業務階層とアプリケーション機能の関係もSuperset/Subsetの関係として捉える事が出来るでしょう。当社は業務を見える化する時には必ず業務階層図を描きます。その手法としてBPEC(Business Process Engineering Cycle)という手法を推進しています。ご興味があればWEBサイトをご覧ください。

リソースとリソースの関係は「対照表(QUASI ENTITY)」を作ります。イベントとイベントの関係で元がNの時は「対応表(MAPPING LIST)」をつくります。エンティティの箱の右上にどういう性質のエンティティかを記号で表します。

エンティティの箱の左側には個体指定子(昔はアイデンティファイヤーと呼んでいました)を書きます。自分以外のエンティティの個体指定子を左側に(R)として記述することでリレーションシップを表します。(R)のRはリユースという意味です。
右側には性質(属性)を羅列します。この性質にも日付やテキストなど様々な種類があります。(D)と書くと、他のエンティティから導出した事を表します。私は初期値として持ってきて上書きするかどうかの区別を大文字/小文字で書き分けています。

セクション3:

佐藤さんのコンサルを受けていた時に「正規化とはリンゴはリンゴ、ミカンはミカンで集める事」と何度も言われました。正規化はご存じだと思いますが、T字形ERで重要なのは、バイナリ方式(2項関係)を基本としていることです。2個からしか対照表を作れません。3項以上の関係を許す事をNアレイ(n-項関係)と呼びます。

正直バイナリ方式で分析すると箱の数が増えるのですが、間違いなく丁寧な分析が出来る事は事実です。

セクション4:

エンティティの切り出しにはコード体系に注目します。コードの中に含まれている意味も分析しながらモデル化します。「取引先コード」が意味ありだという事はその会社がどういうビジネスをやっているかがコード体系に隠されている可能性が高いです。

<02:モデリング発表(T字形ER手法)>

システムズ・デザイン(株)鳥谷部 聡さん

セクション5:

実務では頭の中だけでやっていることを勉強会ですので紙に起こしてみました。

(1) 「花屋」と聞いて想像出来る単語(イディオム)です。業務のイメージを浮かべます
(2) 練習問題の中から気になる文章を青字にしました
(3) 先ほど説明したBPECの業務階層図です。今回作るかは別にしてこの程度は意識しながらモデリングすべきでしょう。
(4) 小売業というビジネスモデルの「鉄板」は、仕入-加工-販売-回収です。
それぞれの業務ごとに一般的な考慮点はこの程度あります。
(5) 先ほど(2)で抜き出した単語についてそれぞれどう考えるか
(6) モデリングを行う手順を示します。まずコード体系を見つけるところから開始です。
(7) 美しいダイヤグラムを描くコツも書きました。リソースを上下に配置し、イベントは左から右に時系列に配置します。

モデルは時間がないので一部だけ説明します。クレジットカードは国際ブランドごとに扱いを変える事が多いので対照表を作っています。得意先アカウントパスワードだけを分離しているのはセキュリティ上の要求レベルが違う事が予測されるためです。
副資材は一般的には在庫管理が不要ですので、原材料としての花と分けて管理しています。在庫は、仕入予定発注と得意先受注からリアルタイムに計算して表示します。

<03:モデリング発表(三要素分析法)>

デービーコンセプト 渡辺幸三さん

モデリングセッションをするとき、お客さんからよく「どういう準備が必要ですか?」と聞かれます。そんな時は「実際に業務をされている方が来てもらえるなら何の準備も必要ありません」と答えます。

これは現状システムをおろそかにしているということではありません。まずはおおよそどういうシステムが欲しいのかについて納得感のある叩き台を作る。その後に、抜けている仕様要素がないかチェックするために、現行システムと丁寧に突き合わせます。これを逆にして現行システムの分析から始めると、「最新建材で出来た竪穴式住居」が生み出されます。

(1) カジュアルなまとまりとしての業務フローを描きます。
 この練習問題では受注から出荷の流れと、発注から入荷の流れが必要です。これもお喋りしながらです。今回は受注から出荷の流れだけを描きます。
 本当は帳簿の絵を書けばわかりやすいのですが、難しいのでドラムの絵でお茶を濁します(笑)
 業務の処理は誰かが上から俯瞰して指示しているわけではありません。何かをトリガーにして作業を開始しているはずですので、それを聞いて書きこみます。加工指示なら例えば「11時になった」時に行う事にします。

(2) データフローを見ながらデータモデルを描きます。
 3要素分析法だとテーブルの下に実際の値を書いていけますのでわかりやすいです
 マスターから描き出します。「商品ってどういう項目あるのですかね?」とか質問しながら次々に描きます。特に管理したい項目があれば落とさないですが、全部描く必要はありません。スピード感が重要です。

(3) 描いていくと、面白い事に気付きます。単品ロットエンティティを作れば、廃棄予定を受払予定として更新出来てしまいます。

(4) 受注明細がありますので、もし花が足らないという事態が起これば、必須でない花を勝手に変更することが出来ます。カーネーションセットでカーネーションがなければダメですが、かすみ草が足らないので他の花に変更するという事が受注明細を更新することで出来てしまいます。

<所感>

T字形ER手法といえば現状分析のボトムアップからスタートするというイメージでした。でも、本来のコンサルタントとしてどういうアプローチでトップダウン設計をされているのかが良く理解出来ました。普通なら紙に書かない頭の中をよくここまで書いてくれたと思います。
特に「小売業の鉄板」というのは、この程度の事が頭になくてお客様の前に立てないという最低限の話だと私も思います。とは言え経験が少ないと難しいでしょう。
鳥谷部さんのモデルをゆっくり読むと、モデラーがどういう視点でビジネスを捉えているのかが良くわかります。普通なら一つのエンティティに入れる属性でもバイナリ方式で分解する事で「ビジネス分析」を実現している事も良くわかりました。

一方の渡辺さんの方法はビジネスを分析するのではなく、やりたい事を素早くするためのモデルになっていると思います。それにしてもこの程度の複雑な業務をホワイトボードだけでたった30分丁度でモデリングされるとは素晴らしいの一語でした。渡辺さん以外でこれが出来る人には会った事がありません。

ただ、経験がある方が見ると様々な疑問が浮かんでくるはずです。例えば、受注は「商品No(花束の番号)」で行うのですが、受注明細には「単品No(花単体の番号)」が入っています。つまり受注登録する瞬間に所要量展開するというイメージです。加工指示するタイミングで所要量展開していると在庫推移監視方式が使いにくいので省エネの策でこうなっているのだろうと判断しました。2カ月先の受注を受け付けた時、出荷までに季節が変わって商品構成が変わると処理が大変になるでしょう。どなたかから質問が出ないか期待したのですがありませんでした。
また単品マスタに(最初は持っていなかった)在庫数を持った瞬間にマスタではなくなります。私には違和感がありますが、質問がなかった事を見ると皆さん納得されたのでしょうか。

是非様々なモデルをもっと見たいと思います。お二人を踏み台にして(失礼)ぜひどなたか発表して下さい。

以上

DDD,UML,DOA競演モデリング発表会2<第40回IT勉強宴会in大阪>

$
0
0
20150425(土) 14:00から開催しました。申し込み案内はこちら

今回も前回に続き花束問題でした。モデリングには一家言ある方々にお越し頂いてますので全員が面白く為になります。40人を超える方にご参加いただきました。ありがとうございました。また毎回無料で会議室をお貸し頂いているJAC Recruitment様には毎回感謝しております。本当にありがとうございます。

今回はIT勉強会スタンプラリーというものに参加してみました。「なれる!SE」というライトノベルのヒロイン(?) 室見立華ちゃんのスタンプシートとワッペンを配布しました(笑)

登壇者の関係で土曜開催になりました。土曜の方がゆったりしていますが、このBLOGを書く時間がないのが難点です。2次会は前回も利用した魚民でした。東京から来られた2名が帰られたのをきっかけに3次会に突入。途中で電話がかかってきたので私ははぐれてしまいました(笑)

<今回の勉強宴会資料>
1.ドメイン駆動設計 後藤さんの資料です
https://drive.google.com/file/d/0BykMR9FfFyLOdmNxaDdkcDJTSEU/view?usp=sharing

2.存在従属性 井田さんの資料です
https://drive.google.com/file/d/0BykMR9FfFyLOcllhQlRpTXBDTGM/view?usp=sharing

3.THデータモデル 石井さんの資料です
https://drive.google.com/file/d/0BykMR9FfFyLOdDg4RmxLa3QxVEk/view?usp=sharing

4.THデータモデル 文法解説資料です
https://drive.google.com/file/d/0BykMR9FfFyLOT2JOcUktdkdnaFE/view?usp=sharing

<動画公開します>
ドメイン駆動設計で花束問題をモデリングする動画公開(48分)
http://www.youtube.com/watch?v=vIE4c14jIAk

存在従属グラフで花束問題をモデリングする動画公開(42分)
http://www.youtube.com/watch?v=tqPrii2eExs

THデータモデリングの動画公開(80分)
https://youtu.be/uZoOuScEepY

<01:花束問題をDDD(ドメイン駆動設計)で考える>

インクス株式会社 社長 後藤 秀宣さん


 SWEBOK3.0のモデリング原則は次の3点です。
(1)本質をモデリングせよ (2)大局感を提供せよ (3)効果的な伝達を図れ
そこに私はもうひとつ加えたいと思います。それは【動くモデルであれ】です。

 システムとは何でしょうか。例えば忙しいレストランで、ホールも厨房もてんてこ舞いをしています。そこに注文レシートを挟む「回転盤」を導入すれば解決するかも知れません。それがシステムです。回転盤を「設計として」意図を持って導入するのです。それによりホールと厨房のインターフェースの役割を果たします。
 ※この事は、吉原賢治さんの本に書かれていました

 前回の渡辺幸三さんのモデルの意図を考えました。私は「受払予定」がそのインターフェースになっていると思いました。ところが、データ構造だけですので、そのロジックまでは読み取れませんでした。
--------------
 ドメイン駆動設計の「ドメイン」とは領域くらいの意味です。たまに「現場」とか「現場の部署」だとかだと勘違いされている方がおられますが違います。自分から積極的に見つけていくものです。ドメインの中にさらに小さなドメインがあるという入れ子構造になっています。

■ドメインスコーピング(ドメインの認識)
 花束問題をドメイン駆動設計でモデリングします。まずはドメインをさぐるために何かの線を引きながら領域に分けていきます。
■ドメインモデリング(ドメインの理解)
対象と考えられる「ドメイン」について調べます。検索すると「稲垣生花店」と「青山フラワーマーケット」の記事があり、在庫ロスを防ぐ事が重要だとわかりました。

■スタート
 次の手順で整理します
・問題分から単語をピックアップする
・大構造を見る(俯瞰する)
・縦に切る(サブシステムにわける)
・ざっくりとコンテキストにわけてみる

 たとえば、「販売管理」と「在庫管理」というコンテキストに分けた場合、販売管理の中で在庫を意識したくない。そういう場合は「受注可能確認」というクラスを作り、その中だけで在庫管理とインターフェースする。在庫管理側には「在庫予定問合せ」というクラスを作り販売の概念を持ち込まないようにします。「受注可能確認」というクラスを考え付くと、例えば在庫以上に受注出来るかどうか(オーバーブッキングポリシー)などもその中で処理可能になります。

 次に責務のレイヤにわけます。
「意思決定支援」「ポリシー」「確約」「業務」「潜在能力」
在庫ロスの問題を見ると「品質維持可能日数」は確約のレイヤになります。ロスを減らしたいというゴールを意思決定支援レイヤに定め、ポリシーレイヤとして例えば「受注増」や「新鮮な花を仕入れる」といった方法論を導きます。

 これらを繰り返してたたき台のモデルを作ります。そして「モデリング活動としての実装」を行う事でそのまま動きを確かめながらモデルをシェープアップします。何度かイテレーションを繰り返した後、実装したクラス群を、「言葉」で検証し、ユースケースを確認します。

<02:存在従属関係に着目した花束問題の一分析>

有限会社井田代表 井田明男さん

 学生にオブジェクト指向を教えていても上手く教えられません。考えると、とにかく主語になるべき名詞が必要な英語を話している人は常にオブジェクト脳で考えているのではないでしょうか。そのため日本語に訳すとうまく伝わりません。というのは、自然な日本語には主語がないため、「する文」(行為文)でなく「ある文」(存在文)になっているためです。
 例: 行為文「私が、会議室を、予約しました」
    存在文「会議室は予約してあります」    × 従業員-会議室-予約
※ここら辺の事情は、金谷武洋さんの「日本語文法の謎を解く」(ちくま書房)にわかりやすく書いてあります

 ところが、存在従属性に着目して日本語要求記述にあたると改善する事がわかってきました。
予約するためには、従業員と会議室の存在が必要。つまり予約は従業員と会議室に存在従属している。
    従業員 ← 予約 → 会議室   ・・・これは「存在従属グラフ」と呼びます

※この存在従属性(existance  dependency)は、Pチェンが明確に書いているのですが、その後Eヨードン、Pコード、UMLの産みの親のGブーチ、Iヤコブソンも書いていません。Jランボーだけが少し言及していました。この辺りの事情をご存じの方は是非教えて下さい。

-----------------------
 花束問題を存在従属関係からモデリングします。まずはじっくりと問題文を読みます。そして単独で存在できる概念、単独では存在できない概念の順にチェックしていきます。

 存在従属グラフを書いていく中で、「あれ?」という場所が出てくるとその理由を考えます。例えば、発注リードタイムというものが花の単品仕様に出てきますが、それって仕入先の都合じゃないか?と疑問が出たりします。その時は「提供」という概念を出して仕入先別の都合を格納します。

 これらを繰り返してモデルが完成すると、そのままリレーショナルモデルに変換出来ます。存在従属名クラスの識別子は必ず複合主キーとなります。

 今後は存在従属ツリーからユースケース記述も自動生成できる可能性があります。
※従来は、ユースケース記述から名詞、動詞を拾ってクラス図を作成していました。

<03:THデータモデル>

(株)データ総研 社長 堀越雅朗さん

(株)イントリーグ 石井健作さん

 元堀越さんの部下でした。今はRFPを専門に扱うコンサル会社に転職しましたが、データモデリングの能力は活用しています。ベンダさん側にデータモデルベースで会話できる人がいると、データでなくメタデータで会話出来ますので要件が早く間違いがありません。

 THデータモデルというのは1975年に椿さんと穂鷹さんが発表された表記法です。ま、表記法ですから使いやすい表記法を使われれば良いと思います。分析方法論としてはPLAN-DBという名称です。これは多数のメンバがボトムアップで設計する時にやりやすいものです。誰がモデリングするのか?という視点でも方法論の性格が出ているように思います。

 さて、THデータモデルの文法を資料として持ってきました。最初は業務の構造をモデルのパターンとして覚えました。エンティティにはリソース系、イベント系、それに月間集計などの情報系があります。リソース形には商品マスタなどのタイプリソースと、ひとつひとつを管理する社員マスタなどのオカレンスリソースがあります。イベントには通常イベントと、配属などリソースの属性を変えてしまう異動イベントがあります。

 配置ルールも厳格に決まっていますので慣れるとわかりやすいです。データ総研に入社したときから使っている椿正明さんの本「データ中心システムの概念データモデルも持ってきました。

------------------
 それでは実際にツールを使ってモデリングしてみます。画面を分割して、左に問題分を表示し右側にモデルを書いていきます。画面と帳票のサンプルがありますのでそのままモデリングすることが出来ます。

(株)データ総研 社長 堀越雅朗さん

 先ほど井田先生の存在従属性という話は実はトップダウンの方法論そのものだと思って聞いていました。THデータモデルは通常ボトムアップで作るのですが、実はトップダウンで作る事も出来るのです。

 イベントに異動イベントというものがあるという話をしました。例えばお客様との契約などもリソースが変わるので異動イベントだという見方も出来ますが、我々は会社の経営リソースが変わるものだけを異動イベントと呼んでいます。

<所感>

私はエバンスさんのDDD本しか読んでいませんので「ドメインエキスパートとモデラー」という対立軸を開設されるのだと誤解していました。後藤さんのDDDは真正面からドメインに向き合ってモデリングしようというものでした。twitterでどなたかが書き込まれていましたが、マルチパラダイムデザインに近い考え方だと思いました。そして実用的にはこれしかありえないだろうとも納得しました。

 井田さん存在従属性は英語が苦手な私にはありがたい方法論かも知れません。情報処理学会に論文が掲載されるそうです。ただ、Pチェンへの先祖がえりという見方も出来てしまいます。それならコッドまで先祖がえりしてTHデータモデルという選択肢もあるはずです。

 最後、堀越さんと石井さんにはわざわざお越しいただいて感謝です。比較的若い方も多くおられたようですので、本物のモデリングコンサルタントの話を聞く機会も少ないと思いますので良い経験になったのではないでしょうか。

以上

ビブリオバトル

$
0
0

20150619(金) 18:45から開催しました。申し込み案内はこちら

 場所はJACリクルートメント様の会議室を無料でお借りしました。毎度ありがとうございます。第23回に続いて2年ぶりのビブリオバトルでした。5分間ずつ本の紹介を交代で行って、最後に多数決で「チャンプ本」を決めるという段取りです。

参加者は前回9名、今回8名。皆さん本には興味がないのでしょうかね。私は楽しいのですが次回は企画を考えなおさないとだめですね。

前回と同じくあみだくじのサイトと5分間タイマーにお世話になりました。ありがとうございました。

人数が少なかったので二次会は本日開店の「THE PERFECT 黒ラベル BEER GARDEN 2015 OSAKA」に行きました。入ったところで個室風の立ち飲みの場所を借り切ってワイワイやってました。想像以上に楽しかったです。

発表頂いた皆様、参加頂いた皆様、ありがとうございました。では始まりはじまり・・・
※Amazonリンクはアフェリエイト設定していますのでご了解ください

<あきぴーさん>:Redmine実践ガイド

Redmine関連の本が今年4冊ほど出る予定になっています。その中でもこの本は利用者視点だけでなく、マネージャ視点やサーバ管理者の視点まで網羅されているという珍しい本です。そのため多少高価になっています。
 島津製作所さんや三菱電機さんなど実際にRedmineをバリバリ利用されている企業の方が運用事例を執筆され、かつ全体のレビューまで受け持って下さいました。この本は執筆者だけでなくレビュアーが錚々たる方々だというのが特徴の一つです。
 実際の企画は昨年6月でしたので丸1年かかって出版することが出来ました。私の持論では目次は2回大きく変わると考えています。この本もレビューで大きく構成が見直されて相当大変でした。



(トップバッターは6月22日(月)に発売されるRedmine本の紹介です。一部の章をご自分も執筆されたという事で宣伝のために登場されました。)

<ディービーコンセプト 渡辺幸三さん>:聖徳太子は蘇我入鹿である

蘇我入鹿というと大化の改新(正確には乙巳の変)で後の天智天皇と藤原鎌足に暗殺された悪人という事になっています。実はその1世代ほどまえに生きていたとされ天才の良い人の聖徳太子と同じ人物だったと言う事を解き明かした本です。
その理由は、日本書紀は藤原氏の大本営発表だけを書いたものであり、藤原氏に都合の悪い事が書かれた本は焚書にあったためです。この本は3つの書物から証明しているのですがそれらもわざと分かりにくく書いてあります。
私は10回は読みなおしています。涙なくして語れない話です。





(日本書紀に書かれた聖徳太子の虚構説が力を持ち、2014年から教科書からも消えつつあると新聞で読みました。この本の正しさが証明されるのかも知れません)

<(株)アスタリスク 野村昌由さん>:入門 朱子学と陽明学

朱子学も陽明学も、孔子を起源とする儒教思想の一派です。日本で大変広がっている儒教思想。それがもしかすると「ソフトを他人に作らせる日本」を生んだのかも知れません。春秋戦国時代、人々が争っている中に「美」や「秩序」をもたらそうとしたのが儒教です。欧米の個人主義に対して日本の集団主義の根本に儒教思想があるのだと思います。
ところが、12世紀ごろに西洋思想が入って来ます。それに対して理論武装する必要が出てきました。儒教は宗教的側面もありますが、勉強会サークル的な一面もあります。そこで朱熹(しゅき)が再体系化したのが朱子学です。
その後、王陽明が「孔子の教えを変えるのはおかしい」と異を唱え、理を超えた心の学問にしたのが陽明学でした。詳しくはこの本を読んで下さい。




(日米のソフトの作り方の違いを儒教に求めるのは無理やりですが、一つの見解かと思います。)

<(株)セールスフォース・ドットコム 佐野初夫>:在庫マネジメントの基本

在庫についての基本的な説明を知りたければこの本をお薦めします。例えば在庫とは何かという章では在庫が生まれる4つの理由-お客様が欲しい時に出すため(需給ギャップ)など-が書かれています。また、安全在庫の計算も計算式だけでなく何故そうなるかも丁寧に解説されています。クロスドックという言葉はご存じでしょうか?そういう基本的な概念が一通り網羅されています。
特に驚くのはSCMが日本でことごとく失敗したのは紹介の方法が間違っていたと断罪されていたことです。本来はマネージメントの手法なのに川上から川下への在庫削減のオペレーションとして紹介されたので間違ったシステムを構築されたそうです。
またJIT(Just In System)についても手厳しく、時間指定の納品を指示された仕入先は工場の近くに倉庫を立てて無駄な在庫を持つ事もあるそうです。

<(株)ランドコンピュータ 奥田高行さん>:ブルー・オーシャン戦略

4~5年前に、大阪でセールスフォースのビジネスを立ち上げる時、まずは戦略を考えようと、有名なマイケルポーターさんの競争戦略論のⅠ、Ⅱ、を買って読みました。Ⅰで挫折しました。その時偶然手に取ったのがこの本でした。この本を読んでから競争戦略論を読むと少しはわかるようになりました。
レッドオーシャンやブルーオーシャンという言葉はご存じだと思いますが、この本では具体的な事例が豊富に載っていますので大変参考になりました。2つの方法でブルーオーシャンを探す手順が具体的に書かれています。
アクションマトリックス:増やす/減らす、付け加える/取り除くの4アクション
戦略キャンパス:競合に対してどこで差別化してどこで負けるかをマッピングする
当時の大阪のセールスフォースビジネスを見た時にプリセールスが弱いパートナーが多いと判断してそれを差別化ポイントとして広げてきました。

(飛び込みで、初参加でしたが、ご自分のビジネスとからめたプレゼンは素晴らしかったと思います。)

<(株)ビジネスラボ 中尾泰治さん>:フラットデザインで考える 新しいUIデザインのセオリー

2013年にiOS7が出た時ユーザインターフェースが大きく変わりました。その時私も「何だ?」と思いました。そして2014年にはGoogleもマテリアルデザインという名称でフラットデザインになりました。様々なユーザーインターフェースがフラット化しています。この本ではその背景などを丁寧に解説されています。著者はヤフーのデザイナーです。
今まではボタンは立体的なボタンの形、つまり現実のものを出来る限り再現しようとするデザインが主流でした。ところが「ラジオボタン」の本物を見た事がある人がどれだけいますか?若い方なら「フロッピー」すらわからないでしょう。あのフロッピーのアイコンは既に「保存」という意味で学習されているのです。
従来より使う時間が長くなったために派手でない疲れないデザインを主と考えて、わかりにくくても学んでもらうという方向になったのがフラットデザインです。

(UXはもう少し大きな概念であり、UXの一部にフラットデザインがあるそうです。またアフォーダンスという言葉は誤解されやすいのでノーマン自身使わなくなったそうです)

--------------------

結果発表!!今年のIT勉強宴会のチャンプ本は

  ブルーオーシャン戦略

に決まりました。奥田さんおめでとうございます。

<所感>

もう少しIT縛りにするかどうかは難しいです。何のためのIT勉強宴会なのかわからないという気持ちもあります。でも、前回のチャンプ本がドラッガー、今回がブルーオーシャンですからIT縛りにすると出てこなかった本でしょう。結局ビブリオバトルは常連さんが多くなる運命なのでしょうね。

以上

Viewing all 87 articles
Browse latest View live