2018/06/07

7/7土の第2回astah関西の見所 #astahkansai

2018/7/7土にグランフロント大阪で、第2回astah関西勉強会を開催します。
勉強会の見所と、最近僕が考えているモデリングに関する問題意識についてラフなメモ書き。

【告知】
astah関西 第2回勉強会 - connpass

【参加申し込み】
Osaka Mix Leap Study 特別編 - astah関西 第2回勉強会 - connpass

【過去の資料】
第1回astah関西勉強会の感想 #astahkansai: プログラマの思索

【告知】astah関西 第1回勉強会を7/14金に開催します #astahkansai: プログラマの思索

【1】今回のテーマは、「開発現場のモデリング事例紹介」です。

(引用開始)
実際にastahを使っているエンジニアに、開発現場でastahを使ったモデリング利用事例を語って頂きます。
具体的には下記になります。

・astahをより良く使えるためのTips
・リバースエンジニアリングによるモデリング技法に関する事例
・STAMP等の機能安全規格のモデリングに関する事例
・astahを使って、匠メソッドによるビジネスモデリングを行う事例
・astahのRedmineプラグインの利用紹介

また、グループディスカッションでは、モデリングの初心者も気軽に質問できたり、モデリング経験者の経験談を共有できる場を設けます。
(引用終了)

第2回勉強会では、チェンジビジョンの開発者の方2名だけでなく、astahフレンドというastah公認ユーザ、匠メソッド勉強会スタッフをお呼びして、幅広く講演していただけることになった。
たとえば、ビジネスモデリングやリバースエンジニアリング、astahのより良いTips、STAMP等の機能安全規格など、業務システム設計に限定されず、幅広い充実した内容になった。

【2】「モデリング思考とモデリングツールは表裏一体である」という考え方

スタッフ打合せで、@kawakawaさんから「astahとモデリングのどちらをやりたいのですか?」という質問があった。
また、稲田さんから「勉強会の目的、ターゲットは何ですか?」という質問もあった。
以下、自分の考えを書いておく。

僕は以前から、モデリングの技術とその思考にはIT業界に入ってからずっと興味を持っていた。
理由は、いくつもの失敗プロジェクトの原因には、プロジェクト管理やチームビルディングだけでなく、システムを業務やアーキテクチャの観点できちんと設計できていなかった事の方が多いのでは、と痛感していたから。

そのうち、astahを使って、自分が思いつくまま、ラフなスケッチをたくさん書いてきた。
そうするうちに、モデリングという思考技術とモデリングツールは表裏一体ではないか、と感じてきた。

たとえば、UMLでは7つのダイアグラムを用いて、一つのシステムを複数の観点で徹底的に分析する。
UMLの中に、複数の観点でシステムを分析する、という思考方法が既に埋め込まれている。

あるいは、データモデリングでは、T字形ER手法のように、マスタとイベントの間の外部キー・複合キーの制約には、業務上の制約が反映されている、という考え方がある。

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

そういうモデリング作業で重要なノウハウというものは、紙でモデルを書いてもいいが、モデリングツールを使うことで自然に身に付く、という場合が多いことに気づいた。
実は、モデリングツールの機能に、そういう数多くのノウハウがいくつか埋め込まれているからだ。
他に、モデリングツールを使うと、気軽にモデルを描けるため、自分の頭で空想していたモデルを書き出すと、たくさんの矛盾や曖昧さが出てきて、色々書いていくうちに、気づきが多くなる、という経験もあった。

そうして、数多くのモデルをモデリングツールで描くことで、自分の中に数多くの暗黙知が溜まってきているのは感じていた。
だから、そういう経験をコミュニティと言う場でみんなと共有して、議論を深めたい、という気持ちがあった。
たぶん、僕なんかよりも、もっと深く考えている人はたくさんいるだろうし、そういう人たちと数多く議論して、気づきを得たい。
あるいは、自分が持っているモデリング上の問題意識を公開することで、誰かに気づきを与えたり、逆に、自分が教えられる場合があるかもしれない。

例えば、モデルと設計書、プロセスの間で発生する「モデルの粒度」「モデルのトレーサビリティ」「モデルの変更管理・構成管理」に関する疑問は、astahに限らず、モデリングツールを使いながら、ずっと問題意識を持ち続けてきた。
その辺りも色々議論してみたいと思っていた。

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

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

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

そういう僕のわがままな要望に賛同してくれたスタッフが数多く集まってくれたことで、昨年初めてastah関西コミュニティを開催できたし、今年も開催にこぎつけることができた。
ゆえに、astah関西のスタッフには特に感謝したい。
そして、第2回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

| | コメント (0)

2018/05/27

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

第14回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
感想をラフなメモ書き。

【参考】
2018/5/26 第14回勉強会 - redmine.tokyo #redmineT - Togetter

第14回勉強会 - redmine.tokyo

redmine.tokyo 14 で登壇してみた – アカベコマイリ

【1】グループディスカッションで話を聞くと、最近Redmineを運用し始めた、という人から、10年近く触っている人まで幅広いユーザ層でした。

また、1年前から参加者の女子率が上がっているように感じてます。
女性陣もデザイナー、品質保証部、PMO、インフラ管理者など幅広い分野で活躍しており、Redmineに関する問題意識も当然高い。
以前は、40代のおっさんばかりがRedmineコミュニティにたむろしていたのを振り返れば、感慨深い。

ゆえに、参加者層が幅広くなったおかげで、ユーザコミュニティの雰囲気は、毎回開催するにつれて良くなっていると思う。

【2】個人的には、Twitterでやり取りしている人と対面できたのも嬉しい。
講演してくれた@akabekobeko さん、@nekosanz1 さん、グループディスカッションでお話できた@endo_5501 さん、@kabukawaさんを認識することができた。
もちろん、@kaorabeさん、@MadoWindaheadさん、@acha_821さん、@aj15_aj15さん達ともお話できたのも楽しかった。
また、Redmineコミュニティが縁で結婚されたカップルも居る。

コミュニティを通じて、輪が広がるのも楽しい。

