« 2013年4月 | トップページ | 2013年6月 »

2013年5月

2013/05/31

IT人材白書2013を読んだ感想

日本のIT業界でも、日本のIT技術者も、アジャイル開発へ大きくシフトし始めているようだ。
IPAが公開したIT人材白書で気になった箇所を見つけたのでメモ。

【元ネタ】
情報処理推進機構:プレス発表:記事:「IT人材白書2013」のポイントを紹介 ITベンダーからユーザー企業へIT人材の流動が明らかに ~中途採用でユーザー企業のIT部門に配属された人のうち40.5%は直前の職場がITベンダー~

IPA 独立行政法人 情報処理推進機構:IT人材白書

IT人材白書2013 製本版・データ編は、アンケートに回答すればPDFを無料で取得できる。
6部あるうちの「IT人材白書2013~強みを活かし多様化の波に乗れ~グローバルIT人材、WEB人材に求められるスキルとは」(ITjinzai2013_Hires.pdf)の280ページ、288ページには、開発プロセス別のIT人材に対する興味深い調査内容が掲載されている。

Q. 日々の開発業務において開発プロセスの改善を意識しているか
 アジャイル型:   「よく当てはまる」→20.4%
 ウォータフォール型:「よく当てはまる」→9.2%

Q. 今の仕事に一生懸命取り組んでいる
 アジャイル型:   「よく当てはまる」→28.4%
 ウォータフォール型:「よく当てはまる」→12.5%

Q. 仕事が好きである
 アジャイル型:   「よく当てはまる」→23.4%
 ウォータフォール型:「よく当てはまる」→9.9%

Q. この仕事をしていることを誇りに思う
 アジャイル型:   「よく当てはまる」→19.9%
 ウォータフォール型:「よく当てはまる」→7.3%

上記の調査結果では、アジャイル開発を実践している技術者の方がWF型の人よりも、より高いモチベーションで、開発プロセスの改善を意識している事実を示唆している。
しかも、アジャイル型人材の方がWF型人材よりも2~3倍の違いがあるから、かなりの差があることになるだろう。

この傾向から知られる事実は、管理職よりも経営者の方が目ざとく知っているように思える。

Twitter / akipii:1月24日号日経コンピュータのマネックス証券CTOの記事が面白い。「OSS、アジャイル開発といった新技術を取り入れることが、結果的に優秀な技術者が集まり、プロジェクトの成功が高まる」

とは言え、アンケート調査の母数が偏っている可能性もあること、アジャイル型人材に未踏プロジェクトのような日本のSIとは全く別の高度な人材が入っていること、WF型人材が日本のIT業界のほとんどを占めていることを考えると、あまり比較にならないかもしれない。

でも、XP祭り関西のLTでは、プログラミングの勉強のためにIT勉強会に顔を出していたら、皆がアジャイルの話をしていて最初は分からなかったが、自然にアジャイルに興味を持ち始めて、勉強し始めたという話もあった。

アジャイル開発は、チームによるソフトウェア開発を支援するプラクティスやプログラミングテクニックがたくさんある。
アジャイル開発に触れれば、プログラミングだけでなく、開発プロセスやソフトウェア工学にも自然に興味を持ち始めるきっかけになる。

アジャイル開発には、プログラマを力づける雰囲気があるのだと思う。

| | コメント (0)

2013/05/30

Astahプラグインの資料のリンク

Astahプラグインの資料を見つけたのでリンクしておく。

僕はモデリングツールとしてastah Professionalを愛用している。
2冊の本を出版した時、ワークフローや概念モデル、状態遷移図をイメージする時に役立った。
システムを設計するようになると、たくさんの絵を描きながら、自分のイメージを補強していくやり方が増える。
astah Professionalは、静的モデル(クラス図、ER図、パッケージ図など)だけでなく、動的モデル(シーケンス図、状態遷移図、アクティビティ図など)も書けるので、一つのツールで色んな観点でモデルを表現できるのが良い。

Office連携は、Windowsユーザやアーキテクトにとってありがたいプラグインだろう。

Office連携 プラグイン

astahはもっとプラグインが増えると面白いだろうに、といつも思っている。
モデルという優れた資源から、色んなデータを抽出して見せるビューが欲しいのだ。

例えば、システムをモデル化した時、静的モデルで見る時もあれば、動的モデルで見る時もある。
複数のビューでモデルを揺さぶり、ビジネス制約を反映させて、モデルの整合性を取っていく。

あるいは、モデルはテストにも使えるはずだし、見積もりにも使えるはずだ。
つまり、モデルからテストケースを生成できるはずだし、概念モデルからある程度の開発規模を測定することはできるはず。

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

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

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

色々考えてみる。

| | コメント (0)

2013/05/28

CCPMの考え方

CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)の解説記事があったのでリンクをメモ。

【元ネタ】
CCPM とは:梅田弘之のプロジェクトマネジメント講座:【第6章】大型プロジェクトにはCCPMを取り入れよう

サルでもわかるTOC/CCPM(第五回)|ザ・プロジェクトマネジャーズ

TOC流の開発型プロジェクト管理術「CCPM」(1):なぜプロジェクトの進行計画はいつも壊れるの? 「クリティカルチェーン・プロジェクトマネジメント」とは (1/3) - MONOist(モノイスト)

TOC流の開発型プロジェクト管理術「CCPM」(2):PDCAサイクルに潜むプロジェクト管理の問題点 (1/3) - MONOist(モノイスト)

TOC流の開発型プロジェクト管理術「CCPM」(3):TOCのPMが本当に管理すべきポイントはどこか (1/3) - MONOist(モノイスト)

TOC流の開発型プロジェクト管理術「CCPM」(4):プロジェクト管理の成否はバッファ設計で決まる (1/3) - MONOist(モノイスト)

TOC流の開発型プロジェクト管理術「CCPM」(5):進ちょく率管理で納期遅れを防げないのなら…… (1/3) - MONOist(モノイスト)

TOC流の開発型プロジェクト管理術「CCPM」(6):対策の実施されないマネジメントは今すぐ中止! (1/3) - MONOist(モノイスト)

【1】CCPMは、クリティカルパスに人間の心理学を適用したプロジェクトマネジメントと言える。

人間の心理を支配する法則として、パーキンソンの法則(仕事は常に許される時間まで伸びてくる(学生症候群))、遅延伝播の法則(遅れは伝播するが、早期終了は伝播しない)の二つがあるが、これをプロジェクトマネジメント適用したものだ。
つまり、人は与えられた期間に余裕があっても、ダラダラ作業してその余裕を食い潰してしまう。
そして、早めに自分の仕事が終わっても、他人の仕事が完了しなければ、作業待ちの時間が発生し、納期短縮が伝播しない。

CCPMでは、50%実現の確率で作業見積もりし、バッファ全てをプロジェクトバッファとして最後に一括管理しておく。
そして、各作業の残工数のみ管理し、作業の遅延はプロジェクトバッファで吸収するという考え方。

CCPMの利点は、作業時間の短縮が即座にスケジュールに反映されて納期が短くなることだろう。
残工数の管理という発想も、アジャイル開発の考え方に似ているように思う。

また、プロジェクトバッファで全作業のバッファを集めて一括管理する手法は、PMBOKにおけるコンティンジェンシー予備の発想に似ている。
つまり、プロジェクトのリスクに対する費用確保は、個々のリスクではなく、プロジェクト全体である一定の割合で費用を積み上げておくわけだ。
バッファは自分だけの持ち物ではなく、プロジェクトに関わる全員の共有物なので、作業の遅延が発生した時にバッファを使わざるを得ない時、その理由を他の関係者に明確に説明しなくてはならないプレッシャーがある。
だから、作業の遅延が発生しないように頑張らざるを得ない場面もあるのだろう。

【2】しかし、CCPMの実践は、従来の発想の逆転が必要なのだろうと思う。
まず、ギリギリの工数で見積もった計画と、プロジェクトバッファを積んだ外向けの計画の2種類を作る手間がかかる。
WBSできちんと作業や成果物をMECEで洗い出して、それぞれの見積もり工数を把握する必要があるだろう。

顧客から見れば、プロジェクトバッファを積みすぎた外向けの計画は、そのバッファの正当性を説明できなければ、単なるコストの割り増しにしか見えない。
本来あるべきプロジェクトバッファを削られてしまったら、余裕のない単なるデスマーチプロジェクトになってしまう。

また、メンバーの立場では、50%実現の確率の見積もり工数で作業をしているために、遅延してしまったら、
「今日までXX日遅れています」という実績報告をせざるを得ず、プレッシャーがかかって本来の力を発揮できなくなる。
だから、経験者に聞くと、「残りXX日で完了できます」という残工数で実績報告するように変える必要があるらしい。
むやみにメンバーを追い詰めても、作業が完了することはないし、成果物の品質も下がるだろう。

【3】僕の考えでは、むしろ作業の完了条件の考え方も重要だろうと思う。
ソフトウェア開発では、一つのプログラムが完了するまでに、仕様書には記載されていない課題が噴出したり、顧客に使ってもらったらもっと使いやすくして欲しいなど、色んなリスクがあるものだ。
すると、3日で終わるプログラムは、障害修正や改善要望の反映などで、倍以上の工数がかかるのはざらにある。

だから、当初の計画通りにまずは動かして使えるレベルまでの工数を見積もっておき、その作業が終わったら、完了として、その後の障害修正や機能改善は別タスクとして管理するようにした方がいいと思う。
つまり、本来のチケットから障害修正や改善要望、課題などの別チケットを切り出して、それらのチケットを解決しながら、ソースや成果物へどんどんパッチを当てて改良していくように進める。

つまり、チケット駆動開発にCCPMの発想を取り入れれば、タスク管理をより柔軟に行えるようになると思う。
色々試してみたい。

| | コメント (0)

2013/05/26

ERPの落とし穴part4~システム移行という名のデスマーチ

