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

Swaggerて゛のapi開発よもやま話 from KEISUKE KONISHI

【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、他たくさん）で、今まさにたくさんの技術が実験されている。

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

自分の天分を知るとは何だろうか

ネットでウロウロしていたら、『物理の道しるべ―研究者の道とは何か』に関して、物理学者が自分の天分を知る事について記事があったのでメモ。
すごく心を揺さぶられた。
以下はラフなメモ。

【参考】
『物理の道しるべ―研究者の道とは何か』を読んだ - shiroshippo's blog

(引用開始)
少し前に読んだ。
元は雑誌『数理科学』の連載で，物理学者たちがその人生について振り返ったエッセイを集めたもの。
出てくる先生の人生も，運とか人のつながりで決まってるんだなと思った。

p.154, 155から引用。
私が物性理論という分野を選ぶまでにはいろいろな紆余曲折がありました。
高校時代は数学が3度のご飯より好きで，東大の理科I類に入学したときには当然数学科に進むつもりでいました。
実際，当時の雰囲気は最もできる学生が数学科に進学するという感じだったのです。
ご存じのように，東大では最初の2年間は駒場で教養課程を修了し，その後（実際は1年の夏休み明けごろに）学部・学科を決めるという進学振り分け制度が行われています。
その駒場での2年間，自分の適性というものを試してみるチャンスがあったわけです。

まず，大きな期待を持っていた数学ですが，すぐに自分には無理だとわかりました。
解析は良かったのですが，線形代数の講義が，いきなり体とか環とか抽象的なものばかり出てきて，公理・定理・補題…の連続に頭が痛くなってしまったからです。
その反動か，今度はドイツ文学や哲学に惹かれて文学部に進もうかと考えたり，そうかと思うと今度は化学こそは現実の世界に最も肉迫できる学問だと考えていろいろ勉強したりしていました。

ちょうどそのとき，化学の授業で「試薬分析」の課題がありました。
いろいろな試薬を使った反応を見て，試験管の中の未知の物質Xを決定せよ，という課題で，私はその日が来る前から十分な準備をして，「完璧な」場合分けの系統図を作り，どのような物質Xに対しても必ず決定できる方法を持って臨んだわけです。
ところが当日になると，匂いを嗅いだりして大体の「あたり」を勘でつけて，2, 3個の試薬を試して「わかった。
これはXXだ」と正解を出してしまった友人が近くにいたのです。

結局最後の一人になってようやく分析を終えた私に，担当の助手の先生が「君は理論に進んだ方がいいと思うね」とおっしゃったとき，人にはそれぞれの天分というものがあると実感しました。
抽象性と具象性の1次元座標を作ったときに学問分野に応じた抽象度というものがあって，数学を左端だとすると，素粒子理論，物性理論，物性実験，素粒子実験，化学，生物，医学というように並んでいてそれぞれの人に最適のところがあるのだと思います。

こういう風に，大学で何を専攻しようか迷っていた人は結構おおい。
(引用終了)

自分では理解できない現象に出会った時、自分の中でどう対処するのか？
現実問題として、生きていく中で、自分の中の知的誠実さを維持しながら、どうやって折り合いをつけていくのか？

４０歳を過ぎてもまだ分からない人もいるし、２０代で使命を見つけた人もいる。
自分が本当にやりたいこと、自分の使命とは何だろうか？
自分の天分とは何だろうか？

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

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

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

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

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

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

カイゼンジャーニーの感想～アジャイルサムライの再来かな

「カイゼンジャーニー」を一気に読んだ。
昔読んだ「アジャイルサムライ」の雰囲気に似ている。

興奮しすぎて、理解した内容をまとめきれていないけど、ラフなメモ書き。
付箋を引いた所だけ、思いつくまま書いておく。
ロジカルでないので、後で直す。

【感想】
akipiiさんのツイート: "カイゼン・ジャーニーを一気に読んだ。スクラムからモダンアジャイルまでのプラクティス、著者の経験に裏打ちされたノウハウを文章の背後からすごく感じる。アジャイルサムライの日本版だなあ。 https://t.co/B54C8o2Dw2"

akipiiさんのツイート: "素晴らしい本で凄く惹き込まれました。コラムの知識もウンウンと頷くと共に、中身の濃い本と思いました。ストーリー形式もいいですね。… "

【1】(P.80)「何のために、このチームは、こんな追い立てられるように仕事しているの？」
「ベロシティを上げることを目的とする限り、このチームは目先のタスクに圧倒され続けるやろうね。みんながそれを選択してしまっている。」

ソフトウェア開発の途中では、当初のゴールや目的を忘れて、日々のアウトプットを作るだけになってしまう時がある。
タスクの消化だけに目が向いている。
しかし、実際に作り上げたシステムは、受け入れテストで実は顧客の思いと違っていた、という結果になる事態は経験上よくある。

「カイゼンジャーニー」はここでインセプションデッキを使う。
紹介されているインセプションデッキは、筆者独自にカスタマイズされている。
そのノウハウを読むと、数多くの現場で叩かれて、鍛えあげられたのだろう、とその背景を想像してしまう。

【2】(P.117)狩野モデル

狩野モデルと商品企画：部門別スキル - 品質管理なら日本科学技術連盟

チームが狙うべきシステムの品質を狩野モデルの3つの品質で区別しようとしている。
「カイゼンジャーニー」の文脈では、アーキテクチャや開発基盤を安定させることを重視する当たり前品質から攻めるのか、iPhoneのようにユーザエクスペリエンスを重視した魅力的品質から攻めるのか、作戦を考えるべきだ、という。

僕は、狩野モデルをメーカーのハードウェア製品の観点で理解することしか知らなかったから、ソフトウェア開発における狩野モデルに軽いカルチャーショックを受けた。

製造業の品質管理における狩野モデルでも、機能安全を重視する当たり前品質から攻めるか、iPhoneや一時期のソニー製品のような魅力的品質から攻めるか、という観点が同様にある。

もう一つの別の狩野モデルの観点では、製品ライフサイクルによって、魅力的品質→一元的品質→当たり前品質へと顧客から見た品質の観念が変わっていく、と言う考え方もある。
たとえば、販売当初の熱気がある頃は魅力的品質があれば多少のキズも大目に見てもらえるが、売れ出して一巡すると、ユーザはちょっとした機能不足に不満を感じ、最終的には、そういう機能はあって当然でしょ、みたいな感覚となり、シビアに見られてしまう。
僕はむしろそちらの方がしっくりいく。

