« 2014年7月 | トップページ | 2014年9月 »

2014年8月

2014/08/30

「プロフェッショナルCIOの教科書」の感想~調整型CIOは必ず失敗する

ユーザ企業のCIOを目指す人やCIOにこれから担当する人にとっては、良本だと思う。
CIOの失敗事例やCIOの使命、CIOに必要なスキルや考え方が具体的に提示されており、網羅的に書かれているのが良い。
情報システム構築を伴う業務改革や内部統制を統括する部門長の仕事の内容がよく分かる。

逆に言えば、CIOに近い仕事をしていない人の観点では、面白みに欠けるだろう。
書いてある内容が当たり前に思えてしまうからだ。

でも、CIOに近い仕事をしている人ならば、失敗事例はそうだよとうなずくだろうし、アインシュタインの式を真似た改革の公式「E=gi^2」には感心するだろうし、ERPの問題点とカスタマイズの回避策についても同感するだろう。

また「調整型CIOは必ず失敗する」という指摘も、経験上すごく同感する。
いくら利用部門と妥協して業務システムを導入しても、目的や投資対効果を明確に決めてないと、結局「動かないシステム」をたくさん作ることになってしまうから。
技術者上がりのCIOで技術にこだわり過ぎると、システムの導入自体が目的になってしまい、導入効果や現場への浸透が二の次になりがち。

以下、感想をメモ。

【1】けものみち:理由の分からない複雑な業務手順。
例えば、業務システムで複雑な返品機能があり、現場から悲鳴が出ていた。
その理由は、以前の現場で、営業マンが売上ノルマ達成のために、不正な受注を入力して、後から大量の返品が発生した事件が何度もあり、その対策のために返品機能が複雑になったから。

けものみちは、システム化の妨げになる。

【2】基幹システムの勘所
【2-1】会計システムの勘所:
①勘定科目の見直し
 →法改訂やIFRS対応
②会計PKG製品の流用
 →保守費用の削減
③財務会計と管理会計を区別
 →財務会計は法令を元に社外報告。管理会計は社内で使うので、目的を明確化する。
④データの誤りは、上流の業務で直す
 →販売管理システムの不始末、生産管理システムの不始末を会計システムで解決しない。会計監査で粉飾の指摘を受ける。

【2-2】販売管理システムの勘所:
①システム使用場面の明確化
 →営業マンが出先でモバイル端末を使うのか、事務員が社内で使うだけなのか、EDIで発注データを連携するのか。
②売上計上のタイミング
 →普通は出荷基準。
 →例えば、製品倉庫から営業倉庫への倉庫移動を売上計上した会社は、会計監査で粉飾の指摘有り。
③締め戻し処理の考慮
 →例:請求締め後に、取引先の要望で請求書の再発行など。
④システムごとのコード体系を整理統合

【2-3】生産管理システムの勘所:
①基準情報の精度を求める
 →MRPに入れる情報を正しくする。
 →例:リードタイムや所要量。BOMや工程の情報。
 →情報の精度が低いと、「計画と活動指示」の機能を現場が使いこなせなくなる。
②現場での情物一致を徹底させる
 →システム上のデータが現場で違う。
 →例:在庫や原材料手配。
 →現場ではシステムを信用しなくなる。
③販売予測と生産計画を連携する
 →MRPの精度を上げる
 →営業部門と製造部門が互いに信用しないと実現は難しい
④基準生産計画(MPS)の変更管理は柔軟にする
 →市場の変化や製造の歩溜まりで変更がよく発生する
⑤納期回答業務の機能を重視する
 →製品を在庫として持つのはリスク大。不良在庫、死蔵在庫になりやすい。
 →そこで、MTS、BTOやMTOで対応する会社が多い。
 →すると、受注や引き合いで、顧客や取引先に正確な納期を回答するのが重要

【2-4】人事システムの勘所:
①雇用形態の多様化
 →契約・派遣・時短などの社員もいる。育休や有休もある。
②個人情報への配慮
 →社員情報も個人情報保護法の対象。
③給与体系や手当の配慮
④PKGソフトの流用
 →システム維持作業を削減

【2-5】ワークフローシステムの勘所:
①外部システムとの役割や連携
②業務改革そのものにつながる
 →業務フローの見直しと最適化。意思決定の迅速化。ペーパーレス化。冗長な手続きや不要な業務を廃止。

【2-6】EDIの勘所:
①社外システムの活用
②客や仕入先にデータ入力させる
 →システムの使いやすさの追求
③社外の業務プロセスも含めた業務改善

【2-7】SCMの勘所:
①予測情報を全社で共有
 →計画立案業務を支援。販売・受注情報の精度を上げる。
②実績情報をタイミングよく収集する
 →計画業務へフィードバックして支援する

【2-8】ERPの勘所:
①メリットとデメリットは表裏一体
 →ERPのベストプラクティス導入は、自社に合わない場合もある。
  ERPを自社の業務に合わせると、ERPカスタマイズ費用が発生する。
②SOAの考え方が広がっている
 →一つのERPで全社の業務をカバーできない。統合DBの実現は無理。
 →複数のERPを組合せる。
 →しかし、業務単位の部分最適になりやすい。

【3】改革の方程式:E=gi^2

①E:業務の効果(Effect)
②g:業務改革(gyoumu)
 →業務の最適化。組織改編など。

③i:意識改革(ishiki)
 →社員の意識。変えようとする意識。
④i:情報改革(Information)
 →・改革の必要性を伝える。社員の動機づけ。
  ・業務改革の情報を伝達。活用できる業務情報を伝達。
  ・業務改革、意識改革のPDCA支援。状況のフィードバック。

【3-1】経営者がCIOによく投げかける発言「高い投資をしたシステムが何故活用されないのか?」。
「使い勝手が悪い」というユーザ部門の声は表面的であり、業務改革や現場への動機づけ(意識改革)が徹底されていないから。

【4】DMMによる業務の棚卸し

【4-1】DMM:1つの業務を8つの業務へ詳細化するために、8個のボックス形式にする。
 人がひと目で分かるのは6~8個。
 約3~5階層まで細分化する。

ザックマンフレームワークの考え方に似ている。
例えば、全社→販売→出荷→・・のように業務を細分化し、最下層の業務に対し、業務フローを書く。

【4-2】業務マニュアルの作り方
①見える化する
 →業務の暗黙知を見える化。考え方、用語、動作など。
②基準を作る
 →・標準を示す。例:業務手順
  ・幅を示す。例:チェックリスト
  ・考え方を示す。例:方針や理念。
③基準を守ることができるようにする
 →ポイントやコツ。例外業務や事例。評価する仕組み。
④ベストパフォーマーを作る
 →習熟度レベルで道筋を見える化する。プロセスチャンピオンを増やす。

【5】改革の失敗パターン

【5-1】経営トップがリーダーシップを示そうとしない
【5-2】経営者の意識が一枚岩ではない

【5-3】社内プロジェクト活動への疲労感が強い
 →経営者は業務改革にやる気満々。
  しかし、推進役は業務多忙で疲弊している。
  現場も業務改革についてこない。

【5-4】社員の意識が不足している
【5-5】社内に抵抗勢力がいる

【5-6】社内のけものみちが温存されている
 →例1:盲目的な月末在庫の削減
   あるメーカーでは、在庫削減の改革のために、現場は意図的に月末に在庫を置かなくなり、欠品が増えた。
   すると月末に出荷できない受注が出て、月末は取引できない雰囲気が出た。
   在庫削減活動による局所最適化が、販売機会のロスを招いた。

 →例2:計上部門が違う売上は計上部門ごとに入力する
   あるサービス業では、以前は、商品群ごとに対象とする顧客に重複はなかったので、売上データ入力は、商品群ごとに担当する部門が入力するルールだった。
   その後、同一顧客に複数の商品群の商品を提供するようになったが、従来の運用ルールが変わらない状況のまま放置された。
   その結果、顧客が複数の商品やサービスを一度に購入した場合、担当部門ごとの請求書が届き、支払方法も請求書ごとに異なるようになってしまい、顧客満足度が落ちた。
 
 →例3:同一商品でも営業部ごとに異なる商品コードを使う
    あるメーカーは、以前は、市場別のサブブランド戦略を取っていたために、同一商品でも営業部が異なれば、別の商品コードで売上管理していた。
    しかし、サブブランド戦略が廃止されたのに、同一商品でも営業部ごとに異なる商品コードを使う運用は残ったままになっていた。

【5-7】改革の浸透努力が不足している
【5-8】改革の手段が目的化
【5-9】ITソリューションの効果を過信している
【5-10】現場にITアレルギーがある
【5-11】改革推進のノウハウが欠如している

【5-12】調整型CIOは失敗する
 →妥協を取り付けても、情報改革の目的は果たせない。
 →期待効果と実現性のポジショニングマップで、優先度を付ける

【6】ERPやパッケージソフトを上手く使う
基幹システムをスクラッチ開発する会社は稀。

【6-1】成功のポイント:
①コード体系の全社統一
 →ERPは統合DBが前提。
  CRMやBIなど他システムへも不具合をもたらす。

②情報の精度を高める
 →データを重複なく一元管理する必要あり
 →十分な人手と期間を割り当てる。人間系の手作業とシステム化の業務を分ける。

【6-2】ERPカスタマイズの問題と回避策

①カスタマイズの失敗は深刻な事態を招く
②カスタマイズ要件の採否のポイント:
 ・情報改革に期待する効果の貢献度
 ・カスタマイズ無しでERP標準に合わせた業務の実現可能性
③ERP導入業者の見極め
 ・ITベンダの支援が必要
 ・カスタマイズ要件とのフィットギャップ分析できる能力があるか否か

| | コメント (0)

astahでいつも忘れるTips

astah Professionalを使っている時に、いつも忘れる使い方があるのでメモ。

【1】コンポーネント図のインタフェースで提供インタフェースと要求インタフェースを関連づける
astah* Users Community Site - フォーラム コンポーネント図のインタフェースに関して

astahでは、コンポーネント図で提供インタフェースと要求インタフェースを関連付ける方法は直感的ではないと思う。
やり方としては、提供インターフェースを作成した後、ツールパレットから「使用依存」を選択し、
コンポーネントから提供インターフェースに向かって作成する。

【2】クラス図で限定子を作る

astah* Users Community Site - フォーラム 限定子

関連、関連クラス

クラス間の「関連」をクリックして表示されるポップアップメニューから「限定子を追加」を選択する。

| | コメント (0)

2014/08/27

経験の浅い人はEVMの「出来高」という概念を理解しにくい

「経験の浅い人はEVMの「出来高」という概念を理解しにくい」という話を聞いて、心当たりがあったのでメモ。
ラフなメモ書き。

EVMで重要な概念は、計画と実績の予実管理だけでなく、出来高管理にある。
今、実際に労働コストを費やして、どれだけの出来高をアウトプットに出したのか、という状況を見える化するためにある。

しかし、新人やマネジメント経験の少ない開発者は、出来高という概念が理解しにくいらしい。
そういう人に限って、作業の進捗率が曖昧で、90%シンドロームに陥りがち。

出来高という概念を理解しにくい原因を辿ると、作業の完了基準を明確に理解していない事実が判明する。
「未着手」「作業に着手した」「設計書は完成したがレビュー未完了」「レビューが終わった」「リーダーが承認した」というフローを理解していないのだ。
あるいは、それぞれのチケットの状態と成果物が対応付けられておらず、進捗率を自分の感覚だけで適当に付けてしまう。

その意味では、WF型開発では、出来高=計画工数 * 進捗率で計算されるため、出来高を理解しにくい弱点があると思う。
レビュー未完了の設計書の出来高は、本当に80%なのか?
設計工程が完了しても、システムは何一つ作られておらず、リリースされていないのに、出来高を計上してもいいのか?

アジャイル開発を経験している人なら、出来高は理解しやすいはずだ。
完成したモノが出来高と等価であり、未完了のモノは出来高としてはゼロだから。
つまり、アジャイル開発の領域では、出来高は現物と同じ。

また、この話は、アジャイル開発ならDoneの基準に相当する。
製品をリリースできる基準、作業が完了した基準、成果物が完成した基準が、チーム内で認識が不統一なのだ。
Scrumでは、スプリント計画を立てる時点で、Doneの基準もチームで決める。
それによって、メンバー全員が、作業を完了する基準を理解し、共有する。

Scrumが優れている点は、Doneの基準がチームの成長に従って変化していくことを許容していることだ。
初期のスプリントでは、メンバーも新しいフレームワークや仕様に慣れていないし、チームも有機的に動けないので、アウトプットの量は少ない。
だから、Doneの基準の範囲も狭い。

しかし、スプリントを経ていくうちに、メンバーもチームも成長し、生産性が上がり、成果物の品質も向上するようになるだろう。
だから、リリース後ないしスプリント計画時に、Doneの基準を見直して、Doneの基準の範囲を広げていく。
そうすれば、より品質の良い作業や成果物をメンバーに期待することにもつながる。

出来高という概念には、現物主義、Doneの基準という概念と密接に関連する。
アジャイル開発で考える方が厳密で分かりやすいと思う。

| | コメント (0)

RedmineとGitを巡る疑問点~Gitとの連携機能の強化がRedmineの課題

RedmineとGitを巡る疑問点をメモ。
詳細は後で書き足す。

【参考】
チケット駆動開発に分散バージョン管理を組み合わせるアイデア: プログラマの思索

分散バージョン管理ツールにおけるブランチ戦略: プログラマの思索

