2018/01/18

AstahのRedmine連携プラグインが公開されました

AstahのRedmine連携プラグインが公開されました。
とても使いやすいので気に入っている。
ラフなメモ書き。

【参考】
Redmine連携プラグイン | Astah

ChangeVision/astah-redmine-plugin: Associating Redmine tickets to a diagram

【1】astahを使いながら、モデリングという作業に、変更管理や構成管理の概念が反映されていない点にずっと違和感があった。
その問題意識は下記に書いた。

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

描いたモデルは、一度書いたらそれで終わりということはない。
頻繁な仕様変更、洗練された設計思想へ反映などの作業で、モデルはどんどん変化する。

また、モデリング作業を行っていくと、数多くのモデル間の整合性を考慮していくうちに、モデルが変化する。
さらに、モデルの粒度を考えながら、モデルをリファクタリングすることもあるだろう。

つまり、モデル間の粒度やトレーサビリティを考慮すると、モデルの変更履歴をどこかで保持したくなる。

しかし、astahにせよ、EnterpriseArchitectやRationalRoseにせよ、モデルのファイルはバイナリのため、Gitで履歴管理してもあまり有り難みがない。
また、モデルの変更箇所をノートや吹き出しで追加していくうちに、モデルが醜くなってしまう。

【2】では、上記の問題点はどうやって解決できるか?

根本的な解決方法ではないが、モデルの変更履歴はRedmineチケットへ外出しすることで、モデルの変更管理や構成管理の問題点はある程度解決できるはず、と僕は考えている。

つまり、モデルの変更履歴のように、モデルのある時点のスナップショットとなる履歴情報は、Redmineチケットで管理すべき、と考える。
そうすれば、モデルは常に最新の仕様を反映した状態で保持すれば良い。
モデルが色んな事情で変更された経緯は、Redmineチケットの内容で確認すればいい。

たとえば、Excel設計書に必ず付属する変更履歴シート、昔のJavaのJavaDocにあった@historyのようなソース変更履歴コメントは、そもそもRedmineで一括管理すべき情報だから。

【3】上記のRedmine連携プラグインでは、下記の機能を持つ。

1)astahのモデル(実際はUMLダイアグラム等)の単位で、Redmineチケットを登録・参照できる
 仕組みとしては、RedmineのREST APIを使う。

2)astahのモデルとRedmineプロジェクトは1対1に対応付けられ、Redmineチケット一覧が表示される。
 astahで表示されたRedmineチケット一覧では、ステータスや優先度などのチケット項目でソートできる。

3)astahの全モデルのRedmineチケット一覧も表示できる。

4)但し、astahにはRedmineチケットの基本的情報を表示するだけであり、詳細な情報はRedmine上で編集する運用になる。
 Redmine上で編集した情報をastahへ同期する場合、「Sync」ボタンを押せばよい。

【3-1】Redmine連携プラグインによって、astahモデルから、モデルの変更履歴の吹き出しの情報は全てRedmineチケットへ外出しされる。
Redmineに蓄積されたモデル変更のチケット情報は、Redmineの優れたチケット集計機能でいくらでも分析できる。

たとえば、モデルのレビュー記録チケットから、レビューの効果やモデルの品質を計測してもいい。
また、モデルのアーキテクチャや要望が未決定のため保留となっている箇所は、課題チケットに外出して、未解決リストとして扱ってもいい。
あるいは、Redmineチケットはタスクと見なせるから、将来のモデル修正のToDoリストとして使ってもいい。

すなわち、astahのモデルに付属するRedmineチケットのビューは、「モデルの変更履歴」だけでなく「モデル修正のToDoリスト」だったり、「モデルの未解決の課題リスト」として扱うこともできる。

【3-2】そういう複数の観点でRedmineチケットを管理できれば、astahのモデルの作業管理が大変やりやすくなるだろう、と思う。
なぜなら、モデルは一夜で完成するものではなく、数多くの顧客要望を五月雨式に反映したり、他要件を考慮しながら洗練させていく作業のために、たくさんのToDoや課題が発生するからだ。
それらのTODOや課題を漏れなく管理していくことは、とても重要だから。

【3-3】そこで、astahのモデルのRedmineチケット一覧画面で、各項目をソートできる機能が有効に役立つ。
たとえば、ステータスでソートして、未着手・作業中のチケットを一覧の上部に表示するようにすれば、TODOリストのように扱える。
あるいは、優先度でソートして、優先度の高いチケットを画面上部に表示すれば、直近で最優先のタスクを判別できるようになる。
さらに、トラッカーでソートして、障害や課題チケットのみに注目してもいい。

実際にRedmine連携プラグインを使っていくと分かるが、モデルの変更作業の情報をチケットに起票していくと、じきに10件、50件とチケットが増えていく。
そして、完了チケットと作業中チケットがたくさん混じってしまい、管理しにくくなる。

だから、変更履歴として見たい時は、ステータスの降順でソートする一方、TODOリストとして見たい時はステータスの昇順でソートするし、課題リストとして見たい時は、トラッカーでソートしたくなるだろう。

【3-4】さらに、Redmineチケットの情報をもっと詳しく書きたいなら、astahではなく、Redmineチケットに書き込めばよいだろう。
そうすれば、Redmineの優れたチケット集計機能や全文検索機能で、欲しい情報をいくらでも集計したり検索できるようになる。
また、Wikiとリンクさせて情報を集約させることもできるだろうし、モデルのTODOリストとなるチケットを元に、Redmine上で進捗管理してもいい。

すなわち、astahではモデルそのものの要件や仕様を描くことに注力し、課題やTODOやRedmineで管理するように、区別して管理すればいい。
つまり、モデルの作業そのものの進捗管理、課題管理はRedmineで代用できるし、その方がRedmineの優れた機能を利用できるメリットがある。

但し、モデルそのものの履歴管理、つまりモデルの構成管理はRedmine単体だけでは実現できない。
モデルがどのように変化したのか、実際に見たい、という要望は、上記のプラグインでも実現されないので注意。

【3-5】astahユーザがRedmineを使っているならば、Redmine連携プラグインはたぶん使いやすいと思う。

似たようなastahのプラグインとして、TODOプラグインなどがあったけれど、TODO一覧がastahモデル単位に表示されないので、TODOが溢れると探しにくくなる弱点があった。
また、TODOをソートできない弱点もあり、TODOが多くなるとイマイチな面があった。
でも、Redmine連携プラグインで、それらの弱点は全て解決される。

【4】僕は、astahのようなモデリングツールとRedmineやTestLinkなどの開発支援ツールと外部連携することは、とても発展の余地があると考えている。
なぜなら、astahのモデルと外部の開発支援ツールが連携することで、数多くの情報を相互に参照しやすくなり、色んな使い道が出てくるからだ。

実際、Redmine連携プラグインによって、astahのモデルの変更履歴がRedmineチケットに蓄積されるだけでなく、モデリング作業の進捗管理やモデルの課題管理を行えるようになる。
また、TestLinkとastahがもし連携できれば、テストケースと要求図を相互リンクできて、要件カバレッジを出力できたり、トレーサビリティマトリクスを出力する、という機能も実現できるかもしれない。

よって、モデリング作業を開発プロセスの一部に取り込んでしまい、昨今の優れたプロセス支援ツールの機能を流用して相乗効果を得る、ということもできるのではないか。

あるいは、astahで設計したモデルに関する情報を超高速開発ツールに取り込んで、即座に開発していく、というモデル駆動開発も実現できるかもしれない。

この辺りの構想も今後まとめる。

| | コメント (0)

2018/01/01

アジャイル開発にはモデリングや要件定義の工程はあるのか、という問題とその周辺

最近のツイートで、アジャイル開発には要件定義工程はあるのか、というテーマで、DOAモデラーとアジャイル系のアーキテクトの間で議論があった。
内容がとても奥深い。

僕はまだ自分の考えをまとめきれていないので、自分が後で参考にしたいためにリンクしておく。
以下、ロジカルでないラフなメモ書き。

【参考】
@yusuke_arclampさんのまとめ記事が公開されました。

アジャイルにおける事前合意について - arclamp

【1】エンタープライズアジャイル勉強会 2017年12月セミナー開催のお知らせ

アジャイルを機能させる外枠について - arclamp

(引用開始)
アジャイルを機能させる2つの外枠

1つ目の外枠は「何を作るべきか」という観点。
チームが何を作るべきか、という手前には「そのチームが実現すべき価値とは何か」をきちんと考える必要があります。この点はギルドワークスの市谷さん(@papanda)にお願いしました。市谷さんの講演は「アシ?ャイル開発はWhyから始まる」というタイトルで、機能開発の前にWhyとしての仮説検証を行うことで開発が右往左往しなくなる、という話でした。「顧客開発をプロダクト開発よりも極端に優先するとチームが右往左往する」という指摘はその通りですね。

