2019/01/11

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか

GitHubが無料でプライベートリポジトリも使えるニュースが届いた。
とても素晴らしい。
このニュースは、小説家にもGitが必須になってきた事実を示唆していると思う。
以下、ラフなメモ書き。

【参考】
GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

【1】GitHubが無料でプライベートリポジトリも使える最大のメリットは、プライベートなドキュメントは全てGitHubで管理できることだ。
僕は、この恩恵は計り知れない、と思う。

たとえば、ブログの元ネタのメモ、Excelで作った家計簿、執筆原稿用のWord、プレゼン資料のパワポなど、全てGitHubに入れてしまえばいい。
そうすれば、日々更新するファイルは全てGitHubの履歴として管理でき、いつでもどこでも復元できるようになる。
よって、「yyyyMMdd_ファイル名」みたいなExcelファイルを一時的に作ったり、他の共有ファイルサーバーに逐一手動でバックアップしたりする作業は不要になる。

また、GitHubにはIssue管理(チケット管理と呼ばないんだね笑)、Wikiの機能も付いているので、日々のタスクをIssueにメモしたり、常に参照すべき共有情報はWikiにまとめることができる。

つまり、個人のドキュメント管理と情報管理は、今後、GitHub中心に回るようになるだろう、と思う。
プライベートPCを切り替えても、GitHubにドキュメントがあるなら、いつでも自分だけの環境を復元できるわけだ。

【2】最近の最先端の小説家は、どうやら、GitHubを使っているらしい、という記事を見かけるようになった。
文系の人達も、プログラミングしない人達も、Gitが必須になってきたように思える。

「Githubで小説? そんな時代なの?」そうなのだ。 - 景虎日記

GitHubをコーディング以外で活用する7つの方法 | readwrite.jp

世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita

Web小説のリリース自動化 - Qiita

【1】小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること。

【2-1】1点目の利点は言うまでもない。
出版業界でも、Word主体が多いが、たぶんもう時代遅れだと思う。
Wordの変更履歴機能もあるが、正直使いにくいと思う。

【2-2】2点目の利点は、小説の推敲作業にもプルリクを使うことで、小刻みな改善がスピーディに行えるようになることだ。
僕も4冊ぐらい出版したので経験があるが、1冊の本を書くには10万~20万文字くらいの分量がいる。
それだけの文章にチェックを入れて、フィードバックを反映する作業は正直面倒だ。
その反映作業を漏れなくスピーディに行うのは、GitHubのような構成管理とチケット管理の両方の機能がなければ難しい。

その時に、プルリクが使えると便利だ。
編集者は、修正すべき該当箇所を指摘するチケットを起票するだけでなく、修正パッチをプルリクで提供すれば、Masterを管理する小説家はそのプルリクを吟味した後、取り込むだけで済む。
つまり、編集者は小説を改善する開発者、小説家は小説を管理するコミッターの役割で置き換えられる。

【2-3】他に、世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiitaで共感する箇所は、「過去に書いた文章を再利用しやすい」部分だ。

(引用開始)
小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない!」となってバッサリ切り捨てることがあります。
そして後になって「あ、ここはあの時の文章が使えるのでは?」という時が必ず来ます。1割くらいの確率ですが。
そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
でも Git なら大丈夫。全部記録しているからね。
(引用終了)

1冊の本を書く時、最初に当然、目次と構成をラフに決めてから、書き出す。
しかし、良い本を出版しようとする時、必ず1回は、目次や構成をビッグリファクタリングするタイミングが訪れる。

そのビッグリファクタリングでは、目次や構成が大幅に変わってしまうので、今までの文章をざっくり削ったり、大幅に入れ替えたりする必要が出てくる。
一度削った内容を参照したり、一部だけ取り出すこともあったりする。
すると、Gitのような構成管理ツールで管理していなければ、こんなビッグリファクタリングの作業は怖くてやってられない。

こんなビッグリファクタリングが発生する理由は、自分が書きたい内容を書き出していくと、想定以上の分量になってしまい、出版媒体という箱の中に入れるには、大幅に削るしかない状況に陥るからだろう。
僕の経験上、そんなタイミングを数冊の本で経験したので、たぶん、他の人もそうではないだろうか。
書きたい内容がいくらあっても、それを一連のストーリーに論理的に配置して、読みやすい分量に収納するには、ビッグリファクタリングで大幅に削ったり、構成を見直す事が必要だから。

一方、それを最初から計画するのもあまり意味がないように思う。
やはり、執筆するのはかなりのパワーを浪費するので、最初は多少論理がずれていても、とにかく書き出しておけばいい。
その後で、Gitで履歴管理しているのだから、少しずつ修正すればいいだけ。

【3】さらなる利点は、GitHubとCIツールを連携することで、小説を多種多様なフォーマットに出力して、色んな媒体で公開できることだ。
Web小説のリリース自動化 - Qiitaに、こんな一節がある。

