2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

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

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

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。

| | コメント (0)

TRIZ(発明的問題解決理論)のリンク

マーケティング企画業の古典的本「アイデアの作り方」、メーカー技術者が創造的発明する時に使う手法「TRIZ(発明的問題解決理論)」に関する情報のリンク。
結論もなく、自分のアイデアのためのラフなメモ書き。

【参考1】
アイデアのつくり方(ジェームズ・ウェブ・ヤング) - Wikipedia

「アイデアの作り方」 ジェームス・W・ヤング 感想 - 人といる時にスマホを触るな

わずか100ページの薄い本。
率直な感想は、「アイデアとは、古いアイデアを新しい机においたものと同じ」みたいに連想した。

【参考2】
TRIZ(アルトシューラ) - Wikipedia

アルトシュラー『発明的創造の心理学について』(邦訳) | 産業能率大学 総合研究所

アルトシュラー『発明的創造の心理学について』(邦訳)

TRIZが普及していないわけ(歴史的背景) ? アイデアを出すためのコトバとイメージの使い方

TRIZの概要

【1】研修で、プロジェクトマネジメント技法の一つとしてTRIZが挙げられていた。
こんな説明だった。

「(TRIZ)とは、直訳すると発明的問題解決理論。ロシアの特許審議官が膨大な特許情報を分析して「相反する問題を同時に解決すれば発明になる」「現実の問題を一般的な問題に抽象化すれば解決策がいくらでも出る」といった発明の法則をまとめた問題解決の方法論。」

つまり、品質とコストの両立という、互いの解決策が矛盾するような課題であっても、TRIZを使えば、いくらでもアイデアが出てくるよ、という売り文句だった。
それが本当かどうかはよく知らない。

【2】でも、産業能率大学 総合研究所にあるアルトシュラーの原論文「アルトシュラー『発明的創造の心理学について』(邦訳)」を読むと、深い思索があることが何となく感じた。

【2-1】原論文PDFにある自転車の事例が面白い。

最初に発明された自転車には「伝動装置がなく、走行する時は両足で地面を蹴らなければならなかった」。
そして「前輪の軸にペダルを取り付けるという技術進化」が起きた。

次に、「ペダルによって走行速度の増加」による事故障害の課題に対し、ブレーキが発明された。
「その結果、駆動輪の直径を大きくし、これによりペダル 1 回転による自転車の進行距離を増大させるという形で、作業装置をさらに発達」したが、「駆動輪の直径をそれ以上増加させると、自転車走行の危険性が急激に高まる」課題が出てきた。

そこで、「伝動装置の変更(チェーン伝動の採用)」が発明されて、「チェーン伝動により、車輪の直径の大きさではなくて、足踏み回転数を増加させる方法で高速を得ることができるようになった」。

そして「空気入りタイヤが導入」されて、「伝動装置の新たな変更(フリーホイール機構の採用)」が行われ、現在の自転車が完成した。

【2-2】つまり、ある機能の改良は、各要素のバランスを崩すまで劇的に改良できるが、その矛盾が噴出すると、システムの全体的発展のブレーキになり、成長速度が止まる。
なぜなら、ある機能に関する課題があるが、その課題を解決すると、他の技術的課題が現れ、その矛盾は現状のやり方では解決できなくなる段階に到達するから。

しかし、その矛盾の除去が本来の意味での「発見」であり、その発見は、システムの機能の一部を根本的に変更することにつながり、その影響範囲が広いほど、他の部分にも抜本的な変更を施すことになる。

そういうストーリーであると理解した。

【2-3】TRIZの原論文を読んで、「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の一節を思い出した。

「ローバー、火星を駆ける―僕らがスピリットとオポチュニティに託した夢」の感想: プログラマの思索

科学者とエンジニアの間には、宿命的な対立関係がある。

科学者の立場は、真実の探求、自然界の仕組みの探求、制約なしの研究の結果を重視する。
科学者は理想主義者。