【3】(P.162)タックマンモデル

この理論も僕は好きだ。

タックマンモデルとチームビルディング – ゲームを用いて貴社のチームビルディング研修,グループワーク,階層別研修をサポートします | 株式会社HEART QUAKE

似たような話として、「世界で闘うプロダクトマネージャになるための本」の中では、プロダクトマネージャが持つべきスキルの一つとして「転換点を意識する」というものがあった。
プロジェクトの中で、ある時点（転換点）を超えると、急に決断しやすくなったり、状況が大きく変わる時がある。
そういう転換点を意識して乗り越えるようにすべきだ、と。

タックマンモデルでいう「雨降って地固まる」みたいな転換点を意識して作り出し、それを乗り越えるように、プロジェクトリーダーはそういうスキルを準備すべきなのだろう。

【4】(P.175)モダンアジャイル

Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける
(引用終了)

2001年のアジャイル原則は、確かに時代から少しずつズレている気はする。
もっと今風の言葉で、2018年の現在に合うような言葉で言い換えたくなる。

心理的安全という言葉は、「アジャイル開発は、組織駆動ではなく、個人のパフォーマンス駆動で行うものだ」という観点では、個人の安全欲求が満たされた状態で本来のパフォーマンスを発揮してもらうための環境づくり、とも言い換えられると思う。

【5】(P.219)仮説キャンパス、(P.234)ユーザーストーリーマッピング

リーンキャンパス、ビジネスモデルキャンパスは僕も一時期、使ってみようとして色々試してみたが、まだしっくりきていない。
たぶん、ぼくの理解が未熟だからだろう。

ユーザーストーリーマッピングも実戦で試せてないので、本を読んでみると試したくなってくる。
実際の理論と現実の狭間、衝突が面白いのだ。

【6】(P.251)SL理論

リーダーシップの状況適合理論も、僕は好きだ。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

プロジェクトリーダーとして、チーム運営する時に、リーダーシップを発揮せざるを得ない状況になった時、チームの成熟度に応じて、自分はどんなリーダーシップの振る舞いをすべきか、をこの理論は教えてくれる。
自分の振る舞いとチームの現実が合わない場合、裸の王様に近い感じになる。

【7】(P.255)ハンガーフライト

僕がハンガーフライトと似たような感覚を持つ場所は、新しいコミュニティを立ち上げる時だ。
自分で何かをやりたい、と思った時、傍に同志がいて、彼らと夢を語り、そのエネルギーを使ってコミュニティを立ち上げる。
初めてやってみるのは多少怖いけれど、やってみれば意外に報われる時が多い。

【8】他のプラクティスにも、僕が知らないものもあったし、今までの経験でモヤモヤしていたものが「カイゼンジャーニー」を読んで改めて気づかされたものもあった。
また感想を書いておく。

アジャイル開発とウォーターフォール型開発の違いについて再考

「カイゼンジャーニー」を一気に読んだ後で、もう一度、アジャイル開発とは何なのか、現時点で考えを整理しておく。
自分の中の暗黙知を整理するのにとても役立ったので、下記の記事をリンクしておく。
特に主張なし。

【１】アジャイル開発では「個人のパフォーマンスで駆動」されるので、チームワークや心理的安全を重視する。
一方、WF型開発では、プロジェクトの成功を「組織の力で担保」する。

となると、先日の冬季オリンピックで、日本女子がパシュートで金メダルを取った事例を振り返ると、日本人は組織の力を重視する方が好きなのか？
ならば、個人のパフォーマンスで駆動する開発プロセスを志向するアジャイル開発は、日本人の文化とは本来合わないものなのか？

アジャイルとウォーターフォールは文化や価値観のレベルで異なるという話 - たなかこういちの開発ノート

(引用開始)
このプロジェクトでは“本物”の「スクラム」を実施していました。アジャイル手法をほんとうに実践している現場の経験は初めてでした。
当初は本当に戸惑いました。
自分が“普通の”エンタープライズ・システム開発でPMを務めるようなときは、Unified Processの「アーキテクチャー・セントリック」や「リスク・ドリブン」を意識しつつ、要件たる機能セットの全体を明らかにして、スコープ管理を重視したスタイルで進めます。
今回のプロジェクトでは、スクラムとして「バックログ」としてタスクが列挙されはしていますが、システムのアーキテクチャーや機能スコープの管理がされているようには思えず、「これで破綻無くゴールできるのか？」と大いに不安を感じました。
（引用終了）

(引用開始)
そして、得られた一定の理解は次のようなものです。
「アジャイル」の本質は、「イテレーティブに進める」などというところには無い。
本質は「メンバー個々が個々としてプロジェクトあるいはプロダクトにコミットし、メンバー個々が如何にすればプロジェクトの成功あるいはプロダクトの完成に貢献できるか、自ら強いオーナーシップをもって考える、その点にいわば賭けている」、という点にある。

対して、ウォーターフォールの本質は、「プロジェクトの成功あるいはプロダクトの完成を、組織として仕組みとして担保しよう」と考えている点にあると言える。
よく"Collaboration and Teamwork" vs. "Command and Control"などのフレーズで対比されます。「個人の力」を信じるか、「組織の力」でこその安心か。。
このような“文化的背景の違い”からみれば、Unified Processもほとんどウォーターフォールの一変種でしかありません。

「イテレーティブ」という点では、アジャイル系方法論もUnified Processも類似に見えます。
しかし、個人のパフォーマンスで駆動しようとするか、組織の仕組みで駆動しようとするか、その価値の置き方は全く異なります。
（引用終了）

【１－２】アジャイルにおける「計画」とは優先順位を見極めること。
一方、WF型開発の「計画」は、QCDの決定事項であり、予実管理すべきもの。

(引用開始)
また、アジャイルとウォーターフォールでは「計画」に対する考え方が全く異なると感じました。
ウォーターフォールでは、スケジュールと機能スコープが示され、それに対して必要リソース（お金や人）を見積もり、Work Breakdown Structureを作成したりします。
投入可能リソースによって、スケジュールやスコープを調整するものの、それで決定された「計画」は、基本的に遵守すべき事項となり、その「計画」を達成することを目的にしてプロジェクトは進みます。
「計画」通りに進捗しない事象が生じた場合は、リソース配分を調整し、WBSを組み替え、新たなクリティカル・パスを構築します。

