« 2014年3月 | トップページ | 2014年5月 »

2014年4月

2014/04/29

「研究室リテラシー教育スライド」~学生からビジネスマンに変身するためのアドバイスが書かれているスライド資料

学生からビジネスマンに変身するためのアドバイスが書かれているスライド資料が素晴らしいのでメモ。
山根英次さんが「研究室を現場と置き換えてもなんら違和感がないですね!」と言われていたが、本当に同感。

僕自身、学校教育に染まりすぎて指示待ち人間だったから、そこから脱却するのにかなり時間がかかった。
ビジネスマンになれば、基本はアウトプット指向。
仕事であれ、コミュニティでの発表、本の出版にせよ、いずれも自分が行動した結果、自分が経験して得た実践知が基本にある。
社会人の成長は、日々の経験から得られた知識と呼ばれる。

教科書から得た知識がそのまま仕事に生かされるわけでもないし、そんな知識をコミュニティで発表しても、自分で記事や本を執筆しても、当たり前の話に過ぎない。
他人が知らない「自分だけの体験に基づく現実」にオリジナリティがあるのであり、そこから抽象化された形式知に重要な意味がある。

「自分で考える」ことは重要だが、「自分の過去の体験から自分だけのベストプラクティスを見つけて整理していく」事の方がはるかに重要だと思う。
なぜなら、考える材料は自分が現在知っていることの一部であるから。
つまり、自分が体験している範囲内でしか物事を考えることはできないから。

このような経験から知識を得る思考サイクルは、コルブの「経験学習モデル」として既に理論化されている。

デービッド・コルブの「経験学習モデル」:現場での学びを蓄積して「持論DB(データ・ベース)」:今いる社員を収益を生む考え方と行動に変える「考動知図」

教科書から知識を得るのではなく、経験から知識を得る場合、「経験→省察→概念化→実践」というサイクルから生まれる。
そのサイクルを意識して実践すべきなのだろう。
個人的には、経験学習モデルはKPTの流れによく似ていると思う。

| | コメント (0)

「挫折しないRedmine」の資料が分かりやすい

@g_maedaさんの講演資料「挫折しないRedmine」が分かりやすいのでメモ。

僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。
ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。
最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。

上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。

アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。
すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。

この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる。
僕も以前に、Redmineのアンチパターンやチケット管理の癖について色々書いたので、ご参考ください。

【公開】RedmineのFAQとアンチパターン集 #Rxtstudy: プログラマの思索

チケット駆動開発を上手に運用するためのポイント: プログラマの思索

TiDD初心者から必ず聞かれる質問~「チケットの粒度」と「チケットの完了条件」 #47redmine #redmine: プログラマの思索

Redmine導入でいつも問題なること~ワークフロー管理とDoneの条件: プログラマの思索

Redmineの初心者向け資料: プログラマの思索

Redmineを使ってみよう~No Ticket, No Work #tidd : プログラマの思索

【追記】参考になるTwitterを見つけたのでメモ。

Twitter / kamayan1980: Redmineに限らず、タスク管理ツールは「自分たち用にツールをカスタマイズする」のではなく「ツール用に自分たちをカスタマイズする」という努力が必要になる。 / “「挫折しないRedmine」の資料が分かりやすい: プログラマの思索” http://htn.to/CKy2t

Twitter / kamayan1980: 弥生会計でもRedmineでもWordPressでも。ソフト側が想定している『使い方』に全のっかりした方が、すげー楽です。それがBest。でも、そうはうまくいかないから、『導入』というお仕事が発生するし、それ用のスキルが必要になる。

ツールを導入する時、自分たちの現場のやり方にツールを合わせるよりも、ツールの機能に合わせて、自分たちのプロセスを変化させる方が効果は出やすい。
業務システムの導入・運用も全く同じ発想だ。

業務パッケージ製品をユーザ企業が導入した場合、自分たちの会社に合わせてカスタマイズし過ぎると、従来の業務プロセスのままになり、業務の抜本的改善の効果が出なくなる。
カスタマイズしすぎると、業務の局所最適化になってしまい、本来の業務の全体最適化にならないのだ。
カスタマイズの範囲と運用の容易さはトレードオフの関係にある。

| | コメント (0)

2014/04/28

オープンソースの業務アプリケーションを組合せてERPを構築するアイデア

オープンソースERP idempiereと他のオープンソース業務アプリを組合せると、ERPを構築できるアイデアが公開されていたのでメモ。

【参考】
Twitter / HideakiHagiwara: 大幅に加筆しました。
他のOSSと連携してコストを最小限に抑えたIT経営の促進!! http://www.compiere-distribution-lab.net/compiere-distribution-%E3%81%A8%E3%81%AF/%E6%B4%BB%E7%94%A8%E3%81%AE%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88/%E4%BB%96%E3%81%AEoss%E3%81%A8%E9%80%A3%E6%90%BA%E3%81%97%E3%81%A6%E3%82%B3%E3%82%B9%E3%83%88%E3%82%92%E6%9C%80%E5%B0%8F%E9%99%90%E3%81%AB%E6%8A%91%E3%81%88%E3%81%9Fit%E7%B5%8C%E5%96%B6%E3%81%AE%E4%BF%83%E9%80%B2/ …
#idempiere #erp #オープンソース #oss

他のOSSと連携してコストを最小限に抑えたIT経営の促進!! - OSS ERP Compiere Distribution Lab

【その他】無料のOSS-ERPを売るためには - OSS ERP Compiere Distribution Lab

(引用開始)
そう考えると、今後オープンソースの業務アプリケーションを上手に活用しコスト削減していく事が、企業の生き残り戦略のひとつになるのではないかと思います。言い換えれば、OSやミドルウェアでオープンソースの活用が当たり前になってきているのと同じように、オープンソースの業務アプリケーションを活用するのが当たり前になる時が遠からず来ると思います。
 オープンソースの業務アプリケーションを上手に活用する事も「他がマネのできない付加価値の高い物やサービスを提供する事」と同様に、簡単にできる事ではありませんが、両方とも企業が生き残るために取り組まなければならない課題なのではないかと思います。
(引用終了)

業務アプリのパッケージ製品を購入して導入・運用する場合、いつもネックになるのが保守サポート。
パッケージ製品元が突然、製品の寿命がなくなったので保守サポートを切り捨てます、と言い出すリスクがある。
業務パッケージ製品を一度導入したら、ユーザ企業はそう簡単に廃棄することはできない。

普通は減価償却に5年はかかるので、最低でも10年ぐらい使わないと元が取れない。
また、他の社内システムとバッチ・SOA連携したり、パッケージ製品の一機能を使ったアプリの改造をしたくなるので、余計にコストもかかってくる。

でも、idempiereのようなオープンソースERPを導入すれば、業務アプリの基盤として使うことができる。
つまり、オープンソースのERPないし業務アプリをフレームワーク(開発基盤)とみなして、自分たちのシステムをどんどんカスタマイズしたり、機能拡張していくパターンが使えるのだ。

この利点は、開発基盤がオープンソースなので、保守サポートを気にせずに長期間使い続けられる。
逆に弱点は、ユーザ企業に技術力がなければ、開発基盤のメンテナンスやカスタマイズによるスクラッチ開発が自力ではできない点がある。

特に、現在の日本のユーザ企業は、ソフトウェア開発者を大切にしていないので、自社で開発できる技術力がほとんどない。
外部ベンダーに丸投げしているために、自分たちで要件定義もできないし、最悪なケースは、自社の利用部門の調整すらも外部ベンダーに丸投げして任せている時もある。

上記の記事を読むと、オープンソースERPを中心に、SugarCRMのようなCRM、BIツール、人事システムなどのオープンソースの業務アプリををI/Fする仕組みで、一企業の社内システムをすべてオープンソースで実現できる事例があるようだ。
個人的にはとても興味深い。

似たような発想として、僕も、Redmineを中心としたプロジェクト管理サーバーをオープンソースのツール(TestLink、Jenkins、StatSVNなど)で固めるアイデアを持っていた。
今なら、Redmine+Jenkins+Gitで一通りの構成管理インフラが整うだろう。

プロジェクト管理サーバーとは: プログラマの思索

アジャイル開発の弱点をプロジェクト管理サーバーが助ける: プログラマの思索

チケット駆動開発が進むべき道 part3~BTSを中心に構成管理・テスト管理を含めたプロジェクト管理の枠組みを作る #tidd: プログラマの思索

僕は、オープンソースのツールを使って、業務プロセスやソフトウェア開発プロセスを改善ないし変革する手法が好きだ。
ソフトウェアは単なるツールではない。
ソフトウェアを導入すれば、運用が変わり、不要な人員や役割が削除されて組織も変わり、人の行動すらも変わっていく。

ツールで業務改善やプロセス改善するアイデアを色々探ってみる。

| | コメント (0)

2014/04/27

【公開】XP祭り関西2014講演資料「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」 #xpjugkansai

XP祭り関西2014が無事に終わりました。
参加者やスタッフの皆さん、お疲れ様でした。

私の講演資料を公開します。

【参考】
XP祭り関西2014 - XPJUG関西wiki

【1】今回の講演では、KPTによるプロセス改善の経験談を中心に話しました。
私の立場として、最近はRedmineエバンジェリストと思われる時が多く、プロジェクト支援を依頼される時が多い。
なので、各プロジェクトを横断して、PMOの立場で、プロジェクトリーダーの管理を支援する場合が多いです。

そんな立場でプロジェクトを見ていると、うまく回っていないプロジェクトには幾つかの共通点がある。
真っ先に分かるのは、このプロジェクトリーダーは、PDCAサイクルを回した経験を持っていないから、チーム運営をコントロールできていないな、という点。

【1-1】PGあがりのPLには幾つかの落とし穴がある。
1点目は、何らかの計画書を作った経験がないこと。
例えば、WBSを作ったことがないので、目的や方法を知らない。
すると、行き当たりばったりで作業していることになる。

普通は部課長レベルになれば、彼らの仕事の殆どは、プロジェクト計画、部課の予算計画などひたすら計画書を作るのがお仕事。
マネージャレベルならば、このレベルはクリアしている。

【1-2】2点目は、作業指示ができないこと。
人は指示するだけで動くわけではない。
プログラマあがりのPLにありがちなのが、指示は出すけど、指示の目的や意図や期待する結果を伝えていないために、担当者のアウトプットが想定と違ってしまうこと。
そんなことが続くと、自分でやった方が早いから、PLが作業を抱え込んで破綻するケースが多い。

【1-3】3点目は、予実管理できてないこと。
マネジメントでは、当初の予定と実績を比較して、その差異をみつけて、変化に合わせて状況をコントロールしていく。
しかし、臨機応変に対応できてない。
この部分は、Redmineによるチケット駆動開発など、ツールでカバーできる部分がある。

【1-4】そして4点目は、「カイゼン」の経験がないこと。
ここで「カイゼン」は継続的に改善するという意味で、カタカナで表現している。
実は、部課長レベルでも、カイゼンの経験がない人は以外に多い。
その人達がよく言うのは、「これだけお膳立てしているのに、なぜ皆は変わらないんだ?」というフレーズ。
現場の状況に合わせて改善して効果を上げるのは、それなりのテクニックを必要とする。