一方、エンジニアの立場は、技術的課題の単なる解決ではなく、最も優れた方法で問題解決する。
限られた予算、開発スケジュール、納期の制約の下、「まずまずのところ」で折り合って解決する。
エンジニアはがんこな現実主義者。

つまり、エンジニアは、品質・コスト・納期のバランスという制約条件の中で、「ほどほどの品質」「ほどほどのコスト」「ほどほどの開発期間」で、最大の良い製品を生み出す。

その宿命的対立を乗り越えたら、すごく良い製品が生まれる、という話。
TRIZにも似たような雰囲気を感じる。

【2-4】但し、TRIZはソ連における膨大な特許から、そのアイデア発想方法を理論として生み出した背景があるので、そういう膨大な知識データベースがないと、本来のメリットを活かせない気もした。
課題を解決したい時、その課題に関連する技術情報が即座に収集できなければ、無い知恵をいくら絞っても、解決策は出てこないのでは、と思った。

つまり、「アイデアの作り方」と同じく、既存のアイデアを組み合わせるやり方に近い気もした。

TRIZ――10分以内に「それ、どうやって実現するか」を思いつく方法 (3/3) - ITmedia エンタープライズ

(引用開始)
筆者はTRIZの専門家から詳しいことを教えてもらう機会が幾度かあった。
TRIZを作った人々が分析した特許は非常に膨大であったが、その99%が40のパターンで表現できたと言われている。

逆に考えると「世の中にはパターンでは表現できないものが1%存在する」とも言え、人の知性のロマンチックな可能性をTRIZ創設者らが示唆しているように思えてならない。
真偽は定かではないが、筆者は少なくともこう考えている。目の前の100の課題に対して、この40個のパターンを使えばほとんど(99%)、何かしらの解決コンセプトが発案できる。
解ける問題は効率的にどんどん発案し、人間の知恵を絞るしかないこと(1%)にぜいたくに時間を使いたいものだ。
(引用終了)

【2-5】解決策をそういう組合せの問題に持ち込めるならば、その分野はソフトウェアが強い。
そういうアルゴリズムをプログラムで実装して、ひたすら組合せの結果を評価すればいい。

それは、機械学習、人工知能にも似たような匂いを感じる。
しかし、AIが全ての問題を解決できるわけではない。
たとえば、AIでも人間と同じく、過学習という罠にはまれば、そこから脱出できなくなる。

でも、量子コンピュータなら、トンネル効果を使えば、過学習から脱出できるかもしれない。


| | コメント (0)

WinSCPでトンネリングする方法のリンク

踏み台サーバーを経由してFTP接続する方法がWinSCPで実現できると分かったので、リンクしておく。
自分が後で参考にするためのリンク。
特に主張なし。

【参考】
WinSCPでトンネリングする方法: 小粋空間

踏み台サーバ経由でWinSCPを使ってSCP接続する方法 | 株式会社ビヨンド

WinSCPで多段階接続をする - 時雨に舞う

外部から踏み台サーバ経由の多段SSH接続をWindowsクライアントから行う | Developers.IO


| | コメント (0)

2018/08/28

Redmineにタグ機能を追加するパッチが投稿された

昨日、Marius BALTEANUさんがRedmine本家にタグ機能のパッチを投稿された。
次期Ver4.0で実現できたら、Redmineをより使いやすくしてくれるだろう、と期待している。
ラフなメモ書き。

【参考】
Feature #1448: Add tags to issues - Redmine

【1】なぜ、タグ機能が重要なのか?
それは、GitHub、Gitlab、Jiraなどの他のツールを見ればよく分かる。
Twitterのハッシュタグのように、「#○○○」を書けば、勝手にリンクできて、カテゴライズ化できる。
しかも、情報を探したい時に、タグで探しやすくなる。

(自動翻訳の引用開始)
私たちの問題の多くは複数のカテゴリにまたがっています。具体的には、単にカテゴリ以外のものよりも柔軟性のあるものを検索して管理したいと考えています。

