ソフトウェア工学

2018/03/29

SwaggerでWebAPIドキュメントをExcel仕様書から脱却するアイデア

Swaggerを使うと、WebAPIドキュメントをExcel仕様書から脱却してシステム化することができる。
自分はまだ無知なので、以下は自分用のメモのリンク。

【参考1】
【連載】Swagger入門 - 初めてのAPI仕様管理講座 [1] Swaggerとは|開発ソフトウェア|IT製品の事例・解説記事

(引用開始)
システム開発のトレンドとして、マイクロサービス化が進んできています。モノリス(一枚岩)スタイルの開発に比べて、アプリケーションの単位は小さくなり、多くのサービスが構築されます。

Uberの配車ビジネスやAirbnbの民泊に代表されるデジタルビジネスにおいても、APIエコノミー化が進んできており、Google Map APIやTwitter APIなどさまざまなAPIを組み合わせて素早くシステムを構築します。
Programmable Webでは、2017年1月時点で16,590以上のAPIが検索可能で、2009年9月の10倍以上、2006年5月の90倍近くに達しています。

では、そういったマイクロサービス・APIエコノミーの開発現場では、一体どのようなことが起こっているのでしょうか。

例えば、Androidのアプリから叩いているサーバのAPIが機能追加されたために、3日間かけてテストして終わったと思ったら、いつのまにか更なる仕様変更が入っていた。APIのインタフェースを定義するドキュメントの仕様に従ってアクセスしたら、実は実装との乖離があり、うまく動かなかった。

このようにAPIプロバイダとAPIコンシューマ間の悩みはさまざまです。ただし、いずれもサービスインに影響を及ぼす重大な問題と言えます。インタフェースの向こうの世界は関与できないことが多いだけに、仕様と実装の乖離はあってはならないものなのです。
APIエコノミーを作るにあたり、このようなことを起こさないためにも、APIについて正しく記述した仕様書が必要となってきます。
(引用終了)

【参考2】
Swaggerとは何か? - プログラマでありたい

Swaggerを使ってインタラクティブなWeb APIドキュメントをつくる - Qiita

SwaggerでRESTful APIの管理を楽にする - Qiita

Swaggerの概要をまとめてみた。 - Qiita

【Swaggerの実例】
API リファレンス | SORACOM Developers

【1】Webシステムをモノリック・アーキテクチャからマイクロサービス・アーキテクチャで設計することで、まるで部品を組み立てるかのように、迅速にシステムを構築することが可能になった。
つまり、斬新なアイデアを実現するWebサービスを素早くリリースして、市場のニッチリーダーからシェア独占を狙って、先行者利益という独占利潤を得たいわけだ。

例えば、Uberの配車ビジネスやAirbnbの民泊。
日本なら、例えば、メルカリ、DMMとか。

現代は、これらシリコンバレー発祥のWebサービスが、自動車業界やホテル業界を直撃している、と言える。
よって、マイクロサービス・アーキテクチャで作られたWebサービスは、ありとあらゆる業界のビジネスモデルを一瞬にして破壊してしまう可能性が高い。
だから、こういうAPIエコノミーに対し、古い業界の人達も戦わざるを得ない。

【2】しかし、マイクロサービス・アーキテクチャの根幹となるWebAPIは、VerUpによってコロコロ変わってしまう問題がある。
そこで、I/F仕様をWebで公開して、即時に情報共有できるようにしたい。

つまり、マイクロサービス・アーキテクチャの実装基盤であるREST APIのI/F仕様を公開できるようなWeb基盤が欲しいわけだ。

【3】そこで、その候補として、Swaggerがあがる。
Swaggerの特徴は、「インタラクティブなWeb APIドキュメント」。

つまり、単純にWebへ公開できるドキュメントが作成できるだけでなく、リクエストを入力すればレスポンスを表示できる仕組みまである。
すなわち、APIをWebに公開できるだけでなく、使用しているAPIがVerUpしても使えるかどうか、事前に自動テストすることも可能。
これによって、Webサービスをリリースする時、利用しているAPIが使えなくなった、というリスクを減らすことができる。

たとえば、ソラコムさんのWebサイトが最も良い事例だろう。

API リファレンス | SORACOM Developers

上記の記事にもあるが、Dockerによるビルド環境構築やCIツールをSwaggerと組み合わせれば、マイクロサービスで組み立てたWebサービスの自動テスト、デプロイやリリース作業の自動化にもつながるだろう。
つまり、マイクロサービスで作られたWebサービスの品質向上、開発速度の向上にも役立てられるはず。