【3】山崎さんの講演では、Redmineとツール連携する例として、MSProjectからRedmineへインポートするプラグイン、RedmineとSlackを同期するプラグインが紹介されていた。
(たぶん、山崎さんの会社でプラグインを作成されているだろう)

プロジェクトマネージャの要望としては、立上げ時にMSProjectで作ったプロジェクト計画をRedmineへインポートしたい要望が多い。
ざっくりしたスケジュールを引いてクリティカルパスを表示させるのは、やはりMSProjectの方が楽だから。

しかし、予定はMSProjectで作ったとしても、その後の実績管理はRedmineの方がはるかに運用しやすい。
日々の進捗はどんどん変わるし、複数人が編集して最新化する手間を考えると、MSProjectに拘る必要はないと思う。

このプラグインで面白いのは、親子チケットの構造をRedmineでも再現できる点。
現状のRedmineのREST APIでは、ツリー上のWBSを作る時、どうしても2回発行しなければならない。
なぜなら、親チケットが決まった後で、子チケットをぶら下げる更新処理が必要だから。
ゆえに、1回の更新で、しかもチケット番号を昇順に採番して更新するような仕組みがあると便利だろう。

【3-1】また、Slack連携では、Redmineの活動ログをSlackに流すだけでなく、SlackからRedmineへチケット登録する運用が紹介されていた。
仕組みとしては、Slack上で、「タイトル:~、内容:~」のようにコメントすれば、RedmineのREST API経由で登録される仕掛け。

Slackからチケット登録できるメリットは、Slack上で障害を見つけたやり取りをしている時に、Slackから即座にチケット登録したい時もあるだろう。
すなわち、Slackの運用が既に定着していて、Redmineに情報を集約して記録して残したい場合に、有効に使えるだろう。

【3-2】似たような例として、@netazoneさんがGoogle Homeで、ボイス入力した内容をRedmineにチケット登録する利用事例のLTがあった。
仕組みとしては、Google HomeからIFTTT(IF This Then That)・GMail経由で、Redmineへチケット登録メールを送って、メールによるチケット登録機能を使っていた。
Google HomeからRedmineのチケット登録ができるメリットは、PC操作無しで会話するだけでチケット登録できること。
たとえば、カスタマーサポートや事務担当者などの非エンジニアが使う利用シーンが考えられる。

このように、Redmineの優れた外部I/Fを上手く使えば、チケット管理のコストを下げることが出来るだろう。
また、現場の利用シーンを考えながら、Redmineと連携する設計を考えるのも楽しい。

【4】@akabekobekoさんの「なじむ Redmine」も面白かった。

個人的には「Redmineを浸透させるために、故意に「活況を演出する」」という考え方が面白かった。
つまり、流行っているレストランは、流行っているから更に新規顧客も増える、という現象と同じ。
特に日本人は、皆がやっている雰囲気に弱いので、故意にRedmineの活況を演出し、Redmineに触らざるをえない雰囲気に持っていく。

事例としては、Wikiで議事録や設計メモをまとめることから入り、その後チケットの運用に入っていく。
どうやら、初心者にとって、チケットを登録するのはハードルが高いらしい。
チケットのUIはボタンが多いし、ちょっとの更新でも履歴が残ってしまうので、変な更新ができない、完璧に書かないといけない、という心理が働くらしい。
几帳面で完璧主義の古き良き日本人にありがちな行動だろう。
だから、そんな時は、周囲がサポートする。
たぶん、Redmine警察とか、Redmine職人、とか、Redmineエバンジェリストの出番なのだろう。

【5】実は、今回の勉強会では、RedmineのGit連携が最大のテーマだったと思う。
パネルディスカッションで取り上げられた。
@akabekobekoさんの講演でも、最後の課題にあげられていた。

(引用開始)
最近、日本のRedmine 界隈で話題?になった記事
Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索
↑で挙げられている内容はRedmine 運用していて強く 実感させられる課題です。
私的には環境面の運用が厳しい。インストール、更新、プラグインやテーマの配布と互換性など。
(引用終了)

【5-1】パネルディスカッションで、パネラーや参加者の声を聞く限り、RedmineユーザはSVNとRedmineの連携はよく使っているが、Git連携を使っている人は少ない印象を持った。
つまり、SVNの知見は皆良く知っているが、Gitの知見を持つ人は少ない。

話を聞いた印象としては、プロジェクトマネージャやPMOとしてRedmineでチケット管理している人たちは、そもそもGitを運用する利用シーンがそもそも無い。
彼らのモチベーションはチケット管理による作業の進捗管理やリソース管理がメインだから。

【5-2】一方、RedmineとGitを連携して運用する場合、2つのパターンの事例があった。

1つ目は、RedmineとGitlab、Gitoliteと連携して、Redmineではチケット管理、Gitlab側ではブランチ管理で分けている。

Redmineサーバー側にGitのBareリポジトリをクローンし、Redmineのリポジトリ画面と連動させる運用をしている。
もちろん、Redmineのチケット番号をGitのコミットログに埋め込むので、トレーサビリティは維持できている。

しかし、Gitlabのプルリクは使えていない。
あくまでも、Gitのブランチ管理とマージ作業だけに限定されている。
よって、昨今のGitHubで最も優れている運用方法「プルリク時点のコードレビュー」が仕組みとして提供されていないデメリットがある。

2つ目は、Redmineのチケット管理とGitHubのソース管理は明示的に連携せず、Redmineではプロダクトバックログや障害チケットの管理を行い、GitHubではマージやプルリクを使う、と運用を分けている。

すると、GitHubでは活発なプルリクが行われるので、プルリクのタイミングで必ずコードレビューが行われて、masterの品質は維持される仕組みになる。
このプルリクとコードレビューが密接に関係することで、エンジニア同士のコミュニケーションが促進され、お互いの理解も進み、ソースの品質も維持される仕組みが作られた点にあると思う。

しかし、Redmineのチケット管理と連動していないので、チケット管理ツールの最大のメリットの一つであるトレーサビリティ機能が使えていない。
結局、Redmineのチケット単位にトピックブランチを手動で作り、トピックブランチをプルリクする時点で、Redmineチケットを更新するという手動の運用ルールでカバーしている。