2つ目の外枠は「どう作るべきか」という観点。
ただし、これはプロダクト本体の作り方ではなく、プロダクトの外側と連携する部分の作り方の話です。これは僕が「アジャイルを支えるアーキテクチャ設計とは」というタイトルで、アーキテクチャ設計にも、プロダクト本体の作り方を考える「小さなアーキテクチャ」と、プロダクトの外側の作り方を考える「大きなアーキテクチャ」という紹介をしました(参照:大きなアーキテクチャ設計と小さなアーキテクチャ設計 - arclamp)

というわけで、アジャイルチームを機能させる外枠は「仮説検証というビジネスの話」と「大きなアーキテクチャという技術の話」があるのでは、という整理をさせてもらいました。
(引用終了)

つまり、見積りできないモノ、ステークホルダーとの調整をアジャイルチームに持ち込まない。

isopさんのツイート: "kent beckや平鍋さんが偉大なアーキテクトだから、という文脈は激しく同意したい"

isopさんのツイート: "@hiranabe 先日のエンタープライズアジャイル勉強会での @yusuke_arclamp さんのQAセッションで開発サイクルを回すことでアーキテクチャは自然と生まれてくるのか?という質問に対する回答でした"

鈴木雄介/Yusuke SUZUKIさんのツイート: "どちらかというと「平鍋さんやkent beckがアジャイルを語るとき、アーキテクチャの重要性が本人達にとって自明すぎるがゆえに語られないのは問題だ」というクレームめいた言い方をしまして... https://t.co/P6Ou6WRkpl"

【2】上記に関する感想をツイート。

akipiiさんのツイート: "名言。ストンと落ちた。RT @yusuke_arclamp: エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM https://t.co/qFNXcROiek"

昌。さんのツイート: "@akipii @yusuke_arclamp 先日のアジャイル勉強会でもその辺り激しく主張されてましたね"

akipiiさんのツイート: "@aj15_aj15 @yusuke_arclamp 立場によっては、当たり前だろ、という意見と、開発を最大に効率化する観点では、この方法しかないので、この方法を洗練化すべきだ、という意見があると思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@akipii @aj15_aj15 特にエンタープライズ業界でアジャイルをスタートする方は強めに意識してもらいたいな、と思います。僕の知る現場で苦労しているのは、この2つということが多いので。"

門屋 浩文さんのツイート: "@yusuke_arclamp @akipii @aj15_aj15 なるほど。エンタープライズアジャイルにはまだ踏み込んでいませんが、納得です。ただ、それができるPOやSMはウォーターフォールでもうまくいく気がします。早く成果物を作る・使うって効果を優先ってことで手法を選択、ですかね"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 いえいえ、もっと深い意味があります。DOAモデラーとの議論では、アジャイル開発では要件定義やアーキテクチャ設計は誰が担当するのか?と言う議論がありました。アジャイル開発の文脈では、開発チームは要件定義やアーキテクチャ設計を担当せず、POに委ねることで解決しようとしてます。多分。"

akipiiさんのツイート: "@MadoWindahead @yusuke_arclamp @aj15_aj15 よって、DOAモデラーの観点では、そうならば 速く開発できるのは当たり前でしょ、と。でも要件定義やデータモデリングを他人の手に委ねて良いのかと。僕は、アジャイル開発のような特化したやり方は有りと思うし、そういう仕組みがあるから中小SIが市場に食い込めるので日本では人気あると理解し… https://t.co/QO72yG0fhm"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@MadoWindahead @akipii @aj15_aj15 アジャイルでは「要件定義レベルでモデルやアーキテクチャを固くすることに意味がない」とも言えます。なぜなら変化するから。つまり、作りはじめるまでに、いつ、どこまで、誰が固く表現するのか?というのが論点かと。"

【3】スクラムとの関わりについて。

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルで「エンジニアにとって面倒なことをチームに持ち込まない」というのを「効率化のために調整は減らすべき」と考えるか「エンジニアの甘え、仕事の醍醐味は調整だ」とするかで分かれそう。もちろん、両面ある。僕としては「両者を混ぜて曖昧にするな」というだけ。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スクラムマスターってエンジニアの世話役とかおもりみたいな面もあり「そんなの甘え」と思う人もいるだろが、そういう人がいないとエンジニアが機能しないのも事実なんだよね。ウォーターフォールでいう「バッファ」を実体化したのがスクラムマスターともいえるのかな?"

鈴木雄介/Yusuke SUZUKIさんのツイート: "ともかく日本でまともな開発現場、エンジニアがやり甲斐があって、つらくならない開発現場を増やしたい。でも、なんでもできるエンジニアは限られているから組織やチームとしてできる体制を作らないといけない。だから、マネジメントが必要になる。アジャイルは良いツール。"

みぞやんさんのツイート: "@yusuke_arclamp WFでいう(人数によりますが)サブシステムごとのチームリーダーがスクラムマスターを担えるといいのかなと思いました"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@mizoyan432 最新のスクラムガイドでも「スクラムマスターはサーバントなリーダーである」と記載があるので、ある意味ではその通りです。ただしコミュニケーションパスを抑えるようなリーダーではないべきですね。"

HARADA Kiroさんのツイート: "@yusuke_arclamp 有効なら「甘え」でなにか悪いことでも?くらいのノリですかねえ。バッファよりは、もうちょい能動的で、バッファ減らす要因に働きかけに行く感じ。"

【4】アジャイル開発とWF型開発における、プロセスの違い、体制の違い、

鈴木雄介/Yusuke SUZUKIさんのツイート: "企画の決める仕様がゆるい、基幹システム連携がもめる、運用部門に提出するドキュメント作成が大変、といったことはWFからアジャイルになっても変わらない。むしろ、課題として明示化される。作業に落とし込めない調整事を開発チームに持ち込ませないのが大事。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンタープライズ開発だと、WFでもアジャイルでもやるべきことはきちんとやる、のです。ただ、作業にならないものはスプリントに持ち込めなくなるからPOやSMが頑張って作業になるように調整を行うことになる。その代わりチームは機能の実現に全力を尽くす。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "スプリント計画で「開発チームが見積もれないものはスプリントバックログにいれない」というのが大事です。それがグダグダになるとうまく回らなくなる。そもそもプロダクトバックログに調整中のものは持ち込まないべき。その手前に解決しておかないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "アジャイルに比べてWFの方がゲートやプロセスが厳密なんて聞きますが、間違いです。アジャイルはスプリントごとのゲートやプロセスは大変に厳密です。ただWFはゲートの数が少ないので一回でやるべきことが多くなるだけで。"

上記のツイートは、本当に同意。
大規模WF型開発でも、優秀なプロジェクトマネージャは故意にフェーズ分けして段階リリースを踏む、という手段を取る場合が多い。
最後の1回だけの本番リリースは危険すぎる。

鈴木雄介/Yusuke SUZUKIさんのツイート: "WFからアジャイルへの転換で相談を受けることがあるけど、大抵のお悩みはプロセスの問題ではなくて、その会社の組織やルールの問題。で、そうであるならアジャイルに転換しても解決できません。むしろ、転換を機会にどうするのかを考えないと。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラ開発における調整の多さに対してアジャイルなんてうまくいかないだろうと思っていた頃が僕にもありましたが、うまくいく方法があるんです。仕掛けは簡単、調整をアジャイルチームに持ち込まないことです。外で調整してから持ち込む。その防波堤がPOやSM"

そういう文脈で、アジャイル開発では、スクラムマスターやプロダクトオーナーが防波堤になる。
組織パターンにおける防火壁、ファイアウォール。

鈴木雄介/Yusuke SUZUKIさんのツイート: "エンプラで調整が面倒なのは仕様合意、システム連携、インフラ調整、運用引継。インフラ調整はクラウド化で軽減、システム連携や運用引継はプロセス関係なく事前ネゴ。仕様合意はアジャイルの締切駆動や定期調整に変更。つまり、アジャイルで変化を強く求められるのはビジネス側"

鈴木雄介/Yusuke SUZUKIさんのツイート: "みんなアジャイルに期待しすぎなんだよ。面倒なことは面倒なままだし、ちゃんとしないといけないことはちゃんとすべき。むしろ、エンプラなんてそうじゃないと困る。ただし、仕様を先に全て決めるという無理ゲーからは解放してくれる。"

【5】@yusuke_arclampさんと@sugimoto_keiさんのやり取りを読んだ後で振り返ると、おそらく、アジャイル開発には要件定義工程はあるのか、という問題の本質を突いているのではないか、と直感した。

杉本啓さんのツイート: "鈴木さんのエントリで一番気になったのは「見積もれないことをチームに持ち込まない」という点です。興味深い要求は、ふつう最初見積もれないですからね。これは「なすり合い」「平行線」とは違うと思うのです。私は鈴木さんの心情を批判しているのではなく書かれた主張を批判している点ご理解下さい。 https://t.co/XE9KG0za2U"