(引用開始)
動機
なぜ小説をいくつものフォーマットで発表する必要があるのだろうか。これにはふたつの理由がある。
第一に、作品を発表する場所が増えれば増えるほど、人の目に触れる可能性が高くなる。
特に、小説投稿サイトには小説を読むことを目的とした人が集まっている。
第二に、特定のプラットフォームに依存しなくて済む。
たとえば、小説投稿サイトには、突然規約が変わったり、サービスが終了したりするリスクがある。
そうしたリスクは分散させておいたほうがよい。
しかし、作品を発表する場所が増えれば増えるほど、運用が大変になる。作品の変換やアップロードに時間を取られれば、肝心の作品を書く時間が減ってしまう。
また、運用に失敗すると、場所によって内容が違い、どれが正しいかわからないという事態にもなりかねない。
逆に、更新作業が面倒だからという理由で誤字脱字等を放置するようになれば、それこそ本末転倒だ。
運用作業を自動化してしまえば、そうしたことに頭を悩ませる必要がなくなる。

方針
自動化の理想は、原稿を書いたり修正したりするだけで、はじめに挙げたすべてのフォーマットで小説が公開・更新される状態である。
この記事では、それに限りなく近いものとして「作品をGitリポジトリとしたとき、origin/master を更新するとすべてのリリース作業が自動的に行われる」という状態を目指す。
これはソフトウェアの世界でいう「継続的デプロイ」の一形態である。
(引用終了)

Web上で自分が書いた小説を公開する時、BlogやカクヨムのようなWebサービスは確かに良いが、閉鎖されるリスクはゼロではない。
閉鎖されると、自分の作品が消えてしまうリスクがある。
だから、リスクゼロのためには、GitHubに小説本体のソースは一括管理しておき、Blogや有償サービス、AmazonのKndleに配布するような手段を確保した方が良い。

すると、その手法は、継続的ビルド、継続的デプロイのような仕組みと一致するだろう。
僕もそういう考え方は以前から持っていたし、既に多くの人も同じようなことは既に考えているわけだ。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

epub出版システムの作り方: プログラマの思索

Pandocでテキストファイルからドキュメント生成: プログラマの思索

Web小説のリリース自動化 - Qiitaでは、Webサイトへの変換にJekyllを使う事例まで載っている。
JekyllはRuby製の静的ジェネレータなので、使い方は簡単。
また、Jekyllプラグインには、カクヨムと小説家になろうへの投稿のための「jekyll-deploy-shosetsu」、電子書籍の作成のための「jekyll-build-ebook」など色んなGemが使える。

他に、達人出版会のReVIEWも有名だろうか。

ReVIEW記法 基本文法最速マスター - 達人出版会日記

TeXとRubyだけでWindowsにRe:VIEW環境を構築した話 - Qiita

【3】以上の話は、プログラマには無関係だろうと思われるかもしれない。
しかし、プログラマは技術書同人誌を書いてみよう、という記事もあり、ネタさえあれば簡単に出版できるらしい。

技術書同人誌を書きましょう! - Qiita

いろいろ試してみる。

【追記】
@8amjpさんのRedmine小説も流行していましたね。

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が流行しているらしい: プログラマの思索

「Redmineで始める異世界人心掌握術」を連載中です。 | at 8 AM, JP.

他に、@akiko_pusuさんの本「Redmineでやってみた」もありましたね。

Redmineでやってみた - うさぎまんじゅう - BOOTH

| | コメント (0)

【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。
第3弾は、3/2土に気象庁 予報部 数値予報課の技術者の方が来て下さって、「気象予報システムを支える技術」を講演される。

実は、この講演の発端は昨年のRedmine大阪で、気象庁の方が講演してくださったのがきっかけ。

第66回 SEA関西プロセス分科会&第18回 Redmine大阪 「チケット管理システムによるソフトウェア開発支援と今後の課題」 - connpass

昨年のRedmine大阪では、気象庁の数値シミュレーションシステム開発において使われている、Redmineの複数インスタンス運用がメインテーマだった。

一方、今回の講演では、気象庁内において、スーパーコンピュータを使った天気予報の数値シミュレーション開発の話そのものがメインテーマになる。
気象予報のシステム開発に、並列計算や機械学習など数多くの技術を紹介してくれる。
この部分だけでもとても興味がある。

また、システム開発の運用基盤に関わる話の一つとして、RedmineやGitなどの話も含めてくれるらしいので、Redmineユーザも要チェックでしょう。

そう言えば、昨年のRedmine大阪の講演では興味深い内容がいくつかあった。
たとえば、気象庁では「プログラマ」という官職があり、給与人事制度があるので、プログラミングに専念する技術者という地位が認めらている。これは、官公庁という発注者の環境でも存在できる、という点で興味深い。
また、そういうプログラマがいる雰囲気のせいだろうか、気象庁内ではFortrunだけでなく、インフラ運用などでRubyが頻繁に使われている、という話もあった。
最近は、海外の技術者の影響を受けて、Pythonにも挑戦している、という話もあったな。

気象庁の技術者の講演を聞くチャンスは少ないので、興味のある方は是非お越しください。

【参考】
第70回 SEA関西プロセス分科会 気象予報システムを支える技術 - connpass