問題にタグを追加する方法があれば素晴らしいだろう。
(自動翻訳の引用終了)

Redmineにタグ機能が欲しい、という要望は10年以上前からずっと言われていた。
そのため、熱心なユーザがタグ機能を実現するプラグインを開発してくれていた。
しかし、RedmineやRailsの度重なるバージョンアップに追随できなかった経緯もあった。

【2】ついに、Marius BALTEANUさんがパッチを投稿された。
そのコメントを読むと、Redmineユーザのニーズをすごく考えていることがよく分かる。

(自動翻訳の引用開始)
私は、プラグインhttps://github.com/ixti/redmine_tagsに基づいてRedmineにタグ機能を追加する作業を始めました(これまでの2年間で寄稿しました)。
私の計画は、第1段階で問題に簡単なタグ付け機能を追加し、機能がコアに承認/追加された後、他のエンティティ(ウィキ、プロジェクトなど)に拡張し、他のすべての機能を提案することです(バルク編集タグ、着色されたタグ)などがあります。

1.第1フェーズは、以下の2つのパッチで構成されています。

タグの追加/削除
タグの追加/削除タグの表示
タグの後にチケットをフィルター
チケット一覧の項目としてのタグ
タグ書き出し(pdf、csv)

添付されたパッチを使用してテストすることができます。
私はタグを管理する権限を持っているべきかどうか(私の見地からは、編集の権限は十分です)、何か他のものがなくなっていて、それがこの第1段階にあるはずなのかどうか疑問に思っています。

2. JSライブラリを追加してUIのタグを処理する(オートコンプリートを含む)添付のパッチでは、Jean-Philippe LangがSelect2をコアに追加したくないことを知っているのでSelectize.jsを提案します。
プラグインによって使用されることはもはや維持されません。
パッチは準備ができていませんが、私はこのライブラリを使用できることを最初に確認したいと思います(他の提案は歓迎です)。
また、プロジェクトからオートコンプリートでタグを提案する必要があるかどうか確認する必要があります。
プロジェクト階層、サブプロジェクトから)。