すなわち、現状のRedmineのGit連携には、昨今のGitHubのプルリクという優れた機能を埋込できていない。
よって、Gitの恩恵を最大限活用できているとは言えない。

MAEDA Goさんのツイート: "https://t.co/9GswyYgo4P にコミットするときいつもすごく緊張する。コミットログをスペルチェッカーにかけ直したり、diff見直したり。 #redmineT"

【5-3】RedmineのGit連携の機能が不十分である、という課題は、おそらく有識者は皆知っていて、何とか解決を図ろうと色々試されている、と思う。

@agilekawabataさんは、RedmineのBareリポジトリを作成するプラグインを作ったら欲しい人はいるか、という質問を投げかけていた。
初心者にとって、GitのBareリポジトリを作成する作業はハードルが高いので、プラグインがあれば、その部分のハードルは下がるだろう。

onozatyさんのツイート: "Bareリポジトリを画面側からクローンできると確かに楽だなぁ。 (回数がそこまで多くないので耐えられているけど、、)… "

onozatyさんのツイート: "そですね、きつすぎますね。 GitLab+Redmineで使っているのですが、新規プロジェクト立ち上げる時の手間がそれなりにかかるので、そのあたりもう少し便利になるといいですね。 画面からBareリポジトリ作れるようになると、画面操作だけで完結するので敷居も下がるかなと。… https://t.co/tJVZYxcff5"

また、maeda-m さんのredmine_git_work_in_progress プラグインでは、作業ブランチとマージ先のブランチのDiffやブランチの状況を可視化する機能を紹介されていた。

matsukei/redmine_git_work_in_progress: This is a plugin that provides Reduine's Issue like "Work In Progress Pull Request" and makes it easy to share knowledge.

あるいは、RedmineとGitlabを連携したり、RedmineとGitHubを連携する方法で運用をカバーするやり方もある。

akipiiさんのツイート: "#redmineT Gitlab からベアリポジトリを作ってRedmineと連携してるのね。では同期はどうしてる?"

taikiixさんのツイート: "(会場で結論が出ているかもしれませんが)私はこのプラグイン使っています。 https://t.co/C0DQ7APwxL… "

koppen/redmine_github_hook: Allow your Redmine installation to be notified when changes have been pushed to a Github repository.

たむさんのツイート: "うちは、gitlabとredmineは独立したインスタンスなので、nfsマウントしていますよ… "

MAEDA Goさんのツイート: "mod_perlがRHEL 7から標準ではなくなったので、https://t.co/YqxU0tFwwx のインストールめんどくさそう。 #redmineT"

【5-4】RedmineとGitlabの連携で最大の問題となるのは、GitのプルリクとRedmineチケットが密接に連携できない点がある、と思う。

例えば、プルリクを作る前に、その作業のチケットがない場合、Redmineにチケットを書いて、Gitにチケット番号を書いてコミットしてプルリクを送る、という面倒な作業が発生しないか。

あるいは、トピックブランチの作業とチケットが連動できていても、プルリクを送りたい場合、プルリクに相当するリビジョンをチケットに明示的に書いて、チケットを「プルリク」ステータスに変更して、作業するのは面倒ではないか?

akipiiさんのツイート: "#redmineT @tkusukawa さんの質問はとても重要。そもそもソース修正の発端、変更管理はどこでやるの?GitHub のプルリクでやるとしても、発端のチケットが登録されてから、ソース修正が発生する。プルリクは発生チケットの後になる。ではどうやって紐づけるの?"

門屋浩文@redmineエバンジェリストの会さんのツイート: "修正変更の出発点と完了条件を決めるツールによるということか? #redmineT… "

おそらく一般の運用ルールでは、GitのトピックブランチとRedimneチケットは1対1に対応させるはず。
たとえば、Redmineチケットを発行後、チケット番号をGitブランチ名に明示的にSuffixとして入れて、対応付けて運用するだろう。
たとえば、#12ブランチみたいな感じ。
すると、masterにマージしたい時に、プルリクしたい、というステータスをRedmineチケット上に設けざるをえない。
つまり、Redmineチケット上のステータス変更でプルリクを検知し、コードレビューが行われ、OKならば、マージされてチケットもCloseされる運用になるだろう。

本来はこの運用がRedmineの機能として、手軽に操作できるように実現できたらいい。
現状は、Git上でマージ作業を行い、Redmineのチケットを別途更新する、といった作業が2つのシステムで発生するので、正直面倒に感じやすい。
実際、GitHubでは一つの画面で操作できているから、尚更そう感じてしまう。

一方、Redmine本家のPatchチケットのように、パッチファイルとRedmineチケットが1対1の場合もある。
つまり、Redmineチケットが発行されないまま、トピックブランチが作られ、マージして欲しいなと思う時点でパッチファイルを出力して、Redmineチケットにパッチファイルを添付する運用スタイル。

この運用では、trunkが成長するにつれて、パッチファイルが古くなってしまい、マージされるタイミングを逸失されがちになる。
昨今のように、ビジネスレベルでもアジャイルが求められる時代では、このパッチ主導の運用は正直、時代に合っていないと思う。

よって、今後のRedmineのGit連携の機能改善としては、下記3点が必須になるのではないか。

(1)GitのBareリポジトリ作成を画面上の操作で行える。
さらに、GitのBareリポジトリはリアルタイムに同期される。
(2)GitのトピックブランチとRedmineのチケットを1対1に明示的に対応付ける操作を画面上で行える
(3)GitHubのようなプルリク機能をRedmineにも取り入れて、GitのマージをRedmine画面上で操作できるだけでなく、チケットCloseも自動更新できるようにする

【6】参加者に聞いてみたら、東京Redmine勉強会ではいつも講演が盛り沢山なので、たとえば午前10時から午後17時までRedmineカンファレンスを開催する、とか、限定されたテーマでRedmine勉強会を開催してはどうか、という意見があった。

Rubyカンファレンスには及ばないけれども、Redmineカンファレンスみたいなイベントがいつか開催できるといいな。

| | コメント (0)

2018/05/25

「大学生・社会人のための言語技術トレーニング」の感想

「大学生・社会人のための言語技術トレーニング」の本がとても良かったので、感じたこと、考えたことをラフなメモ書き。
自分の考えと感想を混ぜて書いているので、ロジカルでない。