【1-5】「これだけ! KPT」に書かれているように、改善サイクルを1年ないし3ヶ月のような長期スパンで回すのは至難の業だ。
むしろ、1週間~4週間のように短い期間で、どんどんPDCAサイクルを回して改善して行く方がやりやすい。
この点は、アジャイル開発をやっているチームの方がカイゼンにすごく向いている。

逆に、WF型開発に囚われすぎているチームは、カイゼンがとてもやりにくい。
KPTを実施するタイミングがプロジェクト完了時しか取れないので、せっかくチームの一体感が生まれてもチームは解散してしまう。
KPTで得られた知見をチームの成長に使えない弱点がある。

KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai: プログラマの思索

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy: プログラマの思索

【2】今回の講演では、僕の実体験「チケット駆動開発を始めた頃」「炎上プロジェクトに火消しPLで支援」「炎上プロジェクトにPMOで支援」について、KPTを実施して得た知見を話した。

ポイントはいくつかある。
資料に詳しく書いたので、読んで下さい。

・KPTはCAPDで回す
・SECIモデルで暗黙知を表出・内面化
・KPTは経験学習モデルに似ている
・KPTの良い兆候
・【反例】ベクトルがバラバラのチーム
・【反例】1回だけのKPT
・意見を出すためのフレームワーク
・【反例】コンフリクト
・タックマンモデルでコンフリクト解決
・【反例】残り続けるProblem
・フォースフィールド分析でProblemを考える
・【反例】期待過剰
・Will-Skillモデルでチームの成熟度診断

まとめると、こんな感じ。

【2-1】KPTでPDCAサイクルを回そう
・「チームに変化を起こす」ことを心がける
・「暗黙知にする」流れを意識しよう(SECIモデル)
・チームの経験からプラクティスを編み出す流れを意識しよう (経験学習モデル)

【2-2】KPTでチーム内の力学が分かる
・コンフリクトはチームビルディングのチャンス(タックマンモデル)
・推進力を強め、抑止力を弱める(フォースフィールド分析)
・成熟したメンバーは動機付けor委任で回る(Will-Skillモデル)

Twitter / Uemmra3: あきぴーさんの経験から、組織をうまくまとめるのには潜在的な衝突を早めに出してあげて、つまらない障害を早く乗り越えてチームをまとめる。タックマンモデルというらしい。 #xpjugkansai

【2-3】KPTは日本人のチームに向いている
・ほとんどの日本人は、自分の意見を表明する行為に慣れていない
・意見表明に慣れていない人からKPTで本音を引き出す

【2-4】KPTのタイミングに注意しよう
・WF型開発はふりかえりするタイミングが取りにくい

【3】懇親会で感想を聞いたら、プロジェクトリーダーや管理職以上の方には、気づきが多かったらしく、参考になったという意見をもらえて嬉しかった。
ただし、チーム運営の経験がない開発者には、遠い世界の話に聞こえたらしく、その点は反省点かもしれない。

| | コメント (0)

2014/04/23

KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai

XP祭り関西2014で「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」を講演する予定ですが、一部の資料が余ってしまったので、プレ資料として公開します。

【参考】
XP祭り関西2014 ~やってみよう!XP~ - 日本XPユーザーグループ関西 | Doorkeeper

XP祭り関西2014 - XPJUG関西wiki

XPやScrumなどのアジャイル開発をやった経験がある人なら、KPTと言えばすぐに分かるだろう。
そして、ふりかえりも実際に経験したこともあるだろう。

僕も、プロジェクトファシリテーションの流れから、KPTとふりかえりを実際に試してみた経験がある。
その経験から、PDCAサイクルとはこういうプロセスなのだな、という感覚がつかめたように思う。

そして、周囲のプロジェクトリーダーや部課長などを見ていると、この人はPDCAサイクルを回した経験が無いんだな、と思う時もあった。
そんな人は、チームを動かしたり、もっと大きな組織を動かしたという経験がないのだろうな、と思う。

作業を指示したからといって、人は動くわけではない。
エンジニアのように、技術の専門家に対して、部課長が上から指示を出して、それでシステムが完成するわけではない。

また、そんな人に限って、計画をきちんと作ったとしても、その計画を現場に当てはめて、微調整しながらコントロールしたことがない。
無理やり、チームや組織に当てはめようとするから、現場の人はサボタージュしたり、服従背面の行動をとったりする。

そんな現場では、いわゆる継続的な改善というプロセスが存在しない。
だから、いつまで経っても、チームも組織も成長しない。
同じような失敗を何度も繰り返す。

これだけ! KPT」にも書かれているが、PDCAサイクルを回すのは至難の業だ。
1ヶ月や3ヶ月という長いスパンでPDCAサイクルを回すのは、たとえ少人数のチームでも、結構難しい。
PDCAサイクルを回した経験がないプロジェクトリーダーや課長が上に立っていたら、もっと最悪だ。
毎日がデスマーチ。

KPTの良さは、PDCAサイクルを自然に回す仕組みが整っていること。
プログラマ上がりで、マネジメントの経験が短い人でも、KPTでチームを回すことは可能だし、簡単にできるのがいい。

但し、KPTには結構コツがある。
そのコツをKPTのアンチパターンとしてまとめみた。

詳細を聞きたい場合、XP祭り関西2014 - XPJUG関西wikiにぜひ聞きに来てくだい。

| | コメント (0)

2014/04/21

「Working In Progress」な WIP Pull Request ~Github-flowの新たな使い道

「Working In Progress」な WIP Pull Request という概念を知ったのでメモ。

【元ネタ】
Github を使って雑誌原稿を書く - naoyaのはてなダイアリー

git commit --allow-empty を使った WIP PR ワークフロー - Qiita

WIP (Work in Progress) な Pull Request を目立たなくする Chrome 拡張をリリース - @kyanny's blog

非開発者もGitHub Flowに巻き込んでみんなハッピーになった話 - Masatomo Nakano Blog

github を用いた開発フロー テンプレート

pull request を利用した開発ワークフロー // Speaker Deck

「Working In Progress」な WIP Pull Request とは、ソースのパッチを書き上げた所でPull Reuqest するのではなくて、いきなり Pull Request を出してしまって、そのあとはその Pull Request に、コーディングの進捗に合わせてコミットしていくやり方らしい。

WIP PR とも略されるらしい。

この手法の良い点は、PullRequestする対象のパッチが完成していなくても、まずは送れば、そのやり取りがチケットのコメントのように記録されることだ。

(引用開始)
作業途中のトピックブランチを PR することによって

・早期にコードレビューのプロセスをまわせるので仕様誤認や設計不備があった場合の修正コストが比較的低い
・修正コストが低いため、レビュワーも気兼ねなく指摘することができる
・実装完了後のコードレビューだと「ここはもう少しこうしたほうがいいけど、スケジュールも詰まってるしすぐに問題になることはなさそうだから今回はこれでいいや…」となりがちです
・作業に着手した段階で PR が作成されるので進捗を追いやすい / 他のメンバーが何をやっているか可視化される

といったメリットがあります。
(引用終了)

WIP PRという言い方も絶妙。
つまり、仕掛中(作業中で未完成)のパッチを送って、お互いにそのパッチについて、議論しながらパッチを改善していくわけだ。
まさに「仕掛中(WIP)」なわけだ。

普通のパッチ送付ならば、不完全なパッチは送られても正直困る。
レビューもできないし、無駄な時間がかかるだけ。

しかし、WIP Pull Requestは、Pull Requestの行為そのものがチケットの機能と一体化しており、Pull Requestのやり取りが時系列に記録される。
そのおかげで、当人同士も情報共有できるし、パッチのやり取りが全員に公開されるので、進捗も分かりやすい。

WIP Pull Requestの機能を振り返ると、チケットよりもかなりラフというか、アバウトな感じだ。
もっと気楽にやり取りして、masterにある成果物を成長させる。

チケット(Issue)という概念は、もっと厳格なものだ。
ステータスによって完了条件がはっきりしているし、ステータスの遷移によるワークフローも厳格に定義できる。
でも、その厳格さが面倒という声もよく聞く。
WIP Pull Requestなら、チケット管理すべきほどでない場合に使える。

WIP Pull Requestの場合、仕掛中のプルリクエストがOKだけでなく、そのチームでWIP制限(仕掛り制限)を設ければ、無駄な作業を減らすような運用も可能かもしれない。

GitHubを見ていると、単なるコーディングだけでなく、原稿を書くという行為に携わる人は全員慣れた方が良いのだろうと思ってくる。
生産性が全く違ってくるわけだ。
そして、GitHubが普通の人にも普及するようになれば、法律や文学などのお固い分野も大きく変わるだろうと直感する。

GitHubによるソーシャルコーディングが法律や出版物を変革させる可能性: プログラマの思索

| | コメント (0)

2014/04/15

システム投資のパターン~SI案件以外のビジネスモデルは何があるのか

システム投資のパターンをまとめてみた。
自分が業務システムを購入する立場ならば、高価で使いにくいし、中身がブラックボックスなので、購入には躊躇するだろうと思う。
ラフなメモ書き。

【0】業務システムの投資には、3つのパターンがあるように思う。
「ユーザ企業の資産」「ユーザ企業のリース資産」「ユーザ企業の利用料支払い」の3パターンについて、以下に考えを書いてみる。

【1】ユーザ企業の資産:普通のSI開発

【1-1】発注元はSIにシステム開発を委託し、SIが受託開発していくパターン。
通常の受託開発案件であり、一番事例が多いだろう。
納品されたシステムは、運用後に数年かけて減価償却される。

発注元(ユーザ):資産、受託先(SI):売上として計上される。

SIから見れば、受託開発のプロジェクトさえ黒字で完了できれば、運用保守費用で毎月売上が計上されるので、安定的な収入源になる。
だから、SIの受託開発案件は、ソフトウェア開発の界隈では主流のビジネスなのだろう。

【1-2】しかし、この投資パターンは、発注元が最終的に大きなリスクを背負う。
開発を委託したシステムが実は性能が悪くて使い物にならなかったり、一番重要な仕入先や会計システムとのシステム連携ができていなかったり、想定していた要件とは違うシステムで納品されたり、など、たくさんの失敗事例がある。
発注元のプロジェクトマネージャが、システム投資の目的を常に忘れないように、その目的からシステムの機能の優先度を決めていかなければ、すぐに機能は肥大化する。
そして、システム開発で一番重要な要素であるリリース時期に間に合わなくなる。

だから、発注元も最近は経験してきて、このパターンで本当に投資対効果(ROI)があるのかどうか、計画段階から厳しく精査するようになってきたように思う。

業務システムを運用した場合、利用者は何人か、システム運用によって一人当たり何分だけ省力化されるか、どれだけ人員を減らせるか、という観点で、投資したコストをどれくらいの期間で回収できるか、計算する。
あるいは、会計帳票をペーパーレス化することで、紙として保持する倉庫代金が減らせる、などで計算するときもあるだろう。

