« 2014年6月 | トップページ | 2014年8月 »

2014年7月

2014/07/31

「納品をなくせばうまくいく」の感想part3~「納品のない受託開発」のビジネスモデルの不明点とあるべき姿

「納品のない受託開発」のビジネスモデルの不明点とあ今後の方向性について考えたことをメモ。
倉貫さんに直接質問しないと、理解できた気にならないと思っている。
間違っていたら後で直す。

【元ネタ】
書評:システムインテグレーション崩壊 ~これからSIerはどう生き残ればいいか? | Social Change!

「納品をなくせばうまくいく」の感想part2~「納品のない受託開発」のビジネスモデル分析: プログラマの思索

「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで」: プログラマの思索

【1】「初期費用なしで開発したソフトウェア」は誰の資産なのか?

「納品」をなくせばうまくいく」を読んでみて、このビジネスモデルはSaaSであり、開発したソフトウェア(システム)はSI側の資産であり、顧客は利用費を支払うものだと思っていたが、違うらしい。

(引用開始)
違うというのは、お客さまはすべて経費にする訳ではないんです。「納品のない受託開発」というキャッチフレーズではありますが、実質は、私たちの持ち物ではなく、お客さまの持ち物なので、お客さまに資産計上はして頂きます。新規開発にかかった分が計上対象になります。納品というのはその区切りに過ぎないので、納品という様式がないからといって計上しないわけではないのです。
(引用修了)

【1-1】「ソフトウェアは誰の資産なのか?」が根本的な問題だ。

従来のSIモデルでは、開発したソフトウェアはユーザ企業の資産だ。

普通、受託側のSIは、発注側のユーザ企業にシステム提案して、システムを導入すると業務がこのように抜本的に改革できますよ、とアピールする。
すると、発注側の立場では、では、そのシステムの回収計画とROIを示してくれ、とSI側に要求する。

発注側としては、システムの初期構築費とランニング費用が知りたい。
その理由は、単に安く開発を済ませたいからだけではない。
導入したシステムで本当に元が取れるのか、ROIと損益分岐点が知りたいのだ。

普通は、システムの初期構築費は数千万円、数億円のような巨大な金額になる。
はい、契約します、とすぐに発注側企業も契約できるわけではない。
情報システム部門が、色んな利用部門にヒヤリングして根回しし、経営者に向けて、システムのメリットをきちんと説明できて初めて契約できる。
多額の初期費用を支払ったのに、「誰も使わない、使い勝手の悪いシステム」になるのは困る。

初期構築費用は、SIの開発工数だけではない。
サーバー代金もあるし、Oracleなどミドルウェアのソフトウェアライセンス、パッケージ製品のソフトウェアライセンス費用、開発者のライセンス費用、ユーザ企業への教育・研修費用も含まれる。
それなりに費用はかかるものだ。

また、苦労して開発したシステムが無事に稼働しても、実際の利用人数が少なく、ランニング費用が高ければ、「使うだけ損」という気持ちにもなりやすい。
発注側企業にすれば、毎月の保守費用に数十万円、数百万円も支払うのに、SIベンダーはちゃんとその価値を提供してくれているのか、と疑いがちだ。

普通の会社では20万円以上の費用の支払は、部課長の決裁はできず、会社の稟議で承認を得ないといけないから、高額になるほど、社内の根回しが大変になる。
実際、本番障害がほとんどなく安定稼働しているなら、ランニング費用はせいぜいサーバーの電気代や通信費くらいでそんなに高くないでしょ、と思っているからだ。

だから、発注側企業はSIに対し、システムの初期構築費用と毎月のランニング費用はどれくらいになるのか、その回収計画を提示してくれ、そしてROIがどのように変化するのか回収計画に盛り込んでくれ、とよく言う。

一方、SIにとって、回収計画は非常に重要な提案だ。
オンプレミスの業務システムならば、業務システムは顧客の資産になる。
すると、初期構築費用は顧客側の資産に計上され、3~5年かけて減価償却される計算になる。
そして、本番稼動後1年間は無償の瑕疵担保責任をSIが持ち、1年後からランニング費用が発生するのが普通。

すると、発注側企業は、最初の1年間に初期構築費用という高額な大金を支払い、1年後から毎月、それなりの金額のランニング費用を支払い続けることになる。
業務システムを使い続ける限り、ランニング費用の支払いを止める訳にはいかないから、最終的には発注企業はSIの言いなりになって支払い続けるしか無い。

すると、業務システムを開発して運用し続けた場合、業務システムのライフサイクルを考えると、業務システムが生存している間にユーザ企業が支払い続けるコストは、「初期構築費用+ランニング費用 * (稼働期間 -1年)」となり、かなりの金額になる。
たとえ小規模な業務システムであったとしても、5年も使うならば、おそらく数億円以上はかかっているのではないだろうか。

逆に言えば、SIとしては、一度導入したシステムがユーザ企業で使い続けられるなら、毎月定額のランニング費用が入ってくるので、安定した収入源になる。
ユーザ企業がいくら現状の業務システムに不満があったとしても、その業務システム無しでは業務が止まってしまうならば、SIも、その仕様変更はすごく工数がかかります、と突っぱねることもできる。
「システムの安定稼働が最優先です」を大義名分にすれば、SIは無理して、開発する必要もないのだ。

だから、業務システムのライフサイクルの観点から見た回収計画は、発注側企業と受託側SIの駆け引きになりやすい。

【1-2】従来のSIモデルにはそんな背景があるから、「納品のない受託開発」のビジネスモデルは画期的と思っていたけれど、SaaSモデルと同じという僕の理解は間違っているみたい。

「初期費用なしで構築したソフトウェアは顧客の資産であり、毎月のランニング費用(月額定額料)を支払う」というモデルはそもそも実現し得るのか?
構築したソフトウェアに関する費用は誰が持つのか?
初期構築費用は資産ではないのか?

そもそも、最初に何か新しいモノを生み出すには、初期投資という費用が発生する。
その費用はどこから湧いてくるのか?

単純に考えると、「納品のない受託開発」のビジネスモデルは、ユーザ企業の資産(ソフトウェア)の減価償却を毎月のランニング費用という月額定額料に混ぜ込んでいるのではないか?

つまり、普通は3~5年かけて分割払いにする減価償却費を、もっと長いスパンの薄い費用にしてしまい、月額のランニング費用に上乗せしているのではないか?

すると、実は、月額定額料の金額はかなりの高額になるのではないだろうか?
なぜなら、普通のランニング費用の上に、少しとは言え薄く積み上がった減価償却費を積んでいるからだ。

この辺りのビジネスモデルは直接聞いてみたい所だ。

【2】「納品のない受託開発」のビジネスモデルのあるべき姿は、「優秀なエンジニア」と「CTOやCIOを求める企業」のプラットフォームではないか

「納品のない受託開発」のビジネスモデルで最も興味が惹かれる部分は、月額定額料のビジネスモデルよりも、優秀なエンジニアのリソース・プールである「ギルド」というプラットフォームだ。

日本のIT業界が抱える問題は、受託SIの多重下請構造のために、優秀で意欲ある技術者がインセンティブを持ちにくい点に尽きると思う。
その理由は、「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索に書いた。

そんな問題を抱えたままなので、日本のユーザ企業が自社内で優秀なエンジニアを抱えて、自社開発を進めることも実際は難しい。

その背景は、【公開】第30回IT勉強宴会「最近感じる日本企業のITの問題と展望~「ソフトを他人に作らせる日本、自分で作る米国」を読んで」: プログラマの思索にも書いた。
「日本のユーザ企業がシステム開発を内製化するにはどうすればよいのか?」とユーザ企業自身も考えているけれど、実際の開発現場では、なぜか、ユーザ企業の若手はプログラミングしなくなるのだ。

おそらく、日本のユーザ企業では、プログラマよりもプロジェクトマネージャのような管理職になるのがスキルアップのモデルとして普及されているから、自分の給料や社会的地位を上げるには、プログラマで居続けるインセンティブがないのだ。

一方、「納品のない受託開発」のビジネスモデルでは、優秀なエンジニアは「ギルド」という集団で技術を切磋琢磨する空間が保証されている。
そして、ソニックガーデンが技術レベルを認めれば、「ギルド」にいる技術者が、ユーザ企業のCTOないしCIOとして、ユーザ企業のビジネスをITインフラ面から支援する仕事を請け負う。

つまり、「ギルド」は「CTOやCIOを求める企業」のためのIT技術者を提供するプラットフォームでもある。
このプラットフォームにいる優秀なエンジニアが多いほど、CTOやCIOになれるエンジニアをユーザ企業に提供でき、毎月の売上も定額料のおかげで安定した収入として増やすこともできる。

だから、このビジネスモデルの本質は、「ギルド」というプラットフォームをいかに育成するか、という点にあるように思う。

僕が単純に考える「ギルド」のイメージは、最近活発に開催されているITコミュニティの一部と同一視できるのでは、と思う。
活発なITコミュニティには、意識の高いIT技術者がたくさん集まり、能力を切磋琢磨している。
また、若い技術者も定期的に流入しているから、幅広い年齢層のITコミュニティも多い。
そんなITコミュニティをギルド化すれば、「納品のない受託開発」のビジネスモデルの基盤にもできるだろう。

この辺りは完全に僕の考えにすぎないので、実際に聞いてみたいと思う。


| | コメント (0)

2014/07/29

第33回関西IT勉強会の感想~製造業の基幹システムのパターンが知りたい

第33回関西IT勉強会のメモ。
感想をラフなメモ書き。

【元ネタ】
第33回 IT勉強宴会in大阪 : ATND

関西IT勉強宴会のブログです: 第33回IT勉強宴会in大阪 【「受注生産」のためのシステム開発ライブ】

Twitter / akipii: 渡辺さんの話。受注生産にはロットごとの在庫管理もいらない。下手に経験し過ぎて過去の開発の経験の奴隷になっていた。すごく意味深

Twitter / akipii: 渡辺さんの受注生産の話は単品生産かつ受注後に仕様に基づいて生産する方式。作出属性や評価をデータベースで実現する場合、evalを使うと言う事例。最終的にはDSLに繋がるだろう.

Twitter / akipii: 生産管理システムの設計パターンが知りたい。佐野さんの話では四種類あり、それぞれ特徴と課題がある。トヨタのJIT生産方式もその一つに過ぎない。在庫の変動と工場の操業率に課題がある。その辺りをモデルで整理できないか

「受注生産に徹すれば利益はついてくる」の感想~ERP普及が上流工程の軽視を助長している: プログラマの思索

【1】佐野さんの話。
製造業の受注生産のプロセスは幾つかのパターンがある。

単品生産と混流生産。
個別生産と反復生産。
大量生産と少量生産。
部品集約生産と展開集約生産。

見込生産と受注生産。
見込生産は組立型とプロセス型がある。

組立型の例は、家電製品。
ロットごとに個別に製造する。

プロセス型の例は、化学、化粧品、製薬、食品など。
バルク生産。
石油や化学薬品という原材料から副産物ができたり、製造後の半製品をリサイクルできたりする。

生産管理には幾つかのパターンがある。
ETO、MTO、BTO、MTSなど。

製番管理は受注生産の基本形。
受注番号=製造番号で、一つの製造番号に関係する部品を紐付ける。

追番管理は、渡辺さんが提唱する在庫推移監視方式に似ている。
但し、計画の変更が発生すると、生産計画に大きな影響がある。

セル生産。
JIT生産、つまり、トヨタのかんばん方式。
TOC。

【2】渡辺さんの話。
ある中小企業の受注生産は、受注したら、技術者の長年の経験で、設計から部品仕入れ、部品組み立て、加工、出荷までやる。
ロットごとの在庫管理もいらない。生産計画もいらない。進捗管理もする気がない。
すごく単純。