アジャイル（※ここでは主にスクラムでの考え方に基づきます）では、最初にリソース（主に人）を制約として捉えます。まずメンバーが具体的に決定されます。
その具体的なリソース（メンバー）は一定期間にどれだけの開発パフォーマンスを出せるのか実測します。（スクラム用語で「ベロシティ」と言います。）
それにより、このチームが一定期間に達成できそうな開発量の見通しを立てることができます。そして開発タスクを優先順位をつけて順次消化していきます。
目標への見通しはあるものの、そこには「いつまでに何を」というかたちで管理され遵守されるべきという意味での「計画」はありません。
アジャイルにおける「計画」とは優先順位を見極めることです。
（引用終了）

【２】アジャイル開発では「全部つくらない」を前提とする。
一方、WF型開発では、「全部つくること」を前提とするので、請負契約と相性が良い。
だから、日本のIT業界では、発注側が委託ベンダーにリスクを一方的に背負わせる方向に向くために、請負契約から離れられない。

アジャイル開発の本質 ? アジャイルとウォーターフォールの違いとは | Social Change!

(引用開始)
アジャイルとウォーターフォールの本質的な違いは、プラクティスを実践するかどうかではなく、手順として繰り返し型にするかどうかではなく、「全部つくらない」を前提とするか「全部つくること」を前提とするかの違いだと考えています。昔あったスパイラルとかRUPとかありましたが、それも「全部つくること」を前提にしていたように思います。だからうまくいかなかった。ただ繰り返しても駄目なんです。

私がシステムインテグレーターで働いていた頃に、プロジェクトをアジャイルに進めるために多くの人に協力や説得をしてまわったことがあります。そこで出た意見が以下のようなものでした。

「アジャイルとは、つまり、これまでのプロジェクトでやってきたようなベストプラクティスを取り入れるということかね？」
「ウォーターフォールでも、ふりかえりとかテスト駆動開発とかを取り入れてやってきたんだけど、それとは何が違うんだ？」

一括請負でビジネスをしているシステムインテグレーターにとっては、システムを完成させることがゴールであり、全部つくることでお客さまに検収してもらえて報酬が支払われます。つまり「全部作ること」こそが仕事な訳です。そんな中で「全部作らないこと」をしましょう、と言っても伝わりません。

そこでアジャイルの良さを伝えるために出来ることは「変化に対応する」とか「人を大事にする」とか「顧客満足度を向上」とか「速く・安く」とか、そういったボンヤリした言葉で伝えるしかなくなる訳です。しかし、それらはどれも絶対にアジャイルでなければいけないものではない訳です。これまでのやり方だってやろうと思えば出来るものです。

これまでのウォーターフォールのやり方から、決定的に違うことを言うのであれば「当初に想定した機能は"全部"つくらない」ということになります。しかし、それは一括請負として「決まった機能を"全部"つくること」でビジネスをしている会社では言うことは出来ませんね。
（引用終了）

【３】Agile 2016の基調講演: モダンアジャイル

(引用開始)
モダンアジャイルの4つの指導理念は以下である。

人々を尊重する
安全な状態を前提とする
素早い実験と学習
価値を継続的に届ける

Joshua氏は、改めて古いアジャイル原則を見ると、古い大きなラップトップを誰かが持っているようで良い印象を持たないだろうという意見を持っている。そして彼はスクラムに対して以下のように言及した。

少し年をとり、素晴らしい寿命を迎え、歴史の一部と認識されて立派な引退をするのに相応しい。
（引用終了）

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

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

【参考１・MkDocs】
MkDocs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【２－２】では、お勧めの静的ジェネレータは何が良いのか？

単純な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

【３】他の解決方法

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

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

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

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

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

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

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

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

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

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

複数Redmineの内容を一つのRedmineに集約して見る方法

複数Redmineの内容を一つのRedmineに集約して見る方法について、ツイートされていた内容を@y503unavailableさんがまとめてくれたのでメモ。

【元ネタ】
気づき #764: 複数Redmineの内容を集約して見たい。 - Unofficial Redmine Cooking - redmine.tokyo

【発端】
@j15_aj15さんから、社内に複数のRedmineインスタンスが起動されていて、それらRedmineのチケット内容を一つのRedmineの画面上に集約して見たい、という要望があった。

昌。さんのツイート: Wiki Extensionsプラグインのiframe使ってよそのRedmine見よ！って思ったけど動かない。バラけてるタスクをメインの子で見れたら幸せだったのに。

【関連ツイート】

りょうまさんのツイート: "自ホストのapacheなりnginxでリバプロしてやって、自ホストのURLとしてiframeに埋めれば見られるのではないでしょうか。 パスの階層違うと別な対処が必要ですが。… "

あきこさんのツイート: "iframeで他のサイトに埋め込みできると、クリックジャッキングという攻撃(悪用)ができてしまうので、レスポンスヘッダに「ブラウザさん、このサイトはほかのサイトのiframeに読み込んじゃだめねー」という情報を渡すのです。多分これかなと。… https://t.co/dozV8W5zBx"

あきこさんのツイート: "更新系の操作ができるサイトはiframeで意図せず埋め込まれるのに気をつけないといけないです。 https://t.co/NsfRjWF9PW… "

あきこさんのツイート: "Redmine (というかRails4以上かな) デフォルトでsameoriginです。 ソースを変えない前提なら、各Redmineが同じドメインでSub URIで複数稼働してるケースなら行けると思います。https://t.co/Fixggi7YmP, https://t.co/eOhIZmak4f みたいな感じだったら。安全性を鑑みてAPIで統合が良いとは思います。… https://t.co/q1y6F9QVHm"

昌。さんのツイート: "解除できたらいいなー。情報一元化したい。 現実問題、他方のRedmineにタスクが散らばってること、結構あるんですよね。… "

neta＠筋肉 筋肉〜💪さんのツイート: "https://t.co/gcFS9svZF5第12回勉強会/ のLT4 が(jvasseurさん)「複数 Redmine での開発のためのツールを作ってる」話でした(Private になってるようなのでスライド直リンクできず)。 これもAPI経由ですね、チケットを見るのではないかもですが… https://t.co/SVNfI5GRkH"

昌。さんのツイート: "もんのすごく乱暴ですが、とりあえず自分の環境でタスク一元確認するために、Ignore X-Frame Headerで一時的に回避してみました。少しだけ幸せ。皆様、有効なご意見色々ありがとうございました。さらに精進します。… https://t.co/zlcb3ZDv0J"

【一つの解決方法】
（引用開始）
(1)リバースプロキシの利用

