2018/02/21

Redmineのアンチパターンは2種類に区別できるのではないか

以前、Twitterで、日付カスタムフィールドに関するRedmineのアンチパターンが議論されていた。
その議論を読みながら、Redmineのアンチパターンには、プロジェクト管理の要件のブレかフィットギャップ分析の甘さの2種類に区別されるのではないか、と考えた。
ラフなメモ書き。

【問題の発端】
nekosanzさんのツイート: "難問。1つのプロジェクトではなく、1つのチケットにマイルストーンがほしい。こんなこと言われたの初めてだ"

門屋 浩文さんのツイート: "チケット割るか説明に書く!… "

nekosanzさんのツイート: "結論が日付カスタムフィールドを10個ぐらい追加してほしいという炎上物件… "

【問題の真因を突いている議論】
neta@筋肉 筋肉???さんのツイート: "Redmine の日付カスタムフィールドはあかん。ウチも『期日』という名称が気に入らなかったらしく、『希望納期』という残念なカスタムフィールドを作ってしまった。ガントには出ねーわ、リマインダーは効かないはマイッタマイッタ。今は反省している… https://t.co/MSqH2RmwwQ"

門屋 浩文さんのツイート: "日付のカスタムフィールドはあまり良くない 標準のガント使わなくなったのが実績日が出てこないからという理由なので… "

【アンチパターンに関する感想】
akipiiさんのツイート: "久しぶりにRedmine のアンチパターンを集めたいですなぁ笑… "

nekosanzさんのツイート: "みなさんおっしゃる通り。コミュニケーションツール不在の会社にRedmine 導入するとアンチパターンの温床になりえますね。… "

akipiiさんのツイート: "アンチパターンの種類にも、プロジェクト管理の要件を詰めきれてないことと、Redmine の機能を理解しておらずフィットギャップ分析が甘いこと、があるから区別したいな。… "

【1】チケットにマイルストーンが欲しい、という要望を元に、Redmineに日付カスタムフィールドを10個も追加してしまった、という事例。

おそらく、障害管理票、課題管理票のような類の帳票をチケット化した時、数多くの異なる日付を入力する必要になったのでは、と勝手に推測する。

しかし、上記の指摘の通り、Redmineチケットの「期日」を使わなくなると、ガントチャートに表示されないし、リマインダーのメール通知機能も使えなくなる。
よって、本来は、チームの要望にある「日付」の概念をRedmineの「期日」に合うように修正すべきだったのだろう。
あるいは、ja.ymlにある「期日」の文言をチームの組織文化に合った文言、たとえば「納期日」などへ修正しても良かっただろう。

【2】そういう話をふりかえると、Redmineのアンチパターンには、2つの観点で綺麗に分類できるのではないか、と思う。

【2-1】一つは、プロジェクト管理や開発プロセスの本来の設計思想に関する理解が浅いために、プロジェクト管理の要件を詰め切れていないこと。

よくある例は、WBSは工程単位に作るべきなのか、機能単位に作るべきなのか、どちらがいいのですか、という質問が相当するだろう。
この質問に関しては、下記の記事で明確に回答が述べられている。

WBSはプロジェクト組織を規定する : タイム・コンサルタントの日誌から

WBSはコスト見積の基準を規定する : タイム・コンサルタントの日誌から

WBSの作り方はプロジェクト型組織の構造を決めるという考え方はRedmineチケット管理にも通じる: プログラマの思索

また、「チケット無しの作業不可」の運用ルールの理解が浅いために、作業履歴やレビュー履歴をチケットに残してナレッジを蓄積し、最終的にはプロセス資産になる、という思想まで考えが及ばない、という話もあるだろう。
その他にも、チケットの棚卸し、トレーサビリティなどの話も同じ論点ではないか、と思う。

つまり、Redmineのようなチケット管理ツールとは無関係な観点で、プロジェクト管理や開発プロセスの理解が甘いために、RedmineやJiraであろうが、どのチケット管理ツールも使いこなせていない、という結果になるのだろう。

すなわち、この観点のアンチパターンは、ツールとは無関係な一般論に近いレベルまで昇華できるだろう、と思う。

【2-2】もう一つは、チームの開発プロセスの要件とRedmineの機能について、フィットギャップ分析が甘いこと。
これは、今回の日付カスタムフィールドの話に相当するだろう。

他に、親子チケットの作り方、ロードマップの使い方などもあげられるのではないか。