(引用開始)
気象予報システムを支える技術
講師: 
 雁津 克彦 氏(気象庁予報部数値予報課プログラム班)

概要: 
 気象庁では、風や気温などの時間変化をスーパーコンピュータで計算し、将来の大気の状態を予測する「数値予報」を用いて、日々の天気予報や防災気象情報の作成を行っています。

気象庁はTop500で28位・29位(2018/11現在)のスーパーコンピュータを整備して数値予報を行っており、運用中のスーパーコンピュータシステムについて紹介した後、C, Fortran, Ruby等で内製している数値予報のプログラムについて、並列計算やソフトウェア技術といった側面を中心に紹介します。併せて、予測結果を天気予報に利用できる形に翻訳する「ガイダンス」では各種機械学習を用いたプロダクトを作成しており、こうした機械学習の利用についても紹介します。

また、これらのソフトウェアは複数の課室で開発を分担していますが、実行プログラムや読み込む定数ファイルなど多くの部分を共有して利用しており、これらを齟齬なく維持管理する現在のルーチンシステムの管理手法や、バッチ処理のためのスケジューリングソフト(ROSE)、開発管理としてのRedmine, subversion, git 等の利用についても併せて紹介します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

開催日時:  2019年3月2日(土)14:00~16:45

開催場所: 
 〒540-0031 大阪市中央区北浜東3-14
 エル・おおさか(大阪府立労働センター) 7階 701号室
 http://www.l-osaka.or.jp/index.html
(引用終了)

| | コメント (0)

【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。

第1弾は、2/09(土)に、Node-REDのワークショップ。
Nodeから手が出るNode-RED - connpass

第2弾は、2/16に、IPAの方が大阪まで来て下さり、「IoT時代のシステム開発アプローチ」の講演会です。

1本目の講演は、IOTシステム構築に必要な要件であるセキュリティ要件や信頼性の観点のお話。
2本目は、IOTシステムが、組込製品からクラウドシステムまでも含むシステムズ・オブ・システムズの観点であることから、システムエンジニアリングのアプローチが有効である、というお話。

IPAの最近の活動をネットで見ると、日本の製造業の技術力強化には、組込製品のソフトウェア開発だけでなくIOTシステムも重要、という認識の元、製造業と密接に関わるソフトウェア開発の話が多いように思う。

「日本のモノづくりは高品質」という神話があったけれど、現代は、ハードウェアよりもソフトウェア開発の方がはるかに重要になってきてる。
だから、日本の製造業はもっとソフトウェア開発に目を向けるべきだ、というメッセージが込められているように思える。

IPAの方の講演は関西ではそう簡単に聞けないので、興味のある方は是非お越しください。

第3弾は次のブログで紹介予定。

【参考】
第69回 SEA関西プロセス分科会 IoT時代のシステム開発アプローチ - connpass

(引用開始)
IoT時代のシステム開発アプローチ
講師: 
 宮崎 義昭 氏(独立行政法人情報処理推進機構 社会基盤センター 産業プラットフォーム部 研究員)
 端山 毅 氏 (独立行政法人情報処理推進機構 社会基盤センター イノベーション推進部  主任研究員)

概要: 
本セミナーでは、IoT製品の開発者が開発時に考慮すべき安全性やセキュリティ観点でのリスクや対策と、品質の確保・維持に必要な考慮ポイントを説明したうえで、多様な専門領域にわたる取組みが求められるIoTの開発に役に立つ開発アプローチである、システムズエンジニアリングについて、その基本的な考え方を解説します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

後援:  独立行政法人 情報処理推進機構(IPA)

開催日時:  2019年2月16日(土)13:30~16:45

開催場所: 
 〒530-0001
 大阪市北区梅田1-2-2-500 大阪駅前第2ビル5階
 大阪市立総合生涯学習センター 第1研修室
 http://osakademanabu.com/umeda/

講演1: つながるシステムの安全安心に向けた課題と対策

講師: (独)情報処理推進機構 社会基盤センター 研究員 宮崎 義昭 氏

IoTと呼ばれる製品・サービスの普及が進み、個人生活や生産現場など様々な場面での 活用事例が報告されています。一方で、IoTシステムは、セキュリティやセーフティの観点で、これまでとは異なるリスクを含んでおり、システム提供者には、開発や運用の場面において、十分なリスクの洗い出しと対策が求められます。本講演では、IoTの安全安心に対する課題と高信頼化に向けた考慮ポイントや品質確保の取り組み方について、具体的な事例を交えて解説します。

講演2: 成功事例に学ぶシステムズエンジニアリング

講師: (独)情報処理推進機構 社会基盤センター 主任研究員 端山 毅 氏