Gitによるチケット駆動開発の事例: プログラマの思索

A successful git branching model とgithub flowの比較: プログラマの思索

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

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

【1】Redmineは日本のSIでかなり普及しているらしい。
その状況と並行して、オープンソース界隈では、GitHubでチケット管理する運用も多い。
すると、最近の状況としては、RedmineとGitを連携して、うまく運用したいという要望があるように思える。

しかし、RedmineとGitの連携とその運用は、まだまだ試行錯誤の部分が多いと思う。
RedmineとGitを巡る疑問点をリストアップしてみる。

【Q1】RedmineとGitリポジトリブラウザのツールと連携する方法はあるか?
具体的には、Gitlab、GitHub、GitBucketなど。

Redmineのリポジトリ管理機能には、GitをSVNと同様に設定できる機能はある。
しかし、Git単体で入れるよりも、Gitlab、GitHub、GitBucketのようなGit用のリポジトリブラウザを入れる方がGitのブランチ管理がやりやすい。

Gitlab、GitHub、GitBucketのいずれともRedmineと連携する方法については、既にネット上にたくさん書かれている。

だが、問題は、Redmineのチケット管理とGit用リポジトリブラウザのツール上のチケット管理をどのように使い分けるか、だ。
Gitlab、GitHub、GitBucketともに、Redmineのチケット管理よりも機能は貧弱。
でも、Redmineのリポジトリ画面よりも、Gitlab、GitHub、GitBucketの方が、Gitのブランチ管理やマージ管理はすごくやりやすい。

その問題の解決方法はまだ僕には分からない。

redmineとgithubの連携 - katashiyo515's diary

GitBucketとRedmineを連携する | 眠るシーラカンスと水底のプログラマー

GitLabとRedmineを連携してみるの巻 - アルパカDiary

RedmineとGithubの連携 - Qiita

【Q2】Gitのブランチ管理をRedmineへどのように対応づけるか?

Gitの利点の一つは、ブランチの生成と消滅に至るまでのライフサイクル管理がすごくやりやすいことだ。
ちょっとした機能追加、障害修正があれば、トピックブランチをすぐに作って、実験すればいい。

その場合、Gitブランチは、Redmineのどの機能と対応付けられるか?

ブランチをRedmineへ対応する方法は2つある。
一つは、プロジェクト。
もう一つは、チケット。

Redmineプロジェクトをブランチに対応付けた場合、ブランチからビルドされるモジュールは製品とみなされ、その製品のタスク・障害・課題管理にチケット管理が対応付けられる。
そのような運用がおそらく理想だと思う。

僕が6年前にRedmine+Subversionを運用した時も、リリースブランチを作るたびにRedmineのサブプロジェクトに対応付けて、リリースブランチの生成と消滅のライフサイクルと、Redmineのサブプロジェクトを対応付けていた。
SCMCreatorのようなプラグインでは、Redmineプロジェクト名とSVNリポジトリ名を合わせて新規作成する機能を持っていた。

Redmine+SVN/Gitの環境構築 (3)|ソフトウエア開発(android・iphone・windows・java等)の事なら株式会社パークにお任せください_パク太郎のソフトウエア開発者ブログ

概要 - SCM Creator (+Github) - Andriy Lesyuk site

だが、Gitのようにブランチがたくさん作られる運用では、このような運用は非常に面倒になる。
Redmineプロジェクトの生存期間がすごく短くなるし、Redmineプロジェクトが乱発されて、チケットが散在してしまい、見通しも悪くなる。

後者の運用では、トピックブランチの生成のタイミングでチケットを作成し、マージのタイミングでチケットをCloseする。
Gitでブランチを作る時、チケットを先に作成し、ブランチの名前をチケットNoにしてブランチを作る。
そのようなコマンドもネット上にはある。

bleis-tift/Git-Hooks

mikoto20000/redmine_git_branch_hook

この運用の利点は、チケットにトピックブランチの修正履歴が残ることだ。
つまり、トレーサビリティを実現することができる。

この運用は、「No Ticket, No Fork」という運用ルールに発展する。

【Q3】Gitのマージ or PushをRedmineチケットのステータスとどのように対応づけるか?

Redmineチケットにトピックブランチを対応付けた場合、Pushするタイミングで、チケットも同時にCloseできるようにしたい。
そうすれば、「fixes #123」のコミットログを書いてコミットしたらチケットの進捗率が100%になってCloseされる運用と同じように運用できるから。
そのようなコマンドもネット上で公開されている。

mikoto20000/redmine_git_branch_hook

Git-Redmine: GitのコミットとRedmineを連携する。チケット駆動開発にも。 (ゆめ技:ゆめみスタッフブログ)

coiled-coil/git-redmine

この運用は、「No Ticket, No Merge」という運用ルールに発展する。

しかし、この運用ルールには幾つかの問題もある。
一つ目は、トピックブランチをマージする時に、特定のリビジョンを選択してマージしたり(cherry-pick)、複数のリビジョンをまとめて一括でマージする(squash)する時、現状のトピックブランチから別のブランチ上にパッチを一旦作成する必要があるために、チケットとマージ用ブランチが対応しなくなる。
つまり、トピックブランチの全ての修正履歴がチケットに記録されなくなる。

もう一つは、トピックブランチをPushするのは普通はありえないので、masterへrebaseが許せるのか?
本来は、rebaseのマージが一番美しい。
トピックブランチの修正履歴がそのままmasterに引き継がれるので、修正履歴が残るから。

しかし、トピックブランチの修正履歴を全てmasterに反映する必要は、普通はそもそもない。
コミッタやライブラリアンの立場では、masterには完成されたパッチだけマージすれば良いのであり、パッチの作成に至るまでの試行錯誤の修正履歴は必要ない。
パッチのコードレビューは、マージするタイミングの完成したパッチだけで十分。

この辺りの運用ルールの判断は、品質保証部やPMOと開発チームの力関係に依存する。

【Q4】プルリクエストをRedmineにどのように実現できるか?

GitHubが優れている利点の一つは、パッチのマージをプルリクエストという手法で実現することで、Web上でそのやり取りが見える化され、コミッタがコードレビューして判断するプロセスを自然に実現できたこと。
コミッタは、プルリクエストされたパッチが気に入らなければ、Rejectすればいいだけ。
コミッタとコントリビュータの間のやり取りは、プルリクエストのコメント履歴に残り、その後の運用保守で非常に役立つ。

しかし、RedmineではプルリクエストをGitHubのように自動化できていない。
プルリクエストするためにチケットを作り、そのチケットにパッチを添付するような運用しか無い。

本来は、プルリクエストを依頼する時に、チケットが自動作成されて、そのパッチのリビジョンが自動で添付されるような仕組みが作られるべきだ。
わざわざチケットを作って、依頼するための文章を書くのは面倒な手続きだからだ。

この点は、今後のRedmineの課題になるだろう。

【Q5】git-flowやGitHub-flowをRedmineにどのように実現して運用したらよいか?

Gitのブランチ管理を体系づけたgit-flowや、それをGitHub用に簡略化したGitHub-flowは、Gitを使う人なら当たり前の運用方法だ。
しかし、Redmineではそれをどのように運用すればいいのか?

GitHub Flow (Japanese translation)

git-flow によるブランチの管理 - O'Reilly Japan Community Blog

Gitブランチを使いこなすgit-flow/GitHub Flow入門(終):プルリクエスト/レビューを取り込んだ、よりシンプルなGitHub Flowの運用を図解する (1/2) - @IT

ブランチ管理やマージ方法やプルリクエストを、Redmineのチケット管理とどのように対応付けるとよいのか?
Gitのブランチ管理やマージ方法やプルリクエストなどの一連の作業を、Redmine上で自動化して、もっとアジャイルに開発できる仕組みを実現できないのか?

現状のRedmineは、Subversionに特化しすぎていて、Gitとの連携方法の研究は未完成だ。
幾つかの手法は試されているが、それだけでは不十分だ。

Gitとの連携機能の強化は、Redmineの今後の課題になるだろう。

| | コメント (0)

2014/08/25

伊藤直也氏の記事のリンク

今年のWeb記事で、伊藤直也氏のインタビュー記事がとても優れているのでメモ。

【参考】
伊藤直也が語る「仕事の流儀」第1回──KAIZENでの開発体制をKAIZENする|CodeIQ MAGAZINE

伊藤直也が語る「仕事の流儀」第2回──スタートアップにリモートワークツールを推奨する理由|CodeIQ MAGAZINE

伊藤直也が語る「仕事の流儀」第3回──OSSプロジェクトのように組織をつくる|CodeIQ MAGAZINE

伊藤直也が語る「仕事の流儀」第4回──常に技術の新陳代謝が生まれる場所にいたい|CodeIQ MAGAZINE

伊藤直也氏が「Web開発は高度化している」と語る理由と、押さえておきたい3つの技術領域【2014年前半のインプットlog】 - エンジニアtype

開発プロセスの進化の良い記事。日本では伊藤直也さんを追いかければ動向が分かる。@hyuki: これは良記事。内容とともに情報収集の考え方についても注目。 伊藤直也氏がWeb開発は高度化していると語る理由と押さえておきたい3つの技術領域 http://t.co/s9Z7FyiRjd

GitHub Kaigiで「はてなブログチームの開発フローとGitHub」という発表をしました - Hatena Developer Blog

特に2011年以降、開発チームを支える開発環境やインフラ面で技術革新が多い。
その技術の中心にGitHubとChef、そしてリモートワークを巡る技術があるといえるだろう。

Redmineやチケット駆動開発のアイデアはもはや当たり前であり、最先端の技術に触れている開発者なら、既に先の技術を見据えている。
その方向はどこをターゲットにしているのか?
その方向に向かおうとする動機は何なのか?

技術の流れは、オープンソースの開発スタイルをベンチャー企業のスタートアップ開発やSIの受託開発にも適用しようとする方向だ。

ブランチとマージが頻繁に行われ、その作業履歴はすべてWebに記録される。
ソースの共同所有やコミュニケーションは、Webでやり取りされるから、自然にリモートワークになる。

そして、プルリクエストでは、必ずコミッタのレビューが入る。
Googleがやっているコードレビューがオープンソースでもプロセスとして自然に実現されている。

そのオープンソースのような開発プロセスは、基本はアジャイル開発だ。
WF型開発のように、事前に大きな計画を立てて、予実管理するのではない。
大まかなロードマップは立てておくが、ユーザのフィードバックとコミッタの意思をもとに、変化を受け入れながら、小刻みに頻繁にリリースしていく。

そんなことを思うと、ソフトウェア開発はコミュニティという場が重要なのだろうと思う。
コミュニティに、ソフトウェアをこんな風に使った、こんな風に使いたいから機能拡張してくれ、こんな便利な使い方があるよ、というユーザの議論が活発であるほど、ソフトウェアは進化する。
コミッタには、ソフトウェアの開発だけでなく、コミュニティの運営という能力も別途必要とされてきている。

面白い時代になりつつある。

| | コメント (0)

2014/08/24

「チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化」の資料のリンク

インフラ運用チームにおけるチケット駆動の運用について、良い資料があったのでメモ。

【参考】

会社でのJiraについての取り組みを夏のプログラミングシンポジウム2014というとこで話すことになったので資料うp。#sprosym2014 チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化 http://www.slideshare.net/masatoigeta/2014-igeta

インフラ運用チームのタスク管理は、プログラマ主体の開発チームのタスク管理とは異なる。
「主な業務は依頼作業とアラート対応」の通り、顧客やベンダーやアプリチームからの作業依頼、本番障害などの対応が多い。
つまり、突発的な作業で、緊急度の高い作業が結構多い。
すると、JiraやRedmineのようなチケット管理ツールがなければ、突然発生するタスクが割り込んで、日々の作業に追われるだけだろう。

上記の資料で興味深い点はいくつかある。

基本は、手作業の自動化を目指したものの、完全な自動化は無理だったこと。
アラートメールの集計処理の自動化、依頼作業やアラートメールをチケット化など、色々やっている。

しかし、インフラチームの対応先は、顧客、アプリチーム、ベンダー、社内部署など多岐にわたり、組織間の調整がかなり面倒。
チケット化しようにも、外部の利害関係者にチケット更新を強制するのは難しい。

また、暗黙知化したサーバー設定を紐解くのも難しい。
最近のサーバー設定なら、ChefやらDockerなどいろんなツールで再現可能な環境構築が可能だろうが、10年以上前のサーバーが稼働中の場合、そのサーバーの内容をリバースして洗い出すのは非現実的だろう。

そんな問題点を抱えながらも「作業前業務が多い」点に注目して、「作業前業務のDSL化」という対策を実行したのは興味深い。
DSLの内容は具体的に書かれていないが、「作業前業務をコード化」「Chefでやっていたことを人に当てはめる」「DSLとして業務タスクを明文化」「TODO、手順書、特殊仕様、確認コマンド結果をチケット化」という内容から類推すると、手順化できる業務をDLS化したみたい。
おそらく、Rakeもしくはyamlで手順をDSL化し、DSLをチケットに添付して運用担当者に作業を依頼し、DSLの実行結果をログとして残す運用と思われる。

DSLを使う発想はそもそもどこから出てきたのか、すごく興味はある。
おそらく、Chefなどを触っているうちに、手順化できる業務はRakeなどにまとめられると気付いて、DSL化する発想にたどり着いたのではないか?

そういう意味では、Rubyの強力なメタプログラミング機能が、手順や業務を抽象化して再利用できる方向に使えることを示唆しているように思える。