【事前公開】【第16回Redmine大阪】RedmineのFAQとアンチパターン~親子チケットの功罪: プログラマの思索

Redmineの親子チケットの功罪: プログラマの思索

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

最近なら、デブサミ2018のRedmine利用事例の講演でも、アンチパターンに関する話があった。
その中で、@g_maedaさんの下記の話は、Redmineにおけるトラッカーを使いこなせていないアンチパターンがある事実を示唆している。

MAEDA, Goさんのツイート: "最近は、トラッカーの追加とは入力フォームを設計して追加することだと説明するようにしています。… "

つまり、Redmineに埋め込まれた本来のチケット管理の機能要件を理解できていないために、Redmineの優れた機能を発揮できない結果に陥る、という結果があるだろう。

すなわち、この観点のアンチパターンは、Redmineの設計思想とユーザが利用したい要件に関して、Remdineのフィットギャップ分析が甘い点に原因があるだろう、と思う。

【3】では、Redmineのアンチパターンを「プロジェクト管理や開発プロセスの一般論」と「Redmineのフィットギャップ分析」で分類したら、どんな面白い内容が出てくるだろうか?

【3-1】まず、僕は、「プロジェクト管理や開発プロセスの一般論」のアンチパターンは、Redmineが機能豊富になるにつれて、最終的にはどんどん難易度が高くなるのではないか、と思う。
一般論の話は、実際にチケット管理して経験して、失敗したり、成功してみたら、すぐに理解できて解決できる。

よって、Redmineに上手く当てはまれば解決できるアンチパターンは、Redmineが誕生して10年経った今、知見やノウハウとして、普通の経験者は理解できているだろう。
そして、じきに、本来のユーザ利用要件をRedmineに当てはめられなくなった、というレベルまでたどり着いて、改めて考えなくてはならない、という方向に落ち着くだろう。

つまり、一般論の話で解決できないアンチパターンは、ソフトウェア開発やソフトウェア工学に関する本質的な問題まで辿り着くのではないか、と思う。

たとえば、チケットの粒度に関する議論は、ソフトウェア工学における「ソフトウェアの本質的な複雑性」に由来するがゆえに、そう簡単に解決できる話ではない、と思っている。

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

【3-2】一方、「Redmineのフィットギャップ分析」のアンチパターンでは、Redmineの標準機能で解決できる事例はどんどん公開されてしまい、最終的には、Redmineをカスタマイズすることでしか解決できないアンチパターンが多数出てくるだろう、と思う。

たとえば、最近よく聞くRedmineのFAQ~Excel添付のチケットから野良Redmineまで: プログラマの思索でもあげたが、ロードマップ画面におけるチケットの並び順をドラッグ・アンド・ドロップで制御する機能パッチは、アジャイル開発におけるプロダクトバックログ管理に相当する機能なのに、未だに実現されていない。
つまり、先進的なアジャイル開発のプラクティスをRemdineで運用したい、と思っても、Redmineの標準機能では不足しているのだ。

他に、MSProjectみたいにRedmineのガントチャートを使いたい、とか、色んな要望が出てくるだろう。

つまり、「Redmineのフィットギャップ分析」のアンチパターンを完全に解決するには、Redmineにプラグインを導入したり、Redmineそのものをカスタマイズする、という方向性が必要になる事例が数多く残ってくるのではないか、と思う。

【4】個人的には、Redmineのアンチパターンを上記の2種類の観点で区別した時に、下記のテーマがあると思う。

(1)既によく知られているアンチパターンは、上記2種類のどちらに分類されるか?

(2)未解決のアンチパターンの原因は、上記の考え方で合っているか?
そして、解決の方向性も、上記の考え方で進められるか?

この辺りも色々考えてみたい。

| | コメント (0)

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/31

Redmineに2要素認証のパッチが提供されている

Redmineに二要素認証のパッチが提供されているのでメモ。
次期バージョン4.0で設定されているので、じきに実装されるのでは、と推測する。

Patch #1237: Add support for one time passwords or two-factor authentication - Redmine

@g_maedaさんがレビューしてコメントされている。

(翻訳開始)
パッチを共有してくださったFelixとPlanioに感謝します。
2FAはアカウントを安全に保つのに役立ち、最新のクラウドベースのアプリケーションでは必須の機能なので、これは非常に優れた拡張機能だと思います。
多くのユーザーがこの機能を歓迎する必要があります。
私はパッチを試しました。 それは非常にうまく動作します。
(翻訳終了)