但し、Swaggerで全ての問題が解決されるわけではなく、まだ課題もある。
たとえば、Swaggerて゛のapi開発よもやま話の18ページにあるように、たくさんのAPIを一瞥できるような『オブジェクト構造図(仕様書のObjectの参照関係を階層構造で定義)』が欲しくなる。

【4】今の僕は、Excel仕様書からいかに脱却するか、というテーマを持っているが、その中でも、I/F仕様書は色んな意味で重要性が高い。

なぜなら、公開したI/Fというものは、自分のチーム以外の他チームも参照するので、説明責任が発生するし、I/Fの仕様はシステムのVerUpによって変わってしまう時が多いのに、その変更内容をExcelドキュメントへ反映する手間が結構かかるからだ。
しかも、I/FがVerUpで変わった、という事実を他チームにも随時連絡する手間も発生する。

よって、I/Fが変わったら、自チームがプッシュ通知するのではなく、他チームがプル通知で自動検知する仕組みの方が運用が楽になる。
そこで、SwaggerのようなWebAPIドキュメントの基盤を有効に活用できるだろう、と思う。

【4-1】ここで、I/F仕様書がSwaggerで置き換えられる可能性を考えると、現代という時代は、Excelドキュメントを一生懸命に書くよりも、仕様書というモノさえプログラミングする時代なのだ、という気がしてくる。

実際、単体・結合テストなどのテスト工程の作業は、TDDやCIなどの開発支援ツールでプログラミング作業に集約できる。
また、デプロイやリリース作業、そしてビルド環境や本番環境のインフラ構築作業も、DockerやGitHub、CIツール、AWSなどのクラウド環境などの技術によって、プログラミング作業で代替できるようになった。

今後は、要件定義や設計作業ではExcelドキュメントを書く、という作業も、きっとプログラミング作業で代替されるようになるだろう。
つまり、いちいち自然言語で要件や仕様を書くよりも、YAMLやJSONに似たデータ構造あるいはDSLによって、いきなりプログラムを書いた方が速いし、その後の保守更新も楽になる、という方向へ進化していくはずだ。

仕様書をプログラミング作業の本体であるテキストで代替できれば、Gitで管理できるし、そうすれば、TDD・CI・プルリクエスト・継続的デプロイなど昨今の開発支援技術の恩恵を受けられる。
よって、ドキュメントの情報共有が促進され、フィードバックを受けて修正すれば、仕様書の品質そのものも向上できるはず。

では、仕様書のExcel脱却の起点となる課題は何か?
答えは、Gitで管理できるか、そして、テキストからAPI仕様書や図表などを自動生成できるか、という課題に集約されるだろう、と思う。
幸いなことに、MarkdownやPlantUMLなどの記法でテキスト化すれば、HTMLやOfficeドキュメント、PDFへ自動生成するツール(Pandoc、MkDoc、他たくさん)で、今まさにたくさんの技術が実験されている。

この辺りの技術も、技術の進化の歴史の観点で今後整理していきたい。

| | コメント (0)

2018/03/23

製造業の品質管理の背後にあるSDCAという考え方をソフトウェア開発に適用できるのか

製造業の品質管理を調べてみて、その背後には、「SDCA」という考え方があるのではないか、と考えてみた。
ロジカルでないラフなメモ書き。

【参考】
日常管理 - エクセルQC館

PDCAサイクルとSDCAサイクル【品質改善と維持管理の考え方】

mame1

「当社の業務改善サイクルは『SDCA』」 トステム 佐藤方厚 執行役員IT推進統轄部統轄部長 | 日経 xTECH(クロステック)

【1】製造業の品質管理では、「標準化(Standard)」という言葉が頻繁に使われる。
彼らの意図としては、定型化できる作業、皆が知るべき技術ノウハウは標準マニュアルで整備して、安定した状態(品質)にすべき、という考え方がある。

たとえば、工場で大量生産するネジを作る時、不良品がたくさんできて歩溜まりが低いと、製造原価が高くなってしまう。
製造作業が不安定であると、製品の品質のブレが大きくなってしまうからだ。
つまり、管理図で言えば、UCLやLCLを超えた製品が多くなり、品質不良として出荷できなくなることを意味する。

そこで、ベストプラクティスを標準化という名の下に作業マニュアルにしてしまい、作業員はその作業マニュアルに従って作業すれば、安定した品質となり、歩溜まりが向上する、という方向へ持っていく。

