ソフトウェア工学

2018/02/04

第18回Redmine大阪の感想 #RedmineOsaka

第18回Redmine大阪の感想をメモ。
疲れているので、ラフなメモ書き。
書きかけなので、また後で書く。

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

2018/2/3 第66回 SEA関西プロセス分科会&第18回 Redmine大阪 - Togetter

第18回Redmine大阪のまとめ | MadosanPlace 新しい風をプラス!

【1】気象庁のRedmine利用事例の話は、本当に面白かった。
JAXAのRedmine運用とは、また別の観点の思想を持って運用されている。

第65回 SEA関西プロセス分科会&RxTStudy #15 「チケット管理システムによるプロセス支援と今後の課題」の感想: プログラマの思索

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT: プログラマの思索

気象庁内のシステムには、天気の予測シミュレーション、PM2.5やら色んな気象データのデータ収集と分析、シミュレーションなどがある。
それらのシステムは、全て内製化されている。
つまり、気象庁の研究者がプログラマとなり、実際に開発している。
この点は、JAXAなど他の官公庁とは全く違う。

だから、気象庁では、数値予報官という役職だけでなく、「プログラマ」という名前の役職も公式に存在する。
この点も他と大きく異なるのだろう。

【1-1】気象庁内では、Fortran、シェル、Rubyが一般的なプログラミング言語。
数値予測などの科学計算は過去の開発資産があるので、Fortranが使われている。
一方、仮想サーバー構築、バッチ処理、インフラ構築などは、シェルとRubyがよく使われている。

【1-2】気象庁では、部署もあるが、開発はシステムごとに、各部署を横断してプログラマや研究者が集まって担当する。
そのシステムに携わる集団を開発コミュニティと呼ぶらしい。
僕の理解では、マトリクス型組織のように思えた。
つまり、研究者やプログラマは部署に所属するが、天気予報、シミュレーション、共通基盤などの各システムの開発に携わるので、クロスファンクショナルなチーム構成になる。

但し、プログラマはどこか一つのコミュニティに属する運用になっているので、複数のコミュニティに所属することはほとんどない。
つまり、各開発コミュニティは縦割り組織に似たような雰囲気になっているみたい。

【1-3】最近は、欧米の気象庁ではPythonを使って数値予測プログラムを書く事例が多くなってきたので、彼らから、なぜまだFortranを使っているの、Pythonなら他言語のライブラリや資産も簡単に呼び出して使えるので、Pythonがいいよ、と言われているため、Pythonをこっそり試し始めている、とのこと。

この辺りの話を聞くと、海外の研究動向にも追随しながら、最先端の技術を導入しようという雰囲気が既にあるのだろう。

【2】気象庁では、各開発コミュニティごとに「あえて」Redmineインスタンスを複数個立ち上げた意図

バージョン管理は、2000年代からCVS、Subversion、Gitへ移行してきた。
2008年頃から、各コミュニティが独自にTracやRedmineを使い始めた。
原さんが海外の動向を踏まえて、各開発コミュニティがバラバラな開発基盤を持つのではなく、共通の開発基盤で運用すべきだ、と提案して、2014年頃から、RedmineとSubversion、Gitを共通の開発基盤として各コミュニティに提供する運用になったらしい。

その時、1台の物理サーバーに1個のRedmineインスタンスで運用する案も考えられたが、一つのRedmineの運用ルールに縛ることを目的とすると、各開発コミュニティから反発が起きるかもしれないことと、各開発コミュニティの組織文化を尊重することも考慮して、複数個のRedmineインスタンスを各開発コミュニティごとに立ち上げることになったらしい。

【3】2段階コードレビューの意図

【3-0】Redmineを導入した動機

そもそも、RedmineやSVNを開発基盤として導入しようという契機になったのは、コードレビューをしっかりやるべきだ、という考え方が、原さんだけでなく、各開発コミュニティでもそのような気運が盛り上がっていたから。

たとえば、天気予報の数値予測シミュレーションのようなプログラム開発では、理論物理や流体力学など科学理論から導かれる機能要件から、それに基づくプログラム実装が行われる。
しかし、かつてはバージョン管理すらなかった時代では、なぜそのような機能が実装されたのか、なぜそんなソースコードになったのか、記録が残っていない。
しかも、科学理論の発展やソフト・ハードの進化に伴うプログラム修正の履歴やその変更理由も残されていない。
だから、システムのリリース後に障害が発生して、トラブルが起きることがあったから。

【3-1】2段階コードレビューの意図

Redmineではコードレビューのプロセスはワークフローの一部として運用されている。

興味深い点は、気象庁のコードレビューでは、2段階レビューが踏まれていること。
まず、サイエンティフィック・レビューでは、科学者の観点で、数値シミュレーションが物理法則や物理の理論に基いた要件でコードが実装されているか、レビューされる。
おそらく、研究者同士の議論に近い雰囲気なのかもしれない。

次に、ソースコードがプログラミングの観点できちんと書かれているか、という立場でコードレビューされる。
Fortranのコーディング規則に従っているか、エラー処理、とか、この部分は我々のコードレビューと同じだろう。
また、物理法則の要件に従って実装されたプログラムを、実際に膨大な気象データに基いてシミュレーションするテストも行う。
このテストには、半日で終わることもあれば、数週間かかることもあるらしい。

たとえば、そこで性能が出なかったりすることが分かれば、その要件の実装はソフトウェア的に実現可能性が低いので、別の代替案を考える、などのフィードバックがコードレビューで行われる。

つまり、単なるコーディング規約のチェックだけでなく、たとえば性能要件を満たすかテストしてみた結果をフィードバックする、などの作業も行われている。

この辺りは、アーキテクチャのフィージビリティ・スタディ、つまり、アーキテクチャ実装のコスト・品質・納期のトレードオフを評価しているのと同じように思える。

これら2段階レビューは、既に欧米の気象庁では行われているので、日本でもやるべきだ、という提案があり、徐々に浸透しているらしい。
そういう内容を聞くと、Redmineチケットにコードレビューの結果を記録し蓄積していくことは非常に有意義な作業であることが理解できる。

【3-2】そして、git-flowによる並行開発とコードレビューが組み合わされて、上手く運用されるようになっているらしい。
つまり、ある要件を開発する場合、trunkからブランチを派生し、そのブランチ上で修正して、コードレビューが完了になれば、trunkにマージされる。
そのブランチはRedmineチケットと対応付けられて、Redmineチケットに要件や仕様、コードレビューの結果などが全て記録される。

【3-3】気象庁のRedmineでは、チケットのカスタムフィールドは使わないし、複雑なワークフローも設定されていないし、プラグインもほぼない。
Redmineのチケットに、コードレビューの指摘、結果、対応の記録を残すことに注力している。
そのおかげで、海外派遣で2年間、気象庁から離れた研究者も、帰国した後、Redmineのチケットを検索するだけで、すぐにプログラム開発の仕事に復帰できた、と言っていたらしい。

つまり、気象庁のRedmineは、進捗管理用のRedmineではなく、ナレッジ資産の為のRedmineなのだ。

【4】複数個のRedmineインスタンスで運用されるデメリットは、原さんによれば特に感じていない、と言われていた。
もし、他コミュニティのRedmineを参照したい場合、RedmineにはRSS機能があるので、RSSをフィードすれば、リアルタイムにチケット更新の状況を把握できる。

【4-1】また、Redmineという開発基盤が普及した後、Redmineの副次効果がいくつかあったらしい。
たとえば、あるコミュニティで、コードレビューはプログラム実装後に行うのではなく、プログラム実装前に関係者が集まって事前に内容を協議する運用を始めた所、他コミュニティでも、その運用はもっともだ、という意見があり、他コミュニティにも徐々に反映されたらしい。

つまり、あるコミュニティのRedmineのベストプラクティスが他コミュニティにも自然に横展開された、という事実を示唆している。

また、気象庁がいくら先進的な官公庁であっても、やはり役所なので縦割り組織の雰囲気がある部分はある。
しかし、Redmineを利用することで、コミュニティ内では、チケット経由のやり取りによって、研究者の知見やソース修正の履歴が記録されて、メンバー間の情報共有がスムーズになったらしい。

【4-2】さらに、データ処理など共通の処理を行う基盤担当のコミュニティがあり、そのコミュニティは気象庁の各コミュニティと関係するが、そのコミュニティのメンバーは、各コミュニティのRedmineにログインできる。
すると、各コミュニティでRedmineやコードレビューの運用ルールが微妙に違うので、同じように運用したい、という声が上がっているらしい。

つまり、現状はあえてコミュニティ単位の複数Redmineインスタンスで運用しているけれど、現場から、ボトムアップでRedmineの標準化を図るべきだ、という声が上がっているわけだ。
将来は分からないけれど、いつか、単一の標準Redmineにサーバー統合される可能性があるかもしれない。

【4-3】この点に関して、参加者からは、Redmineではトラッカーやカスタムフィールドがグローバル変数のような性質のために、使いづらくなっている。
Redmineにも、サイトのような機能を持たせて、各プロジェクトごとのトラッカーやワークフローを定義できるようにすれば、一つのRedmineインスタンスで、各プロジェクトごとにトラッカーやワークフローの自由裁量の権限を与えて運用できるのではないか、という指摘があった。
この意見は全くその通り。

以前も、東京Redmineでも似たような議論があった。

Redmineのワークフロー設定を拡張する機能提案~Redmineは汎用的なBPMツールになりうるか: プログラマの思索

【4】個人的には、Redmineは単一インスタンスの運用だけでなく、複数インスタンスの運用もベストプラクティスの一つになりうる、という発見があって、改めて深く考えさせられた。
この点はまたまとめる。

akipiiさんのツイート: "#RedmineOsaka #seakansai 気象庁の事例ではRedmineをナレッジ基盤として使う運用を目的としたら、色んな副次的効果も出てきた。単一の標準Redmineがベストの先入観があったけど、Redmine の複数インスタンスでも成功事例があるのは改めて衝撃を受けた。奥が深いね。"

【追記】
今回のRedmine大阪で、気象庁における開発管理の取り組みの公開資料に基いて、Redmineのチケット管理やGitによるブランチ管理やコードレビューについて数多く質問したのだが、「テストハーネスを用いたテスト自動化」の内容は聞き漏らしてしまった。
おそらく、Fortranプログラムをシェルからバッチで起動して、入力データと出力データを差分比較するようなテストを自動化する仕組みを取り入れていると思われる。
この部分のノウハウも聞きたかった。