2要素認証方式は、ネットバンキングでも身近だ。
たぶん、スマホでセキュアなクラウドサービスを使っているならば、この認証方式が普通だろう。

実は知られていない、2段階認証アプリの落とし穴について | 仮想通貨のあるとこ

Redmineに2要素認証が追加されるメリットとしては、Redmineをよりセキュアに使いたい利用シーンで役立つだろう。
たとえば、社外へ公開しているRedmineでは、認証操作が甘いと、Redmineの情報が漏れてしまうリスクがある。
そのリスクを軽減するために、二要素認証をユーザに課すことは考えられる。

また、RedmineをSaaSで提供しているクラウド事業者にとっては、2要素認証の機能は非常に重要な機能要件になるだろう。
アプリそのものがよりセキュアに作られている、という証拠にもなるからだ。

パッチ後の管理画面を見ると、オプション機能で全ユーザに対し2要素認証の設定を各ユーザアカウント画面で有効・無効にできること、バックアップ用のQRコードを作成する機能があるようだ。
2要素認証では、スマホのようなクライアント機器が水没したりして無くなると、非常に困るので、バックアップ用QRコードは助かる。(それが漏れるとリスクありだが)

こういうセキュリティ強化につながる機能がどんどん実装されることで、Redmineがよりエンタープライズな業務やユースケースでも利用範囲が広がれば、Redmineの信頼性も増すだろう。
今後も注目していく。