だが、受注して生産する製品は、多品種少量生産だが、仕様はある程度決まっている。
長さ、幅、重さ、面積はこれくらい、とか。
これらが受注生産する製品の仕様を構成する。

製品の仕様構成からなる項目の計算式、例えば、面積や重さが仕様を意味する。
それらは作出属性でもあるが、意味がある。
また、長さの範囲という評価式もある。
つまり、単純ではあるが、計算式という関数をテーブルのカラムにセットする必要がある。

では、どのようなテーブル設計にすべきか?

答えは、仕様構成というテーブルに、受注製品Noと仕様変数Noを持たせ、長さ、幅、重さ、面積のような各種の項目を属性としてそれぞれ独立させて持たせる。
評価式をテーブルの属性として文字列として持たせる。
その評価式を計算したい時、evalで評価する。
つまり、画面上で、例えば、長さAと長さBから面積を求めたい時、JavaScriptで評価式をevalで実行して計算させて、結果を表示させる。

つまり、evalのような評価機能のある言語が必要。
ただし、変な値がテーブルにセットされていたら、セキュリティ上危険。

また、コンテキストのスコープはどうなるのか?という質問もあった。

【3】「受注生産に徹すれば利益はついてくる」を読んできたから、製造業の受注生産システムのパターンを整理するような話が聞きたかったが、もっと細かい話で、ちょっと残念だった。
多分、講演の面白さはごく一部の人達だけではなかったか、と想像する。

【4】今まで、業務システムの設計や開発をしてきたが、上流工程の設計技術がどんどん軽視されている気がする。
むしろ、クラウドやモバイル、データマイニングなど、下流工程の技術革新の方が激しくて、そちらを追いかけるのに精一杯。
また、そんな最新技術を追いかけるのは楽しい。

実際、上流工程の設計技法は必要性は分かるが、実際の現場ではさほど必要とされていない。
理由は「受注生産に徹すれば利益はついてくる」の感想~ERP普及が上流工程の軽視を助長している: プログラマの思索にも書いたけれど、ERPというパッケージ製品が普及しているために、生産管理や会計、販売などの業務を一からスクラッチで開発する必要がないからだ。
たとえば、弥生会計や奉行シリーズのような安い会計パッケージ製品のおかげで、中小企業なら会計システムを一から作る必要もない。

同様に、大企業ならSAPやOracleEBSのようなパッケージ製品を導入するのが普通だから、自社の業務とパッケージ製品のフィットギャップ分析だけやれば十分。
細かい機能設計まで考えなくても、導入して運用することはできる。

すると、上流工程の設計技法はさほど必要ではない。
むしろ、パッケージ製品にある機能を知り尽くすだけで十分。
上流工程の業務知識や設計の技法をあまり知らなくても、パッケージ製品を知り尽くしていれば、導入できるし、コンサルみたいに振る舞える。

でも、そんな流れは本当に正しいのか?
上流工程の知識の重要性は落ちているのか?

DOAは日本が編み出した設計技法であり、その技法はとても優れていると思うが、そのノウハウを公開しなかったこと、また、そのノウハウをパターンや知識体系として綺麗に整理できず世の中に広めようとしなかったことが、上流工程の知識の軽視の一つに遠因になっているような気がしている。

【5】僕自身は、「受注生産に徹すれば利益はついてくる」を読んで、製造業の生産管理の方式、その生産プロセスの特徴と長所、弱点が綺麗に整理されていて、非常に面白かった。
一口に受注生産と言っても、下記の4種類があり、それぞれ利点と長所がある。

ETO:設計前に受注して、顧客の要望に合わせて材料を購入して生産する(例:製鉄、造船など)
MTO:設計書がある前提で受注を受けて部品を発注して組み立てる(機械部品、半導体機械など)
BTO:見込生産で部品は自社工場で倉庫に作り置きしておいて受注が来たら即座に組み立てて出荷できる(例:自動車、パソコンなど)
MTS:見込生産で製品を作っておき、受注が来たらすぐに出荷する(例:家電製品など)

上記の4種類の生産方式は、リードタイムの長さ、在庫の有無、工場の操業度の変動有無、見込生産と受注生産など色々違いがある。
その違いが、業務システムにも大きく影響している。

この辺りを整理してみたい。
できれば、アナパタみたいに、モデルのパターンまで抽象化してみたい。

| | コメント (1)

2014/07/26

知的誠実さの大切さ~Moodleが持つ教育のイノベーションの可能性

結城さんのTwitterで気づいたことをメモ。

【元ネタ】
Twitter / akipii: 良い質問。知的誠実さが重要。無知の知を実践すること。RT @hyuki: 結城さんはわからないことがあったときどうしていますか? 私は高校生なのですが物理がわかった感じがしません。... ? 「わかった感じ」は難しいですね。http://ask.fm/a/b2ai10dd

結城さんはわからないことがあったときどうしていますか? 私は高校生なのですが物理がわかった感じがしません。公式を当てはめているだけで理解できていない感じがします。 | ask.fm/hyuki0000

【1】勉強していると「分かった気がしない」という感覚を感じる時がある。
教科書を読んで、先生や同僚から説明を受けて、確かにそうでしょう、と思うけど、腹の底では、自分の中で本当に納得できない時がある。

その時、あなたはどう対処するか?

最悪な方法は、分かったと思い込んで進んでしまうこと。
すると、もっとレベルの高い概念に触れた時に、基礎となる概念を理解していないから、結局つまずいてしまう。
そして、その先に進もうとしても進めなくなる。
でも、テストがあるから、何も考えずに丸暗記でカバーしようとする。
結局、考えることを放棄したり、自分の心を偽って、ありのままの現実を否定する行動に移る。

「分かった気がしない」という気持ちは大切にすべき。
ソクラテスが「無知の知」と読んだ内容と似ていると思う。
「自分が何も知らないことを知っている」ことを持っておくこと。

ソクラテスの無知の知は矛盾していませんか? - 哲学 - 教えて!goo

【2】上記の高校生の質問を見て、渡部昇一氏の「知的生活の方法」の一節を思い出す。

英語には「知的正直さ」という言葉がある。
これは、分かっていないのに分かったふりをしない、ということ。
当てずっぽうで間違えたのか、本当はそうだと確信しながら間違ったのか、その辺りの区別を自分自身でつけること。

「知的正直さ」を持つべき、と言う事実が上記の質問の回答になると思う。

【3】上記の高校生の質問から連想したのは、「世界はひとつの教室」というカーンアカデミーの一節。

教育にソフトウェアによるプロセス改善サイクルを導入する~カーンアカデミーによる教育の未来: プログラマの思索

カーンさんが自分で作った教育ソフトウェアを、実際に米国の小学生の講座に適用して実験する時、あえてA/Bテストを実施してみた。
A/Bテストの実施方法は、6~8年生の生徒に対し、一つのクラスは5年生レベルから始め、他方のクラスは1年生レベルから始めること。

その結果、最初に崩れた前提は「6~8年生にとって基礎的な算数は優しすぎる」ということ。
算数の九九や二桁のひき算のような所でつまずく生徒も出てきた。
でも、それらをクリアすれば先に進んでいけた。
逆に、5年生レベルから始めた生徒のグループは、数段階先に進んだ所でつまずいてしまい、最終的には、カメがウサギを追い越した、とのこと。

更に興味深いのは、A/Bテストをサポートした先生から、本当に欲しいのは生徒がいつ「立ち往生」しているかを教えてくれるソフトです、というフィードバックを得たことだ。

「立ち往生」とは、「分からない」と「分かった」の間にある、「分かった気がしない」感覚。
その感覚を子供は自覚できない時がある。
その時は、先生から諭してあげて、生徒に気づかせて、自力で解決させねばならない。
そんな「立ち往生」はソフトウェアで気づかせられればもちろん良いし、一番良いのは生徒自身が自覚しながら勉強できることだろう。

【4】最近「Moodle 2ガイドブック」の本を読んで、教育という古くからのやり方に、ソフトウェアが大きな影響を与えている事実を改めて感じている。

カーンアカデミーでは、10問連続して正解するまで先に進めない、というルールを設けて、「立ち往生」をチェックする機能を作った。
この「10問連続して正解するまで先に進めない」のようなルールは、Moodleのようなeラーニングツールでは、「完了チェック」機能と呼ばれている。
つまり、各コース(授業)の修了条件を設けて、学習の修了を自動判断する機能を作っているわけだ。

Moodle 2ガイドブック」を読むと、コンピュータ支援教育には、従来の教育を根本的に変える可能性を秘めているのがよく分かる。
従来のプロイセン型教育のような詰め込み教育から、カーンアカデミーのような完全習得学習、つまり、パーソナライズされた教育体験の提供への流れ。

カーンアカデミーの話もそうだし、最近は東大や京大もMOOC(大規模オープンオンラインコース)に参加する話ももあった。
何百万円もの大金を支払わなくても、誰もが高等教育を受けるインフラが整ってきた時代が来つつある。

Moodle 2ガイドブック」では、破壊的イノベーションの本の著者であるクリスティンさんが書かれた本「教育~」もあったので読んでみたいと思う。

【5】Moodleは、オープンソースのコース(授業)管理Webシステム。
Moodleの使い道は、従来の詰め込み教育の補完にも使えるし、オンラインの自己学習、O2O(オンライン・トゥ・オフライン)を生かした授業の支援などがある。

従来のように、教室で行なっている対面授業をサポートする仕組みとしてMoodleを使う「ブレンディッドラーニング」。
カーンアカデミーのように、自宅で講義のビデオを見て、教室では問題を解いたり、実習したり、個別指導を受ける「フリップモデル」。

あるいは、オンラインで基礎知識を学習後、集合研修を行い、研修後のフォローアップをMoodleで行う「ハイブリッドモデル」。
このハイブリッドモデルは、兵器の取り扱い、船や航空機の操作ができる人材を大量に教育する必要がある所から生まれているらしい。

さらに、オンライン上で授業を受ける生徒同士がMoodle上のフォーラム、チャット、ワークショップ(相互評価・ペアレビュー)でコミュニケーションしながら、学びの実践共同体を形成する方法。
これはいわゆる「コミュニティ・オブ・プラクティス」と呼ばれる。

Moodleは、このソフトウェアを作った研究者が「社会的構成主義」という考え方を具体化するツールとして実現したもの。
「社会的構成主義」とは、個人だけでなく、人々がグループ内でインタラクション(相互作用)しながら何らかの成果物を作り上げていく過程で、知識を形成していくのだ、という考え方。
だから、Moodleには、授業の教材を単純に管理する機能だけでなく、ワークショップ、Wiki、用語集、フィードバック、フォーラム、チャット、投票、調査など、色んな機能が実現されている。

Moodle 2ガイドブック」を読んで、Moodleの基本的な運用方法がイメージできたので、後でまとめてみたい。



| | コメント (0)

2014/07/16

「受注生産に徹すれば利益はついてくる」の感想~ERP普及が上流工程の軽視を助長している

@hatsanhatさんから借りた本「受注生産に徹すれば利益はついてくる」を一気に読んだ。
渡辺幸三さんの本「生産管理・原価管理システムのためのデータモデリング」を読んできたものの、腹の底まで理解してなかったけれど、「受注生産に徹すれば利益はついてくる」を読んで、製造業の業務システムのコツが何となく理解できたような気がした。
理解できた内容をラフなメモ書き。

【参考】
書評:「受注生産に徹すれば利益はついてくる!」 本間峰一・著 : タイム・コンサルタントの日誌から

【1】受注生産の会社は下請け業者の意識が強い。

日本の製造業の大半は受注生産。
自動車も顧客ごとの要望を受けて受注生産する。
旧電電ファミリーの家電メーカー(NTT、NEC、富士通、OKI、日立)も、旧電電公社の通信機械を受注生産する所から発展してきた。
重電メーカーの三菱、東芝、日立も同様。
だから、これらの受注生産のメーカーの企業風土は、今も中堅の下請け部品メーカーのそれと変わらない。
つまり、大手重電メーカー、大手家電メーカー、大手部品メーカーも受注生産がメインで、その組織風土が残っているわけだ。