吉田 収さんのツイート: "@yusuke_arclamp @sugimoto_kei いわゆる「ビジネスアナリスト」の領域はチーム外とした方がよいということになるでしょうか。"

杉本啓さんのツイート: "@omuysd @yusuke_arclamp お尋ねの点は、どう仕切りたいかという意思の問題に依るところが大きいように思います。私としては、業務側との関係が宜しければ、業務要件の定義・分析もチームで担当する方が好みですが、それは設計/開発だけチームで受けるのとは少し異なるビジネスかと思います。"

鈴木雄介/Yusuke SUZUKIさんのツイート: "@omuysd @sugimoto_kei フェーズによると思います。初期は完全に外でも良くて、作るものが見えて来たらやり取りを開始し、画面への落とし込みはチームに任せていくという雰囲気でしょうかね。杉本さんが言われるようにチームのスキルや関係性で寄り方は変わるでしょうが。"

@yusuke_arclampさんも違和感を感じられているのかな、と感じた。

akipiiさんのツイート: "DOAモデラーとの議論を読んでたら、そんな感じがする。RT @yusuke_arclamp: なんか自分の主張がRUP的にフェーズによってチームスキルの濃淡を付けろという話になっている気がしてきて微妙な気分。うーむ https://t.co/Vweh4rkrnO"

【6】DOAモデラーからの意見。
モデリングするという行為の立場から言えば、まさに正論。

年忘れLT宴会<第60回IT勉強宴会> | IT勉強宴会blog

ソフトウェア開発と業務システム開発(杉本さん)

(引用開始)
アジャイルとウォーターフォール

・「ソフトウェア開発」に関するアプローチの違いだけではない。
・スコープ(視野に収めている範囲)が違うよね。
・ソフトウェア開発 vs. 業務システム開発
・超高速開発は、スコープの点ではWFと同じ。
・ソフトウェア開発を仕事としているエンジニアに超高速開発を訴えるとき、注意しないとスコープを誤解される。
・超高速開発は、業務システム開発の面を強調した方がよい。超高速開発というとソフト開発が早くできるというメッセージだけ。
(引用終了)

個人的には、関西IT勉強会で、DOAとアジャイル開発におけるモデリングや要件定義の違いについて、@yusuke_arclampさんと@sugimoto_keiさんの対談を聞いてみたい、と思う。

【7】個人的な感想を以下、書いておく。
ラフなメモなので、論理がズレているかもしれない。

【7-1】超高速開発ツールが何故プログラマに嫌われるのか

超高速開発ツールを使うと、DB設計や実装モデルを作れば、プログラミングレスで即座に業務システムを作れる。
つまり、超高速開発はモデル駆動開発の方向性に似ている。

しかし、プログラマの観点では、超高速開発ツールは正直面白くない。

プログラマなら、誰もが自分のプログラムが一番と思っている。
でも、自分が書いた優れたプログラムを見てくれ、という場面をアピールできない。
Githubで互いに書いたプログラムをフォークして、プルリクエストを送る、といったソーシャルコーディングが実現されない。

また、モデルという絵や、モデルを表現するための別のプログラムであるDSL(ドメイン特化言語)を別途覚える手間がかかる。
そんなものを覚える暇があるなら、RubyやPythonをガリガリ書きたいし、そちらの方がはるかに意味があるでしょ、と。

すると、超高速開発ツールは製造業のSE向けがマーケットなんだろうな、と思う。
つまり、プログラミングしないけどシステムを開発したい人達、すなわち発注者、特に日本では製造業のSEがターゲットになるだろう。

彼らはプログラミングは下流工程とみなし、外部へ発注するのが普通と考えているからだ。
外部に発注する工程が超高速開発ツールで代替されて、発注費用がなくなるのが理想だろうから。

akipiiさんのツイート: "同感。良い物なのに肝心のターゲット、つまり発注側のSEに届いてない気がする。RT @sugimoto_kei: 翻って超高速開発ツールを見るに、ターゲットがバクっとし過ぎのような気がする。もちょっとターゲットを定めた方がよいのでは?"

また、超高速開発ツールは多分最終的にはDSL基盤を目指しているんだろうな、と思う。
つまり、超高速開発ツールはプログラミングしない代わりに、モデルを描くために特化したスクリプト言語が必要になり、それがDSL(ドメイン特化言語)になるわけだ。

たとえば、UMLでもOCLみたいなDSLが提唱された時もあった。
DSLの優れた事例は、ExcelのVBAという意見もあったな。

そのDSLの最大の特徴は、プログラマでなくても、ユーザが分かるようなプログラミング言語であり、ユーザが簡単に書けることだろう。
システム化したい業務を一番良く知っているユーザ自身が、モデルをDSLで書いてしまえば、後は超高速開発ツールが即座にシステムを作れる、というストーリー。

そういうストーリーでは、プログラマの出番はないし、業務システムの発注者であるユーザ自身が超高速開発ツールを使いこなせるようにならなければならない。
超高速開発ツールはおそらく、そういう方向へビジネスモデルとして進化するのではないか。

【7-2】アジャイル開発における発注者と開発チームでの設計上の役割分担の誤解

上記のように、アジャイルチームには、外部との調整や要件定義に関わる作業は担当させない。
要件定義やそこから定まるプロダクトバックログはプロダクトオーナーが担当するし、スクラムマスターがスクラムチームの守護神として守る。
つまり、アジャイルチームの外側に、要件定義やモデリングの作業が追いやられているように見える。

モデラーの立場から言えば、そういう分業体制なら、速く開発できるのは当たり前だろう、と。
既に、作るべき機能リストがあり、チームはそれを淡々とこなせばいいのだから、と。

おそらくこの部分で、アジャイル開発とDOAモデラーとの間で、認識の相違が生まれるのだろうと思う。

【7-3】アジャイル開発が何故日本では中小SI企業に人気があるのか

では、なぜ、アジャイル開発が日本でも注目されているのか?
アジャイル開発が注目される理由の中に、日本特有の事情があるのか?

理由として、日本の中小SI企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という意見があって、すごく納得した。

実際、日本のIT業界では、受託開発は請負契約の多段階の下請構造になっている場合がほとんど。
すると、その構造のままでは、中小SI企業自身がIT案件を主導するビジネスはやりにくい。

しかし、アジャイル開発を採用すると、ユーザ企業とシステム企画や要件を直接ヒヤリングしながら、スピーディにシステム開発して納品するビジネスモデルを実現できる。
つまり、今までは、元請けSIの大企業が担当していたシステム企画や要件定義フェーズを、下請けの立場に甘んじていた中小SI企業が直接担当して、ユーザ企業と直接契約できるようになるメリットがある。

特に、Webシステム開発のように、技術力に特化しているならば、要件定義さえ上手くまとめれば、ユーザ企業と直接やり取りしながら、小刻みにリリースしながらシステムを納品していくことができる。
一方、発注者であるユーザ企業も、早い段階でシステムの受入れで確認できるし、途中で細かな改善要望も織り交ぜられるので、双方にメリットが共有できれば、受け入れやすい契約になる。

また、ドメイン駆動設計のような設計手法、ユーザストーリーマッピング等の要件定義手法、リーンキャンパスやリーンスタートアップなどのシステム企画の手法も色々編み出されているので、従来のアジャイル開発の盲点であったフェーズもカバーできるようになってきている。

すなわち、日本におけるアジャイル開発の文脈では、アジャイル開発は、中小SI企業が多段階の下請構造から脱却するためのビジネスモデルとして捉えられる、のではないか。

【7-4】DDD(ドメイン駆動設計)がアジャイル開発におけるモデリング技術の補完的役割を担っている

では、アジャイル開発では要件定義やモデリングは不要なのか?
開発チームの外側で要件定義やモデリングを行うとしても、プロダクトオーナーはアジャイル開発の文脈でどのような要件定義手法やモデリング手法を持つべきなのか?

2018年初頭の日本では、ドメイン駆動設計がアジャイル開発における唯一のモデリング手法として認知されている、という回答になるのではないか。

現場で役立つシステム設計の原則を読んだ | mizoguche.info

Takuto Wadaさんのツイート: "(トッパン|ピアソン)ショック、単に絶版、様々な要因でOOA/OODの書籍がほぼ死滅し、訳書が出るタイミングが遅かったDDD本だけがオーパーツのような存在になった結果、日本ではDDD ≒ OOA/OODになってしまったという奇妙な状況の背景の話をした #teppeis_sushi"

@t_wadaさんの指摘の通り、2000年代はオブジェクト指向分析の観点で色んなモデリング手法が提唱されていたが、それらの本を出版していた出版元が書籍発行を辞めてしまったため、最も遅く出版されたドメイン駆動設計本だけが生き残り、その本しかアジャイル開発者は参考できない、という現状があるからではないか。

つまり、ドメイン駆動設計が日本で注目されている理由の一つは、そういう日本特有の事情があるのではないか。