そこで、実際に計算してみると、業務システムの投資対効果には5~10年かかるのが普通だ。
普通は数千万~数億円(あるいはもっと上)の開発案件なので、3年くらいで元が取れるわけではない。
すると、モバイル・クラウド・ビッグデータのバズワードのように次から次へと技術革新される現状では、10年前のシステムはその価値がすぐに陳腐化してしまう。
3年前に作ったシステムはもはやガラクタと同じレベルになってしまうのだ。
だから、発注元も、システムを資産として保持するリスクをよく考えてきている。

【1-3】SIの観点でも、受託開発案件の旨みが最近は少ないように思う。
受託開発案件の成功率が低すぎるのだ。
たぶん、半分以上は赤字でカットオーバーしているのではないだろうか。

その原因は色々あるだろう。
発注元の仕様スコープを制御できず、スコープクリープしてしまい、開発工数が当初の見積りよりも大幅超過してしまった。
最新のフレムワーク、モバイル・クラウド・ビッグデータなどの最新技術を使いこなせず、当初の想定通りに開発できなかった。
当初想定していなかった非機能要件、システム連携でリスクが発生し、工数がオーバーした。

普通に考えれば、前回の開発案件で使用したライブラリやフレームワークを流用するなどの対策を取れば、SI案件は成功しやすいはずだ。
以前の顧客に提供した業務パッケージ製品があれば、新規顧客にはそれを多少カスタマイズするだけで同じくらいの値段で売上が取れるはず。
フレームワークや部品の再利用ができれば、元々、運用品質が担保されているだけでなく、ソースの保守もやりやすいはずだ。

しかし、現状はそうもいかない。
SIが作ったパッケージ製品の著作権はSIにあっても、発注元企業へ納品した時に、カスタマイズした機能の著作権がSIの手から離れると、その部品を流用できなくなる。
あるいは、フィットギャップ分析してみると、パッケージ製品をカスタマイズすると一から新規のシステムを作っているのと同じくらいのコストがかかることが判明する時もあるだろう。

だから、SIは、受託開発する時にどのような手段を使って開発するか、アーキテクチャ設計が以前にも増して重要になっているように思う。

【1-4】SIの受託開発案件の旨みが最近ないのは、カットオーバー後の運用保守費が以前よりも元が取れなくなっている場合があるからだと思う。

発注元企業がうまく難癖をつけて、SIへの運用保守費に、システムの減価償却費用を上乗せして来る場合があるからだ。
発注元が要件を出したのに、SIが納品してきた業務システムは使い物にならず、作り直しの期間は運用保守費を削減されたり、運用保守費用に使いものにならない機能の費用(つまりその機能の価値)を上乗せして削減されたりするのだ。

SIが無事に納品できれば問題ないが、受託開発案件の成功率が低いため、元々赤字なのに、ユーザ企業から難癖をつけられて更に赤字になってしまうパターンがあるのだ。

【2】ユーザ企業のリース資産:SIから貸し出された最新版のパッケージ製品

【2-1】発注元:リース負債、受託先:リース資産のパターン。
SIから貸し出された最新版のパッケージ製品の例が多いだろう。
あるいは、開発用PCやサーバーのように、3年で陳腐化する場合、リース資産として契約し、契約終了後はまた新しいハードウェア機器を納入する例もあるだろう。

このパターンの利点は、発注元は常に最新版の製品を資産として使用できることだ。
つまり、システムやハードウェアの更新サイクルが短い場合、リース資産として購入した方が元が取れやすい。

【2-2】SIの観点でも、リース資産はとてもありがたい。
SIが開発した製品なので、その製品はSI企業で資産として計上されるから、減価償却が発生する。
その分、多額の費用が数年かけて発生するわけだ。

ただし、発注元にリース資産として貸し出しているので、発注元からリース料として、売上代金を毎年支払ってもらえる。
投資リスクは発注元企業が背負っているわけだ。

【2-3】しかし、業務システムにリース資産のパターンが使えるかどうかは分からない。
業務システムの運用期間が10年以上の長いスパンならば、リース資産にした場合、発注元は減価償却が発生するだけでなく、その費用をSIに支払わなければならない。
発注元の資産としての減価償却なら、費用が発生しても、その費用を他者に支払う必要はないのに。

おそらく、リース資産のパターンは、少額であり、短期間で元を取りたい場合に適用される場合が多いだろうと思う。

【2-4】AWSに業務システムを乗せるようなクラウドの場合、リース資産として扱う事例も増えるのではないか、と想像している。

クラウド上に業務システムを乗せられるならば、システムの移植性が高いため、ハードウェアの性能向上がやりやすいし、別のサーバーに載せ替えることも可能だ。
しかも、システムの移植性が高いということは業務システムの複製がやりやすいということなので、古い業務システムから新しいシステムへの入れ替えもかなり簡単になるはずだ。

例えば、「ブルーグリーン・デプロイメント」を使って、古いシステムの背後で新しいシステムへの移行作業を実施しておき、移行作業が完了すればすぐに新しいシステムへ切り替えればいいだろう。
つまり、クラウドの手法を上手く使えば、業務システムのバージョンアップを増やして、システムの寿命を長持ちさせることもできる。

今後の研究テーマになるだろう。

【3】ユーザ企業の利用料支払い:SaaS

【3-1】発注元はシステムを持たず、SIからシステムを必要な時に借りるパターン。
発注元:費用、受託先:資産のパターン。

発注元は利用した分だけ支払えば良い。「資産」として抱える必要がないので身軽。
経費扱いなので少額なら決裁権限が不要。

最近は、SaaSの事例が多い。
特に、中小企業のように、自前の業務システムを多額の費用をかけて導入することができない環境では、SaaSのように資産として保持しない方がありがたい。
また、SaaSの利点は、システムのバージョンアップが多いので、最新の機能を早く使えることもある。
自分でカスタマイズしなくても、製品元が機能改善してくれれば、その恩恵を受けられる。

【3-2】SIの観点では、SaaSの製品はSIの「資産」なので減価償却になる。
利用者が増えれば売上増だが、利用者が少なければ投資対効果が得られず赤字になるリスクが大きい。
つまり、投資リスクは受託先企業が背負っている。

一番のポイントは、SaaS利用料の決め方。
SaaS利用料が高ければ、利用者は増えない。
かと言って、SaaS利用料が低くても、投資コストが回収できない料金体系は意味がないし、低い利用料金に見合ったユーザしか集まらない。

SaaSの料金体系の決め方は難しい。
当初の計画通りに利用者が増えなければ、赤字が累積するだけだ。

おそらく、AIDMA、AISAS、AARRRのようなマーケティング手法をもとに、ABテストを実施しながら試行錯誤するしかないと思う。

AIDMA - Wikipedia

「AARRR」 今更だけど絶対抑えておくべきグロースハッカーのコンバージョンの見方 | グロースハックジャパン | growth hack japan

【3-3】今後は、SaaS形式の業務システムが増えてくると思う。
従来の業務システムは、SI案件が多く、多額の投資が必要だった。
そのために、そのマーケットは大企業に限られていた。

しかし、SaaSという技術がクラウドによって可能になり、中小企業にも業務システムを使えるという恩恵が受けられるようになり、マーケットが広がった。
中小企業の利用者も利用料も少ないかもしれないが、潜在的なマーケットであるし、未開拓なマーケットだ。
しかも、スタートアップの企業もSaaS技術さえ操ることができるなら参入しやすい。

【4】まとめ

普通のSIに勤めていると、受託開発案件のビジネスモデルしか知らない。
でも、最近はクラウドという新しい技術のおかげで、リース資産やSaaSのようなビジネスモデルも作り出せる。
この新しいビジネスモデルは、特にベンチャーのスタートアップ企業が特に盛んに試されているように思える。

ソフトウェア開発のビジネスモデルは、いったいどれくらいのパターンがあるのか。
僕は今この3種類しか知らないけれど、まだ他にもあるだろう。
色々調べてみたい。

| | コメント (0)

組織的な阻害要因は欧米人と日本人で問題の観点が異なる

組織的な阻害要因は欧米人と日本人で問題の観点が異なる指摘があったでのメモ。

プロマネBlog: 日本型パターン その1

プロマネBlog: 日本型パターン その2

(引用開始)
そして先に揚げた日本のプロジェクトの大規模なトラブルの例に、共通のパターンがある事がある事がよく話題にのぼります。

そのパターンというのは、これらのプロジェクトは共通して、細かい項目はかなり精査され綿密に計画されるのに対し、それらの上位項目である中項目や大項目が決定されないままであり、従って詳細項目も暫定的なものにならざるを得ず、その上位項目の決定がどんどん遅れていき、最後に破綻に至るパターンです。
このパターンは、むしろ日本固有と言って良いと思います。
これは、このパターンが日本でしか見られないと言う意味ではなく、このパターンが分野を問わず日本の組織に広く遍在し、かつ省みられることなく何度も繰り返される、と言う意味で日本固有です。

欧米人と日本人で異なる見え方

このパターンに対し欧米人と日本人では異なる見解を示します。
欧米人のコンサルタント達は、これは能力の問題というとらえ方をします。
彼らの目には、日本の組織は、ポジションが上がるにつれ、そのポジションに就く人間のマネジメント能力が劣って行く様に映ります。
つまり、ポジションが上がるにつれ、そのポジションに要求される決断力やリーダーシップ、場合によっては政治力が欠落して行く様に見えます。
現場で求められる能力と、上位のポジションで求められる能力は、明らかに異なる訳ですが、日本の組織は往々にして、後者の能力がポジションが上がれば上がるほど欠落していくように彼らには映るらしいのです。
また逆に、外国人コンサルト達は、異口同音に、現場レベルの人間達の優秀さに驚くと言います。
破綻したプロジェクトの中で、現場レベルの人々が何とか問題を収拾しながら、曲がりなりにも解決して行く能力は驚嘆に値すると言います。

一方、日本人のコンサルタントには、このパターンは、能力の問題とは映らず、むしろ組織に戦略眼、戦略の視点が欠けている事に問題を感じます。
また、能力に関しては、欧米に比べ、組織全体がかなり均質的である様に感じる傾向があります。
(引用終了)

スクラムを積極的に推進していくと、最終的には「組織的な阻害要因(Organizational Impediment)」にぶちあたると言われる。

例えば、スクラムによって、チームはソフトウェア開発プロセスをどんどん改善していくので、プロセス改善を妨げる問題を共有し解決しようとしていく。
すると、組織に対して、プロセスの進化や問題解決のための変革を実施するよう、継続的にプレッシャーを与え始める。

組織にとって、1つのチーム内のプロセスが改善されて効率化されるのは良いが、それが組織の階層構造や組織のルールにまで文句を言い始めてくると、組織とチームで軋轢が生じる。
この症状が「組織的な阻害要因(Organizational Impediment)」になる。

上記の記事では、組織的な阻害要因は欧米人と日本人で問題の観点が異なる。
欧米人は、それを組織の能力の問題ととらえる。
簡単に言えば、経営トップの能力がない、という事実を指摘しているだけ。