| | コメント (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/25

統計学の考え方に関する感想

統計学を勉強してみて、気づいたこと、考えたことをメモ。
ラフなメモ書き。
以下は、自分が理解したいために、僕が理解した内容をラフスケッチで書き残す。
但し、自分はまだ統計初心者なので、間違っていたら後で直す。

【1】統計学という学問が最近、すごく重要になっているのはすぐに同意するのに、実際に理解しようとすると訳が分からなくなる。
IOT、AI、ビッグデータみたいなバズワードもあれば、心理学、経済学、疫学、国勢調査のように古くからの数多くの専門分野でも統計学の知識が語られていて、何が本質なのか分かりにくい。

【1-1】それぞれの学問では、統計学をやりたいのではなく、それぞれの学問で解決したい問題があり、その解決に統計学の手法を利用しているだけ。
だから、ベイズ統計の話は経済学で多かったり、因子分析の話は心理学やで多い、など、使われる統計手法も異なるみたい。
よって、初心者が勉強しようとすると、数多くの手法が紹介された情報を読んでしまって、逆に混乱してしまいがち。

【2】では、統計学の基本的な思想とは一体何なのか?

なお、以下の考えは、「経済数学の直観的方法 確率・統計編」に大きく影響を受けている。

【2-1】物理における古典力学の基本的思想に対応するものが、統計学では正規分布に相当する

統計学の計算方法を理解してくると、微積分や古典力学とは発想が大きく異なることに気づく。
考え方が全く違う、と思った方がいいと思う。

古典力学の発想は、自然現象はビリヤードみたいなもの。
粒子が衝突してどう飛ぶのか、微小な現象から全体の運動系を微分方程式を使って探し出す。

一方、「経済数学の直感的方法~確率統計編」を読んで理解した限り、確率・統計学の基本思想は、確率論ではなく誤差論にある。
統計学の発想では、真の誤差(ボラティリティ)は正規分布で表現されるので、正規分布の形さえ確定すれば、現象の確率を見極められる、というストーリー。

【2-2】統計学の発想では、自然現象における物事のバラツキは、トレンドとボラティリティの2種類がある。

トレンドは、ある傾向で偏りが発生するもの。
ボラティリティは、人の意思で制御できず、偶然の産物で発生するもの。

そして、トレンドに相当する部分は、人の知恵や改善によって解決できるが、ボラティリティの部分は人は制御できず、神様のサイコロに任せるしか無い、と考える。

このボラティリティの部分は、大数の法則によって、正規分布に近似される。
そこで、正規分布の形を把握できれば、自然現象の不確定な動きを予知できるようになる。

たとえば、トレンドとボラティリティという考え方は、製造業における大量生産の製品の統計的品質管理、あるいは、ファイナンスにおけるデリバティブ商品のリスクとリターンの考え方へ適用できる。

但し、全ての誤差の分布が正規分布に集約される、というわけではない。
誤差が非線形に発散する場合、色んな分布が提唱されているみたい。

【2-2-1】実際、製造業の品質管理では、量産した製品の品質のばらつきに対し、系統誤差(トレンド)と偶然誤差(ボラティリティ)に明確に分けるために、フィッシャーの3原則を適用する。
つまり、局所管理や無作為化の原則によって系統誤差を調整し、繰り返しの原則によって偶然誤差を調整する。

あるいは、品質管理において、バラツキの種類には、偶然原因によるバラツキ(トレンド)と異常原因によるバラツキ(ボラティリティ)と考える。

異常原因によるバラツキは、製造工程で何らかの不備があり発生した、と考えて、根本原因を追求し、是正処置を取って、バラツキをなくす。
偶然原因によるバラツキは、原因を調べても意味がないもの。
たとえば、正しい作業手順を作って、その作業手順にいくら従っても発生してしまうバラツキ。
つまり、トレンドは統計定期品質管理の技法を使って原因を除去するが、ボラティリティは対処しようがない。

【2-2-2】また、ファイナンスでは、ボラティリティが大きいほど、リスクは大きいがリターンも大きくなる。
そこで、たとえば、猛暑でリターンの大きい証券と冷夏でリターンの大きい証券を組合せて、リスクを減らして確実にリターンを得るように考慮する。
つまり、相関関数が-1になるように組合せる。

すると、証券を上手く組合せると、無リスク資産の概念が出てきて、これが最終的にはデリバティブのオプション価格として提供されるようになる。
その煙のようなオプション価格は、ブラック・ショールズ・モデルによって原理的に計算されるわけだ。

経済数学の直感的方法~確率統計編」では、微分方程式を発展させた確率微分方程式の背景には、トレンドとボラティリティを分離する、という思想があるという。
その思想を具体化したものが、伊藤の補題。
この伊藤の補題があったからこそ、ブラック・ショールズの公式が証明できた、というストーリーらしい。

【2-3】正規分布の形は、平均値と標準偏差の2つで決まる。

平均値は、正規分布の頂点。
標準偏差は、正規分布の頂点と変曲点の間の距離。
つまり、標準偏差が大きいほど、正規分布はなだらかな形になり、バラツキが大きい性質が導かれる。

物事の不確定な現象の動きを把握するために、正規分布を使う。
ある母集団の母平均と母分散が判明していれば、あるサンプルが正規分布のどこに位置するのかを、計算することで、そのサンプルが発生する確率を導ける。

この確率の計算が特殊。
確率は、正規分布の面積から求まる。
つまり、Z=(x-μ)/σでZ値を求めて、Z値から正規分布の面積を求めると、その面積が確率に相当する。
だから、昔は、正規分布の面積を簡単に計算できなかったので、正規分布表なる紙がいつも準備されていたわけだ。

【2-4】2つのサンプルの違いなどを把握するために、t検定、F検定、χ二乗検定などの推定を行う。
これらの検定処理で使うt分布、F分布、χ二乗分布は、正規分布の発想と同じ。

サンプルの測定値から、t値、F値、χ二乗値を計算して、各分布の面積を求めることで確率が出る。
その確率が5%未満ならば、帰無仮説が棄却されて、有意となる。
この有意という発想も、最初は理解しにくい。

僕の理解では、主張したい仮説を対立仮説、その逆を帰無仮説として提示する。
すると、帰無仮説が発生する確率が5%未満ならば、その帰無仮説が発生する事象は相当稀である。
ほとんど発生しないと言っていい。
そこで、背理法を拡張した確率的背理法によって、帰無仮説が発生する事象はほとんど起こらない、ゆえに、対立仮説は確率的にほぼ正しい、と導く。
この辺りは、用語も使い方も数学的にも厳密に証明されているみたい。

この検定処理を使って、2つの社会的集団に対して、補助金の政策効果、会社の人事施策の効果、マーケティングにおける販促の効果などを測定する、といった使い方を行うわけだ。
そして、そういう手法を行うための統計学的理論は揃っているので、後は、Webシステムとクラウド環境を使えば、いくらでもデータ収集できるし、いくらでもデータ分析できる、という流れなのだろう。

【2-5】相関関係があっても因果関係があるとは限らない

相関関数はわりと簡単に計算できる。
しかし、その解釈がすごく難しい。

2つの事象に対し、相関関数が大きければ、たしかに関係が深い、と分かるが、だからと言って、因果関係があるとは言い切れない。
ニセの相関関係、隠れた因子など、色んな観点で考慮しなくてはいけない。

「相関係数」ってなんですか? -意味と利点と欠点をわかりやすく- - Data Science by R and Python

つまり、相関関数の一つの値に、多様な現象の因果関係の意味がたくさん込められているから、解釈が難しいのだ。
一方、相関関数はデータさえ収集できれば、現代ならすぐに計算できる。
だから、解釈が難しくても、使われているのではないか。

【2-6】最近のWebやIOTでは、どんな傾向があるのか?

結論は、最近は、WebやIOTのおかげで、ランダム化比較試験を実施しやすくなった点だろう。
そのおかげで、いくらでも、多様な人間の集団に対して、色んな仮説を検証しやすくなった事があるのだろう。

Webとクラウドの環境さえあれば、ユーザにスマホやセンサー機器にデータを入力してもらい、いくらでも個人情報とその履歴を統計学の知識を用いて、仮説を検証すればいい。
この辺の考えは、下記にラフに書いた。

データ分析の面白さはどこにあるのか: プログラマの思索

データ分析の課題はどこにあるのか: プログラマの思索

すると、ランダム化比較試験がやりやすい環境とは何だろうか、という問題意識につながる。
個人情報保護法が厳しいほど、こういう実験がやりにくい。
そこで、オープンデータのような流れもある。

また、ユーザ数が多いほど、データを集めやすい。
おそらく、中国のように10億人以上のユーザがスマホを使って、決済やビジネスを行ってくれれば、そこに蓄積されるデータ量は、他の国よりも莫大だろう。
データという資源が多い国ほど、データ分析も有利、という考えが正しいならば、今後はそういう流れになるのではないか。

【2-6-1】しかし、現代はランダム化比較試験の環境を整えやすくなったと言っても、その前提条件を満たすように構築するのはそれなりに人もシステムも費用もかかる。

人の集団を介入群と非介入群の2つに分けようとしても、既にバイアスがかかっていると、本当に検証したい仮説をいくら立てても無意味になる。
むしろ、世の中の経済データ、マーケティングデータは、バイアスがかかって手垢の付いたデータばかりなので、そのデータをそのまま統計処理することはできない場合が多い。

統計処理できるパターンは、「自然実験」「回帰不連続設計法」「集計分析」「パネル・データ分析」など、限られた手法になる。
この辺りの問題点は、「データ分析の力 因果関係に迫る思考法」が詳しい。

【2-6-2】しかし、ランダム化比較試験を行うための環境を構築するための前提条件は、統計学の理論で既にある程度知られているようだ。

たとえば、フィッシャーの3原則がそうだろう。
あるいは、ランダム化比較試験の環境を作るために、層別サンプリング、集落サンプリング、系統サンプリングなどのサンプリング手法を使い分ければいい。

たとえば、製造業の品質管理の技法では、層別サンプリングがよく使われるみたい。
技法として、ヒストグラムやパレート図を頻繁に使うからだろう。

一方、心理学、教育学、経済学などでは、集落サンプリングがよく使われるように思える。
なぜなら、全ての人間の集団をテストできないので、母集団からランダムにあるクラスタ(集落)を選んで、その集落全員を試験対象にする方法を使うことで、母集団と同質でありながら狭い範囲の集団をテストすることで代用したいからだ。

今はExcelでも簡単に乱数を生成できるので、集落サンプリングがやりやすくなったこともあるのではないか。

| | コメント (0)

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

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

【追記】下記の要望があがっていた。
上記のRedmine連携プラグインは、astahモデルから、変更履歴や課題一覧、ToDoリストをRedmineへ外出ししているに過ぎない。
最終的には、モデル自身の構成管理、つまりモデルの変更履歴を保持する仕組みが必要になるだろう。
つまり、モデルのライフサイクルを管理する枠組みが必要になるのではないか。

岡本卓也さんのツイート: "Redmineチケットからastahダイアグラム方向への参照(クリックで図に飛ぶ)が出来ると素晴らしいのですが、そうなるとastahファイル自体がシングルトンで共有できてて欲しい。 と言うようなことを開発者の人とも話してました。… "

岡本卓也さんのツイート: "確かに現状では難しいですよね。ただ、モデリングの目的(の1つ)がコミュニケーションだとすると、モデルを共有して検討を積み上げる機能が欲しいなと。 astah Shareが健在なら、、ってよく思います。… "

| | コメント (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)

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