【追記】
感想があったのでメモ。

akipiiさんはTwitterを使っています: "大変参考になりました。RT @noexpect: いろいろ書いていただけててありがたい。 「チケット駆動のサーバ/インフラ運用における問題点と手動作業の自動化」の資料のリンク http://t.co/UpULRDC5rP"

| | コメント (0)

第10回ドメイン駆動設計勉強会の感想 #dddosaka

第10回DDD勉強会で議論した内容をメモ。
自分が理解できたことだけを書いておく。

【参考】
第10回ドメイン駆動設計(DDD)読書会@大阪 - ドメイン駆動設計(DDD)読書会@大阪 | Doorkeeper

dddosaka/reading_ddd_report

第7回ドメイン駆動設計勉強会の感想 #dddosaka: プログラマの思索

第6回ドメイン駆動設計読書会の感想: プログラマの思索

第4回ドメイン駆動設計読書会の感想: プログラマの思索

ドメイン駆動設計に出てくる「モデル」とは何ですか?~第28回関西IT勉強宴会の感想: プログラマの思索

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

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

いまさら「ドメイン駆動設計」を読み終えた - 勘と経験と読経

【1】15章「汎用サブドメイン」「隔離されたコア」

コアドメインは、ソフトウェアプロダクトラインのコア資産とほぼ同じ。
蒸留は、コア資産抽出の作業と同じ。

コア資産こそがそのモデル、そのシステムの中核となるドメインの塊。

すると、そのコアドメイン(コア資産)から、補助的な役割を持つドメインを分離して、コア資産の凝集度を高めることが重要になってくる。

【1-1】補助的な役割を持つドメインはいくつかある。
一つは、汎用ドメイン。
たとえば、フレームワークなどの開発基盤、アナパタやリファレンスモデルのようなモデルテンプレート、自動テスト、共通関数など。
ドメイン駆動設計」の例では、タイムゾーンモジュールがあった。

他にも、会計や物理学は既にモデルとしてテンプレート化されているため、汎用サブドメインの範疇になる。

【1-2】他には、隔離されたコア。
ドメイン駆動設計」の例では、P.437にあるように、輸送パッケージから、配送<<コア>>と物流、顧客、金銭<<汎用>>のドメインに分離していている。
コアドメインが配送<<コア>>であり、隔離されたコアが物流、顧客、汎用サブドメインが金銭<<汎用>>に相当する。

責務駆動設計の観点では、以下の点で整理される、という話もあった。

・配送<<コア>>:コアドメイン。実績に相当。「業務」に相当。
・顧客、物流:隔離されたコア(補助的なサブドメイン)。計画に相当。「能力」「潜在能力」に相当。

【1-3】「ドメイン駆動設計」を読んで面白いのは、「汎用サブドメイン」「隔離されたコア」 の注意点やリスクが興味深いところ。

汎用サブドメインは共通関数やモデルテンプレートが該当するので、開発チームの中で優秀なメンバーが割り当てられやすい。
すると、技術系の人間ほど、タイムゾーン変換や物理学のような限定可能な問題を楽しむ傾向があり、そういう問題に時間をかけすぎてしまう。
本来ならば、コアドメインの開発に注力すべきなのに、2級レベルの開発者をアサインして、プログラムがあまりきれいでない状況になってしまいがち。

また、XPのようなアジャイル開発では、アーキテクチャスパイクやゼロリリースのように、初期のイテレーションで、技術的アーキテクチャの妥当性を証明するように、補助的な汎用サブドメインを扱う周辺システムを構築したがる。
しかし、これでは、本来のリスク管理にはならない。
コアドメインを少しずつ作っていき、ドメインモデリングのリスクを下げていく方向に進まないから。

それゆえ、初版のシステムは、単純であってもコアドメインの一部を作らなければならない、と主張している。
この点は同感。

【1-4】また、「隔離されたコアを切り出すタイミングは、システムにとって重要な、巨大な境界づけられたコンテキストがあり、モデルの本質的な部分が大量の補助機能のせいでわかりにくくなった時」と「ドメイン駆動設計」に書かれているが、そのタイミングでは手遅れではないか、という質問もあった。

確かに、コアドメインがどんどん巨大になっていた事実に気づいた時には、リファクタリングしようにも本番稼働中なので手を入れられず、最終的には、既存ドメインを捨てて、新規システムへリプレースするしかない経験が多い。
隔離されたコアを抽出して修正すべきタイミングを見つけるのは、実際にはとても難しい。

議論の中では、一つの解決法として、CIのメトリクスで凝集度や結合度などのメトリクスを常時測定しておき、メトリクスの兆候がある閾値を超えるとか、メトリクスの怪しげな傾向を見つけたら、隔離されたコアを抽出するタイミングと判断することもあるね、という話もあった。

【1-5】「<<コア>>」「<<汎用>>」はステレオタイプ。
パッケージ名やクラス名に、「~コアクラス」と書くのは良くない。
「<<コア>>」「<<汎用>>」はタグのようなものだから、ステレオタイプにした方がいい。

【2】16章「責務のレイヤ」

・ポリシー、業務、能力のレイヤは、パッケージを横断した構造ではないか?

・「業務」はイベント、トランザクションに相当。
・「能力」「潜在能力」はマスタ、リソースに相当。

・顧客が「能力」に相当する理由:
→輸送会社の例では、顧客はリピータ中心のため、顧客はビジネス上の資源であり、何度も活用する情報である。
 例:ダイレクトメールを客に送って、輸送の注文を促す

・逆に、一見の顧客の場合、顧客は「業務」でとらえられる。
 一見の顧客なら、顧客の情報をマスタとして持つ必要がない。
 トランザクションテーブル(例:輸送、配送、注文)に顧客の情報が含まれて、混在しているだろう。
 トランザクションテーブルに混じっている顧客データは、再利用される対象ではない。

・運送行程クラスは「能力」層なのに、「望ましい(isPreferred)」というメソッドがあり、唯一調和していない。
 そこで、「ドメイン駆動設計」では、運送行程クラスの「望ましい(isPreferred)」を「経路偏向ポリシー」クラスへ外出しして、「ポリシー」層に抽出している。

・新しい機能「特定の危険物に対しては、経路選択時に制限が適用される」をドメインモデルに反映する場合、従来のクラス設計では、「危険物経路サービス」を作ったとしても、呼び出しクラスになる「貨物」クラスにロジックが集中し過ぎて良くない。
 そこで、「ドメイン駆動設計」では、「経路選択サービス」に危険物の経路判断の呼び出しロジックを移動し、貨物クラスから切り離す。

・「ドメイン駆動設計」における「~サービス」クラスは、ユースケースに相当する。
 ユースケースに該当するサービスクラスが、業務ロジックのトリガーになっている。

| | コメント (0)

2014/08/22

Redmineによるチケット駆動開発はパッチ駆動開発と同じ

ソフトウェア開発をRedmineによるチケット駆動開発で進めていると、パッチ駆動開発のように思える時がある。

【1】まず、SubversionやGitのリポジトリにソースコードがあるとする。
そのソースに対して、チケットに書かれた内容をどんどん実装して、リポジトリへコミットしていく。

たとえば、チケットには以下の内容が書かれているだろう。

お客さんから、機能の追加要望があった。
方式設計に不備があり、フレームワークにパッチを当てる必要がある。
本番障害を調査したら、実は以前リリースしたソースにバグがあったので、すぐに直さなくてはいけない。
新機能の実装をしていたら、エラーメッセージの仕様の不明点があり、お客さんに仕様を決めてもらった。

それらチケットは作業指示書と同じ。
仕様をソースコードで表現したものが「パッチ」になる。

そのパッチがチケットの成果物だ。
チケットがCloseするタイミングで、そのパッチはリポジトリにある製品のtrunkにmergeされる。

パッチがトリガーとなって、リポジトリはどんどん最新化され、強化されていく。

【2】Gitが普及する以前は、CVSやSVNのtrunkと比較して、diff出力してパッチを作っていた。
shohinManager.diffみたいなパッチを作っていた。

開発者がそのdiffファイルというパッチをチケットに添付したら、レビューアはそのパッチをレビューし、OKならtrunkにmergeしていた。
コードレビューというプロセスも、Redmineのワークフロー機能で有効にカバーできた。

今なら、Git+Redmineの運用が普通だろう。
すると、Git上で各チケットに対し、トピックブランチが作られ、トピックブランチ上でパッチが育まれる。
パッチが完成したら、Gitリポジトリに取り込まれる。

GitHubでは、パッチのやり取りがすべてWeb上で行われるから、すごく便利。
パッチをローカルPC上で、手作業で差分比較しながら作る必要もない。

gitのコマンドを駆使して、必要なリビジョンをつまみ食いしたり、複数のリビジョンを一括でまとめたり、色んなマージ方法を選択できる。
マージ用の別ブランチを作れば、パッチの色んな作り方を試すこともできる。

その開発プロセスは、git-flowやGitHub-flowで整理されて公開されており、そのプロセスを真似れば、ブランチ管理の方針も開発チーム内で共有できる。

Gitのおかげで、パッチ作りやパッチのmergeは非常に簡単になった。

【3】パッチ駆動開発とは、「チケットの成果物がパッチ」であること。

チケットは仕様書ではない。
チケットは成果物ではない。
チケットは作業指示書であり、チケットは課題やQAだ。

チケットの成果物がパッチ。
パッチはリポジトリのtrunkに取り込まれる。
リポジトリにあるソース、つまり製品は、常に最新の機能を持ち、いつでもリリースできるブランチでもある。

【4】パッチ駆動開発の意義は、「成果物と実際の作業内容は区別されて管理すべき」という主張だ。
チケットは、成果物のメタデータに相当する。
作業内容は、チケットに書かれるべきであり、ソースやパッチに書かれるべきものではない。

もし、チケットなしでパッチを作っていたら、そのパッチはそもそも何の目的で作っていたのか、を忘れてしまうだろう。
だから、一昔前のプログラミングでは、ソースコードの冒頭に、修正履歴をコメントで書く習慣があった。

チケット駆動開発を推進すると、ソースコードにある修正履歴や、無駄なコメントは、ソースコードから省かれる。
そんな修正履歴はチケットに記載し、いつでもソースのリビジョンから参照できるようにしておけばいい。
そうすれば、ソースコードは常に綺麗な内容になるし、短くできる。
ソースコードは常に最新の機能を持つ状態であればいい。

過去の経緯はソースコードに書く必要はない。
過去の経緯はチケットに書き、「No Ticket, No Commit」によるトレーサビリティによって、チケットからいつでも参照できればいい。

【5】この発想を突き詰めると、リポジトリにあるものがソースだけでなく、設計書やドキュメントも同じだと分かる。
なぜ、Excelの設計書には、変更履歴というシートが必要なのだろうか?

チケット駆動開発で設計書を作っていたら、修正の発端となったトリガーはチケットに記載されている。
チケットの内容に従って、設計書の修正部分を反映し、設計書を最新化する。
設計書の修正部分が「パッチ」に相当する。

ただし、Excelの設計書の場合、ソースのdiffファイルのようなパッチを明示的に作れないのが最大の弱点だ。

設計書の変更履歴に「チケットNo.123を参照」として書くのは、結局、リポジトリ画面にある一つの設計書のリビジョン履歴と同じだ。
コミットログにチケットNoを書いてコミットすれば、コミットログが設計書の変更履歴と同じ。

わざわざ、Excelの設計書に変更履歴シートを作る必要はないのだ。

そして、Excelの設計書も、修正パッチのようなファイルが作れるとなおよい。
そのパッチを積み重ねれば、設計書は常に最新機能を持つ状態として維持しやすくなるからだ。

| | コメント (0)

2014/08/17

製造業の受注生産プロセス

受注生産に徹すれば利益はついてくる! -取引先に信頼で応える“おもてなし"経営-」本の内容のうち、製造業の受注生産プロセスをまとめてみた。

【受注設計生産(ETO)】
【業界】造船、製鉄、金型
【リードタイム】3~6ヶ月
【在庫】仕掛品在庫が予測しにくいので増加しやすい
【特徴】
・特注品を作る受注生産。
・顧客の満足度は高いが、待たされる納期が長い。
・納期調整が難しく、仕掛品在庫が増加しやすい。


【繰返し受注生産(MTO)】
【業界】機械
【リードタイム】1~2ヶ月
【在庫】仕掛品在庫は少ない。
【特徴】
・あらかじめ設計済みの製品(部品組立は未実施)を受注後に生産開始する。
・日本の中小企業は、繰り返し性の強いMTOを主体にしている。
・注文または内示情報をトリガーに生産を開始するので、生産計画を事前に立てにくい。
・生産調整が難しいので、工場の操業度が変動しやすい。赤字と黒字を繰り返しやすい。


【受注組立生産(ATO)】
【業界】PC組立、自動車
【リードタイム】短い
【在庫】在庫が増えやすい
【特徴】
・部品は先行手配または見込生産で在庫しておき、受注後にその部品を組み立てて製品を出荷する。
・MTOではリードタイムが長すぎ、MTSでは製品在庫が膨れ上がるような製品が多い。
・多品種少量生産プロセスでよく使われる。
・欠点は、在庫が増えやすい(MTSの欠点)。工場の操業度変動が発生しやすい(MTOの欠点)の両方を持つ。