しかし、日本人は組織の能力の問題ではなく、組織の戦略が欠落している、と見なす。
組織のあるべき方針、あるべき行動が間違っていると見なすのだろう。

この違いは、実はとても大きい。
組織的な阻害要因が組織の能力の問題ならば、正直救いようがない。
「あなたのスキルでは、この問題は解決できないのですよ。あなたの首を変えるしかありません」と言っているのに等しい。

上記の記事によれば、日本のソフトウェア開発に限らず、日本の他の業界の経営方法、日本の政治・経済などを見渡しても、同様の事象が発生しているように思える。
つまり、日本の組織のトップを変えるか、もっと能力を向上させるようにしなければ、根本的な解決にならない。

日本でアジャイル開発を導入しにくい、と言われる理由は、最終的には組織的な阻害要因にぶち当たり、それ以上の根本的な変革につながらず、抑えこまれてしまうからだろう、と直感している。

| | コメント (0)

2014/04/13

日本でモデリングツールが使われない背景

日本でモデリングツールが使われない背景について記事があったのでメモ。

【参考1】
プロマネBlog: SysML 中級講座: 第7回 日本のモデリング事情

(引用開始)
北米が50%を占めていますが、そのうち大半がUS(合衆国)です。
欧州市場は40%を占めていますが、その40%のうちの7割ぐらい(全体比で30%程度)は英独仏の3カ国で占められています。
そして、残りの10%は、日本を含むその他すべての国を意味します。
この図で、日本のモデリング市場の特徴を見る事が出来ます。
一般のソフトウェア市場で見た場合、日本の市場規模はアメリカに次いで2番目に大きく、国別ではヨーロッパのどの国よりも大きいのが通例です。
しかしながら、モデリング・ツールの市場で見た場合、アジア市場は非常に小さく、また日本は、そのアジア市場でも必ずしも多数派ではなく、インドやオーストラリアなどと横並び状態です。
日本は決してソフトウェア投資、IT投資をしてない訳ではなく、GDP比で見ても、投資額で見ても、先進国の中では中の上くらいに位置しますが、 モデリング・ツールをあまり使わないと言う点で、相対的に異質です。
欧米の専門家は、ツールを用いないモデリングは実用性に欠けると考える人が圧倒的であり、筆者自身の経験から言っても、欧米で、ツールを使わないでモデル・ベース開発を行なっている現場を見た事がありません。
また、このポイントは、IPAのモデリング部会(筆者もOMG代表として出ております)の日本企業に対するアンケート結果に示される「モデリングの実用性に不満を持つ層が多い」と言う事実と符合します。
日本は、モデリングそのものに関する知見は高いものの、実用のための知見に乏しいと言っても良いのではないか、と言うのが率直な感想です。
(引用終了)

【参考2】
プロマネBlog: SysML 中級講座: 第8回 日本のモデリング事情  2

(引用開始)
以前のブログで、日本のモデリング事情の特徴の1つとしてツールの使用度が非常に低い事を挙げました。
そして、このことが多くの日本の組織がモデリングが実用な技術ではないと感じていると言う調査結果と方向的に一致していると述べました。
本日は、それでは、「なぜ日本ではモデリング・ツールが使われなかったのか?」と言う事について議論してみたいと思います。
非常に多くの要因が考えられると思います。例えば、財務上の問題でツールが買えない、とか、上司が旧来の実績ある方法に固執している、現状の方法論で十分間に合っている、以前使った事があるが上手くいかなかった、プログラマ達が新しいやり方に抵抗を示す、等々、日本の組織の数だけ理由が出てくる事でしょう。

現実問題として、日本のエンジニアが全員一律にモデリング開発を行う必要はなく、現状で満足できるのであれば、わざわざリスクを取る必要が無い事は事実ですが、既に旧来の方法の限界に直面しているにもかかわらず、モデリング手法を取り入れる事を躊躇する組織が多く見受けられます。
大別すると、①以前ツールを使ってみたが、その後使わなくなった(挫折型)と②使った事が無い(食わず嫌い型)に分かれると思います。
今、筆者が非常に興味を持っているのが①の挫折型です。
と言うのも、日本以外、特に欧米では①のパターンを殆ど見かけないからです。

欧米の開発現場の新入社員は、最近では、殆どがUMLを学校でならって入社して来ています。
そして、大学(院)では、UMLはツールを使いながら学習しています。
ちなみに、話の枕に取り上げたMITの数学の講義ですが、線形代数の講義中、要所要所でMATLABではどう計算するか、と言うポイントを講師が簡単に説明しており(実演は無し)、数学の教育にもツールを取り入れている事がうかがえます(日本で言うと、教養課程の数学教育の段階でMATLABを使用)。
従って、大学(院)でUMLを習った場合、
UMLを知っている ≒ UMLツールが使える
と言う公式が成り立ちます。(これは、学生本人や企業が期待するところでもあります。)
(引用終了)

【1】2000年代前半なら、モデリング・ツールと言えば、RationalRoseが主流だった。
使い道は、モデル駆動開発。
つまり、UMLでクラス図、シーケンス図を書いて、そこからソースを自動生成して実装していく。

でも、ソースを修正すれば、モデルと相違点が出てくる。
本番リリース後に次々に出てくる障害修正パッチを当てていくと、WF型開発で作ったモデルはもはや、現実のシステムを表現していない。
かと言って、モデルを直してからソースを自動生成するやり方は、モデルの修正箇所が多いほど、修正時間が長くなる弱点がある。

結局、モデル駆動開発の問題点は、モデルとソースの同期が最大のボトルネックという感想を持っていた。
モデリングツールがモデル駆動開発を標榜する限り、その問題から離れることはできない。

【2】モデリングツールが使われない原因として、「上流工程の分析よりも下流工程の実装に興味がある」という話もある。
おそらく、日本における設計のイメージは、詳細設計書レベルのイメージが強いのだろうと思う。

プロマネBlog:アーキテクチャー:メタモデルのすすめ ③
(引用開始)
上流工程の重要性とその限界
ソフトウェア工学によると、ソフトウェアの品質に最も影響を与えるのは設計フェーズの品質であり、その設計に決定的な影響力を持つのが要件フェーズです。
オブジェクト指向分析設計も歴史をひも解くと、元々は要件の分析と概念設計の為にモデリング言語が開発されました。
従って、UMLは本来要件フェーズで最も活用されるべきツールです。
しかしながら、日本での使い方は圧倒的に実装フェーズで実装設計のツールとしてのみ使われる事が多いようです。
本来、要件を記述するための言語であったUMLがむしろ実装設計にのみ用いられる状況は、恐らく日本固有の現象のようです。
これは、実装のアーキテクチャーにのみ興味があり、上流部分(ドメイン側)のアーキテクチャーに無関心な現況とも一致する現象です。
全体に東アジア圏の国々(日本、韓国、中国等)は、実装技術に強い関心を示す反面、ドメイン側に対する興味は非情に薄いと言われていますが(興味が薄いのではなく、アーキテクチャーやモデリング技術を上流行程に持ち込む発想が薄いだけだと思いますが)、日本はその傾向が顕著なようです。
理由はともあれ、日本は結果的に上流行程のアウトプット品質が非常に悪いと言う定評を得つつあるのは残念です。
特徴的なのは、UMLを使わないから悪いのではなく、UMLを用いて書いた要件仕様でも、分析を行なった形跡がなく、単なる表記法としてのみ用いられていて品質の向上が見られないと言うのが平均的な現況のようです。
昨今のこの状況に対し、日本でも要求フェーズの品質を高める事が脚光を浴び始めて来ました。
しかしながら、水をさすようですが、要求フェーズの品質向上だけでは、大した改善は期待出来ない、と言うのが歴史的事実です。
(引用終了)

プロマネBlog:アーキテクチャー:メタモデルのすすめ ④

(引用開始)
要件分析・概念設計の日本固有の現象
創造性の軽視
前回は上流設計の重要性を書きましたが、仕事柄、筆者は開発プロジェクトに関与する事が度々ありますが、最近はつくづく、その違いを考えさせられます。
最近は日本でもUMLの使用率がかなり上がって来ていますが、大半が実装設計以降での下流工程での使用が中心的です。
最近はオフショア開発の条件として要件仕様をUMLで書く事が条件になるケースも多いのですが、現地のエンジニアからは、日本のUMLは要件を本当に分析したのか?とか、分析した形跡がまったく見あたらない、と言う意見を聞きます。
「要件仕様をUMLで書いてくれ」と言うリクエストは、国際的には「要件をオブジェクト指向分析設計してくれ」とほぼ同義語ですが、日本人は文字通り、単に表記法としてUMLで書く、と言う意味で捉えられてる形跡があります。
巷間、日本の携帯電話がなぜ海外で売れないかが一時話題になりましたが、多くの人は、実装技術ではなく要件分析等の上流工程の品質の問題を指摘していました。
本来、要件設計や概念設計は製品やサービスの価値を決める最もクリエイティブなフェーズであり、モデリング技術も本来そのために発展して来たものですが、全体に日本のエンジニアは実装設計には熱心ですが、上流工程にモデリングを持ち込む事が苦手なようです。
アーキテクチャーも同様な傾向が見られ、上流工程のアーキテクチャーよりも実装のアーキテクチャーにのみ関心が集中する傾向があります。
(引用終了)

最近、IPAの分科会でも、要求分析の工程で機能要件だけでなく非機能要件も考慮したり、超上流工程というバズワードで要求の品質をあげようという流れがある。
しかし、それらの活動にモデリングツールを使って、要求の品質を改善しようとする動きはあまりない。

モデリングツールを使わない要件分析や設計作業の成果物は、Excelで書かれた膨大な日本語のドキュメントだ。
それらは印刷されないと、特に50代以上のマネージャは読んでくれないので、大量のバインダーで保管されることになる。

日本語ので書かれたドキュメントはたしかに必要だが、運用保守されていくうち、現行システムと乖離が生じやすい。
1件の障害修正で、影響する要件や仕様を修正する必要があるが、その考慮が漏れてしまったり、書いていくうちに粒度が変わってしまったりする。

結局、設計書の間のトレーサビリティが意識されないまま、修正されてしまうのが最大の問題。
仕様の修正とモデルの変更の間のトレーサビリティの確保は、モデリングツールで自動補完されなければ、人手による作業は無理だろう。

【3】日本では、何故、モデリングツールが使われないのか?
上記のような問題点だけでないと思う。

個人的には、日本のSIの現場では、ソフトウェア開発を効率化するためのツールや環境に投資しない、という発想がすごく根強いと思う。
売上を上げる前に、お金を投資して、開発環境を整備しよう、という発想が、特にマネージャ層にない。
彼らは売上のコスト責任があるので、コストはできるだけ減らして、利益を確保したい動機がある。
つまり、マネージャ層の考え方や行動は、全体最適化の結果ではなく、局所最適化の結果であると言える。

そんな環境にあっても、オープンソースの開発ツールやモデリングツールを使う場合は、マネージャも大目に見てくれる。
運用ノウハウが事前にあれば、どうやって現場に浸透させると効果が出るのか、という利点も説明しやすくなる。