RedmineのWebサーバ側でリバースプロキシし、
参照先Redmineの表示内容を自ホストのURLとして表示可能にすることで、iframeを利用して表示できる。

(1-1)iframe , X-Frame-Options ヘッダ設定

Wiki Extensionsプラグインのiframe使って別Redmine上の内容も表示させたいが、
X-Frame-Options ヘッダで制限されている。
→X-Frame-Options ヘッダのALLOW-FROMで、参照先サーバを許可サイトに追加するなどの対応が必要。

iframeの利用には、セキュリテイ面の注意が必要（クリックジャッキング攻撃などの対策）
『クリックジャッキング』に関するレポートに関するレポート（IPA 技術本部 セキュリティセンター）
（引用終了）

(2)あるいは、PCクライアントにて、X-Frame-Options ヘッダを無効化するChromeエクステンションなどを入れておく。

ローカル環境でX-Frame-Optionsを無効化する - 仕事中の問題と解決メモ。

【X-Frame-Options レスポンスヘッダ】
X-Frame-Options レスポンスヘッダ - HTTP | MDN

X-Frame-Optionsの設定 | 勉強したことのメモ

【クリックジャッキング攻撃】
IPAテクニカルウォッチ　知らぬ間にプライバシー情報の非公開設定を公開設定に変更されてしまうなどの『クリックジャッキング』に関するレポート：IPA 独立行政法人 情報処理推進機構

(引用開始)
サイトへの攻撃はX-FRAME-OPTIONSヘッダが付与されていないからというだけで、攻撃を受けてしまうとは必ずしもいえませんが、IPAではこの対策が最も有力な手段であると考えています。
(引用終了)

クリックジャッキングとは？その攻撃事例と対策方法を解説 | サイバーセキュリティ.com

Webエンジニアだったら当然知っておきたい「 クリックジャッキング対策 」とは？ | ヌーラボ

≫ クリックジャッキングって？ TECHSCORE BLOG

【感想】
社内にRedmineが複数個インスタンスが立ち上がっている利用シーンはとても多い。

自分たちのチーム専用のRedmineが欲しいニーズもあるし、RedmineインスタンスはBitnamiやDockerなどですぐに立ち上げられるからだ。
すると、社内にRedmineが乱立してしまい、PMOや品質保証部の立場では、各プロジェクトの進捗状況を知るために、各Redmineインスタンスにログインしてデータを取得する手間が発生してしまう。
だから、PMOが主体で管理しているRedmineに、各プロジェクトのRedmineの進捗データを集約するようにしたい。

では、どうやって、複数個のRedmineインスタンスの情報を、一つのRedmineサーバー上に集約させて表示させるか？

この解決方法のアイデアは、@netazoneさんがRedmine大阪のLTにて披露してくれた、RedmineにGoogleカレンダーや動画、Googleスプレッドを埋め込むためにiframeタグを使う方法を公開したノウハウが発端になる。

Redmine にいろいろ埋め込んて゛みた

（引用開始）
今回のテーマは”Embed”(埋め込み)。
Redmine にカレンダーやら動画やら埋め込んでみたところ、意外にうまくやれて捗ったのでご紹介。
（引用終了）

留意点としては、クリックジャッキング攻撃のようなセキュリティリスクの可能性があるので、社内LANの閉じた中だけで行う方が安全だろうと思う。
しかし、社内LANの中でさえも、セキュリティ対策上、許可されない場合もあるかもしれないので、細心の注意を払う必要がある。

とはいえ、Redmineユーザとしては、ちょっと危険な香りのする（笑）ノウハウが蓄積されることも楽しい。

RedmineもOSLC規格を導入してトレーサビリティを強化すべきか

@agilekawabataさんが、RedmineにOSLC規格を実装すべきでは、と提案されていたのでメモ。
詳細は知らないので、ラフなメモ書き。
間違っていたら後で直す。

【参考】
Feature #8678: Provide OSLC support - Redmine

（引用開始）
Open Services for Lifecycle Collaboration（OSLCまたはオープンサービスとも呼ばれます）は、ライフサイクルツールを組み合わせて使用しやすくすることで、製品ライフサイクルとアプリケーションライフサイクルの間の障壁を解消するためのオープンコミュニティです。
（引用終了）

Kawabata Mitsuyoshiさんのツイート: "チケットによく気付きましたねー。 ツール連携の標準規格です。JIRAは対応してて、こういうのが世界標準としては必要だなあと。 https://t.co/RV0KgGh56u… "

Kawabata Mitsuyoshiさんのツイート: "自動車業界など、欧米の大手企業には必須な感じです。ただ、RedmineもWebAPIがそれなりに揃ってるので、もしかしたら対応できてるのか、どこまで対応すれば良いのかがよく分からない。。… "

Kawabata Mitsuyoshiさんのツイート: "規格に対応することで、他のツールが標準で連携をサポートするようになり、複数のツールによってシステム構築するような大手には導入が進みます。JenkinsやGitHubと連携するようなことと同じです。世界的に広めるには結構重要な要素だと思います。… "

Open Services for Lifecycle Collaboration

OSLC CM Plugin - Jenkins - Jenkins Wiki

OSLC Japan Wiki : 1.OSLC とは

【1】OSLCとは、アプリケーションライフサイクル管理（ALM）でツール連携する時の公式規格のように思える。

OSLCの利用 - Enterprise Architect 13.5 日本語版 ヘルプ

(引用開始)
Open Services for Lifecycle Collaboration (OSLC) とは、ツールを統合するための仕様を定義するオープンなコミュニティです。
この仕様により、利用者の設計開発プロセスにおいて、さまざまなツールを連携させ設計データとワークフローを統合した環境を作ることができます。

OSLCはW3C Linked Dataに基づいています。OSLCでツール間を繋ぐ主要な技術の一つは、HTTPでデータを繋ぐことです。HTTPやRDFのような標準的な技術で、データの作成・参照・編集・削除を実現します。
HTTPのGETやPOSTのような標準的な方法で内容を編集できます。
(引用終了)

OSLCに対応したアプリ一覧では、Jira、Bugzilla、Mantis、Jenkinsなども含まれる。
よって、ツール連携する時に、この規格を使うことも可能。

Software - Open Services for Lifecycle Collaboration

【2】では、このOSLC規格を使うと、何が嬉しいのか？
僕は正直分からない。
今の所、OSLC規格がなくても、Redmineの運用で困った経験はない。

しかし、2012年の古い記事だが、自動車業界の安全規格ISO26262に準拠するために、このOSLC規格を持つALM管理ツールは必須だ、という主張があった。