業務システムの開発案件では、最後にシステム移行と言う名のデスマーチがある。
ラフなメモ書き。

【1】業務システムの開発ではリプレース案件が非常に多い。
例えば、リプレース案件の発端は色々ある。
今までのCobolやVBのシステムをWeb化したい。
年々性能が悪くなった旧式のWebシステムを、Ruby on Railsのような最新のフレームワークのシステムへ変えたい。
iframeを使いまくった古いWebデザインを捨てて、アクセシビリティに配慮した最新のUIを持つWebシステムに変えたい。

すると、現行システムを廃棄して、新システムへ移行する開発プロジェクトもすごく多い。
いわゆるリプレース案件なのだが、普通はデスマーチになるパターンが経験的に多い。

システムのリプレース案件が最も危険な理由: プログラマの思索

リプレース案件が大変なのは、現行システムの機能は満たした上で更に機能追加してくるために、ひどいパッチ当てが発生しやすい点にあると思う。
保守性、移植性という品質特性がボトルネックになってしまうのだ。

アジャイル開発が重視する品質特性~保守性と移植性: プログラマの思索

また、リプレース案件では、現行ステムから新システムへ移行する作業が必要になる。
このシステム移行作業は、非常にリスキーな作業で、デスマーチになりやすい。
システムが変わったとしても、ユーザの業務に影響ないように、システムを入れ替えるのはすごく大変な作業だ。
サーバーの入れ替え、モジュールの配置タイミング、本番データの移行作業など、作業の大変さを考えるとキリがない。

【2】システム移行の方針はいくつかのパターンがある。
以下、説明してみる。

単純移行は、現行システムから新システムへ切り替えて稼働する手法。
ウォーターフォール型開発では、本番リリース日に新システムへ一斉に切り替わるために、前準備に相当の作業負荷がかかる。
直前まで修正していたモジュールをリリースの1週間前にはコードフリーズしておき、稼働確認する作業もある。

特に本番データ移行作業では、ユーザが直前まで使っていた本番データを新サーバーにインポートしないといけないから、作業時間をあらかじめ見積り、手順を十分にレビューして置かなければならない。

また、単にそのままデータを移すだけではなく、新しいコード値に採番し直してインポートする時もある。
その場合、採番し直すプログラム(移行ツール)を新規に作る必要があり、テストによる事前動作確認や、データ量によってどれだけの変換の時間がかかるかも計測するとなると、その分だけ工数が増える。
しかも、実際の本番データにクレジットカード番号などの個人情報が含まれていれば、本番データを使うこともできないために、単体テストではうまく動いても、実際の本番データ移行作業で障害が発生する時もある。
だから、とても気を使うものだ。

実際の移行作業では、全ての機能をすぐに本番稼動できない時もある。
その場合は、一部の機能を制限して、部分稼動させる手法もある。
例えば、新システムでは、データ量が増えた場合は画面操作を受け付けなくなる場合があるため、その場合は、あらかじめ開発者が本番環境からデータを抽出しておき、ユーザに届けて、手運用でカバーするやり方などがある。
その場合、システムの機能が全て使えない状況であることをユーザにも承諾してもらい、時間の猶予をもらって、その間に機能を改善する手法が取られるだろう。
つまり、顧客調整というプロジェクトマネジメント能力がかなり要求される。

単純移行は、移行手順は簡単だが、他の方式に比べてリスクが大きく、高い信頼性が要求される時が多い。

【3】並行稼動は、現行システムと新システムをある一定期間中は両方稼動させて、本番稼働日に新システムへ切り替える手法。
普通、並行稼動の期間は、ユーザが現行システムと新システムを両方使いながら、受け入れ検証を行ったり、新システムの使い方に慣れる期間になる。

並行稼動の利点は、新システムで本番障害が発生したとしても、並行稼働中は現行業務の影響を小さくできることだ。
だが、新旧のシステムを稼動させるために、サーバーが少なくとも2台は必要だし、リソースをかなり消費する。
そして、本番リリース日には現行システムから新システムに切り替わるために、単純移行時の問題点が必ず発生する。
しかも、並行稼動が終わる直前までの最新データを移行しなければならないので、単純移行の時よりも、作業時間もデータ量も制約が厳しくなる。
単純移行の作業よりももっと大変なのが普通だと思う。

【4】部分移行は、旧システムをサブシステムに分割しておき、旧サブシステムを新サブシステムへ順次移行する手法。
例えば、サブシステム単位に新規システムをリリースする手法は、段階リリースとも呼ばれる。
この手法は、アジャイル開発の手法に近いが、ウォーターフォール型開発を複数回繰り返してはリリースしていく開発スタイルなので、アジャイル開発とは厳密には違う。

いきなり全ての機能を稼動させるわけではなく、徐々に稼動するシステムを増やしていくので、システム障害が発生した時の影響が小さい利点がある。
また、先行リリースしたシステムの機能をユーザに使ってもらい、そのフィードバックを早めにもらうことができるので、その次のシステムのリリースにその内容を反映させる利点がある。

しかし、部分移行の弱点は、先行リリースしたサブシステムを保守しながら、裏では新規サブシステムを2次開発していくという並行開発にならざるを得ない点だ。
障害修正しながら、新しい機能を追加していくには、複数のブランチ間で簡単にマージできる強力な構成管理が必須だが、普通の開発ではデスマーチになりやすい。
せっかく障害修正したのに、新機能を追加したら、影響範囲の調査が不十分のためにデグレードしてしまう現象が多発しがちだからだ。

アジャイル開発が難しい理由の一つは、並行開発という構成管理のインフラが不十分な点があるからだろうと思っている。

【5】パイロット方式は、限定した部門で新システムを導入し、その後の運用を観察した後で部門全体を移行する手法。
パイロット方式の利点は、新システムを運用している部門が限定されているために、移行時に発生する問題による影響範囲を局所化できる点がある。
さらに、その運用ノウハウがたまった後に、部門全体へ展開すれば、運用のトラブルを未然に対応できる余地がある。

パイロット方式を使う状況は、ERPのような業務パッケージ製品を社内へ導入する場合が多いだろう。
つまり、一部の部門が先行して、新システムで業務を運用してみて、今までの業務の違いをユーザが確認したり、新システムでどんな効果が出たのかを調査することで、運用ノウハウを蓄積できる。
普通は、運用ノウハウは業務マニュアルとしてまとめられて、全部門へ展開される。

とは言え、実際はそんなにうまくいくこともない。
初めてのシステムなので、ユーザも慣れないし、実際に導入してみて、不足した機能が発覚したりする。
それら障害修正や機能改善のたくさんのパッチが先行システムに当てられて、まともに使えるようになって、ようやく全部門に展開される。
しかし、部門ごとに人の性格も違うし、業務も違うから、使ってみて初めて、不足した機能が分かる時も多い。

また、パイロット方式を行う場合、ユーザ企業の情報システム部門がどれだけの力量を持っているのか、という点も重要だ。
先行リリースする部門とSIの間で仲介役として振舞わなければならないし、全部門に展開する場合は、他の部門にも配慮しないといけない。
SIは情報システム部門と一体化して、新システムをアピールしながら、ユーザの現場の業務を改善していくミッションを進めないといけない。

【6】システム移行作業が難しい理由をまとめると、以下の点があげられる。
一つ目は、移行作業に試行錯誤しながら試す方法が許されていないために事前の準備や計画作りに手間がかかること。
二つ目は、情報システム部門など数多くのステークホルダーと利害調整するマネジメント能力が必要とされていること。
三つ目は、データ移行や並行開発で技術力が要求されること。
このような理由があるからだろうと思う。

| | コメント (0)

2013/05/25

ERPの落とし穴part3~外部システム連携がプロジェクトのボトルネック

業務システムを開発したり保守している時に、本番障害が多発したり、想定外の障害で業務が止まったりしたりするのが「外部接続」という名の外部システム連携機能だ。
今までの経験も含めて考えたことをラフなメモ書き。

【参考】
ERPの落とし穴part1~SW開発ではない。要求開発だ!: プログラマの思索

ERPの落とし穴part2~業務の裏には会計あり: プログラマの思索

【1】業務システムは基本は何らかのERPを真似たり、そのまま取り入れることで実現している。
その時、一つのシステムで全ての業務をカバーできるわけではないので、複数のサブシステムを作って各システムを連携することで、ユーザ企業の業務をカバーする方式設計が多い。

例えば、基本的な業務システム(仕入れ・売上・請求・在庫など)の他に、会計システムは別システムで作っておき、業務が発生したら自動仕訳が起きて、会計システムへデータが流れるようにする。

例えば、物流や在庫に至る全ての業務をSCMでシステム化した後、経営者が経営分析したりするための情報系システムへ連携するために、日々の売上や原価、物流の情報を日次・月次で集計して送ったりする。

例えば、仕入先から仕入れた商品のデータや仕入伝票をEDI経由でデータを受信し、日次で業務システムに取り込み、発注や物流の業務に使ったりする。

例えば、請求や発注業務で、ユーザ企業が開設している銀行の口座預金からEB連携(あるいはファームバンキング)、仕入れ代金や売掛金の回収を月末の締め請求で一括で支払ったり、入金したりする。

例えば、Felicaなどの電子マネーで決済する場合は、業務システムから送付したいデータを商取引の標準形式に変換して、SOAPのようなAPI経由でデータを送受信したりする。

つまり、基幹系業務システムとは、自社内にあるたくさんの業務システムと連携するだけでなく、仕入先のような外部企業のシステムとEDIで接続していたり、銀行のEB連携したり、SOAPでやり取りしたりする。
あるいは、今流行のソーシャルなデータを連携したいがために業務システムとCRMと連携したり、情報系システムへ連携するなどのやり方もあるだろう。

【2】外部システム連携には幾つかの用語がある。