【7-5】超高速開発ツールには、DOA基盤のツール以外にも、SalesforceやKintone、Ruby on Railsも含まれる

そういう超高速開発ツールはDOA基盤のツールだけでなく、著名なパッケージ製品では、SalesforceやKintoneも含まれるだろう。
たとえば、DOAの発想でデータモデルさえきちんと設計すれば、Salesforceで簡単に実装できる。
また、要件定義できちんと要件さえ確定していれば、KintoneでAPIを駆使して、簡単な業務システムを作り込める。

杉本啓さんのツイート: "kintone というのは複数テーブルのジョインも出来ないと聞いて、全然だめじゃないのと思っていたのだが、使ってみるとそうでもないようだ。簡単な台帳を作るにはよく練られている。ターゲットとする用途をうまく選択することがいかに重要かを示す例かもしれない。"

杉本啓さんのツイート: "@akipii はい。私も超高速開発ツールと同じと思っていましたが、おっしゃるように、想定している利用シーンが異なる(kintone の方が絞り込まれている)のではないかと今は考えています。@iteman さんの方が詳しいですが。"

Atsuhiro Kuboさんのツイート: "@sugimoto_kei @akipii 汎用の CMS と WordPress 等のブログシステムとの違いに近いと感じています。超高速開発ツールは「設計する」というアクティビティがあると思いますが、kintone にはそれがない感じでしょうか。"

そういう観点では、Ruby on Railsも超高速開発ツールの一種とみなすこともできるだろう。
業務のデータモデルをActiveRecordで対応付けることができれば、画面は簡単に自動生成できるから。

さらに、画面の細かなUIは、JavaScriptで作りこめばいい。
たとえば、XEADでも、画面UIの作りこみの部分はJavaScriptで実装できるように作られている。

特に、Ruby on RailsはJavaScriptと大変相性が良いので、画面UIをデスクトップアプリのような操作感で実現できる。

よって、最近は、DOA基盤のツールだけでなく、SalesforceやKintoneのように手軽に操作できる有償のパッケージ製品、さらにはRuby on Railsのような強力なフレームワークが普及したことで、超高速開発ツールを適用したいニーズに当てはまるのだろう、と思う。

【7-6】超高速開発ツールが普及したからこそ、匠Methodのような要件定義手法に価値がある

アジャイル開発やプログラマの視点では、超高速開発ツールに否定的になってしまう。
しかし、超高速開発ツールのおかげで、発注者自身がお手軽にシステム開発できる基盤が整った、という側面もある。
つまり、要件定義できちんとシステム要件さえ確定できれば、超高速開発ツールを使えば、即座にシステム化できるのだ。
よって、萩本さんが提唱する匠Methodを要件定義のための手法として扱って、超高速開発ツールのインプットに連携すれば、スムーズにアジャイルに開発できるだろう、と思う。

そんな話を連想できたのは、先月に関西匠塾に行ってきて、匠メソッドの概要を初めて聞いたから。
詳細はまだ理解しきれていないけれど、ビジネスモデル設計やシステム企画から業務の要件定義まで一通り、設計できる、とのこと。

価値を描き、活動に落とし込む手法を学ぼう! - connpass

では、その後はどうやってシステム開発するのか?
お話を聞くと、たとえば、Salesforceを使って、システム要件を元に素早くシステム開発していく、というストーリーみたい。
つまり、匠メソッドを要件定義のアウトプットを作るフェーズで使って、業務の要件定義書を作り、それをSalesforceやKintoneのインプットとして用いることで、アジャイルに開発できる。

【7-7】kintoneという超高速開発ツールの開発基盤があるからこそ、業務ハックという職業も生まれる

この考え方は、最近、倉貫さんの会社でも提唱されている業務ハックにつながるのではないか、と推測する。

業務改善とシステム化を一緒にやってしまう「業務ハッカー」という新しい職業 | Social Change!

業務ハック勉強会@大阪 ? 働き方改革にも効く!事例で学ぶ業務改善のノウハウ - connpass

つまり、超高速開発ツールのような即座にシステム化できる開発基盤があるからこそ、プログラマの観点では、業務モデリングも実装ツールの一つに組み込んでしまって、アジャイルにシステムを作りながら、業務もシステムも改善してく手法を取っていく、という考え方ではないか。
ユーザから画面UIに関する細かな改善要望があっても、JavaScriptさえ操ることができるなら、画面UIの作りこみにさほど苦労することはないだろうから。

この辺りは聞いてみないと分からないけど。

【8】以上は妄想にすぎない部分もあるけれど、今年も色んな勉強会に行ってみて、上記のアイデアの方向性が合っているのか、確認してみたい。

【追記1】
鈴木雄介/Yusuke SUZUKIさんのツイート: "相変わらずウォーターフォールとアジャイルの話は受けがいいなぁ。最近のエンタープライズ界隈はウォーターフォールからアジャイルへの転向が増えている気がするので、もっと、こういう話はされていいんだろうな。 https://t.co/yR1x9ZUku4"

【追記2】
杉本啓さんのツイート: "読みました。興味深い試みですね。業務の仕組みを作るという志向において超高速開発やDOA界隈と似ていると思います。「業務ハッカー」という呼称は、確かに新味があってプログラマに受けそうですが、顧客サイドからするとどうですかね。現場の人には響くでしょうが、上の方には響きにくいかも。 https://t.co/fbXybQn6vL"

akipiiさんのツイート: "@sugimoto_kei 実現したいものは超高速開発ツールも業務ハッカーも同じ方向性に感じます。但し、モデリングに注力してノンプログラミングにする超高速開発ツールと、プログラミング作業の中に業務設計や運用設計を取り込む業務ハッカーは手法が異なると読み取りました。"

杉本啓さんのツイート: "@akipii まあ、嗜好は違うのだとは思いますが、同じ問題領域を対象にするのであれば、収斂してくるような気がしますね。超高速開発がノンプログラミングというのはセールストークであって実際にはDSLなどでプログラミングするわけだし、業務ハックで使うkintoneもある種のDSL環境ですしね。"

杉本啓さんのツイート: "@akipii 業務ハッカーについては、私は、さほど違和感を感じていません。買う側の意思決定者には響きにくいだろうなと思う程度です。調整をチーム外にという鈴木さんの話については、たぶん問題意識についても不一致があると思います。"

杉本啓さんのツイート: "@akipii とはいえ「超高速開発」よりは「業務ハッカー」の方がセンスありますね。ユーザ視点に立つと、前者では開発が速くなるんだろうなあという印象しか湧きません。後者だと、自分たちの業務に踏み込んで考えてくれるのかも、という期待が持てます。"

| | コメント (0)

2017/12/30

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか

下記の記事で、モデルの粒度とトレーサビリティの問題はモデリングツールではなくUMLそのものに真因がある、という事実に気づいたのでメモ。
以下、ロジカルでないラフなメモ書き。

【参考】
プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MONOist(モノイスト)

akipiiさんのツイート: "「UMLの使いにくいところと開発現場での実際的対応」の内容が本当に同感。UMLそのものが大規模案件で使うことが想定されてない問題があると思う。プロジェクトを成功させるモデリングの極意(3):UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MO… https://t.co/qHIjmtpMKt"

【1】(引用開始)
UML/SysMLの使いにくいところと、それを使いこなすコツ
 UMLとSysMLは組み込み系開発で比較的多く使われていますので、ここではUMLとSysMLの使いにくいところと、開発現場でそれを克服して使いこなすコツを紹介していきます。

UMLの使いにくいところと開発現場での実際的対応

(1)階層記述ができない
 UMLで大規模なシステムをモデリングするときに、使いにくい欠点としては「階層記述」ができないという点を挙げることができます。大規模なシステムでは、ユースケースやクラス、オブジェクト、シーケンスなどの個数が膨大な量になり、ユースケース図やクラス図、シーケンス図などを描くときに階層記述ができないと非常に大きな紙が必要になります。A3用紙であっても描ききれなくなります。

 そこで開発現場では何らかの工夫をして、これらの図を階層記述をしているのが実情です。しかし、階層記述の方法が統一されていないため、各組織や各プロジェクト、さらに個人で違う記述をしていることがあります。結果として、階層記述の方法を確かめるところから、レビューを始めるということになります。

(2)要求図が弱い
 UMLで要求をまとめる図はユースケース図とそれを補間するシナリオ記述、さらに詳細に記述するためにアクティビティ図などを用いますが、要求図としての分かりやすさとしては不十分です。

 ユースケース図で要求とそれらの概略の関係は分かりますが、要求の一覧や要求間の関係、特に内包関係、要求の差分、要求の優先度などの記述は弱いものになっています。それを補間するシナリオ記述は基本的に自然言語で記述するため、モデラーの表現能力に大きく依存します。逆にアクティビティ図は機能がありすぎて、要求を記述すると別の図のようになってしまいます。

 開発現場ではユースケース図で要求の概略を表現し、詳細や一覧は昔ながらのExcelを使って自然言語で記述し、それに要求番号を振って、トレーサビリティを高めているような記述方法をよく見かけます。