【見込生産(MTS)】
【業界】家電
【リードタイム】極端に短い。
【在庫】完成品(製品)の在庫が膨れ上がりやすい。
【特徴】
・販売予測を基に生産計画を事前に作り、生産計画に基づいて製品を作る。MRPが主流。
・受注生産企業でも、製品保守サービスのために保守部品を見込生産で作りこんでおく所もある。

【感想】
受注生産に徹すれば利益はついてくる! -取引先に信頼で応える“おもてなし"経営-」本にも書かれているが、現在の日本の製造業は、繰り返し受注生産(MTO)がベースにあるが、多品種少量生産が普通なので、トヨタのようなATO(BTO)生産方式を目指そうとしている。
しかし、ATO生産方式は、在庫が増えやすく、工場の操業度変動が発生しやすい弱点を持つ。
したがって、ATOを推進するのは非常に難しい。
JIT生産コンサルタントを入れても、なかなか効果が出ないらしい。

トヨタがATOで成功している理由は、受注から製造までの各工程の在庫の変動量を、トヨタが系列会社も含めて統制しているからだ、と指摘しているのは、なるほどと思う。

だから、トヨタはすごいのだ、という指摘もあるけれど、僕よりも年上の人達に聞くと、トヨタには「自動車絶望工場 (講談社文庫)」のようなイメージもあって芳しくない話もあったらしい。
今はどうなのかは知らない。


| | コメント (0)

「業務システムモデリング練習帳」の感想

実際のデータモデリングの事例があり分かりやすい。

興味深いのは、第一部に、データ構造(ER図)と画面レイアウトに関連性が記載されていること。
発想としては、Railsのscafoldに似ている。
この発想を使えば、ER図から画面レイアウトを想像できるし、逆に画面レイアウトからER図を連想できるようになるだろう。
データ構造と画面レイアウトのパターンを明示した書籍として素晴らしいと思う。

【1】Singleタイプ

データ構造:
・単一テーブル。または、参照関係を持つ(外部キーを持つ)単一テーブル。

画面レイアウト:
・1画面に1テーブルの1レコードを表示・編集する。

例:顧客マスタ保守画面

注意点:
・外部キーはプルダウンになる。
・または、隣に検索ボタンがある場合がある。

【2】Multipleタイプ

データ構造:
・外部キーを持つ単一テーブル。

画面レイアウト:
・1画面に1テーブルの複数のレコードを表示・編集する。
・画面のヘッダ部に、外部キーまたは他キーによる検索入力部がある。
・画面の明細部に、検索結果後の複数のレコードを表示する。

例:商品マスタ検索画面

注意点:
・再帰構造を持つデータ構造の場合、ツリー表示の画面レイアウトになる。
 →例:部品表の編集・参照画面。

【3】Familyタイプ

データ構造:
・親子関係にあるテーブル。
・子テーブルは、複合キーを持つ。

画面レイアウト:
・ヘッダ部と明細部(一覧)を持つ。
・ヘッダ部に、親テーブルの1レコードを表示する。
・明細部に、ヘッダ部のレコードに対応する「子テーブルの複数レコード」を表示する。

例:受注ヘッダ・受注明細を結合した受注登録・参照画面。

注意点:
・参照関係を持つテーブルの編集・登録画面で使われる時もある。
 その場合、【2】Multipleタイプと同じ画面レイアウトになる。


| | コメント (0)

2014/08/16

「SysML/UMLによるシステムエンジニアリング入門」の感想

SysMLの概要、SysMLのダイアグラムの意味や使い方を知るのは良い本。
最近IPAが注目している「組込システム開発にモデルベース設計を適用する」発想が何となく分かった。
この本では、SYSMODと呼ばれるSysMLを使ったモデリングアプローチを紹介している。

【流れ】
プロジェクトスコープ、ステークホルダー分析を実施

要求を収集して要求図を作成

開発対象のシステム境界(開発スコープ)を明確にするために、システムコンテキスト図(ブロック図の一種)を作成

システムやアクターの情報フローをモデル化する。
・情報フローはアクティビティ図で作成&詳細化
・アクターやシステムの内部構造の仕様が分かったら、ブロック図でメモしておく
・システムの相互作用点(ポート)はブロック図で表現
・概念モデルを書きたいなら、ブロック図でメモしておく

システム境界が明確になったら、要求図を元に、システムが提供するサービスをユースケース図で表す。
要求図の機能要件は、ユースケースで詳細化(refine)したり、システムの部品(block)で実現(satisfy)したり、非機能要件の関連を追跡(trace)で表す。

洗い出したユースケースは、ユースケースフローとしてアクティビティ図でモデル化する。
つまり、ユースケースは、アクティビティ図のアクティビティ(サブアクティビティを持つ)へマッピングされる。

システムに対する一般要件を元に、ドメイン知識が溜まってきたら、ブロック図でシステム構造を表現する。
UMLのクラス図(概念モデル)に似ている。

ドメイン知識を表すブロック図を元に、システムやアクターの相互作用をモデル化する。
・システムの相互作用はシーケンス図。
・システムの部品(block)の状態の遷移はステートマシン図

システムの入出力をモデル化する。
・部品(block)の内部構造は、内部ブロック図で描く。UMLのコンポーネント図に似ている。

作成したモデルのシミュレーションは、物理法則を表すパラメトリック図と連動して実施する。

テストするために、要求図からテストケース(testcase)のモデル要素を作成する。
要求は、テストケースによって検証されるため、検証(verify)の関連が引かれる。

【感想】
・レンタカー会社の車載システムを例にSysMLの使い方を説明しているので分かりやすい。
 ソフトウェア開発チームがハードウェア開発チームとコミュニケーションしたい時に、SysMLを使えば、設計情報を共有できるので、理解しやすくなると思う。
・ブロック図などのように、組込システム設計をすごく意識している。
・SysMLはUMLよりも、各ダイアグラムのトレーサビリティを重視している。
 したがって、モデリングの成果物の品質がより強化されるように思う。
・SysMLがUMLよりもトレーサビリティを意識しているおかげで、モデルの粒度や案件のスケールアップにも対処しやすい。
 開発プロセスに合わせてカスタマイズしやすいだろうと想像する。

| | コメント (0)

2014/08/15

ソフトウェアパターンの記事

ソフトウェアパターンの記事があったので、リンクをメモ。

【参考】
先人の知恵を集めた「ソフトウエア・パターン」 - 第1回 適用範囲が拡大する「ソフトウエア・パターン」:ITpro

先人の知恵を集めた「ソフトウエア・パターン」 - 第2回 アクティビティ配置のひな型「ワークフロー・パターン」:ITpro

先人の知恵を集めた「ソフトウエア・パターン」 - 第3回 成果物や組織の管理方法「マネジメント・パターン」:ITpro

(引用開始)
 パターンの目的はソフトウエア開発で直面する様々な問題とその解決策を明快に示すことだ。先人の経験に裏打ちされていることから,パターンは先人の知恵とみなすことができる。パターンで示されている問題に実際に直面したとき,そこに書かれている解決策は大いに参考になる。

 例えば,最も知名度の高いパターンにGoF(Gang of Fourの略)の「デザイン・パターン(Design Pattern)」がある。このパターンは,主に詳細設計で直面しがちな問題を23種類のパターンとして示している。その中のオブザーバー(Observer)パターンでは「あるオブジェクトの変化を他のオブジェクトに伝えたいが,通知したいオブジェクトを静的に決定できない」という問題を提起。その上で「通知するオブジェクトに対して共通のインタフェースを実装し,それらを変化するオブジェクトに登録する」という解決策を示している。

 これまでソフトウエア・パターンと言えば,ソフトウエア開発の分析,設計,実装の各フェーズを対象にしたものが中心だった。具体的には,クラス/データモデルの分析フェーズでは「アナリシス・パターン」や「データモデル・パターン」,基本設計フェーズでは「アーキテクチャ・パターン」や「エンタープライズ・インテグレーション・パターン」,詳細設計では「デザイン・パターン」,実装フェーズでは「イディオム」――といった具合である。

 ところが,ここに来てパターンの適用範囲が急速に拡大している(図1)。背景にあるのは何か。パターンに詳しいサイクスの宗雅彦社長は「分析/設計/実装といったエンジニリング・プロセスの知識だけでは,高品質なソフトウエアを素早くかつ確実に作れなくなったこと」と見る。言うまでもなく,開発すべきシステムは大規模化・複雑化し,短納期や高品質への要求も高まるばかり。そうした中では,ソフトウエア開発の「問題」も分析,設計,実装にとどまらない。これを受けて,適用範囲が広がりを見せているのだ。
(引用修了)

紹介されているパターンは以下の通り。

・デザイン・パターン
 →GoFの本「オブジェクト指向における再利用のためのデザインパターン

・アナリシス・パターン
 →ファウラーの本「アナリシスパターン―再利用可能なオブジェクトモデル (Object Technology Series)

・データモデル・パターン
 →「Data Model Patterns: Conventions of Thought (Dorset House eBooks)

・アーキテクチャ・パターン
・エンタープライズ・インテグレーション・パターン

・ワークフロー・パターン
 →「詳説 ビジネスプロセスモデリング ―SOAベストプラクティス (THEORY/IN/PRACTICE)

・構成管理(Software Configuration Management)パターン
 →「パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

・導入パターン
 →「Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

データモデルパターン以外は邦訳もある。
データモデルパターンとワークフローパターンだけは読み切れていないので、読んでみたい。

| | コメント (0)

「超高速開発が企業システムに革命を起こす」の感想

超高速開発は、企業の社内向け業務システムが基本なので、アジャイル開発とは相性が悪く、データモデリングを基本にすべきという発想。
そして、データモデリングや業務フローの設計情報を設計リポジトリに一元化し、そこからプログラムを自動生成する流れ。

この考え方は昔のモデル駆動開発をリプレースに見える。
最近の開発プロセスの進化(GitHubのソーシャルコーディング、クラウドによるシステムのサービス化、ビッグデータ)とつながっていないのが気持ち悪い。
メーカー系企業の情報システム会社は好きそうだろうが、ソフトウェア開発の技術革新につながらない気がする。

| | コメント (0)

2014/08/13

Mooldeの基本的な概念

Moodle 2ガイドブック―オープンソースソフトウェアでオンライン教育サイトを構築しよう」本を読んだ。
Moodleの基本概念(ドメイン)をメモ。


【発端】
この記事を書こうと思った発端は、「ルポ MOOC革命――無料オンライン授業の衝撃」を読んで衝撃を受けたから。
2011年は電子書籍元年と言われたが、2012年はMOOC元年と言われていたのに気づかなかったから。
実際、MITの無料授業公開をきっかけとして、米国の大学はほとんどが無料の授業を公開しているらしい。

| edX

Course Catalog for Online Classes - Udacity

Your Courses | Coursera

2014年になってようやく、東大や京大もMOOCに参加する記事があった。
日本の大学も、世界中の大学と競争せざるを得ない環境に陥っている。

MOOCとは - はてなキーワード

181号 世界で広がる無料のオンライン講義とは 1/4 : カレッジマネジメント : リクルート進学総研

東京大学[社会連携] 大規模公開オンライン講座(MOOC)

edXで京都大学の無料講義配信が始まる! - 化学者のつぶやき -Chem-Station-

MOOCが広がれば、大学入学のために数百万円や数千万円の授業料を払わずとも、独学で習得し、修了証をもらえる。
その修了証が大学卒業の資格と同じくらいの価値があるようになれば、大学に行かなくてもいいい。
その結果、大学の存在価値が薄れる影響がある。

一方、MOOCの修了証が社会で認知されれば、人は義務教育を卒業しても、一生学習せざるを得ない。
実際、会社の平均寿命は人の労働期間よりも短いし、10年後に働いている職場、職業は変わっているだろう。
つまり、MOOCのような無料オンライン授業を使うなどして、人は生きている間、時代に追いつくために学習し続け、自分の生活手段を確保する必要があるのだろう。

ただし、注意すべき点は、今世界で流れているMOOCのほとんどは大学生向けの英語の授業であること。
英語が読み書きできるだけでなく、英語で授業を理解する能力も必須条件。
英語ができなければ、最先端の知識やノウハウの学習すらできない。
その点では、日本人にはギャップがある。

現在の日本ではようやく、小学生から英語学習する流れになってきたが、この流れは止まらないだろう。
日本の中学生・高校生で能力のある人は、学習の早い段階から、MOOCのような授業を見て、世界の潮流や世界のレベルを知っておくべきなのだろう。

【1】Moodleの基本フロー

教師の授業(Moodleでは「コース」と呼ばれる)をサポートするWebシステム。
PDCAサイクルで回ると考えると分かりやすい。

Plan:
 授業の理念や授業設計を行う。
 →アウトカム、評価尺度、コース、レッスン、リソース。

Do:
 教師がコースを使って授業の情報を公開し、生徒とやり取りする。
 →フォーラム、チャット、用語集、データベース、活動、リポジトリAPI、リソース連携。

Check:
 教師が生徒をテストで評価したり、授業のフィードバックを得る。
 →課題、ワークショップ、フィードバック、調査、小テスト、盗作プラグイン。

Action:
 テスト結果やフィードバックから、データ集計したり、テストの集計結果を生徒にフィードバックする。
 →ポートフォリオ、評定、評定者レポート、統計、バッジ(OpenBadge、バックパック)

【2】基本概念

【コース】
授業ごとのWebページ。
授業や学習プログラムごとに先生と学生を登録する。
登録メンバーのみアクセス可能。

【リソース】
教材や資料。
PDFやパワポ、動画、音声など。