ISO26262 日本IBM インタビュー：規格準拠は“入場券”にすぎない、ISO26262をきっかけに製品開発力の強化を (2/2) - MONOist（モノイスト）

(引用開始)
MONOist　オープンという意味では、「Redmine」のようなOSS（Open Source Software）ベースのプロジェクト管理ツールも候補になりませんか。

根城氏　OSSベースのツールを組み合わせてトレーサビリティを確保することもできますが、プロセスが複雑になります。その上、ISO 26262のPart.8で求められる「Qualification of Software Tools」を満足させるための情報入手が困難です。
　また、ISO 26262に準拠するということは、その製品の企画から廃棄まで最低でも20～30年はデータを管理し続ける必要があります。そのISO 26262と関連するツールも、長期間のサポート継続が確保されていなければなりません。
　小規模の企業のツールやOSSベースのツールは、このサポート継続に不安があります。これに対して当社は、DOORSやRTCについて継続的なサポートを約束していますし、世界的な大企業であることから買収の恐れもありません。
(引用終了)

上記の意見に僕は納得できていないが、そういう発想もあるのだろう。

【3】ここで、上記のOSLC規格の背後にある意図を推測すると、チケット管理・ビルド管理・構成管理の全ツールで、OSLC規格に準拠していて、このOSLC規格が使いやすいものになれば、ツール間連携でトレーサビリティを明示しやすくなる、というメリットを導き出したいのだろう、と思う。

なぜなら、自動車業界の安全規格ISO26262では、機能や要件から成果物に至るまでのトレーサビリティを明示することがプロセス管理の観点で重要である事により、OSLC規格を満たすツール同士を連携して、要件から成果物までを明示的にトレースできますよ、と言った事がやりたいのだろう、と推測されるから。

但し、その方向性をOSLC規格で解決できるのか否かは分からない。
過去にも、SOAPやらソフトウェアタグやら、WSDL・UDDIなど、数多くの規格が提唱されては、消えていった歴史があった。
OSLCは残っていく規格なのか？

【4】Redmineにおけるトレーサビリティについては、Redmineを使い始めてから、トレーサビリティの可能性、そして、トレーサビリティを実現できる範囲をどこまで拡張できるか、をずっと考えてきた。
未だに僕の中では解はない。

Redmineにおけるトレーサビリティの課題は何か？: プログラマの思索

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

Redmineをもっと強化できるポイントpart1～上流工程のトレーサビリティ強化: プログラマの思索

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

チケット駆動開発がもたらした新しい観点part2～トレーサビリティの拡張: プログラマの思索

実際、僕自身、Redmine大阪でも、Redmineでのトレーサビリティの実験結果を発表したが、まだまだたくさんのハードルがあって、思い通りの結果は得られていない。

Redmineにおけるトレーサビリティ管理の現状と可能性(第66回 SEA関西プロセス分科会＆第18回 Redmine大阪) #RedmineOsaka

いろいろ考えてみる。

【追記】
akipiiさんのツイート: "内容を聞きたい。そもそも今必要な規格か？RT @ir9: ぶっちゃけ当時そこそこ関係する（糞な）ソフトを創っていた（ぉ // RedmineもOSLC規格を導入してトレーサビリティを強化すべきか https://t.co/mJwHYSu4j6"

いろきゅうさんのツイート: "直接OSLCには関わらないお話で恐縮ですが… リンク記事のようにその昔の車業界の一部では、仕様書からソースまでを紐付けて仕様変更時の影響範囲を知りたい…という飯ネタがあり、そのようなソフト開発に関わってました。「そのうちOSLC対応する」と意識していましたが対応はしていません（申し訳ない… https://t.co/PygxMeoimR"

いろきゅうさんのツイート: "作成してたツールとしては… たとえば、EAのアプリ上にあるUML要素を選択して「関連要素検索」→「wordのxx章 / Excelのyy表 が関連」等出てるのは便利感ありましたが…… アプリ超えた要素の紐付け作業が面倒というのが正直な所でした…… "

akipiiさんのツイート: "ありがとうございます。やはり規格倒れな感じですかね。JenkinsのOSLC対応プラグインも2012年から更新停止だし。Redmine への実装優先度はかなり低そうですね。… "

PlantUMLを使ってExcel設計書をテキスト化するアイデア

以前、Excel設計書をテキスト化できないか、考えたことがあった。
ネットしながら、PlantUMLや他ツールを使ってExcel設計書をテキスト化するアイデアをメモ。
以下は、後で自分が参考にしたい記事をリンクしておく。

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

【参考1】
PlantUML 埋め込み AsciiDoc の Gradle を用いた HTML 一括変換 ・ Yutaka ?? Kato

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

【参考3】
PlantUML を導入するのに適したケースとは - kkeisuke blog

(引用開始)
以下のいずれかに当てはまる場合、PlantUML はプロジェクトの生産性を向上させます。

一人で利用する場合
少数精鋭、もしくは統制(教育)されたチームで共有したい場合
情報共有ツールがすでに浸透している場合

PlantUML が解決している課題
UML を理解していなくてもそれっぽい図が書ける
誰が書いても体裁が揃う
検索が可能
バージョン管理システムと合わせると履歴管理の生産性が向上する

PlantUML は「書く」こと、また適切なツールと併用することで「調べる」ことの生産性を向上させます。
(引用終了)

【参考4】
現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる - Qiita

(引用開始)
システム設計が大好きで大嫌いな皆さん、こんにちは。
突然ですが、皆さんはどのようにシステム設計における ドキュメント腐る問題 に立ち向かっていますか？
ドキュメント腐る問題とは、設計時に作成した各種ドキュメントがGoogle Driveやファイルサーバ上で陳腐化してしまい、現状の正しい状態を指していないことです。せっかく新規参画者がキャッチアップしようとしてもドキュメントが真実を示していないという怖いやつですよね。

解決策としては、各種ドキュメントを、MarkdownやAsciiDoc、UMLはPlantUMLやmermaid、ERDはPlantUMLやerd、画面遷移図はUI Flow、REST-API設計はSwaggerなど、なるべくテキストベースで管理し、GitHubなどのリポジトリで管理することで、（レビューフローなどを適切に設定した上で）コードとの乖離を防ぐ、といったことが一案としてあるかと思います。
(引用終了)

【参考5】
PlantUML言語リファレンスガイドのPDFが素晴らしい。
１００ページ以上もあり、丁寧。