(3)仕様が膨大で不統一
 UMLはその歴史から分かるように、モデル図と仕様が膨大になっていて、その思想も記述も不統一です。平たく言えば、図がばらばらで多すぎます。図が多いので、真面目なメンバー(融通がきかないメンバー)はどうしても多くの図を描いてしまいます。類似の情報を複数の図やその説明で見かけることになります。さらに悪いことにその用語や使い方がモデル図間で統一されておらず、同じ用語でもモデル図で違う情報になっていることもあり、どれを信用するか分からなくなります。まさしく魑魅魍魎な図になりがちです。

 開発現場では新規の開発よりも既存開発(改良開発)が多く、既存の多数のUML図をほぼコピペして再利用していることが多くなっています。コピペで低コストなのはいいことかもしれません(本当はそんなことはありません!)が、図が多いため、差分管理ができずに、全ての図の全ての部分を延々と保守続けることになります。いざ差分を探そうとすると、非常に面倒なことになります。

(4)トレーサビリティが弱い
 各モデル図で使用した要求やクラス、オブジェクト、シーケンスなどが他の図でどのようになっているかを追跡するときに、UMLでは弱すぎます。UMLツールによって、ある程度のトレーサビリティは保証されますが、図として見た場合は、トレーサビリティがなく、見にくくなっています。

 開発現場では、ここでもUML図とは別にExcelなどを使って、トレーサビリティを保証するようにしている場合が多くなっています。

(5)目的が総花的
 仕様が膨大という欠点と同様ですが、UMLを描く目的が曖昧になるとUMLで作ったモデルも総花的になりがちです。このため、モデル図は大きくなり、大きな紙(A3用紙)を必要とします。

(6)コード生成が弱い
 UML2.0になってコード生成は強化はされていますが、UMLでコード生成をするのは弱く、はっきり言って、使いものになりません。特に例外処理のコードも含めると面倒なことになります。最初の1回はコード生成をしても、その後、プログラムを変更する必要が生じたときに、モデル図から変更するのは骨が折れます。心が折れます。

(7)差分表記(相違性と共通性の表記)が弱い
 これはUML特有の欠点ではなく、多くの図的表現に当てはまりますが、以前のシステムとの差分、以前のモデル図との差分の記述が明示的にできません。ソフトウェアプロダクトラインエンジニアリング(SPLE)で使われるフィーチャー図のように差分を明示的に記述できません。開発現場では前のモデル図とどこが変わったのか、逆にどこが同じなのかを何らかの方法で記述し、共通部と差分(派生部)を明確に示す必要があります。

(5)その他のコツ
 UMLの各図では目的を絞って描く、コード生成には使わない、一覧表示などの管理は別にするなどがあります。
 ここではUMLの悪口とその対応の面倒くささを紹介した形になりましたが、これは逆に開発現場でUMLが定着し、使っている人が多いからこそです。この記事を読んで別のものを使おうとせずに(苦労はするかもしれませんが)UMLを使ってみてください。
(引用終了)

【2】astahをずっと使い続けてきて、モデルの粒度とトレーサビリティ、変更管理に関して不満があったので、その問題点について下記で考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

しかし、上記の記事を読むと、モデリングツールの問題ではなく、UMLの仕様そのものに真因があるようだ。
UMLでは、アーキテクチャを描いたモデルの階層化やトレーサビリティに関する仕様またはプラクティスがほとんど見られない現状がある。

一方、実際の開発現場では、要件定義から基本設計、詳細設計へ工程が進むにつれて、モデルの粒度はどんどん詳細化していく。
もっとモデルを詳細化すべきだ、という認識になったら、普通は次フェーズの工程で作業するように予定する。
つまり、各工程の設計モデルに関する粒度については、基本は設計者の間で認識は統一されているのが一般的だ。

また、要件から画面帳票の詳細設計書に至るまで、普通は設計書の間でトレーサビリティを確保するように、開発プロセスを計画する。
なぜなら、各工程のアウトプットが次工程のインプットになるので、トレーサビリティを意識しなければ、詳細設計書の正当性を保証できないからだ。
一般に、Excelの管理台帳で、要件定義書、基本設計書、詳細設計書の一覧を管理し、それらの間の関係を何らかの形で保守し続ける。

そういう現実を考えると、UMLでは各工程の成果物の粒度やトレーサビリティに関する基本方針がない点に問題があるような気がする。

【3】では、なぜ、UMLでは粒度やトレーサビリティに関する問題点にあえて触れていないのか?

理由はおそらく、粒度やトレーサビリティに関する仕様は、各案件で多種多様な運用ルールがありうるので、標準化する作業そのものが難しいからだろう、と推測する。
もし、粒度やトレーサビリティに関する標準ルールを決めたとしても、抽象的すぎて、実際の現場では、その仕様に耐えうるテーラリングにすごく時間や労力を費やすしかないのではないか。

似たような事例として、過去に、IPAがソフトウェアタグという仕様を定めて普及しようと頑張っていた事例があったけれど、実際の現場にはほとんど影響しなかった。

IPA 独立行政法人 情報処理推進機構:ソフトウェアジャパン2009 IPAフォーラム

コンピュータソフトの開発過程が一目でわかる仕組みを世界で初めて規格化 複雑化、大規模化する製作状況に対応した「ソフトウェアタグ」|奈良先端科学技術大学院大学

理想論としては、ソフトウェアタグのような符丁をソフトウェア成果物に組み込めば、農産物や製品のトレーサビリティのような運用が可能なはず。
しかし、ソフトウェアはそれらモノとは違って、実体が曖昧で管理しにくいために、現実に運用しにくい。
結局、粒度やトレーサビリティに関するExcel管理台帳が余計に増えていくだけで、その保守コストが増えていくだろう。

【4】また、UMLで変更管理や構成管理の問題を解決するアイデアはないのか?
UMLの仕様に関する最新情報は知らないので、この辺りは分からない。

しかし、UMLでモデルをお絵描きしても、その後の保守で問題となるのが、構成管理や変更管理の話題だ。
実際、本番リリース後の保守フェーズで、細かな仕様追加や仕様変更が発生すれば、その都度モデルを修正していくコストが発生する。
その作業コストは意外とバカにならない。

また、仕様変更前のモデルと仕様変更で変わった後のモデルの差分を表示する機能がモデリングツールでは弱い。
だから、その後の保守作業で、作業者が頻繁に入れ替わったら、変更理由や本来の意図も分からなくなりがちだ。

さらに、Gitならフィーチャーブランチを切って、マージする時にプルリクエストを送ってコードレビューを依頼する、という一連のプラクティスをモデリング作業に適用しにくい。
つまり、モデリングのレビューは、昔ながらのレビュースタイルで実施せざるを得ない。

モデルの構成管理、変更管理に関する問題は、10年以上前からほとんど進歩がないように思える。

【5】さらに、UMLそのものにその弱点が内包されているとすれば、どんな影響が出てくるのか?

僕は、大規模システムでは特に、モデルの粒度とトレーサビリティに関する枠組みがなければ、現実的に運用しにくいだろう、と考えている。

たとえば、大企業向けのERPは、販売管理、発注管理、生産管理、会計管理、人事管理など数多くのサブシステムで組み立てられている。
それらサブシステム単位に要件から仕様まで数多くのモデルがあり、それらが階層化されて、トレースされていなければ、描いたモデルは設計書の代わりにはならない。

また、描いたモデルの粒度について認識が合わなければ、設計者と開発チームのコミュニケーションを促進されないだろう。
さらに、大規模システムでは、数多くのテーブル、画面帳票、バッチがあり、機能が複雑に絡み合っているので、元々混乱しがち。

10年以上前に、オブジェクト指向開発プロセスが流行していた頃、全ての設計書をEnterprise Architectのモデルで描いて、Javaで実装するWebシステム開発案件に加わっていたが、内実は混乱していたのを思い出す。

【6】このように、UMLの仕様そのものに、モデルの粒度とトレーサビリティ、変更管理の問題が内包されているので、その仕様そのものを実現したモデリングツールもその問題点をそのまま現状に反映しているだけ、と理解できる。
つまり、モデリングツールに罪はない、と僕は考えた。

一方、モデリングツールがUMLの弱点を解決していく、という方向性もあるのではないか、と考えている。
つまり、モデルの粒度とトレーサビリティ、変更管理に関する問題は、むしろ、モデリングツールが積極的に解決できる分野ではないか、と考えている。

実際、業務フローやアーキテクチャをモデリングしていたら、モデラーは自然に、自分が描いているモデルの粒度を揃えたり、詳細化していく時にトレースしながら仕様を詰めているはずだ。
よって、モデリングツールが、モデラーの思考行為そのものを支援するように操作性を向上させることは可能なはずだ。
つまり、モデリングツールは、モデラーのモデリング作業を補完する統合設計環境であるべきだろう。