EDIは、外部システムと標準フォーマットの商取引データ(受発注、決済など)をやり取りする仕組み。
FTPやHULFTなどのプロトコルで集配信サーバーを使う外部接続の方式が多いだろう。
電文のようなテキストファイルやバイナリファイルをやり取りするので、原始的なアーキテクチャとも言えるが、普通は最も基本的なアーキテクチャと言える。
EDIツールと言えば集配信サーバーかな。
バッチ処理が基本なので、COBOLがよく使われている。
枯れた方式設計なので、ノウハウは結構ある。

EAIは、異なるシステム間でアプリケーションの統合・連携を行うための仕組み。
データ連携や中継を行う中核サーバーであるハブと、ハブからデータを送受信する各システムというスポークから成り、ハブ&スポークのパターンで実現されている。

EAIツールはミドルウェアであり、単なるデータ連携だけでなく、システムごとのデータ形式やプロトコルの違いを吸収する変換処理や、受け取ったデータをシステムごとに振り分けるルーティング機能、ワークフロー制御の機能などがある。
例えば、MSのBisTalkServerなどがあるらしい。
新製品のミドルウェアを導入する場合は、ノウハウがないために、試行錯誤しながら運用に苦労する時が多い。

EAIをオブジェクト指向っぽく、サービスの観点で、システム間でメッセージをやり取りしあう仕組みがSOA。
SOAのプロトコルはSOAPと呼ばれ、XML形式で、データやAPIなどが指定されている。
WSDLなど複雑な標準形式になっているので、コーディングがかなり面倒。

EDIとは 【Electronic Data Interchange】 - 意味/解説/説明/定義 : IT用語辞典

EAIとは 〔エンタープライズアプリケーション統合〕 【Enterprise Application Integration】 - 意味/解説/説明/定義 : IT用語辞典

SOAとは 〔サービス指向アーキテクチャ〕 【Service Oriented Architecture】 - 意味/解説/説明/定義 : IT用語辞典

【3】EDI・EAI・SOAのような外部システム連携が必要な理由は、いくつかある。
一つは、ユーザ企業の全ての業務を一つのシステムで実現するのはコストも期間も難しいため、段階的にサブシステムごとに作っていかざるを得ないこと。
だから、普通のユーザ企業の業務システムは、たくさんのサブシステムが乱立していて、情報システム部門の人すら全てのシステムを把握できておらず、訳が分からない状況になっていることが多い。
当然、そこからシステムの障害が発生しやすくなる。

もう一つは、仕入先や取引先、銀行や電子マネーなど、既存の外部システムと連携したい要件が年々増えていること。
だが、外部の企業が自分たちの開発プロジェクトの都合に合わせてくれるとは限らないので、プロジェクト管理の部分の重要性がとても大きい。

例えば、商取引データの標準形式やAPI、プロトコルを早めに公開してくれるように突っついたり、接続テストを行う期間やテストデータの送受信のタイミングを事前に調整しなければならない。

しかし、接続テストをいざ実施してみると、想定外のデータで連携されて障害が起きたり、データ量が多いと性能が落ちたりタイムアウトしたり、提示された文書にあるAPIやプロトコルが間違っていたり、そもそも依頼した時間に送受信できなかったりする。

しかも、接続テストで発覚した障害の原因調査は再現性がなくて難しかったりする。
あるいは、障害の原因が外部企業が持つ外部システムのプログラムにバグがあると分かっても、外部企業が納期までに直してくれなければ、接続テストが完了しないまま本番リリースせざるを得なくなる。
そうすれば、本番リリース後は、障害が多発して、ユーザの業務に支障が出るだけでなく、開発メンバーもその対応に追われて疲労してしまうだろう。

そんな細かな障害は接続テストを実施しなければ判明しないので、経験のあるプロマネは、外部接続テストを早めに実施できるようにスケジュールを組んだり、有能なメンバーを配置したりして、可能な対策は取っておく。
そんなプロマネは、外部接続テストが開発プロジェクトのボトルネックであることを知っているのだ。

つまり、アーキテクチャ設計の弱さをプロジェクトマネジメントでカバーするパターンが現実ではとても多いと思う。

【4】外部システム連携は、まさにITアーキテクトと言う役割の人が、システム全体の観点で、実装レベルよりもユーザ観点のレベルで設計スべきもの。
自前で作るよりも、外部システムを連携して、本来の業務の要件を実現できるように設計する。
その外部システム連携の手法としては、EDI・EAI・SOAなどいろんな手法があるので、コストや納期の観点も入れて、取捨選択する。

でも、外部システム連携のアーキテクチャ設計のノウハウはバラバラに存在していて、パターン化されていない。
しかも、英語3文字の略語が氾濫しているために、何が重要なのかも把握しにくい。
そして、年々増えていくサブシステムを更に連携するために、たくさんのEDIやSOAが作られて、どんどん複雑化していく。
そんな開発作業が、ユーザ企業の本来の価値になっているのか、という評価も忘れたまま進んでいく。

アーキテクトという言葉が広まり、アーキテクトの役割の重要性が知られているにも関わらず、そのアンバランスな事実が業務システム開発の難しさを助長しているように思う。

| | コメント (0)

第8回RxTstudy勉強会でRedmineコミッタが来られます

6/22に開催される第8回RxTstudy勉強会でRedmineコミッタが初めて大阪に来られます。
Redmineに興味のある方はご参加下さい。

第8回RxTstudy : ATND

■タイムスケジュール

詳細は決まり次第更新いたします。

12:40- 開場
13:00- オープニング
13:10-14:10 @hakuraiさん「Gitの話」(仮)
14:10-14:20 休憩
14:20-15:20 まるやま(@marutosijp)さん(Redmineコミッター)「Redmine本体の開発スタイル(仮)」
15:20-15:30 休憩
15:30-16:30 前田(@g_maeda)さん(「入門Redmine」著者)
16:30-16:40 休憩
16:40-17:30 パネルディスカッション
17:30- クロージング
17:40- 後片付け

18:30 ? 会場近辺にて 懇親会! (LTをやるかも?)

■セッション内容

※ 随時更新します。

◇パネルディスカッション  
  「Redmineに期待すること」(仮)

   パネラー:まるやまさん、前田さん、川端さん、阪井さん、赤羽根さん
   モデレーター:あきぴーさん

本セッションは株式会社 アジャイルウェア様の後援です。

| | コメント (0)

ソフトウェア開発の「新」3種の神器

ソフトウェア開発の「新」3種の神器に関する記事を見つけたのでメモ。
日経Systems2013年6月号に掲載されている。

【元ネタ】
記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

記者の眼 - 「新3種の神器」で開発現場を改革しよう:ITpro

【1】興味深いのは、アンケート結果では、「「Microsoft Project」(MS Project)で48.7%、2位はオープンソースソフトウエア(OSS)の「Redmine」で40.4%、3位も同じくOSSの「Wiki」で32.4%だった」こと。
他に、TracやTFSも上位に上がっている。
日本でRedmineの人気は高いのが意外だった。

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blogの記事で、Redmineのガントチャートにおけるイナズマ線描画機能は 伊藤忠テクノソリューションズ株式会社 (CTC) の提供だったという話があるように、日本ではRedmineのニーズが高いのかもしれない。

また、MSProjectとRedmineを併用している特徴もなるほどと思う。
現場ではRedmineで運用し、客向けや上司にはMSProjectのガントチャートで進捗報告する手法を使い分けているのだろう。
この考え方は、基幹系業務システムの発想と同じように思える。
基幹系業務システムを使う人は現場の担当者であり、経営者は普通、現場にタッチしないからそもそもシステムに触れることもない。

でも、プロジェクトの進捗や課題、品質に関する情報はすべてRedmineの背後にあるDBに一元化されているのだから、顧客や上司が知りたい情報の元ネタはDBにある。
そのデータをどんな観点で抽出して見せるのか?
データが一元化されているからこそ、プログラムを組めばいくらでも好きなだけメトリクスを抽出できる。
この発想も、BPR、ERPに似ている。

Redmineを業務システム化するアイデア~メトリクス集計の本質は集計バッチ処理: プログラマの思索

定量的プロジェクト管理ツールはIT企業の基幹システムを目指す: プログラマの思索

Redmineが使いづらいと言う質問~開発業務をRedmineへマッピングできていない: プログラマの思索

【2】ソフトウェア開発の「新」3種の神器とは、「Redmine」「Jenkins」「Chef」を指すらしい。
ちなみに、@haru_iidaさんが提唱された3種の神器はITS・SCM・CIだった。

アンケート結果では、JenkinsやChefの利用度はRedmineに比べて少ない。
現場リーダーの意識はプロジェクト管理に向いていて、開発インフラまで回っていないのかもしれない。

しかし、JenkinsやChefが重要な理由は、ビルド管理やリリース管理、サーバー構築をすべて自動化できることによって、アジャイルに開発できることだと思う。
実装できれば即座にリリースして納品できるだけでなく、顧客から早くフィードバックをもらうことで、ソフトウェアを早く機能改善できる利点がある。

クラウドの本質はインフラ管理のIT化: プログラマの思索

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

また、Jenkinsには「メトリクス収集ツール」「ジョブ管理ツール」という2つの側面を持っていて、そこにたくさんの可能性を秘めていると思う。

メトリクス収集ツールJenkinsという観点では、定期的にプログラムをビルドしたりテストすることでメトリクスを自動収集して集計する機能がJenkinsには元々付いている。

Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索

Jenkinsで静的コード解析を常時自動化する: プログラマの思索

ジョブ管理ツールJenkinsという観点では、定期的にバッチのように処理を一括実行する機能が元々付いているので、高機能化したCronとしてバッチジョブを管理するツールへ発展できる可能性を秘めている。

Jenkinsをジョブ管理ツールとして使うアイデア: プログラマの思索

Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索

Jenkinsをジョブ管理ツールとして使う事例part2: プログラマの思索