PlantUML言語リファレンスガイド PDF

akipiiさんのツイート: "@ogomr さんの記事がすごく役立つ。PlantUML Cheat Sheet https://t.co/xoa9xeeVhj"

PlantUML Cheat Sheet - Qiita

（引用開始）
PlantUML は DSL(ドメイン特化言語) で UML の図を描きます。
テキストで記述するので Git で差分を確認したり GitHub Flow で
関係者とコラボレーションをして図が描けるので便利です。

PlantUML は多くの UML に対応していますが、よく使うものを チートシート にまとめました。
（引用終了）

【参考６】
PlantUMLでMySQLやPostgresSQLのER図を生成できるようになったらしい。

Database to PlantUML - データベースの内容からER図を生成 MOONGIFT

Hywan/Database-to-PlantUML: Compile PostgreSQL and MySQL table information into a PlantUML description.

achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

はてなブックマーク - GitHub - achiku/planter: Generate PlantUML ER diagram textual description from PostgreSQL tables

【参考７】
??...さんのツイート: "PlantUMLで境界づけられたコンテキストとアプリケーション層の設計してみてるんだけどコーディング感覚で書けるしパッケージ設計までできるので実装イメージしながら書けて楽しい"

akipiiさんのツイート: "面白いな。RT @c6h4clch3: シナリオ製作者よ...PlantUMLを使うのです...関係性や時系列などを表すのに便利なテキスト->図の変換ツールです...添付画像はあるシティシナリオにおける探索者と警察、一般人、神話生物との関係性を例にしたものになります...是非ご確認ください... https://t.co/wDfgVTBZNo"

akipiiさんのツイート: "いいね！RT @morimasa1970: @gogotea3 最近、RedmineにPlantUMLのプラグインを導入したんで、フロー図はその辺でがんばろうと勉強中です。"

choroyonさんのツイート: "PlantUMLいいな これなら方眼Excelからおさらば出来る？??… "

yojikさんのツイート: "VSCodeのPlantUMLエクステンションがめちゃくちゃ良い。リアリタイムでプレビューしながら書けるだけでこんなに気持ちよく使えるとは。今までつかったモデリングツールの中でもトップクラスの使用感！これこそ顧客（俺）が本当に欲しかったものだ。。"

N.Cさんのツイート: "PlantUMLの導入終わったー！　これでコード書いてキャラ相関図作れる！ 必要なやつダウンロードしてPC再起動したら使えるよ！?( 'ω' )? やりかたはこちらです https://t.co/Sbl72dGjEd なお、試しに作った画像がこちらです… https://t.co/qPHL28ko8u"

なべや　まいこさんのツイート: "数日前にシナリオ書くのに便利！と話題になってた『PlantUML』をWordで動かしてみたので、記事を書いてみた。日本語記事見当たらなかったので、もしかしたら書けば誰かが助かるかな、と。 WordでPlantUMLを動かしてみた（その１）｜note（ノート） https://t.co/QGB0FWzgEd"

WordでPlantUMLを動かしてみた（その１）｜なべや　まいこ｜note

【参考6】
PlantUMLは惹かれているのだが、astahで描く方が今は手に馴染んでいる。
下記の意見も同意している。

u6k_yu1さんのツイート: "ちょっと思い返したけど、書き散らすときは紙かホワイトボードでグリグリやって、整理するときにastah使ってる。PlantUMLはテキスト管理のしやすさから何度か試用しているけど、うーんという感じだった。"

岡本卓也さんのツイート: "自分もその感じです。astahはホワイトボードの延長で、思考を直感的に書き出すのに向いてる。『あ、この箱とこの箱は会話しそうだから線で繋ぐか』みたいな。 PlantUMLはここで『線で繋ぐなら文法はこうか?』みたいなワンステップ入るのが辛い。確かにテキストなのでgitとの相性は良いんですがね。… https://t.co/uLQFaWD8uv"

astahとPlantUMLが同期できるといいのだが。

【追記】
akipiiさんのツイート: "これはいいね！確認してみたい。RT @htomine: パフォーマンス見て問題無さそうだったらQiitaにも実装します :+1: / “PlantUML対応、記事のコピー機能を追加しました - 生産性を向上させる情報共有ツール - キータチーム（Qiita:Team）” https://t.co/neyBNqB620"

【追記２】
miitonさんのツイート: "設計書、MarkdownとPlantUMLでほぼ事足りるという実感を最近得ているので、あとは設計書＝Excelというステレオタイプを顧客から排除するべく戦うのである"

あたみうららさんのツイート: "エンジニア的にはPlantUMLとMarkdownで書けるものだけを設計書として採用したいですねー… "

akipiiさんのツイート: "なるほど！RT @yuki_ar: 設計書を書くのは体が拒否するレベルで嫌いなんだが、PlantUMLで書くと脳がコーディングしていると誤認してくれるので、スラスラと資料が出来上がっていくというライフハック"

まさるさんのツイート: "数日前からatomからvscodeに乗り換え始めた。ショートカットキーがまだ慣れないけど、markdownやplantumlを書く時にはvscodeの方が気持ちよくかけるというのは痛感した。"

ステルス駆動開発でRedmineを浸透させるアイデア

Redmineを浸透させるには、陰でこっそり運用して、ボトムアップで普及させる「ステルス駆動開発」が良い、というツイートを見つけたのでメモ。
以下、主張のないラフなメモ書き。

【参考】
akipiiさんのツイート: "ステルス駆動開発と言うネーミングがイイ！RT @natsucotech: ステルス駆動開発は地味に効くぞ！　偉い人の許可を取らずに勝手に会社に Redmine を導入し、最初はめちゃくちゃ怒られたけど、だんだん「Excel でのタスク管理より楽じゃん！」と評価されつつある"

【1】大企業や規律のうるさい現場では、標準ツールとか標準プロセスなどが押し付けで入っていて、使いにくい場合が多い。
だから、こっそり陰で、自分たちのチームに合ったツールとプロセスでやりたい時がある。

では、どうやって進めればいいのか？

上記のツイートから類推すると、上司の見えない場所でツールを導入して、現場で使ってみて、各チームに浸透させて、ボトムアップで認めさせる方法がある、という。
「ステルス」にはそんな意味合いが含まれているのだろう。

【2】上記のやり方は、以前、@sakaba37さんが言っていた「補完チケット方式」や「アダプタブルWF」に似ている。
つまり、ExcelのWBS管理が既に運用されているけれど、その運用からこぼれ落ちた障害管理、課題管理などをチケット管理でフォローする、というやり方だ。