その辺りも今後考えてみる。

【追記】
モデル駆動開発の考え方について、良い記事があるのでリンクしておく。

モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン)

akipiiさんのツイート: "モデル駆動開発用ツールBridgePointを使って、クラス図とステートマシン図を作成して実際にシステムを動かすお話。面白い。モデル駆動開発におけるモデル変換の役割 (1/2):CodeZine(コードジン) https://t.co/StxjQjZ8pg"

| | コメント (0)

2017/12/27

安全性解析手法STAMP/STPAセミナーの感想

先日、安全性解析手法STAMP/STPAセミナーに行ってきた。
ラフな感想をメモ書き。

【感想】
安全性解析手法STAMP/STPAセミナー@大阪(ソフトウェア高信頼化 SECセミナー )-SEA関西

安全性解析手法STAMP/STPAセミナー@大阪

「はじめてのSTAMP/STPA(実践編)~システム思考に基づく新しい安全性解析手法~」の公開:IPA 独立行政法人 情報処理推進機構

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

【1】最近のIT業界だけでなく、メーカーでも、IOTやAI、ビッグデータがバズワードになっている。
家電製品は既にソフトウェア化されてしまって価格破壊と鮮度劣化が激しいけれど、ついに自動車にもEVの波が押し寄せてきたように、メーカーが製造するあらゆる工業製品もソフトウェア化が迫ってきている。

しかし、従来のメーカーの品質管理手法は、そういうソフトウェア化の環境変化に対応しきれていないと考えている。
メーカーの品質管理手法は、統計的品質管理を主体とした、量産品の品質管理技法だと思う。
つまり、品質が保証された製品を大量生産するために、品質のばらつきを管理図などのQC技法で潰し、歩溜まりを上げて、経験曲線効果を活用して、コスト低減と品質向上を目指す。
この手法が以前まで、日本の製造業は品質で世界一だ、という評価をもたらしてきた。

しかし、製造業における、大量の資金投入による投資と生産設備の最新化、大規模化、という規模の経済の考え方は、ソフトウェア開発では全くと言っていいほど通用しない。
ソフトウェア開発は徹頭徹尾、労働集約的な産業だと僕は思う。

たとえば、人月の法則で言われるように、大量の開発メンバーが加わるほど、システム開発は遅れる。
他に、コンウェイの法則のように、大人数の組織は、その複雑な組織構造がソフトウェア設計にも反映されて、ソフトウェア構造がより複雑化され、ソフトウェアはエントロピー増大にさらされる。

そこで、アジャイル開発、そしてスクラムでは、規模の経済をベースにした製造業の開発スタイルではなく、サーバーントリーダーシップや自己組織化の理念の元で、小規模な開発チームで状況変化に素早く対応できる仕組みを提唱してきた。
よって、ソフトウェア開発をビジネスの主体とするならば、たとえメーカーであろうとも、アジャイル開発の導入は避けては通れないはずだ、と僕は思っている。

【2】でも、ソフトウェア開発の仕組みを製造業にそのまま取り入れたとしても、上手く行かない部分がある。
それが、安全性という品質特性だろう。
特に、フェールセーフという安全性の品質だろうと僕は思う。

たとえば、鉄道の踏切、交差点の信号、レンジやドラム缶式洗濯機などでは、人が事故に合わないように、安全が保持できる方向へ切り替わる仕組みが考えられ、昔からその機能が提供されてきた。
しかし、ソフトウェアが製品に組み込まれると、ちょっとしたバグが人命の危機にさらされるリスクが増大する。
そして、ソフトウェア開発者なら誰でも知っているだろうが、全ての潜在バグを潰すことは事実上不可能だ。
つまり、ソフトウェアが組み込まれた製品は、安全性に関して、何らかの不安が残る場合がある。

そういう課題は以前からずっと認識されてきたようで、たとえば、自動車の電子制御系に関する機能安全規格はISO 26262として最近公開された。
ついに自動車でもISOとして安全性という品質が業界標準で決まったために、組込ソフトウェアにおける安全性の研究は現在ホットな状況なのだろう、と思う。

IPAでも、この分野の研究が重要と認識しているようで、セーフウェアの本の著者であるナンシーさんとも共同して、安全性解析手法STAMP/STPAという手法を作り、日本のメーカーに広げようとしているようだ。

今回は、そんなセミナーに行ってきた。

【3】正直な感想を言うと、僕は門外漢なので、安全性解析手法STAMP/STPAがどこまで有効なのか、分からない。
でも、こういう安全性解析手法がどんな考え方をしているのか、というイメージは持つことができた。

一言で言えば、部品単体レベルの品質向上を目指すのではなく、もっと抽象的なレベルを上げて、製品とそれに関わるステークホルダーの関係に注目する観点で、安全性を議論しようとしている。
下記の絵が分かりやすい。

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速:IPA 独立行政法人 情報処理推進機構

一般に、メーカーの品質管理の考え方では、下請け業者から仕入れた部品の品質を徹底的に管理し、それら高品質な部品を組み立てて、最終製品の品質を維持しようとする。
しかし、製品が複雑な構造になると、部品単体の品質が良くても、それら部品の関係や依存性で品質が悪くなる時がある。
その話は、部分の合計は全体と一致しない、むしろ全体よりも大きくなる、という集合論の話を連想させる。
バナッハ=タルスキーのパラドックスだったかな。

バナッハ=タルスキーのパラドックス - Wikipedia

ソフトウェアが混じってくれば、なおさら、プログラム単体ではなくシステム全体として機能させた場合の方が品質に大きく関わってくる。
つまり、部品レベルではなく、製品全体、製品とそれに関わるユーザとの相互作用を考慮した「システム」のような考え方が必要になってくる。

【4】この考え方にはいくつか特徴があると僕は思う。

【4-1】一つは、製品のI/Fがユースケースになること。
たとえば、電気自動車を考えた場合、ユーザは電気自動車に何を期待するのか、という観点から、電気自動車に必要な機能を考えていくことができる。
この考え方のメリットは、ユーザの価値や便益を起点に機能を考えるので、ユーザに優しい製品になる可能性が高いことだろうと思う。
つまり、ソフトウェア開発の企画や要件定義の手法を取り入れているように思う。

すると、製品とユーザの接点は、製品のI/F機能、またはユースケースと考えることができる。
なぜなら、ユーザが製品を使う利用シーンを考えるようになり、それを表現しようとすると、ユースケースの概念が自然に現れてくるからだ。

また、ユースケースの概念が現れてくると、「SysML」本のコンテキスト図のように、製品に関係するステークホルダー全てがアクターとして現れ、その中心に製品が配置されるような図が作られることになる。
つまり、この考え方では、アクターを漏れなく抽出すること、アクターと製品に関わるI/Fとなるユースケースを自由な発想でどれだけ考えられるか、という観点が重要になってくるだろう、と思う。

そして、そのコンテキスト図を元に、安全性の観点を組み込んで製品の機能を付けていくことになるはず。

ただし、アクターやユースケースが漏れると、その後の工程で検出することは不可能なので、自由な発想を補強するようなプラクティスが必要になってくるのではないか。

【4-2】もう一つは、製品のハード設計がなくても議論できること。

一般に、ハード屋さんはどうしても実際のモノの設計図から考えたがる。
しかし、企画段階ではモノがないので、イメージにしくい。

だが、製品にはこんな機能があるとユーザにとっていいよね、という観点で、製品のI/Fを洗い出していくことができるし、それらI/Fを整理することで、製品のおぼろげなイメージが出てくる。
たぶん、iPodやiPhoneのような製品も、プロトタイプ製品はあったとしても、ユーザの利用シーンから色々考えて作られたのではないだろうか。

すると、製品のハード設計図がない状態で製品の機能を作り出し、安全性の品質の議論ができるようになる。

なお、SysMLのメリットは、ハード設計図がなくても、ソフトウェア層の観点で抽象的なレベルで要件や機能をイメージできること、という話を聞いたことがあったが、たぶん、その内容とほぼ似たことなのだろう。

実際、IPAの方の講演でも、抽象的なレベルで考えることでより広く安全性を考えることができる。
部品レベルのような粒度の細かい観点で考えると、安全性を考慮すべき観点が漏れやすいから、あえて、抽象度をあげて幅広く議論するのだ、という話があったから。

【5】上記の内容は素人の考えなので、どこまで正しいのか分からない。
でも、安全性の品質に関する議論を、箱と矢印の図で行おうとする方向性を見ると、ハード設計図のレベルではなく、SysMLのようなソフトウェアのレイヤーで抽象的なレベルで設計しようとしているように思える。

この手法がどこまで通用するのか、僕は分からない。
でも、ソフトウェア開発がハード設計でも重要になってくるならば、具体的なモノがない状態で機能を設計する必要性は出てくるだろう。
すると、ソフトウェア設計のように、要件や仕様を決めていく技法やプロセスが必要になってくる。
それら技法は、たぶん今までのハードのやり方は通用しないだろう、と思う。