Jenkinsのジョブフローを可視化: プログラマの思索

【3】だが、Jenkinsの普及がまだ広がっていない理由は、それだけではないと思う。
Jenkinsを使いこなすには、ビルドスクリプトを作って定期実行しなければ意味が無い。
つまり、ビルドやリリースを実現するプログラムがなければ、Jenkinsはただの箱にすぎない。
その意味ではChefも同じ。
逆に、Redmineは一度インストールすれば、画面からチケットを登録してすぐに運用できるお手軽さがある。

Jenkinsの今後の課題は、ビルドスクリプトをAntやMavenのようなJavaではなく、Rakeのようにもっと強力で表現力の高いRubyへシフトして、ユーザを拡大していくことにあるのではないか、と思っている。
Jenkinsを紹介する本や記事で、いまだにAntの使い方を説明しているのはもはや時代遅れだと思う。

Chefのように継続的デリバリーに関するツール群のほとんどがRubyで実装されている事実からしても、その傾向は明らかだと思う。

CIツールはビルドスクリプトのプログラミングに依存している: プログラマの思索

僕は開発プロセスをツールでサポートしていく発想が好きだ。
上から目線で理論を盾に現場を管理するよりも、現場で役立つツールを駆使しながら、ノウハウというプラクティスを生み出していく手法の方が好きだ。

高速道路で走る車の速度はエンジンに依存する~ツールが良くてもプロセスの成熟度はチーム次第: プログラマの思索

今後もその観点で追いかけてみる。

| | コメント (0)

2013/05/22

チケット駆動開発の適用範囲part5~どの工程をカバーするのかという質問

チケット駆動開発を実践していると話すと、チケット駆動開発ではどの工程をカバーしているのですか、という質問をよく受ける。
考えたことをラフなメモ書き。

【1】「チケット駆動開発ではどの工程をカバーしているのですか」という質問は、マネージャやリーダーからよく聞かれる。
彼らの意図としては、ウォーターフォール型開発において、チケット駆動開発がどの工程にうまくはまるのか、どんな利点があるのか、を知りたがっているようだ。
特に、開発工程のタスク管理やテスト工程の障害管理以外に、要件定義や設計の工程でも使えるのか、という疑問があるらしい。

僕は、チケット駆動開発は特定の工程をサポートするわけではなく、プロジェクト管理全般をサポートしている、と回答するようにしている。
チケット駆動開発は本来、ソフトウェア開発のタスク管理をチケット管理に置き換えることで、プロジェクト管理をマネージャのようなベテランだけでなく、1年目の開発者でも体験できるような仕組みだと思っている。

ソース管理やビルド管理とチケット管理が連携することによって、チケットを起点としてソース修正からモジュールのビルド、リリースに至るまで、一括管理できる利点がある。
つまり、チケット駆動開発は、ソフトウェア開発のインフラに相当する側面がある。

【2】チケット駆動開発を開発者の観点で見ると、ToDoリストの管理に近い。
例えば、Redmineのチケット管理もそうだし、GitHubやBitbucketのIssue管理も同様だろう。

すると、ソースという成果物をソース管理のリポジトリで管理する時に、チケットに仕様変更や要望、障害報告を書いておけば、チケットが起点となってソースが修正されてブラッシュアップされていく。
つまり、チケットとソースが連携することによって、成果物と仕様変更を一括管理できる。
ここから「No Ticket, No Commit」という運用ルールが生まれている。

開発者の観点におけるチケット管理の運用においては、設計だけの工程、開発だけの工程、テストだけの工程はありえない。
一つのチケットで、どのような仕様で確定したのか、どのように修正したのか、リリース後のユーザの評価はどうなのか、という履歴が全て残る。
その意味では、チケット駆動開発はすべての工程をサポートしている。

【3】チケット駆動開発を管理者の観点で見ると、プロジェクト管理として使いたい要望が多い。
マネージャやリーダーとしては、進捗管理、品質管理、課題管理をRedmineのようなチケット管理ツールで、プロジェクトに関わる全てのアクティビティを管理したいのだ。
そうすれば、Redmineのチケットを常に監視することによって、プロジェクトがどんな状況にあるのか、をリアルタイムに把握することができる。

彼ら管理者としては、チケット管理ツールの進捗管理機能を強化して欲しいという要望が多い。
例えば、Redmineの最新版2.3においては、ガントチャートにMS ProjectのFS関係(先行・後行く)やイナズマ線を表示する機能が追加されている。

Redmine 2.3新機能紹介: ガントチャートでチケット同士の関係とイナズマ線を表示 | Redmine.JP Blog

上記の記事には「イナズマ線描画機能は 伊藤忠テクノソリューションズ株式会社 (CTC) 様のご協力により実現しました」という文言が記載されていて、大手SIの管理者がRedmineのガントチャートをもっと強化して欲しい要望を持っていた事実を示していると思う。

管理者としては、工数管理もチケット管理で代用したいものだ。
「チケット無しの作業は不可」(No Ticket, No Work)を運用しているならば、チケットに必ず予定工数と実績工数が記録されるので、後から集計可能になる。
そうすれば、EVMの仕組みを使って、CPIという開発ペースを計算して総コストを予測することも可能になる。

管理者の観点では、チケット駆動開発はメトリクス収集ツールという側面がある。
管理能力の優れたマネージャは、単なるプロジェクト運営だけでなく、プロジェクト終了後にメトリクスをきちんとまとめておいて、そのノウハウを他のプロジェクトへ適用したり、自分の研究材料に使ったりしている。
つまり、できるマネージャはきちんとPDCAサイクルを回していて、特にCheck、Actionの部分が優れている。

【4】チケット駆動開発の弱点はいくつかある。

まず、チケット集計というビューが弱い事実があると思うが、個人的には、RedmineのようなRailsアプリならば、不足した機能はRubyで実装すれば良いという問題に置き換えられると思っている。
プロジェクト管理の問題をプログラミングの問題にすり替えることによって、もっと色んな手法が試されるべきだと思う。

また、チケット駆動開発のロールは管理者・開発者・報告者という障害管理ツールの名残りがあるために、Scrumのようにユーザを巻き込んで、開発チームとユーザ、プロジェクトマネージャのバランスを保つ仕掛けは実装されていない弱点がある。
でも、顧客自身に仕様追加や障害報告をチケット登録するような運用ができるならば、チケット上で顧客と開発チームが相互対話する環境が整うので、顧客を巻き込んだ開発スタイルは可能のはずだ。
ITILのようなインシデント管理・問題管理・変更管理プロセスに当てはめれば、多分うまくいく部分があると思う。

それから、チケット駆動開発はアーキテクチャ設計やテスト管理には有効ではない。
テスト管理にはTestLinkなどのようなテスト管理ツールが必要だろうと思っている。
アーキテクチャ設計は、プロジェクト管理とは別のスキルが必要だ。

最近アジャイル開発がソフトウェア開発で有効と思われている理由の一つは、ソフトウェアのアーキテクチャ設計で絶対のベストプラクティスが存在しないために、その時代の技術を使って試行錯誤しながら作っていかざるを得ない事実があると思う。
つまり、アーキテクチャ設計ないしソフトウェア工学が分野として不十分ないし弱いために、アジャイルという開発プロセスでその弱さを代用している面があると思う。

その辺りはもう少し考えてみる。

| | コメント (0)

2013/05/19

Jolt Awardsのリスト

Jolt Awards は プログラマ向けのソフトウェ関係の書籍を扱う総花的なアワードらしい。
1990年からの20年間でどんな本がアワードとして選ばれてきたのか、興味を引いたのでリンクしておく。

【元ネタ】
Jolt Awards の 20年 - etc9

steps to phantasien t(2007-07-14)

【1】個人的な興味はオブジェクト指向設計やアジャイル開発プロセス。

アジャイルソフトウェア開発 (The Agile Software Development Series)」には、アジャイルマニフェストが生まれた背景が書かれているらしい。
今度読んでみたい。
SpolskyとBobおじさんの対決にも、「アジャイルソフトウェア開発の奥義」で有名なRobert C Martinが発起人となり、いろんな議論をした経緯が書かれていて面白い。

アジャイルマニフェスト10周年 - アジャイルマニフェストはどう生まれたのか - kawaguti の日記 (id:wayaguchi)

【2】Steve McConnellも意外に沢山の本を出している。
彼の本で有名な著作は、「Code Complete第2版〈上〉―完全なプログラミングを目指して」「Code Complete第2版〈下〉―完全なプログラミングを目指して」と、「ソフトウェア見積り―人月の暗黙知を解き明かす」ではないだろうか。

ソフトウェア見積り―人月の暗黙知を解き明かす」では、マネージャやリーダーが必ずぶつかる見積り技法について詳しく書かれていて、とても参考になった。

Steve McConnell著作の下記の本「「ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)」」も読んでみたいと思った。

【3】技術的な流れを見ると、プログラミング言語はC++→Java→Ruby→Scala、Lispなどの関数型言語へ進化している。
開発プロセスもPSPなどからアジャイルへ、設計技法もオブジェクト指向からWebのUIへ、と移り変わっているようだ。
こういう流れを見ると、今後、ソフトウェア開発はどのように進化していくのか、を色々考えるのが楽しい。

| | コメント (0)

テスト駆動開発による組み込みプログラミングも良い本です

テスト駆動開発による組み込みプログラミング」を頂きました。
ありがとうございます。
既に色んな方が感想を書かれています。

【元ネタ】
「テスト駆動開発による組み込みプログラミング」 - Yasuo's Notebook

[書評]テスト駆動開発による組み込みプログラミング | Ryuzee.com

O'Reilly Japan - テスト駆動開発による組み込みプログラミング

書籍『テスト駆動開発による組み込みプログラミング』:柴田 芳樹 (Yoshiki Shibata):So-netブログ

"これこそ私の探していたものだった" - テスト駆動開発による組み込みプログラミング: 菊と書評