この機能は、Redmine.orgのチケット投票数のリストで1位にランクされ、120人以上のウォッチャー(この問題で80件、#2897で45件)、複数のコメントと関連する問題があります。
また、プラグインは、タグ付け機能がコアの一部である場合に役立ちます。
Redmine 4.0.0の後の次のバージョン(これはほとんど準備が整っています)でこれを行い、それを提供したいと思います。
(自動翻訳の引用終了)

【3】要約すれば、タグ機能が重要な理由は、2つある。
一つは、Redmine.orgのチケット投票数のリストで1位にランクされ、10年以上前からユーザの要望がチケットに記録され続けてきたこと。
もう一つは、タグ機能がRedmineチケットのカテゴリの代わりの機能になり、検索する時にも役立つこと。

Twitterのハッシュタグに慣れている人は多いだろうから、この機能が追加されることで、より多くのユーザがRedmineにチケットやWikiに情報を書き込むメリットを感じやすくなるだろう。
それら情報は、タグでカテゴライズでき、検索しやすくなるからだ。

このタグ機能も、Ver4.0またはVer4.1で取り込まれるといいなと思う。

また、Redmineの添付ファイルを全文検索できるパッチもVer4.1にセットされており、trunkにマージされることをユーザは待ち望んでいる。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

タグ機能と合わせてリリースされたら、Redmineユーザにとっても待ち遠しいと思う。
今後も、Redmine本家の動向はチェックしておく。

| | コメント (0)

2018/08/19

モデリング技術の習得とモデリングツールの習得は表裏一体

1ヶ月前に、関西IT勉強会で「ITアーキテクチュアのセオリー」出版記念講演に出て、データモデリングの話を聞いてきた。
その講演者から、赤俊哉さんをお手本にしている、という話があり、赤俊哉さんの書籍をいくつか読んでみて、感じたことをメモ。

【ITアーキテクチュアのセオリー】出版記念講演<第64回IT勉強宴会in新大阪> | IT勉強宴会blog

赤俊哉さんの本「SE職場の真実 どんづまりから見上げた空」という本を読んだ。
著者が派遣プログラマ、ユーザ企業の社内SE、そしてユーザ企業のCIOへ築き上げたキャリア遍歴の話がメインで、自分の経験を振り返りながら、そうだなあ、と頷いていた。
その本の中で興味を惹いたのは、業務システムのリプレースの時に、有償の設計モデリングツールXupperに出会い、データモデリングを興味を持ち、データモデリングの技術習得に努め、業務システムの設計情報をXupperのリポジトリに集約させた事で、プロジェクトが成功した、という話があった。

Xupperとは? | 製品情報 | XupperII

Xupperの製品は僕も詳しくは知らない。
しかし、SoRのようなレガシー業務システムの設計情報をDOAモデリングツールのリポジトリに集約することの意義について、色々考える所があった。

SoRのような業務システムでは、どうしても上流工程の設計技術が起点になると僕は思う。
すると、DFD・ER図・CRUD表というDOAの3種の神器のような設計資料がどうしても必要になってくる。
なぜなら、業務の流れをつかむためにDFDが必要だし、データの構造をつかむためにER図が必要だし、仕様変更の影響範囲の調査やテスト設計のためにCRUD表が必要になるからだ。
しかし、それら設計資料をExcelドキュメントで手作業で作り出すのは正直面倒だ。

そこで、例えばXupperのようなモデリングツールが威力を発揮する。
設計情報がモデリングのリポジトリに一元化されていれば、そのリポジトリから、DFD・ER図・CRUD表は最新状態で出力でき、その内容を元に設計作業を効率化できる。
特に、仕様変更の影響調査では、設計情報が三位一体となったモデリングツールがなければ、システム保守でどんどんコストが増加していき、業務システムが経営環境の変化についていけなくなってしまう。

そういう観点では、DOAをマスターする事とモデリングツールを使いこなす事は表裏一体ではないか、と思う。
つまり、データモデリングを理解して自由自在に使いこなすには、モデリングツールがあればその成長速度を速められるし、他方では、モデリングツールを使いこなしていくうちにデータモデリングの技術を習得し、その作法に慣れていく、という側面があるだろう、と思う。

そういう背景やニーズが20年以上前からあるからこそ、最近、超高速開発という分野も脚光を浴びるようになったのだろうと思う。
僕は、超高速開発とは、データモデリングツールとそこから自動生成されたソースとそのシステムをシームレスにつないだもの、と思っている。
その本質は、モデリングツールで業務システムの設計情報をリポジトリ化できたからこそ、設計資料の出力だけでなく、システムの自動生成という所まで行えるのだ、という点にあるのだろう、と思う。

そんな事を考えると、モデリング技術の習得とモデリングツールを使いこなすことは表裏一体ではないか、と改めて感じる。
僕がUMLモデリングツールastahが好きな理由の一つに、そういう考え方を持っている事がある。

丁度それは、プログラミングの習得には、そのプログラミング環境の構築と習得が含まれていることと同じような気がしている。

【追記】
9/8土にastah関西の勉強会をやります。

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

| | コメント (0)

2018/07/05

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアに対する信頼度成長曲線の論文が面白い

「バグの潜在期間が長いほど修正時間が短い」ソフトウェアというものがあるという前提で、従来から研究されている信頼度成長曲線の理論を適用した論文が非常に面白い。
もし、この論文の指摘内容が実際のソフトウェア開発の現場に適用できるならば、そんなソフトウェアはアジャイル開発こそ向いている、と言えるし、アジャイル開発の有効性の範囲が特に最近は広がっている、という事実を補強できるのではないか、と思う。
ちなみに、この論文は@sakaba37さんから教えてもらった。

以下は、浅はかな理解の元でのラフなメモ書き。

【参考】
ソフトウェア・シンポジウム 2018 表彰論文

ソフトウェア・シンポジウム 2018 最優秀論文賞 [研究論文]バグ修正時間を考慮したソフトウェア最適リリース問題についての一考察

【1】研究論文の内容は、正直難しいです。
僕も細かな内容は分かってない。
しかし、言わんとする内容は、とても刺激的。

【2】従来のWF型ソフトウェア開発では、「バグ発見時間が遅いほど、バグ修正時間も長くなる」という前提で、いかにバグを早く発見して修正するか、さらに、バグを作り込まないように予防対策を行うか、という考え方が主流だった。

この発想は、製造業の源流管理ともマッチするので、日本のWF型開発では、上流工程や超上流工程でいかにバグを作り込まないように、漏れなく高品質なものを作って後工程に流すことばかり、考えるように仕向けられていた。

つまり、「バグ発見時間が遅いほど、バグ修正時間も長くなる」は正の相関関係を意味している。

【2-1】しかし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが存在するとしたら、どうなるのか?

もし、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアが世の中の大半を占めていたとしたら、今までの品質予防の対策ノウハウは無意味になるのではないか?
むしろ、バグなんか気にせずにいち早く作ってリリースして、ユーザの反応を見ながら修正していく方が効率的ではないのか?

つまり、「バグ発見時間が遅いほど、バグ修正時間が短くなる」ようなソフトウェアとは、アジャイル開発が適用できるソフトウェアと同一視できるならば、ソフトウェア開発はアジャイル開発に特化してしまえばいいのではないか?

すなわち、「バグ発見時間が遅いほど、バグ修正時間が短くなる」は負の相関関係を意味している。

【3】この論文では、信頼度成長曲線という古典的理論を使って、「修正時間を考慮した最適リリース問題」として置き直して、モデル上で理論的な計算を行っている。
確率分布を使った計算なので、細かい内容はきちんと追わないと理解したとは言えないので、僕はすぐには分かってないが、下記の結果は理解できた。

【3-1】「バグ発見時間とバグ修正時間の相関関係」について、いくつかの前提をおいた上で、モデル上で計算を行った結果は、4ページの「表 1. 最適リリース時刻と最小総期待費用」で説明されている。

ここで、α:相関関数なので、
α=+1:完全な正の相関
α=-1:完全な負の相関
になる。

また、総期待費用 C(T) 、最小総期待費用 C(T*)である。

その結果、αが+1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が増えていくので、「バグを放置していたら、修正コストは増えていくよ」というメッセージなのだと常識的に理解できる。

一方、αが0から-1に近づくほど、総期待費用 C(T) 、最小総期待費用 C(T*)が小さくなっている。
つまり、このモデルでは、「バグを故意に放置した方が、修正コストは最小になるよ」というメッセージを伝えている。
これは、従来のWF型開発における品質の源流管理という常識とは異なる結果だ。

【3-3】この結果は、反常識的で面白いが、「バグ発見時間とバグ修正時間の相関関係」の観点で読み直せば、ストーリーはよく分かる。
つまり、従来の源流管理重視の品質管理では、「バグ発見時間とバグ修正時間は正の相関関係」の前提で語っていたけれど、それはWF型開発しか頭にない人がそういう前提で語っているだけ、とみなせる。
「負の相関関係」の前提となるソフトウェアもあるのではないか?

常識で考えると「バグ発見時間とバグ修正時間は負の相関関係にある」ソフトウェアはすごく変だ。
なぜなら、バグを放置した方がバグを速く直せる、と言っているのだから。

しかし、MTBFを高めることに注力するよりも、MTTRを短くする方に注力するソフトウェア開発プロセスがあるように、「負の相関関係」の前提となるソフトウェアもあるはずだ。
たぶん、そのようなソフトウェアはアジャイル開発に向いているソフトウェアなのだろう。

アジャイル開発が問題点をすり替えた品質特性~機能性と信頼性: プログラマの思索

実際、昨今のWebサービス開発では、いち早くリリースして、頻繁にリリースしながら品質向上していく開発プロセスが主流だ。
何年もかけて品質を作り込んで、ドカンと一発リリースするソフトウェアとは全く違う。

もちろん、そういうコストを掛けて品質を高く保つソフトウェアもあるし、従来はそういうソフトウェアばかりだったように思う。
今でも、航空宇宙や組込みソフトウェア、業務システムはそういう部類に属するだろう。

しかし、従来は周辺的な位置付けに過ぎなかったWebサービスのマーケットが広がり、皆が24時間スマホを触っているのが普通な現代では、アジャイル開発に向いているソフトウェアが多くなった。

とすれば、アジャイル開発に向いているソフトウェアでは、「バグ発見時間とバグ修正時間は負の相関関係にある」という事実と表裏一体なのではないか。

【4】但し、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張は、僕個人の意見に過ぎない。
上記の研究論文でも、そこまで触れられてはいない。
しかし、上記の研究論文では、理論上そういうソフトウェアが存在する前提で、モデルから何が言えるのか、を示唆している。

自分のラフなイメージとしては、「バグ発見時間とバグ修正時間は負の相関関係にあるソフトウェアは、アジャイル開発に向いている」という主張が、上記の研究論文の発展形で保証できれば、アジャイル開発の有用性を証明できた、ということになる、と思う。

そのためには、実際のアジャイル開発の現場で、そのようなソフトウェアメトリクスを採取して、上記の研究論文の理論的検証が正しかった、という体験論文ないし実験論文が続編になればいいだろうな、と思う。

【5】信頼度成長曲線の理論は1970年代からずっと研究し尽くされていて、かなり枯れた理論と聞いているが、この研究論文では、アジャイル開発の要素を取り入れたモデルで考え直すと、古典的な理論から新たな知見が生まれる、という可能性を示唆している、と思う。
そういう意味では、久しぶりに自分の中ですごくホットになって、面白かった。

個人的には、「アジャイル開発はソフトウェア開発ですごく有効である」と証明できるソフトウェア工学の学術論文をもっと読んでみたいし、そういう論文集があると面白いだろうな、とも思う。


| | コメント (0)

2018/07/04

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグイン

Redmineでスケジュール調整や投票ができる「Scheduling Poll」プラグインを見つけたのでメモ。

【参考】
【担当者さん必見】メンバーみんなで日程調整ができる「Scheduling Poll」プラグイン登場!

cat-in-136/redmine_scheduling_poll: a plugin to provide the simple way to schedule appointments on Redmine

QA #824: チケットやニュース、フォーラム、Wikiなどで選択式のアンケートを実施したい - Unofficial Redmine Cooking - redmine.tokyo

画面を見てみると、調整さんのように複数のチェックリストに○△Xを記入した後、入力結果を自動集計してくれるみたい。

選択できるチェックリストには、日付以外にテキストが入力できるので、他のアンケート項目にも流用できるだろう。

時々、アンケート機能がRedmineにも欲しい、という声があがる時があるので、このプラグインを使えばいいかもしれない。

下記のLineの機能にインスパイアされて、Redmineプラグインを作成された、とのこと。

【幹事さん必見】友だちみんなで日程調整ができる「LINE スケジュール」機能登場! : LINE公式ブログ

こういう投票機能は、Redmineを単なるタスク管理、課題管理、障害管理だけでなく、チーム内のコミュニケーションを活性化させるためのツールへ進化させる為の機能と言い換えられる。

Rails開発の技術力があれば、自分のアイデアやプロジェクトリーダーの提案を元に、Redmineをカスタマイズすることにより、チームの一体感を生み出す機能をいくらでも作り出せる。

そういうアイデアを実現する機能とチーム内のコミュニケーションとの相関関係や影響度合いを実際に分析してみたいものだ。

| | コメント (0)

«Redmineにも「いいね」機能が欲しい