最近は、モデリングだけでなく、開発プロセスもツールで効率化していく手法が盛んに研究されている。
その辺りの流れも踏まえて、色々考えてみる。

| | コメント (0)

2014/04/11

ロバストネス図の使い道

オブジェクト指向設計のダイアグラムの中で、特殊な使い方と思われる図法としてロバストネス図がある。
ラフなメモ書き。

【元ネタ】
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記

実践ロバストネス分析 第 1 回 ロバストネス分析の基礎

ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき

【1】僕が現場でロバストネス図を見たのは、RUPが標準の開発プロセスと称している案件だった。
そこでは、設計SEが、画面の処理やバッチ処理をロバストネス図で描いて、設計の意図や処理の流れを説明していて、そんな使い方があるのか、と理解した時がある。

設計SEが要件定義やアーキテクチャ設計で、画面の表示処理や更新ロジック、バッチ処理をプログラマに説明しようとする時、DFD(データフローダイアグラム)に近い絵をホワイトボードに描く時が多い。
処理とデータストアを矢印で結んで、このボタンを押すと、こんな処理が働いて、このテーブルに貯められるのだ、と。

でも、DFDは正直使いづらい。
機能が多かったり、複雑になるほど、DFDは絵として読みづらくなる。
オブジェクト指向設計の発想がないので、長い手続き型プログラムで実装されやすい。

かと言って、独自の記法を使うと、その絵は再利用しづらいし、説明する本人しか理解できない。

【2】ロバストネス図を使うオブジェクト指向設計として、ICONIXプロセスがある。
ユースケース駆動開発実践ガイド」が一番有名だ。

ユースケース駆動開発実践ガイド」では、ロバストネス図は、ユースケースである機能要求とクラス図・シーケンス図などの実装モデルの間をつなぐ「オブジェクトの絵」として定義される。

ロバストネス図の利点は、何といっても描きやすいことだ。
バウンダリ、コントローラ、エンティティの3つの要素は、○を書いて、ちょっと取っ手を付けたり、矢印をつけたり、棒を引くだけですぐに描ける。
ロバストネス図はホワイトボードに手書きで書く時に威力を発揮する。

ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記に幾つかの利点が書かれている。

ロバストネス図なら、かなり多くのバウンダリ、コントローラ、エンティティを埋め込んでも、絵として違いが分かりやすい。
また、バウンダリ、コントローラ、エンティティに色付けできれば、より理解しやすくなる。

【3】僕の感想としては、ロバストネス図の描き方や使い方に幾つかの注意点があると思っている。

一つは、バウンダリは外部とのインターフェイスが定義であるなので、バウンダリの例として、画面や帳票だけでなく、バッチをキックするCronも相当すること。
この方法を採用できるので、ロバストネス図は特にバッチ処理の概要を示すのに都合が良い。

また、ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記のように、外部システムとREST APIでやり取りしたり、SOA連携するやり取りをバウンダリ間のメッセージ送受信として表現する事もできる。

外部システム連携では、外部とやり取りするI/Fがとても重要だ。
外部システム連携の構造は、システムそのものをオブジェクトに見立てて、お互いにメッセージをやり取りしあうイメージで考えると分かりやすい。
この考え方は、システムオブシステムズ(System of Systems)の発想にもつながる。

ソフトウェアの品質を学びまくる:JSTQB-ALシラバスのお勉強 ─ 1.1~1.5

System of systems - Wikipedia, the free encyclopedia

もう一つは、コントローラがメソッドとして実装されること。
つまり、ロバストネス図で分析されたコントローラは、シーケンス図のオブジェクトで存在せず、どこかのクラスのメソッドとして実現される。

UMLを描こう - Vol.5 ICONIXロバストネス図 : アシアルブログのように、コントローラは「主語がシステムとなっている文の動詞」である。
したがって、「システムがすべきこと=実装すべき処理=コントローラ」になっている。

手続き型プログラムにはまりすぎている開発者がロバストネス図を描いてみると、コントローラを多用しすぎる傾向がある。
彼が書いたロバストネス図を絵としてみた場合、コントローラを多用した図は、バッチ処理のように、一つのデータをこねくり回すような処理の流れになりやすい。
つまり、一昔前の構造化設計の機能分解と同じ発想なのだ。

【4】ロバストネス図はホワイトボードで手書きで描くのが一番向いている。
僕は、astahのクラス図の中にロバストネス図を埋め込んで描く時が多い。

astah* UMLモデリングツール | Astah

astahは設計のスケッチとして、とても使いやすいので重宝している。

| | コメント (0)

2014/04/08

「チーム開発実践入門」が発売されている

チーム開発実践入門」が発売されているので、目次をリンクしておく。

チーム開発実践入門──共同作業を円滑に行うツール・メソッド:書籍案内|技術評論社

目次
第1章:チーム開発とは
第2章:チーム開発で起きる問題
第3章:バージョン管理
第4章:チケット管理
第5章:CI(継続的インテグレーション)
第6章:デプロイの自動化(継続的デリバリー)
第7章:リグレッションテスト

目次をみると、Gitのワークフローとして、git-flow, GitHub-flowが紹介されている。
チケット駆動開発も紹介されているが、特に、継続的デリバリーの章が興味深い。

ちょっと分からなかったことは、ブートストラッピング(Bootstrapping)、コンフィグレーション(Configuration)、オーケストレーション(Orchestration)という言葉は、継続的デリバリーのパターンなのかな?

ここ数年、開発環境の周囲は大きな技術革新が生まれている。
チケット駆動開発もその一つの流れに入っているが、「チーム開発実践入門」は、最近のクラウド技術や継続的デリバリーの部分も最新の内容が詰め込まれているみたい。
読んでみたい。

| | コメント (0)

ユビキタス言語は概念群の凝集である

第4回ドメイン駆動設計読書会@大阪の別の方の感想文を読んで、なるほどと思ったのでメモ。
ラフなメモ書き。

【元ネタ】
PHPメンターズ -> Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation

凝集度を高める : クラスもパッケージもコンテキストも「ドメインの視点」で凝集すべし | システム設計日記

sdi - Page: redbook-10 「理論編-9 経営過程」 を読む

(引用開始)
モデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になってはいます。しかし、もう少しブレの無い言葉で表現しておいた方が良いように思います。ここで、ソフトウェア工学で使われてきた「凝集度」という言葉を使えば、「概念群の凝集度」という視点で置き換えられるのではないかと私は考えます。この捉え方はすでに増田亨さんのブログでも触れられています。ドメイン駆動設計の後半では、蒸留カテゴリの中に凝集は繰り返し現れます。
(引用終了)

ユビキタス言語となった設計図は僕はまだ見たことがない。
だから、モデルの理想郷として考えてみる。

「ドメイン駆動設計」では貨物輸送システムの例が何度も出てくる。
普通のオブジェクト指向設計ならば、名詞をそのままクラスにして、その関連を結んで、クラス設計にしてしまう。
しかし、それは浅いモデル。

貨物輸送システムで実装したい機能要求を顧客から何度も引き出してみると、たくさんの業務ロジックが出てきて、その内容をクラス図に反映していく。
その過程は、業務ロジックをクラスの1メソッドで実装する作業ではなく、あるドメイン(関心事)の凝集度を上げて、本質的なドメインを編み出すことにある。
その作業そのものが、「蒸留」という作業なのだろう。

その「蒸留」という作業において、責務のレイヤーパターンを使えば、意思決定支援層にオーバーブッキングポリシーが出てくるのが分かる。
普通のオブジェクト指向設計では、オーバーブッキングポリシーという業務ロジックだけのクラスは出てこないだろう。
おそらく、アプリケーションのサービスクラスに、IF文やFor文が混じったべた書きの長いロジックになってしまうだろう。

深いモデルにするには、クラスは単なる名詞ではなく、業務ロジックやビジネス上のお金のやり取りも反映したものにすべき。
そのためには、やはり何らかの視点が必要。

その視点の一つが「責務のレイヤ」パターンであり、Policy-Control-Operationという考え方であり、T字型ERで言う事業過程・管理過程・組織過程の分類でもある。

そして、貨物輸送システムがビジネスで役立つシステムになるには、最終的には、お金のやり取りを具現化する「船荷証券」という権利をやり取りすることになる。
そこまで行き着いて、初めて、深いモデルになる。

深いモデルは、現れるクラスの凝集度が高い。
深いモデルになって初めて、モデルはユビキタス言語になる。

| | コメント (0)

2014/04/06

第4回ドメイン駆動設計読書会の感想

第4回ドメイン駆動設計読書会@大阪に参加してきた。
感想をラフなメモ書き。

【限定募集:第1回の申込者のみ、参加登録可能】第4回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

Pages ・ dddosaka/reading_ddd_report Wiki

【0】「ドメイン駆動設計」の第1章の最初の例1と2を輪読して、みんなで議論してきた。
改めて、自分の理解が浅いことを痛感してきた。
食いつまんで理解しているだけなので、文章を一つずつチェックして議論してみると、新たな気付きや理解が生まれる。

【1】例1.1では、ビジネスルールをポリシークラスとして抽出することで、隠された概念を見える化させる。
当初の浅いモデルから「深いモデル」へ進化していく。

P.21では、貨物の輸送システムをドメインエキスパートとモデリングしていくと、モノを運ぶのではなく、船荷証券という法律ないし会計の概念が現れたという話がある。
これがまさに、浅い業務のモデルから、ビジネスの本質をとらえた帳簿モデル(渡辺さん、佐野さんが主張するモデル)になるのだろう。

興味深かった議論は、業務知識を知らない開発者が作った浅いモデルから、どうやって、業務の本質をとらえた深いモデルへ変換することができるのか?ということ。
結論としては、やはりそう簡単にはブレイクスルーが起きて深いモデルへ進化することはなく、業務知識を知っておかないと、そんなモデルは出てこないだろう、という話に落ち着いた。

【2】例1.2のユビキタス言語では、貨物輸送プログラムにおいて、「経路仕様を満たす輸送日程を見つける」モデルは、「経路仕様」クラスを使うことがキーポイント。

このモデルは、「責務のレイヤー」パターンを使えば、意思決定支援層が経路選択サービス、業務層が経路仕様、貨物、輸送日程になり、能力層が行程クラスに相当する。

興味深い議論としては、経路仕様クラスのようなポリシークラスはどうやって導き出せるのか?という話があった。
普通の設計工程では、このようなビジネスルールだけを集めた仕様書はないから、ポリシークラスの発想は出てこないかもしれない。

僕の経験では、会計システムにおける計算仕様書という特別な設計書を作成した経験があるので、それがポリシークラスに相当するだろうと思っている。
計算仕様書の中身は、消費税や販売価格の計算方法(税込金額からの税はがし処理、税計算の丸め込み・切り上げ・切り捨てなど)をまとめたもので、ユーザにとってかなり重要な仕様だ。
この仕様の正当性を最終的には、会計の専門家(税理士、公認会計士)に認めてもらう時もある。