テスト駆動開発は設計技法である~組み込みアジャイルコーチ James Grenning さんインタビュー: プログラマの思索

C言語でTDDをやる場合、JavaやRubyに比べると、リフレクションやモックのプログラミングが難しいため、C特有のテクニックが必要になる。
テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」では、テストダブルのようないくつかのテクニックが公開されているので、組み込み系の人にとっては注目すべき内容だろう。

TDDによる設計の観点では、SOLIDという設計原則でまとめられている。
アジャイルソフトウェア開発の奥義」に詳しく書かれている。

・単一責任の原則(SRP)
・オープン・クローズドの原則(OCP)
・リスコフの置換原則(LSP)
・依存関係逆転の原則(DIP)
・インターフェイス分離の原則(ISP)

詳細は「オブジェクト指向の法則集@石井勝さん」のページが詳しい。

TDDでプログラミングする利点の一つは、テストしやすいインターフェイスを考えることで、自然にプログラム設計でき、しかもプログラムの品質も良くなることだろう。
手続き型言語でガリガリ書くと、どうしても長いメソッドになり、後からテストしにくい設計になってしまいがち。
ドライバやスタブでテストできるようにするには、そのようなインターフェイス設計にしなければならないからだ。

テスト駆動開発による組み込みプログラミング ―C言語とオブジェクト指向で学ぶアジャイルな設計」は組み込み系の人だけでなく、JavaやRubyの人にも参考になる本だと思います。

| | コメント (0)

2013/05/18

業務システム設計の隠れた要件~会計監査やシステム監査

業務システムを設計していると、業務システムの設計の正当性を保証するステークホルダーが実はユーザでもITの技術者でもない事実がある。
考えたことをラフなメモ書き。

【元ネタ】
「売上伝票」を問い直す: 設計者の発言

【1】渡辺さん、@hatsanhatさん、@sugimoto_keiさん達と、販売管理システムで売上伝票はそもそも必要なのか、という議論があった。
元々の議論では、販売管理システムにおいて、売上伝票という形式はIT化される前のデータのフォーマットに過ぎず、売掛金履歴や出荷履歴などの業務データから、売上計上されるタイミングで自動仕訳されるのではないか、という考え方があった。
つまり、売上伝票という古くからある帳票に囚われるべきではない、という意見に落ち着いた。

その議論の中で僕が改めて疑問に思ったことは、販売プロセスにおいて売上計上のタイミングはどこなのか、と言う疑問。
売上に関する業務は、IT化する時に重要なポイントとして、売上の計上タイミングをどの時点にするか、という点がある。
小売業であれ、製造業であれ、IT企業であれ、売上計上のタイミングは微妙に違う。

普通の会社では、受注→出荷→売上計上→月末に締めて請求→翌月末に入金されて売掛金回収のような流れが多い。
つまり、売上を計上するタイミングは出荷という実績が発生したタイミングが多い。
何故なら、出荷した時点で自社から商品や製品が離れて、他へ責任が移ってしまうから。
このタイミングで、「売掛金//売上」という仕訳が発生する。

そして、日本の企業の大半は、月末に締めて、売掛金としてまとめて請求することで、翌月に一括入金される業務が多い。
つまり、当座預金へ入金されタイミングで「当座預金//売掛金」という仕訳が発生し、売掛金が相殺される。

この時、売上計上を出荷のタイミングではなく請求払いにした場合、本来の売上計上のタイミングが遅れてしまうために、会計監査で意図的な不正を行なっているという指摘を受ける場合があるらしい。

小売業や製造業ならば、倉庫から出庫した段階が多いが、IT業界ならば、顧客に納品して検収が終わらなければ売上計上できない時が多いだろう。
何故なら、ソフトウェアを納品されたとしても、業務でまともに使えなかったり、顧客の要望とずれている部分がたくさんあったりするので、顧客としては、検収してみてOKにならなければ、SIにお金を払いたいとは思わないからだ。

すると、IT業界の方が小売業や製造業に比べて、売上計上のタイミングがかなり遅い弱点がある。
つまり、会計監査の都合上、時代に合わなくなってきたために、ITプロジェクトでも工事進行基準を適用するような流れになっているのではないかと思う。
受託請負案件でも、工事完成基準のように、最後に売上を一括計上するやり方は、会計監査の観点では、顧客とSIが丼勘定でやり取りしているのではないか、と指摘されかねないのだ。

【2】そんな流れを考えてみると、販売管理システムにおける売上計上という機能は、最終的には税務署へ提出するBS・PLなどの会計帳票を出力するための機能でもあるために、税理士や会計士の観点で、会計監査が問題ない要件を満たさなければならないと思う。

すると、販売管理システムという業務的にはかなりシンプルなシステムでさえも、そのアーキテクチャの妥当性を保証する人は、顧客やSEではなく、税理士や会計士であるという点が出てくる。
販売管理という業務がシステムで運用できたとしても、そのシステムで作られた会計帳票が正式に使えないとしたら、システムとして不十分だ。
現在、業務システムのアーキテクチャ設計をIT技術者だけが保証することが原理的に難しくなっているのではないだろうか?

この例を更に膨らませてみると、最近の業務システムの要件として、会計監査やシステム監査、コンプライアンス(内部統制)などの監査要件の比重がかなり大きいと思っている。
業務を代行するシステムが意図的な不正を行なっていない、という要件を保証するために、それら監査の要件を満たすように、業務システムの機能がどんどん複雑化している現状がある。

個人的に思うのは、システム監査や会計監査は確かに必要だけれども、日本人はあまりにも真面目に運用しすぎているために、ビジネスのスピードを落とす方向に頑張りすぎている面があると思う。
だから、アジャイル開発という流れにも日本のIT業界は乗り遅れてしまっているのではないか、という気もしている。

| | コメント (1)

2013/05/14

Chefで構築するRedmine環境

ChefでRedmine環境構築する資料が公開されていたのでメモ。
ラフなメモ書き。

【元ネタ】
Chefで構築するBP-Redmine環境

サーバー構築を構成管理とTDDで作業する時代になってきた: プログラマの思索

クラウドデザインパターン~インフラ方式設計のベストプラクティス集: プログラマの思索

内容が面白い。
Redmineはミドルウェア。
だから、Chefを使う。
つまり、ApacheやMySQLの設定はもちろん、Redmineに必要なgemのインストールも全てChefで手続き化してしまう。
その利点は、VMやAWSのように仮想環境で構築すれば、何度も環境を壊しては作り直すことができるので、アジャイルな環境構築がやりやすくなる点だ。

悩みも面白い。
RedmineのバージョンアップにChefでどうやって対応するか?
プラグインを入れていたり、カスタマイズしていたら、単純にRedmineを配置してrakeするだけでは動作しないだろう。
ミドルウェアのバージョンアップに伴う移行作業は、他のシステム保守でも結構大変だ。

また、サーバー10台で環境構築する方法も興味深い。
DBサーバーやApache、SCMツールが各サーバーに分散していれば、どのような環境で作るか?
SSLや公開鍵・秘密鍵のようなSSHはどのように設定すべきか?

2013年の現在は、サーバー環境の構築もアジャイルに作業してしまう時代。
単純作業も業務手順もサーバー構築も、全てプログラムに変換できるなら、そこにアジャイル開発を適用できる隙間がある。
色々試してみる。

| | コメント (0)

2013/05/11

わかりやすいAgile開発の教科書はお勧めです

わかりやすいアジャイル開発の教科書」を献本して頂き、じっくり読んでみた。
アジャイル開発を実践する時に最初に参考にするガイドブックとして使えるのではないかと思う。
感想を箇条書きでラフなメモ書き。

【1】アジャイル開発が目指すものは何なのか、というWhyを説明してくれている。
アジャイル開発そのものを自己目的化しないためにも必要。

【2】ソフトウェアの価値とは何なのか?
この部分は、日本のIT業界が遅れている所だと思う。
理由は、受託開発案件が多いために、プロジェクトを納期までにとにかくCloseさせることに精一杯であり、納品したソフトウェアやシステムが顧客に役立っているのか、という観点まで頭が回らないから。

普通は、1次開発で赤字を出しながらも何とか本番稼動させて、2次開発や運用保守で、顧客の業務と実システムの不一致や、業務の改革まで目を向けるようになる場合が多いように思う。
本来は、システム導入によるIT化によって、ユーザ企業の業務改革に役立てたいのだが、肝心のシステムを稼働する品質に持って行くのが、現場ではとにかく大変なのだ。
アジャイル開発はその問題への対処の一つとしてあげられているわけだ。

では、価値づくりのプロセスとして具体的にどのようにやれば良いのか?
わかりやすいアジャイル開発の教科書」では、要求開発におけるコタツモデルを参考にしながら、経営者・IT技術者・業務担当者の観点で、あるべきシステム像を見出そうとしている。
この考え方はなるほどと思う。
但し、立場が異なる3つの組織を束ねて何らかの結論を導く必要があるから、高度なファシリテーション能力やマネジメント能力が必要とされるだろうと思う。

【3】「わかりやすいアジャイル開発の教科書」で面白いのは、実体験に基づいた事例がふんだんに紹介されている点だ。
著者の方の深い経験がすごく感じられる。

「価値が分からないストーリーカード」は要件定義に慣れていない人がはまりやすいアンチパターン。
技術者という立場を離れて、顧客の立場で考えることができるか、という点が大切。

「タスクカードの書き方がバラバラ」も、プロジェクト管理やタスク管理に慣れていない人に多いアンチパターン。
どんな作業をして欲しいのか?
アウトプットは何なのか?
作業しやすいタスクの粒度に注意しているか?
この辺りは、チケット駆動開発を実践しているととてもよく分かる部分。