その考え方をプロセスとして定めると、SDCA(標準→Do→Check→Action)という流れになる。
まずは標準を守って、そこから実施して評価し、是正対策を取って、標準を更新していく、という流れ。
つまり、PDCAサイクルで品質統制を行う発想だ。

このプロセスは、量産品を作るメーカーだけでなく、チェーン展開するサービス業や飲食店などにも適用しやすい。
どこに言っても同じサービスや料理の味を低価格でそこそこの品質で提供する、というやり方が向いているからだ。
たとえば、大量のアルバイトや社員を雇ったサービス業として、コンビニ、小売業、航空機内の客室乗務員、ホテルのオペレータとか。

また、個人経営の飲食店であっても、毎日提供する料理の品質を安定させることができれば、原価低減でき、利益を安定的に確保しやすくなる。

【2】しかし、昨今の時代の流れの中で、特にソフトウェア開発では、SDCAの考え方は向いていないと思う。

たとえば、業務ルールを策定したり、技術ノウハウを共有したい、と考えるWF型開発に偏ったプロジェクトリーダーは、Excelドキュメントでそれらをまとめて、共有ファイルサーバーに置いて、メールで告知して共有しようとする。
しかし、その内容はすぐに忘れられて、同じようなことを何度も繰り返す。

あるいは、社内の標準プロセスを定めて、設計書テンプレートのExcelドキュメントを作り、すべての案件に適用しようとするが、受託開発から保守案件、実費請求の要件定義案件まで多種多様なPJがあると、一つの標準では当てはまらない。
結局、数多くのカスタマイズによる派生ドキュメントが発生し、標準からどんどん離れていってしまう。

組込みソフトウェア開発のプロセス改善の違和感: プログラマの思索

【3】では、なぜ、ソフトウェア開発では標準化という考え方が上手くいかないのだろうか?

僕の考えでは2つあると直感的に思う。

【3-1】一つは、ソフトウェア開発は、組織能力よりも、個人のパフォーマンスに依存する度合いが強い事があると思う。

ソフトウェア開発では、システムの技術ノウハウや設計ノウハウは人に付いて回る。
たとえば、受託開発したシステムを本番リリース後、大量の派遣・委託のプログラマが抜けると、システムに関する知見もチームから失われ、保守コストがどんどん大きくなる、という事例はよく見かける。
そのために、数多くの設計ドキュメント、ノウハウを書いたExcelドキュメントを大量に残すけれど、結局役立たない。
システムは保守するたびにどんどん変化していくので、それらドキュメントも古くなり陳腐化してしまう。

また、新しい技術の知見も人に付いて回る。
ドキュメントを読むよりも、その人に聞いたり、レクチャを受けた方が速い。

「現場から始めるアジャイルの技術プラクティス」資料が素晴らしい~技術は人やチームに残る: プログラマの思索

すなわち、標準化しようとしても、形式知化できない部分があるし、暗黙知の部分の方が大きすぎる。
ゆえに、ソフトウェア開発の生産性は個人の能力に依存する度合いが大きく、それを組織で維持ししていくのは非常に難しい。
よって、個人のパフォーマンスを最大限に発揮できるような環境や組織体制を整備する方向へ持っていくべき、というのが最近の時代の流れなのだろう。

たとえば、議論しやすい場を設けてお菓子を用意する、プログラマが座る椅子を高価なものにする、最新のPCやサーバーを用意する、などのファシリティ(資産)が重要な理由は、個人のパフォーマンスを発揮できる環境づくり、という意味もあるのだろう。

そして、アジャイル開発がプログラマに好まれる理由の一つは、アジャイル開発は組織駆動ではなく、個人のパフォーマンス駆動であり、人重視のプロセスでやり抜く、という点にあるのだろう。

だから、人を大切にすることで、システム開発で得られた知見をチームに残す、という発想につながるのではないか。

アジャイル開発とウォーターフォール型開発の違いについて再考: プログラマの思索

【3-2】もう一つは、Excelドキュメントと相性が悪い点もあるように思う。

技術革新が速いので、Excelドキュメントに書いても、陳腐化してしまう。
Excelドキュメントの賞味期限が短すぎるのだ。

そして、Excelドキュメントは履歴管理しにくいし、検索しにくい。
日付の入ったファイル名のExcelが増殖し、最新の内容がどこにあるのか、作った人も分からなくなる時もある。