気象庁における開発管理の取り組みの公開資料のP.52で下記の引用がある。

(引用開始)
asuca については、トランクへの変更がなかった場合も含めて、テストハーネスと呼ばれる仕組みを毎日自動で実行している。
これは
・ 理想実験
・ 石田ほか (2014) で述べられている、2 次元定常山岳波、周期境界条件における重力波、暖気塊のテスト、重力流、St-MIP
・ 静止大気実験
・ 2 次元スカラー移流
・ 3 次元モデル 3 による狭領域実データ実験
・ 局地解析
・ 接線形モデルチェック
・ 随伴モデルチェック
・ 局地予報
・ メソ予報
といった様々なケースについての実験 4 が、最新のトランクを用いて行われる。
入力データは毎日同じものを用いるため、入出力システムの変更等、予報結果を本質的に変える変更でない場合には、結果はビットレベルで一致する。
自動実行されたテストハーネスの結果は毎日メールで報告され、結果が前日とビットレベルで合わない場合にはそのようなメッセージが付加され、開発者が覚知することができる。
このため、トランクへのマージを行う改変については、テストの段階で開発者が自らテストハーネスを実行し、その結果についてもチケットに記録する。
また、変更の前後で結果が一致しない場合には、その理由や差の妥当性(分布図で見た場合の評価等)も含めて、記録を行う。
(引用終了)

| | コメント (0)

2018/01/27

開発プロセスを管理することでしか、ソフトウェアの品質は管理できない

ネットでフラフラしていたら、偶然良い記事を見つけたのでリンクしておく。
特に主張は無し。
ラフなメモ。

【参考1】Embedded Software Manufactory: ISO 26262との向き合い方 (21) 安全について理解を深める

【1-1】「開発プロセスを管理することでしか、ソフトウェアの品質は管理できない」という文言にしびれた。
ああ、そうなのか。
自分がRedmineにハマっている理由は、たぶん、Redmineを通じて開発プロセスをモニタリングすることで、ソフトウェアプロダクトの品質・コスト・納期を調整しようと暗黙的に行っていたから、と思う。

でも、プロセスアプローチの発想は、アジャイル開発とは異なる。
アジャイル開発は、プロセス重視ではない。
では、その部分はどう解釈するべきか?

(引用開始)
しかし、何もしないで放っておく訳にはいかないので、ソフトウェア開発プロセスによるアプローチを定義することになる。これは現在のところ、どの業務ドメインでも同じようだ。開発プロセスを管理することでしか、ソフトウェアの品質は管理できないというのが、ソフトウェア品質論の定説となっている。(『ソフトウェア品質論の歴史的推移』を参照されたし)
(引用終了)

【1-2】IT業界では、新しい技術や設計思想は、熱意を持った人がエバンジェリストとして普及させる必要がある、という経験則があるのだろう。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン」の最初にも「エバンジェリスト」があったなあ、と気づく。

(引用開始)
そして今では、安全とは何かについての考えが深まっていない人々に対して、どうすれば安全の概念についての考えを深めることができるのかを伝えることが自分の責務だと考えるようになった。
(中略)
Microsoft の社員の肩書きで Evangelist(エバンジェリスト:伝道者)というのを見たことがあるだろう。上に書いた役目は Journalist とか、Consultant ではなく、Evangelist が一番ぴったりくるかもしれないと思っている。
宗教じゃないから伝道という言葉はあまり好きではないが、人間はコンピュータのように常に論理的とは限らないから、熱意を持って伝えないと伝わらない。自然科学ではない、ソフトウェアに対する考え方は、説明ではなく伝道でないと伝わらないことを Microsoft はよく分かっているから、その道のエキスパートに Evangelist を名乗らせているのだと思う。(洗脳者のような胡散臭い感じもするが・・・)
(引用終了)

【参考2】Embedded Software Manufactory: ソフトウェア品質論の歴史的推移

(引用開始)
「不良をなくすことが、究極的な品質の実現である」とする考え方は、古典的な統計的品質管理を極端に形式化した観念論的な品質論である。
「良いプロセスが実践されているからこそ、良い品質が生み出される」と考えるのがプラグマティズム的品質論。
「当たり前品質」と「魅力的な品質」の相対概念は高度に先験的で観念論的な日本的品質管理の概念である
(中略)
この新しい品質論は、グローバル化経済において、究極の品質論のように見える。
「民主主義的原理に基づく品質論」
「品質概念の本質は、製品やサービスの存在目的に基づき、ユーザから見た利用目的の達成度に関する評価である」とする。
評価対象としての製品のサービスの性質と、評価時点における市場のユーザニーズ(利用目的)への適合性(利用目的の達成度)によって決定される。
同じ製品やサービスであっても、評価の時点が違えば、その品質評価は変化する可能性があることを意味している。
「民主主義原理に基づく品質論」はソフトウェア品質評価法に代表される観念的品質論とCS運動における顧客満足に基づく品質改善を基礎とするリバタリアニズム的品質論を融合するものになる。
(引用終了)

製造業の品質管理技法は、いわゆる古典的な統計的品質管理が発端らしい。
つまり、量産品のバラツキを統計的手法によって原因分析して解決し、不良率を減らす。
日本が得意。

一方、プラグマティズム的品質論は、「良いプロセスが実践されているからこそ、良い品質が生み出される」と考える」。
この発想を元に、プロセスを国際規格として定めて、トップダウン・アプローチで形式知として実現したものが、ISOなどの各種規格。
今の日本は、このやり方がグローバル・スタンダードになったために、すごく苦労している。

さらに、「民主主義的原理に基づく品質論」はマーケティング3.0または、アジャイル開発を連想させる。

しかし、日本の品質管理でも、製品ライフサイクルによって、狩野モデルにある「魅力的品質」から「一元的品質」「当たり前品質」へ品質が変化する、ということも既に指摘されていた。
この辺りの整合性はどう取るのか?

【参考3】Embedded Software Manufactory: 機能安全の意味がわかった(IEC61508とISO26262の最新情報)

最近よく聞く「機能安全」とは、安全装置が保証する安全に関する機能、という思想があるわけか。
そうならば、すごく理解しやすい。
最近は、IPAも組込安全規格に関して、盛んに研究しているしね。

(引用開始)
機能安全の説明でよく踏切の例が挙げられる。踏切ではなく高架橋を作ることによって通行者の安全を確保するのが本質安全で、踏切という安全装置によって安全を確保するのが機能安全。
(中略)
機能安全の規格は安全装置によって安全を確保する狭義の Safety という意味合いが強いということがこの記事を読んでよく分かった。本質安全に対する安全装置による安全(=機能安全)と考えると非常にすっきりする。
そして、安全は安全装置の設置という狭い考えではなく、システム全体を踏まえた包括的な安全性の実現を考える必要がある。
(引用終了)

【参考4】Embedded Software Manufactory: ISO 26262との向き合い方 (6) 機能安全のマネジメント2

【4-1】現代のソフトウェア開発では、ITS、SCM、CIツールの3つが使われるのは当たり前。
その効果は、変更管理や構成管理がツールで制御できるようになったこと。
今後の課題は、要件管理である、という主張。

(引用開始)
変更管理や構成管理はここ10年で浸透した。要件管理はこれからで、ISO 26262 への適合がトリガーになって、導入が進むのではないかという内容だ。
(中略)
構成管理や変更管理が日本でも受け入れられているのは、 構成管理や変更管理がボトムアップの開発にも十分に役立つからである。同じように要件管理ツールも普及すると思ったら大間違いだと自分は思っている。(構成管理や変更管理のボトムアップでの組織への浸透については『リコールを起こさないソフトウェアのつくり方』の二章にやり方も含めて詳しく書いた。)
(引用終了)

【4-2】日本発祥の開発プロセスであるXDDPは、特に派生開発で有効。
その理由は、日本人に合うボトムアップ・アプローチによる変更管理をコントロールできるから。

(引用開始)
日本では問題が分かったときの修正のスピードが速い。デグレードはゼロとは言えないが、とんでもない見落としは少ない。それは、品質を心配する意識: Awareness: Worrying about Quality の力ではないかと思っている。(これうまくいかず品質に悪影響を与えるケースが増えており、変更の影響を分析、管理しながら変更を実装していく XDDP という取り組みが今話題になっている。)
(引用終了)

【4-3】安全が確保されている証拠、機能安全の規格を満たしている証拠として、トレーサビリティマトリクスがある。
そのトレーサビリティマトリクスを作成・維持するために、要件管理ツールの存在意義がある、という主張。

(引用開始)
その状態を回避し、ユーザーの期待(安全は当たり前に確保されているはず)に答えるには、安全に対する要求と、その実現方法、実現の結果(証拠)を常にトレースが取れるようにしておく必要がある。そのトレースのセットがトレーサビリティマトリックスとなる。
要件管理ツールはこのトレーサビリティマトリックスを保持するための助けとなる。
(引用終了)

【参考5】Embedded Software Manufactory: ISO 26262との向き合い方 (1) 最初に読んで欲しいこと

著者がISO 26262 にこだわっている理由を経験談を元に書かれている。
「「自分はキチンとやっていたが、組織的な品質システムとして実施されたものではない」という状態」だったから、米国での製品販売が止められた。
著者は、当初、理由が分からなかった。
きちんとやっているのに、なぜ差し止められるのか。

しかし、後に著者は理解する。
「個人が自分の考えで実施している検証は品質マネジメントに基づいたものではないローカルルールで行われものであるため認められないのだ。」
つまり、世界標準のやり方でないと通用しない世界がある。
その背後には、プロセスアプローチ、プラグマティズム的品質論の考え方がある。