【活動】
小テスト、相互評価、フォーラムなどのオンラインでの活動。
Redmineの活動ログと同じ機能。

【条件付き表示】
ある資料を参照したり、特定の課題を提出しなければ、コースにある次のステップに進めないような制約条件。
生徒の進捗度合いに合わせて、学習できる。

【完了チェック】
各コースの修了条件を設けて、学習の修了を自動判断する。
授業の単位修得の制約条件。
普通はテストで学習の達成度合いを測定する。

【外部ツール】
他のサーバーと連携する。
LTI規格。
Moodleでは、リポジトリAPIとは異なる機能。

【リポジトリAPI】
外部のリポジトリから教材や資料を検索、取得して、コースに追加する。
国内・海外の教材リポジトリを横断的に検索して、コースへ登録できる。

教師が授業に関するすべての材料を位置から作る必要はない。
他の教師が作った資料やWeb上の資料を授業に流用して、コース準備のコストを下げる。

【フォルダ】
リソースのうち、静的な資料を分類する。

【ブック】
リソースのうち、文章やメディア(動画、音声など)を分類する。

【ラベル】
リソースをコースに掲載する。
ポータルページに記載するイメージ。

【課題】
先生が説明文を提示し、学生がテキストやファイルを提出する。
宿題に似ている。

【フォーラム】
オンライン掲示板。
教師と生徒、生徒同士の掲示板。

【チャット】
コース上のリアルタイムなやり取り。
コースの登録ユーザのみ可能。

【用語集】
コースのページに用語辞典を配置。
用語集の自動リンクを有効にすると、用語集の言葉がコース内にあると、リンクされる。
Wikiやはてなの用語リンクと同じ。

例:コースに関連した用語。
例:学生が集めたプラクティスやTIPS。
例:試験対策のデータベース(Moodleの機能)。

【フィードバック】
先生自らが作成して、アンケートを実施する。
アンケートと同じ。
回答は匿名もOK。

例:授業評価、実態調査。
例:コースに追加して、授業中にリアルタイムにアンケート実施。
例:あるアンケートを行い、学生に考えさせる。

【調査】
用意された質問に対する回答を収集する。
Moodleで決められた仕様がある。

【投票】
用意された質問に対する投票。
アンケートとは異なるMoodleの機能。

【小テスト】
様々な出題形式のテスト。
問題バンクに登録されていれば、問題を流用できる。

【ワークショップ】
他の学生の提出物を学生同士で評価し合う。
PBLでの相互評価(ピアレビュー)。
課題(Moodleの機能)とは異なる。

【データベース】
コース上で、学生や生徒によるデータの登録。
例:歴史的事件の内容をデータベースに登録する。

【レッスン】
シナリオ型教材。
コースの一種。
学習の回答で分岐する機能も持つ。
ロールプレイゲームに近い。

【評定】
成績と同じ。

【評定者レポート】
成績表と同じ。
指名、メルアド、各活動の評定を表示する。

【評価尺度】
コース内の評価尺度。
普通は、4~6個の基準を策定する。

例:4段階評価(悪い・普通・良い・大変良い)

【統計】
Cronを設定すると、コースの利用履歴などをレポート集計してくれる。

【バッジ】
修了バッジを発行する。
制服に着ける腕章、ワッペンと同じ。
OL授業の修了時にバッジを発行して、到達度や学習成果を見える化する。
生徒の達成意欲を刺激する。

【OpenBadge】
OpenBadgeという国際規格もある。
学習の修了者のバッジを発行できる発行者を認定する。
PNGデータに暗号化されたメタデータを入れ込んで、改ざんを防止する。

例:カーンアカデミーの修了バッジ

多くの人達がカーンアカデミーを選ぶ理由。 スマートスが調査した! | スマートラーニングガイド

最近は、MOOC(大規模無料オンライン授業)の修了証として、OpenBadgeを使い、大学入試や就職などに役立てようという動きがある。

Open Badges 1.0 のご紹介 ~さまざまな教育機関で習得したスキルを証明し、それを関連サイトで共有できます~ | Mozilla Japan ブログ

オンラインの資格学歴証明をどうするか??Mozillaが普遍的な枠組みOpen Badges 1.0をリリース - TechCrunch

【バックパック】
バッジ情報を集約するサービス。
例:MozillaのBackpackサービス。

Open Badges

【アウトカム】
コンピテンシー。
クライテリア。
コース(授業)で達成すべき学習目標。
評価尺度で評価する。
コースを紐づける。

例:異文化理解。学習指導要領の達成。

【ポートフォリオ】
学生の成果物を外部サーバへ転送する。

例:Flickr、GoogleDoc、Picasoなど。

【完了トラッキング】
コース内の学生の学習の進捗を追跡する。
Redmineのチケットトラッキング機能に似ている。

【盗作プラグイン】
成果物の盗作や剽窃を防止する。
外部システムと連携して、盗作プラグインを実現する機能もある。

例:卒業論文や修士論文の盗作防止。


| | コメント (0)

2014/08/10

オープンソースのBPMツールBonitaのメモ

オープンソースのBPMツールBonitaのメモ。

【参考】
なぜ超高速開発が話題になるのか~キーワードはビジネスルール管理システム(BRMS): プログラマの思索

BPMとワークフロー: プログラマの思索

【元ネタ1】
ビジネス・プロセス・マネジメントのための Bonita: 第 1 回 単純なワークフローを構成する

ビジネス・プロセス・マネジメントのための Bonita: 第 2 回 フォームと変数を構成する

第1回 BPM/SOAの設計・実装アプローチ | Think IT(シンクイット)

第2回 BPMN 2.0の概要とビジネス・プロセス・モデリング | Think IT(シンクイット)

第3回 BPMN 2.0エンジンと各社BPMツールの実装 | Think IT(シンクイット)

第4回 ビジネス・プロセス・モデリングの最新動向 | Think IT(シンクイット)

オープンソースBPMジャパン株式会社 - オープンソースBPMジャパン株式会社

オープンソースのBPMツールBonitaは、Eclipseに似た画面からワークフローをBPMNで記載すれば、プログラムや帳票も自動生成できるらしい。

BPMN プロセス モデル ルームへようこそ  ProcessLib - オープンソースBPMジャパン株式会社

下記のサンプルを見ると、普通の会社で頻繁に現われるであろうワークフローに関する業務のサンプルが公開されている。

Bonita BPMの国内Webサイトが公式オープン、BPMN2 サンプル図を一挙公開 | 岩田研究所

P01: 人材募集と採用(Recruitment And Selection)
P02: 社員休暇管理(Employee Leave Management)
P03: 新規社員の配属(Employee Onbording))
P04: 出張申請(Travel Request)
P05: 提案依頼RFP(Request For Proposal)
P06: 注文書チェック(Purchase Order Validation)
P07: 請求書チェック(Invoice Validation)
P08: 販売ノルマの設定(Sales Quota Setting)
P09: クレーム管理(Claims Management)
P10: ローン承認(Loan approval)
P11: 予算編成(Budgeting)
P12: 旅費精算(Travel Expense)
P13: ITヘルプデスク(IT Help Desk)
P14: インシデント管理(Incident Management)
P15: ロードマップ管理(Roadmap Management)
P16: 支出権限レベル(EAL)申請(Expenditure Authorization Level)
P17: プロセス・ガバナンス(Governance - Process Improvement)
P18: 認証(Certification)

そもそもBPMツールやBPMNのようなワークフロー管理ツールが必要とされるのは、ERPで必ず含まれる一機能であるのに、パッケージ製品ごとに仕様がバラバラで共有しにくいし、理解しにくいからだろう。
また、業務のワークフロー管理は、さほど難しい要件でもないし、設計も難しくないのに、構築コストが大きすぎることもあるだろう。

BonitaのようなオープンソースのBPMツールが普及することによって、ERPはより安い方向へ向くのではないか。

【元ネタ2】
BPMはソフトウェア工学ではない

ソフトウェア工学はプロセスプログラミングの一種とみなすこともできる。
すると、BPMのようなツールでソフトウェア工学の成果を表現することもできるのではないか?
実際、BPMツールでプロセスをワークフロー化すれば、無駄なプロセスも判明するだろうし、どのプロセスがボトルネックになっているかも分析できるだろう。

しかし、BPMツールで開発プロセスは表現できるだろうが、そのプロセスにした意図や要件までとらえるのは難しい。

プロセスプログラミング とは - コトバンク

プロセスプログラミングに関しては、@sakaba37さんが色々書かれている。