「%マジック」もありがちなアンチパターン。
ウォーターフォール型開発では、1機能の進捗を工程別に%で計算する時が多い。
特に工事進行基準でプロジェクトの売上計上を実施しているなら尚更だ。
90%まで終わりました、と報告を受けたのに、いつまで経っても作業が完了しない場合が多い。
アジャイル開発の観点では、いくら設計書を作ったとしても、プログラムを書いたとしてもテストしていなければ、動くプログラムがなければ進捗はゼロに等しい。
チケット駆動開発を実践していると、ワークフローをどのように決めて運用するのか、という問題に置き換えられるだろう。

「サインアップの注意」としては、本来は、担当者自らタスクを取りに行くハッピーサインアップであるべき。
とは言え、プロマネの立場としては、プロジェクト運営上、役割が漏れていないタスクがないか、常に確認する必要はある。

「KPTが飽きられた」ケースもよくある。
チームで毎週いくら問題を出したとしても、問題が解決されて問題が減らないと成長している実感が無い。
KPTが上手く回っている時は、Problemにあがった問題に対し、Tryでいくつかの解決案が提示されて、実際に実行した結果、解決されて、そのノウハウがKeepに入り、最後は暗黙知としてKeepから消える。
KPTを上手く回すには、チームに変化や成長が必要だと思う。

「ペアプロがトレーニングになってしまう」場合もよくある。
特に、ペアの二人の能力差が大きい場合は特にそうだ。
だから、ペアを固定せずに、チームメンバー全員に技術ノウハウや業務ノウハウが共有されるようにどんどん回すべき。
ソフトウェア開発では一人で作業することはほとんどなく、ペアプロや本番リリース作業の立会のように同一時間帯に同一の場所で二人で作業するときもあれば、コードレビューや受入検証のように非同期で二人が成果物を作ってチェックし合う(ペア作業)時もある。
ペアプロやペア作業を意識してチームに浸透させれば、メンバーの作業の能力が平均化されるため、トラックナンバーが1となるリスクを減らすことができるし、ジョブアサインの選択肢が増えるのでプロマネとしても助かる。

【4】第4章「アジャイルを現場に定着させよう」の部分は、ファシリテーターとしてチーム運営する時に役立つノウハウが詰め込まれている。
アジャイル開発の面白さは、TDDやCIのような技術面と、チームビルディングの観点があると思う。
各メンバーの専門能力を組み合わせて、チームをいかに有機的に形成していくべきか、という手法について、アジャイル開発にはたくさんの事例が今までたくさんあげられてきた。
プログラマ出身のプロジェクトリーダーやプロジェクトマネージャにとって、最も役立つ部分ではないだろうか?

わかりやすいアジャイル開発の教科書」を最初に読んだ時、読者層は開発者が対象と思ったけれど、何度も読み直すうちに、現場リーダーが本来読んで欲しい対象なのかな、と気づく場面が多かった。
色んな人が、自分の役割や立場の観点で読めるのだろうと思う。
また、チケット駆動開発をアジャイル開発のタスク管理の事例としてあげられていたのも嬉しかった。

個人的には、「わかりやすいアジャイル開発の教科書」に描かれている絵が可愛いので、内容が難しくない印象を受けるのも良い点になるかなと思う。

| | コメント (0)

2013/05/07

ソフトウェア開発における「かんばん」とは何か

@daipresentsさんが、ソフトウェア開発における「かんばん」をWikipeidaに記載していたのでリンクしておく。
内容が整理されているので、大変参考になる。

【元ネタ】
Twitter / akipii: @daipresents さんがWikipediaに書いた「かんばん」の説明。これは力作! アジャイル開発に携わる人は必見かな。かんばん (ソフトウェア開発) - Wikipedia http://bit.ly/15jvK8O

かんばん (ソフトウェア開発) - Wikipedia

【1】上記の記事では、日本の製造業が生み出した「かんばん」をソフトウェア開発へ適用した「かんばん」として説明している。
「かんばん」の最大の特徴は、上記の記事にあるように、「かんばん」を仕掛品(Work-in-progress)という未完成の中間物とセットで運用することで、仕掛品を減らして在庫を減らし、無駄を省く点にある。

仕掛品がかんばんという製造指示書とセットになるという意味は、製造指示書の紙に仕掛品の品質や製造方法、数量、納期などが全て書かれているがゆえに、工場内のすべての作業工程が見える化されていることだ。

また、製造業にいる人ならば、仕掛品という言葉が「製品(完成品)」の状態の意味だけでなく、工業簿記における資産科目の一つ、原価管理すべき対象として捉えているだろう。
仕掛品という概念を使うことによって、倉庫にどれだけの未完成の中間物が作られて、どれだけの資産価値があり、経費が発生しているか、を計算できる。

【2】「実践 反復型ソフトウェア開発」の6.10節「トヨタのカンバン方式とバグ追跡システム」では、BTSの障害管理票が製造業の仕掛かんばんに似ているというとても意味深い意見を述べている。
製造業とソフトウェア開発の「かんばん」の特徴の対比は以下になる。
(以下、→は僕が理解してイメージしている内容)

【2-1】<製造業のかんばんの運用ルール>
・かんばんは必ず現物につけておく
 →かんばんは製造指示書ゆえに、部品という現物とセットにして、いつでも検査できる状態にしておく。

・かんばんと在庫部品を1対1に対応づける
 →在庫の部品を管理しやすくするために、かんばんと部品を1対1にひもづける。

・かんばんがなければ生産を開始しない
 →かんばんという製造手順が書かれた紙がなければ、作業してはいけない。
  かんばんが届いたら、部品も一緒に届くので、その時点から作業を始める。

・かんばんが到着した順に生産する
 →消費部門や後工程で必要になった部品を補充するタイミングでかんばんが発行されるため、かんばんが到着する順序には意味がある。

・流通しないかんばん(紛失)に注意!
 →かんばんを紛失すると、かんばんとセットになっている部品を検査できないので、後工程の作業者が困る。

・かんばんの枚数を減らしていく
 →工場内で流通するかんばんの枚数を減らすということは、かんばんと1対1にセットになっている在庫部品が減ることを意味する。
  かんばんにおける改善活動とは、かんばんを意図的に減らすことによって、現場で課題やボトルネックを出現させる点にある。
  つまり、かんばんを減らしすぎて、準備すべき部品がないために作業できない工程こそがボトルネックになる。
  逆に、かんばんを減らしても問題が出ないならば、工場内部で無駄な在庫が多かったことを意味する。

・不良品を消費部門に送り込んではいけない
 →後工程へ不良品を送りつけてはいけない。かんばんに書かれた品質基準を満たさないから。

・(かんばんを)生産の微調整に使う
 →例えば、当初は必要な部品が5個だったとするが、あとでよく考えたら7個のように少しだけ増やしたり、逆に3個へ減らしたい時がある。
  多少の数量の変動は、かんばんを修正して、かんばん内部で吸収してしまう。

【2-2】<バグ報告票の運用ルール>
・発見したバグは必ず起票しておく
 →バグはBTSチケットに起票することで、チームで共有できる。
  いくらバグを発見しても、BTSチケットに書いてくれなければ、開発者同士で、バグを認識できない。
  また、そのバグを再現させる方法について、開発者同士で共有できないから無駄な議論が生じる。

・バグとバグ報告票を1対1に対応づける
 →バグ1個に対し、BTSチケット1枚を対応付ける。
  BTSチケットの粒度に関係する。
  肥大化したBTSチケットにしない。

・バグ報告票がなければ作業を開始しない
 →チケット駆動開発における「チケット無しの作業不可(No Ticket, No Work)」に相当する。
  BTSチケットに作業者をアサインして、初めて作業が開始される。
  この運用ルールによって、BTSチケットには作業履歴や実績工数が必ず記録され、リリース後の運用保守で参考にできる。
  「チケット無しのコミット不可(No Ticket, No commit)」は、運用ルールの対象を作業から成果物の更新へ置き換えたものに相当する。

・バグ報告票の優先度順で作業する
 →バグの重要度(システムへの影響度、深刻度)や優先度(作業の優先順位)の観点で、大量のBTSチケットの作業順序を決める。

・流通しないバグ報告票(放置)に注意!
 →BTSチケットが放置されてしまうと、チケット駆動開発を運用している意味が無い。
  チケットで開発者同士、チーム内で活発にやり取りしながら、システムをブラッシュアップしていくように運用していくべき。
  「放置されたチケット」はデスマーチプロジェクトの特徴でもあり、チケット駆動開発の落とし穴でもある。

・オープン(未完了)なバグ報告票の枚数を減らしていく
 →未完了のBTSチケットを減らすことで、開発チームの作業負荷を下げて、開発チームが持続可能な開発ペースで作業できる状態にする。
  そのために、イテレーションというタイムボックス開発ないし小規模リリースという開発スタイルが有効になる。

・ブロッキングバグをテストチームに送り込んではいけない
 →プロジェクトを文字通りストップ(ブロック)させてしまうバグを放置したまま、テストチームへ回してはいけない。
  ブロッキングバグのように未完了のチケット、つまり、Doneの基準を満たさないチケットを後工程に回してはいけない。

・(かんばんを)人的リソースの負荷分散に使う
 →開発チームが消化できるBTSチケットの枚数には上限がある。
  (多分、この上限値がVelocityと一致するのではないか、と直感する)
  だから、BTSチケットの枚数が、開発チームの生産能力以上にならないように減らし、変動を抑えるようにする。

【3】製造業の「かんばん」とソフトウェア開発のBTSチケットを対応付けてみると、とても似通った性質を持つのが分かるだろう。
この事実は、製造業の「かんばん」というアイデアがソフトウェア開発にも応用可能であり、しかも有効であることを意味していると思う。

しかしながら、ソフトウェア開発特有の事情があるために、有効でない場面も多い。
実践 反復型ソフトウェア開発」では、製造業の「かんばん」とBTSチケットの性質の違いについて、いくつか述べている。