さかばさんのツイート: "本人的には、保守本流のつもりです。 RT @akipii: 補完チケット方式はチケット駆動開発の先祖返り http://t.co/Q3xj7EuK"

gomasaさんのツイート: "WF型開発にチケット駆動を取り入れる時の考え方: アダプタブルWFや補完チケット方式について、考えたことをラフなメモ書き。 【参考】 「チケット駆動開発」の適用について考える｜コラム「ITよもやま話」｜特集│株式会社JS... http://t.co/JE12CXBsDe"

実際のシステム開発では、プロジェクトリーダーが引いた理想的なガントチャート通りに進むことはなく、むしろそこからこぼれ落ちた数多くの細かな作業・障害・課題の管理の方が重要だ。
それらを漏れなく、1つずつ解決していくことで、納期が見えてくる。

そんな時に、きれいなガントチャート管理にこだわるよりも、泥臭く一つずつチケット管理してこなしていく方が、リスク対策になると思う。
但し、Excelとチケット管理の二重運用になるので、面倒な部分はある。

【3】上記では、ステルス駆動でRedmineを運用してきたことで、アジャイルな雰囲気が出てきた、という話があった。
おそらく、チケットで作業が見える化され、チケットがどんどん消化されていく様子なのだろう。

それは、Redmineの導入時に目指していた当初の目的とは違うかもしれない。
でも、そういうRedmineの副作用こそが、面白い点だと思う。

良いツールは、想定していなかった数多くのメリットや効果をもたらしてくれる。
そういう副作用をもっと調べて整理してみたいのだ。

【4】他に、会社で標準Redmineがあるけれども、自分たちのチームに合ったRedmineを陰でこっそり導入するという「野良Redmine」「闇Redmine」という症状もあった。
つまり、会社内に複数のRedmineインスタンスが存在している状況になる。

ステルス駆動開発では、複数Redmineインスタンスの運用も含まれるのだろうか？
もちろん含まれるだろう。

ステルス駆動開発で生まれた野良Redmine、闇Redmineは良いものなのか？　悪いものなのか？
以前考えたことをふりかえると、状況によって評価が違うのだろう。

Redmineインスタンスとプロセスの関係～Redmineは組織に従うのか、Redmineに合ったチームを作るべきか: プログラマの思索

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

【その他】
「ほげほげ駆動開発」を調べた人がいたので、リンクしておく。
もちろん「チケット駆動開発」も含まれている笑

○○駆動開発(xDD)がどれだけあるか調べてみた - shouhの日記

【追記】
門屋　浩文さんのツイート: "最近の話ですがなかなかredmineを準備しないが、このままではヤバイ案件があり自分の把握のためにチケット化して成果物とのヒモ付けを毎日してたらそのまま使われ始めました まずは第一歩… "

門屋　浩文さんのツイート: "まあ、そのプロジェクトは利用経験者も効果も知ってるメンバーが多かったので時間の問題なだけでしたが 自己把握にも使えるredmine（笑… "

akipiiさんのツイート: "僕は、ステルス駆動開発、とか、こういうネーミングが好きです。名前付けされると、今まで経験してきた暗黙知を他人に説明しやすくなる。喩え話で使えるし、Redmineをステルス駆動、と言えば、イメージしてもらえるし。パターン言語につながります。… "

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由

以前のSQIP2016で、チームの開発環境が開発プロセスの品質を向上させる点を指摘していた資料があったのでメモ。
そこから、未だにチームの開発環境が導入されない理由も考えてみた。
途中で書きかけなので、後で書き直す。

【参考】
モダンなチーム開発環境を追求しよう : SQiPシンポジウム2016 SIG8 - MassKaneko.Out

(引用開始)
チーム開発 とはソフトウェア開発における技術分野の呼び名であり、"チーム開発実践入門(技術評論社, 2014)"*1 の発刊を機に日本で普及している技術分野名だと思います。バージョン管理・課題管理・継続的インテグレーションなどの技術分野をひとまとめにしているのが特徴で、組織的におけるソフトウェア開発のワークスタイルを大きく決定づける技術分野だと考えています。国際的に "チーム開発" と同義の用語が存在するか確認が取れていませんが、ソフトウェアライフサイクルプロセスの規格である ISO/IEC 12207 におけるサポートプロセスと多くの技術領域が重なります。

ここ5年くらいの国内のチーム開発分野におけるトレンドを振り返ると、チケット駆動開発, Pull Request, 継続的インテグレーション, ChatOps が思い浮かびます。例えば2012～2013年には国内大手/有名サービス企業においてGitHub Enterprise の導入事例が報告され*2、SlideShare にてツールの名前で検索すると、カンファレンスや勉強会における企業からの発表資料が多くヒットします。

一方、SQiPシンポジウムはソフトウェア品質を扱うシンポジウムであり、企業での事例が毎年20件以上報告されるのですが、チーム開発技術にフォーカスをあてた発表は何年か振り返っても多くは見当たりません。本文執筆時点で公式ウェブサイトでは2009年からの発表資料・論文が公開されていますが、それらのうち私から見てチーム開発技術にフォーカスをあてている、またはチーム開発のツールが発表内容に大きく関係していると判断できるものは5件でした。
（中略）

私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えておりますので*3、なぜSQiPシンポジウムではチーム開発の発表が少ないのだろうと疑問を持ちました。理由として "もう当たり前で語ることが少ない" ということも考えられますが、「いや、絶対そのようなことは無いし需要はあるはずだ。」と信じてSIGを主催することにしました。
(引用終了)

SQiP2016 SIG8 from Masanori Kaneko

【1】僕は、「私は経験上、チーム開発技術は品質向上に大きく寄与し、数あるソフトウェア工学技術の中でも優先的に取り組むべきものと考えております」という意見に、完全同意だ。

製造業の品質管理に影響を受けすぎている人達は、Excelドキュメントによる標準プロセスの構築ばかりに意識が行きたがる。
しかし、そのやり方が実際の案件で作業にブレーキを掛けたり、逆にシステムの品質を向上させない症状を生み出している現場を色々見てきた。

むしろ、チームによる開発を支援する共通基盤を準備した方が、開発スピードも早くなるし、品質向上にも役立つ結果になる。

では、なぜ、彼らはチーム開発の開発基盤を構築して運用する方向に目が向かないのか？

【2】いくつかの理由が考えられる。

【2-1】開発環境の構築に投資する発想がない。