そこで、技術ノウハウはWikiに書いて残す、という手法もある。
もちろん、Wikiの内容も陳腐化してしまう可能性は高いが、Webで公開されていれば、他の人が気づいて更新することもできる。
全文検索エンジンによって、有用な情報だけ探す、ということもできる。

標準化した情報がすぐに陳腐化してしまうなら、その内容を即座に更新できたり、それらを即座に共有できたりする基盤があれば、ある程度は解決できるはずだ。
この辺りの内容は、一つのテーマとして、ずっと考えている。

仕様書にもExcel脱却が求められている: プログラマの思索

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア: プログラマの思索

【4】SDCAという考え方が合わない場面が増えているのは、定形業務のビジネスモデルが最近は儲かりにくい、という点にもあるのだろう。
「Software is eating the world」という流れでは、定形業務や低賃金労働は全てソフトウェア化できるし、ソフトウェア化されたビジネスは、限界費用ゼロまでコストが徹底的に低くなる。
すると、人間の手でSDCAサイクルを回して品質管理をやっていく、という悠長なやり方は通用しにくくなるのではないか。

「ソフトウェアが世界を飲み込む理由」「ソフトウエア、それが問題だ」の記事のメモ: プログラマの思索

『ソフトウェアが世界を飲み込む理由』 - 渡部薫 ジークラウド CEO - 経歴・略歴 - Kaoru Watanabe, Profile, Career

ソフトウェアが世界を変えている – うめのんブログ

この辺りも整理してみる。

| | コメント (0)

2018/03/21

静的ジェネレータを使ってExcelマニュアルをWeb公開するアイデア

ちょっとしたExcelマニュアルの内容を公開する仕事があって、色々調べたこと、考えたことをラフなメモ書き。

【参考1・MkDocs】
MkDocs

ドキュメント作成ツール > MkDocs - Qiita

MkDocsでドキュメント管理 - notebook

ドキュメント生成ツール「MkDocs」でRedmine Guide日本語訳のWebサイトを作ってみた - ファーエンドテクノロジー株式会社

【参考2・Jekyll】
まだWordPressで消耗してるの?Netlify CMSでブログを作成しよう! - Qiita

Jekyll ? シンプルで、ブログのような、静的サイト

Jekyllで作るシンプルWebサイト - Jekyllとはなにか | CodeGrid

GitHub Pages の Jekyll で Web サイトを無料公開する方法 - Qiita

【1】Excelマニュアルの問題点

IT業界では、設計書のたぐいは、とにかくExcelでマニュアルを作りたがる。
インストールマニュアル、製品マニュアル、運用マニュアルなど。

Excelマニュアルの一番の問題は、誰も見なくなることだ。
共有ファイルサーバーにExcelマニュアルを置いてメールで連絡しても、そこにたどり着いて、Officeファイルを開かなければ見れない。

マニュアルを作った本人としては、皆に周知して使ってもらいたいのに、いつも、どこにあるのですか?という問合せばかり受ける。
こういうExcelマニュアルのたぐいは、社内イントラ上で公開できればいいのに、といつも思っている。

また、社内ポータルにリンクを貼っておけば、検索エンジンや更新案内で、勝手に見てくれるようになる。
つまり、マニュアル設計者がプル戦略で周知できる仕組みを作ればいいはず。
すなわち、多数のユーザが自ら情報を引き出すような仕組みを作ればいい。
プロモーション戦略におけるプル戦略と考え方は同じ。

では、マニュアルをプル戦略で公開する仕組みはどう作ればいいか?

【2】静的ジェネレータの使い道

【2-1】マニュアルのようにドキュメントの構成が統一的で簡単であるならば、静的ジェネレータでHTMLを自動生成してApacheで公開するのが一番簡単だ。
静的ファイルを配置するだけでいい。

この発想に落ち着くまでに、CMSのような製品も必要か色々考えてみた。
しかし、複雑なドキュメントを書くのでなければ、静的ジェネレータでHTMLを生成するので十分。

たとえば、OSSのCMSならば、WordPressが一番有名だ。
ブラウザ上で更新できるし、管理画面や機能も豊富だ。

しかし、公開後のアプリ保守やインフラ保守を考えると、セキュリティパッチやVerUpのたびにWordPress本体の保守作業が発生して、かなり手間がかかる。
また、機能改善のためにプラグインを導入せざるを得ないが、WordPress本体のVerUpでプラグインの動作保証まで検証するコストも発生してしまう。
つまり、その後の保守コストが結構かかってしまう。