大学生・社会人のための言語技術トレーニング - 発声練習

医学書院/週刊医学界新聞(第3054号 2013年12月02日)

7月の言語技術教室: タイガ日記

言語技術の有効性 三森ゆりかさん | 女王様のブログ

【0】書店に行くと、ロジカルシンキングや論理的思考の書籍がたくさん並んでいるし、たくさん売れている。
なぜ、そんな本が売れるのだろうか?

「大学生・社会人のための言語技術トレーニング」を読んだ後、たぶん、日本人は小学校から大学まで論理的思考の訓練を習得しないまま就職して、実際のビジネスで数多くの論理的思考を使う場面に遭遇するので、慌てて勉強し直す必要があると感じているから、と思った。

【1】ロジカルシンキングとかクリティカルシンキングとか、色んな本を読んできたけれど、「大学生・社会人のための言語技術トレーニング」を読んで、ようやく、日本語での思考と英語での思考では方法が違うのだ、という事がよく分かった。
もちろん、英語でも日本語でも、言語を使うのだから、論理的な思考を行う方法は双方とも適用できるし、同じ結果も得られる。

しかし、日本語というツールは、その内包する弱点を特に意識しなければ、たぶん、論理的に思考する時に数多くの落とし穴にはまってしまいがちなのだろう、と感じた。

【2】日本語の最大の弱点は、主語なしでも書けること。

【2-1】「私は」「あなたは」「彼が」という言葉を使わなくても、自分の主張を公表できる。
むしろ、日本語では、「私は~と考えます」といつも使っていたら、自己主張が強すぎ、のように思われて、引いてしまう雰囲気になる。

しかし、英語だろうが他の言語では「I think~, because~」という表現は普通だ。
そういう構造が言語に埋め込まれていれば、自然な発言が自己主張につながるし、自分の立場を明確に公表する、という言動につながっていく。

日本の小学校・中学校の国語の試験問題を見ると、「この文章の主語は誰でしょう?」みたいな問題があったりする。
こういう主語探しの問題は、英語ではありえない。

日本の文学では、主語なしの文章で、故意に複数の解釈を埋め込む技法もある。
例えば、川端康成の「雪国」の最初では、トンネルを抜けたら雪だった、という文章の主語を故意に省略し、後で、主人公の発言であったかのようにストーリーが進む。
しかし、こういう文学的技法は、政治やビジネスのように交渉する場面では全く不要。

日本人は自己主張が弱い、という理由は、たぶん、「私は~と思います。理由は~だからです」という文章が日本語の構造として形式的すぎて、日常会話で話すと不自然に感じてしまう、という弱点があるからだろう。
よって、「主張→根拠→結論」という一般の3段階論法を、日本語で自然に話すのが、上手くフィットしない雰囲気を感じてしまうからだろう。

【2-2】「大学生・社会人のための言語技術トレーニング」で興味を惹いた点は、中学生向けのドイツ語の小説で、文章の主語が3人称→1人称→3人称に変遷する時に、読者である中学生がその文章の主人公に意識を挿入しやすいことがある、という指摘。

実は、その小説で男の心理を3人称で語っている文章は、第三者的視点で客観的に語っているのだが、1人称で語っている場面では、男の心の中の動きであり、主観的であり、実は狂気な言動、という仕掛けになっている。
つまり、中学生は、日常生活ではありえない狂気の男性の心の中に入り込むことで、小説内で疑似体験しているわけだ。
そういうテクニックもあるらしい。

【2-3】他の日本語の弱点として、時制がないという点もある。

「大学生・社会人のための言語技術トレーニング」の一節では、ドイツの小説には過去形の文章が続いた後で、現在形の文章に急に変わった場面がある。
実は、過去形の文章は他人事だが、現在形になることで読者がその状況に入り込むことで、小説内で疑似体験するように仕向けている、と言う。

しかし、そういう技法を日本語で翻訳しようとすると、変な日本語になってしまって読みづらい、という事もあるのだろう。

【3】「大学生・社会人のための言語技術トレーニング」で「説明の黄金律」というものが紹介されている。
空間配列、時系列、重要度(度合い)の3つだ。
この考え方をドイツでは小学生低学年から叩き込まれるのに、日本の小学生は国語でも習わない。

【3-1】特に、空間配列(Spacial Order)という考え方を日本人は意識していない。
これは構造の順序そのもの。
説明の順序は、外から内へ、大から小へ流れる。

しかし、日本人のよくある説明は、空間配列の順序で整理して話さないために、あちこちの論点に散在する説明になってしまい、主張や結論が曖昧に聞こえてしまう。

「大学生・社会人のための言語技術トレーニング」では、フランスの国旗の説明で空間配列を説明せよ、という問題があり、良い回答と悪い解答の比較が非常に面白い。

また、「大学生・社会人のための言語技術トレーニング」によれば、絵の分析は、空間配列の考え方の強化に最適らしい。
絵の分析は、事実と意見の違いを明確に区別する訓練にもなるらしい。

たとえば「偉大な物理学者アインシュタイン」という文章では、どこまでが事実で、どれが意見解釈なのか?
それを即座に読み取れるか?

【3-2】空間配列=構造の順序、時系列=時間の順序、重要度=比較の順序。
実はこの考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」にも記載されていた。
彼女の本には、この考え方は小学生頃から知っているから、という一節が書かれているが、実は、日本の小学校の国語ではこんな考え方を僕は習って来なかった。
だから、論理的に思考する、論理的に話す、という手法に苦労してきたのかもしれない。

【3-3】「大学生・社会人のための言語技術トレーニング」では、物語の構造についても詳しく説明してくれている。
簡単な具体例は、桃太郎。
物語の構造は、英語であれ日本語であれ、古今東西同じ。

物語の構造は、状況→複雑化→疑問→答え、という流れになる。
しかし、英語圏ではこの物語の構造という考え方を明確に小学生の頃から教わっているのに、日本の小学校では明確に教えられていない。
実は「状況→複雑化→疑問→答え」という考え方は、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」の最初に記載されている。