開発基盤を作ると、保守コストがかかる。
日本のプロジェクトマネージャには、開発環境に投資する、という発想がない。
管理コストに投資する発想がない。
案件をまたいだ共通の開発基盤に投資する場合、社内の稟議申請が必要になり、経営層を納得させるだけの理由が作りにくく、普通は通りにくい。

但し、OSSの開発基盤ならば、プロジェクトマネージャに技術力さえあれば、自身の人件費以外はほぼ無料で導入できる。

【2-2】従来通りの開発スタイルによる過去の成功体験があるから

以前、新しい開発ツールを導入して失敗した経験がある。
新しい開発ツールの考え方に慣れることを嫌う。

特に、有償のパッケージ製品には、販売元の会社のプロセスが埋め込まれている為、現場のプロセスにはなかなかフィットしない。

Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想: プログラマの思索

標準化作業は、SDCAの考え方。
つまり、誰もがいつ、どこでも同じ作業をやれるような仕組みを標準として定め、その標準に従って、DCAを回すべき、という発想。

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

この標準化の考え方は、工場のブルーカラー、外食チェーンや他店舗展開の小売業の作業者、コールセンターやサポートデスクのオペレータの管理には向く。
しかし、IT技術者のようなクリエイティブな人には向かない。

アジャイル開発は常識だ: プログラマの思索

なぜなら、IT技術者である限り、最新技術のキャッチアップは必須。
よって、過去の経験が全てクリアされて、一から学習し直す覚悟がいる。
しかし、その学習コストを各自で責任を負うのはハードルが高い。

【2-3】既に投資した社内ツールを捨てられないから

社内に既に、内製化したツールがある。
従来の社内ツールを捨てられない。
従来の社内ツールに、数多くのプロセス資産が蓄積されているので、埋没コストになる。

一般に、2000年頃にBTSが必要と認識した、レベルの高い会社で、そういう社内ツールを内製化した場合が多い。
しかし、OSSの発展に比較すると、UIが古かったり、機能改善が追いつかず、OSSよりも機能が劣っている場合が多い。
なのに、社内ツールを廃棄すると、埋没コストになるから捨てられない。

Redmine運用の感想を集めてみた: プログラマの思索

Sean Osawaさんのツイート: そういうのってホントにあるんだなぁ〜 RT @sonoyu670 あるお客さんのところでは「それredmineでええやん」という使い勝手の悪い独自のPJ管理システムを持ってて、これウン千万とかかけて作ったんだろうな、馬鹿だな、って思ってた。

(引用開始)
フリーのBTSがまだ普及していない頃、障害管理やタスク管理の重要性に気づいた会社は独自でBTSやITSを作り込んでいた。
そういう会社は先見の明があったに違いない。
だが、長年使ってくると、オープンソースのBTSやITSの方が普及してかつ高機能になって、逆に足枷になっている場合が見られる。
システムを長く使うのか、それとも新しいシステムにリプレースして移行するのか、判断が難しい。
(引用終了)

すなわち、組織変革の障害になりうる。
結局、変革に対抗する力となり、組織慣性として惰性のまま現状維持が続く。

埋没コストとは・意味｜MBAのグロービス経営大学院

サンクコスト（埋没費用）とは | カイロスのマーケティングブログ

【2-4】開発環境は衛生要因であり、動機づけにつながらないから

開発環境が導入済みだとしても、動機づけにつながるとは限らない。
環境がなくても、従来通りやり続けてきた。

一方、優秀なチームでは、開発環境が導入されていないと、モチベーションを落とす。
むしろ、開発環境は導入されていて当たり前。
つまり、開発環境の導入は衛生要因であり、動機づけ要因にならない。

ハーズバーグの動機づけ・衛生理論 ｜モチベーション向上の法則

ハーズバーグの二要因理論 ? リーダーシップインサイト

【2-5】チームの成熟度が低く、Redmineを使いこなせないから

開発環境が既に用意されているとしても、上手く使いこなすか否かは、チームの成熟度に依存する。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

Redmineインスタンスはチームの組織文化や慣習を表す: プログラマの思索

チームの成熟度に対するPMOの支援度合いは、リーダーシップの状況適合理論（SL理論）で説明できるのではないか。

2/4 リーダーシップは部下の成熟度で変化させる [リーダーシップ] All About

SL理論 ? リーダーシップインサイト

SL理論（状況対応型リーダーシップ） | マネジメントオンライン

たとえば、チームの成熟度が指示待ち人間のレベルである場合、Redmine導入と運用は、RedmineエバンジェリストやRedmine警察の役割の人達が、逐一メンバーにコマンドコントロールする必要がある。
つまり、PMOは指示型リーダーシップを発揮して、チームに相当介入せざるを得ない。

一方、チームの潜在能力は高く、Redmineのような新規ツールを欲しているならば、RedmineエバンジェリストやRedmine警察の役割の人達は、コーチングや運用支援のようなスタッフ的な立ち位置で支援すればいい。
つまり、PMOは、コーチングのような説得的リーダーシップ、参加的リーダーシップを発揮して、チームを支援すればいい。

最終的には、チームの成熟度が自律的になっていれば、PMOは委任的リーダーシップ、つまり、サーバントリーダーシップに似たリーダーシップを発揮して、チームにRedmine運用そのものを委任すればいい。

そうなると、各チームは自チームに特化したRedmineが欲しくなるので、チームごとに複数のRedmineインスタンスを提供する方式になるのではないか。
つまり、野良Redmineが普通の状況になるかもしれない。

個人的には、現代において、PMOが教示的リーダーシップ、指示的リーダーシップを発揮してチームをコマンドコントロールしなくてはならない状況は相当減っているはず、と思う。
ネット上に情報もたくさん流れているので時代の方向性は理解できるし、若い人ほど潜在能力が高いように感じるから。

【3】他にも色々考えてみる。

【追記】
akipiiさんのツイート: "個人的には、@MadoWindahead さんがPMOでチームに関わる立場はSL理論でどのポジションにいるのか、知りたいかな。指示的リーダーシップはさすがにないと思うし、委任型リーダーシップであれば、そもそもPMOがチームに関わらなくてもいいので、説得的または参加的リーダーシップかなと推測。… https://t.co/lg3gcKgLZ7"

門屋　浩文さんのツイート: "指示型は敢えてやらず 説得と参加、不安の軽減、やってみせて、効果を感じてもらうことかなあ サーバントリーダーシップはどこまでできてるかの評価は分かれるところかも… "