IoT時代における製品やサービスは、利用者からの要請や期待に応えるため、製品やサービス自体が複雑化・高度化し、その実装には多様な専門領域にまたがった取組みが求められます。
このような状況には、航空宇宙分野で培われてきたシステムズエンジニアリングのアプローチが役に立つと考えられます。本講演では、特にシステムズエンジニアリングの考え方を理解する上で重要な4つのポイント(「目的指向と全体俯瞰」、「多様な専門分野を統合」、「抽象化・モデル化」、「反復による発見と進化」)や、システムライフサイクルプロセスの上流プロセスについて、実践的な解釈と事例を交えて解説します。 また、システムズエンジニアリングのアプローチが有効に機能したと評価できる日本企業の開発事例を紹介します。
(引用終了)

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

【参考】
PlantUML Example for モデルベース要件定義テクニック - Qiita

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

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

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

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

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

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

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

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

2018/12/30

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク

歴史の流れをplantUMLのシーケンス図で書き起こした事例がツイートされていいたのでリンクしておく。
これは分かりやすい。

【参考】
読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。… "

akipiiさんのツイート: "歴史はシーケンス図で書くと面白いな。RT @kurubushi_rm: 右手を痛めてから手書きを減らすべくAtom+PlantUMLで図を描くようにしてる。 画像は、大化の改新の前後をシーケンス図でまとめたもの。 https://t.co/4FBraKNyco"

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "実は「UMLで描く日本史」という企画もあってですね。… "