すると、マーケティングを使った華やかな最終製品メーカーに比べると、地味で、社員も下請け意識が強い。
ほとんどの受注生産企業はB2Bなので、知名度も低い。
大学4年生で就職活動している学生は、B2Bの大手の受注生産メーカーをほとんど知らないのが実情。
だから、自社の知名度が低いゆえに劣等感や卑屈感を持つ人もいる。

また、受注生産メーカーは取引先企業の意向に沿うビジネスになるので、経営の自由度が低い。
取引先からのコスト削減要求を受けるために、社員の給料も最終製品メーカーに比べると低かったりする。

さらに、地味な社風であるがゆえに、ぬるま湯体質にもなりやすい。
大手の取引先から安定して受注生産していると、安定して売上や利益は得られるので、対外的な派手な宣伝活動もなく、大儲けして社内が盛り上がることもない。
業務改善活動は、取引先からの圧力で始めることがあっても、社員自らが率先して業務改革に取り込むことは少ない。
なぜなら、社員自ら改善活動を行うインセンティブがないからだ。
従って、社員全体が指示待ち状態に陥りやすく、自ら考えて動かなくなる。

正直、日本の製造業の大半は、このような傾向が多いのではないだろうか。

【2】しかし、受注生産は日本人に向いている。

見込生産は、大量生産・大量販売の頃の生産方法。
受注生産は、わがままな取引先や顧客の要求に柔軟に応えて生産する方法。
「日本人独特の感性」のおかげで、取引先や顧客のわがままな要求を柔軟に取り入れて形にすることができる
日本の経営者のリーダーシップや経営能力が世界基準で低くても、日本の現場にいる技術者は優秀だからだ。

日本のビジネスマンは勉強熱心な人が多い。
そんなビジネスマンがマーケティングや経営戦略を勉強していると、アップルやグーグルのようなベンチャー企業の精神溢れる事例に比べて、受注生産メーカーの経営戦略が貧弱に見えてくる。
しかし、日本の企業経営者がマーケティング戦略を重視していないのは、彼らが無能だからと一概に言えない。

取引先とのパイプが受注生産メーカーの最重要生き残り戦略。
すると、売上計画は取引先の業績に左右され、自社独自で計画立案してもあまり意味が無い。
マーケティング・マネジメントの基本戦略の4Pですら、自社で自由に管理できない。

むしろ、受注生産メーカーは、マーケティングの教科書に出てくる経営戦略を作るよりも、取引先や仲間の下請け企業と人的パイプ作りを強める方が効果が出る。
受注生産メーカーがマーケティングを重視した新製品・新事業に乗り出したり、イノベーション重視の戦略をいきなり乗り出しても、簡単に成功はありえない。

むしろ、日本人に向いた「受注生産」を極めた方がいい。

【3】受注生産は、MTS~ATOまで4種類ある。

【3-1】ETO:受注設計生産。
 設計前に受注してから精算する。
 たとえば、造船業や建設業。金型メーカー。
 相手の要求に合わせて製品を作るので顧客満足度は高い。
 しかし、納入に3~6ヶ月かかるので、納期調整が難しく、仕掛品在庫が増加しやすい。
 ソフトウェア業界の受託開発もココに当てはまるだろう。

【3-2】MTO:受注生産。設計済みの製品を、受注を受けてから生産する。
 たとえば、機械部品、産業機械。
 日本の多くの中小製造業は、ココに当てはまるだろう。
 納入に1~2ヶ月かかる。
 注文や内示情報をトリガーとして生産開始するので、自社独自で個別製品別の生産計画を作れない。
 すると、工場の操業度が変動しやすいため、損益の変動が激しいから、赤字になったり黒字になったりする。

【3-3】ATO:受注組立生産。あらかじめ先行手配した部品を税込しておき、受注した時点でその部品を組み立て製品を出荷する方式。
 たとえば、デルのPC。トヨタの国内向け自動車。
 多品種少量生産の企業に多い。
 受注生産メーカーの究極の競争優位戦略とも言える。
 顧客対応面では優れている反面、在庫が増えやすく、工場の操業度の変動が激しい弱点がある。

【3-4】MTS:製品在庫生産。別名、見込生産、計画生産。
 先行生産した製品在庫を出荷倉庫に積み上げておき、注文に応じて出荷する。
 短納期で出荷できる。
 受注生産が基本の企業も、MTS指向が多い。
 受注生産メーカーでも、保守部品だけはMTSという企業も数多い。

 MTSの企業では、MRPという生産システムを必ず持っている。
 MRPは、BOMから部品展開して部品の必要数量とリードタイムを計算する。
 しかし、MRPは使いにくいので有名だ。
 しかも、MRPは受注生産に不向きだ。
 
【3-5】MRPの部品展開計算(MRP)を手作業で実施するのは非常に難しく、生産管理パッケージ製品を導入して実現するのが普通。
 しかし、MRPの問題は、あいまいなInput情報への対応が苦手なために、取引先のわがままな要求に対する生産計画を立てづらいことだ。
 だから、普通は、欠品状態を出さないように、眺めのリードタイムや短めの納期を設定したりして、個別に対応する時が多い。

 また、MRPでは「タイムオフェンス」という機能があり、ある時期を過ぎたら計画変更を一切できないような仕組みがある。
 しかし、受注生産メーカーは取引先のいかなる要求にも対応せざるを得ないから、タイムオフェンスは受け入れがたい。
 現実には、現場要員が手作業で生産計画を調整しがち。
 
 すると、MRP生産管理システムを正しく運用している製造メーカーは、日本では極めて限られる。
 一般には、全ての部品で同じリードタイムを設定したり、部品展開後にすぐに指示書を出すように、部品展開計算だけを利用する。
 これでは、MRPが目標とするJIT生産に程遠く、仕掛品在庫の削減、欠品による製造作業の停止抑制などは実現できない。
 逆に生産管理システムを有効に動かすために、余分な在庫を持たせて生産ラインを止めないようにする、といった本末転倒なアプローチが多くなる。

 この辺りの話を聞くと、ソフトウェア開発のWF型開発の弱点や問題点と全く同じだ。

【4】MRPやERPの導入、運用は受注生産に向いていない

【4-1】では、なぜ、MRP生産パッケージ製品はこのような問題があるにもかかわらず、生産管理パッケージ製品の標準になっているのか?
 その理由は、MRPロジックが機能しなくても、製造業の業務一般をカバーする必要な標準機能が網羅されているために、それら機能を使うだけでも、かなり自動化されるし、作業を標準化できる恩恵が得られるからだ。

 たとえば、各種の作業指示書、伝票の発行、在庫管理、計画と実績の予実管理など、現場業務をサポートする機能が一通りそろっているので、一からスクラッチで開発する必要はない。
 特に、部品展開計算は非常に難しい機能なので、スクラッチ開発するのは非現実的。
 むしろ、パッケージ製品を購入した方が、たくさんの企業の導入実績があるほど、品質は高いだろうから、安くつく。
 つまり、MRP生産パッケージ製品を受注生産メーカーが導入する場合、JIT生産だけあきらめれば、自動化や標準化などのメリットは得られる。
 しかし、その生産システムは製造指示書の発行、生産完了報告の入力だけに特化した矮小化したシステムに過ぎない。

【4-2】本来は、受注生産メーカーはトヨタのようなATO生産方式で生産したい。
 だが、MRP生産ソフトでATO生産方式を実現するのは相性が非常に悪い。
 MRPは元来、MTSをベースとした仕組みのため、ATO方式の現場に適用すると、たくさんの問題が噴出するからだ。
 
 たとえば、自動車の組立生産では、何万~何十万の部品をあらかじめ先行手配しなければならないが、MRPソフトによっては、先行手配した部品が存在するかの確認が苦手なものがある。
 すると、少しでも部品の欠品が出ると、それを使っている製品の全てのMRP計算結果にアラームが出てしまい、いつまで経っても所要量計算が終わらない。
 アラームのリカバリー業務だけに多大な時間が費やされ、製造業務が滞るリスクがある。
 
 MRPだけでなく、販売管理、会計管理など企業の業務全般を統合した基幹系業務システムがERPだ。
 代表例はSAPだろう。
 特に、日本国内だけでなく海外にも工場を展開する製造メーカーは、SAPを導入するのが基本だ。
 というか、SAPがグローバルスタンダードという宣伝に売り込まれて、日本の大手製造業はほとんど導入しているだろう。
 
【4-3】ERPの本来の目的は、経営者の経営数値管理の強化にある。
 ERPを活用すれば、各部門や製品の採算管理が厳格になり、部門評価も行える。
 最終的に、各事業の事業責任者(普通は、事業部長)に対し、売上・利益拡大意識を高め、企業全体の経営効率が高まると信じられた。
 
 しかし、ERPが主導する経営効率化は落とし穴がある。
 ERPが対象とする経営効率化は、基本はコスト削減や在庫削減という守りの戦略なので、新しいマーケットの開拓などの攻めの戦略はやりづらい。
 必然的に、取引先や下請け企業への無理な要求の乱発につながりやすい。
 大企業の守りの効率化は、多くの下請けの受注生産メーカーを苦しめるだけで、日本経済の利益になっていない。
 
 また、ERPは欧米の独立最終製品メーカーで効果を発揮するように作られているため、日本のような受注生産メーカーのビジネススタイルに合致していない。
 取引先のわがままな要求に対応する受注生産ビジネスでは、メーカーごとに業務の形態がかなり違って当然だ。
 そこで、ERPで個別の業務を対応するようにすれば、ERPのカスタマイズが発生し、追加費用が必要になる。
 
 さらに、ERPのバージョンアップに追随してカスタマイズした機能も保守しようとすると、スパゲティソースになってしまい、保守費用が思った以上にかさんでしまう。
 
【4-4】日本の現場は、現場の責任者の機転によって処理される業務が多く、そうした業務のおかげで受注生産力を高めている。
 なのに、肝心の受注生産力がERPの導入で制限を受けると、受注生産メーカーの競争力を落としてしまう。
 
 そのため、大手の受注生産メーカーは、ERPのカスタマイズで全ての業務を実現するのではなく、下請けや取引先に業務のバックアップを求めるようになっている。
 つまり、大企業からの要求の複雑化を誘因しており、下請け企業や小会社に理不尽な業務が押し付けられているわけだ。

【4-5】取引先からのわがままな要求に答えるには、受注生産メーカーにも優れた基幹系業務システムが必要だ。
しかし、最近、日本の受注生産メーカーの情報システムを利用したサービスレベルが低下した事例が多くなってきた。
 その原因は、ERPブームがある、と著者は述べている。
 
 従来は、どのメーカーも自前でスクラッチで基幹系業務システムを開発して運用していた。
 そして、1990年代後半ERPというパッケージ製品を導入するブームが湧き、殆どの企業がERPを導入した。
 ERPの謳い文句は、その業界のベストプラクティスがあるからそれに合わせた方がむしろ良く、ERP導入の方がスクラッチ開発よりも初期費用も運用費用も安い、と。

 しかし、取引先要求に業務を合わせることで成長した日本の受注生産メーカーには、ERPが馴染まなかった。
 パッケージの標準機能に合わせてしまうと、痒い所に手が届くような対応してきた業務はERPでカバーできないからだ。
 すると、取引先の要求を無下に断るわけにもいかず、多額な費用をかけてERPを改造する場合が多い。
 
 更に、問題を根深くしたのは、ERPのVerUpにカスタマイズした機能を追随するコストが年々大きくなったことだ。
 その結果、日本の受注生産メーカーの強みである「個別要求対応力」を生かしづらい。
 だから、旧来のシステムのようにスクラッチ開発を目指す企業もいる。
 
 しかし、昨今のERPブームの影響で、ベンダーにも受注生産メーカーにも業務の分かるSEがほとんどいなくなったため、今度は個別開発にも多額な構築費用がかかるようになった。
 つまり、ERP普及が上流工程の軽視を助長しているわけだ。
 結局、ERP導入にせよ、スクラッチ開発にせよ、受注生産メーカーの基幹系業務システムはROIが悪いわけだ。