そして、アジャイル開発を取り入れた場合の品質保証は、どのような観点に考慮すれば効果的なのか?
そういう課題も考えてみたい。

| | コメント (0)

2017/12/26

第18回Redmine大阪の見所~「チケット管理システムによるソフトウェア開発支援と今後の課題~気象庁のRedmine利用事例報告」

来年2月3日に開催予定の第66回 SEA関西プロセス分科会&第18回 Redmine大阪の見所を書いておく。

【参考】
第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - connpass

気象庁の数値予報課におけるRedmine利用事例: プログラマの思索

【1】(引用開始)
テーマ~「チケット管理システムによるソフトウェア開発支援と今後の課題」

今回の勉強会のメインセッションでは、気象庁の担当者の方にRedmineやGit等によるソフトウェア開発支援の事例報告を講演して頂きます。

気象庁|数値予報課報告・別冊 第63号(平成28年度) 数値予報モデル開発のための基盤整備および開発管理

気象庁におけるソフトウェア開発プロセスの事例で興味深い点は3つあります。

まず、一つのサーバー上で複数のRedmineインスタンスが運用されていて、各部署がそれぞれのRedmineインスタンスで異なる運用ルールを実施している点です。

次に、Redmineの特徴を十分に理解した上で下記のような運用ルールを展開している事が挙げられます。

(1)チケットの粒度は最初は気にせず、まずはチケットを作成して試行錯誤することを勧める事
(2)「No Ticket, No Commit!」ルールを徹底周知し、開発成果の信頼性向上や情報共有に役立てる事
(3)親子チケットによる進捗管理では、子チケットを五月雨式に作成しない点に留意する事

さらに、RedmineとGitを連携してgit-flowの開発プロセスを利用されているように、並行開発やコードレビューの仕組みを取り入れている点です。

以上のように、気象庁の事例報告を読むと、数値予報モデルの開発基盤と開発管理に、昨今のOSS開発では普通に行われているモダンな開発プロセスを上手く取り込んで運用されていることがよく分かります。

気象庁の担当者の方の事例講演を次回も聞くチャンスはそうありませんので、Redmineの初心者から、ソフトウェア開発プロセスに興味のある方まで、ぜひお越しください。

講演1
「気象庁の数値予報モデル開発における開発管理ツールの活用」

講演者:原旅人 様(はら たびと・気象庁予報部数値予報課予報官)

概要:
現在の天気予報は、スーパーコンピュータによる気象シミュレーション(数値予報)の
結果をもとに作られていて、そのためのソフトウェアのほとんどを気象庁の職員が
自らプログラムを作って開発しています。これらのソフトウェア開発は気象庁内で
組織横断的に、そして継続的に長いスパンで行われることが多いため、情報共有、
議論や作業の記録が大変重要であり、その支援ツールとして Redmine やバージョン
管理ツールを活用しています。

本講演では、気象庁の業務を簡単に紹介したのちに、気象庁におけるソフトウェア開発、
Redmine やバージョン管理ツールの利用の背景と経緯、およびその活用などについて
紹介します。
(引用終了)

【2】このたび、気象庁のRedmine利用事例を講演して頂けることになった。
個人的に聞きたかった内容ばかりなので、とても嬉しい。

上記の参考資料の通り、気象庁の開発プロセスでは、RedmineやGitなどの開発支援ツールを積極的に取り入れて、コードレビューや複数ブランチの並行開発、進捗管理などを効率化し、最近のオープンソース開発で主流となっている開発スタイルを実践されている。
気象庁というお硬い役所でも、モダンな開発スタイルを実践されているのに、未だにExcel主導のWF型開発に囚われた古い開発スタイルをやっているSIの方が多くて、時代遅れに感じてしまう時がないだろうか。

また、実際の開発業務では、気象庁の担当者自らがプログラミングして、天気予報の予測などの業務に役立てているのを読むと、自分たちの業務系システム開発とは違った別の側面が見えてきて、とても面白い。

たとえば、「Rubyは数値予報ルーチン関連のツールでも利用されている言語であり、管理者育成でも比較的少ない人的教育コストで管理可能という面を持ち合わせている」という記載から、気象庁にRedmineを導入しようとする壁は低かったのだろう、と推測する。
他に、欧米の気象庁に相当する官庁では数値計算にPythonを使うのが普及している、という事例を参考にして、Pythonスクリプトを記載していたりして、昨今の開発トレンドを積極的に取り入れようとする姿勢がよく伺える。

【3】そんな内容を考えると、気象庁では、先進的な技術を積極的に取り入れるという先取り精神が旺盛なのではないか、と思える。
実際、RedmineやGit等の先進的な開発支援ツール、RubyやPython等のプログラミング言語やライブラリを積極的に取り入れて、天気の数値シミュレーション等の業務に役立てているからだ。

Redmineコミュニティに関わるスタッフの立場としては、JAXAや気象庁という日本の大手官公庁でもRedmineを相当研究して利用されている、という事例が公開されることで、より普及が促進される効果もあるだろうと思う。

当日は、資料に記載されているRedmineやGitの開発ワークフローの背景、実際の気象庁の業務についても、色々詳しく聞いてみたいと思っている。

【追記】
ツイートした感想。

akipiiさんのツイート: "気象庁のRedmine 事例報告書を読み直してるけど、非常によく、Redmine によるチケット駆動の特徴を生かしてると思う"

akipiiさんのツイート: "Redmine チケットの粒度は最初は気にせず、チケット作成に躊躇せず、まずは試行錯誤してみたらいい。そのうち、チーム毎に運用は固まる、と。だから、あえてRedmine インスタンスを部署毎に立てて、運用とプロセスを任せている。"

akipiiさんのツイート: "気象庁では、チケット無しのコミット不可のルールを徹底周知して、Redmine とGitを連携し、さらにgit-flowに似たモダンな開発プロセスで運用されてる。お堅い官公庁の開発部署の方が民間企業より最先端かもしれない笑"

akipiiさんのツイート: "気象庁では、Redmine の親子チケットかんりでは、むやみに子チケットを五月雨式に作らない事に留意するよう促してる。そりゃそうだ。進捗率が90%になったのに安易に追加して50%に下がったり、仕様変更によるスコープ増大のチケットがどれか分からなくなる。アンチパターンでありそう"

| | コメント (0)

2017/12/23

仕様書にもExcel脱却が求められている

現代は、タスク管理や障害管理だけでなく、仕様書にもExcel脱却が求められている記事があったのでメモ。
ラフなメモ書き。

【参考1】
エクセルで手順書を作るのはきっとやめた方がいい - Qiita

(引用開始)
ある製品のインストール手順書を作ることになり、参考資料として過去の案件で作ったものをもらったのだが、それはエクセルファイルだった。
どういうものだったかを端的に述べると以下の通り。

目次がない
シート名に番号はついていない
各シートにも番号の記載はない
各シートの中身はスクリーンショットの羅列
スクリーンショットについての説明がほぼない
間違った手順のスクリーンショットも混ざっている
操作の結果を確認する手順が漏れているケースがある

この時点で大分げんなりするが、具体的に辛い点をあげる。

1. 全体像が掴めない
2. 順番に確信が持てない
3. コマンドの内容やインストール先のディレクトリもスクリーンショットに埋まっている
4. インストールがうまくいったかの判断材料がない、それを見つけられない
5. 再利用できない
6. 修正したときに差分がわからない
7. レビューするのが困難
(引用終了)

【1-1】一般に、要件定義書、設計書、テスト仕様書などはExcelで書かれている時がほとんどだ。
しかし、Excelのドキュメントは色んな点で弊害が出てくる。

僕の観点では、Excelファイルは構成管理と相性が悪い、という点が最大の弱点ではないか、とずっと思っている。

まず、GitでExcelを管理してもバイナリファイルは差分が分からないので、履歴管理する効果が薄い。
また、GitHubで管理できないと、コードレビューしにくいし、ユーザからのプルリクエストによるフィードバックも受付できない。
つまり、GitHubがもたらしたソーシャルコーディングという手法を適用できず、アジャイルにドキュメントを修正しにくい。

次に、Excelドキュメントは再利用しにくい。
罫線があったり、画像があったり、レイアウトが特殊だったりすると、修正するだけでかなりの手間がかかる。
特に、シートや節を1個追加すると、インデックスや目次が変わってしまうが、じきに誰も保守しなくなる。
すると、Excel設計書の全体イメージが把握できなくなり、ブラックボックスのような仕様書が残るだけ。

結局、共有ファイルサーバーに、いつ修正されたか分からない状態のExcelドキュメントがたくさん散在することになる。

【参考2】
Atom と PlantUML で快適シーケンス図駆動開発ライフ | Developers.IO

