コミュニティ

2019/06/16

業務系エンジニアが生き抜くのは難しい時代になった

業務系エンジニアが生き抜くのは難しい時代になったという記事をリンク。
以下、脈絡のないポエム。

【参考】
業務系エンジニアはどうしていくべきか? - 急がば回れ、選ぶなら近道

【1】日本のSIなら、プログラマからマネージャになるにつれて、実装技術から離れてしまい、どんどん技術から離れていく。
すると、一番怖いのは、技術の目利きが落ちることだと思う。
最新技術のメリット、デメリットをいち早く見抜き、どの場面で適用すると上手くいくのか、逆に失敗するのか、という目利きができなくなると、正直怖くなる。

結局、技術の全部を抑えておかないと難しい。

【2】「最終的にはシステムはIOに行き着く」という指摘は秀逸。
アプリ、ミドルウェア、インフラなどの層別アーキテクチャ(N-Tier)はいつの時代も基本。
最近は、インフラが熱い。
インフラを押さえれば、最近の技術の動向はいち早く把握できる。

【3】イノベーションを常に強いられる業界は、そこで働く人にとっては苦痛に思える人も多いだろう、と思ったりもする。

実際、若かった人も年を取ればどうしても、過去の経験値に縛られたり、集中力や瞬発力が落ちるので、新しい文化を取り入れるのが難しくなる。
広岡達朗の著書の中で「人間は常に保守的な存在だ」という文言を以前読んだことがあったが、たぶんその言葉は真実なのだろう。
人間は、従来成功したやり方を明日からいきなり変える、ということに抵抗感があるのだろう。

経験値がゼロで、獲得した資産や家族がなければ何も怖くはない。
しかし、長年蓄積してきた資産、経験、家族が増えてくれば、それを全て捨て去り、一から作り出すのは心理的に難しくなる。
一方、イノベーションのジレンマでは、過去の資産を活用できるプロセス・イノベーションを前提にしていない。
むしろ、イノベーションを阻害するような過去の経験は無い方が、イノベーションを生み出しやすい。

イノベーションを常に強いられるIT業界は、脱落するエンジニアが多く、経験豊富な人よりも若者の方が有利、という特徴が出てくるのだろう、と思う。
そして、「IT業界はイノベーションが激しい」ということと「IT技術は後方優位性が強い」ということは同じ意味なのだろうと思う。


| | コメント (0)

2019/05/19

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

昨日の第16回東京Redmine勉強会の感想をラフなメモ書き。
疲れているのでラフなメモ。

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

第16回東京Redmine勉強会『Ver4に上げよう Redmineのさらなる進化と多用性!』 #redmineT (18ページ目) - Togetter

第16回redmine.tokyo勉強会 まとめ

redmine.tokyo 16 感想 - アカベコマイリ

redmine.tokyo 第16回東京Redmine勉強会に参加してきました。 - みずりゅの自由帳

「Redmine 4.1 新機能選抜総選挙」で紹介できなかった新機能 10選 - ファーエンドテクノロジー株式会社

【1】昨日のRedmine勉強会でちょっと嬉しかったことは、@rechiba3 さんに初めてお会いできたことと@ohnukiさんに5年ぶりにお会いできたこと。

akipiiさんのツイート: "#redmineT 東京Redmine 勉強会から離脱しました。講演者、スタッフ、参加者の皆様ありがとうございました?? 懇親会の参加率が約7割で50人で盛り上がりが凄いと思います。今回は7年越しに @rechiba3 さんとお会いできたのが収穫でした。ユーザー層も老若男女、開発者からPMOまで幅広くて来る度に面白い"

@rechiba3 さんの下記の資料を以前読んでBlogに感想を書いたことがあったので気になっていた。

TiDDでウルトラハッピーな開発フロー実践しちゃおう!

WebディレクターによるRedmine運用事例: プログラマの思索

また、@ohnukiさんは、5年前の勉強会が大雪だった時にLTで講演して頂いたことを覚えていたから。

第6回勉強会 - redmine.tokyo

他にも@MzRyuKaさんから、懇親会でこんな話もあって盛り上がった。

みずりゅさんのツイート: "#redmineT https://t.co/XfSENoynLn 初参加、どれも凄く楽しかったけど、あえて一番を選ぶとしたら懇親会でakipiiさんとお話しできたこと。 数年前に会社のブログで書いた記事を取り上げてもらったことに、やっとお礼を言うことができました。"

チケット駆動開発の運用例part4: プログラマの思索

BlogやSNSのおかげで、実際に会ったことがなくても、すぐに仲良くなれる。
そういう場をコミュニティが提供してくれて本当にありがたい。

【2】10個以上の講演があったので、記憶に残った所だけ書き残す。

【2-1】@netazoneさん「ある工場の Redmine バージョンアップ」では、プラグイン作者にVer4.0対応を自らお願いしまくった結果、そうなったからには自分のRedmineをバージョンアップしなくては、という行動に至った気概に強く共感した。
数多くの日本人プラグイン開発者が対応してくれたからこそ、Ver4.0に安心してバージョンアップできるからだ。

つまり、Redmine本体だけでなく、主要なプラグインがVerUpに追随することは、Redmineユーザにとって非常に重要な要素である、という事実を明示していると思う。
よって、RedmineコミュニティがRedmineプラグイン開発者を巻き込んでRedmineを盛り上げていくことは、非常に重要な活動なのだ、と改めて感じた。

【2-2】@agilekawabataさん「LycheeカンバンとRedmine運用の事例紹介」では、Lycheeプラグインの機能紹介が多くなってしまったけれど、メーカーのRedmine利用事例の話に興味を惹かれた。

akipiiさんのツイート: "#redmineT 複数案件を複数チームで進捗管理するにはどうする?メーカーなら、エンジンチーム、ボディチームなどの複数チームがあるが、トラックプロジェクトと乗用車プロジェクトの親チケットから派生した子チケットは、それぞれのプロジェクトで管理したい。"

例えば、自動車メーカーでは、トラックプロジェクト、乗用車プロジェクトの2つのプロジェクトが別々にある一方、エンジンチーム、ボディチームの2チームも別々にある。
トラックプロジェクトの機能(親チケット)には、エンジンチーム、ボディチームの開発タスク(子チケット)でぶら下がるが、チームごとのプロジェクトで扱いたい。
理由は、チーム単位のタスク管理がしたいこと、各プロジェクト単位で他者には情報を見せたくないことがあるから。
現状の標準Redmineでは、Redmineプロジェクトを跨ぐ親子チケットや関連チケットは作ることができるので、ある程度は運用できるだろうが、もっと細かなニーズを実現して運用する場合は、色々問題が噴出するだろう。
おそらく、それら問題となる利用シーンでは、Redmineのカスタマイズやプラグインによる機能拡張が必要になるだろうと想像する。