【5】他にも、「全部原価計算よりもTOCのスループット会計で原価管理した方がいい」「MTO型の受注生産は追番管理、ETO型の受注生産はWF型風のプロジェクト管理が向く」という優れた記述があり、なるほどと思った。

受注生産と言えば普通は製番管理だが、追番管理は渡辺幸三さんが提唱する「在庫推移方式」の仕組みに似ている、とか、色んな気づきがあった。
追番管理は、戦前の中島飛行機(零戦を作った会社)が生み出した生産方式だった、とか、裏話も面白かった。

Twitter / nmrmsys: 受注生産本読了。受注生産メーカーに合った生産管理=追番管理って、昔この本読んで http://amzn.to/1oZc0ME 社内SEで常駐してた会社にブッ込もうとした記憶がw、イメージ的には在庫推移監視方式を全域に適用したようなの http://bit.ly/1oZcgvj

Twitter / hatsanhat: @nmrmsys 追番管理を知っている方がいて心強いです。リンクしてくれた本には繰り返し生産用と書かれてますね。受注生産に向いている方法だと思ってました


| | コメント (0)

2014/07/15

オープンソースCRM「vtigerCRM」の資料

オープンソースCRM「vtigerCRM」についてリンクしておく

【参考】
vtigerCRM.jp 日本語版コミュニティサイト

vtiger CRMの使い方:vtiger CRMの概要

vtiger CRMの使い方:見積りの作成

vtigercrm-jp/vtigercrm-6.0.0-ja

vtigerCRM 中小企業の強力な助っ人 世界で人気 ERPに近い統合型CRM(オープンソース) - 小規模組織のためのフリーIT(ソフト、Webサービス)活用伝道日記

vTigerCRM | システム管理者の憂鬱

vtigerCRM5.0.4インストール手順 [Solaris VPS/レンタルサーバー | ZoneExpress]

ノートみたいなもの: VtigerCRM 6.0 インストールメモ

(引用開始)
vtiger CRMはphpで開発されているオープンソースの顧客管理システム(CRM:Customer Relationship Management)です。

vtiger CRMは同じオープンソースの顧客管理システムであるSugarCRMから派生した
システムで、オープンソース版のSugarCRMには搭載されていない在庫管理や見積の管理機能を備えています。

日本語対応は、vtigarCRM日本語化プロジェクトにより日本語化パッケージがリリースされていて、日本語パッケージをインストールすることで日本語対応可能です。
(引用終了)

(引用開始)
機能盛りだくさんなのでどこからいじるか悩んでしまいそうですが、ちょっと使って見ていいなと思ったのは、請求書や見積書を日本語でPDF出力できる機能。
海外製のオープンソースだと、特にPDF周りの機能に問題があることが多いのですが(文字化け)、日本語コミュニティのみなさんのおかげで、インストール直後から問題なく使えそうでした(もちろん、レイアウトなどの見た目は自社用にカスタマイズが必要だと思いますが)。
営業活動からサポート履歴、見積り、請求書発行業務まで、クライアントコミュニケーションに関わるすべての活動がワンストップで行えるくらいよく作りこまれているので、うまく運用できれば強力なツールになりそうです。
(引用終了)

僕はRedmineという一つのオープンソースのプロジェクト管理ツールを使い始めてから、パッケージ製品と実際の業務への適用、その間に横わたるフィットギャップ分析に興味を持ち始めている。

Redmineによるチケット駆動開発は、アジャイル開発の一つの実装例。
その運用方法は、対象のチームにうまく当てはまる時もあるが、ソフトウェア開発には沢山の種類があるから、全ての開発チームに有効なわけではない。
でも、Redmineそのものがすごく柔軟なおかげで、WF型開発、システム運用保守、PC資産管理、ヘルプデスク管理など色んな運用方法を試すことができる。

「Redmineの運用パターン集~私に聞くな、チケットシステムに聞け」

そこから、他のオープンソースのパッケージ製品に対しても、企業の業務システムに適用できないか、を考えている。
当然、オープンソースのパッケージ製品をそのまま導入しても、実際の業務と合わない部分はあるし、フィットギャップ分析が必要。
特に、日本企業の業務は、工場や店舗などの現場の力が強く、各現場の独自の運用ルールを持っており、そのすべての運用ルールをオープンソースのパッケージ製品に盛り込むのは非現実的だ。
だから、システムによる自動化の恩恵が得られる範囲と、従来の手運用でカバーしたり、導入したパッケージ製品に合わせて手運用の業務を見極める必要がある。

オープンソースCRMはSugarCRMを調査していたが、肝心の請求管理や見積り管理の機能は有償オプションであり、イマイチな感じだった。
しかし、vtigerCRMは、営業支援や顧客管理だけでなく、請求管理や見積り管理の機能も提供されており、PDF帳票で出力できるらしいので、十分に高機能だ。
vtigerCRMで、CRMの業務をどこまでカバーできるのか見てみたい。

個人的には、オープンソースのERPであるiDempiereに興味を持っている。
iDempiereは、元SAPコンサルタントがスピンアウトして、SAPのノウハウを詰め込んで作ったCompiereが発端であり、そこから派生して発展している。
MRPも付属しているらしいし、SOAPもあるから、他の社内システムと連携することも可能だろう。

ERPはなぜ難しいのか?~オープンソースERPで業務改革を試したい: プログラマの思索

iDempiereのインストール方法と画面キャプチャ: プログラマの思索

こういうオープンソースのパッケージ製品は、業務改善だけでなく、教育や実験という観点でも重要だと思う。
僕自身、Redmineを使い倒すことで、プロジェクト管理やアジャイル開発の抽象的な知識を実際の運用で試した時に、どの部分が有効で、どんな限界があり、どんなリスクがあるか、を把握できた。
同様に、オープンソースERPであるiDempiere、オープンソースCRMであるvtigerCRMを使い倒せば、一企業が必要とする業務システムの機能要求や、営業支援・見積り・顧客管理などのCRMの機能も理解できるようになるだろう。

iDempiereとvtigerCRMは今後も注目していく。

| | コメント (0)

2014/07/14

「納品をなくせばうまくいく」の感想part2~「納品のない受託開発」のビジネスモデル分析

「納品」をなくせばうまくいく 」を一通り読んだ。
自分の理解のために、「納品のない受託開発」のビジネスモデルを分析してみたので、ラフなメモ書き。
自分の想像で書いているので、今度お会いした時に、実際にレビューしてもらった方がいいかもしれない。
間違っていたら後で直す。

【元ネタ】
「納品をなくせばうまくいく」の感想part1~ソフトウェア業界のビジネスモデルが抱える問題: プログラマの思索

【1】「納品のない受託開発」の戦略マップ(イメージ)

バランス・スコアカードの戦略マップを真似て、ソニックガーデンの戦略を整理してみた。
すると、4つの大きな戦略があるように読み取れた。

【1-1】財務の視点

基本は「月額定額制」であり、月額のサービス利用料として回収する。
おそらく当月末請求翌月末入金のような流れかな。

この契約は、準委任契約や派遣契約とは同じではない。
常駐しない保守契約のような「オフサイト保守」「リモート保守」ではない。
そうであれば、人月契約と全く同じ。

あくまでも、クラウド基盤上のWebシステムをSaaS形式で提供しているから、人月契約とは同じではない。
でも、普通のSaaSならば、利用料の値付けが難しい。
利用料が安くてもユーザが集まらなければ、売上を確保できない。
かと言って、利用料が高いとユーザが集まらないし、値下げすると、既存ユーザから反発を食らうだろう。

「納品」をなくせばうまくいく 」を読むと、単なるSaaSではなく、中小企業やベンチャー企業のCTOサービス、CIOサービスとして付加価値を付けている点がミソなのだろう。
つまり、「顧問エンジニア」という呼称は、ユーザ企業のCTOないしCIOの役割として、ユーザ企業の事業システムを開発するから、単なる開発者だけではない。
技術顧問みたいな役割だから、その分、付加価値を付けているわけだ。

【1-2】顧客の視点

基本戦略は「Point of Use(システムは所有せず利用する)」。

従来は、ユーザ企業が業務システムを開発した場合、サーバー代やソフトウェアライセンスの初期費用、システムの初期構築費は、資産として計上され、5年くらいかけて減価償却されていく。
しかし、実際は、初期構築した後、ランニングコストという運用費用が発生し、さらにカスタマイズが発生すれば、追加の費用もかかる。
すなわち、業務システムを無形資産としてユーザ企業が保持するのは、多額の資金を必要とするから、高リスクだ。
しかも、ITの専門家でないユーザ企業にとって、受託SIが開発した保守性の悪い業務システムは、ブラックボックスになりやすい。
SIから、これだけの工数がかかります、と言われても、システムの詳細を知らないし、業務が改善されないのは困るので、SIの言いなりのまま支払うしか無い。

そんな背景があるから、SaaSのように、ユーザ企業がシステムを資産として持たず、使った分だけの利用料を支払う方式が増えている。

但し、全てのシステムをSaaSにできるわけではない。
ミッションクリティカルな基幹系業務システムは、オンプレミスないしプライベートクラウドにならざるを得ないのが現実だろう。

「納品」をなくせばうまくいく 」を読むと、開発対象システムは、事業システム(≠業務システム)の開発だけに限る。
だから、エンタープライズなシステムは範囲外。
つまり、開発対象のマーケットをかなり絞り込んでいる。

すると、大手企業の業務システムよりも、ベンチャー企業や中小企業の事業システムの方が向いているのだろう。
リーンスタートアップのような最新の開発手法も適用しやすい利点もある。

【1-3】業務プロセスの視点

基本戦略は、格安航空会社(LCC)を真似た技術戦略がある。

格安航空会社(LCC)の戦略は、「使用する飛行機の機種を統一して整備費やパイロット訓練費を削減」「搭乗手続きのオンライン化などITによる自動化」「乗務員が機内の清掃・顧客サービスなどを兼務して人件費削減」だ。
この戦略を真似ると、以下の3つの観点になる。

・技術の標準化
→フレームワークはRuby on Rails、本番環境はAWSやHerokuで統一して、効率良いソフトウェア開発を実践。

・SaaS
→クラウド環境を利用して、スモールスタートやスケールアップをやりやすくし、デプロイ・リリース作業を自動化。

・マルチプレーヤ
→エンジニアは、開発者だけでなく、顧客との要件定義、クラウド環境へのリリースなど幅広い技術を使いこなし、複数の役割を兼務する。

もちろん、アジャイル開発などの開発手法も取り入れる。
そんな技術戦略を見ると、かなり対象を絞って、ニッチなマーケットで攻めている感じがする。

【1-4】学習と成長の視点

基本戦略は、ギルドによるフランチャイズ制。
ソニックガーデンと手を組む開発者はギルド集団として認知され、遠隔地でも働けるようにしている。
必要なエンジニアは、ギルド集団から随時登録され、仕事が与えられて回っていく仕掛けみたい。
この形式はフランチャイズ制に似ているように思える。

ギルド集団はエンジニアの育成集団、または、エンジニアの貯蔵庫(リソース・プール)みたいだ。
「納品」をなくせばうまくいく 」を読むと、「レビューによる教育」や「技術者にのれん分け」するなどの話があるので、プログラマをすごく大切にしている雰囲気が読み取れる。