「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」では、プレゼンのイントロ部分では、古典的な技術であるストーリー形式(物語形式)で始めると聴衆を引き込みやすい、という一節がある。
その一節で、「状況→複雑化→疑問→答え」という考え方が紹介されていた。

僕が、バーバラ・ミントの名著「考える技術・書く技術―問題解決力を伸ばすピラミッド原則」を最初に読んだ時、とても堅苦しくて読みにくい本だ、どこが名著なのか分からない、と感じていたが、「大学生・社会人のための言語技術トレーニング」を読んで理解した後で読み直すと、なるほど、そういう背景があったのか、とようやく理解することができた。

【4】パラグラフ・ライティングという技法も、日本の国語の授業で習わない。

トピック・センテンス→サポーティング・センテンス→コンクルーディング・センテンスという流れ。
トピックセンテンスには、コントローリングアイデアが必要。

パラグラフ・ライティングには5つのルールがある。
・各段落に話題(テーマ)は一つ。
 →日本語なら、意味段落に相当する。
  「意味段落◆----形式段落」のような構造。
  日本語の文章は、形式段落がむやみに多すぎるので、意味段落にまとめる作業が別途発生する。
  「形式段落を意味段落にまとめよ」という国語の試験問題もあるらしい。

・話題文(トピックセンテンス)は段落の先頭に置く。
・話題文だけで話を成立させる
 →コントローリングアイデアに相当。

・不用意に接続詞を置かない。
・論理を整理しておく。

パラグラフ・ライティングを発展させると、「序論→本論→結論」という学術論文の基本構成になる。
つまり、小学生が習うパラグラフ・ライティングを起点として、10年かけて論理的思考を徹底的に訓練した後、大学生の卒業論文という結果になる。

【4-1】日本人の文書が分かりにくい、と言われる原因のうち、最大の原因は、起承転結のスタイルで書いているからだろう。

起承転結のスタイルでは、前置きが長く、結論が一番最後になるので、すぐに結論を判別できない。
だから、エレベータートークで話すように訓練しろ、と、新人社員はよく言われるわけだ。
日本語の文章は、結論が後回しになりやすい。

他にも原因がある。
一つは、空間配列の技法を習得できていないために、情報を構造として整理できていないこと。
情報を外から内へ、大から小へ、という構造で整理していないので、情報の粒度がバラバラで、論点が分かりづらい。
ちょうど、外部設計から内部設計へ、というソフトウェア設計の考え方と同じ。
いきなり、プログラムの詳細設計レベルの話をされても、そのシステムは結局何ができるのか分からない、という問題と同じ。

もう一つは、日本語特有の論理スタイルが悪いこと。
たとえば、主語なし文章のようなゾンビ文。
時制が曖昧。
形式段落が多すぎて、意味段落としてまとめられていない。

【4-2】日本でオブジェクト指向が普及しなかった、という理由の一つは、オブジェクト指向の日本語の文章が感覚的に変、という事もあるだろう。

「オブジェクトが~する」という文章は、まるでモノが人のように振る舞う点が日本語として感覚的でない。
むしろ日本語としては、「オブジェクトは~される」という受動態で表現する方が感覚的に読みやすい。
つまり、逐次実行的な受動態の文章スタイルの方が、詳細設計の文章は肌感覚で合う。

【4-3】「空間配列・時系列・重要度」という考え方は、チケット管理にも即座に適用できる。

空間配列は、チケットの粒度そのもの。
WBSのように、工程→作業→成果物のように粒度を詳細化していく考え方と同じ。

時系列は、チケット登録日、更新日の順序と同じ。
重要度は、チケットの優先度、チケットの並び順、リリース順、と同じ。

【5】「大学生・社会人のための言語技術トレーニング」では、自分の意見を立証するための構造として「トゥールミンモデル」が紹介されている。
たとえば、絵の分析で、こういう人物が描かれているので、私はこう考えた、と主張する時、その証拠とその論拠を明確にして、主張を支える技法だ。

この技法を発展させると、クリティカルシンキング、クリティカルリーディング、批判的思考につながっていく。

トゥールミンモデルの考え方は、ゴール思考モデル(GSN)につながるし、昨今の自動車業界における機能安全規格の要件適合やシステム適合性にもつながる。
つまり、なぜこの自動運転システムは機能安全といえるのか、という主張を支えるための証拠や論拠を揃えて、論理的に組み立てる必要性があるわけだ。

【6】「大学生・社会人のための言語技術トレーニング」に書かれている素材は、小学生の国語の内容と同じ。
しかし、ロジカルに読む・書く・考えるという技法は、実は日本人は意識していないのかもしれない。
僕自身も明確に意識していなかったので、改めて、理解できた部分は書き残してみた。

| | コメント (0)

第14回東京Redmine勉強会の見所


第14回東京Redmine勉強会の見所についてラフなメモ。
そして、今後のRedmineコミュニティの方向性について、最近個人的に考えていることをラフなメモ書き。

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

第14回redmine.tokyo勉強会 - connpass

【1】今回の勉強会では、講演者もLTを含めて11人と豪勢な内容になった。
また、Git連携に関するパネルディスカッションを入れたり、グループディスカッションも入れているので、相当盛りだくさんの内容になっている。

【1-1】今回のテーマは『Redmineとその周辺ツール活用事例』。
REST APIやGit連携、他システムの連動に関する事例がある。

僕は、Redmineの醍醐味は外部ツールと色んな手段で連携できるI/Fを持つことではないか、と思っている。
なぜなら、Redmine単体で不足している機能は、Redmine標準で用意しているI/Fを使って外部ツールに任せることができるから。
そういうシステム設計や運用を考えるのも楽しい。

また、Redmineは構成管理ツール連携が当初から標準だったので、この機能を使ってトレーサビリティがどんな性質を持つものなのか、実体験できたのも良かった。

但し、今後はGit連携の強化がRedmineの鍵になると思っている。
その内容に関する議論は、パネルディスカッションで盛り上がるだろうと期待している。

Redmineの直近の課題~競合ツールGitlabに対抗できるか: プログラマの思索

【1-2】個人的には、@akabekobekoさんに講演して頂けることがとても嬉しい。
以前から、下記の記事は参考にしていた。