[#TiDD] プロセスプログラミング1 - ソフトウェアプロセスもソフトウェアである -: ソフトウェアさかば

[#TiDD] プロセスプログラミング2 - ウォーターフォールとアジャイル -: ソフトウェアさかば

[#TiDD] プロセスプログラミング3(改) - ファシリテーション -: ソフトウェアさかば

【追記】
さかばさんからTwitterがあったのでメモ。

「BPMはソフトウェア工学ではない」という意味は、

「BPMはプログラム実装ではない」
→「BPMはエンジニアリングではない」
→「BPMはソフトウェア工学ではない」

という流れらしい。

さかばさんはTwitterを使っています: "「ソフトウェア工学」ではなく「…エンジニアリング」「…実現技術」と訳さないとそういう誤解が生まれますね。 RT @akipii: ソフトウェア開発プロセスもプログラムの構造を持つという発想と同じか。 BPMはソフトウェア工学ではない http://t.co/Hi4GjXrkhy"

さかばさんはTwitterを使っています: ".@akipii 記事はビジネスプロセスモデルはプログラム実装(エンジニアリング)そのものではないよと言っていますが、それをソフトウェア工学ではないと訳して意味が不明になっているだけです。"

| | コメント (0)

BOMのトポロジー類型~MRPとBOMの関係

BOM/部品表入門」を読んで、BOM(部品表)には構造があり、その構造という制約によって数々の性質があると書かれていた。
BOM(部品表)のトポロジー類型についてメモ。

【参考】
工程データ・物流ルートをも統合する新世代の部品表 - TechTargetジャパン ERP

広義のBOM--その輪郭 生産マネジメント ワンポイント講義(5) BOM(部品表)

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

【1】製造業に導入されたERPの中で、MRPとBOMは生産管理の最重要な機能。
普通は、BOMという部品表を使ってMRPが所要量展開して計算して、調達すべき部品の数量と納期、発注時期を算出する。

BOM/部品表入門」を読むと、BOMの種類によって、所要量展開の方法が微妙に異なるらしい。
例えば、BOMの構造は組み立て加工ならA型とか、素材産業ならV型とか言われるらしい。

実は、TOCで有名なゴールドラット博士が様々な製造業の現場を見て、BOMの形によって類型化できると気が付いたらしい。
そのあたりをまとめてみた。

【A型】
【業界】組立加工。機械、自動車など。
【特徴】
・他のBOMに比べて生産指示は単純。
・部品の個数が多く、部品ごとのリードタイム(発注・製造・納品等)が違うため、部品調達が大変。
・MRPで部品の見込生産の計画を作り、所要量展開を計算する方向へ発展した。

【I型】
【業界】半導体
【特徴】
・一つの素材を複雑に加工して出荷する。
・BOMの必要性が意識されない場合が多い。
・V字型の製品は1つずつ見れば、I字型になる。

【V型】
【業界】製鉄業、石油精製業、食肉加工業、家電リサイクル
【特徴】
・一つの原材料から多種多様な製品(連産品)が作られてしまう。
・ある製品だけを独立して生産できない。
・期待していない連産品の製造実績が作られてしまい、在庫が増えやすい。

【T型】
【業界】化粧品、潤滑油、プラスチック製造などの素材産業
【特徴】
・最終段階の加工で多種多様な製品が生まれる。
・最終加工で添加物や容器を変える場合が多い。

【X型】
【業界】化学、酒造業、豆腐製造など
【特徴】
・複数の原材料を化学反応させて製品を作るが、副産物(例:酒かす、おから)が必ず生まれてしまう。
・副産物は販売できる。
・副産物はBOMに材料として登録し、員数(部品の必要数量)=マイナス値、標準リードタイム=0に設定する。
 →所要量展開すると、マイナスの総所要量が発生する=副産物は意図しなくても作られる。
・員数=マイナス値、総所要量=マイナス値が扱えるMRP計算システムが必要とされる。

【Q型】
【業界】製鉄、化学、ガラス
【特徴】
・製造工程の生産物の一部が現在利用としてリサイクルできる。
・BOMの形としては、リサイクルされる生産物(原材料)は再帰構造を持つ。
・リサイクルされる生産物はBOMに材料として登録し、員数(部品の必要数量)=マイナス値、標準リードタイム=0に設定する。
・多くのMRP計算システムでは、リサイクルされる製品の部品展開計算はできない。(部品が再帰構造を持つため)

【2】製造業と言えば、自動車や家電製品をイメージするが、実際はたくさんの種類がある。
たとえば、製鉄、化学、酒造業、化粧品、食品加工(!)などは、部品も違うし、製造工程もかなり違う。

特に、X型やQ型のようなBOMは、員数(部品の必要数量)=マイナス値のような値を設定するので、正直混乱する。
必要な部品の個数がマイナス値の部品とは何なのか、僕も正直理解できなかった。

でも、製造業の業務システムでは、上記のような業務知識や設計思想は正直知らなくても、実際の現場は回っている。
その理由は「受注生産に徹すれば利益はついてくる」にも書かれている通り、ERPがほぼすべての大企業に導入された結果、パッケージ製品の標準機能だけでほとんどの業務がIT化できたために、上流工程の知識がなくても製品の機能比較(フィットギャップ分析)だけで導入できるようになってしまったから。
その結果、ユーザ企業の情報システム部門では、上流工程で設計できるメンバーが必要とされなくなり、技術力も設計力もすごく落ちている会社が非常に多いと思う。

今後も、ERPが主流であり続ける限り、上流工程の業務知識が軽視される傾向は続くだろうと思う。
ERPが業務の複雑な内容をブラックボックス化してしまったから。

とはいえ、ゴールドラット博士が生み出した部品表のトポロジー類型とその制約から発生する機能要件は、重要な話だと思っている。

| | コメント (0)

2014/08/09

「APIデザインの極意」のメモ

APIデザインの極意」の感想Blogがとても素晴らしいのでメモ。
APIデザインの極意」を買おうと思ったら、台風で警報が出ており、買いに行けないのが残念。
ラフなメモ書き。

【元ネタ】
アジャイルAPI設計時代の到来!?APIデザインの極意を読みました。 - シスアーキ in はてな

ソフトウェア再利用の概念: プログラマの思索

ソフトウェア部品化の幻想: プログラマの思索

SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索

【1】ソフトウェア再利用の概念としては、ホワイトボックス再利用、ブラックボックス再利用の2種類の区別がある。

ブラックボックス再利用とは、再利用資産を変更なしでその まま利用する。
よくある例は、GUIコンポーネントや数値演算ライブラリなど。
例えば、DLL、Jar、Exeなどのバイナリの実行ファイルが相当するだろう。

ホワイトボックス再利用とは、再利用資産を要求に合わせて部分的に変更して使用する。
よくある例は、オブジェクト指向設計によるフレームワークなど。
例えば、Struts、Hibernate、Rails、Playなどの有名フレームワークが相当するだろう。

2000年代初頭の頃までは、コンポーネント指向開発が今後進むべき道だ、と言われていた。
オブジェクトを再利用資産として持ち、その資産を触らず、接着剤の部分だけソースを書けばよい、と。

【2】しかし、実際は、再利用できる部品を作り出すのが難しい。
再利用できる部品になるような設計が難しいのだ。
実際は、部品そのものに手を入れてしまい、中身はスパゲティコードになり、破たんする。
ソフトウェアプロダクトラインも、ドメインから再利用できる概念をコア資産として抽出しようとしたが、開発コストがかかり過ぎる割には、効果が薄いという評価が多い。

最近の傾向としては、フレームワークを使った開発手法を取るのが多い。
受託開発では、アーキテクチャ設計時に、どのフレームワークを採用するか、という決断が大きなウェートを占める。
良いフレームワークを採用すれば、開発効率や品質を担保できるし、知名度が高ければ、開発者の要員確保も楽になる。
その後の保守もやりやすいはず。

特に、Webシステム開発では、工期短縮のために、その時に有名なフレームワークを採用して、一気に作り上げる開発スタイルが多いと思う。

【3】しかし、フレームワークの利用にも癖がある。
SIerの俺様フレームワークは最悪に激しく同意: プログラマの思索にも書いたが、大手SI独自のフレームワークを作りこんだ場合、保守が非常に大変だ。

俺様フレームワークはなので、中身が公開されていないので自分たちでパッチを当てることもできない。
フレームワークの修正を依頼しても拒否されたら、仕方なく、非常にダーティなパッチを当てて、その場限りの障害再現の回避を取らざるを得ない。
そんなことをしていくうちに、本番稼働中のソースを修正するのは忘れ去られて、ソースがどんどん汚くなる。

しかも、フレームワークのバージョンアップに追随できなくなる。
パッチを当てた箇所に影響が出るかもしれないから。
つまり、フレームワークのバージョンアップのたびに回帰テストの工数が増えて、顧客から見れば、何の価値も生まないバージョンアップに多大なコストを強いる。

【4】「APIデザインの極意」では、外部公開されるAPIのプログラミングに力点を置いて、そのノウハウが書かれているらしい。
内容を推測すると、ブラックボックス再利用の観点と思われるが、ホワイトボックス再利用の観点でも役立つだろう。

APIで思いつく例としては、SOAやWebサービスが思いつく。
よくある例は、クレジット会社が提供するクレジットカード支払いサービスがあるだろう。
カード支払いサービスのAPIを使えば、ECサイトの支払方法でカード支払いのロジックを作りこむ必要がなくなる。
特に、カード支払いサービスの利用事例が多いほど、パフォーマンスや品質も枯れていると推測できるから、下手に自分たちで作りこんで本番障害を発生させるよりも楽だ。
最近は、カード情報のような個人情報を自社で資産として持つ危険性の方が高いので、外部サービスを使った方がリスクが減るメリットもある。

アジャイルAPI設計時代の到来!?APIデザインの極意を読みました。 - シスアーキ in はてなを読んで、僕が、なるほどと思った点は以下の通り。

・APIの後方互換性の担保が重要。
 APIを長持ちさせるには、ソース互換性、バイナリ互換性、特に機能互換性が重要。

・APIが後方互換性を維持しながら健全に発展できる為の具体的な手法の一つとして「不変型を指定するためにJavaインタフェースを使用する」「メソッドを安全に追加できる型としてfinalクラスを使用する」

・Decoratorパターンは問題になりやすい。
 APIは使用者向けと提供者(サービスプロバイダー)向けに分けて提供する。

・テストをサポートするテストAPI、テスト互換性キットは、仕様書の代わりになる。
 APIの後方互換性の維持のために非常に役立つ。

・今後APIはより、宣言型プログラミングや関数型プログラミングに向いて進化する

APIに関する実際のノウハウが公開されているのは興味深い。

| | コメント (0)

2014/08/08

リーンスタートアップはバックワードループで始めよ

牛尾さんによる Kent Beck がリーンスタートアップイベントで語った講演のディクテーションが素晴らしかったのでメモ。

【元ネタ】
Twitter / akipii: これは素晴らしい記事。RT @hiranabe: この記事見逃していた! Kent Beck がリーンスタートアップイベントで語ったのの牛尾さんによるディクテーション。 http://qiita.com/TsuyoshiUshio@github/items/28f4c127c911170cad49 …

Startupプログラマの為の新アジャイルマニュフェスト(Kent Beck: beyond agile programming) - Qiita


Build→Measure→Learnではない。
スタートアップでは、顧客を創造すること、マーケットを決めることが大事。

プログラマはどうしても自分が好きなものから始める。
スタートアップでは、それだけでは足りない。

Learn→Measure→Buildで進める。

(引用開始)
「学習」の次は、「測定」です。私は「ミス」と「成功」を測定します。そして次にコードを書く事です。
 仮説があっているかを確認するために、測定して、そのために、コードを書くのです。
(引用終了)

では、どうやって学習を検証する?

(引用開始)
スタートアップは、ほとんど不可能なことのリストで始まるのです。
これは、「検証しないと致命的になる仮定」と呼ばれます。つまり、その仮定が覆ると、そのビジネス自体が成り立たなくなるのです。例えば誰かがお金をはらってくれるかとか、顧客を獲得できるのかとか。
(引用終了)

ありえないような前提、仮定を置いたのに、お金を払ってくれる人が見つかれば、そこに顧客が存在する。

(引用開始)
だから、私にとっては、アジャイル開発を越えて、スタートアップは、チームビジョンをもって、規律をもって、全体を最適化しないといけない。

プロセスやツールは、人のアウトプットを最大化しない。ソフトウェアを作る事よりも、学習することにフォーカスをあてよう。
そして、ニーズからはじめて逆のループをまわそう。顧客を見つけるのだ。
そして、変化を単に待つんじゃなくて、自ら変化を起こすのだ。
(引用終了)

ソフトウェアは一つの手段。
自ら変化を起こす。

では、顧客を見つけた後、どう進める?

(引用開始)
もし、ゲームがヒットしたらどうなるだろう、スケールしてしまったら。あなたは、そのサイクルから、モードを変える必要がある。あなたがやるべき事は、顧客を魅了できるかどうか確かめることでは無くなっているからだ。

今や、あなたが学習するべき事は、どうやったら顧客を倍にできるかだ。

テスト駆動開発や、自動化、リファクタリング、レスポンシブデザイン、そして、スタッフの仕事を妨げる事無く、平行で変更できるようにするようになることだ。

そして、今のお金の流れから、どうやったらより多くのお金を獲得できるかを学習するのだ。
(引用終了)

でも、一つ落とし穴がある。

(引用開始)
もし、あなたが顧客を獲得してスケールしたとき、最高のエンジニアリング戦略は、機能を削減することです。
これらの、考え方の移行は本当に難しい。なぜならこれらは、技術の問題ではなくて、文化の問題だからです。
(引用終了)

これは、XPの計画ゲームでも言われていたことだ。
機能を追加するだけでなく、機能を削減することも一つの要求なのだ。

| | コメント (0)

2014/08/04

Redmineチケットの担当者を固定にする手法はWBS駆動に凝り固まり過ぎ

RedmineとWBS駆動の相性の悪さについて、一つの意見を聞いたのでメモ。

【参考】
チケット駆動開発がWF型開発と相性が悪い理由: プログラマの思索

EVMとバーンダウンチャートは本質的に違う: プログラマの思索

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

イテレーションの考え方は締め処理と同じ: プログラマの思索

何故チケット駆動開発はタスクやイテレーションの変更に強いのか?: プログラマの思索

【1】とある人から、RedmineとWBS駆動の相性の悪さの意見を聞いた。
その人曰く。

Redmineでは、チケットの担当者がどんどん変わっていくように運用すべきなのに、WF型開発に凝り固まっている人は、チケットの担当者を固定して作業を管理しようとする。
だから、プロジェクト管理をチケット管理に置き換えても、なかなか効果が出ない、と。

この意見は一つの真実を示していると思う。

チケット駆動開発では、チケットはペアプログラミングまたはペア作業のように、複数人でキャッチボールしながら、ステータスを変更してCloseしていく。
例えば、ソースコードを書いたらレビューアにコードレビューしてもらったり、設計書を書いたらレビューアに設計レビューして、フィードバックをもらって修正する。
バグを発見したら、開発者に修正してもらい、修正内容を再検証して、リリース担当者に最終リリースしてもらう。

つまり、一つのチケットは、一つの目的を達成するためのやり取りを記録する。

【2】しかし、WF型開発ないしWBS駆動で凝り固まっているプロジェクトリーダーは、一つの作業は一人の担当者に固定して、実績工数と進捗率を管理しようとする。

例えば、「カード払いにする」機能の追加依頼が来た時、設計・設計レビュー・実装・コードレビュー・単体テスト・テスト結果レビュー・リリースのように、工程ごとにタスクを細分化し、それぞれのタスクを一人の担当者に固定する。
このような作業管理はExcelやMSProjectを使いこなしている人に多い。

実際のExcelを見ると、縦軸に機能、横軸に工程(設計・設計レビュー・実装・コードレビュー・単体テスト・テスト結果レビュー・リリース)毎の予定日・作業日・担当者名、というクロス集計のような膨大な表で表現される時が多い。

【3】このような「1タスク=1担当者」に固定する作業管理は、実績工数や進捗率を計測しやすいかもしれないが、実際の作業はとてもやりにくい。

他の作業が遅延すれば、担当者を入れ替えする必要もあるし、開始日や終了日もコロコロ変える場合が多い。
すると、毎日の担当タスクは流動的になり、どのタスクを最優先にしたらよいのか、ExcelやMSProjectでは分かりづらい。
プロマネも、Excelから最優先にすべきタスクを見つけ出すのは、かなりの手間だ。

しかも、ユーザ観点では、開発チームの誰がどんなタスクをしたのか、という過程は興味がなく、肝心の依頼した機能がいつリリースされるのか、後どれくらいの期間で終わるのか、が知りたいだけ。
だから、そんな細かな作業管理の詳細スケジュールは見たくもない。

「1タスク=1担当者」に固定する作業管理は、担当者やユーザのためではなく、プロマネ自身が管理しやすくするための一つのやり方に過ぎない。

【4】「1タスク=1担当者」に固定する作業管理にしてしまう問題は、チケットの粒度はどのレベルにすべきか、という問題に置き換えられる。

Redmineチケットの担当者を固定にする手法では、工程ごとにチケットを分割するので、チケットの粒度はあまりにも細かい。
おそらくそのやり方は、アジャイル開発に向かない。
アジャイル開発では、作業を工程で分断するのではなく、一つの機能を一つの塊の作業とみなして、並行作業する。

実際の開発は、設計書を書いてレビューを受けると、アーキテクチャをきちんと考えおらず、全然ダメで大幅に書き直す場合もある。
プログラミングしてコードレビューを受けると、ボロクソに言われ、確かに読みにくいコードなので大幅に直さざるを得ない時がある。
そのような手戻り作業は、ガントチャートでは管理しにくい。

ガントチャートに手戻り作業を追加すると、先行・後続のタスクの依存関係が崩れる。
また、担当者の作業負荷を正確に反映すると、山崩しが必要となり、ガントチャートを大幅に修正せざるを得なくなる。

かと言って、手戻り作業の実績をガントチャートに反映しなければ、進捗&工数管理できないから、前工程に戻るような状態に反映しないといけない。
すると、いつまで経ってもガントチャート上では進捗が進んでいないように見えてしまう。

【5】チケット駆動開発が教えるには、チケットはタスクというよりも、一つの目的に従った作業にすべきであり、担当者を頻繁に変えながら、チケットに紐づく成果物をブラッシュアップすべきだ、という点だ。

設計書やソースコードという成果物は、仕様変更や機能追加などの要望、課題や問合せ対応、障害修正などの数多くのチケットで更新されながら、顧客の要望に見合う方向に収れんされていく。

一つのチケットに開発者、テスター、設計者、プロジェクトリーダー、顧客などシステムに関わる全員が担当して、解決されていくのがあるべき姿。
一つのチケットを一人でやりきるよりも、複数人で交互に担当し合う方が、二人の目による成果物の品質チェックで品質向上も期待できる。

つまり、「チケットの担当者を固定する」手法よりも「ペア作業」の方がチケット管理に向いている。

【6】さらに重要な点は、ペア作業によるチケット管理の背後には「ワークフロー」という概念が隠れていることだ。
すなわち、ペア作業はワークフロー管理機能によって、ステータスごとに誰が担当すべきか、という制御がツール上で実現されている点だ。
作業の種類(トラッカー)ごとに、どんなステータスがあり、どのようにステータスが遷移されるのか、という制御はあらかじめ決まっており、チームのメンバーはそれに従って作業するだけでいい。

「チケットの担当者を固定する」手法は、プロジェクト管理にワークフローという機能が必要である事実があいまいで、そのために進捗が遅れてしまいがちになるのではないかと思う。
つまり、「チケットの完了条件」があいまいなのだ。

実際、「機能Aの設計書が完成した」「機能Bのプログラムが完成した」という状態は、単なる作業が完了しただけではなく、レビューやテスト、プロマネの承認が完了して初めて、「終わった」と言うべきだ。
そして、それらの作業は、ステータスで制御すべきであり、その機能はワークフローとしてチケット管理ツールで実現されている。

ワークフローを明確に意識していれば、どのステータスで、どの担当者がボトルネックになっているのか、をチケット集計機能で即座に分析できる。
そうすれば、すぐに対策を打つこともできるだろう。

チケット管理にはたくさんのノウハウが込められていると思っている。

| | コメント (0)

2014/08/03

「朝の3分モデリング講座」の温水洗浄便座 セサレットの状態マシン図

「朝の3分モデリング講座」の温水洗浄便座 セサレットの状態マシン図を書いてみた。

朝の3分モデリング講座 - 例で理解するUML状態マシン図 - YouTube

温水洗浄便座 セサレットの状態マシン図の特徴:
(1)着座センサーとフラッシュセンサー(便器洗浄)は並列処理で動作する。
(2)便器に座ると、着座センサーONになる。
便器から立つと、着座センサーOFFになる。

(3)着座センサーONでおしりボタンを押すと、おしり洗浄中になる。
(4)おしり洗浄中に、停止ボタンを押すと洗浄が終わる。おしり洗浄中は60秒を過ぎると、自動的に終了する。

「おしり洗浄中」ステータスの意味:
(1)停止ボタンもタイマーも、おしり洗浄停止処理(exit)を実行後に動作する。
(2)おしり洗浄開始処理が始まってから「おしり洗浄中」状態に移る。

温水洗浄便座はどこの家にもあるから、誰でも描けそうだが、意外と複雑。
下記にさらに問題が追加されていた。

パズルっぽくて、考えると面白そう。

状態マシン図セミナー2014年2月 事前宿題

(引用開始)
【問題1】
このセサレットに、【ビデボタン】と、【乾燥ボタン】を追加してください。
状態マシン図に追加して設計してください。

要求:「おしり洗浄中」に【乾燥ボタン】を押すと、おしり洗浄が止まって乾燥を開始してください。
(そのほかも同様にしてください。おしり洗浄とビデ洗浄と乾燥はどれか1つしかできません。)

【問題2】
問題1を解いたセサレットに、【流すボタン】を追加してください。

要求:着座しているときも、着座していないときも、流せるようにしてください。
また、流し始めると、途中で止める方法はありません。

【問題3】
問題2を解いたセサレットに、
おしり洗浄のムーブ機能、
ビデ洗浄のムーブ機能
を追加してください。

要求:おしり洗浄は、【ムーブOFF】と【ムーブON】の状態があり、【おしりボタン】を押すたびに交互に変えてください。
このときも、おしり洗浄は、開始してから60秒あとに必ず止めてください。
ビデ洗浄も同様に処理してください。

【問題4】
問題3を解いたセサレットを仕様変更して、【流す小ボタン】、【流す大ボタン】にしてください。さらに、
着座してから、60秒以内に起立すると、流す小が、
着座してから、60秒あと以上に起立すると、流す大が
自動的に起きるように追加してください。
さらに、着座中に、一度でも【おしりボタン】が押されれば、流す大が
自動的に起きるようにしてください。
(引用終了)

個人的には、UMLのダイアグラムの中で、状態マシン図が重要だと思っている。
プログラミングやソフトウェアテストで最も使えるからだ。
実際、状態マシン図が書ければ、そこからプログラムに落とせるし、テストケースの仕様にもなる。

たぶん、DSLのように、プログラムの自動生成のための元ネタとなるモデルそのものにもなるはず。
実際、形式手法の一つであるモデル検査のSPINも、状態マシン図をプログラムからリバースして作成し、状態遷移をしらみつぶしに実行して、仕様の不備を見つける手法を採用している。

著者の方のBlogには、astahで描かれた状態マシン図の書き方について詳細に書かれているので、後でじっくり読む。

島ぶくろ 状態マシン図

| | コメント (0)

2014/08/02

「リーン開発の現場」の感想part6~累積フロー図は生産管理の流動曲線管理または追番管理である

生産管理の記事を読んで、「リーン開発の現場」に出てくる累積フロー図は生産管理の流動曲線管理または追番管理であることに気づいた。
考えたことをラフなメモ書き。

【元ネタ】
目次 - 生産管理パッケージ導入の留意点 本間峰一:ITpro Active

リーン ソフトウェア開発~プラクティス 累積フロー ダイアグラム

第3回 何のために生産管理システムを構築するのか - 生産管理パッケージ導入の留意点:ITpro Active

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

「リーン開発の現場」の感想part5~かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

「リーン開発の現場」の感想part4~トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

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

「リーン開発の現場」はアジャイルサムライの再来となるかpart2~重要な概念は仕掛り(WIP)とサイクルタイム: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

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

第33回関西IT勉強会の感想~製造業の基幹システムのパターンが知りたい: プログラマの思索

【1】「受注生産に徹すれば利益はついてくる」の本にも出てくる流動曲線管理または追番管理とは、工場で使われるかんばんにおいて、各工程の製造個数を時系列に集計したグラフ「累積フロー図」で在庫管理や進捗管理を行う手法。
追番管理は、戦前の中島飛行機が発祥と言われているらしい。

【1-1】流動曲線管理の特徴は、工程間の製造スピードの差、製造個数の差、滞留在庫の差、投入から完了までのリードタイムを簡単に計算して把握できること。
単純に時系列にステータス(未着手、仕掛中、完了)ごとに集計しているだけだから、単なる引き算で計算できる。
基本は、グラフの縦が仕掛かり在庫、グラフの横がリードタイム、傾きが生産能力に対応する。

つまり、グラフの横の間隔が広いほど、リードタイムが長くなり、納期が遅れる。
グラフの縦の間隔が大きいほど、倉庫に在庫がたまり、どこかでボトルネックが発生しているわけだ。

【1-2】「受注生産に徹すれば利益はついてくる」の本で、流動曲線管理または追番管理を推奨する理由は二つある。

一つ目は、生産管理システムの実績データを流用するだけで、累積フロー図を簡単に実装できること。
日次バッチで当日の実績データが確定すれば、その実績データをステータスごとに集計するだけで累積フロー図を簡単に作れる。
ERPの枠外にバッチ処理を1本追加するだけで作れるから、MRPやERPをカスタマイズして作る必要もない。

二つ目は、累積フロー図による流動曲線管理がMRPの弱点を補ってくれること。
MRPの弱点は、生産計画におけるリードタイムや納期があいまいな状況に弱い。
ちょうど、計画重視のWF型開発が仕様変更や突発的な変更要求に弱い状況と同じだ。

しかし、流動曲線管理で、工程間の製造スピードの差、仕掛品在庫の量を簡単に把握できるため、どこでボトルネックが発生して遅延が発生したのか、を調査することができる。
例えば、工場の製造工程において、第1工程と第2工程の差を累積フロー図で見れば、どこで差分が時系列に大きくなっているのか、は見るだけですぐに原因を特定できる。
そこから、対策を打てばよい。

つまり、MRPで部品の所要量展開を行って、必要な部品の個数とリードタイムを大まかに把握し、流動曲線管理で日々の製造実績からボトルネックを監視・追跡するように進捗管理すればいい。

【1-3】流動曲線管理は、例えば、大量生産の食品工場、クリーニング工場のように季節変動が激しい工場の納期管理に向いている、とのこと。
すなわち、需要変動が激しく、生産計画を事前に決定するのが難しい製造業で有効である、という指摘なのだろう。

では、この発想をソフトウェア開発にどのように生かせばよいのか?

【2】『リーン開発の現場』第12章に累積フロー図 (P.90)という概念が出てくる。
【2-1】累積フロー図とは、かんばん上にあるカード(ストーリーカードまたはタスクカード)をステータス(ToDo、Doing、Doneまたは、バックログ~受入完了)ごとに時系列に集計したグラフ。

累積フロー図の目的は、どのステータスのカードがたまり過ぎてボトルネックになっているか、を見える化するツールだ。

(引用開始)
累積フロー ダイアグラムは、ワークフローの各状態にある累積作業項目の面グラフをプロットします。 これは豊富な情報を含み、プロセス内のステップの平均サイクル タイムとスループット率 ("ベロシティ") を調べるために使用できます。 累積フロー ダイアグラムに表示される視覚的特徴は、ソフトウェア開発ライフサイクル プロセスによって異なります。 作業者は、面グラフに表示されたプロセスの機能不全のパターンを見分ける方法を習得できます。 真のリーン プロセスでは、安定したペースでなだらかに上昇する、均等に分布した色の領域が表示されます。 図は、のこぎり状になったステップや一見してわかる色の塊がなく、滑らかに見えます。

最も基本的な形式の累積フロー ダイアグラムは、作業項目ライフサイクルの特定のステップにある仕掛品の量を視覚化するために使用されます。 また、ボトルネックを検出し、"ムラ" (フローのばらつき) の影響を監視するためにも使用できます。
(引用終了)

【2-2】しかし、「リーン開発の現場」では、実際の開発現場ではあまり有効ではなかった、と書いていた。

グラフに増減があったとしても、その原因は、カードを数える基準を変えたり、ボードのレイアウトを変えたりしたことが多いから。
つまり、人為的に計測基準を変えてしまったために、累積フロー図の傾きの増減の原因分析に有効でなかった、と言っている。

【3】なぜ、製造業の進捗管理では有効である「流動曲線管理(追番管理)」に出てくる「累積フロー図」は、リーンソフトウェア開発では有効でなかったのか?

その理由は、製造業では明確に工程を識別できるのに、リーンソフトウェア開発では工程という概念が明確でないために、累積フロー図の見せ方がマッチしていないのが原因にあると思う。

アジャイル開発では、WF型開発のように、要件定義→設計→プログラミング→テスト→リリースのような工程別の作業が「機能単位」にすべて一体化されている。
機能ごとのカードをステータスごとに時系列に集計しているから、どのステータスがボトルネックにあるのか、は分かるが、根本原因を累積フロー図から見つけ出すのは難しいだろう。

たとえば、累積フロー図を見て、設計工程のレビューに時間がかかっているのがボトルネックだ、単体テストのやり直しが発生して単体テストのリードタイムが長くなっているのがボトルネックだ、というような現象を見出しにくい。

だからと言って、リーンソフトウェア開発で累積フロー図が使えない、という結論は早急すぎる。
本来は、累積フロー図から、リードタイムや仕掛かり在庫の差を時系列に比較して、その傾向を分析したいのだ。

おそらく、累積フロー図の作り方、つまり、何を集計して累積フロー図を作成すべきか、という点に問題があるのではないか?
つまり、集計する単位が間違っているのではないか?

この辺りはもっと試行錯誤しながら考えるしかないだろうと思う。

【4】そんなことを思いつきながら書いてみると、疑問に思うことがある。

トヨタが生み出した「リーン」「かんばん」、中島飛行機が生み出した「追番管理」「累積フロー図」という概念のように、日本人は製造業の進捗管理で優れた概念を生み出したのに、なぜ、ソフトウェア開発にそれらの概念を適用して、アジャイル開発を生み出せなかったのか?

この辺りも色々探ってみたい。


| | コメント (0)

2014/08/01

UML再考

UMLベースの開発手法を整理するためのメモ。

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

【1】要求定義フェーズ:

a)目的:利用者の要求や現行の業務から、システムの要求を定義し、システムの全体像を描く。

b)利用例:
①ユースケース図:利用者やシステムであるアクターと機能要求を表すユースケースから成る。
開発対象の機能要求の範囲が明確になる利点がある。

<感想・留意点・課題>
1)ユースケース≠機能。ユースケースは、アクターに対する価値あるサービス。