SIの観点では、受託開発は開発・テスト工程で開発要員の変動が大きすぎるため、社外のプログラマを短期間に大量に集めて、本番リリース前に契約を終了する開発スタイルが多い。
だから、プログラマを大切にする雰囲気は生まれにくいと思う。

一方、ギルドによるフランチャイズ制は、プログラマを顧問エンジニアになるレベルまで育成するリソースプールに置いておき、必要になれば仕事に呼ぶみたいな感じを受ける。
当然、ビジネスであるからには、仕事が渡ってこないプログラマもいたり、脱落するエンジニアもいるかもしれない。
だが、技術の向上を目指すエンジニアならば、武者修行としてやれるかもしれない。

ギルドによるフランチャイズ制には、プログラマのインセンティブを高めるような仕組みがあるように思える。

【2】「納品のない受託開発」のビジネスオーナー観点のチーム構造(イメージ)

「納品のない受託開発」のチームは、3つの構造を持つ。

【2-1】ビジネス推進チーム
・ビジネスオーナー=ビジネスの最終責任者
・プロダクトオーナー=仕様を決める最終責任者
・顧問エンジニア=顧客企業のCTO or CIO

【2-2】スクラムチーム
・プロダクトオーナー=PO
・顧問エンジニア=開発チーム
・ファシリテーター=スクラムマスター

【2-3】ギルド集団
・エンジニアの育成集団、貯蔵庫。

このような3つの構造があれば、顧問エンジニアはユーザ企業主体のビジネス推進チームだけでなく、開発会社主体のスクラムチームにも属しているので、開発会社のファシリテーター(スクラムマスター)の支援も受けることができる。
つまり、顧問エンジニア一人が苦労して潰れてしまうリスクを回避しているように思える。

また、開発会社のエンジニアの背後には、ギルド集団というエンジニアの育成集団がいるので、人数さえ揃っていれば、エンジニアの供給ができるだろう。
つまり、ギルド集団がうまく機能していれば、ビジネスのスケールアップにも対応しやすいはず。

【3】「納品のない受託開発」のエンジニア観点のチーム構造 (イメージ)

エンジニア観点では、3種類の役割があるように思える。

【3-1】エンジニアの担当作業
ユーザ企業(例:ビジネス推進チームA~C)ごとに、開発会社のエンジニアが顧問エンジニアで担当する。

【3-2】開発会社内部のエンジニア
・開発会社内で、エンジニア同士でサポートし合う。

【3-3】ギルド集団のエンジニア
・エンジニアの育成集団、貯蔵庫。

上記の役割を見ると、顧問エンジニアが一人で潰れないように、開発会社のエンジニアのサポートやギルド集団の支援もあるように思える。

【4】上記の戦略マップやチーム構造は僕の理解なので、多分正しくない部分があると思う。
でも、「納品のない受託開発」のビジネスモデルは、たくさんのパーツを整合性が取れるようにうまく組合せているように思う。
単純なアジャイル開発をやっているビジネスモデルではないみたい。

実際、SaaSでシステムを提供しながらも、ベンチャー企業のCTOサービスを提供して付加価値を付けているし、技術の標準化やマルチプレーヤ化でプログラマのスキルを高める配慮があるし、ギルド集団によるフランチャイズ制で、エンジニアを補給する手段も作っている。
つまり、プログラマのインセンティブを高める仕組みと売上を確保できるビジネスモデルを上手く組合せているように思える。

この辺りは本音をまた一度聞いてみたいと思う。

| | コメント (0)

2014/07/13

第11回RxTstudy勉強会「Redmine Plugin 活用最前線」の感想~今後の課題はRedmineのエコシステムの創造 #RxTStudy

第11回RxTstudy勉強会「Redmine Plugin 活用最前線」の感想をラフなメモ。

【参考】
第11回RxTstudy「Redmine Plugin 活用最前線」 : ATND

第11回RxTstudy「Redmine Plugin 活用最前線」 - Togetterまとめ

RxTstudy公式サイト

RxTstudy Facebookファンページ

【1】@haru_iidaさんの講演

Rails初心者レベルのRedmineプラグイン開発の講演内容なので、非常に参考になった。
「RedmineプラグインはミニRails」「フック処理の実装はRailsの黒魔術」など、Railsに触れたことがある人なら、ああそうか、と理解できることばかり。
Rubyの黒魔術を知りたい人には、「メタプログラミングRuby」をお勧めしていた。

他に心に残ったお話は以下の通り。

「Ruby&Railsの開発環境は、Rubymineがお勧め。有償製品だが、オープンソース開発者は無償なので是非使うと良い。」
→デモはRubymineだったが、デバッグやリファクタリングがやりやすそうなイメージがあった。

「CodeReviewプラグインのVerUpでは、RailsのVerUpよりもPrototype.jsからJQueryに変更された影響が大きかった」
「CodeReviewプラグインのVerUpはまだなのか、と海外の人からも問い合せが何度もあった。パッチも送られてくるが、綺麗なソースコードでない時もあるので、無下に断るわけにもいかず、穏便に断るように、英語で書くのが大変だった」
「海外の人の障害フィードバックは、あなたのプラグインはとても素晴らしい、と持ち上げた後に、こんなバグがあります、と言ってくる。開発者としては、自分の趣味、または、自分が欲しいと思って作った動機があるから、褒められるとモチベーションがわく」
「日本人の障害フィードバックは、メールの最初から、障害の内容ばかりで、気が滅入る。海外の人のように、最初は褒めておだてて、その後に障害報告をする方が、開発者のモチベーションは上がります」

Redmineの最新情報チェックに「あきぴーセンサー」と言われたのはちょっと恥ずかしいかなw

【2】@pinzoloさんの講演

Redmineをプロジェクト管理やタスク管理ではなく、テーブル定義などの情報管理に使っている、とのこと。
こういう使い方も面白い。
Redmineプラグインのテスト方法、テストプログラムの注意点、ビルド実行など、開発者ならではのノウハウがたくさんあって興味深かった。

以下メモ。

Redmineのテストコードは、ユニットテスト、ファンクショナルテスト、インテグレーションテストで5千以上ある。

それらをrakeのCIコマンドで、一発で実行できる。

TravisCIがお勧め。Redmineコミッタの@marutosijpさんも使っている。
Rubyのバージョン+Redmineのバージョンのマトリックステストも出来る。

tail -f pinzo.log: RxTstudy 11th で発表してきました

Redmineの全てのテストプログラム実行は2~3時間かかるらしいが、@akahaneさんの話によると、Ruby2.1.2上ではRuby2.0.xよりも40%速くなったらしい。
だから、Ruby2.1.2+Redmineでは、性能が大きく向上されたのではないか、と期待されているらしい。

Feature #16194: Ruby 2.1 support - Redmine

Twitter / akahane92: お!待ってました!速度Upとメモリ節約に期待ですね( ^o^)ノ RT @g_maeda: @akahane92 チケットがクローズされ、2.5.2に入ることが確定しました。 http://www.redmine.org/issues/16194

Twitter / akahane92: 急がば回れ / Ruby2.1.2にすればITS(Redmine)の応答が向上する見込みなんだけど、提出物の締切で動けない…。H/W増強機材もSetup待ち。もったいないけど、体は一つだしね。

【3】@ogomさんの講演

第11回 RxTstudy「Redmine Plugin 活用最前線」 | ogom.github.io

Rails - sidekiqの使い方 - Qiita

sidekiqは非同期実行を実現するgem。
Redmine上で、ジョブスケジューラ機能を実現できる。

使い道としては、Redmineの画面上から、定期的にバッチ処理をキックしたい場合、とか、ユーザが画面からバッチ処理をキックしたい時に使える。
例えば、Redmineの実績工数や予定工数を月末に工数締めしたい時とか、案件完了でRedmineプロジェクトをCloseした後で検収締めをしたい時に、非同期で締め処理を実行する時に使えるだろう。

あるいは、メンバー全員に今日、または、今週の担当チケットを通知したり、放置されたチケットや停滞したチケットを通知する時に、メールで一括送信するバッチ処理にも使えるだろう。

今後の使い道に期待大。

【4】パネルディスカッション

テーマは色々あったが、Redmineが今後どのように発展していくべきか、というテーマに絞られたように思う。

@sakaba37さんが、パネルディスカッションでこんな話をされた。
IPAが作ったRedmineベースの定量的プロジェクト管理ツールEPM-Xの前身として、別の定量的プロジェクト管理ツールがあったが、結局普及しなかった。
その理由は、マネージャの観点で、プロジェクト管理ではこんな機能が必要だ、という要望を取り入れて実装したが、開発者の観点では、現場の開発作業の邪魔になるようなデータ入力などの煩雑な作業が多いだけで、開発者のメリットがなかった。

また、@haru_iidaさんは、こんな話をされた。
Redmineのプラグインを開発した理由は、自分が使いたかったからであって、誰かのために作ったわけではない。
だから、開発者の観点で作ったのであり、マネージャの観点で作ったわけではない、と。

では、Redmineは今後、どのように発展していくべきなのか?

Redmineは、開発の現場で、こんな機能があったら便利なのに、と開発者が気づいて、自ら開発したのがきっかけで発展してきている。
だから、コミュニティという場で、開発者とコミッタがお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展していくべきなのだろう。

Redmine本家のフォーラムやチケットの議論を眺めていると、Redmineがアジャイル開発のプロジェクト管理と相性が良い、と気づいて、BackLogsプラグインで実現したり、PMBOKやITILで既に知られているプロジェクト管理のベストプラクティスをRedmineで実現できると気づいて、リスク管理やEVM、リソースヒストグラムの機能をプラグインで実現したりしている。
ユーザとコミッタがRedmineというオープンな場で、それぞれのアイデアを出して実現してフィードバックしていく、という議論はとても有益だと思う。

チケット駆動開発が進むべき道part1~ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

ITの地殻変動はどこで起きているのか?~チケット駆動開発が進むべき道: プログラマの思索

すると、@pinzoloさんの講演で言われていたが、今後は「Redmineのエコシステム」という発想が必要になるだろう。
Redmineの新機能の追加、新しいプラグインの公開だけでなく、Redmineを使った新しい運用方法、初心者向けのインストール方法やRedmineの使い方などの情報をコミュニティという場に集約して発信できるようにしていくべきだろう。

例えば、Redmine2.5.2から「プラグインアップデートチェック」機能が実装された結果、Redmine本家にプラグイン情報が登録され、集約される傾向になっていくだろう。

Twitter / sakaba37: 大切なのは、いいものを作るのではなく、いい循環を作ること #RxTstudy

Twitter / akipii: redmineのエコシステムが必要。プラグインの情報を集約したりなど。 #rxtstudy

Redmine2.5.2の新機能~プラグインアップデートチェック: プログラマの思索

今後もRedmineに着目していく。

| | コメント (0)

2014/07/09

Redmineでリソースヒストグラムを出力してくれるプラグイン~RedminePlannerPlugin

Redmineでリソースヒストグラムを出力してくれるプラグインRedminePlannerPluginを見つけたのでメモ。

【元ネタ】
Resource Planner - Plugins - Redmine

dr-itz/RedminePlannerPlugin

RedminePlannerPlugin/doc/concept.md at master ・ dr-itz/RedminePlannerPlugin

RedminePlannerPlugin/doc/todo.md at master ・ dr-itz/RedminePlannerPlugin

【1】リソースヒストグラムとは、開発要員の稼働率を月別に並べた表のことだ。
要員表または山積み表とも呼ばれる。

受託ソフトウェア開発のようなSIなら、リソースヒストグラムは必ず作っている。
普通は、プロマネが要員表をにらめっこしながら、営業で引合中の案件を受注したら、誰をアサインすべきか、鉛筆をナメナメしながら考え込んでいるはずだ。

MSProjectには、ガントチャートとEVM、そしてリソースヒストグラムを作成ないし生成する機能があるので、Redmineでも仕様上は実装可能だ。