Redmine 運用について 1/3 ? はじめに ? アカベコマイリ

Redmine 運用について 2/3 ? 運用ルールと諸設定 ? アカベコマイリ

Redmine 運用について 3/3 ? 普及の施策と課題 ? アカベコマイリ

(引用開始)
つきあいの長い Redmine について以前からまとまった文章を書いてみたかったのだが、なかなかその気にはならなかった。書きはじめたら長くなるのは必然で、そのため腰が引けていた。そんな折、Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例: プログラマの思索はてブの反応はよい刺激になった。
Excel 中心で管理したい上司をどう説得するか。説得を諦めて現実解として Excel ジェネレーターを実装するのか。
幸い私は理解ある環境に恵まれて Redmine 導入に成功したが、そうではない人や環境に対して知見の一部でも役立てば、という気持ちで記事にしてみた。
(引用終了)

既存のExcel中心の組織文化の中で、いかにRedmineを浸透させて効果を上げていくか。
そんな組織の中で、現実的で実現可能な方法やレベルはどこにあるのか。
その辺りも聞いてみたいと思う。

【2】今後のRedmineコミュニティの方向性について、最近色々考える点はある。

一つは、Redmineユーザのレベル感や興味に関するセグメント別に、Redmine勉強会を定期的に開けたらいいな、と思うこと。
理由は、東京Redmine勉強会はいつもすぐに満席になってしまうので、せっかくRedmineに興味を持っている人達を取りこぼしてしまっているのが残念だから。

最近の勉強会に参加する人達とグループディスカッションで話を聞いてみると、長年の経験者もいれば、今から触ってみたいと思いますという初心者まで幅広かった。

そんな状況をふりかえると、経験者や初心者というレベル別に向けた勉強会を別の日程で開催してみる、とか、ViewCustomizeプラグインの使い方や効果的な事例のような特別テーマに関する勉強会を開催してみる、とか、もっとバリエーションを増やしてもいいかなあ、と思う。
既に、Redmineエバンジェリスト会のように、組織とRedmineをテーマにした勉強会も運営されているので、もっと増えたらいいな、と思っている。

もう一つは、Redmineコミュニティを東京や大阪だけでなく、各地でも開催できたらいいな、と思うこと。
なぜなら、東京でも大阪でも、福岡や福井、名古屋などの遠方からの参加者が意外に多いからだ。
今の自分のパワーでは東京と大阪ぐらいしかタッチできないけれど、Redmineユーザが各地にいるならば、各地で開催できるといいなあ、と思う。

こういうオープンソースのコミュニティ活動に好きで関わっているけれど、じきに、こういうコミュニティを半永久的に維持していければいいなあ、とぼんやりと思っている。
どんな実現方法があるのか、正直分からないけれど、いつか実現できるといいな。

| | コメント (0)

2018/05/08

論文のお作法は、さかばさんから真似る

さかばさんのブログにある論文のお作法の記事がとても良くて、いつも参考にするのでリンクしておく。
以下、ラフなメモ書き。

【参考】
社会人のためのシンポジウム発表入門 リーン論文作法: ソフトウェアさかば

論文の善し悪しをサンプルで見る: ソフトウェアさかば

できる人を観察して勝負する: ソフトウェアさかば

さかば流・論文作法 その1 - 論文の構成 -: ソフトウェアさかば

さかば流・論文作法 その2 - 論文を書く上での注意点 -: ソフトウェアさかば

さかば流・論文作法 その3 - 良い技術 -: ソフトウェアさかば

【1】僕も論文を書くのは嫌いだったかな。
学生の頃、先生からいつもたくさんの指摘を受けて直すのに、OKの返事がもらえなくて苦労した。

今思い出すと、その理由は、論文特有の書き方を知らなかったから、だけでなく、経験した現実とあるべき理想の対立を自分の心の中で強く持っていなかったから、とも思う。
僕は世間にこういうことを主張したい、という熱い気持ちで書き出して、その内容を数多くの人に叩かれたり議論したりして、アイデアを鍛えて、内容をブラッシュアップしていく、という過程を、その頃は経験できていなかったから、とも思う。
ずいぶん自分のレベルが低かったと思う。

まず言いたい主張が先にある。
そこから、その主張がどんな問題を解決するのか、何が課題として今後の研究テーマになるのか、などの骨組みが決まっていく。

【2】さかばさんの下記のツイートが好き。

【2-1】
さかばさんのツイート: できる人は、頭の中で知識の構造を常にリファクタリングしている。凡人は、整理しないままで置いておくから活用できない。大学院で学んだ事の一つです。

僕はSEA関西の知的サロンのような雰囲気が好きなのだが、そこでは、アジャイル開発とか新しい技術とか議論していると、必ず定義を聞かれることがあった。
互いの議論によって、自分が持っている知識体系、理解している知識ツリーに入れば理解できたことになる。
その作業が、知識構造のリファクタリングにつながる。
世話人の方は、たぶんそういう作業を常にされているのだろう。

僕自身の経験でも、いつもポンチ絵を描いている。
モヤモヤしたアイデアを明確にするために絵を描く。
新しい知識を色んな観点で比較評価するために絵を描く。
絵を何度もリファクタリングして描き直すうちに、あるべきイメージが固まっていく。

【2-2】
さかばさんのツイート: @tunemage まずは論文で主張したい点を3つにまとめて、それを裏返して問題設定すると論文の概要ができます。それを端的に表現すればタイトル。用語を説明すれば背景になります。各段落を一行で表した箇条書きを作ってから書き出すと綺麗な構造になりますよ。

普通は、自分が言いたい主張が必ず先に存在する。
その主張から問題点を明確にして、主張を正当化する必要がある。
その作業は、「Justify」と呼ばれている。
数学ならwell-definedに相当するだろうか。

論文作成の技法part2~論文作成の観点 : プログラマの思索

Well-defined - Wikipedia

このJustifyの作業を「主張の裏返し」という言葉でさかばさんが表現されているのは凄いなあ、と思う。
自分の経験を振り返れば、主張と問題点に線を引いて因果になっているか、トレースできているか、自分でチェックしていたけれど、その作業と同じだったわけか。