例えば、かんばんは製造指示書であるがゆえに、どのように作ればよいか、手順が明確に決まっている。
でも、BTSチケットに書かれたバグに対しては、バグの修正方法はすぐに分からない時が多いし、そもそも明確に決まっていない時もある。

あるいは、製造業の工場では、流通する「かんばん」の枚数は人為的にコントロールできるのに対し、ソフトウェア開発ではバグは際限なく見つけることができるから、BTSチケットが際限なく増えてしまう場合がある。
つまり、BTSチケットの枚数を開発チームがコントロールするのは事実上不可能だ。

このように、ソフトウェア開発特有の事情があるが故に、製造業の「かんばん」のアイデアをそのまま適用できない状況も多いし、有効でない。

従って、製造業の「かんばん」から派生する特徴と、製造業とは異なるソフトウェア開発特有の特徴を厳密に区別することが今後の課題になると思う。
少なくとも、ソフトウェア開発で出てくる「かんばん」は、欧米人が日本の製造業が生み出した「かんばん」を理解したものであり、更にソフトウェア開発へ適用することで、その概念を変形させている。
「かんばん」本来の特徴をソフトウェア開発に活かすだけでなく、ソフトウェア開発特有の事情も「かんばん」へ反映させているのだ。

今後、その辺りも考えてみたい。

| | コメント (0)

2013/05/06

アジャイル開発は工事進行基準と相性が良いという仮説

アジャイル開発は工事進行基準と相性が良いという仮説について考えたことをメモ。

【元ネタ】
Twitter / z200: スクラムを例に取ると、リリース(および検収)と売上・請求フローを組み合わせることは可能かと。開発で試したことはありませんが、制作現場では有効でした。 RT @akipii: そういう考え方もあるのか RT @z200: アジャイル開発は、工事進行基準との相性も良さそうだな。

【続報】ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ

ソフトウェア開発の売上げ計上タイミング:むささびの視線:ITmedia オルタナティブ・ブログ

販売管理~売上の計上時期(売上計上基準)

【1】ソフトウェアの受託案件が一括請負契約の場合、例えば1年間頑張って作った後、ユーザの受入検収が完了して初めて売上計上されるのが普通。
作って納品しておしまい、ということは普通はないだろう。
ユーザが使ってみて、確かに使えるね、という承認をもらわなければ、ユーザはお金の支払に首を縦に振ってくれない。

そして、実際の受入検収時に、バグを見つけた、この機能が足りない、この機能が使いづらい、といった障害や改善要望がたくさん押し寄せる時が多く、そう簡単に売上計上できない場合が多いのではないか?
しかも、ソフトウェアを納品した後の1年間は、瑕疵担保責任がSIに発生し、普通は無料で障害修正を行う時が多い。
だから、新規顧客のシステム開発は赤字になるリスクが大きいと思う。

最近は、システム監査やコンプライアンスが厳しくなったために、工事完成基準のように、システム全てを作った後に売上を一括で丼勘定で計上するやり方が適用しにくくなった。
工事進行基準に合わせて、システムの開発中の進捗度合いで売上がとれていないのに、売上を立てていく必要がある。
多分、実際は進捗度合いに合わせた売上金額を計算して、「売掛金//売上」として計上していると思う。
そして、最後に検収された後に、顧客からSIの銀行口座に振り込まれた時に、「当座預金//売掛金」として仕訳が立つのだろう。
でも、ウォーターフォール型開発では、設計・開発・テストの工程単位で開発しているために、例えばドキュメントを全部作ったとしても、動くシステムは一つも動いていないのだから、設計工程だけで売上が上がるということは正直現実的でないだろう。

【2】でも、アジャイル開発の場合は、工事進行基準と相性が良いのではないかと考える。
理由は、製品(完成した成果物)の基準が明確であることと、イテレーション単位に出荷可能な製品をリリースできることの2つがあるからだ。

アジャイル開発では、スクラムのように、スプリントの最後には出荷可能な製品が出来上がる。
「出荷可能(shippable)」とは、ユーザにデモで見せることができるレベルを指している。
つまり、デモがベータ版であっても、未実装の機能が半分あっても、少なくともユーザが手に取って受入検証できるレベルでなくてはならない。
その意味では、製品という完成した成果物の基準はとても明確だ。
受入検証できるからこそ、売上という尺度で、製品(現物)の価値を測定することができる。

また、スクラムでは、各スプリントの最後にスプリントレビューを実施し、プロダクトオーナーだけでなく、ユーザや上司などのようなステークホルダーにデモを見せて、評価してもらう。
つまり、スプリントと言う定期的な期間ごとに、デモで検証できる現物を見ながら、ステークホルダーは価値を測定することができる。
すなわち、工事進行基準の観点では、スプリントを経るたびに、少しずつ売上という価値(出来高:EV)が計上されていくし、その売上という価値は、スプリントレビューでステークホルダーの承認も得ているので、きちんとした証拠も残る。

逆に、ウォーターフォール型開発では、工事完成基準のようにプロジェクトの最後までずっと売上=0円で、最後にいきなり多額の売上高が計上されるパターンか、工事進行基準を適用して、動くシステムが作れない状況のままプロジェクトの最後まで仮の出来高(設計書は完成しているがシステムはバグだらけ)でしか売上を計上できないパターンしかないだろう。

【3】そんなことを考えると、ソフトウェア開発のようなビジネスが増えている現実において、会計原則がその流れに追いついていない感触を持っている。
ソフトウェア開発の産業は、製造業や小売業とは全く違う性質を持つ。
そもそも、出来高ないし現物という基準や納品するという概念が、従来の製造業とソフトウェア産業では全く異なるからだ。

そんな状況で、アジャイル開発は「定期的に現物をユーザに届けることで価値を定期的に確認する」プロセスを取り込むことで、ユーザにいち早く価値を届けられるだけでなく、ビジネス上の売上という価値基準も明確になる仕組みがある。

特に、アジャイル開発はソフトウェア開発特有の特徴をうまく生かしている点があるから、その特徴に見合った会計原則なり会計基準が早く出現するといいのではないかと思ったりする。

| | コメント (0)

2013/05/05

3Dプリンタでプロトタイプを素早く作る

最近、3Dプリンタなるものが流行しているらしい。
記事をリンクしておく。

【元ネタ】
3Dプリンタ - Wikipedia

ファッション小物からギターまで! 3Dプリンターで作れる驚愕のアイテムたち : ギズモード・ジャパン

Make: Japan | 3Dプリンターはどれだけ普及するか

「 #3Dプリンター 」ってなに? 何ができるの? いくら?:山田眞次郎の「メイカーズ始めました」:ITmedia オルタナティブ・ブログ

家庭用3Dプリンタを買うならどれ?特徴別3Dプリンタリスト  | Social Design News【ソーシャル・デザイン 公式サイト】

3Dプリンタとは、立体型の模型を作れるプリンタ。
プリンタという言葉がフィットするかどうかは分からないが、まずは3Dプリンタで何ができるのかを知るには、Gizmodoの記事「ファッション小物からギターまで! 3Dプリンターで作れる驚愕のアイテムたち : ギズモード・ジャパン」を見ると良い。
例えば、ちょっとした小物や模型だけでなく、レプリカや彫刻、顔マスク、ミイラとか。

3Dプリンタに可能性を感じるものは、新製品開発時のプロトタイプにも使えるだろう、ということ。
ベンチャーのような中小企業が新製品を作りたいと思う時、まずは3Dプリンタで、自分たちの製品イメージをプロトタイプを作るとよいのではないか?
そこからどんどんブラッシュアップしていくやり方がいいのではないか?

スティーブ・ジョブズ II」にも、アップルでは発泡スチロールで製品のプロトタイプを作り、ジョブズがそのプロトタイプを元に議論していたという話もある。
目に見えるプロトタイプは想像を刺激し、従来とは違った製品を生み出す。

リーンスタートアップや製造業では必須の道具のように思える。

| | コメント (0)

2013/05/04

ドメイン駆動設計を考え直す

UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方」を読んでいたら、とても面白かった。
OOAはDOAよりもモデリングが優れている本が多い気がする。
ラフなメモ書き。

【元ネタ1】
UMLモデリングレッスン - 安藤友晴@北海道のてっぺん

UMLモデリングレッスン 21の基本パターンでわかる要求モデルの作り方」では問題回答形式で、概念モデルについて説明しているのでとても読みやすい。
21のパターンも提示しているが、そのうち興味を引いたのは「リビジョン」パターン。
「リビジョン」パターンは、変更履歴を表現する概念モデルのパターンなのだが、部品表の仕様変更や自動車損害保険の契約変更にも適用できた、という話が興味深かった。
全く違う分野でも、概念モデルによる似たような解決方法があり、それがパターンになる。

OOAではオブジェクト指向らしくパターンも重視する。
そのおかげで、OOAは概念の共有がやりやすいように思う。
逆に、DOAはパターンという概念があまり普及していないように思える。

【元ネタ2】

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索

ドメイン駆動設計の感想~OOAは過ぎ去りDOAはもう一度舞台に上がるのか: プログラマの思索

Agile開発に足りないもの~モデリング技術: プログラマの思索

ドメイン駆動設計」の第8章に出てくる「ブレイクスルー」について、クレジット与信限度額計算に関するドメイン駆動設計のお話。

ドメイン駆動設計は設計のアジャイル化~オブジェクト指向設計の先祖返り: プログラマの思索にも書いたけれども、ブレイクスルーとは、概念モデルが開発者観点の設計モデルからユーザ観点の分析モデルへ質的に転換するタイミングを指す。
仕様変更のたびに概念モデルを拡張してリファクタリングしていくうちに、概念モデルから本質的な特徴を見出す時があり、そのタイミングをブレイクスルーと言う。