【3】ユビキタス言語とは、ドメインエキスパートと開発者が互いに理解しえあえるドメイン知識。
ユビキタス言語があれば、どのチームでも、どの作業でも、共通に使える概念としてモデルからソースに落とし込める。

ユビキタス言語がない場合、業務の専門家と開発者はお互いに通訳しながら会話しなければならない。
また、開発者同士でも、お互いに通訳して、相手の概念を理解する時もある。
通訳はコミュニケーションのロスを発生させて、コミュニケーションを鈍らせる。
これは方言ともいえる。

ユビキタス言語は、業務の用語集に似ている。
用語集がない場合、ホモニム(同音異義語)やシノニム(異名同義語)が発生してしまい、チームが混乱してしまう。
チームごとに方言があるような状態が相当するだろう。

ユビキタス言語には使用範囲がある。
それが「境界づけられたコンテキスト」になる。
そして、複数チーム、大規模システムにおけるサブシステムの単位でユビキタス言語として使われる概念が違う場合(つまり、方言)、「コンテキストマップ」によって、方言を対応付ける。

境界づけられたコンテキストを意識しなければ、ユビキタス言語はあいまいに使われてしまう。
コンテキストマップがなければ、方言の対応を開発者自身が行わなければならないので、意思疎通がしにくくなる。

また、大規模システムになれば、ユビキタス言語をレイヤーで分ける。
「責務のレイヤー」がまさにそうで、意思決定支援・業務・能力の3つの層で分けて分類する。
「責務のレイヤー」に似た話としてREAモデルを久保さんから教わった。
REAモデルは、リソース(Resource)、イベント(Event)、エージェント(Agent)の3つでビジネスモデルを構築・分析するやり方。

要求開発アライアンスのビジネス・モデリング道場 - REAとビジネスパターン入門(1):ITpro

テーブル設計 | システム設計日記

REAモデルから考えても面白かもしれない。

【4】他に興味深い感想は、ユビキタス言語はどんなものなのだろうか?という議論。
僕も含めて、ほとんどの参加者はドメイン駆動設計をしたことがないので、ユビキタス言語は用語集みたいなもの? ユビキタス言語はAPIみたいなもの?みたいなアナロジーで議論していた。

ユーザと開発者が同じ概念で会話しあうという場面を想像できなかったのだ。
久保さんが何度も説明してくれたが、やはり自分でモデルを作ってみないと分からないと思う。

【5】個人的に不明に思うのは、ドメイン駆動設計の成果物は何なのか?
やはり、UMLのクラス図が多いのか?

普通の要件定義では、AsIsの業務フローを洗い出し、それに対して、人や組織をマッピングし、あるべき業務フローへ洗練させる。

このやり方は王道であるが、大量のドキュメントを作る羽目に陥りがち。
また、AsIsモデルを作るだけで精一杯なので、あるべきモデルを提案する頃には時間切れになる。
すると、現状の問題を残したままシステム化してしまい、システム稼働後に、ユーザから、こんなはずではなかったという苦情を受けてしまいがち。

おそらく従来のPOAに近い手法ではなく、ドメインモデル主体なのだろうと推測する。
勉強会でさらに議論してみる。

【追記】他の方の感想をリンクしておく。

ドメイン駆動設計読書会、第4回のメモ - nyanp::blog


| | コメント (0)

2014/04/05

【公開】第10回 RxTstudy/第57回 SEA関西プロセス分科会「チケット駆動開発とメトリクス」の感想 #RxTstudy

4月5日 第10回 RxTstudy/第57回 SEA関西プロセス分科会 チケット駆動開発とメトリクスに参加したので、ラフなメモ書き。

【0】大杉さん、神谷さんをお呼びして、チケット駆動開発とメトリクスに関係するお話。
僕はパネルディスカッションに出た。
パネラー4人のうち、3人(大杉さん、神谷さん、@sakaba37さん)は工学博士というかなりレベルの高い方ばかり(笑)。
聴衆にも、品質保証やメトリクスに詳しい方もおられて、パネルディスカッションが1時間以上白熱しました。
久しぶりにチケット駆動開発について熱い議論ができて有意義でした。

【1】僕のポジショニングトークスでは、Redmine導入・運用を支援するPMOの立場から、メトリクスの経験談と今後採取したメトリクスについてお話しました。

【1-1】Redmineでテスト工程の障害分析を見せると、上司も開発チームも驚いてくれる時が多い。
普通の開発チームは、プロダクトをリリースするのに精いっぱいで、障害がたくさん出ているのは分かるが、その詳細や傾向は知らない。
上司も、品質やコストを知りたがっているが、現場から離れているので、チーム状況が分からない。

だから、結合テスト工程が終わった直後に、チームの振り返りをするときに、反省会のイメージで、最もメトリクスが取りやすい障害分析の結果を見せると、Redmineを使うとこんなこともできるのか、と効果を感じてくれる。
その内容も、カテゴリ・対応者・原因工程・検出すべき工程・混入工程・機能別にサマリするだけでも、定量データで見せるのはかなり威力がある。

特に、新人SEや若手に見せると、その後の作業でやる気が出るみたい。
おそらく、今後は改善していこう、という意識が自然に働くのだろうと思う。
だから、僕はあえて、メトリクスを見せて成績評価に使うことはしない。
そんな使い方をしなくても、メトリクスを見せれば、行動は自然に変わってくる。

また、定量データは、上司への報告書や計画書の元ネタになる。
特に、マネージャレベルになると、テスト報告書やプロジェクト完了報告書を書くときに、リリース判定基準となる定量データとして使える。
今後のプロジェクト計画でも、過去のシステム開発の定量データを元に、今回は、こんな対策を講じて実施します、という使い方もできる。
経営者に近いレベルの人には、定量データを見せて論理的に話さないと、説得しにくい場面が多いからだ。

【1-2】信頼度成長曲線も実際に集計する時は多い。
すると、普通は、理論通りの曲線のように見える時が多い。
実際は品質が悪いのに、その感覚が現れていないように見えるのだ。

その理由は簡単だ。
普通は、結合テストやシステムテストの工程の後半になると、開発要員を縮小する計画になっているので、少ない人数でテストを続けるために、バグの発生が少なくなったり、そもそもテスト作業が減ったりする。
つまり、単にテストしなくなったから、バグが増えなくなって、S字のように見えるだけだ。
だから、次工程に進んでよい判定基準に使うことは難しい。

そんな事例を新人SEに話すと、彼らも実際の理論と現場の現実のギャップに気づいて、何かしら考えてくれる。
メトリクスは、若手にとって良い教育になると思っている。

【2】WF型開発とアジャイル開発を比べると、アジャイル開発はメトリクスを重視していると思っている。

【2-1】アジャイル開発の最大の利点は、直近のイテレーションで採取したメトリクスを、次のイテレーションですぐに使えることだ。
つまり、メトリクスのフィードバックをチームや次イテレーションに生かせる。

例えば、ある機能の障害が多発したならば、次回からはこんな対策を考えよう、と行動を促すこともできる。
あるいは、今回のイテレーションでは50枚のチケットを完了できたので、次回はこれぐらいの機能をリリースできるだろう、という見積りにも使える。

また、同一プロジェクトでメトリクスを採取できるので、イテレーションを繰り返すたびに、メトリクスの精度は理論上高くなる。
同じメンバーでチームを組んで、小刻みにリリースしていく開発スタイルならば、メトリクスを採取する前提条件があまり変わらないからだ。

アジャイル開発はメトリクスが取りやすい: プログラマの思索

【2-2】しかし、WF型開発はメトリクスを使いにくいと思っている。
テスト工程やリリース前の工程でメトリクスを採取したいと思っても、普通は障害が多発するために、メンバーもリーダーも忙しすぎてメトリクスを収集しにくい。
また、プロジェクト完了時にメトリクスを採取して、チームにフィードバックしたとしても、チームは解散してしまうので、そのノウハウをチームとして学習することができない。

つまり、せっかく採取したメトリクスをチームの学習やチームの成長に生かせないのだ。

本来は、障害分析や設計レビュー、課題の傾向分析などから、そのプロジェクトの知見、そのシステムのノウハウをチームは学習して、どんどん改善すべきなのだ。
しかし、普通は、要件定義と設計工程は元請、開発・単体テスト工程は下請けのように、メトリクスを採取する対象のメンバーが違うために、そのメトリクスをチームの成長に使いづらい弱点がある。

日本のSIでWF型開発を標準プロセスとして持っている企業は多いし、品質保証のためのメトリクスの知見も持っているのにも関わらず、そのメトリクスのフィードバックが開発チームの学習に生かされていないのではないか、と思っている。

【3】今後、僕が意識的に採取したいメトリクスがある。
それは、Velocityとサイクルタイム。

【3-1】その理由は簡単。
Velocityを計測することで、チームの生産能力を定量的に計測し、次のイテレーションや次の改善要望の見積りに生かしたい。
例えば、顧客から追加要望が来た時に、これぐらいの開発規模までならば、1か月以内にリリースできるだろう、と見積りしたいのだ。

あるいは、サイクルタイムを計測することで、リリースまでの平均待ち時間を計測し、顧客への回答に使いたい。
例えば、現在の仕掛中の作業を踏まえると、顧客から新たに受け取った追加要望は、リリースまで6週間待つ必要がある、と回答できるようにしたいのだ。

【3-2】Velocityとサイクルタイムは、Redmineのチケット集計で簡単に計測できる。

(1)サイクルタイム=平均待ち時間=チケットの平均滞留期間 or チケットの生存期間=全ての完了チケットの開始日~終了日までの平均期間

(2)Velocity=チームの生産能力=1イテレーション(例:1ヶ月)の平均完了チケット数

ここから、待ち行列理論のリトルの法則を使えば、Velocityとサイクルタイム、WIP(仕掛かり制限)には下記の関係がある。

リトルの法則:サイクルタイム=WIP/Velocity

※チームのWIP=1サイクル(一つの工程)の仕掛中のチケット総数

例えば、作業中チケット(WIP)は30枚で、5枚/週ペースで完了(Velocity)できるなら、サイクルタイム=30枚/5枚/週=6週間になる。
つまり、顧客の新規要望がリリースされるまでに6週間かかることを意味している。
普通の感覚としては長すぎるので、チケットの優先順位を変えたり、チケットの取捨選択によって、リリースサイクルを短くするように改善するだろう。

「リーン開発の現場」はアジャイルサムライの再来となるかpart3~サイクルタイムとリトルの法則の関係: プログラマの思索

チケット駆動開発におけるサイクルタイムの計測方法~リーン開発で最も重要なメトリクス: プログラマの思索

【3-3】また「リーン開発の現場」に出てくるプロセスサイクル効率も採取したい。

プロセスサイクル効率=実績工数/サイクルタイム

目的は、プロセスのムダを見える化できることだ。

例えば、機能Aの実績工数は1日なのに、完了させるまでに10日もかかっているとする。
すると、プロセスサイクル効率=1日/10日=10%なので、残りの9日間(90%)は、チケットが放置されたまま、何もしていない事実を意味している。