(引用開始)
「認識合わせ」という名目でホワイトボードに図を書いて会話することがよくあります。共通言語で会話してあいまいなところを少なくしたら、マネージャーも安心感がありますし、プログラマも自分がやるべきことに集中できますね。

…3日経ちました。あのとき描かれていたホワイトボードの図のとおりに、実装することになりました。認識の齟齬をなくしてくれた貴重な図です。写真に撮りました。どこに保存してたっけ。やっぱり変更したくなったらどうしましょう。またホワイトボードに書き起こす?DRYじゃないですねえ。

そこで、UML図 が登場します。表現したい図を電子データで作成、保存できて、あとで見るときも役に立ちますね。が、しかし、UML図はそれはそれでやや手間がかかるところもあります。作図を助けてくれるツールやサービスはたくさんありますが、

描画ツールを使いたくない
差分管理ができないのが辛い
メンテするのがいやだ。どこにあるかわかりづらくなる
というのが私の感想です。
(中略)
テキストで書けると差分管理できるようになる点が良いです。履歴が残ります。GitHubの機能が使えます。つまり、変更に対して レビューをしてもらえ、コメントをもらえます。 描画ツールでやろうとするとレビュー方法に工夫が必要ですし、もらったコメントの管理が大変です。GitHubの仕組みに乗せてしまうことでそのあたりの課題が一気に解決できます。

シーケンス図は強い
UMLには種々の図がありますが、こと設計~開発段階においては シーケンス図 が強力です。どのようなコンポーネントがあって、それらがどうやりとりするかを視覚的に捉えることができるためです。

シーケンス図というとオブジェクトがあって、そのオブジェクトのメソッドを実行すると他のオブジェクトが生成される…といったような図をイメージするかもしれませんが、「コミュニケーションをとりつつ進める設計段階」ではもっと大きな粒度、データベースや、外部APIといった粒度をオブジェクトにします。クラスやメソッドレベルのやりとりはコードで十分表現可能 である一方、コンポーネント間のやりとりは外部仕様として日本語ベースになっている ことが多く、後者はたとえ厳密だとしても可読性が低いです。シーケンス図はそれを補完するのに役立ちます。次の図は「ニュースの一覧を外部から取得してクライアントに返すAPI」のシーケンス図です。
(引用終了)

【2-1】設計書にUMLのシーケンス図を書きたい時がある。
なぜなら、たとえば、詳細設計書で仕様の意図を伝えたい時、オフショア開発チームにコンポーネント間の処理のイメージを伝えたい時があるから。
そんな場合、シーケンス図でラフに描くことには意義がある。

しかし、お絵描きするUMLモデリングツールで出力した画像ファイルを設計書に載せると、仕様変更のたびに修正が発生してしまう。
設計書のメンテナンスという作業に、保守PJではかなりの工数を費やされている場合が多いのではないか。

ここでも、たとえば、UMLのシーケンス図をplantUMLでテキストで残し、GitHubで管理し、設計レビューで使う、という運用が紹介されている。
UMLで描いた設計の絵はテキストファイルで保持できるなら、GitHubに載せることで、プログラミングの時と同じような効果が得られる。

【2-2】下記の記事では、設計書は全てテキストで書き切る、という方法が紹介されている。

AsciiDoc と PlantUML と mermaid.js で素敵なテキストベース仕様書ライフ

設計書そのものもMarkdownやAsciiDocでテキストで保持しておけば、Jenkinsで定期的にビルドして最新版のドキュメントを出力する、という手法も採用できる。
つまり、設計書もプログラミングと同様に、最近の開発スタイルを適用できるはず。

Redmineに作業内容をチケット起票
→設計書をExcelでなくテキストで作成
→Gitにコミット
→GitHubやGitlabで設計レビュー、再修正してGitにコミット
→Jenkinsで定期的にビルド
→納品時に、タグ付けした版を成果物として納品

「設計書は全てテキストで書き切る」ことにより、設計書も構成管理の配下になり、アジャイル開発の各種プラクティスが適用できるし、その恩恵も受けられる。

また、チケット駆動開発のメリットであるトレーサビリティを設計書の変更管理に利用できるようになる。
そうすれば、システム保守での元々の要件の調査、仕様変更の影響範囲の調査に大いに役立つはず。

【3】ちなみに、Redmineでもmermaidやplantumlのプラグインが提供されている。
RedmineのWikiに、設計概要やノウハウを集約できるので、便利になるはず。

Redmine Mermaid Macro Plugin

Mermaid Macro - Plugins - Redmine

「mermaidプラグインで始める構成図管理」 20171117 redminetokyo13

RedmineでPlantUMLを使う事例: プログラマの思索

Redmine で技術仕様書を書こう | Aiming 開発者ブログ

plantuml - Plugins - Redmine

【4】しかし、仕様書をExcelでなくテキストで全て書いて、ソース管理と同様にGitの構成管理に置くというやり方は、まだ試行錯誤している所だろう。
たくさんの課題がまだ残っているだろうが、いわゆる上流工程でも下流工程と同様に開発プロセスもIT化していくべきだ、という方向性へ進化せざるを得ないと思う。

【追記】
ソフトウェア開発の設計書のExcelテンプレートを公開した記事について、数多くのはてなブックマークが寄せられていた。
ここにも、上記の問題点が背後にあるのだろう。

はてなブックマーク - 無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき

akipiiさんのツイート: "皆苦労してるんだな笑。RT @mandamgame: RedmineのAPI叩いて未完了チケットを表にするExcelください。 / 他154コメント https://t.co/jXdGcJ3iFe “無料のシステム開発テンプレート集(Excel版): ある SE のつぶやき”… https://t.co/MBWCoh8mBQ"

akipiiさんのツイート: "@MadoWindahead @mandamgame いえいえ、Excel設計書のテンプレートなので、PJ毎の設計書が作られるため構成管理すべき対象になります。今の時代は、plantUMLでmarkdown形式でクラス図やシーケンス図で詳細設計書を書いたり、ドキュメントは全てmarkdownで書いた方がGitで管理しやすい、と思います https://t.co/UpnoEEDcbj"

| | コメント (0)

2017/12/16

Friends of astah*になりました

このたび、Friends of astah*になりました。
とても嬉しいです。

【参考】
Friends of astah*

振り返ると、自分は10年以上前からastahを使っていたんですね。

【再考】GanttProjectとFreeMindとJude: プログラマの思索

astah*Professionalファーストインプレッション: プログラマの思索

本格的にastahを使い始めたのは、Redmineによるチケット駆動開発の開発プロセスをUMLで分析してみよう、と思い立って色々描いていた時。
その頃は、アクティビティ図とステートマシン図、配置図がメインだった。

我流のプロセス分析をしながら、色んな気づきがあった。
たとえば、プロセスの例外処理はJavaやVBスクリプトの例外処理に似ているなあ、と思った。
また、プロセスが複雑な理由は組織の構造や権限をそのまま反映しているからだ、と気づいた。
つまり、コンウェイの法則そのままじゃないか、とか。

また、要件定義でシステム構成図、機能構成図、業務フロー、データモデルを書きながら、それぞれのダイアグラムにトレーサビリティという関連があること、粒度を保ちながらレイヤ化という思想で詳細化していく、という発想も身を持って体験できた。

こういう体験は、モデリングツールがあったからこそ、できたのだろうと思う。
なぜなら、Excelやパワポで絵を描くと、ちょっとしたレイアウト変更だけで労力を費やして、本来明示したい設計思想を忘れてしまいがちだから。
また、ダイアグラムを試行錯誤して描くことで、複数の観点でモデルを分析することが自然に身に付くし、各ダイヤグラムのトレーサビリティや粒度を気にするようになるから。

一般に、日本企業では、設計書は日本語という自然語で記述するのが普通。
しかし、日本語では主語が明示されていない、構造が明確化されていない、などの弱点があるので、いくら詳しく書いても必ず漏れる。
巻物みたいなExcel設計書をたくさん書いても、その後のマイグレーション案件では役立たない。

むしろ、A3の1枚用紙に描いたシステム全体概要の方が役立つ時もあったりする。
そんな経験もあって、自分の理解も深めるために、astahを重宝している。

しかし、astahも10年以上使っていると、こういう機能も欲しい、という思いも強くなってくる。
そんな思いも書いてみた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

また、XPJUG関西メンバーの後押しもあり、astah関西というコミュニティも立ち上げてみた。
来年度も、Redmineコミュニティと合わせて、色々活動してみたいと思う。

astah関西 第1回勉強会 - connpass

個人的には、ソフトウェア工学の実験ツールであるRedmineと同様に、astahも、ツールがモデリング技術の可能性を高める部分が沢山あると思っている。

ツールがプロセスを改善していく。
ツールが開発プロセスに新たな利用シーン、想定していなかった副次効果をもたらす。
ツールがモデリング技術の新たな可能性を開拓していく。

そんなアイデアを色々考えてみたいと思っている。

| | コメント (0)

«RedmineをMSProcjetっぽく使う事例