2)ユースケースを機能分割するのは良くないと言われる。
理由は、ユースケースがどんどん詳細化されて収拾がつかなくなるから。

しかし、機能分割しないユースケースは粒度が大きすぎて、ユースケース図を書く意味が薄れる。
ユースケース記述書を書く場合、類似した内容は、Includeしたユースケースで記述したくなる。
Includeされるユースケースを洗い出しておけば、再利用できるから、ユースケースを記述する量が減るからだ。
だから、どうしてもユースケースは機能分割したくなる。

ユースケース図のあるべき姿は何なのか?

ユースケースを記述する粒度 - Ken's Blog

3)astahでは、ユースケースをどのように利用すればよいか?

astahでは、マインドマップで、アクターやユースケースを洗い出しておけば、右クリックで生成できる。
つまり、マインドマップでラフなスケッチとしてアクターやユースケースを書き出すと、すごく楽。

ユースケースが使える場面は、SysMLの要求図、CRUD表、ロバストネス図。

3-1)要求図では、要求(Request)を実現する(satisfy)対象としてユースケースを対応づけることができる。
つまり、ユースケースの発端となる顧客の要求の関連を示すことができる。
この方法を徹底できれば、顧客の要求→ユースケース(実現すべき機能・サービス)→クラス(実装対象)へ後方追跡できるだけでなく、逆方向から前方追跡できるようになる。