つまり、複数プロジェクトと複数チームのタスク管理を横串でプロジェクト管理する手法を、Redmineが支援できる可能性がある。
そうすれば、組織をまたいだ複数案件のPJ管理のように、より大規模なPJ管理もRedmineがカバーできるようになるだろう。
本来、Redmineという一つの箱にWF型開発案件もAgile案件もデータが格納されているので、横串のデータ集計はRedmineのようなチケット管理ツールが得意な所。
その機能をさらに大規模なPJ管理にも適用していくには、Redmineにどんな機能が標準で必要になってくるのか、という問題を提起してくれた点が面白かった。

【2-3】@yassan168さんのLTでは、クラウド上でDockerを使って、Redmineを含めたサーバー構築を行った、という点が興味を惹いた。
Redmineサーバーだけでなく、リバースプロキシやDNS設定などは、オンプレサーバー上のインフラ構築作業と全く同じなのに、クラウドの方がものすごく簡単に構築できるわけだ。
オンプレミスのインフラ構築は、本当に面倒な作業だった。
たとえば、iptableをいじったり、hostsをいじったりしていたから。

しかし、@akabekobekoさんと話しながら、簡単に構築できる理由は、DockerでOSに依存しないミドルウェアの構築ができるので、後はそれらをつなぐ構成をすればいいだけ、ということで理解した。
よって、今後はAnsibleよりもDockerの方が有用だろうという気がした。

【2-4】hin-tさんのLTでは、定期的にチケット登録するプラグインを紹介していた。
営業事務の定形業務で、物忘れせずに役立つんですよ、という発言があった。
どのプラグインか忘れたので後で探しておく。

定期的なタスクをチケット登録するRedmineプラグイン: プログラマの思索

【2-5】石川さんのLTでは、message_customizeプラグインが興味を引いた。
このプラグインは、ymlに書かれた文言を修正して表示できること。
メリットは、ymlを書き換えなくても、管理画面で修正できるので、viewCustomizeプラグインに似た感覚で管理者が操作できることだろう。
すると、@netazoneさんが発した問題「海外ユーザと1個のRedmineインスタンスを共有する時、ステータスやトラッカーを日本語・英語で併記しない方法はあるか?」に対応できないか、考えてみたくなる。
一方、@g_maedaさんの話では、Redmineの画面をリロードしたらhtmlからlang=ja,enは取得できるので、その情報を元に、ログインユーザ毎に修正文言を表示できるはず、と言っていた。
たぶん、message_customizeプラグインとviewCustomizeプラグインを駆使すれば、その問題は解決可能だろうと思う。

GitHub - ishikawa999/redmine_message_customize: This is a plugin for Redmine.

GitHub - onozaty/redmine-view-customize: View customize plugin for Redmine

【2-6】堂端さんのLTでは、Redmine大阪で話したGitHub連携プラグインの続きだった。
興味を引いたのは、RedmineチケットとGitHubブランチを紐づけた後、Github上でプルリク受付、プルリク承認、masterマージという一連の作業ごとに、Redmineチケット一覧画面でチケットのアイコンが更新される機能があったこと。

つまり、GitHubからRedmineへフックさせているわけだ。
裏では、GitHubのクローンがRedmineサーバー上にあるので理解できるが、Redmineチケット一覧でプルリクのステータスをアイコンで判別できる機能は良いな、と思った。

但し、RedmineチケットとGitHubブランチを紐づける時に、「xx@#チケット番号」のようにブランチ名にプレフィックスを付ける手順がいる点は注意。

GitHub - agileware-jp/redmine_github

【2-7】@miokakusuさんのLTでは、MSのVisualStudioからTFSへチェックインする時に、Redmineチケットと同期させる仕組みを作った事例。
TFSの通知メールからRedmineとREST APIで連携する処理が面倒ですね、という話が興味を引いた。
仕掛けについては、@ryouma_nagareさんからアドバイスをもらったので理解できた。

akipiiさんのツイート: "#redmineT TFSの通知メールをRedmine がキャッチして、RESE APIで、チェックインとチケットを紐づけた。ごめん、この辺りがよく分からない。"

りょうま@redmine.tokyo終了でRedmineロスさんのツイート: "ですね。 メールサーバで受信したメールを標準出力でスクリプトが受け取る 本文解析して、チケット番号、内容、ステータスを生成 REST APIでRedmineサーバにアクセス です。メールサーバかRedmineに同居している必要もないです… "

【2-8】@naitohさんのアンケート集計では、Git利用率が下がっている点が気になった。
たぶん、Git中心で開発する場合、GitHubやGitlabだけの運用に流れているのかもしれない。
つまり、RedmineとGit連携の機能が弱い点は、今後、Redmineの弱点になってくるかもしれない。

【3】@ohnukiさんから、コミュニティ運営を褒められたことは一スタッフとして嬉しかった。

Hiroshi Ohnukiさんのツイート: "久しぶりの参加、第一印象ですが運営が素晴らしい #redmineT"

【4】Redmineコミュニティに関わって8年経つが、なぜRedmineコミュニティを継続できたのか、とふと疑問に思う。
僕はコミュニティ経験がまだ浅いけれども、過去を振り返ると、コミュニティの浮き沈みはとても激しいと感じる。
長期に渡って熱気を維持できるコミュニティは正直多くない。

その理由は、Redmineというツールが、日本における市場の潜在ニーズをうまく汲み取ってきたから、ではないかと考えた。
つまり、日本の官公庁や大企業における非効率な業務にRedmineが当てはまるケースが多いのだろう、と考える。

たとえば「プラットフォーム革命」にはこんな一節がある。
プラットフォームビジネスの機会を見つけるには、「取引コストが高い所」「複雑で見過ごされているネットワーク」「大規模で分断された未活用な資源がある所」に注目せよ、と。

この言葉を念頭に置いて、以前、CoderDojoの関係者と話していたら、まさに日本の教育業界はとても非効率な業界なので、ベンチャー企業が参入しやすいという印象を受けた。
実際、日本の学校ではIT化が進んでおらず、プログラミング教育や英語教育などの外部環境の大きな変化に揺さぶられていて、教育者だけで自力解決できず、袋小路になっている印象だ。
そんな非効率な業界だからこそ、CoderDojoなどのITコミュニティやITベンチャー企業はちょっとした改善ツールを導入するだけでも、すごく通用する。
そういう話を聞きながら、CoderDojoは本当に良いマーケットを持っているなあ、今後しばらくはその業界でビジネスをやっていけるだろう、という印象を持った。

同様に、日本の官公庁や大企業は、メールやExcel帳票の文化で凝り固まっている現場が多いので、昨今の最先端のIT企業から見れば、非効率極まりない利用シーンが非常に多く見受けられるだろう。
だからこそ、そういう業務にRedmineを単純に導入するだけでも、それなりの改善効果を得やすい状況があるのだろう、と思う。
よって、そういう非効率な市場が残っている限り、まだ今後しばらくは、Redmineは日本で根付いていくだろうと思っている。

| | コメント (0)

2019/04/07

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク

「プログラミングのできる羊とできない山羊を区別する方法」の記事をリンクしておく。
プログラミングの向き不向きに関する興味深い記事。

【参考】
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog

(引用開始)
実に多くの人がリンクしているこの論文(PDF)では、プログラムやプログラミング言語に触ったことがない学生達を対象に、「プログラミングのできる羊とできない山羊を区別する方法」を提案している。
おしなべてプログラミングの教師はプログラミングができる学生とできない学生の二つの山ができることに気付いている。それぞれの山は独立な正規分布を成している。プログラミング教育に関する研究のほとんどすべてが教授法についてのものである。すなわち、言語を変え、応用分野を変え、IDEの利用法や仕事へのモチベーションの維持について教えるわけだ。しかしそれらの試みはなかなか上手くいかず、二つの山は依然として残り続けている。
(中略)

この論文の著者は計算機科学における最初のハードルは以下のようなものになると仮定している。
代入と系列
再帰 / 繰り返し
同時並列性

上から順にハードルは高くなっていく。従ってテストは新米プログラマに対する最初のハードルである代入から始めていく。このテストの結果は3つのグループに綺麗に分かれる。
学生の44%は代入がどのように働くかについて一貫したモデルを持つに至る(たとえ正しくなくとも)
39%の学生は代入のモデルとして一貫したものを形成できない。
8%の学生はふてくされて回答を空白のままにする。

このテストは2回実施された。最初の一回目を何の説明もなしに行い、3週間後にもう一度行った。印象的なことは、一回目と二回目では実質的にグループの変化がほとんど無かったことである。つまり、一回目のテストであなたが心の中に一貫したモデルを得られるかどうかが最初のハードルになっている。
著者はプログラミングができることと一貫したモデルを心に持てるかどうかの間には極めて高い相関があることに気付いた。
(引用終了)

つまり、プログラミング教育の講座では、プログラミングにすぐに慣れる人と、プログラミングがずっと分からない人から成る正規分布の2つの山に分かれる現象らしい。
確かにそうかもしれない。

個人的に興味があるのは、小学生からプログラミング教育が義務化された状況において、プログラミングを知らない子供がどうやってプログラミングのスキルを習得していくのか、を観察してみることだ。
子供が母国語を自然に覚えるように、プログラミング言語を自然に習得できるのか?

それとも、40代を過ぎたおじさんがTOIEC対策のために英語習得に非常に苦労している風景と同じく、プログラミング初心者も、通常の論理体系とは異なるプログラミング言語を習得することに、非常に苦労するものなのか?

上記の記事を理解した後で振り返ると、数学の公理体系と同じく、それ自体は無意味な論理規則の集合体であるプログラミング言語をどうやって操れるようになるのか、その習得過程に興味がある。
それが分かれば、ソフトウェア開発の難しさという本質に触れられるような気がするから。

| | コメント (1)

2019/03/10

第19回Redmine大阪の感想 #redmineosaka

昨日の第19回Redmine大阪が無事に終了した。
スタッフの皆さん、参加者、そしてJiraやBacklogのパネラーの方、ありがとうございました。
感想をラフなメモ書き。
Mroongaはまだ分かっていないので、間違っていたら後で直す。

【参考】
第19回 Redmine大阪 - connpass

第19回 Redmine大阪(2019/3/9) #redmineosaka - Togetter

第19回Redmine大阪の見所 #redmineosaka: プログラマの思索

redmineエバンジェリストの会 メンバー4人がRedmine大阪へ

続・姫路IT系勉強会で

Node.js meets Redmine (第19回 Redmine大阪 LT発表内容)|足羽川永都(あすわがわえいと)|note

【1】今回の勉強会では、参加者層が多様だったので、大変盛り上がったように思う。
大阪圏の参加者だけでなく、東京・名古屋・福井・京都・神戸・姫路・松江・福岡などの遠方から多数の参加者があった。
また、Jiraのエバンジェリストの方も来て頂いて、チケット管理ツールに関する有用な議論もできた。

直前のキャンセルがあったにも関わらず、補欠の参加者が全員参加されて、参加率100%超になったのはすごいな、と思う。
それだけRedmineのニーズが広がっているのかな?

【2】@akahane92さんの講演では、特に全文検索プラグインの仕様と性能評価が興味を惹いた。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

clear-code/redmine_full_text_search: Full text search for Redmine

@akahane92さんの会社では、クリアコードさんと共同開発して、GitHubに公開されている全文検索プラグインに対し、RedmineのチケットやWikiなどの全文検索を更に強化した機能も含めて公開されている。
今後は、添付ファイルやSVNなどのリポジトリ情報も全文検索の対象としてプラグインの機能に含めていく、という。

【2-1】この講演内容を聞いて重要と考えた事は2つある。
一つは、メーカーという知的財産に非常にセンシティブな企業であっても、オープンソースの方が価値がある、という考え方に同意してくれていること。

もう一つは、Redmineに蓄積されたチケットやWikiだけでなく、添付ファイルや構成管理ツールのリポジトリ情報もテキスト情報として全文検索の対象に含めること。

Redmine本家では、添付ファイルの全文検索も機能追加するチケット(Planio提供 #306)があるが、@g_maedaさんや@akahane92さんに聞いた所、Redmineの検索機能が更に劣化する可能性があること、パッチの規模が大きすぎることから入らないのではないか、とのことだった。
しかし、全文検索プラグインでその機能が実現されるならば、問題はない。

Redmineチューニングの実際と限界 - Redmine performance tuning - Speaker Deck

つまり、全文検索プラグインによって、Redmineに蓄積されたチケット・Wiki・添付ファイル・リポジトリは全て検索対象となり、Redmineを真のナレッジ基盤として実現できるわけだ。

(引用開始)
Redmineのファイル内容 全文検索
添付ファイルの内容検索がパッチとして提供されている(Planio提供 #306)が、 大量の添付ファイルを検索対象とした場合、全文検索の性能は低いと予想される。
想定される課題は3点:

1)検索処理時間
実運用環境の35万ファイルを使用して、全文検索(非索引型)の応答性能を計測すると、10億文字分の検索処理が長時間かかってしまい、日常的に使うには性能が不足するだろう。将来のデータ増加を最大200億文字と想定すると、このままでは厳しい。
→ Full Text Searchプラグインによる、検索機能の拡張開発「添付ファイルの索引型高速全文検索」により改善できる(もうすぐ)
2)検索結果の精度
SQL検索では探している情報が大量のデータに埋もれてしまうため、見つけるまでに時間がかかってしまう。
→ Full Text Searchプラグインによる、 検索機能の拡張開発「高精度検索」により改善できる(予定)
3)リポジトリ内容の検索機能が無いため、ソースコード検索、ドキュメント検索ができず、効率が悪い。
→ Full Text Searchプラグインによる、検索機能の拡張開発「リポジトリ内容の索引型高速全文検索」により改善できる(予定)
(引用終了)