問題を明確にするというJustifyの作業が重要な理由は、問題となる前提条件、スコープが明確にされなければ、主張したいアイデアが何を解決するのか、一方、現在の主張では解決できないので何が課題として残るのか、というストーリーを説明できなくなるからだ。

自分の主張で、全ての問題が解決するわけではない。
普通は解決できた部分はごく一部だけ。

でも、その主張のアイデアが優れていれば、未開拓の分野にどんどん適用されて、関連研究が広がる。
たとえば、科学者の論文でも、すごく偉い科学者が理論を打ち立てたら、その後続の凡庸な科学者は、その理論を使って細かい問題をしらみ潰しに論文を量産していく、というパターンが多い。
そういう凡庸な論文が多いので、それを関連研究として整理するのもまた一苦労、みたいな感じかな。

【3】論文作成のお作法であるロジックの組み立て方は過去にまとめていた。

論文作成の技法part1~論文の構造: プログラマの思索

【4】さかばさんの「リーン論文作法」の発表資料には、そういうノウハウが濃縮されている。
なので、さかばさんの「リーン論文作法」の発表資料はお勧めです。
ダウンロードできるので、印刷したり、スマホに常に持っておき、いつでも参照すると便利です。

| | コメント (0)

2018/05/06

Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスのリンク

最近、Markdownで資料を書いて、WordやPDF、epubに変換したり、RedmineやConpass等に書く場合が多い。
しかし、いつも表形式が書きにくい。
そこで、Excelの表をMarkdown形式に変換するExcelアドオン、Webサービスをリンクしておく。

【参考1】
選択したExcelのセルをMarkdown形式でコピーするExcelアドインをリリースしました。 - nuits.jp blog

nuitsjp/CopyToMarkdownAddIn: Add-In for copying from Excel to Markdown

Excelのアドオン。
Excel上で右クリックした後、テキストに貼り付けるだけ。
こちらを愛用してる。

【参考2】
Excelの表をMarkdown形式に変換 - Qiita

Markdown Tables generator - TablesGenerator.com

Excel上でコピーして貼り付けるだけ。

【参考3】
Markdown で書いた試験仕様書を Excel に変換するツールを作った

Markdownのテスト仕様書からExcelに変換するツールを作られたらしい。

似たような例として、FreeMindのマインドマップからテストケースを自動生成するツールもあったな。
因子の組合せによるテストケース生成は、ツールを使った方が簡単。

FreeMindからテストケースを自動生成するテストツールFMPictをリリース - 千里霧中

fmpict/manual.md at master ・ hiro-iseri/fmpict

こんな本もあった。

『マインドマップから始めるソフトウェアテスト』を読んでマインドマップを書こう! - そこに仁義はあるのか(仮)

| | コメント (0)

2018/04/28

第62回IT勉強宴会のメモ~2人の方法論者によるデータモデリング激レア対談

昨夜の関西IT宴会「2人の方法論者によるデータモデリング激レア対談」が開催された。
自分が後で読み直すために、殴り書きのメモ。
自分の感想も入れておく。
DOA屋さんから見れば、理解してないな、と思われるかもしれないが、気にせずに公開しておく。

2人の方法論者によるデータモデリング激レア対談 - connpass

2人の方法論者によるデータモデリング激レア対談<第62回IT勉強宴会in新大阪> | IT勉強宴会blog

【1】By 佐野さん
オブジェクト指向は、ゲームや組込みシステムには向いているだろう。
しかし、業務システムのように、帳簿組織を起源に持つシステムには、オブジェクト指向は向かない。
帳簿組織の業務はデータモデリングすべき。

【2】By 佐藤さん
昔はT字形ERだったが、今はTMと呼んでいる。
中身は別物。
(注:その意味は、後述)
(注:僕はT字形ERの本しか持っていないので、以後は、T字形ERと書く)

TM手法はOOAみたい、と言われる。
理由は、astahで描けるから。

注:たぶん、下記の記事のことかな?
「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料: プログラマの思索

T字形ERの対照表は、OOAの関連クラスと同じ。

【3】By 渡辺さん
AS400の頃に、RDBを本格的に触り始めた。
私は理系なので、「テーブルA:カラムa, b, c・・・」とモデルを書いていたが、周りのSEが全く理解してもらえない。
しかし、具体的にモデルを書くと、SEも理解してくれる。
仕方なく(?)、今の渡辺式ER図のようなデータモデルを書いている。

その頃に流行した4CLでモデルのテンプレートを作り、システムを自動生成するような仕組みを作っていた。
そして、自分で、Delphiでモデルのテンプレートを作り、システムを自動生成するようなモデリング支援ツールを自作していた。
それが、今の三要素分析手法のきっかけ。

感想:
DOA屋さんがOOA屋さんと同じくモデル駆動開発に行き着くのは、モデリング支援ツールを作りたかったという動機があるんだろうな、とふと思った。

【4】By 佐藤さん

Coddの論文を元に、商用ベンダーは商用RDBMSを実装した。
しかし、実際にRDBをそのまま使うとパフォーマンスが出ない。
DBMSには、性能が悪化しないように工夫している。
だから、DBMSの仕組みを理解しないと、パフォーマンスが出ない。

T字形ERは、Coddの弱点に気づいて理論として構築した。
でも、まだ欠陥が残っていた。
TM手法を構築して、佐藤さんの中では完全に解決した。

【5】By 佐野さん

OOAを毛嫌いする理由は、関数従属性を前提にしないこと。
モデルでは、単なる関連で書いている。

【6】By 渡辺さん

三要素分析法は、ER図、DFD、アクションツリーから成る。
データの形はER図、仕事の連携はDFDやアクションツリーで表現される。

データの形が決まれば、画面UIはほぼ確定してしまう。
また、データの形が決まれば、バッチ処理も決まってしまう。
仕事の連携が決まれば、システムの機能(仕様)も決まる。

そういう発想から、三要素分析法は生まれた。

XEAD Tools and Resources - 設計方法論 三要素分析法(TEA Method)

【7】By 佐藤さん

インデックス設計でアクセスパスが自然に決まる。
T字形ERでは、アクセスパスは自然に実装される。