設計工程でトレーサビリティを実現できれば、仕様変更や障害修正で変更すべき要求から、影響を受けるユースケースやクラスを調査でき、実装漏れを減らせる。
また、影響対象の機能の規模が分かれば、工数を見積もれるので、コストの予測の精度も上がる。

astah 6.1 で「要求モデル」が目指している姿:An Agile Way:ITmedia オルタナティブ・ブログ

3-2)CRUD表は、ユースケース(機能・プロセス)とクラス(クラス図)・テーブル(ER図)に関するCRUD表。
画面Aの機能Bでは、どのクラスまたはどのテーブルを参照し、更新し、登録・削除されるか、を示す。
CRUD表の利点は、詳細設計書やテストケース、テストデータの元ネタになること。

画面Aの機能Bの詳細設計書では、CRUD表を見ながら、対象テーブルの参照・更新の処理をトランザクション処理の観点で書けばいい。
画面Aの機能Bのテストケースでは、参照されたテーブルのデータが画面に反映されているか、更新対象のテーブルに想定通りの入力データが入っているか、を確認するケースを書けばいい。
そのために必要なテストデータを洗い出しやすくなる。

ユースケースが効果的な場面はおそらく、CRUD表として用いる時ではないかと個人的に思っている。
データモデリングの設計経験がある人がCRUD表を見れば、どんな機能であるか、その機能の画面の入力項目はどんなレイアウトか、その機能の開発規模はどれくらいか、を想像できるだろう。

Railsのようなフルスタックフレームワークを知っていれば、テーブル設計さえできれば、scafoldでWeb画面は一瞬で自動生成できる。
しかも、テーブルのレイアウトと画面の入力項目は強い依存関係があるから、テーブルレイアウトから画面のユーザインターフェイスを想像できる。
実際、外部キーがあれば、ポップアップの検索画面が欲しくなるし、複合キーがあれば、ヘッダ部分は検索条件、リスト部分は明細データのようなレイアウトに強制されるから。

渡辺幸三さんの本「業務システムモデリング練習帳」を読めば、テーブルレイアウトと画面のユーザインターフェイスの関係性に法則があるのがよく分かる。

3-3)ICONIXプロセスでは、ユースケースをオブジェクトの絵として表現する時、ユースケース記述の内容をロバストネス図で表す。
ロバストネス図は、論理的なDFDと見なせる。
ロバストネス図に出てくるバウンダリ、エンティティはクラス、コントローラはクラスのメソッドに対応付けられる。

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

ロバストネス図は手書きが一番書きやすい。
また、ロバストネス図はDFDの代わりに書きやすい。
Webの画面設計だけでなく、バッチ処理に出てくるジョブフロー図の代わりにも書けるから便利。

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

②アクティビティ図:利用者の業務や現行システムの機能を手続き的流れで表した図である。
主に利用者の業務フローを可視化し、機能要求を抽出するために使われる。

<感想・留意点・課題>
1)「業務システム」を「コンピュータ上で動く情報システム」だけでなく、「ユーザが関わる手運用の業務」も含めるものとして見なす時に、有効。
ITコンサルとしてシステム提案する時、システムの機能だけでなく、どの利用者がどのようにシステムを使い、実際の業務を行うのか、をイメージする時に使う。

業務システムを導入するのは、業務のコスト削減が目的なので、アクティビティ図からその箇所を明示できると良い。
たとえば、手運用のプロセスが減る、とか、関わる人数が減る、とか、リードタイムが短くなる、とか。

2)アクティビティ図では、ステータスよりも処理やプロセスを記述する。
その時、処理の目的が分かるように明記する方が良い。
つまり、アクティビティの粒度は荒く、システムへの実装はあまり意識しない。
その方が、システムの仕様変更があっても、アクティビティ図への影響が小さくなるから。

3)アクティビティ図は、レーンを使った場合とレーンを使わない場合の2種類を意識して使い分ける。

3-1)レーンを使う場合、アクターに組織またはロールを当てはめる。物理的な業務モデル。
プロセスの流れが同じでも、どのアクターに配置するか、で業務の意味が変わってくる。

アクターに配置されたアクティビティ(プロセス・業務)が多いほど、その役割に期待される責任の量は大きい。
下手をすると作業負荷が集中しやすくなる。
役割分担を再配置することは、組織構造の変更に最終的につながる。

3-2)レーンを使わない場合は、論理的な業務のモデル。
組織や役割を当てはめる前のモデル。
「機能関連図」と呼ばれるモデルに相当する。
組織や役割は機能ではなく、機能の一部として書く。

4)アクターにシステムが出る場合、システムのレーンのアクティビティはユースケースに対応づけられる。
だから、ユースケース図は、アクティビティ図で書かれた業務の流れの順にユースケースを縦に並べて上から下へ並べると分かりやすくなる。

【2】システム分析フェーズ:

a)目的:ユースケースから利用者と設計者が相互理解できる概念モデルを作成する。

b)利用例:
①クラス図(概念モデル):問題領域の概念を表すクラスとその関連をまとめた図である。
但し、分析フェーズで使われるクラス図はそのまま実装されるのではなく、システムの機能要件や制約を分析するために使われる。

<感想・留意点・課題>
1)ドメイン駆動設計で使われる最も重要な成果物。
ユビキタス言語がクラスで表現される。

概念モデルのクラス図の設計は、ER図のモデリングと同じ。
どんな情報を蓄積したのか?
その情報をどのように加工したいのか?

2)クラスの抽出元は、ユースケース記述に出てくる名詞。
しかし、実際はそれ以外の概念もクラスに出てくる。

イベントはクラスで抽出しやすい。
イベントを時系列に並べると業務フローになる。

クラス図で表現しにくいのは連関エンティティ。
リソース同士の関連(A◇--C--◇B の絵)をどう表現するか?

ER図ならば、テーブルCに外部キーが2個ある場合と、テーブルCに複合キーがある場合(連関エンティティ)は厳密に区別される。
しかし、クラス図では両方とも同じ表記になってしまい、混同されがち。

あえて連関エンティティを表現したいなら、「A◆--C--◆B」の絵で表現するか?

3)astahでは、ステレオタイプごとにクラスを色付けすると、絵として読みやすくなる。
ER図と同じく「リソース(マスタ)」「イベント(トランザクション)」「サマリ」の3種類で色付けしてもいい。

②オブジェクト図:クラスのインスタンス同士の関係を示した図である。主にクラス間の関連や多重度を検証するために使われる。

<感想・留意点・課題>
1)オブジェクト指向設計を十分に理解しているかどうかは、オブジェクト図の使い方で分かる。
実際のインスタンスがどのように関連付けられるのか、を理解できていないと、オブジェクト図は書けない。
オブジェクト図が書けるならば、多重度やクラス間の関連の意味を説明できるだろう。

2)クラス図を書く前にオブジェクト図を書くと理解が早まる。
astahでは、クラス図上でオブジェクト図が書ける。

【3】システム設計フェーズ:

a)目的:概念モデルを元に論理的な設計モデルを構築する。

b)利用例:
①クラス図:概念モデルのクラス図をより具体的に詳細化する。

<感想・留意点・課題>
1)astahでは、テキストファイルにクラス名の一覧を洗い出しておき、クラス名の一覧をコピー&ペーストすると、クラスを自動生成できる。

2)クラスに「Actor」のステレオタイプを付けると、ユースケースのアクターにもなる。

②シーケンス図:クラス間の動的な相互作用を表す。

<感想・留意点・課題>
1)シーケンス図は詳細設計書と同じ。
プログラムの記述はシーケンス図で表現できる。

詳細設計書→プログラムのフォワードエンジニアリングよりも、現行システム→詳細設計の抽出というリバースエンジニアリングで、シーケンス図が役立つ時が多いと思う。
プログラムの流れを大量の日本語で読むよりも、絵で読み取る方が概要はつかみやすい。

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

2)astahでは、クラスをドラッグ&ドロップすれば、ライフラインが表示される。
クラスのメソッドを選択すれば、メッセージを表現できる。

③ステートマシン図:あるクラスの状態の変化に着目し、生成から消滅までのライフサイクルを表す。

<感想・留意点・課題>
1)一つのクラス、オブジェクトのライフサイクルを状態の変化で表す。
ステートマシン図は、プログラム設計だけでなく、業務モデルの設計にも使える。

会員クラスの状態遷移図も書けるし、画面遷移図をステートマシン図と見なしてももいい。
ワークフローシステムで、一つの申請書に申請者→上長→経理部のようなハンコの押印を状態とみなしてもいい。

2)ステートマシン図は、組み込み設計ではすごく重要。
センサー、監視モニタなどの操作をステートマシン図で表現できれば、詳細設計書に落とせるし、テストケースにもなりえる。
絵で描ければ、大量の日本語の仕様では気づかなかった、処理の漏れも見つけやすくなる。
例えば、この状態から別の状態へ移る遷移はあるはずなのに、設計書に漏れていた、とか。

3)ステートマシン図とアクティビティ図、シーケンス図は1対1に対応する。
アクティビティ図のアクティビティやシーケンス図のメッセージは、ステートマシン図のアクティビティに相当する。
ステートマシン図の状態は、アクティビティ間の矢印、シーケンス図の活性区間に相当する。

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

だから、アクティビティ図やシーケンス図を書いた時に、ステートマシン図も一緒に書くと、仕様の網羅性が高まるはず。

4)ステートマシン図は、プログラムの自動生成に必須の情報がすべて含まれている。
おそらく、DSLもステートマシン図で表現できるだろうと思う。
形式手法におけるSPINも、システムからある範囲の状態遷移図をリバースエンジニアリングで復元し、そこからしらみ潰しに状態遷移を計算してバグを見つけ出そうとする。

モデルから動くプログラムを自動生成したい場合、ステートマシン図は必須だ。

④コミュニケーション図:クラス間の相互作用を責務の観点から表現する。

⑤パッケージ図:クラスをパッケージにまとめてレイヤ化する。

<感想・留意点・課題>
1)パッケージ図はあくまでも、クラスやユースケースなどを整理するための論理的枠組み。

2)凝集度や結合度、レイヤー設計で使う。

【4】実装フェーズ:

a)目的:設計フェーズの成果物を物理的なコンポーネントや物理的資源(例:サーバー)へ対応付けて配置する。

b)利用例:
①コンポーネント図:クラスやパッケージ等をコンポーネントとして部品化した図である。
大規模プロジェクトでシステムを俯瞰する際に有用である。

<感想・留意点・課題>
1)コンポーネントは、パッケージとは違う。
コンポーネントは、メッセージを送信できる部品。
パッケージはあくまでも分類しただけ。

コンポーネントの例は、WindowsのEXE、DLLなどのように、実行可能な物理ファイルや呼び出し可能な物理ファイル。
Javaならwar, ear, jar, classなど。

2)コンポーネント図の使い道はよく分からない。
使える場面が極端に少ない気がする。

コンポーネントの中身を表現しようとしても、10個ぐらいのコンポーネントではそもそも頑張って描いてもあまり意味がない。

The Rational Edge:UML 2.0のキホン:コンポーネント図の詳細解説 - ITmedia エンタープライズ

The Rational Edge (22):サブシステムの「なに?」「なぜ?」「どうやって?」(前編) - ITmedia エンタープライズ

②配置図:コンポーネントと物理的資源の関係を表した図である。
ハードウェアやコンポーネントの依存関係を可視化するのに役立つ。

<感想・留意点・課題>
1)配置図は、ルータやファイアウォールなどのネットワーク図の代わりに使える。
また、リリースされる物理ファイルの配置イメージにも使える。

配置図から非機能用件を類推する: プログラマの思索

2)配置図は、クラス図のような概念モデルと、オブジェクト図のようなインスタンスモデルの2種類がある。
実際に使えるのは、オブジェクト図のように、ノードのインスタンスで物理的ファイルを表現して、その関連を描く場合。

例えば、バッチ処理のファイルを配置する場合、そのファイルがどこに配置されるか、他のファイルとどのように関連するかを記述できる。
開発環境と本番環境の違いも的確に表現できる。

配置図は必須 - ビープラウド社長のブログ

また、ノードのインスタンスをサーバーに対応付けて、IPアドレスを振れば、ネットワーク図と同等になる。
ExcelやVisioで書かれたネットワーク図はアイコンで表現する時が多いが、ほぼ同じ。

ゼロから始めるUMLモデリング講座 (12) 配置図の作成 | マイナビニュース

| | コメント (0)

« 2014年7月 | トップページ | 2014年9月 »