【2-2】@akahane92さんに聞いた所、Redmineの全文検索プラグインでは、プロジェクト単位に全文検索できる仕様が重要である、という点が興味を惹いた。

なぜなら、プロジェクトは新製品開発など、情報アクセスに厳しい制約があるため、Redmineユーザは所属しないプロジェクトにアクセスできない仕様が必要だからだ。
おそらく、ISOやISMSの制約上、重要な機密情報は限定されたユーザだけがアクセスできるような仕組みが必要なのだろう。
Redmine本体の検索機能には、既に検索時の絞り込み条件が設定されているので、問題ないわけだ。

【2-3】全文検索プラグインの実装仕様、特に機械学習によるAI検索について、@akahane92さん、@ryouma_nagareさんの説明を聞いて、ようやく概要を理解できた。

チケット登録時に、チケットの情報とともに、Mroongaが検索用インデックスを保持する。
Redmineで全文検索を行う時、その検索用インデックスを使うので検索時間はかからない。

また、Mroongaが保持する検索アルゴリズムは、定期的にメンテナンスする。
例えば、Redmineの外で、GPUを使った特別のサーバーを用意して、AIエンジンで別途、機械学習させて、その学習結果をMroongaに週1回または月1回のように定期的に取り込む。
したがって、Mroongaの検索アルゴリズムは定期的にアップデートして、Redmineの検索精度を高めるように運用すればよい。

僕はMroongaを機械学習エンジンと勘違いしていたが、そうではなく、全文検索用の語彙表テーブルとインデックスカラムを自動生成してくれるミドルウェアだと理解した。

他に、お話を聞くと、MroongaはRedmineのver3.4, 4.0にも対応済みらしい。
そしてOSS化されている事から、MroongaはRedmineの最新版に追随してくれることが期待できる。

【3】アジャイルウェアの堂端さんのGitHub連携プラグインのデモも興味深かった。

仕掛けとしては、RedmineでGitHubの接続情報を設定しておくと、Redmineサーバー上にGitHubのBareリポジトリが作られて、そのリポジトリをRedmineが参照すること。

agileware-jp/redmine_github

【4】JiraとBacklogパネラーを含めたパネルディスカッションも面白かった。

BacklogやJiraが向いていない利用シーンは、大規模なWF型開発の案件です、という発言を聞いて、Redmineのチケットやプロジェクトの階層無制限の機能がそこに有効に作用している、という点を改めて認識した。
つまり、日本の企業でRedmineが好まれているのは、従来のWF型開発にとてもフィットしているツールとして使われているからだろう。

【5】今回の勉強会を一スタッフかつ一参加者の立場で楽しんだ後、Redmineコミュニティは今後どのように進んでいくのだろうか、と思った。
懇親会でも、最近の東京Redmine勉強会は盛り上がっているが、Redmine大阪はどうなんですか、という質問もあった。

僕は、JiraとBacklogのパネルディスカッションを聞きながら、2011年当時のチケット管理ツール大決戦のイベントを思い出していた。
2011年のRedmine勉強会発足当時、大阪や東京のRedmineコミュニティではアジャイル開発者が率先して試行錯誤していた。
たとえば、以前は、@daipresentsさん、岡本さん、小久保さんなど数多くのアジャイル実践者は、Redmineでいかにアジャイル開発を運用するか、を試されていた。
その過程で、Scrumのプラグインを作られたり、Gitと連携するプラグインを作られていた。

しかし、その後、Redmineのユーザ層が変化したように思う。
実際、最近のRedmine勉強会のユーザは、PMOやSEPG、情報システム部門のユーザが多い。
また、Redmineを全社で展開しているので、Ruby開発者よりもインフラ関係のエンジニアが多いように思う。

つまり、Redmineのユーザ層は、アジャイル開発者ではなく、日本のソフトウェア開発や現場の業務に合うように実運用する立場の人達に変化した。
そんな流れを振り返ると、日本のユーザはRedmineが自分たちのニーズに向いていることに気づき、多種多様な現場に片っ端から適用してみることで、Redmineをより深く理解しようとしているのではないか、と思った。
今回の勉強会では、そんな気づきがあった。

| | コメント (0)

2019/01/26

第19回Redmine大阪の見所 #redmineosaka

第19回Redmine大阪の見所を書いておく。

【参考】
第19回 Redmine大阪 - connpass

(引用開始)
テーマ~「次世代プロジェクト管理システム Redmine の未来を考える」
約1年ぶりに、待望のRedmine のメジャーバージョン4.0がリリースされました。
今回の勉強会では、さらに機能改善されたRedmineの解説だけでなく、下記の内容を提供します。

最新バージョンのRedmineでのチューニング結果報告
国内で代表的なプロジェクト管理ツール Redmine・JIRA・Backlog の有識者を招いて、プロジェクト管理ツールについてディスカッション

Redmineの初心者から、Redmineをバリバリ使う経験者まで、興味のある方はぜひお越しください。
(引用終了)

1年ぶりの勉強会の見所は、次の3つがある。

【1】@akahane92さんの「Redmineチューニングの実際と限界 ~ 200万チケットでもサクサクなRedmineの作り方~ 改訂4版」

Redmineチューニングに関しては、世界トップクラスの@akahane92さんが最新バージョン4.0の性能評価、チューニング技術に関して報告して頂く。
特に興味深い点は、全文検索プラグインを使った性能評価だ。

Redmineの全文検索プラグインが、Redmineにとってとても重要な理由は、Redmineをナレッジシステムとして実現する為に重要な機能であるからだ。
その理由は下記に書いた。

Redmineの検索機能の改善はチケット管理システムにとって重要な要件だ: プログラマの思索

Redmineの全文検索プラグインには、Redmineに蓄積された過去のチケット、Wikiなどの情報を高速に検索できるだけでなく、GoogleのPageRankのように重要度の高い順にソートしたり、Amazonのお勧め商品のように類似チケットを表示する機能などがある。
この機能がRedmineに組み込まれれば、システム保守や顧客問合せなどのデータをRedmineに蓄積するほど、Redmineにその会社のナレッジが蓄積されていくので、Redmineは有用なナレッジシステムになる。
さらに、昨今の機械学習や人工知能のライブラリをアドオンで組み込むなどすれば、より的確な情報を提供するだけでなくアドバイスすることも可能になるだろう。

Redmineの全文検索を高速化するプラグインfull_text_searchのリンク: プログラマの思索

第17回Redmine大阪の感想 #redmineosaka: プログラマの思索

@akahane92さんの講演内容は今後、詳細が明らかになっていくと思うが、既にRedmineをIT全般統制(ITSMS)に適用して実運用されている背景を考えると、Redmineの全文検索プラグインがIT全般統制の内部監査で重要な役割を担っているのではないか、と推測される。