なぜモデルは普及しないのか?という質問に対し、
モデルはあって当然。
それをユーザの環境に合わせて、どのように導入するか?をモデラーは考えるべき。

【8】By 渡辺さん

経理マンの専門知識をデータモデルで表現すると、システムの知識を知らない経理マンも、そのデータモデルを理解できる、という経験をした。
そして、経理マンは勝手に自分達でモデルを描き始める。
そういう経験を経て、モデルの重要性を感じている。

注:懇親会で佐藤さんに、T字形ERでは、顧客のビジネスをデータモデルで表現した時、イベントとリソースのテーブルの個数を数えて比較する。
その時、イベントの個数がリソースの個数よりも少なければ、顧客の潜在的なビジネスモデルを構築できる可能性がある、という話を読んで、すごく納得した、と僕は話した。
つまり、イベントとリソースの組合せで新たなイベントを作り出せる可能性があること、それは顧客の新たなビジネスモデルを構築することにつながることと同じ。

すると、佐藤さんから、ああ、その話では続きがあって、そのデータモデルを顧客に見せたら、顧客自身が自分達でビジネスモデルを作り始めたんだよ、と言われた。
その話と同じかな。

リソース数がビジネスの可能性に関係する理由: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

【9】By 佐野さん

情報系の大学の学生は、学校でデータモデルを習わない。
UMLは習うのに。
彼らも、Postgresは知っているし、使える。
でも、中身のテーブルは全てサロゲートキーになっている。
関数従属性を気にしていない。
そもそも関数従属性を考える、という行為すらしていない。
テーブルは単にデータを格納するだけ、にすぎない。

【10】By 佐藤さん

元々RADを目指していた。
T字形ERで設計すると、当時100万ステップのプログラムのうち、7割は不要になる。

でも、いつも背中から撃たれた。
同業者から嫌われる。

たとえば、大手SIのSEから、T字形ERみたいなこんなに正規化しすぎるとパフォーマンスが悪くなりますよ。
だから、パフォーマンス向上のために、あえて非正規化を施し、森羅万象テーブルみたいに1個のテーブルに300個以上のカラムを設計する、みたいなデータモデルを作ってくる。

「大規模集積回路モデル」と「板チョコモデル」: 設計者の発言

SIでは、生産性を上げたくない。
人月商売なので、開発者の人数が減ると売上が減ってしまうから。
SIは、高価格で、バグ込みのソフトウェアを納品しているんですよ、と。

【11】By 佐野さん

T字形ERはモノありき、のように感じている。
(注:たぶん、業務システムのリプレース案件では、DOAが最強だからだろう、と思った)

他のDOAの流派でも、AsIsベースが多い。
例えば、請求書をデータモデルにする、とか。

渡辺式DOAの凄い所は、いきなりToBeを描く所。
何もない所から作る。

注:懇親会で佐藤さんから、T字形ERは他のDOAと違う。
他のDOAの流派は具体論ばかり話す。
T字形ERは理論から始める。
だから、数学基礎論から勉強し直した、と言われたのが印象に残った。

Oracleを初めて触り始めた頃、OracleでSQLを書くと、テーブルをJoinした時、小さなテーブルを先に読むとパフォーマンスが遅くなる。
Oracleの中身を知らないと、なぜSQLのパフォーマンスが悪化するのか分からない。

真因は、DB設計できていないから、SQLのパフォーマンスが出ないことにある。
だから、SQLは重視しない。
むしろ、真の問題はデータモデリングにある。

X-TEA Driverの面白い所は、複数のDBも扱える。
例えば、マスタはOracle、トランザクションはPostgres、とかでもOK。
しかも、複数のDBのテーブルもJoinできる。

また、データモデルと業務の整合性も事前にチェックしてくれる。

【12】By 佐藤さん

SQLを何も考えずに書くのは信じられない。

モデルはアトリビュート、インデックス定義が含まれる。
実は、アルゴリズム指示書もある。

その中身は、Input=モデル、Process=アルゴリズム、Output=インデックスのような詳細設計書。
すると、アルゴリズムの部分は、ほとんどプログラム自動生成に近い。
プログラマは不要で、コーダーさんに近い。
SIは不要だね。

【13】By 佐野さん

ORマッパーが普及したので、SQLを書けない人も多い。

一方、SQLマッパーというモノもある。
SQLで書いたモノがオブジェクトになる。
たとえば、下地さんのRMenuではjson形式でSQLを表現でき、そのままパースできるので便利。

注:懇親会で下地さんに聞いたら、RMenuで業務システムを実装したら、最初はあえてインデックスを貼らない。
システムの運用後、データが蓄積されて、遅くなった、と言われたら、該当の画面からjson形式のSQLを抽出し、それをパースしてインデックスを生成して、組み込んでいる。
jsonだからすごく使い勝手がいいよ、と。

【14】By 下地さん

プログラムは使い捨てであるべきだ。
なぜなら、プログラムは資産ではない。
その時限りの費用で計上すべきものだ。

注:その意図は、データモデリングを極めると、テーブル設計さえ確定すれば画面UIはほぼ確定されてしまうので、プログラムはほとんど自動生成できてしまう。
つまり、プログラムで書くべき部分はすごく少なくなる。
すると、プログラムは資産というよりも、データモデルに付随したモノに過ぎない、という考え。

佐藤正美さんも、ソフトウェアを資産と考える考え方は嫌いだ、と言っていた。

但し、会計の理論上では、ソフトウェアは無形固定資産に含まれる。
だから、業務システムは保守フェーズで減価償却費が発生するし、システムの改善は、価値が目減りした資産を増やす行為になるので、会計処理も複雑になるデメリットもある。

注:
アジャイル開発では、ソフトウェア(=プログラム)は、最初は負債であり(なぜなら何もないところに投資するから)、その後、キャッシュを生み出して売上を上げていき、損益分岐点を超えたら初めて黒字になるイメージだ。
そういうアジャイル開発の考え方と整合性は取れるか?

プロエンジニアになるための「アジャイル開発」再入門

「プロエンジニアになるための「アジャイル開発」再入門」が素晴らしい: プログラマの思索

| | コメント (0)

«技術革新とエンジニアのキャリア形成にオープンソースコミュニティの存在が重要性を増している