apple][ (28)さんのツイート: "あーこれはわかりやすいかも。 歴史の教科書って、時系列に文字で説明されているだけだから、相互関係や因果関係がすごく分かりにくいんだよね。図があってもすごく分かりにくかった。結局単なる暗記ものの域を脱しなくて、学問として全く興味が湧かなかったのもそれが大きな要因と思う。… https://t.co/kEoyxxbWNg"

akipiiさんのツイート: "「UMLで描く日本史」だけでなく「UMLで描く世界史」も期待しております! PlantUMLでソースをGitHubで公開してくれると、日本の高校生や受験生にも役立つと思いました。… "

てるりん🍙お結び隊 No.6🎸TEAM Mさんのツイート: "納品ドキュメントにWordやExcelが求められたりした場合は仕方ないけど、納品対象にならない内部設計のドキュメントやチームメンバー間での情報共有目的なんかは、SublimeTextやVSCodeとPlantUMLで書いてMarkdownで埋め込んでPDF化とか、最近よくやる。… https://t.co/ZxsDIBnsmJ"

【1】日本史や世界史のような歴史は大嫌い、という人も多いと思う。
理由は、暗記が大嫌いだからだ。
訳の分からない人名、関連して覚えにくい年号、など、丸暗記しなければ解答できないものばかりだから。

でも、僕自身は数学と歴史は好きだった。
理由は、数学はロジカルに組み立てられているので、基本的な公式さえ理解すれば、後は、そこから演繹的に導くだけで暗記が不要だから。

また、歴史も、その時代の政治的な背景や経済的な構造という仕組みを理解すれば、歴史上の大事件をマグマの噴火の現象として捉えることで、一連の流れで捉えることができるから。

たとえば、一昔前の歴史物であれば、マルクス主義史観や民主主義史観みたいに、歴史は経済中心で発展していくべきものであり、最終的には独裁政治から資本主義を経て民主主義へ落ち着く、という流れの中で、その国の歴史をプロットする、という考え方もある。
実際、民主主義に発展した国と歴史を考えれば、英国→フランス・米国→ドイツ・日本→ロシアの順で民主主義化されてきた。
あるいは、一人あたりGDPがある一定水準を超えると、中産階級の政治的発言力が高まり、独裁政治から民主主義に政治体制が変わる、とか。
とは言え、そういう進歩主義的歴史観が中国に当てはまるのかどうか、分からないが。

【2】では、そういう考え方で、歴史を捉えたい時、どんなモデリング手法を扱えばいいだろうか?

その答えの一つは、歴史をシーケンス図で書き起こしてみる事ではないだろうか。

たとえば、上記では、大化の改新前後の歴史的事件を、シーケンス図で書き起こしている。
さらに、吹き出しに、年号と事件名を書いている。
ゆえに、シーケンス図を見ると、誰が誰に何しているか、というのが一目で読み取れるので、理解しやすい。

シーケンス図のメリットは、アクターやオブジェクトの相互作用を表現できることだ。
そこから、UMLモデリング手法の考え方も適用できるだろう。

たとえば、Fatなオブジェクトがあって、メッセージの発信源が集中しているならば、他のオブジェクトが実は他に存在しているのではないか、と疑ってみると面白いかもしれない。
実は、XX事件の黒幕とか、他の重要人物が隠れているのかもしれない。

あるいは、「責任の委譲」を使って、メッセージが階段状になるように書き起こしてみて、歴史的事件のステーク・ホルダーが誰なのか、ステーク・ホルダー同士でどんなやり取りがあったのか、を書いてみると、より詳細に理解しやすくなるのではないか。
特に、XX戦争における敵と味方の区別、とか。
たとえば、新聞の国際欄では、シリア紛争の複雑な利害関係者の敵と味方の区別をクラス図に近いモデル図で表現している。

【3】そこで、歴史をシーケンス図で書き起こす時、VSCode+PlantUML+Gitを使うと非常に書きやすくなるだろう。

なぜならば、シーケンス図をプログラミングのように書けて、即座にプレビューできるので、試行錯誤しながら考えをまとめられるから。
また、Gitで構成管理の配下に置けば、理解した内容を継ぎ足していくことで、歴史のシーケンス図を一つの絵巻物として書き上げられるから。

上記の日本史のシーケンス図を見ていると、PlantUMLと歴史は相性が良い、という気がした。
日本史や世界史の年表を全てシーケンス図で書き起こしてみたら、世の中の高校生に貢献できるのではないだろうか??

たとえUMLを知らない高校生であっても、シーケンス図のように箱と矢印だけの絵を見れば、だいたいのイメージは分かるはずだろうから。

【4】PlantUMLの可能性については、以前から考えていた。

僕は、日本のSIで広く使われているExcel設計書は、全てテキスト化してGitで構成管理させたい。
そのためには、PlantUMLのような何らかのモデルの絵が必要だろうと思う。

一昔前の詳細設計書のような自然言語のドキュメントは現代では不要だが、システムの構想やアーキテクチャのイメージは、何らかのモデルという絵で表現したいからだ。
そうすれば、アーキテクトは、顧客やプログラマに説明しやすくなるから。

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

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

ツイートを読み流していると、世界中の人達がPlantUMLを使って色んなアイデアを試そうとされているのがよく分かる。
業務フローやシステムのアーキテクチャだけでなく、ER図、ジョブフロー図、ガントチャートもPlantUMLで実現できる。
さらに、リスク関連図(?)みたいな、因果ループ図までPlantUMLで実現しようと試されている人もいるみたい。

akipiiさんのツイート: "後で読む。RT @pdl_runa: 現場で役立つシステム設計の原則にあるUMLをPlantUMLで書いてみる https://t.co/LIRmSOsBWW"

akipiiさんのツイート: "後で読む。RT @tech_advent: OPENLOGI Advent Calendar: plantUMLで業務フローを整理する https://t.co/2LWksWSyuI"

akipiiさんのツイート: "なかなか良いな。RT @abe4tawa8: PlantUMLでER図を描く! – VELTRA Engineering – Medium https://t.co/7eVRHuFjFC"

akipiiさんのツイート: "ジョブフロー図も書きたくなるな。RT @jiro_saburomaru: 定期実行のバッチとかのタイムチャートをテキストから生成できないのかな。plantuml みたいに"

akipiiさんのツイート: "I think it interesting. RT @DinisCruz: Here is the first draft and @PlantUML version of our revised @Jira schema for risk management What do you think? Does it make sense? Created by @madplatt #IN https://t.co/76Fy4FM1me"

立花優斗さんのツイート: "PlantUMLめっちゃいいな… "

【5】PlantUMLを用いて、Excel設計書をテキスト化するだけでなく、日本史や世界史もモデルで書き起こす事例のように、他の分野にも適用して試してみたくなってきた。

来年のastah関西でも、そういう話をしてみたいな。

【追記】
@kurubushi_rmさんが、「大化の改新前後.pu」「環大西洋革命.pu」をGitHubでソースを公開されている。
とても参考になる。

kurubushi--rm/history-in-UML: We will use UML to summarize Japanese history and world history

読書猿『問題解決大全』4刷、『アイデア大全』9刷さんのツイート: "@akipiiさんのご提案を受けて、このPlantUMLでソースをGitHubを公開しました。https://t.co/I8kF93dALf これだけだと日本史なので、世界史のサンプルとして「環大西洋革命」を追加しました。 何れにせようろ覚えなので、修正パッチなど遊んでいただけると幸いです。 https://t.co/aaYZyrlmSJ"

akipiiさんのツイート: "年末年始の忙しい時にありがとうございます! 歴史だけでなく、新聞の国際欄にある利害関係者の図、例えばシリア紛争、をクラス図やコラボレーション図で描く、とか、色々アイデアが膨らみます。… "

akipiiさんのツイート: "@kurubushi_rmさんが日本史と世界史のシーケンス図がPlantUMLでソースをGitHubを公開されてます。https://t.co/RzJsYwXpUj 中国の王朝変遷の歴史、歴史上の戦争とか、色々描けそう。 他に、民法や会社法、知財法などの理解の為に、UMLが使えないかな?と思ってる。"

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

【追記2】
y503Unavailable@非公式Redmine調理法unofficialcookingさんのツイート: "Redmine界隈をネタに作成してみました。(記載判断は自分の主観) 振り返り易くすることは必要ですね。… "

| | コメント (0)

2018/12/20

Redmine 4.0.0 released !!

ずっと待ち続けていたRedmineのVer4.0がついに先日リリースされた。
ラフなメモ書き。

【参考】
Redmine 4.0.0, 3.4.7 and 3.3.9 released - Redmine

Redmine3.4.0 Released !: プログラマの思索

Redmineの新機能開発チケットの記事のリンク: プログラマの思索

【1】今回のリリースで最も重要な点は、Rails5に対応したことだろう。
最新のRubyやRailsに追随することで、セキュリティパッチや最新ライブラリへの対応などがやりやすくなるはずだ。

【2】リリースされた機能改善のうち、個人的に重要と思うチケットは下記がある。
一つは、メールを非同期的に送信する機能改善だ。

Feature #26791: Send individual notification mails per mail recipient - Redmine

Redmineを導入すると、時々、チケット更新が遅いと言われる時がある。
たいていの原因は、チケット更新のメール送信時にメールサーバーとやり取りしてタイムラグが発生する場合だ。
たとえば、大量のチケットを一括更新すると、メール送信が完了するまで次画面が表示されない症状が発生する時がある。
よって、今回の機能改善により、Redmineの性能改善に役立つ可能性が非常に大きくなる。

もう一つは、Wikiのシンタックスハイライトが100個以上の言語に対応されたこと。

Feature #24681: Syntax highlighter: replace CodeRay with Rouge - Redmine

以前から、VBやC#などのソースがコードハイライトされない問題があった。
だが、CodeRayからRougeへ変更されたことで、この問題も解決された。

よって、チケットやWikiに技術情報をたくさん残そう、というユーザの動機づけにも役立つだろう。
Redmineに情報が集約されれば、いつでも誰でも共有できるからだ。

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

Redmineの次期バージョン3.4の見所: プログラマの思索

【3】リリースニュースの中で、Bernhard Rohloffさんのコメントが最も興味を惹いた。

(引用開始)
Thanks to JP and all the people who made this release possible!
Redmine 4.0.0 will be a great base for further improvements in the future and keeps the community vital.
(引用終了)

(超意訳)
JPLとリリースを可能にしたすべての人々に感謝します!
Redmine 4.0.0は、将来のさらなる改善のための偉大な基盤となり、Redmineコミュニティの存続を維持させてくれます。

特に、日本では、Redmineがプロジェクト管理システムとして、事実上ミッションクリティカルな状況になっているので、Redmineが活発に開発されていくことには重要な意義がある。

今後もRedmineを安定運用したいならば、ソフトウェアの寿命が長持ちするように、Redmineコミュニティもずっと活発で居続けなければならない。
そのためには、熱心なユーザと活発にパッチ貢献する開発者、そして活発にコミットするコミッタの三者の活動が鍵を握る。

幸いなことに、Redmineコミュニティは、プロジェクトマネージャとRuby開発者という、人的属性が相異なるユーザ層から成り立っているので、開発プロセスの運用事例や技術的なカスタマイズ事例だけのテーマに偏ることなく、多様な観点で議論できる強みがある。

今後もRedmineをウォッチしていく。

| | コメント (0)

2018/12/10

チケット駆動開発のアイデアがRedmineへ与えた影響は何か

この記事は Redmine Advent Calendar 2018 の12月25日分です。

Redmine Advent Calendar 2018 - Adventar

チケット駆動開発というアイデアがRedmineに与えた影響を改めて考察してみる。
以下はラフなメモ書き。

【1】チケット駆動開発の発端とは?

Redmineを導入運用する時、「チケット駆動開発」という言葉を使う場面がある。
既に、さかばさんがチケット駆動開発の由来と経緯について書かれている。

TiDD:チケット駆動開発: ソフトウェアさかば

必然から生まれたチケット駆動開発 - XP祭り関西2009 その3-: ソフトウェアさかば

チケット駆動開発の概念は、2007年にTracのチケット管理から生まれた。
その素朴なアイデアは、「チケット無しのソースコミット不可」「No Ticket, No Commit」。

2008年頃、そんなチケット駆動開発のアイデアをRedmineで試してみたら、XPに基づいたアジャイル開発に適用できることに気づいた。
そんな僕の経験を熱く語っていたら、さかばさんが「チケットはXPのタスクカードと同じ」と上手くまとめてくれた。
この言葉がヒントになって、Redmineによるチケット駆動開発を運用した時のPJ管理の技法、チームビルディングの技法に対し、既存の専門知識を片っ端から適用してみた。
たとえば、アジャイル開発、ソフトウェア工学、PMBOK、ITIL、品質管理、など。
そういうアイデアを専門知識で補強することで、より理解が深まる一方、理論はそのまま適用できず、効果を出すには前提条件や制約条件が色々あることにも気づいた。

【2】チケット駆動開発はどのように定義されているのか?

【2-1】Redmineでチケット駆動開発を実践した時のプロセスをフレームワーク化する試みは、下記から始まった。

脱Excel! Redmineでアジャイル開発を楽々管理 (1/5):エンジニアがお薦めする 現場で使えるツール10選(3) - @IT

【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」: プログラマの思索

【2-2】チケット駆動開発をアジャイル開発プロセスとみなした時の運用サイクルは以下になる。

1・プロジェクトで発生するタスク、課題、障害は、「XPのタスクカード」とみなし、全てチケット化する(Ticket First)。
チケットは作業指示書であり、課題管理票、障害管理票でもある。

2・それらチケットは、リリースするタイミングで、Redmineのバージョン単位にグループ化する。
Redmineのバージョンは、XPのイテレーション、Scrumのスプリントに相当する(Iteration is a version)。

3・リリースまでのPJ管理は、Redmineの優れたチケット集計機能、構成管理ツール連携機能でリアルタイムにモニタリングすることで実現する。
「No Ticket, No Commit」で、ソース修正履歴は全て、チケットで把握できる。

4・Redmineのバージョンの進捗が100%になったらリリースする。

5・リリース後、チームはふりかえりを行うし、顧客からの改善要望を収集して、次のイテレーション計画へフィードバックして再修正する。

【2-3】上記によって、チケット駆動開発によって明確になったプロジェクト運営のやり方は2つある。

一つは、プロジェクト内で発生するあらゆる作業や課題などをチケットに記録することで、プロジェクト運営はチケットのライフサイクルに置き換えられること。
もう一つは、RedmineバージョンをXPのイテレーション、Scrumのスプリントと同一視することで、Redmineのロードマップ機能は、長期のリリース計画と短期のイテレーション計画に置き換えられること。

つまり、プロジェクト運営の日々の作業は全てチケットでリアルタイムに追跡できるし、それらチケットはRedmineのロードマップ機能など数多くの優れた機能で、プロジェクトの長期の計画づくりにも使えるようになった。
すなわち、チケット駆動開発の概念をRedmineに導入することで、プロジェクト運営の全ての管理プロセスをコントロールできるようになるメリットがある。

【2-4】では、このメリットによって、PJ管理技法がどのように変化するのか。
僕がチケット駆動開発で運用した時に、プロジェクトリーダーとして一番意識したことは「チケットの取捨選択」だった。

プロジェクト運営では、日々数多くのチケットが発生し、計画当初のタスク以外に、納期までに収まらないタスクが発生する。
それらチケットを1つずつ精査し、対策を打ち、1つずつ潰していかなければならない。
見て見ぬふりして放置しても、悪い状況は何も変わらないから。

すると、ガントチャート保守という面倒な作業が必ず発生し、その作業に多大な管理工数を取られて、悪循環に陥る。
一方、チケット駆動開発では、ガントチャートは所詮、1個のビューに過ぎない。
ロードマップ、チケット一覧、カレンダー、かんばん、EVM、リソースヒストグラムなどのビューをチケット集計機能として実現できるし、それらでモニタリングすればよい。
1個のビューにこだわらず、必要な状況で必要なビューを使い、手を打てばよいのだ。

それら機能を使っていくと、バージョン単位にグループ化したチケット群を精査して、優先度の高いチケットから一つずつ潰していくようになる。
もちろん、それらチケットは時々刻々変わるが、Redmineの優れたチケット集計機能で把握できるので、プロジェクトリーダーの意思決定を支援できる。
すると、チケットを分割して次バージョンへ延期したり、捨てる意思決定が多くなると思う。
「直近の納期までに何が必要なのか」をプロジェクトリーダーに徹底的に考えさせる基盤をチケット駆動開発は提供してくれるからだ。

つまり、PJ運営を「チケットの取捨選択」というミクロな意思決定に落とすことが、実はマクロな観点のPJ運営を実現しているわけだ。

【3】チケット駆動開発の具体的な特徴は何か?

チケット駆動開発をRedmineで実装すると、下記の3つの特徴が見えてくる。

チケット駆動開発の戦略: プログラマの思索

【3-1】Redmineの優れた構成管理連携により、要件からソースコードまでのトレーサビリティのインフラが整う。これにより、Redmineは本来の(真の)構成管理ツールとして実現される。

「チケット無しのコミット不可」の運用ルールにより、チケットとソースが密関係で相互リンクされる。
つまり、チケットが作業指示書であれば、チケットを発生させた要件や仕様書からソースやビルドモジュールまで、相互にリンクで遷移でき、追跡可能になる。
よって、要件からビルドモジュールまでのトレーサビリティを理論上は実現できる。

過去のソフトウェア工学の書籍を読むと、トレーサビリティの重要性は謳っているが、その実現方法はExcel台帳でソースやバージョンを管理するなど非常に面倒に思えた。
他方、Redmineであれば、事実上、トレーサビリティを実現できる「真の」インフラになりうる。

また、Redmineはツール連携できるI/Fを持っているので、GitやJenkinsなど数多くのツールと連携すれば、「プロジェクト管理サーバー」なるものを実現できる。
つまり、PMBOKの言う「PMIS(プロジェクト管理システム)」を初めて実現できる。
僕は、PMBOKが目指していたものは、たぶん、こういうインフラが前提であって初めて理解できるのではないか、と思った。

そして、このアイデアは、ソフトウェアプロダクトライン(SPL)にもつながっていく。

さらに、チケット管理システムはソース管理と同じように、作業のUnDo、ReDoを行う為のリポジトリとみなすこともできる。

チケット管理システムは作業の構成管理と同じ: プログラマの思索

【3-2】Redmineの優れたワークフロー管理機能により、プロジェクト管理のフレームワークへ昇華・汎用化できる。

Redmineのワークフロー設定画面が意味するものは、三位一体論だ。
つまり、業務フローというアクティビティ図、ワークフローの状態遷移図、ワークフローの状態遷移表という3つの機能は、Redmineの1つの機能として実現される。

よって、PJ運営に出てくる全ての業務フロー、開発プロセスは、事実上、Redmine上で全て実装できる。
このアイデアにより、Redmineでは、WF型開発も、Agile開発も共存して運用できるメリットが出てくる。
もちろん、PMBOK、ITIL、サポートデスク、会議体管理、PC資産管理など、ソフトウェア開発以外の業務にも適用できるようになる。
ここが、Redmineの運用で一番面白く、そしてホットな部分だろうと思う。

【3-3】チケット集計結果をソフトウェア・リポジトリ・マイニングによって、色んな角度からメトリクスを採取して、プロセス改善の材料にできる。

Redmineに蓄積された過去の大量のチケットは、データマイニングの宝庫だ。
PMOや品質保証部にとって、ソフトウェア工学のメトリクスを実際に研究できる元ネタになりうる。
信頼度成長曲線というメトリクスも、こうやって作るのか、ということも初めて体験できた。

しかし、実際は、チケットの内容が詳細に記載されていないと、なかなか理論通りのメトリクスが得られないことも分かった。
他方、PMBOKのEVMやリソースヒストグラムは、こうやって実装できるのか、ということも体験できた。

チケットと言う一つのデータが蓄積できれば、PJ管理で使われるビューのうち、既存の理論をRedmineで簡単に実装できる。
さらに、Redmineは柔軟でカスタマイズしやすい特徴を活かせば、新たな観点のPJ管理のビューを生み出す可能性があるはずだ。

【4】チケット駆動開発で最も面白い特徴は、「チケットはストックとフローの二重性を持つ」ことだ。

Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ: プログラマの思索

ストック型チケットは記憶媒体、フロー型チケットは流通媒体: プログラマの思索


Redmineのチケット駆動開発では、チケットに複数の意味を持たせて運用した方が上手く回る: プログラマの思索

チケットはタスクカードであるから、フローとして流れる「流通媒体」。
一方、チケットは障害管理票、課題管理票でもあるから、ストックとして蓄積される「記憶媒体」でもある。

この2つの特徴が混在しているので、チケットの粒度を標準ルールでガチガチに定めるのは難しくなる。
なぜなら、流通媒体のチケットは細かくなるし、記憶媒体のチケットはどうしても大きくなりがちだから。

また、1つのチケットという実体は、ステータスが変更されるたびに、流通媒体と記憶媒体に性質が変わる特徴も持つ。
たとえば、タスクのチケットはフローとして流れるが、途中で仕様変更やらソース修正の内容など、ストックの内容が蓄積される。
他方、障害管理票のチケットは、当初は障害内容や対策を詳細に書いてストックとして蓄積されるが、テスターと開発者の間でやり取りする時、チケットはフローとして流れる。
そのおかげで、チケットはキャッチボールのような雰囲気になる。

つまり、チケットは障害や仕様変更の内容をストックして持つ一方、チケットで進捗管理でき、ワークフロー設定に沿って変更管理が自然に行われる。
すなわち、チケットは、データマイニングの元ネタやナレッジ基盤となる「記憶媒体」の側面と、進捗管理や変更管理などを回す「流通媒体」の側面が既に埋め込まれている。
よって、チケットの粒度に悩むよりも、このチケットの二重性を意識して運用したり、その特徴を活かすように知恵を絞る方が良いと思っている。

【5】チケット駆動開発の今後の課題は何か?

課題は3つあると思う。
一つ目は、チケットの粒度、チケットの完了条件について、考え方を整理すること。
チケットの粒度は、ソフトウェアの本質的な複雑性に由来すると考えているので、それを逆手に取って、ソフトウェアの本質をチケット駆動開発で探ることもできるはず。

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

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

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

2つ目は、チケット駆動開発で実装できるプロセス基盤の種類を整理し、それらプロセスの特徴・メリット・デメリット・プラクティス・アンチパターンを明確にすること。
たとえば、WF型開発、Agile開発、PMBOK、ITIL、サポートデスク、PC資産管理、など。

Redmineが今後発展する方向のアイデア: プログラマの思索

Redmineが今後発展する方向のアイデアpart2: プログラマの思索

3つ目は、チケット駆動開発と組織の関係を整理し、「組織がチケット駆動開発をどのように複雑化させるのか」「チケット駆動開発は組織にどんなメリットをもたらすのか」を明確にすること。

第15回東京Redmine勉強会の感想~Redmineの2つの顔が相異なる2つのユーザ層を生み出している #redmineT: プログラマの思索

大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響: プログラマの思索

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

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

Redmineは戦略に従う。そして、Redmineは組織に従う~システム運用フローの背後にある組織構造の影: プログラマの思索

Redmineとチケット駆動開発は表裏一体と思っているので、Redmineを使うことで、色んな実験ができると思う。
それらアイデアを試してみたい。


| | コメント (0)

«Redmineの新機能開発チケットの記事のリンク