一方、静的ジェネレータであれば、普通は、Markdownでドキュメントを自然言語で書けるし、CSSやJavaScriptでプログラミング・ライクに装飾できるし、Gitのようなバージョン管理ツールと相性も良い。
Gitでバージョン管理できれば、ビルド管理やデプロイ管理も、今までの自分が持っているノウハウで自由にカスタマイズできるし運用しやすくなる。

ドキュメントの中身を保守更新することを考えると、コンテンツそのものはMarkdownでテキスト化してGitで管理して、いつでもビルド・デプロイできる環境を作っておいた方が良いと思った。

【2-2】では、お勧めの静的ジェネレータは何が良いのか?

単純なExcelマニュアルの元ネタは、Markdownやマインドマップで書いているので、個人的には、MkDocsで十分だった。

Pythonを入れて、インストール
pip install mkdocs

MkDocプロジェクトを作り、Markdownでどんどんテキストに書いていく。
mkdocs new my-project
cd my-project

書いたら、localhost上でプレビューしながらチェックする
mkdocs serve

ビルドしてHTMLを生成したら、それをAacpheへアップして公開するだけ
mkdocs build

他の記事を探してみると、CMS代わりの静的ジェネレータは色々あるみたい。
個人的には、Ruby製のJekyllを触っていて、Blogコンテンツを移行できないかなあ、とか思っている。

Jekyllのメリットは、Blog記事をMarkdownで書き溜めておけば、GithubPagesでそのままWeb公開できる仕組みがあるからだ。
GitHubでバージョン管理して、静的HTMLをビルドしたら、GithubPagesへデプロイするような仕組みを作っておけばいい。

もちろん、静的ジェネレータは他にも色々ある。
大量のMarkdownドキュメントになってくると、もっと他の選択肢が必要になるのかな、と思う。

静的サイトジェネレーターは脱CMSなブログが作れるツール | Qookie Tech

WordPressの代わりになる!2018年注目の静的サイトジェネレーター6選|ferret [フェレット]

静的サイトジェネレータを比較してみた - Qiita

【3】他の解決方法

【3-1】一昔前なら、PukiwikiのようなWikiで、こういうノウハウを書いて社内で共有するのが一般的だった。
最近はQiitaのように、技術ノウハウをWeb上で記述してストックし、公開して知見を共有するスタイルが流行しているように思う。

つまり、静的ジェネレータが最善の解決策ではない、とは思っている。

でも、製品マニュアルや技術ノウハウなど、不特定多数のユーザに情報共有したい内容をExcelマニュアルでまとめるのは、もう時代遅れではないか、と思う。
Qiitaにせよ静的ジェネレータにせよ、Web上で公開する仕組みが時代として要求されている、と感じる。

自分では大したことはない、と思う情報であっても、インターネット上あるいは社内イントラ上で公開されていれば、他の人が検索エンジンによっていつでも探し出すことができる。
つまり、検索しようとする人たちが、そのコンテンツに新たな価値を見出してくれるわけだ。

【3-2】Qiitaが静的ジェネレータよりも優れている点は、コメントやリンク、いいね、タグ機能など、著者と読者がインタラクティブにコミュニケーション出来る環境を提供している点だろう。
それによって、著者もフィードバックから得るものがあるし、他の記事と相互リンクすることで、記事の価値も高まる。
自分のアイデア、得られたノウハウは、一人で貯めておくよりも、Webで公開した方が、読者によって新たな価値を創りだしてくれるメリットがある。

【4】最近の自分のテーマは、Excelドキュメントをいかにテキスト化して、Gitのバージョン管理の配下に置けるようにできないか、だ。
それについては下記で色々考えていて、まだ試行錯誤中。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

今回の静的ジェネレータの件も、Excelマニュアルをいかに駆逐するか、という点で方向性は同じ。

プログラムだけでなく、設計書やマニュアル、ブログ、プレゼン資料のような自然言語で書くドキュメントも、Gitで構成管理できるようになれば、昨今の開発環境の技術革新の恩恵を受けられるはず。
このアイデアがどこまで実現可能で、どこまで問題や課題をクリアしてくれるのか、考え続けている。

| | コメント (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は組織に従うのか、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のようなソフトウェアのレイヤーで抽象的なレベルで設計しようとしているように思える。

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

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

【追記】
STAMPについての分かりやすい記事が紹介されている。

STAMP/STPAとは何か (4/4) - MONOist(モノイスト)

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

より以前の記事一覧