リソースヒストグラムをRedmineで生成するアイデアは、以前、Redmineでリソースヒストグラムを実現するアイデア: プログラマの思索を書いた。

【2】Redmine本家を見ると、リソースヒストグラムを実現するRedmineプラグインRedminePlannerPluginが公開されていた。

RedminePlannerPluginのインストールは簡単。

cd plugins
tar zxf planner-v0.4.tar.gz
mv RedminePlanner* planner

bundle install --without development test

rake redmine:plugins:migrate NAME=planner RAILS_ENV=production

【3】RedminePlannerPlugin/doc/concept.md at master ・ dr-itz/RedminePlannerPluginに、RedminePlannerPluginのコンセプトが丁寧に説明されている。

マトリクス組織を持つ企業のリソース計画を解決するために設計されている。
チームリーダー、プロジェクトリーダー、チームメンバー、営業の観点から、RedminePlannerPluginの利用シーンを説明している。

「資源要求」では、メンバー単位に週別の稼働率が表示される。
80%なら、20%の余裕があるから、少しだけ作業を依頼できる。
120%なら、逆に作業が溢れているので、減らす必要がある。

RedminePlannerPluginを見ると、チケットとは別に「タスク」を新規登録して、その「タスク」から稼働率を計算するようだ。
しかもその「タスク」に承認・拒否などのワークフローが設定されている。
「これだけの人をアサインして確保したい」という申請と承認のフローがあると思われる。

チャートを見ると、週別にチームごと、人ごとのリソースヒストグラムが見れる機能があるようだ。
このリソースヒストグラムは、プロマネにとってすごく重要な機能なので、とてもありがたいはず。

【3】但し、RedminePlannerPluginでリソースヒストグラムの機能が本当に実現されて運用できるか、検証は必要だ。

本来は、チケットにWBSの計画工数を設定し、日々の実績工数は担当者が入力することで、月別・週別のリソースヒストグラムを自動生成したいはず。
チケットにリソースヒストグラムの情報を一元化したいからだ。
そうでなければ、リソースヒストグラムのデータの精度は日々の状況を反映しておらず、意味が無いだろう。

また、月別・週別にリソースヒストグラムを出力する場合、どの時点で工数締めするか、という観点を機能として実現する必要がある。
なぜなら、リソースヒストグラムの過去の実績工数は確定されており、勝手に修正されると改ざんしたと思われてしまうから。
だから、日次バッチ処理で工数集計したり、月末に工数締めする機能が必要になるだろう。

これらの配慮がRedminePlannerPluginに反映されていなければ、Redmine EVM Pluginのように、EVMのアイデアを実現しているものの、実際の運用では使えない判断になってしまうだろう。

RedminePlannerPlugin/doc/todo.md at master ・ dr-itz/RedminePlannerPluginを読むと、機能改善したいアイデアがあるようなので、今後に期待したい。

・稼働率が閾値を超えた倍、アラート機能を追加
・リソースの週間表示
・タスクの階層化
・パートタイム労働者の計画
・休日の対応
・予定外の欠勤
・Redmineのプロジェクト "バージョン"をリンクする
・Redmineのグループでプランナ「チーム」を同期させる

RedminePlannerPluginが惜しいのは、日本語化されていないことなので、誰かパッチを送ってもらえたらと思う。

個人的には、アジャイルウェア社のRedmine Lychee製品シリーズに、リソースヒストグラムのプラグインもあったらいいのにと思う。
なぜなら、Lychee製品シリーズには、EVMやGanttChartのように、MSProjectの主要3大機能(ガントチャート、リソースヒストグラム、EVM)のうち2つがRedmineで実現されているのに、リソースヒストグラムだけがRedmineで実現できていないからだ。

もし、LycheeResouceHistgramがそろったら、RedmineのLychee製品でMSProjectの機能はすべて実現できますよ、とアピールできるはず笑

Lychee Enterprise

| | コメント (0)

Redmine2.5.2の新機能~プラグインアップデートチェック

Redmine2.5.2がリリースされた。
新機能であるプラグインアップデートチェックについてメモ。

【元ネタ】
Redmineのプラグインアップデートチェックを試す - Qiita

Redmine 2.5.2 リリース | Redmine.JP Blog

tail -f pinzo.log: Redmine 2.5.2 へアップデート

Changelog - Redmine

プラグインアップデートチェック機能は、Redmine.orgに登録されたプラグインのバージョンと稼働中のRedmineにあるプラグインのバージョンを比較して、更新すべきかどうか確認できる機能。

@akiko_pusuさんがプラグインアップデートチェックについて、詳細なメモを残されている。

定期的にプラグインチェックアップデート機能を使えば、プラグインが最新かどうか確認できる。
この機能があれば、プラグインとRedmineのバージョンの違いに苦しむ苦労がかなり減るだろう。

実際、Redmineのプラグインは、Redmine本体のVerUpによって、急に使えなくなったりする。
過去には、Ruby1.9、Ruby2.0へのVerUp、Rails3、Rails4へのVerUp、JQueryへの更新など、Redmine本体の急激な機能拡張に付いていけないプラグインがたくさんあった。

但し、プラグインを自動更新してくれるわけではないので、あくまでも確認しか使えない点に注意。

また、Redmine.orgに登録されていないプラグインに対して、バージョンチェックしてくれないから、「?」マークが管理画面のプラグイン一覧画面に出てくる。
したがって、今後のRedmineのプラグインは、Redmine.org本家のプラグインサイトに登録するように、誘導されることになるだろう。

その意味では、Redmine.orgにプラグインも含めたRedmineの全ての情報が集約されていくから、Redmineを利用したり運用する際には、Redmine.orgの内容を定期的に確認する作業が今後重要になってくるだろう。

こういう細かな機能改善がオープンソースのWebアプリで行われているのはとてもすごいことだと思う。
利用ユーザにより優しく使いやすくすることがどれだけ難しい作業であるか、業務システムやWebシステムを開発している技術者ならだれでも知っていることだ。

Redmineの機能拡張は今後も追いかけていく。


| | コメント (0)

2014/07/07

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料

astahを使って、T字形ERによるデータモデリング手法を解説した資料があったのでメモ。
これはすごくためになる。
自分なりの理解をまとめるためにメモ。
間違っていたら後で直す。

【元ネタ】
Twitter / akipii:凄く良い資料!dddosaka勉強会の人は必読でしょう笑 RT @hatsanhat: データモデリング入門ーastah*を使ってTMの手法を使う http://www.slideshare.net/mobile/inamiK/ss-36665472 … 大変親切にわかりやすく解説されています。

【1】T字形ERのデータモデリングをastahProfessionalのER図でどのように表現すべきか、を解説している。
非常に丁寧で分かりやすい。

個人的には、既存システムのリバース・エンジニアリングの設計技法を選択するとしたら、T字形ERが最強だと思っている。
既存の画面や帳票、テーブルさえ分かれば、どんな仕様なのかを明確に提示できるからだ。

また、T字形ERは、リバース・エンジニアリングの手法も定型的な手順で示しているので、どの設計者がER図を書いても同じようなER図になる可能性が高い。
つまり、設計した成果物の再現性が高いと思われる。

【2】T字形ERの設計技法の中で、丸暗記しても良いくらい重要なパターンは、「リソース」「イベント」のテーブルの間のリレーションシップの貼り方だ。

データモデリングの初心者が設計したER図を見ると、普通は親子関係のテーブルをたくさん作りがちで、外部キーを使った関連がほとんどないのが普通。
外部キーというリレーションシップをどんな時に使えば良いのか、理解できていないのだろうと思う。


業務ルールをどのように外部キーとして張ればいいのか、という問題に対しては、T字形ERが鮮やかに解決している。
※「リソース」「イベント」のテーブルの間のリレーションシップの貼り方については、既に@papandaさんが以前Blogで書かれている。

自分流モデリング探しの旅(2)~T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

(前略)
* resourceとresourceをつなぐ場合:対照表を生成する。対照表はeventである。
 (例)従業員と営業所
     従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合:event側に参照キーを持たせる。
 (例)顧客と注文
     注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「1:1」「1:m」:時系列の遅い方に持たせる。
 (例)受注と請求(一つの受注に対し請求は一つ)
     請求に受注番号を持たせる。
** 「m:1」「m:m」:対応表を生成する。
 (例)受注と請求(複数の受注に対し請求は一つ)
     受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

リソースとイベントのリレーションシップは、リソースの外部キーで関連付ける。
イベントとイベントが先行・後続の関係にある場合、先行イベントの外部キーで関連付ける。
先行イベントを後続インベントが集約する場合、連関テーブル(親子テーブル)を作ると良い。

上記のパターンを覚えておけば、たいていのデータモデリングにすぐに役立てられる。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

データベース設計で派生関係は難しい: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

データモデル表記読み替えハンドブック: プログラマの思索

【3】データモデリングが興味深く面白い点は、ビジネス分析に強力に役立つことだ。
データモデリング入門-astah*を使って、TMの手法を使う-の中の図を説明してみる。

【3-1】P.23:受注・支払いの関連の違いから、ビジネスの違いを見出す

【231】通常の受注・支払いパターン
・受注・支払いに顧客番号がある。
→顧客が受注したデータは、支払いデータに引き継がれる。
・支払いに受注番号がある。
→顧客が受注した後、1回で支払った。

【232】一括/分割支払い
・受注と支払いに関連がない
→受注データと支払いデータは顧客番号を通じてつながっている
→顧客は複数の受注データを1回で支払うor複数回で支払う

【233】家族会員の受注・支払い
・支払いデータに顧客番号がない
→支払いは必ず、顧客が受注したデータから発生する。
→例えば、受注は顧客番号を持つ学生(子供)、支払いは顧客番号を持たない親御さんの場合もあり得る。

【3-2】P.25:注文された商品の価格の違いから、ビジネスの違いを見出す

【251】正価販売(値引きなし)
・注文に「商品単価」がない
→商品マスタの価格でそのまま販売して、注文を受け付ける。
→注文テーブルに「商品単価」がないから、値引きした価格を記録できない。

【252】値引きありの販売
・商品にも注文にも「商品単価」がある
→商品マスタの価格で販売するが、店頭では店員が値引きを受け付けて注文できるようにする。
→「商品.商品単価」と「注文.注文商品単価」は異なる価格の場合がある。

【253】オープン価格の販売
・商品に「商品単価」がない
→商品の値段が販売前に確定していない。
→店頭で販売する時に値段が付けられる。

【3-3】P.27:イベントの順序の違いから、ビジネスの違いを見出す

【271】染色→裁断
⇒伝統的なセーターの製法は「糸を染めてからセーターを編む」。
⇒染色から販売まで6ヶ月もかかるので、見込生産になる。在庫が蓄積されやすい。

【272】裁断→染色
⇒ベネトンは「セーターを編んでから染める」手法へ製造順序を逆転した
⇒製造期間を短縮できるので、受注生産や直販が可能になった。在庫も減らせる。

この話は、T字形ERの本にも記載されているらしく、かなり有名な話。
下記の記事が詳しい。

T字形で事業を解析する、とは - 極北データモデリング

sdi - Page: 149 対照表と 「resource」 の相関関係

リソース数がビジネスの可能性に関係する理由: プログラマの思索

データモデリングに慣れてくると、ER図からビジネスロジックの微妙な違いから、顧客のビジネスのニュアンスを感じ取れるようになる。
この辺りが分かれば、顧客のビジネスに疎いモデラーでも、システム上はこんなビジネスも可能ですよ、と経営コンサルタントっぽく振る舞うこともできるかもしれない。

【4】astahは、UMLだけでなく、ER図もお手軽に書けるのが良い。
また、ER図からExcelのテーブル定義書やDDLを出力できるので便利だ。

個人的には、astahはIE記法やIDEF1X記法にも対応しているので、T字形ERにも対応してもいいのではないか、と思ったりする笑