すると、ISO9001やITSMSのマネジメントシステムにRedmineをうまく当てはめる事が出来れば、Redmineの導入対象は、ソフトウェア企業だけでなく、製造業などの会社にも導入できることになり、Redmineの活用範囲が広がるだろう。
実際、既にITILとRedmineは相性が良いのは知られているので、ISO規格にあるマネジメントシステムとのフィットギャップ分析さえできればいい。
その辺りも色々聞いてみたい所。

SQIP2014の論文「「効率、品質、統制」の共通課題に着目した現場主導によるITS導入の効果検証」がすごい #redmine: プログラマの思索

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

日本の大企業におけるRedmineの利用事例の資料のリンク: プログラマの思索

そうなると、今後の課題は、Redmineの添付ファイルも全文検索プラグインの対象に入れて、Redmineを真のナレッジシステムにすることになるだろう。
なぜなら、RedmineのチケットやWikiだけでなく、チケットに添付されたExcelファイルまで全文検索の対象になれば、より重要な情報を的確にいつでも高速に抽出できるからだ。
そうすれば、Redmineにどんどん情報を蓄積していこう、というユーザの動機付けにも役立つだろう。

Ver4.1で、添付ファイルを全文検索する機能が提案されているので、今後の動向も要チェックだ。

Redmineの添付ファイルを全文検索するパッチの可能性~Redmineをナレッジシステムにするための要件とは何か?: プログラマの思索

【2】アジャイルウェア 堂端さんの「GitHub連携プラグイン」

Redmineの課題の一つには、Git連携がやりにくい、という点が10年前からあった。
現状の機能では、Bareリポジトリを手動で作ったり、Gitlabと連携できるように構築するなど、手間がかかる場合が多い。

今回の講演では、GitHub連携プラグインを提供されるということ。
このプラグインは、Redmineユーザにとってメリットが大きいと思う。

GitHub連携プラグインのメリットは2つある。
一つは、GitHubとRedmineと連携できることで、チケット管理はRedmine、プルリクやフォークなどのソース修正はGitHubという使い分けが簡単に実現できること。
以前から、RedmineとGitlabの連携は試みがされてきたが、GitHubでも使い分けが可能になる。

もう一つは、GitHubが無料のプライベートリポジトリを使用可能にしてくれたおかげで、個人のソース管理やドキュメント管理はGitHub、プライベートなタスク管理はRedmine、で置き換えられること。

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

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

マイクロソフトがGitHubを買収した後、GitHubが非常に使いやすくなったので、GitHub連携プラグインはとてもタイムリーな内容だと思う。

【3】「プロジェクト管理ツール Redmine・JIRA・Backlog によるうちの子の良い所、他の子の欲しい所」

現在調整中だが、Redmine、Jira、Backlogという著名なプロジェクト管理ツールのエバンジェリストをお呼びして、それぞれのツールの良い所を紹介してもらい、自由に議論してもらおう、という企画。
企画の隠れた目的には、そういう議論の内容をRedmineの機能改善に役立てたい、という気持ちも込められている。
個人的には、とても楽しみな内容。

なお、このパネルディスカッションの企画を手伝っている時に、過去の「チケット管理ツール大決戦」の企画を思い出していた。
2011年のデブサミで、チケット管理ツール大決戦という企画が非常に盛り上がって、その企画がユーザ投票で3位にランクインされたのを思い出す。

チケット管理システム大決戦第二弾 Trac vs Redmine vs JIRA vs Backlog を開催しました!勝者は? - I18n and L10n in My Life

デブサミ2011レポート~チケット管理システム大決戦: プログラマの思索