| | コメント (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企業が大手の下請けに依存しない受託ビジネスを行う時、アジャイル開発の手法が最強の道具になるから、という@sakaba37さんの意見があって、すごく納得した。

実際、日本の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/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/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/11/19

第13回東京Redmine勉強会の感想~『Redmineの今と未来』 #redmineT

昨日の勉強会は参加者、スタッフの皆さん、お疲れ様でした。
あいにくの雨にもかかわらず、参加率が約90%で大変盛り上がりました。
楽しかった余韻が冷めないうちに、感想をラフなメモ書き。

【参考】
第13回勉強会 - redmine.tokyo

第13回勉強会 - redmine.tokyo ~『Redmineの今と未来』(2017/11/18) #redmineT - Togetterまとめ

redmine.tokyo 第13回勉強会 - connpass

“CODA” チケット管理システム | JSS2@JAXA

【1】数多くの参加者に感想を聞いた所、JAXA様の講演が聞きたかった、という話もあったが、LTも含めて運用事例からプラグイン開発などの技術、最新バージョンの紹介、ちょっとしたプラグインの利用事例、家庭内のRedmine利用事例など、幅広いテーマで面白かった、という話があった。
また、参加者層も初心者から10年近い利用者まで、年代層も20歳から40代まで幅広かった。

akipiiさんのツイート: "#redminet 今日も参加率90%で驚異的でした。利用事例から技術まで幅広いテーマで面白かったと言う声をたくさん聞けてスタッフ一同嬉しいです。参加者層も初心者より数年経験者の人が半数以上いた。Redmineコミュニティが今後も長続きできるといいなと思う。"

さらに、女子の参加が10名を超えたのも初めてではないかと思う。(正確に数えてない)

akipiiさんのツイート: "#redminet 今日の東京Redmine 勉強会は過去最高で女子率が高くて華やかだったと思う。以前、@agilekawabata さんが、Redmine はおっさんのツールだから若い人や女子は少ないんですよ、と言ってたが、時代が変わった?"

第7回Redmine.tokyoの感想 #redmineT: プログラマの思索

そんなことを振り返ると、多種多様な年齢層や女性という人口的変数、プロジェクトリーダーだけでなくSEPG等の品質保証部の人からプラグイン開発者までの心理的変数というセグメントが幅広くて、たくさんの化学反応があって面白かったと思う。
幅広い利用者が集まるコミュニティになれば、ある人はRedmineを使っているなら常識と思っていても、他の人にとっては新鮮な内容であることも多いだろうから、そういう数多くの議論が発生して、さらに理解が深まるだろうと思う。

たとえば、Redmineのそんな所でつまずくのか、という質問が、実はRedmineというツールではなく、プロセス保証やプロジェクトマネジメントの根本的な問題に触れていたり、とか。
僕も色々気づきがあった。

【2】JAXA様の利用事例で、興味深い点は二つある。

“CODA” チケット管理システム | JSS2@JAXA

【2-1】一つは、フローの管理とストックの管理を明確に別々に分けていること。

akipiiさんのツイート: "#redmineT JAXAでは、議事録はチケット、構成管理すべき文書は、文書管理機能、実際はDMSFプラグインで管理を区別してる。フローの管理はチケット管理、ストックの管理は構成管理ツールでなく文書管理プラグインで制御してる。全文検索プラグインで文書も全文検索できると、かなり良… https://t.co/AVf8WAHtsc"

Redmine本来の設計思想では、日々流れるフローのような管理対象はチケットにする。
タスク、かんばん、ISOの変更依頼書のように、作業指示書のようなレベルのものは、ステータス管理の方が重要だ。
つまり、日々のフローで管理する時、担当者とステータスに着目する。

一方、ストックのような管理対象は基本は、GitやSubversionのような構成管理ツール、あるいはWikiに蓄積する。
たとえば、ソースコードやExcel設計書は構成管理ツールの配下で履歴管理したり、技術や共有情報などのナレッジはWikiに蓄積する。
あるいは、チケットそのものを議事録にしたり、障害管理票のようにチケットに障害の発生原因や修正履歴を追記して、チケットそのものをナレッジにしてもいい。

Redmineのメリットは、フローとストックの管理を一つのツールで一元管理できるので、フローとストックの間で相互リンクを貼ることにより、トレーサビリティを実現できることだ。
よって、成果物から要件の発端まで前方追跡して変更理由を探したり、発端となった要件から成果物まで後方追跡して仕様変更の影響範囲を探る、といった使い方ができる。
この運用ルールが「No Ticket, No Commit」であり、他のプロジェクト管理ツールにないチケット管理ツール特有の最大の特徴でもある。

しかし、JAXA様の運用では、ストックの管理はRedmineの文書管理にDMSFプラグインを入れて活用されている。
この点がRedmine本来の設計思想と大きく異なる。

その理由を推測すると、成果物の対象がExcelであるため、構成管理ツールだけでは文書の変更の権限制御がやりにくい点があるのだろう。
そこで、DMSFプラグインを入れることで、Excel文書の変更履歴を残したり、Excel文書の参照・更新の細かな権限制御を付けることで、より使いやすくしているわけだ。

たとえば、外部委託したベンダーには特定のExcel文書は参照権限はあるが、更新権限は与えない、といった使い方をしたい場面があるのだろう。

【2-2】もう一つは、Redmineではボトムアップで運用ルールを柔軟に変更して、より良くしていく手法がある点。
Redmineは管理画面にあるワークフロー、ロール、トラッカー、カスタムフィールドを細かく制御できるので、運用しながら標準プロセスを固めていくことも可能だし、そういうやり方の方が普通なのではないか。

akipiiさんのツイート: "#redmineT Redmine の良さは、管理機能をフレキシブルに変更できる点。実際の運用は、かなり試行錯誤した、とのこと。プロセス標準化は一夜にしてならず、ですね"

akipiiさんのツイート: "#RedmineT 更新ロールと参照ロールに分ける。基本ワークフローは、全般トラッカーと名付けて、プロジェクトごとでカスタムフィールドを切り替えて利用する。つまり多様なプロジェクトの構造を管理画面の機能で制御するわけだ"

たとえば、Redmineの基本ロールは「PJ管理者」「開発者」「報告者」だけだが、実際に運用してくると、PJ管理者とシステム管理者の間のロールが欲しくなってくる。
その場合、「ロールのORルール」を用いて、「システム管理者でない管理者」のロールを新規作成し、各プロジェクトで各ユーザにそのロールを追加付与すればいい。
すると、既存のロールをいじることなく、既存ロールにパッチを当てる感じで、権限を細かく制御できるようになる。
たとえば、基本ロールと追加ロール、参照ロールと更新ロールのようにロールを細かく作っておけば、ロールのORルールを適用して、数多くのバリエーションで権限制御できるようになる。

すなわち、運用で試行錯誤しながら、ロールやワークフローを再定義したい時に、Redmineではパッチを当てる感じで既存の運用フローを修正していくことが可能なのだ。
こういう運用が可能な理由は、Redmineの管理画面の機能が豊富で柔軟であるからだろう。
換言すれば、Redmineの豊富で柔軟な機能をもっと理解しておけば、最初からトップダウンで完璧な運用を目指すのではなく、運用しながら標準プロセスを固めていく、といった、アジャイル的な発想を取り込めるはずだ。

僕はアジャイル開発が好きなので、ソース修正だけでなくプロセス構築にもアジャイル的なやり方を組み込むことは、実現不可能と思っていないし、むしろ、トップダウンでガチガチに固めてしまってメンバーのやる気を失わせるよりも、メンバーのより良い意見を取り入れながらチーム一丸でRedmineをより良く使いやすくしていくことは可能だと思っている。

【3】前田剛さん、堂端さんからRedmineの次期バージョン4.0に関する講演があり、興味深かった。

Redmineウォッチャーとしては、Railsの最新バージョンに追随する形でRedmineもどんどん最新化して欲しい。
性能面、セキュリティ面、今後の機能追加のしやすさ、を考慮すれば、開発基盤の最新バージョンに追随して欲しいから。
講演によれば、Ver4.0は早めにリリースしたい、とJPLが言っていた、とのこと。

Ver4.0で問題になってくるのは、既存プラグインがそのままでは、ほぼ使えなくなることだろう、とのこと。
Rails5に追随できるようにプラグインの修正が必ず発生する。
過去のRedmineのバージョンアップでも、追随できなかったプラグインは数多くあったので、利用ユーザは注意すべきだろう。

前田剛さんのアドバイスでは、古いRedmineはあらかじめVer3.4へVerUpしておくべきこと。
理由は、Rails5ではRuby2.2.1未満は切り捨てられるので、Ruby2.2.1に対応済みのVer3.4のRedmineで動作できるようにしておくと事前に検証できるから。

【4】他の講演も面白かった。
Redmineの利用が深まる中で、色んな問題意識があげられていて、興味深かった。

RedmineとSlackなどのコミュニケーションツールは、どのように使い分けた方がいいのか?

お子さんの宿題管理にRedmineを適用し、EVMや分析を行ったが結局使いこなせなかった、とのこと。
このLTも、普段のRedmineとは違う観点で面白い、という別の参加者の感想もあった。
個人的には、Redmineが使いこなせなかった理由には、Redmineが見れるPCをお父さん部屋しか置かず、子供の導線上で見える化しなかった点もあるのでは、と思った笑。

akipiiさんのツイート: "お母さんの反省点はRedmineが見れる端末を廊下と子供部屋に置くことかな笑。RT @agilekawabata: お母さんの反省会で導線が大事だったということで、JAXAの事例にもあったように、ホーム画面に担当者が必要となる導線を置くことはとてもいいと思う #redmineT"

【5】Redmineの面白さは、プロジェクトリーダーや品質保証部の観点でプロセスを自分で構築できて運用を試せる一方、プログラマの観点で不足機能をカスタマイズしたりプラグイン開発してより使いやすくできる、という両面があることだろうと思う。

すなわち、前者の観点では、Redmineは標準プロセスの運用基盤またはメトリクス収集・集計のプロセス基盤である一方、後者の観点では、Redmineはプロジェクト管理ツールの汎用的な開発基盤とみなせることだ。
つまり、ソフトウェア工学の観点とRuby開発の観点の両面からRedmineをいじくり倒せる点が、面白い点なのだろうと思う。
そして、その両方に詳しい人はほとんどいないので、Redmineコミュニティで多種多様な人達が集まることで色んなメリットが出てくる。

僕もRubyやRailsをちょっとずつ勉強しなくては、ね。。

他の資料はコチラ。

| | コメント (0)

2017/08/20

セマンティック・バージョニング、チームの依存関係のメモ

セマンティック バージョニングのルールについて、改めてメモ。
主張のないラフなメモ書き。

【参考】
セマンティック バージョニング 2.0.0 | Semantic Versioning

「セマンティック バージョニング」を読んだのでバージョニングについてまとめた - Qiita

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jp

Ruby 2.1.0 以降のセマンティックバージョニングについて

【1】(引用開始)
バージョンナンバーは、メジャー.マイナー.パッチとし、バージョンを上げるには、

APIの変更に互換性のない場合はメジャーバージョンを、
後方互換性があり機能性を追加した場合はマイナーバージョンを、
後方互換性を伴うバグ修正をした場合はパッチバージョンを上げます。

プレリリースやビルドナンバーなどのラベルに関しては、メジャー.マイナー.パッチの形式を拡張する形で利用することができます。
(引用終了)

(引用開始)
例えばVersion 3.2.1の場合、メジャーバージョンは3、マイナーバージョンは2、パッチバージョンは1ということになります
(引用終了)

【2】ソフトウェアはハード製品とは違って、バージョンの依存性関係の管理がすごく重要だ。
特に、OSやミドルウェア、ライブラリのバージョンが違うだけですぐに動かなくなる。
また、バージョンアップの頻度も多いのが普通なので、ライブラリのバージョンアップを追随するのにも結構労力がかかる。

一方、バージョンアップしないライブラリは、進化していないので危険。
たとえば、最新のセキュリティパッチが考慮されていない場合もあると、すごく危険。

僕は、どの開発プロジェクトであっても、そこの構成管理の運用ルールをまずは見る。
ソース管理やビルド管理だけでなく、設計書の版管理はどのようにタグ付けされて、リリースバージョンとしてリリースされるのか?

構成管理はソフトウェア開発プロセスの基本であるが、意外に運用がまちまちだったりする。
今でも、リリース管理台帳というExcelで、リリースモジュールとバージョン番号を記録して、初めてリリースできる運用を行なっている所も多いのではないか。

すると、Excelのリリース管理台帳がロックされて書き込めない、リリース管理台帳が最新化されていない、リリース管理台帳そのものの履歴管理ができてないのでデグレした、とか、諸々の問題点が色々出てくる。

【3】また、バージョンのネーミングルールも重要だ。
メジャーバージョンとマイナーバージョンの違いを認識せずに、何となくナンバリングしていないか?

t32k、怒られる!セマンティック バージョニングしてますか? | HTML5Experts.jpでも「『いっぱい変更したのでメジャーバージョン上げてみるか』、『今回の修正は軽微なものだし、マイナーバージョンを上げるか』」とバージョニングしていたら、ロシアのサンクトペテルブルク在住の青年エンジニアに怒られた、という内容があった。

(引用開始)
彼の言い分は、「APIを変更したので、この場合はSemantic Versioningのルールに従ってメジャーバージョンを上げるべきであり、そうすることでユーザーも予測・対応しやすい」とのことです。
(引用終了)

すごく参考になる。
セマンティック バージョニングによるバージョン番号によって、ユーザに影響箇所を認識させることができるメリットがあること。
数多くのOSSも、そういうバージョン番号になっている。

だが、単一のアプリではなく、数多くの共有ライブラリに依存した大規模システムになると、依存関係の管理が難しくなる。
一つの共通ライブラリのバージョンアップで、回帰テストの工数が増えるリスクもある。
Javaでは、Maven、Ivy、さらにはGradleを使っていたが、今はどうなのかな?

【4】依存関係については、ライブラリだけでなく、チーム間の依存関係の例もある。
100人月以上の大規模システムになると、複数のチームが連携するのが普通だが、他チームのライブラリや成果物に依存するために、開発が滞る時がある。
あるいは、インフラ基盤に依存する場合、アジャイルチームとWF型開発チームが混在している場合、などの例もあるだろう。

下記の記事がすごく分かりやすい。

スクラムで依存関係を取り扱う方法 | Ryuzee.com

【5】この記事を読みながら、「ドメイン駆動設計」のパターンを幾つか連想した。
普通は、依存しあう二つのチームには、権力や影響力の優劣が存在する。
では、力の優劣のあるチームの依存関係では、どんなパターンがあるのか?

「顧客・供給者の開発チーム」パターンなら、上流のチームに対し、下流のチームが顧客として振る舞う。
これが理想。
本来は、上流のチームが「公開ホストサービス」「公開された言語」パターンで、下流のチームが使えるようなAPIを準備して公開すべき。
昨今のマイクロサービスの流行は、この方向性だろう。

「順応者」パターンなら、下流のチームは上流のチームに従順に従うしか無い。
下流のチームにとっては最悪のパターンなので「腐敗防止層」パターンでガードしたり、「別々の道」パターンを採用する。
たとえば、レガシーシステムの開発チームが強い場合は、こうならざるを得ない場合が多いだろう。

セマンティックバージョン、ライブラリの依存関係、チームの依存関係については、既に数多くの知見やベストプラクティスがあるので、それをまとめると面白いかなと思う。

| | コメント (0)

2017/05/22

気象庁の数値予報課におけるRedmine利用事例

気象庁におけるRedmine利用事例のリンクがあったのでメモ。
資料を読んでみると、以前のJAXAとは違った観点でRedmineが運用されていて、とても興味深い。
以下、理解と推測によるラフなメモ書き。

【参考】
数値予報モデル開発のための 基盤整備および開発管理 - 気象庁

第2章 開発記録とバージョン管理 - 気象庁

気象庁における 数値解析予報実験システムとバージョン管理

akipiiさんのツイート: 後で読む!RT @akahane92: #Redmine を有効に活用なさっているご様子が窺えます。気象庁予報部 - 数値予報課報告・別冊第 63 号「数値予報モデル開発のための基盤整備および開発管理」/ https://t.co/BxQV6ncPi5

akipiiさんのツイート: 読んでみると面白い。1つのサーバーに複数のRedmineインスタンスが稼働していて、そのインスタンス名も公開されてる。サーバー構成図もあって興味深い。数値予報モデル開発のための 基盤整備および開発管理 - 気象庁 https://t.co/BxQV6ncPi5

akipiiさんのツイート: 各Redmineインスタンスで異なるルールで運用されてる。親子チケットで進捗管理してるPJもあれば、ラフなタスク管理もあり。これらインスタンスのバージョンは同じなのかな?数値予報モデル開発のための 基盤整備および開発管理 - 気象庁 https://t.co/BxQV6ncPi5

【1】資料を見ると、気象庁の数値予報課における数値予報システムの開発プロセスにおいて、プロジェクト管理システムとしては Redmine 、バージョン管理にはSubversionやGitを導入したらしい。
気象庁では2012年頃には既にRedmineが導入されて、Redmineチケットに気象データや実験データを記録して蓄積する運用を行っているようだ。

(引用開始)
当時は開発コミュニティによっては Trac と呼ばれる Redmineと類似したツールを使っていたが、管理コストの低減、利用方法の共有の促進の観点から、機能がより豊富で柔軟に運用しやすい Redmine に統一することとした。
(引用終了)

(引用開始)
2012 年以前はさまざまなサーバに分散して Trac やRedmine が運用されていたが、すでに述べたように、開発管理サーバを整備して、数値予報課だけに限らず、庁内の数値予報モデル開発に関するプロジェクト管理シス
テムの運用を集約した。
開発管理サーバでは Redmineを標準的なソフトウェアと定め、Trac を利用していたプロジェクトは Redmine に移行した。
(引用終了)

(引用開始)
プロジェクト管理システム同様、一つのシステムに統一したいところであったが Subversion と Git で設計思想が大きく違う中で、すでに使用を開始しているものを一方に変更させるのは負担が大きい、ということから、どちらかを選択すればよいようにした。
(引用終了)

資料を一通り読むと、Redmineのチケット管理を上手く使いこなされているし、SVNやGitのブランチとチケットを連動させて運用させているような箇所も見られるので、OSSのモダンな開発プロセスは一通り習得されて運用されているように思える。
公共機関という、ある意味お堅い所で、RedmineやGitをバリバリに運用されている点がとても面白い。

【2】気象庁のRedmineで興味深い点はいくつかある。
一つは、Redmineのサーバー構成が公開されていること。

(引用開始)
開発管理サーバの構成図。両サーバは 2 台の大容量ストレージ装置をマウントしており、それぞれに主系・副系のゲスト OS を記録したイメージファイルを格納している。

サーバ
主・副 2 台
CPU: 3 GHz (6 core) × 2
メモリ: 48 GB (8 GB × 6)
HDD: 900 GB 2.5 型 SAS × 4
RAID: RAID5 + spare

大容量ストレージ装置
2 台 + 待機 1 台(非接続)
HDD: 3 TB SAT
(引用終了)

複数個のRedmineインスタンスで運用されている理由のせいか、サーバースペックはとてもリッチ。
主系・副系サーバーを用意して、定期バックアップでマウントされているので、サーバーの信頼性は非常に高く作られているように見える。
たぶん、気象庁の数値予報システムの開発状況や、数値予報システムの実験データ自身もRedmineに格納されているようなので、ミッションクリティカルなデータという観点で堅牢にサーバーが作られているのだろうと推測する。

ただし、開発サーバーの障害管理はどのように運用されているのか?
普通は開発サーバーの管理自身もRedmineで運用すると思われるが、資料では明示されていなかったので気になる。
もう1個、別のRedmineサーバーを立ち上げて、過去のデータを移行すればいいのではないだろうか。

(引用開始)
開発管理サーバに関する開発情報は、開発管理サーバに障害が発生した際に利用できる必要があり、障害時でも参照できる場所に情報が存在しなければならない。
そのため、開発管理サーバ自体の開発に関する情報は開発管理サーバの外で独自に管理を行う必要がある。
これらの情報の多くは開発管理サーバ導入前の環境、すなわち Redmineによる開発プロセスが導入される前に整備された環境を利用して情報が集約されている。
このため、現在では当然のように利用されているチケット駆動開発やレビューを行うための枠組みが存在しない。
(引用終了)

【3】もう一つは、一つのサーバー上で複数のRedmineインスタンスが運用されているらしいこと。
「コミュニティ」とは、気象庁の内部の各開発チームまたは開発部署と推測される。

(引用開始)
開発管理サーバの特徴として、一つのサーバ上に複数の Redmine を運用している点が挙げられる。
指針が定める開発管理サーバの利用範囲は、気象庁本庁と気象研究所を含めた複数の課室を想定していることもあり、管理する開発対象が非常に多岐にわたっている。
こうした背景からサーバ上で複数の Redmine を運用し、各 Redmine の管理方法の細目は利用するコミュニティに委ねる方式を採用している。
これによって、各コミュニティの既存の開発プロセスを踏襲しつつ、第 2.2.3 項で述べた Redmine を活用した開発が随時導入できるよう配慮している。
現在、開発管理サーバでは表 2.4.2 に挙げる Redmineを運用しており、モデル技術開発部会が取り組むほとんどの開発課題は、関連する Redmine 上で開発管理が実施されている。
(引用終了)

Redmineインスタンスの一覧は下記で公開されている。

(引用開始)
全球モデル
NHM
asuca
物理過程ライブラリ
海洋気象情報
数値予報事例 DB
共通基盤
化学輸送
同化・観測・QC 関連
結合系
海洋
ガイダンスグループ
お試し Redmine
(引用終了)

興味深いのは、それぞれのRedmineインスタンスで運用ルールが異なる点だ。
そうなった経緯や背景は明示されていないけれど、その理由は、各部署、各チームの業務や組織文化が大きく異るからではないか、と思う。

資料を読むと、10個くらいのチームの開発プロセスが紹介されていて、そのシステムが実現する業務はとても専門的で奥が深い。
たとえば、気象データのシミュレーション、数値解析、データの可視化など。
つまり、業務内容がとても大きく異なるために、一つのRedmineインスタンスにプロセスを標準化してガチガチに固めるよりも、各チームごとのRedmineで運用を任せて、柔軟に対応する方があるべき効果を導ける、という思想になったのではないだろうか。

そんなことを考えると、「闇Redmine」「野良Redmine」という症状は、現場によっては悪い症状ではなく、複数のRedmineインスタンスのVerUpやマスタ保守・インフラ保守のコストをカバーできるならば、現実的な解決策の一つと見なせるのではないか。

最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索

第11回東京Redmine勉強会の感想~Redmineエバンジェリストが日本各地で出現しているらしい #redmineT: プログラマの思索

実際、Redmineで最も多い質問は「チケットの粒度」だが、それに関しては、一律に標準化せず、各開発チームに運用を任せているからだ。
つまり、気象庁では、Redmineの特徴をよく理解しているように思われる。

(引用開始)
Redmine の利用にあたって、チケットに登録する際のタスクの規模、すなわち、タスクをどこまで細かく分割してチケットにすべきかについて悩むユーザが庁内には多いようである。
それぞれの開発コミュニティでルールを設けることが必要であるが、タスクの分割の仕方は主観的な面もあり一律に判断するのが難しい。
そのような場合は、チケットを作成することを躊躇せずに、まずはチケットを作成してその規模について試行錯誤をしてみることをお勧めしたい。
その試行錯誤の中で、開発コミュニティの中での使い方が定まっていくことが多い。
また、チケットの統合、分割は頻繁に行われることであり、作業を進める上で統合または分割したほうがやりやすいと判断される場合は、そのときにその統合または分割を行えばよい。
ぜひ、利用しながら自分の開発コミュニティにとって便利で有効な使い方を模索していただきたい。
(引用終了)

個人的には、チケットの粒度の問題は開発者は気にしないで良いと思う。
チケットの粒度を気にする人は管理者であり、彼らは顧客へ提出するレポートでその問題が絡んでいるだけだからだ。

チケット駆動の罠~複雑さはチケットの粒度に関連している: プログラマの思索

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

チケットの粒度と進捗ビューの関係: プログラマの思索

TiDD初心者によく聞かれる質問part2~チケットの粒度はどれくらいが妥当ですか?: プログラマの思索

【4】各チームの運用ルールも興味深い。

【4-1】全球モデルPJでは、リリール予定バージョンに対し、リリース計画をRedmineのチケットで立てて運用している。
その時、Redmineプロジェクトは、共通基盤は親PJ、各モジュールまたは各サブシステムは子PJで分けているみたい。

気になるのは「カテゴリ」でリリースバージョンを分類している、とのこと。
RedmineのカテゴリはPJ固有の属性だし、リリース終了のバージョンに対応するカテゴリは非表示にできないので不便だと思う。
普通は、リリース予定バージョンはRedmineのバージョンに対応付けて運用しているのでないかと思うけれど、実際はどうなのだろうか?

【4-2】メソモデルPJでは、チケット作成後、開発ブランチを派生させて、チケットに変更履歴を残す運用を行っている。
おそらく、チケット単位にブランチ管理しているので、トピックブランチとRedmineチケットを手動で連携させているように思われる。

また、チケットには、作業の内容だけでなく、テストやレビューも記録されている。
そして、「レビューアによる承認が得られれば、管理者によるトランクへのマージが行われる」ので、その意味では、git-flowに近い。
つまり、OSSのモダンな開発プロセスを取り入れているみたい。

【4-3】気象庁における 数値解析予報実験システムとバージョン管理を読むと、実験データはシステムに蓄積されると同時に、Redmineのチケットとしても自動登録して、記録しているようだ。
たぶん、RedmineのREST APIをコールしてチケット登録しているのだろうと思う。

わざわざRedmineにもチケット登録する運用にしているのは、Redmineに実験データや作業データを集約して、チケット同士の関連やソース管理と連携させたい理由があるのだろう。
つまり、情報共有はRedmineの方がやりやすい、という考えがあるのではないか。

【4-4】共通基盤PJでは、親子チケットによる進捗管理の運用を行っている。
Redmineの親子チケットの特徴を上手く利用して運用されている。

(引用開始)
NAPEX モデルの管理では、作業全体の進捗管理を親チケットで行い、個別の作業の管理は親チケットに結びつけられる子チケットを用いて管理するという方法を用いている。
(中略)
子チケットを用いた進捗管理では、子チケットを五月雨式に作成しない点に留意すべきである。
進捗が進むたびに子チケットを追加すると、全体の進捗状況が把握できなくなる。
親チケットを作成した時点で、必要となる子チケットを予め作成しておくことが望ましい。
これには親チケットを作成した時点で必要となる作業を明らかにしておく必要があり、子チケットとして分割するべき作業の洗い出しが必要となる。
この作業によって必要な作業の見通しを作業者自身の手で自然と把握することができるようになっている。
NAPEXモデルの管理では、子チケットの内容は相互に関連しているものの独立性があり、しかも定型的な作業が多いため事前に見通しが立てやすく、子チケットによる管理に適している。
(引用終了)

各Redmineインスタンスで、親子チケットの進捗管理をしたり、トピックブランチ単位のチケット管理、リリースバージョン単位のリリース計画作りとチケット管理、など、色んな運用ルールがあって面白い。

【5】気象庁のRedmineの利用ユーザ数は約300人、約5万チケットくらい。
JAXAの事例と同じく、たぶん、QMSやISMSなどに絡んでいると思われるので、チケットのデータの精度は良いのではないか、と推測する。

こういうシステムに、Redmineの全文検索プラグインを入れて、PageRankみたいな検索ができたり、類似チケット表示、検索時の入力補完ができると、より使い勝手が上がるだろうと思う。
なぜなら、元々のチケットのデータの精度も良いだろうし、気象データの数値解析やシミュレーションという専門性のため、過去のナレッジがとても重要になると思われるからだ。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

第12回東京Redmine勉強会の感想 #redmineT: プログラマの思索

【6】Redmineのメリットは、気象庁の人自身も感じているようだ。

(引用開始)
Redmine はチケット駆動開発に大変適している。
チケット駆動開発ではチケットなしでコミットしてはいけないという「No Ticket, No Commit!」ルールがある (小川・阪井 2010)。
これを導入することで、課題と成果の紐付けが可能になり開発情報が整理される。
さらに、コミット前にチケットが作成されることで、作業内容が多くの関係者の目に触れることになり、作業に先駆けて問題点やアドバイスが受けられるなど開発の効率化が期待できる。
また、レビューを経てからリポジトリを更新することを追加で義務付けることで開発成果の信頼性向上にも繋げることができる。
(引用終了)

(引用開始)
もちろん、行った変更の中には、物理過程間の相互作用などにより思わぬ結果が得られたものや、不採用になった変更も多いが、そのような情報も含めてチケットに残すことも非常に重要である。
なぜなら、改善につながった変更はドキュメントや報告書という形で残りやすい一方、採用に至らなかった変更はドキュメント化されにくいが、そこで得られた知見はモデルの解釈やその後の開発の方向性を決める上で重要であるためである。
(中略)
これらの実験の中には採用に至らなかった変更が数多くあるものの、チケットに記録しを実施した。
(中略)
内容はそのまま簡易なドキュメントとして残るため、開発者の記録用としてだけでなく、他の開発者への解説資料としても役立っている。
(引用終了)

(引用開始)
担当者間でメールで行っていたことが、ウェブベースに変わっただけと思われるかもしれないが、両者には大きな違いがある。
それは、作業内容を記録としてきちんと残していくことが可能になったとともに、他の P 班員が能動的に試験内容を知る機会が生まれたことである。
これにより、試験内容がさらに多くの人の目に触れることになるだけではなく、それぞれのルーチン変更に対して、担当者の技量の差などから生まれるミスが軽減され、知見を共有することで数値予報ルーチン全体としての品質の向上につながったのである。
また、ルーチン変更に起因する障害の際には、従来はルーチン変更担当者でないと実施内容が不明なために対応が難しい面もあったが、Redmine を導入してからは、他の P 班員に情報が共有されることにより、担当者以外による対応が容易になった。
(中略)
Redmine などのツールを上手く利用することで業務の品質は向上し、良い結果をもたらしたことは明白である。
しかし、それぞれのコミュニティに合ったやり方でツールを導入しなければ、開発効率を落とすだけではなく、業務の品質も落とすことになるので、その点には注意が必要と考える。
(引用終了)

チケット管理を上手く運用できれば、情報共有がスムーズになることで、各メンバーのコミュニケーションが活性化したり、「No Ticket, No Commit」によるチケットとソースのトレーサビリティを実現することで、Redmineの過去チケットをテストやレビューのプロセスに役立てることもできるだろう。
Redmineそのものがナレッジシステムになることで、過去のデータから色んな知見を探し出すこともできる。

でも、Redmineを単純に導入したからと言って、チケット駆動のメリットがすぐに得られるわけではない。
組織の文化、業務内容、成熟レベルによって、Redmineの運用ルールを段階的に変更したり、柔軟にコントロールする必要があるだろう。
複数のRedmineインスタンスで故意に運用しているのも、そういう背景があるのではないか。

気象庁の事例も、Redmine勉強会で講演してくれないかな?

| | コメント (0)

2017/05/14

第12回東京Redmine勉強会の感想 #redmineT

第12回東京Redmine勉強会では、講演者、参加者、スタッフの皆さん、お疲れ様でした。
大雨の土曜日のために、突然キャンセル40人以上発生したにもかかわらず、参加率90%という驚異的な勉強会。
感想をラフなメモ書き。
間違っていたら後で直す。

【参考】
第12回勉強会 - redmine.tokyo

第12回東京Redmine勉強会 - Togetterまとめ

第12回東京Redmine勉強会の見所: プログラマの思索

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。今日は参加率90%で驚異的でした。ディスカッションでは土木建築、デザイナー、ゲーム、メーカーなど多様な業界でRedmine が使われてた。レベル別、セグメント別で議論して、Redmine の運用方法を洗い出してみたい"

【1】@g_maedaさんの発表は、3月のRedmine大阪の発表の改良版。
気になる点は、最後の「Redmine3.4.0になれなかったパッチたち」。

サイドバー折り畳みは、欲しい。
PCの画面が小さいと、フル画面でチケット一覧を見たくなる。
チケット一覧の表示項目が増えると、横スクロールが必要になって、うっとうしい。
また、スマホ、タブレットなど数多くの閲覧媒体が増えてきているので、レスポンシブ対応だけでなく幅広く対応してほしい。

コードハイライト言語を増やす機能追加も早くやってほしい。
特に、VB、C#のコードハイライトがない、という要望は従来からすごく多い。

バージョン内のチケットのD&D機能も早く追加してほしい。
アジャイル開発におけるプロダクトバックログの精査の作業に直結する作業だからだ。
つまり、チケットのリリースの優先順位づけを並び順で表現することは、リリース計画をプロダクトオーナーと開発者が共有しやすくなる点にも直結する。
アジャイル開発の観点では、チケット一覧画面よりも、ロードマップ画面の改良にもっと力を入れて欲しい。

【2】@Madowindaheadさんの講演では、チームの変化やチームの成長を活動画面から事前調査して、支援しているとのこと。
この部分はRedmineの優れた機能そのものだし、チームの成長がRedmineに記録されていく点はチームのモチベーションにもつながるだろう。

あさこさんのツイート: "「決定に関する内容も分かります」 活動内容をどういう粒度で記入するかをしっかり決められているいい事例ですね!! #redmineT"

akipiiさんのツイート: "#redmineT 成長していることを、変化していることで捉える。まさにRedmine の得意なところ"

また、PMxTMのポジショニングマップが重要だと思う。
縦軸=PM技術力、横軸=ツール利用度で、開発チームや開発メンバーをプロットして、どこのセグメントが問題なのか、あるべき姿へどうやってマネジメント力を向上させていくべきか、という観点で分析するのに使える。

特に、Redmineを導入したけど、社内でなかなか広まらない、という時に、どこのセグメントに問題があるのか、という分析のヒントになるだろうと思う。

スライドで面白い点は、社内でRedmine利用度を上げることでマネジメント力を向上させるパターンを経験上3種類あげている点だ。

一つ目は、PM力が大変低く、ツール利用経験も大変低い層。
このセグメントは、「目標になるメンバーと一緒に成長ラインに乗せる」。
つまり、新入社員のように、まだ技術もPMの経験が浅い人は、OJTのような仕組みが有効なのだろう。

二つ目は、PM力は中間くらいだが、ツール利用の経験が浅い層。
このセグメントは、「この位置のメンバーは成長ラインに乗せやすい」。

その理由は、既にマネジメントの経験があり、PMに必要なスキルや概念はある程度分かっている人たちなので、そのスキルを生かしやすい環境としてRedmineを提供すれば、自分たちで問題解決していけるようになるはず、ということだろうと思う。

三つ目は、PM力は高いが、ツール利用度が大変少ない層。
まさにExcelおじさん。
このセグメントは、「メンバーの成長を意識させることで、成長ラインに乗せる」。
この点は、なるほど、と思う。

このセグメントは、自分たちのやり方を持っている人が多いので、なかなか新しいツールを使ってくれない。
でも、自分の立ち位置やメンバーへの影響力は、自分でも分かっている人が多い。
すると、自分がRedmineを使わなくても、メンバーがRedmineを使って自然に成長していけば、自分もちょっとはやってみようか、という気になるのだろう。
つまり、いきなりツールを使いこなせ、とトップダウンでやるのではなく、ボトムアップで攻めていくわけだ。

このパターン集で面白いのは、4象限のうちの右下の部分「ツール利用は多いがPM経験が少ない」セグメントのパターンがないこと。

講演でちょっと触れていたが、このセグメントはヒントを与えたり、支援すれば、自力で解決していってくれる。
個人的には「プログラマ上がりのプロジェクトリーダー」が多いのではないか、と想像する。
そういう人たちには、得意とする技術力をベースとして、Redmineでマネジメント経験を増やしていけば、自然に力が付くのではないか、と想像する。
僕自身もそういう経験があった。

【3】@ktohさんのRedmine全文検索プラグインの話も興味深かった。

たとえば、チケットが数十万枚、数百万枚に増えた場合、それらチケットやWikiなどの情報を、欲しい時に即座に検索できる機能は、Redmineをナレッジシステムとして使うために重要な機能と考える。
Ver3.3では、右上の検索ボックスは表示中のPJだけにデフォルトで絞り込み検索するので早くなっているが、全PJ横断の検索はまだ遅い。
そのような問題を解決するプラグインなので、Redmineをナレッジシステムとして価値を向上させるために有用な機能だと思う。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

全文検索プラグインで興味を惹く点はいくつかある。

一つは、検索ノイズがなく、ランク別・更新時刻順に表示される点。
Groongaという拡張DBエンジンを使うので、スコアを調整して、有用な検索結果を上位N件に表示してくれる。
注目すべき点は、デフォルトの全文検索結果と全文検索プラグインの検索結果は、件数は同じでもソート順が違う点。
つまり、Google検索みたいに、役立ちそうな情報が上位に表示されるので便利。

また、Google検索のように、AND・OR・NOT検索ができるのも便利。
たとえば、「(Groonga OR Mroonga) -PostgresSQL」みたいに、GroongaまたはMroongaを含むがPostgresSQLを含まないように検索できるらしい。
この機能が検索で使えるならば、過去の障害や仕様変更の履歴を探したい時に、より詳しい検索条件で書けば、より早く到達できるようになるだろう。

さらに、更新時刻順にソートできるのもうれしい機能だ。
検索したい状況をふりかえると、直近で自分や他の担当者が書いた内容を検索したい時が多いからだ。
直近の障害情報、直近の課題やQAを見つけたい時が多いから。

二つ目は、高速である点。
この内容は、既に@akahane92さんがツイートされている。

Kuniharu AKAHANEさんのツイート: "200万チケット@MySQLでやってみたよ。検索時間は約380ms。 #Redmine の未来が広がって嬉しいな。ありがたいな。/Redmineで高速に全文検索する方法 - ククログ(2016-04-11) https://t.co/s7FA4gSThu @_clear_code"

neta@世界は私のオイスターさんのツイート: "@akahane92 さん! 今クリアコードの人が 赤羽根さんの全文検索380ms のツイート紹介してました。プラグイン適用前の処理時間を知りたいらしいですよ! #redmineT"

Kuniharu AKAHANEさんのツイート: "@netazone (ご参考まで) Redmineチューニングの実際と限界 / https://t.co/fRU2MvH4my の114ページです。"

三つ目は、まだ未実装だが、類似チケットの検索。
これは、Amazonのお勧め商品表示と同じく、協調フィルタリングとか機械学習みたいな機能を使って、この障害チケットに似た過去のチケットはこれこれです、みたいに表示する。
たとえば、障害チケット起票時に、過去の類似バグを表示してくれると嬉しいだろう。

四つ目は、まだ未実装だが、検索ボックスやチケットのタイトル欄などで、入力補完する機能強化。
これは、PJプルダウンのインクリメントサーチのように、検索ボックスで1文字入れたらGoogle検索みたいにコードアシストしてくれる機能みたいなイメージ。
この機能があれば、チケット内容の入力間違いを減らせるし、途中までの文字入力で自動補完してくれるので、チケット入力コストをかなり減らせるはず。

つまり、ただでさえチケット入力は鬱陶しい、と言われがちな弱点に対し、検索エンジンの強化によって入力補完をサポートすることで、チケット入力者の作業コストを減らし、チケットの内容の精度向上に役立てることができるわけだ。

この辺りの機能を欲しいと思う日本人ユーザ、Redmine利用企業は意外に多いのではないだろうか。
なぜなら、Redmineを利用している現場は増えているし、すでに数年以上運用してかなりの枚数のチケットを蓄積している日本企業も多いと思うからだ。
@ktohさんが支援を要請しているので、興味のある人は声掛けしてはどうだろうか。

すさんのツイート: "第12回https://t.co/YxfaKONoze勉強会の「GroongaでRedmineを高速全文検索」の資料です!今後の野望を一緒に実現したい人はぜひ連絡をください! https://t.co/FEBfQvAVk4 #redmineT"

今後の野望については、下記の記事でアップされている。

redmine.tokyo第12回勉強会:GroongaでRedmineを高速全文検索 #redmineT - ククログ(2017-05-15)

なお、AWSへのセットアップでは、下記のツイートがあるので注意。

Kawabata Mitsuyoshiさんのツイート: "AWSだとmroonga入れられないという質問があったが、最近だとRDSから、MySQL on EC2にmaster-slaveでレプリケーションして、MySQL on EC2側で検索処理するが定石っぽい #redmineT https://t.co/SwD3IFyeVt"

MAEDA, Goさんのツイート: "Redmine本体は現状PostgreSQL推奨です。MySQL 5.6以降だとデッドロックが発生するケースがあります。 #redmineT https://t.co/zRSmVfGY8T https://t.co/y9KtUtJ8SG https://t.co/AS0A6KDeaZ"

【4】宮本さんの「チケット駆動開発基盤とプロダクトライン型開発の融合手法の検討と評価実験」も興味深かった。

ストーリーとしては、既にRedmine+GitLab+Jenkins+Maven+Artifactoryという開発環境がそろっていて、その上にプロダクトラインのプロセスを実装しようとするお話だった。
お話としては大変興味深いのだが、肝心のRedmineの機能にどのようにマッピングさせたのか、という点はぼかされていて、分からないところが残念笑。

但し、講演中の一言「Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所」という話から想像すると、こんな感じかな。

akipiiさんのツイート: "#redmineT Redmine が要件、タスクなどエントリーポイント。MavenやArtifactoryがプロダクトラインでは肝となる所。プロダクトそのものの構成管理がやりたいからだろう"

Redmineには、要件や仕様、それに基づくタスク・課題・障害の情報は一元管理されていて、そのチケットから作業は駆動される。
そして、ソースや設計書などの成果物はGitLabで構成管理されていて、複数の製品ファミリーはGitのブランチで管理されている。

その時、それぞれの製品ファミリーのリリースされたソフトウェア製品は、バージョンでタグ付けされて、それらはArtifactoryでビルドモジュール単位のバージョン管理がなされている。
つまり、各製品は、共通ライブラリやコア基盤となるようなビルドモジュール(たぶんJarやWar)とアプリケーション資産(これもJarやWar)がパッケージングされていて、各製品がリリースされたタイミングで、共通ライブラリのどのバージョンに依存しているか、はMaven+Artifactoryで構成管理されているのだろう。

つまり、ソフトウェア製品とソフトウェアモジュール(汎用ライブラリ)は、ビルドモジュール単位で構成管理されていて、その構成管理が重要、ということなのではないだろうか。
この考え方はちょうど、業務システムがOracleやApache、.NET Frameworkの特定のバージョンに依存して作られていて、それらも含めて構成管理されている、みたいな考え方と同じではないだろうか。

すると、Redmineにある発端となった要件や仕様から、それに紐づくソース、そこからビルドされてリリースされたソフトウェア製品へトレースできる(後方への追跡性)し、逆に、あるバージョンのソフトウェア製品から要件までトレースできる(前方への追跡性)。

そのような開発プロセスを作りたい、という動機も別途あるのだろうと推測する。
そして、その仕組みは、Redmineのチケット管理や構成管理ツール連携という機能を使えば、チケット駆動のトレーサビリティ機能が導出されて実現できる、みたいなストーリーではないだろうか。

チケット駆動開発を要求工学の品質特性の観点から考える~チケット駆動開発がAgile開発を必要とする理由: プログラマの思索

【5】講演資料はコチラ。

| | コメント (3)

2017/05/05

ソフトウェアの複雑性は本質的な性質であって偶有的なものではない

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。
ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。
以下は書きかけ。

【参考】
第0回:人月の神話とはなんなのか?(解説編)|本気で読み解く”人月の神話” | GiXo Ltd.

第2回:銀の弾は無いけど、”銃”はあるよね|本気で読み解く”人月の神話”(第16章) | GiXo Ltd.

ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ

ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間

【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。

「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の内容自体は10年以上前のWebやIT業界の話が多く、内容も古くなっているので、新たな知見が得られるという感覚はしない。
しかし、「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」の中に、「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」という言葉があって、すごくしびれた。

(引用開始)
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。
したがって、複雑性を取り去ったソフトウェアの実体の記述は、しばしばその本質も取り去ることになる。
数学や物理学は、複雑な現象を単純化したモデルを構成し、そのモデルからある性質を引き出し、実験的にその性質を証明することで、3世紀にわたって偉大な進歩を遂げた。
この方法でうまくいったのは、モデルで無視された複雑性が現象の本質的な性質ではなかったからだ。
複雑性が本質である場合には、この方法は使えない。
(引用終了)

上記の内容は、ブルックスの「人月の神話」の一節そのまま。
なぜ自分がすごく衝撃を受けたのか、考えてみると、ソフトウェア開発の本質に触れているものだから。
たぶん、僕の心のなかにある、ソフトウェアに対する楽しさだけでなく、ソフトウェアへの憎しみというか、なぜこう思い通りにソフトウェア開発をコントロール出来ないのか、という腹立たしさに触れている気がしたから。

「偶有的」という言葉も引っかかる。
この言葉は、古代ギリシャのアリストテレスの哲学から引用したものらしい。

(引用開始)
アリストテレスに従って、難しさを本質的なものと偶有的なものに分けて考えてみよう。
ここで、本質的な複雑さとは、ソフトウェアの性質に固有な困難のことであり、偶有的難しさとは、目下の生産にはつきまとうが本来備わっているものではない困難のことである。
(引用終了)

自然科学、特に数学や物理学では、できるだけ単純なモデルを作り、そこから演繹される性質や定理を証明することで、自然現象を多面的に分析しようとする。
複雑なものを複雑なまま捉えるのではなく、理想的な単純なモデルに純粋化して、人間の思考に耐えられるレベルにして、数多くの観点で徹底的に分析するのが自然科学のやり方。
シンプルなモデルを「徹底的に」分析し尽くして、全ての特徴を洗い出し、全てを因果関係や演繹でまとめ上げて一つの理論体系にするのが自然科学のやり方。

すると、シンプルなモデルをどのように事前設定するか、どのパラメータを重視して選択しておくか、というのが重要になる。
その部分が、科学者の腕の見せ所。

たとえば、物理学では、理想気体みたいに、現実から離れるけれど、シンプルなモデルを設定することで、計算や実験を扱いやすくするモデル作りは一般的だ。
熱力学、相対性理論、量子力学など、色んな分野の物理学でもその手法を用いている。

物理学は一つの認識論: プログラマの思索

数学でも、一流の数学者は、自分で理論を打ち立てたい時、最も組合せの少ない公理や公準を直感的に選んで、そこから矛盾が生じないように設定しておく。
そこから、「誰々の定理」のような重要な結果を導き出す。
一流の数学者がすごいのは、最も組合せの少ない公理を直感的に把握できること、そして、重要な定理を導く時に、ロジックの穴になりそうな難しい場所を事前に察知して、それをくぐり抜けるために、あらかじめ「誰々の補題」みたいな補助的な公式を用意しておくのが上手い点。

技術の背後に数学の理論があると廃れない: プログラマの思索

数学や物理は背景にある思想を知らなければ理解できない: プログラマの思索

このやり方がすごく成果を上げているので、人文科学や社会科学でもそのやり方を真似ているように思える。
特に、経済学は典型的だろう。
マクロ経済学やミクロ経済学みたいに、人間は合理的に行動する、とか、市場の価格は恣意的な手段で決めても長続きせず、神の手(つまりは市場原理)で決まる、みたいに、現実とかけ離れた仮定をおいて、数多くの経済モデルを作り、そこから重要な経済学の定理を導き出す。
単純な経済モデルから得られた経済学の定理で現実に通用する場面が過去にあったから、経済のグローバル化が世間に言われ始めてから、世の中の経済事象は、市場原理で決まる、いや決めるべきだ、みたいな論調が多い気がする。

経済数学の直観的方法の感想: プログラマの思索

「推計学のすすめ」「経済数学の直観的方法~確率統計編」の感想: プログラマの思索

しかし、ブルックスの「人月の神話」では、ソフトウェアにはそのやり方が通用しない、という指摘をしている。
「ソフトウェアの複雑性は本質的な性質であって偶有的なものではない」からだ。
つまり、複雑性を排除したソフトウェアは、ソフトウェアの本質を意味しないからだ。

【2】ソフトウェアの本質的な複雑さと、偶有的な複雑さの違いは何か?
ソフトウェアの本質的な複雑さは、リーマンの法則そのものを指すと思う。

リーマンの法則~ソフトウェアもエントロピー増大の法則を避けられない: プログラマの思索

リーマンの第1法則
 使われるシステムは変化する。
リーマンの第2法則
 進化するシステムは複雑性を減らす取り組みをしない限り、システムの複雑性が増す。
リーマンの第3法則
 システムの進化はフィードバックプロセスによって決まる。

(引用開始)
レーマンとベラディは、大規模なオペレーティングシステムのリリースについて、継続してその変遷を研究してきた。
そこで分かったことは、モジュールの総数はリリース番号とともに線形に増加するのに対し、影響を受けるモジュールの数はリリース番号に対し指数的に増加するということだ。
(中略)
システムプログラムの作成は、エントロピーを減らす仮定だから、本来は準安定なものである。
他方、プログラムメンテナンスはエントロピーが増加する過程であり、どんなに器用に行なっても、できるのはシステムが修正不能な陳腐化へと沈んでいくのを遅らせることだけである。
(引用終了)

(引用開始)
ソフトウェア製品開発に関する古典的問題の多くは、その本質的な複雑性と、ソフトウェアの大きさに従ってその複雑性が非線形に増大することに由来している。
(引用終了)

この文章を読んで思い出すのは、ケント・ベックがXPを生み出した経緯のことだ。
ケント・ベックは、ソフトウェア工学の授業で習った、リリース総数が増大するにつれてソフトウェアの複雑度や変更コストが増大していく経験則に対して、異議を唱えた。
時間が進むに連れて、この曲線を頭打ちにできるような開発プロセスはないのか、と。

- eXtreme Programmingの魅力を探る オブジェクト倶楽部

(引用開始)
「変化ヲ抱擁セヨ」
この呪文めいた言葉は,Kent Beck による本の副題として掲げられている. 時間を横軸に,ソフトウェアの変更にかかるコストを縦軸にプロットする.
この「時間-変更コスト」曲線は極端な右上がりになると信じられて来た(図左).
すなわち,要求分析,設計,実装,テスト,保守,と時間が進むにつれ, 変更にかかるコストが増大するというのだ.
現在までのソフトウェア開発プロセスは,この仮定上の議論が多数 だったのである.
XP はこの曲線を平坦にできるのではないか, また,そうできたとしたら,全く違った方針でプロジェクトに立ち 向かえるのではないか,という挑戦をしている(図右)
(引用終了)

こういう素朴な問題意識はすごく重要だと思う。
XPがその理想を本当に実現したのかどうか、は検証がいると思うが、そういう背景を元にアジャイル開発のプラクティスが生まれたことは、アジャイル開発が従来のソフトウェア工学と対立しがちに見える傾向を示唆しているように思える。

ちなみに、上記の第1版の「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法」に、上記の「従来のソフトウェア工学が提唱しているソフトウェア複雑性へのXPの果敢な挑戦」の文章と図はあるのに、第2版の「エクストリームプログラミング」から削られていることだ。
とても残念。
この部分がXPにとって一番重要な主張なのに。

【3】コードクローンと再利用性。

(引用開始)
ソフトウェア実体の本質とは、データセットやデータ項目間の関係、アルゴリズムや機能呼び出しなどが組み合わさったコンセプトで構成されたものである。
この本質は、同じ概念構造体が多くの異なる表現で表されるという点で抽象的である。
それにもかかわらず、非常に正確で十分に詳細なものである。
(引用終了)

コードクローンとは、同一アルゴリズムを各プログラマが別々の実装したプログラムのことだ。
上記は、ソフトウェアの複雑性が増大しがちな理由の一つは、コードクローンが大量に発生しがちである、と言う点を示唆していると思う。

ソフトウェア工学の論文を見ていると、コードクローンのメトリクス採取の記事が割と多い。
その理由は、コードクローンを減らす方がソフトウェアの複雑性が減るので、良い、という主張が隠れているのではないか。

では、なぜコードクローンは良くないのか?

(引用開始)
ソフトウェア実体は、どの2つの部分をとっても似ることがないので、大きさの割にはおそらく他のどの人工構造物よりも複雑なものだ。
似通っている部分があれば、2つの類似部分を1つにする。
この点において、ソフトウェアシステムは、重複要素(部品)が豊富なコンピュータやビルあるいは自動車などとは全く異なっている。
(引用終了)

その理由は、ソフトウェアの再利用が進まないからだ。
たとえば、自動車やパソコン、スマートフォンのような工業製品は、再利用可能な汎用部品を組み立てる手法と大量生産することを組合せることで、規模の経済を生かし、経験曲線効果を生かして、1個当りの製造コストを劇的に減らす。
しかし、この「規模の経済」「経験曲線効果」というコストメリットを享受しうる生産手法がソフトウェア開発には全くといっていいほど通用しない。

ソフトウェアを部品化して、スマートフォンみたいに部品を組み立てるように製造したい、と考えて、CORBAとかEJBのようなコンポーネント駆動開発、製品ファミリー群の製品開発手法であるソフトウェアプロダクトラインとか色々考えられたけれど、どれも実用的ではない。

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

ソフトウェアプロダクトラインが解決しようとするもの~品質と再利用: プログラマの思索

だから、多額の資金を設備投資に投入して、最新の機械で汎用部品を組合せて大量生産する生産手法がソフトウェア開発には馴染まない。
ソフトウェア開発は徹頭徹尾、経験曲線効果すらも有効でない労働集約的な生産手法に似ているように思える。

【4】ソフトウェアの本質的な複雑性とは、同調性、可変性、不可視性。

【4-1】同調性は、リーマンの言う組み込まれた(Embeded)プログラム、を連想する。

「ソフトウェア・グラフィティ」の感想: プログラマの思索

(引用開始)
支配しなければならない複雑性の多くは気まぐれによるものだ。
インターフェイスを人間の社会制度やシステムに適合させるべく、いわば是非もなくそれらによって強制されているからである。
(引用終了)

最近、業務システムとかERPに僕自身が少し興味をなくしているのは、システム化したい業務そのものが元々複雑過ぎて、それを整理しようと言うよりも、現実の業務をいかに忠実にシステム化するかに注力する案件の方が多いからだ。
元々の業務が、日本的な複雑な組織体制を元に作られていれば、複雑なのは当たり前であり、それを忠実にシステム化するなら、複雑怪奇なままだ。
日本では、ERPをBPRとして捉えるよりも、自分達の業務中心に考えすぎているために、システムも複雑怪奇になりやすいような気がしている。

【4-2】可変性は、ソフトウェア品質の移植性や保守性を連想する。

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

(引用開始)
ソフトウェア実体は、つねに変更という圧力にさらされている。
(引用終了)

XPの言う「変化を抱擁せよ」と同じ。
ソフトウェアにとって、VerUpは宿命であり、常に変化が内在している。
ソフトウェアは変化しない固体として存在し得ない。

(引用開始)
純粋な思考の産物であってきわめて融通性に富んでいるので、ソフトウェアがより簡単に変更できるということもある。
ビルも現実には変更されるものだが、だれもが了解しているように、変更コストの高さが思いつきで変更しようとする者の気をくじく働きをしている。
(引用終了)

ソフトウェアに、仕様変更という名の保守はつきものだ。
それは簡単にできるように思えるから、簡単にソフトウェアに手を入れて、潜在バクを埋め込んでしまう。
ソフトウェア品質特性のうちの保守性を連想させる。

(引用開始)
大当たりしたソフトウェアはまずたいてい、すべて変更される。
あるソフトウェア製品が役立つと分かると、人々はもともと処理対象としていた領域ぎりぎりもしくはその領域を越えるような新しい使い方を試してみようとする。
主として、拡張機能のために変更して欲しいという圧力は、基本機能が気に入っていて新しい使い方を考えだす利用者から出される。
(引用終了)

これは、たとえば、Redmineが当初のバグ管理の使い方から、タスク管理、そして、アジャイル開発やWF型開発、さらには、事務処理ワークフロー、ハードウェア資産管理システムへ使い道がどんどん広がっていった事例を連想させる。
本来想定しなかった使い方が一般的になってしまい、その使い方をさらに使いやすくしたり、機能改善することで、ソフトウェアの複雑性がどんどん膨張する。
あらゆるソフトウェアは機能追加という変化にさらされている。

(引用開始)
大当たりしたソフトウェアは最初に書かれた対象である機械機器の通常の寿命よりも長く使用され続ける。
要するに、ソフトウェア製品はアプリケーションや利用者、慣習および機械機器といった文化的マトリックスにすっかりはめこまれているのだ。
そしてそれらは絶えず変化し続けるものであり、その変化がソフトウェア製品に容赦なく変更を強制するのである。
(引用終了)

たとえば、OSやDBやミドルウェアのバージョンアップとか。
あるいは、サーバー本体のリプレースとか。
たとえば、WindowsXP廃棄対応、WindowsServerのリプレース、OracleのVerUp、RailsのVerUpとか、iOSやAndroidOSのVerUpとか、色々思い出す。
つまり、ソフトウェア品質特性の移植性を連想させる。

こういうミドルウェアやOSのVerUpに伴うプログラム変更作業は、とてもしんどいものだ、と開発者なら誰でも知っている。
こういうつまらない開発基盤のVerUp作業は、ソフトウェアの外にある外部環境の変化によって生じるものであり、避けることは出来ない。

【4-3】不可視性は、ソフトウェア設計の難しさを連想する。

(引用開始)
ソフトウェアの構造を制限したり単純化したりすることは進歩したにもかかわらず、その構造は本質的に視覚化できないままになっている。
そのため強力な概念上のツールを作る意欲を阻害している。
その欠落は1人の人間の頭の中のデザインプロセスを妨げるばかりでなく、複数の人間の間でのコミュニケーションもひどく妨害する。
(引用終了)

UMLやDOAは、ソフトウェア構造を視覚化する問題を解決しようと試みていた。
SySMLもその流れだろう。

複雑性をコントロールするための設計技法は、歴史上いくつか考えれてきた。

たとえば、Nティア設計。
つまり、レイヤ化。

another level of indirection
「もう一段の間接参照」を導入すると、コンピュータのほとんどの問題は解決できる。

NFuji's Café: 「Beautiful Code」を読む(中)

ポインタを制する者はプログラミングを制する: プログラマの思索

MVCモデル、通信プロトコルの7層モデルもそういう考え方だろう。

他に、渡部幸三さんの観点でのDOAでは、業務・機能・データの3層構造の業務システムにおいて、業務レイヤとデータモデルのレイヤに複雑性を押しこんで、機能レイヤは複雑性をできるだけ減らす設計が良い、と提唱していた。
すなわち、機能レイヤはまさにプログラミングレベルなので、その部分の複雑性はできるだけ減らして保守性を高めようとする考え方。
つまり、複雑性というエントロピーは一定で変わらないと仮定した場合、人が携わる業務レイヤと、データモデルのレイヤに複雑性を落としこんで、複雑性をコントロールしようとするわけだ。

だが、これらの手法で、ソフトウェア本来の複雑性が本質的に解決されたのか、と問うてみると、正直分からない。

【5】一方、ソフトウェアの偶有的な複雑さは個別撃破している。

「高水準言語」は、たとえば、VBよりもRuby。
たとえば、VBはListやHashなどの基本ライブラリのAPIが非常に不足していて使いにくい。
たとえば、Rubyなら、そういう低レベルなライブラリは非常にAPIが揃っていて、VBよりも1行で書ける。
つまり、複雑性を軽減している。

「タイムシェアリング」は、たとえば、コンパイラ言語よりもインタプリタ言語、継続的ビルド管理、構成管理を指すのかな。

(引用開始)
考えていた内容をすっかりというわけではないが些細な点でどうしても忘れてしまう。
(引用終了)

この部分は、まさにソース管理、構成管理を連想させる。
たとえば、CVS、Subversion、Gitに至るまでの構成管理ツールの歴史を振り返れば、ソフトウェア開発プロセスにおけるブランチ管理、マージなどの作業の複雑性は軽減されている。

「統一されたプログラミング環境」はたとえば、VisualStudioやEclipse、IntelliJとか。

つまり、ソフトウェアを開発する作業そのものが生じる複雑性は、今までの歴史で生み出された技術によって、多少は軽減されてきた。
しかし、だからと言って、ソフトウェアの本質的な複雑性を攻略できたわけではない。
あくまでも、以前よりも大きい複雑なソフトウェアをコントロールできるようになった、というだけだ。

| | コメント (0)

より以前の記事一覧