【追記】続編が公開されていたのでリンクしておく。


| | コメント (0)

2014/07/06

astahによるモデリングのメモ

ドメイン駆動設計」を読み直すようになってから、UMLによるモデリングをもう一度見直している。
アイデアをラフなメモ書き。

【参考】
オブジェクト指向設計の4つの流派からドメイン駆動設計へ: プログラマの思索

astah* professional 6.1の要求図: プログラマの思索

SysMLの要求図の書き方: プログラマの思索

シーケンス図とアクティビティ図と状態遷移図の関係: プログラマの思索

FP法で業務モデルを計測する: プログラマの思索

【1】僕は、UMLの各種ダイアグラムを、業務やプロセスやシステムの分析のラフなスケッチに使っている。
業務の流れ、プロセスの流れ、システムの振る舞い、システムの機能の関係を理解したい時、絵を描く方が、理解が早まる。

基本は手書きが多い。
でも、astahで描いておくと、後から何度でも修正変更できるし、ブラッシュアップできる。

UMLの利点は、1つのモデルを動的・静的な図など7種類以上の図を用いて、複数の観点で分析できることだ。
分析は、文章や表だけ書いても分からない。
文章よりも図の方が直観的で、イメージを共有しやすい。
一つのモデルをいろんな観点から徹底的に分析し、色んな性質や特徴をあげて、その整合性を見出す。

その試行錯誤が面白いし、モデルの本質が分かった時は、なるほどと思う。

【2】そのastahを使って、要求収集の工程から実装まで、一つの体系で一気通貫で設計できないか、考えている。

【参考】
実はastahを使って要求から画面作成までを一気通貫(&自動生成)する方法の論文が無料で見れる - ウィリアムのいたずらの開発日記

組み込みソフトウェアの場合のUML導入の問題とSysML - ウィリアムのいたずらの開発日記

UML以前の、システムの関連性(トレーサビリティ) - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その1:概要 - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その2:ユースケース - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その3:ユースケースシナリオ - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その4:ロバストネス分析 - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その5:属性を埋める - ウィリアムのいたずらの開発日記

astah*を使って、ICONIX風一気通貫システム開発 その6:画面構成 - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(1) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(2) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(3) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(4) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(5) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(6) - ウィリアムのいたずらの開発日記

Astah*で、上流から、下流まで、トレーサビリティをもって開発する方法(7) - ウィリアムのいたずらの開発日記

設計手法は今までたくさん提唱されている。
構造化技法、データモデリング、プロセス指向分析(POA:別名は巻物分析)、オブジェクト指向モデリングなど。
データモデリングにも、TH法、T字形ER、渡辺式3要素分析法もあるし、オブジェクト指向モデリングにも、Rationa統一プロセス、ICONIX、アジャイルモデリングなどたくさんの流派がある。

今まで会ってきた日本のモデラーのお話を聞くと、彼らなりのモデリング技法というかスタイルを独自に持って、システムのあるべき姿を提示しようとしている。

個人的には、データモデリングも包含したオブジェクト指向モデリングができないか、探索している。
DOAもOOAもそれぞれに特徴がある。

DOAは、既存システムから仕様をリバース・エンジニアリングする時は最強の設計手法だ。
例えば、T字形ERがあげられるだろう。
既存の画面や帳票から、機能とテーブルを抽出し、CRUD図を作れば、既存システムの仕様がほぼ理解できる。
CRUD図があれば、元々の仕様を元に新たな設計書を作り出すことも可能だし、テスト仕様書にも応用できる。

OOAは、モデル間のトレーサビリティに特徴があると思う。
僕はアクティビティ図、ステートマシン図、クラス図を良く使うけれど、それらのUML図は、システムの一つの機能を複数の観点で表現したものと見なせる。
動的・静的な観点で表現する事で、モデルについてより深く考えることができる。

それら複数のUML図が一つのモデルを表現したものであるならば、それらのモデル間には相互に追跡できるということだ。
モデルのトレーサビリティがOOAではよく考えられていると思う。

【3】astahに可能性を感じるのは、複数のモデル間のトレーサビリティを補強する機能がチラホラあること。
astahでUMLの各種モデルを書いていると、ああ、こんな機能があるのか、と気付く時がある。
一つの使い方が、新たな設計手法を連想させる。

その辺りをまたまとめる。



| | コメント (0)

astahGSNのメモ

astahGSNが公開されたらしいのでリンクしておく。

【元ネタ】
astah* GSN - GSN支援ツール | Astah

astah* GSN - GSN支援ツール | Astah

GSN(Goal Structuring Notation)解説:An Agile Way:ITmedia オルタナティブ・ブログ

astah GSNを使ったゴール指向分析: プログラマの思索

GSN(Goal Structuring Notation)の使い道は、安全性などの議論の見える化、モデル化。
ディペンダビリティの分析に使う。

最終的には、UMLやSysMLと連携できれば有効に使えるだろう。
つまり、あるモデルとディペンダビリティに関する議論を相互リンクすれば、安全性に関する品質を追跡できる。

おそらく本当にやりたいことは、モデルとディペンダビリティを相互追跡可能とし、モデルの品質を上げることだろう。

最近、astahを使ったモデリングに着目している。
astahは割と安い有償モデリングツールの割りには、結構高機能で、色々使える。
その動向もBlogに記録していく。


| | コメント (0)

MVC2モデルとMVCモデルの違い

MVC2モデルとMVCモデルの違いについて、良い記事があったのでリンクしておく。

【元ネタ】
MVCをWebに適用した「MVCモデル2」 : Java好き

MVCモデルのバリエーション: プログラマの思索

(引用開始)
「MVC」と「モデル2」の違いが、「モデル」の設計に影響を与える

違いは、「モデル」が「ビュー」に状態が変わったことを通知することがWebの性質上なくなった点。

サーバー側からいきなり「モデル」の状態変更が通知されることは
HTTPではできないので、必然的にそうなる。

大したことのない変化に思えるが、これにともない「モデル」の構成が「MVC」と大きく変わる。

「モデル」が状態が変わったことを通知することができないことは、
毎回最新の状態のモデルを作ることにつながる。
「MVC」では前状態を保持しつつ状態変化に対応させるといった「モデル」の使い回しが可能だった。
しかし、「モデル2」では毎回最新の状態のモデルを作るので使い捨てになる。

この「使い回し」か「使い捨て」にするかにより、
モデルを構成する状態やメソッドの設計については大きく異なってくる。

「使い捨て」でよいので、「モデル2」ではDBから取ってきた値を保持するだけのオブジェクトが
必然的に増える傾向にあります。
(引用終了)

MVCモデルは、元来、Smalltalkでデスクトップアプリを設計する時の手法として生まれた。
モデルとビューを分離するだけでなく、モデルの状態の変更をビューに通知する仕組みも必要。
これがObserverパターンになる。

MVC2モデルは、Webアプリの設計において、データとUIを分離する時に、MVCモデルを参考にした設計手法。
Webアプリは基本はステートレスだから、モデルの変更をビューに通知する必要がない。
つまり、セッション接続中のみ、モデルは状態を保持すればよく、それ以外はモデルは状態を破棄して良い。

すると、Webアプリのモデルは、使い捨てになりやすいので、DBから取得した値を保持するだけの「値オブジェクト」がすごく多くなる。
DTO(Data Transfer Object)などがその典型例だろう。

ドメイン駆動設計」では「エンティティ」と「値オブジェクト」を区別する。
Webアプリでは、エンティティはRDBに格納されたデータと同一だ。
RDBのデータは、ただ一つの識別子で保持される。

だが、Webアプリのトランザクション処理の中では、値オブジェクトを使って、データをこねくり回す処理がほとんどだ。
エンティティから取得した値は、値オブジェクトとして使われるからだ。
DTOもそうだし、一時的に使われるリストやハッシュ、変数も値オブジェクトと見なしてもいいかもしれない。

MVC2モデルとMVCモデルはとてもよく似ているけれど、その違いは意識しておくべき。

| | コメント (0)

2014/07/05

出版システムや文書共有システムを作った事例

出版システムや文書共有システムを作った事例の資料が最近たくさん出ている。
以下リンクしておく。

注目点は、いくつかある。

1)GitHubやBitbucketを執筆データのリポジトリにする。
2)執筆データはMarkdownのようなテキストファイルで保存
3)ReViewやSphinxなどのツールでPDF・EPUBに変換する
4)定期的にビルドしてDropboxなどに配布する

昔は手書きの原稿用紙に書いて、その後、推敲して修正して、組版に載せていた。
僕も小学校の頃、ガリ版で卒業文集を書いた経験がある。

でも、今は、Wordでもなく、テキストに書いて、即座にビルドして配布する仕組みが普通だろう。
スマフォへ定期的にビルド&配布すれば、通勤や待ち時間でも、著作物をレビューできる。
そのフィードバックを受けて、著作物をさらに洗練させていくことができる。

執筆環境ももっとアジャイルになるべき。

| | コメント (0)

「採用基準」の感想~日本の根本問題はリーダーシップの総量が不足していること

採用基準」を読んだ。
本の中身は、優れたリーダーシップ論。
自分のキャリアを考えている人、プロジェクトリーダーや経営者のように、リーダーシップの能力を必要とする人にはとてもお勧め。
とても印象的だったので、ラフなメモ書き。

【1】ドラッカーの本ではいつも「マネジメントとリーダーシップの違いは何か。それぞれの本質は何か」という問いに対して、延々と議論されている。
採用基準」では、マネジメントとリーダーシップの違い、リーダーシップとは何か、を明確に提示している。

マネジメントとは、プロセス管理、予算や人材などのリソース管理、スケジュール管理などの管理業務。
PMBOKがその内容を明確に提示している。
課長職以上になれば、必要なスキル。

リーダーシップとは、問題に対しゴール(課題)を提示し、その課題に対する解決策を導き出す行為。
マネジメントとは全く異なる概念。
リーダーシップは、管理職だけでなく、あらゆる人に必要なスキル。
最近は、普通の人でも、リーダーシップが必要な場面が多くなっている。

学校のいじめ、保育所の少なさ、介護の問題から政治における問題に至るまで、問題解決のスキルだけでなく、問題解決リーダーシップが必要とされている。
その問題解決リーダーシップが、日本のあらゆる人に求められている。

リーダーシップの経験がない人は、チームや組織で自分勝手な行動を取りやすい。
チームや組織の中で、自分がどのような役割を求められているのか、チームのゴールを達成するには自分はどのような使命と役割が期待されているのか、をイメージできない。
だから、チームのゴール達成を阻害するような行動を取っても、それに気づかない。
リーダーシップの経験がない人は、人間的に未熟なのだ。

【2】日本が20年以上低迷している原因の一つは、日本でリーダーシップを発揮している日本人が少ないことを指摘している。
目の前に問題があり、それが解決されないのは、リーダーシップを発揮しようとする人が少ない、あるいは、リーダーシップを持っている人を支えようとする人が少ないために、同じ問題が延々と続いているだけなのだ。

たとえば、日本人のサラリーマンは、管理職になるまで、チームとして成果を出すことを求められない場合が多い。
日本における人事評価では、成果主義と言いながらも、赤字部門の社員に優劣をつけると、組織の和を乱してしまうために、オブラートにあいまいに評価する時が多い。
年功序列、終身雇用制度がその風潮を助長している。

特に、大企業になるほど、社会人5年目になるまでは、優劣を付けないという暗黙の了解があるために、若い時期からリーダーシップを発揮することは求められない。
すると、30歳を過ぎてもリーダーシップの経験がない日本人がいる。

このような人は、管理職として振る舞うべき年齢になったとしても、チームや組織を回した経験がないために、管理職になりにくい。
そんな人が管理職になれば、そのメンバーはむしろ不幸になる。