[#TiDD]チケット管理システム大決戦 JIRA vs Redmine vs Trac - デブサミ2011 その3 - #itsjp #devsumi: ソフトウェアさかば

2/17: デブサミ 2011 / チケット管理システム大決戦

チケット管理システム使用状況の調査結果(デブサミ) | Atlassian Blogs

【資料公開】チケット管理システム大決戦 第二弾 | Ryuzee.com

Excel大好きな日本企業の組織文化は、たぶんその頃から変わっていないように思う。
だから、それぞれの製品のメリットを強調するだけでなく、世の中の業務の問題解決にプロジェクト管理ツールが役立てればいいなあ、と思っている。

【4】既に満員御礼になっていますが、懇親会は人数を増やせるので、懇親会からの参加もOKです。

| | コメント (0)

2018/11/11

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

第15回東京Redmine勉強会が盛況で無事に終わりました。
スタッフ、参加者の皆さん、ありがとうございました。
また、コミッタの前田さん、数多くのプラグイン開発者・パッチ開発者の方にも感謝です。
以下は、講演を聞いて、感想をラフなメモ書き。

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

2018/11/11 第15回勉強会 - redmine.tokyo - Togetter

日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について: プログラマの思索

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

【1】参加者の方から、以前の勉強会では講演の数が少なくて、時間を持て余す時が多かったのに、今回の勉強会では講演の数が多すぎて盛りだくさんだった、という感想を聞いた。
確かに、大LT大会になったので、詰め込みすぎたかもしれない。

他方、それだけのコンテンツが集まる事実は、日本のRedmineコミュニティで数多くの事例やカスタマイズのノウハウが蓄積されていることを示しており、コミュニティとして成熟していることかな、と思った。

【2】今回の勉強会のテーマは「Redmineの次バージョン4.0に向けて、皆のノウハウを共有しよう」だったが、隠れたテーマは「日本のプラグイン開発者やコミッタ、パッチ貢献者にコミュニティから感謝の声をあげよう」だったと思う。
@g_maedaさん、@akiko_pusuさん、@tkusukawaさん、@haru_iidaさん、@two_packさん、@onozatyさん、@naitohさん、前田みのるさん他多数のプラグイン開発者に声が届けられて良かったように思う。

中村さんの講演では、現場のRedmineに15個もプラグインを入れていて、プラグイン開発者に拍手喝采を、という内容はまさにそうだった。
Discord上でRedmineコミュニティを運営しているMaxさんの講演も、Redmineのテーマ改善など機能拡張をコミュニティドリブンで開発しよう、という内容だった。

そして、僕のLTでは、Redmineコミュニティがマネージャ層とRuby開発者という二つの全く異質なターゲットから成り立っている特徴を強みとみなし、異質な特徴を持つ彼らが相互交流することで、Redmineの進化を加速させるエンジンになりうるはず、という主張を試みた。

実際、今日の参加者とグループディスカッションや懇親会で話を聞くと、マネージャ層の人達もいれば、プラグインやパッチ等の開発者も多く、多様な参加者から成り立っていた。
たぶん、こういう交差しないセグメントのターゲットが2つ以上もあるようなコミュニティは、非常に稀で、貴重な場ではないか、と思う。

普通のOSSコミュニティは、利用ユーザだけとか、実際の開発コミュニティとか、セグメントがどこかに特定されているような気がする。

【3】では、なぜ、Redmineコミュニティはそのような異質なセグメントのターゲットを2つ以上持つことができたのか?

理由は、Redmineには2つの顔があるからだ。
一つは、「ソフトウェア工学の理論を実験できるプロジェクト管理ツール」という側面で、マネージャ層に対応する。
もう一つは、「汎用的なプロジェクト管理の開発基盤」という側面で、こちらがプラグイン開発者やRuby開発者に相当する。
つまり、全く異なる出身を持つ二つの層が生まれたことで、Redmineの機能改善を相互に議論しあえる場が生まれたように思っている。

たとえば、マネージャ層は、自分達の管理作業を楽にしたいためにRedmineを使うが、Rubyの開発はおそらく殆どの人ができない。
一方、プラグイン開発者は、実際の現場のニーズを元にRedmineに不足した機能を実装し、プロセス改善に役立てる。

Ruby開発者は、マネージャを顧客に見立てて、Redmineに不足した機能を実現できる力を持つ。
一方、マネージャは、プラグインを利用することで、自分達の開発プロセスや組織文化に合わせてRedmineにカスタマイズを施し、彼らのあるべき姿にRedmineをFitさせる。
たぶん、新たなプラグインがマネージャ層の潜在ニーズを刺激し、新たな改善アイデアを生み出すだろう。

実際、今日のLTでもリソース予約プラグインを開発した話があり、タスク管理に使われるRedmineを会議予約システムとみなして使う、という事例もあった。
つまり、柔軟なRedmineのおかげで、マネージャや利用ユーザの潜在ニーズが刺激され、数多くのアイデアが生まれる、という良い意味でのらせん構造が生まれている。

【4】すると、今後のRedmineコミュニティの発展に必要な要素は2つあると思う。
一つは、Ruby開発者をRedmineコミュニティにもっと巻き込みたい、ということ。

なぜなら、他の競合のチケット管理ツールに対し、Redmineが競争優位性を保つには、もっとRedmineの進化の速度を上げたいからだ。
現状のRedmineには、いくつかの課題があると思う。

僕が感じている課題については、以前書いた。

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

また、Maxさんも同じく、Redmineの画面UIをもっと今風に改善したい、と思われている。

換言すれば、次の3つに課題が集約されるのではないか。

1・シングルページアプリケーション化などの画面UIの改善
2・プルリク実装などのGit連携の機能強化
3・プラグインのGem化、RedmineのVerUpの自動化などの、VerUp自動更新機能

おそらくそれらの課題の解決は、そう簡単なものではない。
だが、多くのRuby開発者をRedmineコミュニティに巻き込めば、実現のハードルは下がるだろう、と思う。

Redmineのマイクロコア化は可能か~Redmineを開発基盤にして追加機能は着脱可能コンポーネントにできるか: プログラマの思索

【5】もう一つは、Redmine運用に関する数多くの知見を一つの体系にまとめ上げて、誰もが再利用できるようなプラクティスや知識を提供すること。

なぜなら、大阪や東京のRedmine勉強会で参加者から要望されるニーズは、Redmineの運用事例が知りたい、という内容が多いからだ。

実際、Redmineが生まれて10年以上経った今、障害管理だけでなく、タスク管理、会議の管理、資産管理、ヘルプデスクなど数多くの事例がRedmineで実現されている。

たとえば、今日のグループディスカッションでは、ITILのプロセスをRedmineで完全に実装した事例を持つ参加者がいた。
具体的には、Zabbixで検知したエラーメールはRedmineにチケットで自動登録され、インシデントとして認識される。それらチケットを精査して、修正対応すべきと判断されたチケットは、問題管理へエスカレーションされ、対応策の検討後、リリース管理で開発・リリースされる、という流れ。
つまり、この参加者の方は、システム保守・運用の立場の人なのだろう。

この話は僕も以前経験していて、ITILとRedmineは非常に相性が良いと思っている。
しかし、インシデント管理・問題管理・リリース管理などの各プロセスをRedmineにどのようにFitさせるか、については、運用してみると理論通りにうまく行かない部分がある、というのも経験している。

TiDDにITILの概念を持ち込む: プログラマの思索

Redmine for ITIL: プログラマの思索

残業申請ワークフローやITIL運用プロセスをRedmineで実現した事例の記事: プログラマの思索

エスカレーションをRedmineで運用する方法: プログラマの思索

そういうアンチパターンやプラクティスなどのノウハウを、利用シーンごとにまとめて、体系化してみたい。
おそらく、そういう知見を集めて体系化して、その知識を普及させる役割が、Redmineエバンジェリストであり、Redmine警察に相当する人達だろうと思う。

【6】今日の勉強会の中で、ツイートしながら生み出せた考え方は、「Redmine運用の4原則」のようなものがあるのではないか、ということ。
Redmine運用の4原則とは、Redmineがチームに馴染むには、プロセス・ツール・スキル・マインドの4つの要素がいるのではないか、ということ。

この考え方の発端は、Jiraのような多機能なチケット管理ツールの場合、プロセスを実装した経験がない管理者がJiraを使って運用させようとすると、失敗しやすいのでは、という話から生まれた。

ツールを使いこなすには、プロセスを知っておくことが大前提。
そして、ツールを使いこなしたり、プロセスをテーラリングできるスキルも重要。
また、プロセスやツールを受け入れるマインドもいるね、と話が広がった。

しかし、本当にこの4つで十分なのか、MECEに整合性が取れているのか、この4原則でアンチパターンの事象を演繹的に説明できるか、については検証が必要、と思っている。
でも、この4原則を検証してみるのは価値がある、と思う。

【7】最近の僕が個人的に持っているRedmineのテーマは「組織とRedmineは相互にどんな影響を与えているか」だ。

具体的には、組織構造がRedmineにどんな影響を与えて、Redmineをどんな方向に複雑化させるのか。
一方、Redmineを導入し運用することで、組織文化にどんな影響を与えて、組織にどんなメリットを与えてくれるのか。

例えば、縦割りのガチガチの組織構造は、単一の標準Redmineのワークフロー設定、トラッカー設定を複雑化させる。
その複雑化に現場が対応できなくなると、各事業部や各チームごとにRedmineインスタンスが乱立し、野良Redmineが生まれ、IT統制が効かない状態になりうる。
つまり、組織のやり方にRedmineをカスタマイズしてフィットさせて、プロセスをテーラリングしたいが、実際は理論通りにテーラリングはうまくいかない場合が多い。

一方、縦割りの組織にRedmineを導入すると、Redmineの機能に埋め込まれたベストプラクティスをメンバーが自然に受け入れることで、チームの作業が効率化されることもあるだろう。
また、Redmineがメンバー間のコミュニケーションを活発化させ、より良いプロセス改善がもっとできるのでは、というメンバーの貢献意欲を引き出す場面もあるだろう。
つまり、Redmineはチームの文化を変容させる力を持っている。

そんな経験を踏まえて、「Redmineは組織構造に従う」「Redmineは新たな組織文化を生み出す」という二つの双方向な事象を整理したいと思っている。
実際、Redmineを利用しているマネージャは大企業の方が多いので、組織構造や組織文化とRedmineのバランスを見出すことに苦労しているのではないか、と思うからだ。

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

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

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

Redmineに向いている組織はPJ型組織やマトリクス型組織ではないかという仮説: プログラマの思索

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

グループディスカッションでも、懇親会でも、参加者が持つRedmine運用の問題意識にはこれらが関係しているような気がした。

以前「Redmineによるタスクマネジメント実践技法」で当時の自分が考えていたアイデアは全て書いたけれど、上記のテーマでまた新たに書いてきたくなるなあ、と思った。




| | コメント (0)

2018/11/09

第15回redmine.tokyo勉強会のLT資料の事前公開~今後のRedmineコミュニティの方向性について

第15回redmine.tokyo勉強会のLT資料を事前公開しておく。

【参考】
日本のRedmineコミュニティの活動報告と今後の抱負: プログラマの思索

第15回redmine.tokyo勉強会の見所: プログラマの思索

第15回勉強会 - redmine.tokyo

【1】Redmineには2つの顔がある。

一つは、ソフトウェア工学の理論を実験できるメトリクス収集集計基盤/開発プロセスの運用基盤である顔。
Agile開発もWF型開発も運用可能であり、ワークフロー設定できるならば、全ての開発プロセスをRedmineで一元管理できる。
そこから、Redmineは開発プロセスの運用基盤になり、ソフトウェア工学やプロジェクト管理に関するメトリクス収集・集計基盤になりうる。
つまり、定量的なプロジェクト管理の手段をRedmineによってようやく手に入れられることになる。

もう一つは、汎用的なプロジェクト管理ツールの開発基盤である顔。
RubyとRailsの基盤のおかげで、機能のカスタマイズがやりやすい。
REST APIやrakeなどの外部接続I/Fもあるので、システム連携もやりやすい。

そのおかげで、Redmineに不足する機能をプラグインで実現できるので、プラグイン開発者が多い。
特に日本では、ガチガチの縦割りの組織や自社の開発プロセスに合うように、Redmineをカスタマイズしやすいので、ニーズが多い。

また、Redmineが柔軟な開発基盤を持つおかげで、Redmineコミュニティ自体が活発化している事象もある。
柔軟なソフトウェア設計は、OSSコミュニティを活発化させるメリットがある。
他方、OSSコミュニティの活発化は、ソフトウェアをさらに進化させる、という双方向のメリットがある。
その考察は以下に書いた。

柔軟なソフトウェア設計はOSSコミュニティを活発化させる~OSSソフトウェアとOSSコミュニティの密接な関係: プログラマの思索

【2】言いたいことは2つ。

Redmineコミュニティの参加者の多様化を図ること。
もう一つは、Redmineのエコシステムを作ること。

Redmineコミュニティの参加者層は2種類あると思う。
一つは、プロジェクトマネージャなどのマネージャ層。
もう一つは、プラグイン開発者などのRuby開発者層。

つまり、プロジェクトマネージャかつRuby開発者である層は非常に少ないだろうから、コミュニティで相互の交流を図ることで、斬新なアイデアが出てきて、Redmineを更に進化させる余地がたくさんあるだろう。

マネージャのニーズはRuby開発者にとって、新たなプログラミング体験のチャンス。
Ruby開発者が提供するRedmineの新機能やプラグインは、マネージャのニーズをさらに刺激して、より良いものへ発展させるだろう。

その場合、Redmineベンダーも実はコミュニティのステークホルダーの一人なのだ。
彼らも有償ツールではあるが、Redmineのマーケット拡大に寄与している部分がある。
最終的には、彼らも含めて、Redmineコミュニティが熱気を維持し続ける方向へ持っていきたい。

そういう活発な議論を提供する場をコミュニティで実現したいと思う。

| | コメント (0)

2018/09/09

第2回astah関西の感想 #astahkansai

昨日の第2回astah関西の感想をラフなメモ書き。

【参考】
第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

7/7土の第2回astah関西の見所 #astahkansai: プログラマの思索

第2回astah関西勉強会(2018/9/8)のスライドが公開されました | astah in 5 min

【1】7月の西日本豪雨で1度流れ、4日前の台風の影響で参加者は減りましたが、参加者の熱気もあって盛り上がり、雰囲気はとても良かったように思います。
講演の内容もビジネスモデリングから組込み系、astahのより良い使い方など盛りだくさんで、飽きない感じでした。

講演中のアンケートでは、astahの利用または経験者が多数いた事、組込みエンジニアまたは組み込み系コンサルタントの方が半数以上いた点が興味深かったです。
僕自身は、業務系Webシステム開発をベースとしたビジネスモデリング系だったので、グループディスカッションでは、全く違う層の人たちと、最近の電気自動車や組み込み機器のセンサー化、機械学習の動向などの話が聞けて面白かったですね。

以下、講演内容について感じたことをメモしておく。

【2】兒玉さんの講演では、astahに描いたアクティビティ図から、astahAPIで情報抽出するデモを見せてくれた。

考え方としては、レガシーなCプログラムから手作業でastahのアクティビティ図へリバースしてモデリングする。
その時、アクティビティ図の吹き出しに、該当ソースの行番号も書いておく。
その後、astahAPIを用いて、JavaScriptでアクティビティ図の吹き出しにあるソース行番号の情報を抽出し、Excel設計書に貼られたCプログラムと照合して、合致した行番号に色塗りする、という仕組み。

つまり、astahのモデルとCプログラムの照合作業をastahAPIを使って自動化する、という作業を実現されている。
もちろん、astahのモデルは手作業で描くし、ソース行数も手作業でモデルに埋め込む必要はあるが、モデルを作っておけば、後はastahAPIでいくらでも情報を抽出できるので、照合やカバレッジなどの作業を自動化できる点は面白い。

astahを起動せずにJavaScriptで情報を取得する方法: プログラマの思索

また、astahAPIは、公開されているJavaDocだけでなく、astahからXML出力されたXMLファイルのXPATHを参考にすると良い、という話もあった。
つまり、XPATHからJavaDocにあるメソッドを連想しやすくなる、ということで、これは面白いなと思った。

astah* API

astah* API概要

astahAPIを使いたいと思っていても、大量のJavaDocから見当を付けるのが面倒でいつも何とかならないかな、と思っていたので、この発想は使ってみたいと思った。

【2】高井さんの講演では、組込みシステムのソースのリバースエンジニアリング作業は、プログラマだけでなく、熱力学など自然科学の専門家、自動車や家電機器などの業務の専門家も関係していて、彼らドメインの専門家のリバースエンジニアリングの観点は異なるので、SySMLという共通言語によって有益な情報を組合せることができる、という主張が面白かった。

確かに、プログラマはCやC++は強いだろうが、熱や振動などの自然力学の法則に詳しいわけではないから、アルゴリズムの本来の意味まで分からない。
自然科学の知識を持つ専門家であれば、このアルゴリズムが表す制約条件は、鉄板の強度や耐熱や振動の範囲を示す、などの知見を言い当てることができる。
そうすれば、自動車や家電製品の設計エンジニアは、材料の強度や耐熱、振動などの制約条件を元に、製品の形状や大きさはこういう範囲で設計しなければならない、等の知見が得られる。

すなわち、リバースエンジニアリングした内容は、プログラム層、自然科学のドメイン層、業務ドメイン層等で解釈が異なるわけだ。
そんな事を理解すると、ソフトウェアを組み込んだハードの設計や開発を真に理解するには、プログラミングだけでなく、自然科学の知識や製品の知識まで知る必要があり、膨大な範囲になる。
だから、組み込み機器の設計開発は、どんどん難しくなっているのだろう、と推測した。

もう一つ面白いと思った話は、SysMLはソフトウェア技術者の地位を高めた、という話。
つまり、今まではハードの部品ができた後で、ソフトウェア開発を行うので、ソフトウェア開発者は限定された仕様の中でプログラミングせざるを得ず、主導権を取ることができなかった。
しかし、ハードの部品が開発される前に、SysMLを用いて、製品の論理構造をモデル化できるようになり、ハード技術者へソフトウェア開発に必要な仕様や制約条件を事前に伝えられるようになった、と。

確かに、ハードの部品や製品は、材料の購買・発注・組み立てなど数多くのコストがかかるので、そう簡単に作り直しはできない。
一方、ソフトウェアはいくらでも変更できるので、無理な要望を受けてしまいがち。
しかし、ハードを発注する前の設計段階で、ソフトウェア開発では、これだけのメモリや性能は必要です、という情報を事前にハード設計者に伝達できれば、ソフトウェア開発もやりやすくなる。
SysMLはそういう波及効果があった、という話が面白かった。

【3】細合さんのSTAMPの講演後、僕は、そういう機能安全設計のモデリング技法は、一般事象のリスク識別に適用できるのではないか、と質問してみた。

僕の理解では、自動車の機能安全設計のモデリング技法STAMPでは、対象のハード製品の利用シーンをユースケースとみなして、そこからハザード分析し、人命に関わるリスクを識別し、そのリスクを潰す為の安全設計の仕様を導き出す。
そうならば、PMBOKのリスク管理に出てくるリスク識別において、ある事象のリスクを、何らかの対象の相互作業(I/F)をユースケース(利用シーン)とみなすことで、STAMPの技法を適用できるのではないか、と連想したからだ。

しかし、後で、宿口さんから、STAMPとリスク管理は観点が違いますよ、と教わった。
宿口さんの話を理解した限り、PMBOKに出てくるリスク管理は発散系の技法に近いが、STAMPは収束系の技法である。
仕様が固まっている製品に対し、製品の利用シーンを想定して、それを元にハザード分析していく手法なので、根本から手法が異なる、と。
話を聞いた限り、STAMPの技法は、ロジカルに説明できるような資料作りに役立てる技法の一つ、という印象を受けた。
僕はPMBOKもSTAMPも詳しくないので、この辺りはまた考えてみる。

【4】稲田さんの匠メソッドによるビジネスモデリングでは、経験に基づいた試行錯誤の話が興味深かった。

彼の講演の中で、ビジョンから業務要求・IT要求・仕様へ至るまでモデリングしていく中で、モデルを書いていると、ダブリやつじつまが合わなくなる時がある。
特に、数多くのステークホルダーにヒヤリングしてその内容を収集すると、そういう傾向が出やすい。
だから、その内容を早めにフィードバックして、何を最優先すべきなのか、何を妥協すべきなのか、を決めていく、と。

【5】僕の講演では、astahのRedmineプラグインの紹介。

AstahのRedmine連携プラグインが公開されました: プログラマの思索

言いたかったことは、単にプラグインの紹介だけでなく、その背景にあるモデリングツールが今後発展するために必要な機能追加の要件だ。
それは、モデルのグルーピング機能とモデル間の相互リンク機能を追加することだ。
それらは、モデルの粒度やモデルのトレーサビリティという、モデリング作業の問題解決に直結すると考えている。

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

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

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

高井さんと話していて、モデルを沢山書いていくと、astahでもモデルのタブを切り替えるのが面倒になってくる、という話があった。
モデルが3個ぐらいなら問題ないが、10個、50個と書いていくと、モデルを探す作業に相当の時間が取られるから、とのこと。
つまり、モデルの関連や情報を検索するのに時間がかかっているのだ。

その問題の真因には、モデルの粒度とモデルのトレーサビリティがあると思う。
大規模なシステムになるほど、概念モデル、論理モデル、物理モデルなどモデルにも数多くのレイヤが発生し、区別せざるを得ない。
すると、それらモデルの粒度を合わせるために、グルーピングしたくなる。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

また、一つのシステムを静的な観点、動的な観点、状態遷移図、利用シーンなど数多くの観点で分析したモデルを作ったとする。
それらモデルは、一つのシステムの射影にすぎないので、相互にリンクさせることで、追跡できるようにしたい。
そうすること、重複や考慮漏れに気づくことができ、モデルの精度を上げることができるはず。
しかし、そういう機能がUMLの仕様そのものにないし、astahにもない。

つまり、astahを含めた既存のモデリングツールは、大規模なシステムの分析にはたぶん力不足。
もっと大規模で複雑なシステムを、数多くの観点で数多くのモデルで分析した時に、それらモデル間の整合性をとるために、モデルの粒度とモデルのトレーサビリティという考え方が必要になってくると思う。

一方、アプリ開発者の観点では、モデルのグルーピング機能は所詮、フォルダ分けという機能にすぎない。
また、モデルの相互リンク機能は、モデル間の相互のハイパーリンクという機能にすぎない。
つまり、モデルの粒度とモデルのトレーサビリティという問題解決に必要なモデリングツールの機能改善は、さほど難しいわけではない。

しかし、そういうちょっとしたUIの機能改善が、モデリングツールを洗練させるし、モデリング作業そのものを効率化させていくものと思っている。

モデリング技術の習得とモデリングツールの習得は表裏一体: プログラマの思索

【6】本勉強会のスコープは、「製品astah」「astahで描けるモデリング技法全般」というかなりマニアックな内容だったので、今後の勉強会の継続を懸念していた。
いくら僕が勉強会をやりたい、と思っても、そもそも人が集まるのだろうか、という不安があった。

しかし、参加者から好意的な感想も多く、また、本勉強会を以前からウォッチしていた、という方もいて、勉強会のニーズはある、と感じ取った。

いつまで続けられるか分からないけど、緩く長く続けられればいいな、と思う。


| | コメント (0)

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回勉強会に既に多数の参加申し込みもあり、とてもワクワクしている。

【追記】
大雨のため、9/8土曜に順延となりました。

Mix Leap Study 特別編 -「開発現場のモデリング事例紹介」(astah勉強会) - connpass

第2回astah関西勉強会「開発現場のモデリング事例紹介」 - connpass

| | コメント (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のトピックブランチとRedmineチケットは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)

より以前の記事一覧