OOAでは、概念モデルのリファクタリングが面白さの醍醐味。
リファクタリングという技術もオブジェクト指向プログラミングから発生した経緯もあり、概念モデルを洗練させていく所は色んなやり方がある。
OOAでは、静的なクラス図だけでなく、動的なシーケンス図や状態遷移図も使って、モデルを検証していく。
オブジェクトの責務が均等に配置されるように、メッセージパッシングになるようにオブジェクトを分割していく。

OOAで面白いのは、概念モデルが質的変換を遂げたブレイクスルーを経ると、会計簿記の概念が自然に現れてくる点。
ドメイン駆動設計」では、船舶の輸送システムは単なる貨物の輸送が主体ではなく、実は船荷証券という貨物の権利が現れた。
船荷証券は、商業簿記2級で未着品という商品取引の仕訳として出てくる。
つまり、海外から船舶輸送で発送された商品が1ヶ月くらい長期に渡って届けられる場合、貨物の引渡しや受け取りの権利や義務を船荷証券という形でやり取りするわけだ。

また「ドメイン駆動設計」では、商業融資の利息計算サービスで出てくる支払利息・支払手数料・受取利息などの概念は、発生主義会計、つまり経過勘定科目として表現できる。
経過勘定科目も商業簿記では、未払利息・支払利息・支払手数料・受取利息などの科目として出てくる。
支払利息・受取利息は発生日から発生するので、利息を支払う義務や利息を受け取る権利が発生日に発生する。
しかし、実際にお金を支払ったり受け取ったりするのは、期末や支払期限・受取期限に精算する時になるため、精算時に仕訳を別途起こす必要がある。

UMLモデリングの本質」でも、鉄道の自動改札システムを概念モデルとして揺さぶり(リファクタリング)していくと、切符が乗車権という権利の証明になるという話がある。
つまり、鉄道ビジネスとは物を運ぶだけでなく、乗車権や着席権などの権利という商品を販売するビジネスが本質である、と。
似たような例として、航空会社の「便」、ホテルの「部屋」もあるだろう。

また、「UMLモデリングの本質」では、航空券の予約システムを概念モデルで描いてみると、フライトの座席は実は製造業や小売業の在庫の概念と論理的に同等であるという記述もある。
つまり、座席の予約状況から余っている座席を日々確定しては売るという、在庫の引き当てとか在庫の残高管理に似たような機能が重要であることを示唆している。
もちろん、新幹線の乗車券、ホテルの部屋の予約管理も同様に、在庫管理と似た仕組みになる。

【3】原田さんのDDDのプレゼン資料には、ドメイン駆動設計のパターン言語のリンクがあるので読んでみたい。

Domain Language /DDD

| | コメント (0)

2013/05/03

リーンソフトウェア開発のリンク

てつ。さんが「リーンソフトウェア開発がいまだによくわからない」という記事を公開されていたのでメモ。
僕もリーンソフトウェア開発は理解できてないので、関連記事をリンクしておく。

【元ネタ】
リーンソフトウェア開発がいまだによくわからない - Always All Ways

リーンソフトウェア開発の新刊が出ました。:An Agile Way:ITmedia オルタナティブ・ブログ

『リーン開発の本質』のあとがき。日本のアジャイルをつくりたい。:An Agile Way:ITmedia オルタナティブ・ブログ

Agile から Lean への旅 -- UK Lean Conference を終えて:An Agile Way:ITmedia オルタナティブ・ブログ

「測定できないものは制御できない」は誤りだった。-- by Tom Demarco:An Agile Way:ITmedia オルタナティブ・ブログ

リーンソフトウェア開発が分かりにくい理由は、リーンの発生源がトヨタ生産方式という製造業の現場から生まれた技法にあるからだと思う。
ソフトウェア開発とは違う場所から生まれているために、リーン特有の考え方がしっくりこない気がしているのだと思う。
リーンソフトウェア開発を理解するための一つの手法として、生産管理に出てくるカンバン方式から理解するのも一つの道筋ではないかと思っている。

また、アジャイル開発に比べるとはるかにビジネス寄りであり、経営者の観点のような気がする。
SIの立場ではなく、ユーザ企業がソフトウェア開発する場合に必要な技法の一つとして、リーンソフトウェア開発があるのではないか、と。
だからこそ、ビジネスにおける価値をすごく重視しているし、それに関する概念(意思決定に関する最終責任時点など)が色々ある。

他にも漁ってみる。

| | コメント (0)

DOAはOOA以前に表記法の問題点がある

UMLモデリングで有名な平澤さんの記事を見つけたのでメモ。
ラフなメモ書き。

椿先生のデータモデリング本 - UMLモデリングレッスン執筆日誌

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

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

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

【1】DOAは日本独自の歴史を持ち、業務モデリングに特化したノウハウも多い。
でも、データモデル表記読み替えハンドブック: プログラマの思索にも書いたけれど、TH法、T字形ER、渡辺式、IDEF1Xなどの記法がたくさんありすぎて、正直読みづらい。
個人的には、ER図はIDEF1Xが一番すっきりしていて読みやすいが、業務フローも考慮すると渡辺式が分かりやすいと思う。

最近考えているのは、ER図を基本にして、業務フローと画面UIを組み合わせたモデリング技術としてDOAを再構築できないか、ということ。
UMLのように、一つのモデルを静的モデル(クラス図)だけでなく、動的モデル(シーケンス図、状態遷移図)の観点でも表現して、モデルを洗練させていったり、モデルの整合性を保証するようにしたいのだ。
その点では、渡辺式の3要素技法はよく考えられていると思う。

【2】IDEF1Xの記法とUMLのクラス図の記法の対比を下記にまとめてみた。

IDEF1XがIE記法よりも優れていると思う点は、親子関係と参照関係、派生関係の違いが一目で分かることだ。
OOAであいまいに表現される関連は、DOAでは親子関係と参照関係ではっきり表現できる。
親子関係による複合キー、参照関係による外部キーは全く意味が違うのに、OOAでは一つの関連でしか表現できないため、本来の業務ロジックの表現力が弱いと思う。
また、IE記法では、派生関係の記述力が弱い。また、親子関係と参照関係は、1対他の同じ線で引く表現しか無いため、記述力が弱いと思う。

データモデリングの初心者がER図を書くと、親子関係を多用する時が多い。
よく使われるのは、ヘッダ・明細の親子関係だ。
帳票や画面からテーブルを類推する時、すぐにヘッダ・明細は分かるので、親子関係ばかりのER図になる。

だが、DOAによるモデリングの基本は外部キーを使った参照関係によって、テーブル間のリレーションシップを表現して、業務ロジックを表現する所にあると思う。
DOAに慣れていない人は、外部キーの使い方が良くない。
注文明細にある商品名の表示ぐらいしか、外部キーを使っていない。

本来は、受注→請求→売上計上→入金(売掛金回収)のような一連の業務フローにおいて、外部キーでリレーションシップを表現して、データの登録・更新・削除に合わせて業務ロジックを表現できるようにすべきなのだ。

テーブルの親子関係はOOAのコンポジションに相当するため、一つのエンティティ、つまり、データのライフサイクルが同じものとして捉えられる。
無意味に分割してもあまり意味が無い。

子テーブルは複合キーという主キーを持つが、主キーは普通は更新不可なので、子テーブルのデータを入れ替えたい時に主キーを更新したくなる場合があり、その時に外部キーを使っていないと、他テーブルとのデータの整合性が取れなくなる時がある。
特に、トランザクションテーブル同士の参照関係を上手く使えれば、柔軟なテーブル設計になる時が多いと思う。

【3】外部キーによるリレーションシップには、「暗黙的なリレーションシップ」と呼ばれる別のパターンもある。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索にも書いたけれども、複数のテーブルを結合したビューで参照制約が存在する場合、「暗黙的なリレーションシップ」「動的な参照関係」とか「継承属性」と呼ぶ。

実際の現場では、継承属性が存在する時があり、実はテーブル間のリレーションシップが存在するがゆえに、業務ロジックの制約を表現している時がある。
しかし、継承属性をモデルから読み取るには、ER図をかなり読み込んでいないと難しい。

【4】DOAにもOOAと同様に派生関係(継承関係)は存在するが、共存と排他の2種類の意味があり、区別して使うのは意外に難しい。

データベース設計で派生関係は難しい: プログラマの思索にも書いたけれども、OOAの継承に似た排他という関係と、NULL値を排除するための共存という関係を使い分ける必要がある。

法人顧客と個人顧客、生産管理に出てくる品目や製造・出庫指図などは、DOAの派生関係で表現できるが、理解は意外に難しいものだ。

【5】DOAがOOAよりも面白い点の一つは、業務モデリングと密接に絡んだ場合、会計簿記の仕訳の概念が必然的に出てくることだ。
製造業で、原材料を仕入れて倉庫に入れれば、「仕入//買掛金」というお金の記録が発生する。
小売業で、商品を顧客に現金払いで売ったならば、「現金//売上」というお金の記録が発生する。
つまり、それぞれの業務でデータが流れる時に、カネが発生し、それを記帳する必要が出てくる。
そして、そこから、在庫管理や会計帳簿の話につながっていくわけだ。

一技術者の観点から離れて、実際のビジネスの現場で働いている事務の女性や経理担当者にヒヤリングしてみると、彼らはお金の流れにとても敏感であることがよく分かる。
彼らは税理士や会計士などのような監査部門の人達に対応しているため、ITに弱くても、会社の実務にはかなり強い。

DOAと会計の関係に触れた本としては、渡辺幸三さんの本「販売管理システムで学ぶモデリング講座 (DB Magazine SELECTION)」と梅田弘之さんの本「グラス片手にデータベース設計~販売管理システム編 (DBMagazine SELECTION)」がベストではないかと思っている。
そして、DOAと会計の関係をもっと分かりやすく表現できないのか、という問題意識も持っている。
その辺りで考えたことは、Blogに残していく。

| | コメント (0)

« 2013年4月 | トップページ | 2013年6月 »