そんな人は無謀にも、自分の成功体験をメンバーに押し付けたり、根性論や精神論を押し付けたりする。
課長になってから「チームをどう回すべきか」考える人、社長になってから「会社をどう経営すべきか」を考えているようでは遅すぎる。

ビジネスリーダーへの キャリアを考える技術・つくる技術」では、このギャップを「マネジメントの断層」と呼んでいた。
ヒラの頃から、チーム運営のリーダーシップ、組織運営のリーダーシップを意識して経験しなければ、そのポジションに付けない。

チーム運営の経験が、今まで以上に、ビジネスの現場では要求されている。
SIでプロジェクトマネージャが必要とされていること、新卒募集でコミュニケーション力が要求されていること、というビジネスの事情は、リーダーシップを発揮できるリーダーを必要としている事実を示していると思う。


【3】「採用基準」には、経営コンサルタントの人材教育と言う観点から、リーダーシップに必要なスキルを明確に提示している。

・リーダーシップとは、成果を出すこと。
 リーダーシップは、努力やプロセスよりも、成果を出すことで評価される。

 日本では、社会だけでなくビジネスにおいも、成果が問われず、あいまいになっている。
 だから、リーダーシップの必要性、リーダーシップの認識すら薄い。

・目標を掲げる
 「あるべき姿」「ゴール」を提示すること。
 
 部長、取締役、社長などの人からレビューを受けると、「あるべき姿は何なのか」という質問が多くなる。
 その理由は、その解決策で問題が本当に解決されるのか、その後、どんなロードマップや理想像を持っているのか、を知りたがっている。
 更には、長期ビジョンでそこまで考えているのか、を評価しようとしている。
 この点は僕も最近痛感している。

・先頭を走る
 メンバーを奮い立たせて引っ張る能力。

・決める
 情報が不足している中で、リスクを引き受ける能力。
 「悪い決定は、何も決めないことよりも良いことだ」という格言がある。
 ベストな決断のために検討し続けるよりも、情報が少ない中で決断することには価値がある。
 「決める」ことにはいくつかの効果がある。
 
 一つは、「決める」ことで何かの問題を浮き上がらせる。
 決断で問題が噴出するのは想定内。
 決断を使うことで、逆に、問題の改善策を考える一つのきっかけを作り出す。
 この手法は、リーダーシップの意識が高い人ほど、よく使っているように思う。

・伝える
 単に、作業指示を伝えるだけではない。
 お金やモノがない中で、メンバーを奮い立たせるために必要。
 リーダーシップの意識が高い人ほど、コストのかからない言葉の威力を知っている。

【4】「採用基準」には、マッキンゼー流リーダーシップの学び方が提示されている。

・バリューを出す
 アウトプットを出すこと。
 チームに何らかの付加価値を与え、貢献すること。
 
 成果を出さないメンバーは、チームにダメージを与える。
 チームに貢献しないから、チームにとって、いてもいなくてもあまり関係ない。
 会議で発言しない人も、会議にバリューゼロの人。

・ポジションを取る

 自分の立場、意見を表明すること。
 あなたの意見は何か?
 あなたが意思決定者としたら、どう決断するのか?
 
 分析した結果よりも、結論が問われる。
 結論にフォーカスすることで、検討に必要な時間を大幅に短縮できる。
 つまり、徹底して仮説検証のスタイルなのだ。
 
 このやり方は拙速と思われる時がある。
 情報不足で曖昧な状況で、そんなに早く結論を出して決定しても、その決断した結果は正しくない、と。
 しかし、一度決めた後に、問題を噴出させ、対策を考えていくのは、新しいことを試す時の一つの手法だ。
 
 この点は、アジャイル開発に似ている。
 まずはアウトプットを出し、そのフィードバックを受けて、製品をより良いものにしていく。
 
 自分の立場を表明し、問題解決の着眼点や観点を提示し、結論に持っていく。
 この点は、コンサルタントという立場にいると、すごく分かる。

・自分の仕事のリーダーは自分
 組織の体制の一人ではなく、自分が中心となって、上司を巻き込んで解決すること。

・ホワイトボードの前に立つ
 会議の中でファシリテータの役割を担うこと。

こうして、リーダーシップを発揮するように期待される環境にいると、若手でも自然にリーダーシップが身につく。
リーダーシップは、後天的能力。
リーダシップは、場数の経験を踏めば、必ず身につく能力。

リーダーシップがメンバー全員が持つとどうなるのか?
リーダーシップ意識を全員が持つチームは、各個人の役割はメンバー自身がすぐに理解し、リーダーが指示をしなくても、自律的に動く。
チームのゴールさえメンバー全員が明確に共有すれば、そのゴールへの対策をメンバー自身が考え、調整し、動き出す。

この現象は、アジャイル開発の自律化、特にScrumにおける自己組織化に似ている。
認定スクラムマスター研修で感銘をうけたことの一つは、チーム(ここではスクラムチーム)にはプロジェクトマネージャーが不要であると言う主張だ。
メンバー自身がリーダーシップを発揮するならば、命令指揮系統がはっきりするようなチームは不要であり、むしろ妨害になる。

特に、ITプロジェクトのように、Web・アプリ・DB・インフラ・業務などの専門家からなるチームでは、個々のメンバーの能力が高いから、リーダーシップ能力を持つ人も多い。
そんなチームにはコマンドコントロールのリーダーは不要であり、メンバー全員がそれぞれの成果物を役割分担しながら作り、協調していく方が効果的。

【4】「採用基準」で面白いのは、リーダーシップ能力を持つ日本人、またはリーダーシップ能力を持たないが潜在的な能力を持っている日本人を見つけ出すのが難しい、と指摘し、その原因を分析していることだ。

・保守的な大企業で劣化していく日本人
 学生の頃は自由かつ大胆に思考できていた人が保守的な大企業で訓練を受けて、ヒエラルキーの中での立ち振舞い、自分の考えよりもヒエラルキーの枠内で思考するようになってしまうこと。
 すると、「目上の人に対し、どう振る舞うべきか」を叩きこまれるがゆえに、「上司の意見に反対しない」「立場を考えて発言すべき」と自重してしまい、ゼロベースの思考ができなくなる。
 
 また、大企業では赤字部門でずっと働いている人もいる。
 例えば、家電メーカーの赤字部門が典型的だろう。
 すると、「利益を出すこと=コスト削減すること」という常識にこだわりすぎて、ベンチャー企業や新興国でのビジネスのリーダーにはなれない。

 そんな人は、新卒の時に受けに来たら内定を出したかもしれないが、中途採用で受けたこの時点では採用は難しい、と判断される。

 この現象は、日本人の弱点だ。
 ビジネスだけでなく、学校教育、スポーツ、学術でも、「目上の人を敬うべき」という躾があるために、たとえ、目上の人の言動がおかしくても指摘できなくなる。
 また、ヒエラルキーが公的な場面だけでなく、プライベートや日常生活、議論の場にも出てしまうために、リーダーシップを発揮できるようになれない。

 「これから社会人になる人は、世界から見て周回遅れの常識やスピード感を、社会人としての基礎を作るべき最初の数年間に身につけてしまうリスクも、決して甘く見ない方がいいでしょう」という指摘は鋭い。

・東京大学の法学部よりも経済学部の学生の方がリーダーシップの潜在能力を持っている
・京都大学の学生はリアルなビジネス経験が少ないために、東京の大学生よりも劣る

 リアルなビジネスの現場を知ると、「今の自分は何者でもない」という危機感を覚え、行動が変わる。

・日本企業で成長しなくなってから転職しようとする人は決断が遅すぎる

 最初は、自分の能力の向上が感じられたのに、仕事に慣れてしまい、全力を出しきらなくても仕事できる期間が長くなると、知らないうちに保守的になる。
 大前研一氏は、35~50歳の日本人サラリーマンを「魔の15年」と呼んでいた。
 10年も同じ業界で仕事すれば、さすがに仕事の要領も分かってくる。
 そこから成長するには、管理職や経営者として働かなければ身につかないが、今はポストがないので、同じような仕事をずっと続けて、能力を腐らせてしまう、と。

【5】日本人にもリーダーシップを発揮できる人もいるが、リーダーシップを持つ人の全体数が少なすぎるために、問題解決が遅すぎる、と言われている。
だから「日本にはリーダーシップの総量が不足している」。

この事実は、おそらく最近になっていろんな形で意識され始めている。
日本を超えて世界でリーダーシップを発揮するには、英語力が必須。
今頃になって、日本でも小学校から英語を学ばせるか、百家争鳴になっている。

しかし、韓国人や中国人は、早期に英語の習得に躍起になっている。
その結果は最近すごく目立つようになっている。
たとえば、国連事務総長や世界銀行トップに、日本人よりも韓国人が就任したのはとてもすごいことだ。
たぶん、日本には、リーダーシップを発揮できる外交官や政治家が、その経済規模に比べて少なすぎるのだろう。

他にも、阪神大震災や東日本大震災のような危機でのリーダーシップ不足も身近に思い出される。

【6】では、リーダーシップはどのように身につければいいのか?
採用基準」では、リーダーシップの養成機関として、NPOでの経験をあげている。

NPOは、営利目的もなく、組織も小さい。
メンバーには、その人の社会的地位や財産、役職も関係ない。
「自分が実現したい」と思う人達が集まり、リーダーシップを発揮したいと思う人が自然にリーダーとなる。
その人は自然にリーダーシップ能力を身に付けて、自分が解決できる範囲を広げていく。
そんなリーダーを若手も見ながら、その人をロールモデルと見て、若手も成長していく。

僕は、IT勉強会が、単なる技術知識の共有の場だけでなく、リーダーシップ養成の場にもなっていると考えている。
昨今のIT勉強会ブームは凄まじい。
しかし、社外のIT勉強会に出ている人は、リーダーシップを発揮したい、リーダーシップを身につけたい、と思う人は当初はいないだろう。

実際にコミュニティ運営をするには、同志を集め、コミュニティのゴールを決め、役割分担を決めて、行動していくしかない。
コミュニティでは、大手SIにいる、とか、部長や課長である、とか、社長で財産がある、最年長である、とか全く関係ない。

逆にコミュニティの場に、会社の役職のヒエラルキーを持ち込んだり、自分の財産や他人の財産を使ってお金を用いるようにしたら、他メンバーから非難されるだろう。
コミュニティは、そんな人だけのモノではなく、メンバー全員のモノだからだ。

むしろ、メンバー自身の能力や人格が信頼されれば、そのコミュニティでリーダーシップを発揮できるようになる。
会社では役職が低く、リーダーシップを経験できない現場にいたとしても、コミュニティでは別だ。
逆に、コミュニティでリーダーシップ能力を経験することで、その能力を会社で生かすこともできる。

昨今は、ITの技術革新の場が大企業の研究所から、オープンソースに移ったこともあり、コミュニティの運営能力の比重がすごく高まっているように思える。
おそらく、その事実を暗黙的に認識している技術者が最近増えているから、昨今のIT勉強会が増えていると思っている。

実際、関東でも関西でも、ITコミュニティに顔を出し始めた人が急激に頭角を伸ばし、能力だけでなく、IT業界全般に影響力を与えるようになった事例が多くなっている。
自分の周囲でもそんな人がすぐに思いつかないだろうか?

その理由は、ITコミュニティで、自分と同レベルの技術者と研鑽しただけでなく、コミュニティ運営や、大人数の前での発表、議論などの経験を通じて、その人の人間的スキルが急激に伸びたからだろう。

僕自身は、日本人は決してリーダーシップの能力が先天的に不足しているのではなく、リーダーシップの経験値が低く、その認識がないことが原因であると思っている。
そして、ITコミュニティはリーダーシップ育成の場にもなるだろうと思う。
だからこそ、社内に閉じこもるのではなく、社外のITコミュニティへ積極的に参加すべきだと思う。

| | コメント (0)

« 2014年6月 | トップページ | 2014年8月 »