すなわち、チケットが放置された期間が長いほど、仕掛かり中の製品ないし作業が在庫として溜まっているので、無駄が発生していることになる。
普通のソフトウェア開発では、レビュー待ちや検証待ちや顧客回答待ちでチケットが放置されやすく、PLや上級PGや顧客がボトルネックになっている時が多い。
だから、そのようなボトルネックをなくすような対策を打たなければならない。

ただし、聴衆の方から指摘もあったけれど、実際のソフトウェア開発では、並列で作業する時が多い。
例えば、設計書が完成してレビュー待ちになれば、次の設計書の作成に取り掛かるように、並行作業している。
だから、待ち時間が長くても、さほど無意味ではない、と。

確かに、実際の現実はそんなケースが多いだろう。
しかし、トヨタの改善方式やリーン開発を考えると、作業の無駄を見える化することは、チームに気づきや行動の促進のために重要なことだと思っている。

【3-4】アジャイル開発のメトリクスでは、WF型開発のような品質保証のメトリクスよりも、見積りに関するメトリクスが多い特徴があるように思える。
この点では、アジャイル開発にかなり分があると思う。

上司や顧客にとっては、品質も重要だが、やはりコストや納期の方が知りたいからだ。
アジャイル開発の方が、数回のイテレーションを繰り返すたびに、チームが生み出すメトリクスは安定してくるはずなので、見積りの精度も上がるだろうと思う。
彼らは見積りにすごくこだわっているからだ。

アジャイル開発が見積りに関するメトリクスが多い理由はおそらく、顧客へ納品するという観点が強いために、いつリリースできるのか、を計測するメトリクスが研究されたからだろうと推測している。

Redmineによるチケット駆動開発は、そのようなメトリクス収集ツールの基盤として使えると思う。

【4】今後目指したいのは、工数集計の自動化だ。

月末の開発要員の工数報告を自動化したい。
どの会社でも、部課長がExcelで集計し直していて、とても労働集約的。
理論上は、Redmineチケットに実際の作業工数が入っているのだから、月次バッチ処理で出力できるはず。

また、EVMも理論上は実現可能だ。
EVMの利用目的は、現時点のチームの開発速度から、完成時総コスト見積り(EAC)を予測したいことだ。

それによって、当初の予算よりもコストオーバーになるのか、を知ることができる。
コストオーバーになる時期を予測できれば、その時期に合わせて、ヘルプ要員を投入するように要員計画を事前に立てることもできる。

また、要員表作成(リソースチャート)の自動化もやりたい。
案件の予定表に予定工数と開発要員をマッピングして、どの時期にどれくらいのスキルのメンバーが必要なのかを事前に計画したいのだ。
Javaができる開発者、Rubyの開発者、プロジェクト管理のできる人などのように、要求されるスキルのメンバーはすぐにかき集めることができないから。

しかも、PMのお仕事の殆どは要員表の管理であり、彼らはExcelやMSProjectでやっている。
とても労働集約的。

Redmineでは、WorkTimeプラグインで工数入力の機能やユーザインターフェイスは充実しているので、残る課題は工数集計の部分だ。

Redmine Lychee製品シリーズのEVMプラグインにはとても期待している。
できれば、Redmine Lychee製品シリーズは、MSProjectの機能をすべてRedmine上で実現してほしいと思う。

【公開】第6回品川Redmine勉強会発表資料「開発基盤としてのRedmine~Redmineをカスタマイズするポイント」 #47redmine: プログラマの思索

Lychee Enterprise

マネージャの仕事は、工数集計によるコスト管理、要員表の管理に尽きるからだ。
Redmineがプロジェクト管理用ERPになってしまえば解決できるだろうと思っている。

MS Projectを使いこなせない理由: プログラマの思索

RedmineのガントチャートはMS ProjectのWeb版になりうるか?: プログラマの思索

【5】パネルディスカッションで他の質疑応答で興味深かったのは、二つある。

【5-1】一つは、WBSをチケット管理する時の注意点について。

WBSからそのままチケットに落として、タスク管理することは可能だ。
しかし、神谷さんが言っていたように、WBSを再現したチケット管理は、開発者は楽しくない。
作業の開始日・終了日が決まっていて、納期も決まっているために、がんじがらめに作業する感覚になってしまうから。
むしろ、自分たちで気づいたときにチケットに作業を登録して、チケット管理していく方が楽しい。

また、WBSによるチケット管理ですべてのタスクを実現できるわけではない。
実際は、WBSで予定されていたタスク以外にも、想定していなかった仕様変更や改善要望が発生する。
当初の計画時には、どれくらいの課題が発生するか、どれくらいの障害が多発するか、を正確に予測するのは不可能。
つまり、WBSからこぼれ落ちる作業が結構多いのだ。
僕の感覚では、当初計画したチケットよりも2倍以上増えるのが普通だと思っている。

この解決方法としては、補完型チケット方式、あるいは、アダプタブルWFという手法がある。
つまり、計画外の作業管理に特化してRedmineでチケット管理していく方法だ。

この方法の利点は、WBSは従来のやり方のまま管理すればよく、顧客や上司向けに標準プロセスを変えたように見えないことがある。

【5-2】もう一つは、Redmine+Subversionは相性が悪いのではないか、という指摘が聴衆の方からあった。

その方曰く。
ソフトウェア開発は、WF型開発のようなきれいな開発はほとんどない。
普通は、手戻り作業も発生するし、反復型開発に近い。
そして、並行開発が普通だ。

組み込み製品ならば、一つの製品シリーズに、ある一つの機能が追加されたとする。
すると、製品シリーズの全ての製品群に影響があり、その機能をマージしなければならない。
しかも、影響する機能も他にあるので、単純に移植するだけでなく、それぞれの製品に会った修正パッチをマージする必要がある。

しかし、Redmine+Subversionでは、複数の製品へのマージ作業がやりにくい、と。

この指摘は正しいし、今後のRedmineの課題であると思っている。
その課題は、ソフトウェアプロダクトラインまたは派生開発をRedmineにどのようにマッピングして運用すべきか、ということ。

本来はGitを使うべきだが、RedmineとGitの相性はあまりよくないと言われている。
また、トピックブランチをチケットに対応付ける手法が一つの解決方法だと思うが、1個のトピックブランチから複数の製品群のブランチへマージする場合、GitHubのようなPullRequest機能がRedmineでは実現されていない。
「No Ticket, No Fork」という運用ルールも試されているが、それがすべての問題を解決するわけではない。

一つの修正が、複数の製品ブランチに影響を与える場合、それらの影響調査は現状は手作業しかないし、それらをチケット管理したとしても、あくまでもプロセスは管理できても、そのパッチ取り込みの妥当性はチケット管理では保証できない。
チケット管理はあくまでもプロセス管理に特化しているからだ。

また、トピックブランチがマージされた後に削除される場合、コミットログも消えてしまうために、トレーサビリティが保障されなくなる。
回避方法としては、マージする時に新たにチケットを関連付ける、マージする時のコミットログにチケット番号を書くなどがある。

第9回RxTstudy勉強会の感想~Redmineとチケット駆動開発の今後の課題 #RxTStudy: プログラマの思索

GitHubのプルリクエスト駆動におけるチケット駆動開発の問題点: プログラマの思索

この辺りの課題は今後も考えていきたいと思う。

【追記】他の人の感想を見つけたのでメモ。

「「チケット駆動開発とメトリクス」の感想」の感想 - Some Days You Get the Bear

(引用開始)
開発途中に生かされないこともそうだし、以降のプロジェクトにも生かされない。
まるで知見がその場その場で蒸発して抜けだしていっているようだ。
(中略)
どうもWFは何から何まで流してしまいやすいものだ。
(引用終了)

【追記2】他の講演者のスライドはコチラ。


| | コメント (0)

2014/04/03

最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えている

最近、ツールとプロセスを組合わせたソフトウェア開発手法の本が増えているように思う。
読みたい本は「チーム開発実践入門 ~コラボレートを円滑に行うツール・方法論 (WEB+DB PRESS plus)」と「GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)」かな。
まだ読んでないけど、リンクしておく。

【元ネタ】
『チーム開発実践入門』という本を書きました - ikeike443のブログ

GitHub実践入門──Pull Requestによる開発の変革:書籍案内|技術評論社

【読書感想文】GitHub実践入門 ~Pull Requestによる開発の変革を読み終えました。 | メモ帳代わりのブログ

【書評】 GitHub実践入門 ~Pull Requestによる開発の変革 | IDEA*IDEA

GitHub実践入門を読んでGitとかGitHubについて考えた - 未来のいつか/hyoshiokの日記

【元ネタ2】
GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus)の目次:

第1章:GitHubの世界へようこそ
第2章:Gitの導入
第3章:GitHubを利用するための準備
第4章:Gitを操作しながら学ぶ
第5章:GitHubの機能を徹底解説
第6章:はじめてのPull Request
第7章:Pull Requestが送られてきたら
第8章:GitHubと連携するツールとサービス
第9章:GitHubを利用した開発フロー
第10章:会社でGitHubを使おう

【感想】
Redmineによるタスクマネジメント実践技法」「チケット駆動開発」の2冊を出版した後、もはや「チケット駆動開発」というアイデアはソフトウェア開発では当たり前だと思う。
では、今後は、ソフトウェア開発プロセスはどんな方向へ進化すべきなのか?

僕が思うに、バージョン管理やリリース作業を単に自動化するだけでなく、その背後にあるワークフローをツールの一機能にしてしまうことで、変更管理プロセスをツールに取り込んでしまう傾向があるように思う。

【1】GitHubが優れている点は、PullRequestが、従来のパッチのやり取りをWeb上でお手軽にできるようにしただけでなく、そのワークフローをコミッタやパッチ作成者が意識しなくても、変更管理できるようになり、後からそのやり取りを追跡できる仕掛けが整ったこと。

【1-1】従来のパッチのやり取りは、コミッタとパッチ作成者が、メールにパッチを添付して、メールに引用文をつけて返信しながらやり取りしていた。
だから、やり取りが長くなるほど、メール本文も長くなるし、どのパッチが最新なのかも分かりづらい。
また、コミッタが管理しているソースのtrunkもどんどんバージョンアップしていくから、パッチ作成者もその流れに追随していかなければならない。
だから、パッチを作成するタイミングと取り込むタイミングがずれてしまうと、せっかく作ったパッチが無意味になってしまう可能性がある。

【1-2】GitHubでは、PullRequestのワークフローは意外に厳格だと思う。
少なくとも、コミッタが気に入らなければ、PullRequestされたパッチをコメント付きで却下できる。
また、パッチ作成者は、trunkから最新版のソースを取り込んで同期しながら、パッチを育てることもやりやすい。
Gitの優れたブランチ管理やマージ機能だけでなく、そのパッチの取り込み方法も、一つの変更管理にしてしまっているのが上手いと思う。

【2】また、リリース作業についても、最近のクラウド技術を使って、かなり高度な手法によって従来の問題を解決しようとしている。
キーワードは「ブルーグリーン・デプロイメント」と「Immutable Infrastructure」。

DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (1/2) - @IT

DevOps時代の開発者のための構成管理入門(終):継続的デリバリ/デプロイを実現する手法・ツールまとめ (2/2) - @IT

Immutable Infrastructure~デプロイメントをめぐるシステムインフラの管理~ | NTTデータ

[Agile]継続的デリバリ vs 継続的デプロイ | Ryuzee.com

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(前編) - Publickey

Immutable Infrastructureはアプリケーションのアーキテクチャを変えていく、伊藤直也氏(後編) - Publickey

「Blue-Green Deployment」とは何か、マーチン・ファウラー氏の解説 - Publickey

「Immutable Infrastructure(イミュータブルインフラストラクチャ)と捨ててしまえるコンポーネント」 チャド・ファウラー氏 - Publickey

【2-1】従来の本番リリース作業は、とにかく大変だ。
本番リリースの作業中は、システムを停止するために、ユーザの業務は止まってしまう。

モジュールのデプロイも手作業でやっていると、間違ったバージョンや壊れたモジュールをリリースしてしまう危険もある。
アプリケーションサーバーの再起動が必要なので、システムは一時止まってしまう。
アプリケーションサーバーが2個以上あるならば、ロードバランサーから切り離したりする手順も増える。
手作業のリリース作業ほど危険なものはない。

一番大変なのは、データのバックアップや、本番データへの移行作業だ。
一度データを流し込んでしまった後に失敗すると、そのリカバリー作業はとても大変だ。
長く使っている業務システムほど、大量のトランザクションデータをため込んでいるので、初期化して入れ直す羽目になると、1日以上かかってしまう時もある。

普通の業務システムは、会計システムや発注システムと連動しているから、自動仕訳処理や請求・入金処理、発注処理が開始するまでにシステムを稼働させなければ、ユーザの業務そのものに大きな悪影響を与えてしまう。

【2-2】そんな従来の大変なリリース作業も、本番環境をクラウド化してしまえば、複数の本番環境を準備することで、リリース作業を楽にするだけでなく、移行作業も楽にしてくれる。

(引用開始)
ブルーグリーン・デプロイメントでは商用システムを2組用意して、ブルーとグリーンとを、切り替えることで新しいアプリケーションをデプロイメントしていきます。通常、切り替えは上位のルーターやロードバランサ―、DNSなどで実施するので、デプロイメントに失敗した場合、すぐにロールバックができます。
ただし、商用システムを2組用意するため、コストがかかります。最近ではクラウドコンピューティングをうまく使い、必要なときにだけ、もう1組の商用システムを構築できるため、コストを抑えることができるようになりました。
(引用終了)

(引用開始)
Immutable Infrastructure(Immutable Serverとも呼ばれます)はインフラ管理の新たな手法です。Immutableとは「不変な」という意味です。Immutable Infrastructureでは、その名の通り、一度作成したサーバー(インフラ)は設定変更などを行わず、不変なものとして扱います。デプロイメントのたびに、新しいインフラを構築し、既存のインフラは不要になった後に廃棄します。そのため、クラウドの利用が前提となります。
これにより従来型のデプロイメントで問題となりやすかった環境差分や変更の蓄積による設計書などに記載されない修正がなくなり、毎回クリーンなインフラを扱うことができるメリットがあります。それにより、デプロイメントが失敗する可能性を下げることができます。
このようなインフラ管理ができるようになってきたのもIaaSを中心としたクラウド技術やInfrastructure as Codeなどの技術の成熟に伴い、コンピューターリソースを瞬時に非常に低いコストで扱うことができるようになったためです。
(引用終了)

【2-3】ブルーグリーン・デプロイメントは、全く同じ本番環境が2個あることが大前提。
その前提のもとに、片方にリリースして、スモークテストなど十分にテストした後、ロードバランサーやDNSなどを最新バージョンの本番環境へ切り替えること。

以前なら、全く同じ本番環境を2個もそろえるのは、サーバー機器の購入もあるから、コストがかかり過ぎてありえなかった。
でも、今では、仮想サーバー上に本番サーバーや本番運用中のシステムが載っているは普通だろう。
つまり、ハードはほとんど無料に近く、ソフトウェアライセンスのみ費用がかかっていることになるから、格段に安くなるはず。
そこから発展して、複数の仮想サーバーを用意しておけば、リリース作業はより安全に運用できる。

ブルーグリーン・デプロイメントの手法は、特にDR対策(Disaster Recovery:災害復旧対策)で大きな威力を発揮するだろうと思う。
最近は、内部統制やBCP(事業継続計画)の観点から、インフラチームはDR対策を講じた本番構成を考えるのが当たり前だ。
DR対策では、全く同じ機器構成で本番環境を作らなければならないので、ブルーグリーン・デプロイメントの手法も適用できるだろう。

ディザスタリカバリとは 【 DR 】 【 Disaster Recovery 】 - 意味/解説/説明/定義 : IT用語辞典

【2-4】Immutable Infrastructureは、リリースのたびに、旧バージョンの本番環境は捨てるというサーバーの使い捨ての手法だ。
この手法が実現可能なのも、仮想サーバに本番環境が載っていて、システムの複製やシステムの再現が以前よりも楽になっていることだろう。

従来はパッチを当てまくったリリース作業が多くるなるたびに、本番環境が汚れていき、日付入りのファイルやフォルダが増えてどれを消したらよいか分からなくなったり、無駄なディスク消費が発生することもあった。
一方、Immutable Infrastructureのリリース手法を使えるならば、毎回クリーンな本番環境を使えるし、最新データの移行作業に専念できる利点もある。

ただし、Immutable Infrastructureの手法を採用するには、Infrastructure as Codeのように、サーバー環境構築の設定プログラムから自動生成できることが最低条件にある。
そうでなければ、本番環境を使い捨てにしていく手法は採用できないからだ。

クラウドを前提とした設計手法が最近は必須になってきていると感じる理由は、このリリース作業の自動化が大きな鍵を握っているからだろうと思う。

【3】クラウド技術と密接に連携した本番リリース作業の自動化は、今一番、技術革新が激しいところだと思う。
僕はクラウド技術に詳しくないので、この辺りは色々探っていきたいと思う。

| | コメント (0)

2014/04/01

シーケンス図とアクティビティ図と状態遷移図の関係

最近、「ドメイン駆動設計」を読み直しているうちに、昔のオブジェクト指向設計の本「実践UML」「ユースケース駆動開発実践ガイド」「オブジェクト開発の神髄」も一緒に読み直している。
すると、今まで当たり前と思っていたUMLのテクニックについて、いくつか気づき直す点があった。
シーケンス図とアクティビティ図と状態遷移図の関係について、以下にまとめてみた。

【1】僕が開発プロセスや業務フローを分析するとき、シーケンス図とアクティビティ図と状態遷移図を書く場合が多い。
普通は、astahで、シーケンス図とアクティビティ図と状態遷移図を書く。

IT業界に初めて入った時、オブジェクト指向設計が一番、という雰囲気で育ち、Javaプログラマでずっと仕事してきたから、UMLでダイアグラムを描くのが好き。

UMLが、DFDや他の技法よりも優れている点は、一つのモデルを複数の観点のビューで表現して分析できる点だと思う。

現状の開発プロセスや業務をモデル化するとき、まずは、アクティビティ図で、アクターごとにどんな作業をやり取りしているか描く。
アクティビティ図から、どんなオブジェクトがやり取りされているか見出し、そのオブジェクトのステータスを洗い出して、ステートマシン図(状態遷移図)を描く。
オブジェクト間のメッセージのやり取りを見たいときは、シーケンス図を描く。

一つのプロセス、業務を複数の観点のビューで見ることによって、このワークフローは無駄なステータスが多い、とか、このアクター(作業者)は削除できるのではないか、とか、ここに分岐判定の別のフローが存在するのではないか、など、色んな発想を思いつくことができる。
モデリングの楽しさは、一つのモデルを徹底的に分析して、その抽象的構造から、本質を見出す所にあると思う。
「このモデルの本質は○○○という概念です」と言えればベストだと思う。

【2】「UMLによるオブジェクト指向モデリングセルフレビューノート」という本を読み直していたら、シーケンス図とアクティビティ図と状態遷移図について、次のような関係が書かれていた。

(1)ステートマシン図のイベント
⇔アクティビティ図のアクティビティ
⇔シーケンス図のメッセージ

(2)ステートマシン図のステータス
⇔シーケンス図の活性区間

(1)は、ある状態から発火して、他の状態へ移った時、イベントが生じていることを意味する。
つまり、何らかの処理が実行されたことを意味する。
すなわち、その処理は、アクティビティ図のアクティビティ、シーケンス図のメッセージに相当する。

(2)は、オブジェクトのある状態は、シーケンス図の処理の実行中に相当し、それは活性区間に相当する。

いずれも考えてみれば当たり前なのだが、こういう事実を知らずに、適当に書いていると、モデルの整合性が崩れる。

このステータスは、どうやって遷移してくるのか?
この処理は、なぜ必要なのか?
この処理は、ステートマシン図のどのイベントに対応するのか?

モデルについて自問自答すると、最初に描いていたモデルには漏れが多い。
1個のダイアグラムだけ描いただけでは、その漏れに気づきにくいが、1個のモデルを複数の観点で描いてみると、不自然さに気づきやすくなる。

【3】実際のプログラミングでは、シーケンス図がきちんと書ければ、即座にプログラムになる。
つまり、シーケンス図は昔のプログラム設計、詳細設計に相当する。

しかしながら、僕は、ステートマシン図が結構重要だと思っている。
特にオブジェクト指向でプログラミングしている時、オブジェクトの状態は何種類あるのか、その状態はどんな条件で発火して他の状態へ移るのか、を意識しなければ、If文の多いスパゲティ状態になりやすい。
なぜなら、IF文の分岐条件に普通は、オブジェクトがどの状態にあるか、という判定条件が入るからだ。

【4】UMLを書く場合、astahが個人的には使いやすい。

astah* UMLモデリングツール | Astah

astahで面白そうと思った点は、シーケンス図、アクティビティ図、状態遷移図、クラス図などの要素に「図要素・モデル」を紐づける機能がある点だ。
例えば、astahの要求図に書いた要求にシーケンス図のメッセージ、アクティビティ図のアクティビティなどを紐づければ、トレーサビリティをツール上で表現できる。

astahには、トレーサビリティマトリクスを出力する機能があるので、この機能を使って、上流工程の要求から下流工程のシーケンス図へどのようの反映されているのか、を追跡することができる。
(これは後方追跡性に相当する)

逆にシーケンス図の処理は、どの要求から派生して実装されたのか、も追跡できる。
(これは前方追跡性に相当する)

RedmineとSVM連携、Git連携の運用で気づいたことは、トレーサビリティがソフトウェア開発ではとても重要であること。
トレーサビリティが保障されていれば、過去のパッチの修正理由を理解しやすくなるし、ソース修正の影響箇所を調査しやすくなるし、リバースエンジニアリングもやりやすくなる利点がある。
本来は、モデルという上流工程の成果物でトレーサビリティを実現したいのだ。

このアイデアについても考えてみる。

| | コメント (0)

« 2014年3月 | トップページ | 2014年5月 »