コミュニティ

2020/05/23

第18回東京Redmine勉強会~オンライン勉強会の可能性 #redmineT

第18回東京Redmine勉強会を始めてオンラインで実施できました。
参加者、講演者、スタッフの皆様、ありがとうございました。

【参考】

第18回勉強会 - redmine.tokyo

第18回東京Redmine勉強会『Redmineによるテレワーク運用』(2020/5/23) - Togetter

第18回redmine.tokyoでテレワークの工夫と真髄を知る【リモート開催】 #redmineT | マドびっ! Madosan's View

redmine.tokyo 参戦|makoto0119|note

第18回redmine.tokyo勉強会 - ryouma-nagareのブログ

デッドナイト東京、ではなくredmine.tokyo onlineに参加|みけねこ|note

【1】約3時間の長丁場のオンライン勉強会にも関わらず、最大風速でZoom75人、YoutubeLive100人超えで大盛況でした。
まだ事後アンケートを見ていないが、それだけテレワーク中にRedmineを利用していたり、興味を持つ人が多かったのかな?
ツイートも多くて、読み返すのが楽しい。

【2】講演で気になった感想をメモしておく。

【2-1】前田さんの講演では、RedmineのVer4.2の新機能が紹介されていた。

ユーザグループでウォッチャーに登録できる機能。
ユーザグループを大量に作っている時は欲しくなる。
Feature #4511: Allow adding user groups as watchers for issues - Redmine

ユーザーアカウントのメールアドレスのドメインの制限。
Redmineにある守秘義務のあるデータを個人スマホに転送できなくする為に必要。
ISMSでも必要。
Feature #3369: Allowed/Disallowed email domains settings to restrict users' email addresses - Redmine

優先度が高いチケットの更新を通知するオプション。
Patch #32628: Notify users about high issues (only) - Redmine

akipiiさんはTwitterを使っています 「#redmineT 優先度が高いチケットのみ通知メール対象にする設定の機能追加。通知メールの量を抑えながら、重要な情報のみ検知できる運用が可能。」 / Twitter

プロジェクト一覧のデフォルトの表示形式設定。
Feature #32818: Add a system settings for default results display format of project query - Redmine

akipiiさんはTwitterを使っています 「#redmineT プロジェクト一覧を常にリスト形式で表示できるが、初期表示をカスタムクエリで設定した情報で保存できる機能追加。PMOや経営層のようにPJ横断で見たい人には必要ですね。」 / Twitter

チケット表示画面に「完了」「未完了」のバッジを表示。
完了チケットなのに、コメントする人がいるので、それを気づかせてくれる。
Feature #33254: Show open/closed badge on issue page - Redmine

Wikiツールバーのテーブル挿入ボタン。
Feature #1575: Toolbar button to insert a table - Redmine

Wikiツールバーのコードハイライトボタンのカスタマイズ。

akipiiさんはTwitterを使っています 「#redmineT Wikiで表を簡単に挿入できる。Wikiのコードハイライトでよく使う言語を個人で指定して保存できる。この辺りは、Wikiを使って情報共有したい人には、手が届く痒い機能ですね」 / Twitter

チケットがクローズできない場合の理由を表示。
Feature #31589: Show warning and the reason when the issue cannot be closed because of open subtasks or blocking open issue(s) - Redmine

akipiiさんはTwitterを使っています 「#redmineT チケットがCloseできない理由を警告メッセージで表示してくれる。例のように、親子チケットのCloseができない場合が多く、問合せも多くて面倒でした」 / Twitter

【2-2】門屋さんから、Redmine活動家のお話。
PMOならではの苦労が想像できる。

Redmine警察、Redmine職人、Redmine活動家のような役割は、Redmineの運用をスムーズにさせるには必要な機能と思う。
彼らはRedmineの潤滑油。

ししゃもさんはTwitterを使っています 「Redmine ー警察 ルールが守られているか ーマイスター 職人 使い方の理想を追いつつメンバーを教育 ー活動家 あるべき姿に到達させる人 ー神 まえだ?さん #redmineT」 / Twitter

活動タブをよく見てます、という意見。
プロジェクトの活発度合い、チームの雰囲気を知るのに役立つ。

もりのあささんはTwitterを使っています 「チケット管理は”活動”はかなり重要よね。 よく見る。 #redmineT」 / Twitter

Redmine利用レベルはCMMIを参考にしている、と聞いて、上手く考えているな、と思った。

ししゃもさんはTwitterを使っています 「活動家 レベル1-自主調整 レベル2-相互調整 レベル3-是正提案 レベル4-介入 #redmineT」 / Twitter

あさこさんはTwitterを使っています 「redmine利用のレベル1-5は、CMMIレベル1-5を参照してますよ~ #redmineT」 / Twitter

JiraではチケットよりもConfluenceをよく使う、という意見もあった。
情報を蓄積する機能はWikiの方が良い、ということなのだろう。
以前、Jiraでは、設計書などの仕様は全てWikiで実現すべきという発想であると聞いたので、Confluenceを多用する気持ちは分かる。

もりのあささんはTwitterを使っています 「うちの会社(JIRA)だと詳細がチケットに書かれずにコンフルに書かれてることが多いんだよな。 チケットに書いた方がいいんじゃないかなとは思うんだけど。 (JIRAのアクティビティじゃなくてコンフルの週報とか日報の更新メールを監視してる) #redmineT」 / Twitter

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「門屋さんのお話、RedmineのところをBacklogやJIRAに置き換えても全く違和感ない。それだけ普遍的なお話だということ。 #redmineT」 / Twitter

【2-3】yukiaさんのBacklogとRedmineの比較も興味深かった。

タマコナ??Backlog最近の更新家さんはTwitterを使っています 「Backlogはすぐに利用できる。 (=カップ麺) Redmineは食材を料理してから利用する(=スーパーマーケット) #redmineT」 / Twitter

あさこさんはTwitterを使っています 「「なんで使いにくいと思うのか?」の違和感の追求をすると、本来やりたいところにフィットするツールが選択できるのよねぇ。 機能だけ知っていても、無駄無駄無駄無駄無駄無駄無駄...ッ! #redmineT」 / Twitter

akipiiさんはTwitterを使っています 「#redmineT Redmineにもユーザが既読したのか表示する機能は欲しいな。スマホのMessenger等では今は当たり前だから。」 / Twitter

@saitoさんの「Redmine+Teams=TeleWork」の話も興味深かった。
チケット管理ツールとチャットツールをどのように使い分けるべきなのか、どの利用シーンで使うべきか、という議論が聞きたかったから。

もりもりさんはTwitterを使っています 「初動 Teams ・チャットの嵐 ・ファイル、メモの嵐 ・Web会議 →キーマンへチケット化指示(Redmine) #redmineT」 / Twitter

ししゃもさんはTwitterを使っています 「Teams…第一報はココ。大体の嵐が去った後に作戦が立つ。収拾がつかなかったらweb会議へゴー。この会議がなかなか優秀 Redmine…キーマンが宣言してチケット起票 #redmineT」 / Twitter

Ryo MiuraさんはTwitterを使っています 「「共存」「使い分け」はもっともだと思う。シンプルなツールほど使いやすい。昔は、いろんな機能が入ったソフトが流行っていたけど、いまは、スマホのように「シンプルな機能を自分の画面で並べて使っていく」。こんな時代。PCでも、同じかと。#redmineT」 / Twitter

カエ太さんはTwitterを使っています 「ほっとくと皆チャットに籠もってしまうので、いかにチーム/チャネルに誘導するかがポイント>Teams #redmineT」 / Twitter

【2-4】@naitoh さんによるアンケート集計結果で興味深い点がいくつかあった。
Ver4.xが半数以上なので、ほとんどの人達は最新機能の恩恵を受けている。
よって、RedmineのVerUPに追随できるだけのインフラや環境構築の知識がある人達が多いのだろうと推測する。

また、チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。
懇親会で聞いた話では、TeamsはMicrosoftがすごく力を入れているので、どんどん使いやすくなってますよ、と。
僕はTeamsの経験がないので、どのチャットツールがどんな特徴があるのか、この辺りのツール比較は興味がある。

akipiiさんはTwitterを使っています 「@naitoh さんによるアンケート集計結果。興味深い点は、Ver4.xが半数以上。チャットツールはSlackとTeamsとZoomが半数以上を占めること。GoogleMeetは少なかった。 https://t.co/WbOoFpsXMf 18 questionnaire #redmine https://t.co/5xNYCDW6wQ」 / Twitter

【3】オンライン勉強会の裏方を担当して、こんなやり方もあるのか、という経験ができて良かった。

講演を普通にZoomで配信するのは当たり前。
課題は、オンライン勉強会では参加者の反応が見えず、シーンとなりやすいので、参加者のフィードバックを集めていかに場を盛り上げるか、という点にあると考えていた。
今回は、Twitterで感想や質問を流してもらい、裏で集めてフィードバックする方法を取ってみた。

講演者の立場では、すぐに感想がもらえるのでとてもありがたい。
スタッフとしても、勉強会の評価に直結するので気になる。

今回は流れる量が非常に多く、その内容を質疑応答タイムで使ったら、講演者とスタッフの間で盛り上がってしまって、ちょっと長引いてしまったくらい、良かった。
この辺りの、勉強会の場を盛り上げる方法はいくつかあると思うので集めてみたいと思う。

たぶん、アジャイル開発のコミュニティであれば、全員がリーダーでありファシリテーターでもあるだろうから、こういう段取りをしなくても上手くいくのかも知れない。

| | コメント (0)

2020/05/18

Redmineヘッドラインで今の話題をチェックする

@g_maedaさんが、Redmineヘッドラインを公開されていたのでメモ。

【参考】
Redmineヘッドライン ? プロジェクト管理ツールRedmineの今の話題をまとめて紹介

MAEDA GoさんはTwitterを使っています 「Redmineヘッドライン https://t.co/xRfgvzB3pZ に先週 (2020/05/10-16) は計6件のリンクを追加しました。 - redmine-issue-loader 2.3.0リリース - Issue Templates 1.0.2リリース - Full Text Search plugin と ChupaTextで添付ファイル内全文検索 ほか」 / Twitter

MAEDA GoさんはTwitterを使っています 「@akipii Redmine関係の記事やソフトウェアの情報は、見つけたものはどんどん載せます。Redmineのコミュニティの盛り上がりに少しでもつなげられるといいなと思っています。」 / Twitter

MAEDA GoさんはTwitterを使っています 「@juno_nishizaki ありがとうございます! いろんな方がせっかく公開してくださった記事やプラグインの情報がRedmineに関心がある方に届きやすくして、コミュニティに少しでも貢献できればいいなと思っています。」 / Twitter

Redmine本体だけでなく、Redmineに関するプラグインやTips、ブログなどがリンクされているので、とても参考になる。
最近の流行はすごく速いので、こういうサイトで時々チェックできれば、最新動向も把握できる。

直近の話題は下記ですね。

「こどもれっどまいん」というテーマを作っています。 - Qiita

Docker Compose で作った Redmine だって Full Text Search plugin と ChupaText サーバーを連携させたい - Qiita

doc2vecでredmineのチケット(csv)を学習させてみる - Qiita

redmine-issue-loader のバージョン2.3.0をリリースしました - Enjoy*Study

Redmine draw.io plugin がすごい便利そうなので紹介したい - Qiita

他に、まどさんや僕のブログもリンクされてましたね。

予防型PMOがRedmineでのプロジェクトモニタリング方法を伝授する | マドびっ! Madosan's View

Redmineとチャットツールはどのように使い分けるべきなのか: プログラマの思索


| | コメント (0)

2020/05/17

オンライン勉強会のノウハウのリンク

最近の勉強会は、オンライン配信する時が多い。
友人からオンライン勉強会のノウハウを聞いたので、リンクをメモ。

【参考】
Zoomを活用してOSC2020 Online/Springを開催しました - 宮原徹の日々雑感

Zoomで開くオンラインイベント入門

アットホームな感じの オンラインイベントの配信を意識してみた

20200326 meetup video shooting meetup vol2 kitazaki いつも持ち歩ける ワンオペ配信機材

なぜ Infra Study Meetup運営は配信トラブルを引き起こしてしまったのか - Forkwell Press

オンライン勉強会に参加したり、自分たちが主催になった立場で経験してみると、いくつか気づきはある。

良かった点は、2つある。
一つは、東京など遠方の勉強会であっても、参加しやすくなったこと。
今まで行きたかったのに東京だから無理だ、という障害がなくなった。
また、参加者は全国が対象になったので、多数の参加者を集めることも可能になった。
さらに、会場費用も不要なので、勉強会のコストはせいぜい、Zoom管理費用をサブスクリプションで払うぐらい。

もう一つは、コロナ感染防止による自粛で外出できなくなっても、毎日どこかでオンライン勉強会が開催されているので、参加すれば、孤独感を感じることはなくなった。
むしろ、以前よりも頻繁に勉強会に参加しやすくなったし、以前と同じ交流ができた。
休日ならば、1日間に3回もオンライン勉強会をハシゴすることも可能だ。
実際経験してみたら、朝から晩までノートPCにしがみついているので疲れた。

他方、課題や留意点はいくつか感じる。

1つ目は、それなりの機材や環境は必要であること。
通信速度は100M以上は欲しい。
回線が細いと、ビデオも音声も途切れがちになり、お互いのコミュニケーションがやりにくくなる。

ノートPCにカメラは付属しているけれど、音声はヘッドセットが別途あった方がいい。
ハウリングしたり、自宅のノイズを拾ってしまうから。
片耳にかけて会話も出きるBluetooth ワイヤレスヘッドセットがあると便利。

2つ目は、Zoomなどのツールを使いこなすこと。
Zoomの管理機能はまだよく分からないが、部屋を作って参加者を分けたり、とか、割と機能が豊富みたい。
他にも、GoogleHangoutやSkype for businessなどある。
それらのツールでどこまで使いこなすのか、まだ理解している途中。

また、ビデオで会話するだけでなく、チャット機能やチャットツールも欲しくなる。
だが、オンライン勉強会を主催する立場になると、Zoomのようなビデオツール、参加者とやり取りするためにslide.ioやTwitterなどのチャットツール、スタッフ同士で裏でやり取りするMessengerやSlackなどが必要になってくる。

すると、Zoom、slide.io、Messengerの3つのチャネルを随時見ないといけないので、ノートPC以外にタブレットやスマホなども総動員して、3つ以上の通信機器を机に広げることになる。
つまり、割と大変なのだ。

3つ目は、オンライン打合せのファシリテーションスキルが必要になっていること。
対面の打合せでもファシリテーションは必要だが、オンラインになると、どうしても一方通行になりがち。
いかに参加者から活発な発言を促して発散させるか、そしてその議論を収束させていくか、オンライン特有のファシリテーション技術が必要な気がしている。

対面のファシリテーションでは、ホワイトボードやPostItが有効だったが、オンラインではそれらツールが使えない。
エディタやGoogleスプレッドシートを画面共有したり、マインドマップをツールで書いたりする。

オンライン・ホワイトボードは下記のツールがいいよ、と、坂根さんから教えてもらった。

便利なオンラインホワイトボードサービスmiro(ミロ)の使い方の基本

ファシリテーションでは、人間的なスキルだけでなく、こういうツールを使いこなす技術も必要なのだ、と気づいた。

たぶん、こういうツールや課題は、今はまさに発展途上な状態。
来年になれば、当たり前になっているかもしれないし、まだ先のノウハウも生まれているだろう。
いろいろ試してみたい。


| | コメント (0)

2019/11/03

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

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

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

第17回勉強会 - redmine.tokyo (2019/11/2) - Togetter

第17回redmine.tokyoで自動化の極意と形式知を育む #redmineT | マドびっ! Madosan's View

【1】Redmineコミュニティは1年のうち、大阪で2回、東京で2回、合計4回行われる。
この定期的なリズムが非常に心地よいと感じている。
Redmineを通じて、運用プロセス、プロジェクト管理、インフラ周りやプラグイン開発などの情報をユーザ同士で共有できる場があるのは非常に役立つし、何よりも楽しい。
今回の勉強会で心に残った箇所だけ書いておく。

【2】前田剛さんの発表では、ファーエンドテクノロジー版RedmineであるRedMicaの発表があった。
意図としては、Redmine本家のメジャーVerUpが年1回になっているので、最新機能のパッチが取り込まれているのにユーザに使ってもらえない問題に対し、Redmineの安定版バージョンにtrunkのパッチを当てて、定期的にリリースする、とのこと。

実際、Ver4.1には200個以上の機能改善が含まれているが、1年以上リリースされていないため、せっかくのパッチが使われていない。
この問題意識は重要と思う。

(1) akipiiさんはTwitterを使っています: 「#redmineT ファーエンド版Redmine では、半年ごとにtrunkプラスで最新機能パッチを定期リリースする。リリース計画のお話。気になるのは、Redmine 本家との互換性だが、trunkベースで、相互に移行できるようにする、とのこと」 / Twitter

(1) akipiiさんはTwitterを使っています: 「この考え方は重要。RT @akahane92: 今朝リリースされた Redmica(レッドマイカ) https://t.co/bXt3Pl37Lt Redmine本家のFork版ではない。独自の機能開発は行わず、Redmine本家の機能を先行して提供することに特化するつもり。 #redmineT」 / Twitter

(1) akipiiさんはTwitterを使っています: 「#redmineT Redmine 正式バージョンのリリースが遅い問題意識あり。そこで、ファーエンドテクノロジー版Redmine として、最新機能を盛り込んだフォーク版を公開した。なるほど、パッチを取り込んだ最新機能を早く使えるようにしたいわけか」 / Twitter

一方、Redmineプラグイン開発者の観点では、RedMicaにプラグインを追随させることで、メジャーバージョンアップに事前に対応できる、というメリットもある。

(1) akipiiさんはTwitterを使っています: 「なるほど、プラグイン開発でむ有用なのか。RT @agilekawabata: RedMicaのLychee Redmine対応ですが、本家Redmineのバージョンアップに追随はインパクト大きくて急に大変になるので、定期リリースしていくRedMicaに追随していこうと思います #redmineT #LycheeRedmine」 / Twitter

気になる点は、過去にRedmineをフォークしたChiliProjectのように、Redmineコミッタとギクシャクした関係になったりしないか、という点。
この辺りは、前田剛さんももちろん考えておられて対処している、という印象を持った。
Redmine本家に追随しながら、Redmineの発展を支援していく方向になるといいな、と思う。

【3】アカベコさんのRedmineテーマの開発も興味深い。
テーマは、RedmineのUIを手軽に改善できる手法の一つだ。
沢渡さんの「Redmineをお化粧する方法」という言葉がまさに的確と思う。

(1) akipiiさんはTwitterを使っています: 「お化粧の言葉がいいですね!RT @amane_sawatari: アカベコさん @akabekobeko の講演。「あなたも作れる!Redmineテーマ」 →CSSとJavaScriptでRedmineのUIをお化粧する方法 #redmineT」 / Twitter

SCSSやDockerコマンドの説明は、初心者にも分かる様にすごく丁寧に話されてる点が良かったと思う。

RedmineのUIが古い、UIが使いにくい、という話は以前からよくあがっていた。
Redmineテーマの種類が増えたり、テーマの開発が活発になることで、よりユーザフレンドリーなUIに進化できるきっかけになるといいなと思う。

【4】@akahane92さんの全文検索プラグインのお話は、過去のIT全般統制の事例、性能チューニングの話を振り返りながら聞くと思い出深い。

akipiiさんはTwitterを使っています: 「#redmineT @akahane92 さんは、7年前にRedmine によるIT全般統制の事例を紹介された。その後、性能チューニング、そして全文検索プラグイン開発、と着々とプロセス改善されてる。そういう経過を振り返るとすごいですね」 / Twitter

僕が理解したストーリーとしては、メーカー情報システム小会社の立場として、Redmineを社内システムのPJ管理基盤として導入し、IT全般統制も取り入れて、プロセス基盤を固める。
すると、Redmineが持つチケット管理機能やトレーサビリティの恩恵を受けた後、次に出てくる課題は、チケット40万以上の蓄積されたデータを活用して、ナレッジシステム化していくこと。
もちろん、Redmineが肥大化することで、性能チューニングの課題も出てくる。

そこに、全文検索プラグインを導入することで、Redmineのチケット、Wiki、果ては添付ファイルやSVN配下の文書に至るまで全文検索の対象になり、Redmineは真のナレッジシステムになったわけだ。

@netazoneさんが全文検索プラグイン導入のLTをしてくれたが、@akahane92さんの話を聞くと、単に全文検索プラグインを入れるだけでなく、ChuperTextによる形態素解析、検索Jobの設定などミドルウェアの設定もかなり多い。
つまり、全文検索の精度向上や性能チューニングの為に相当なノウハウが込められている点は注意。

【5】パネルディスカッション「チケットを切れる人切れない人/なじむ文化なじまない文化」にパネラーとして参加させてもらった。
沢渡さんのお話は非常に軽快で楽しかった。
沢渡さんの発言から刺激を受けた内容を話したいという気持ちが強すぎて、言いたいことの半分も話せず、あっという間に終わってしまい、消化不良感が残ってしまった笑。

akipiiさんはTwitterを使っています: 「経験に基づくので参考になります。RT @amane_sawatari: 経験から学ばない残念な組織「4つのない」 ?言わない ?既知か未知か判断できない ?記録しない ?クローズしない (パネルディスカッションでの沢渡のキーメッセージ サマリ) #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「#redmineT 今日は皆様ありがとうこざいました。いつも熱気があって元気づけられます。久しぶりのパネラーで、Redmine には組織の色が出る、一方Redmine 導入でチームが活性化し、メンバーの貢献意欲を引き出してRedmine が組織文化を変える時もある、話までしたかったのに時間切れで消化不良でした笑。」 / Twitter

自分が話したかった事をここで書き残しておく。

【5-1】Redmine導入の成功パターンは経験上2つある。
一つは、トレーサビリティの概念は経験済みであったこと。
つまり、すでに開発プロセスのイメージは僕の中で持っていたので、後はRedmineにプロセスを実装するだけだったので簡単だった。

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

「Redmineによるタスクマネジメント実践技法」の感想を集めてみたpart17: プログラマの思索

もう一つは、システム保守のように、ルーチン作業と突発的作業が混在している環境だったこと。
こういう環境では、チケット管理ツールのような基盤がないと、正直仕事がやってられない。
沢渡さんはチケット管理ツールの特徴として「備忘録のようなもの」という発言をたびたびされていたが、システム保守の現場ではまさに備忘録の基盤が必要。
「備忘録」というキーワードは、@sakaba37さんもチケット駆動開発の説明でも使われていたので、既視感を感じた。

【5-2】チケットには「ストック」「フロー」という2つの特徴を持つ。
物理学における光が粒子と波動の二重性を持つのと同じように、チケットはフローとストックの二重性を持つ点が非常に重要と考える。

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

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

チケット管理の上手な人は、チケットをストックだけ、フローだけで回すのではなく、チケットという1個のインスタンスを状況に応じてストックで扱かったり、フローに見せたりして、2つの性質を同時に使わせようとしていると考える。
一方、Excel管理では、この二重性を持たせるのが非常に難しいので、上手く回らない。

WBS駆動チケットというアンチパターンは中身がスカスカのチケット、と紹介して、他のパネラーも共感してくれた。
チケットをトップダウンでフローだけで扱おうとして、ストックにならないから、中身がスカスカになってしまうわけだ。

【5-3】沢渡さんの話で、オフショアチーム連携では、チケット管理ツールとチャットツールの2つあれば回るという経験談が興味深かった。
NTTデータのお仕事のときは、自社製のITSやチャットツールで運用されていたらしい。

akipiiさんはTwitterを使っています: 「#redmineT 今日はお忙しい中パネルディスカッションありがとうございました。オフショアチーム連携では、チケット管理ツールとチャットツールの2つ有れば回ると言う話は共感しました。」 / Twitter

僕は、沢渡さんの考えでは、仕事をする環境では、タスクや課題を共有する基盤とリアルタイムにコミュニケーションする基盤が必要なのだ、と理解した。
沢渡さんの発言の中ではたびたび、口頭でのやり取りでは後に残らないので仕事にならない、チケットに残して安心して忘れるべきだ、と話されていたが、それを実現する基盤がそれらなわけだ。

今ならば、Redmine はストック、Slackはフローで役割分担するだろう。

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT Redmine はストック、Slackはフローと言う役割分担ですね。」 / Twitter

個人的には、そういうチケットやコミュニケーションする環境を作るためには、心理的安全性という概念が重要になるだろうと思っている。
チケットには、課題やリスク、バグなど、プロジェクトの悪い話が出やすい。
そういう内容をどんどん見える化して、一つずつ解決する必要があるのに、悪い話を出すと周りから叩かれてしまう、という雰囲気では、チケットを切る文化は生まれない。
この辺りも同意してくれる人が多くて嬉しかった。

akipiiさんはTwitterを使っています: 「#redmineT パネルディスカッションのチケットを切る文化の話の中で、心理的安全性の言葉に反応してくれた参加者もいてくれて、嬉しかったな。チケットにはプロジェクトの悪い話が出やすい。そういう話題を1人が抱え込まずに見える化して、皆と共有できる場にしたい。」 / Twitter

【5-4】Redmineは組織に従う、という経験則があると思う。
特に、日本では、Redmineには日本の組織の色がすごくにじみ出る。
自分たちのプロセスに強いこだわりがあるため、Redmineのワークフローやトラッカーだけでなく、RedmineのUIや機能を組織に合わせようとして、カスタマイズして作り込んでいくパターンが非常に多い、と経験上感じる。
この点は、メリットなのか、デメリットなのか?も、参加者に問うてみたかった。

僕の考えでは、メリットもデメリットもある。
デメリットは、Redmineがカスタマイズされすぎた結果、Redmineの運用プロセスが複雑になりすぎてメンバーが使いにくくなること、VerUPの追随が難しくなることがあげられるだろう。
SAPなどの業務システムがいい例だ。

また、会社標準の単一Redmineを導入したとしても、複雑すぎて、現場に合わなければ、各チームごとに立てたRedmineインスタンスが乱立し、野良Redmineがはびこってしまい、標準プロセスから逸脱してしまう状況にもなるだろう。

だが、気象庁や田村さんの事例のように、各部署にRedmineインスタンスを配布して各部署に運用を任せた方が上手く回る、という事例もあった。
つまり、Redmineインスタンスは社内標準の1個がいいのか、各部署が複数個のRedmineインスタンスで個別運用したほうが良いのか、という課題が出てくる。
この辺りも、参加者に問うてみたかった。

一方、メリットは、Redmineが組織文化を変えてくれる場合があることだ。
既存のプロジェクト管理ツールのパッケージ製品には、その会社のプロセスが埋め込まれているので、自分たちのプロセスとフィットしない弱点が多い。
しかし、Redmineは非常に柔軟なので、自分たちの組織のプロセスにフィットさせやすいため、メンバーは慣れ親しんだやり方を変える必要がない。
Redmineの導入や普及の敷居は非常に低い。

すると、Redmineを導入することで、チームが活性化したり、オフショアチームとの信頼関係が強化されたりする場面がよく見られる。
マネジメント経験の浅いリーダーが、Redmineというツールを通じてプロジェクト管理を経験して成長する場面を僕も見てきた。
つまり、Redmineという一つのツールが、リーダーやチーム、そして組織を変化させていく力を持っている。
すなわち、Redmineは組織を変革する潜在能力を持ったツールなのだ、とみなせる。

むしろ、Redmineを導入したい人は、Redmineにそういう効果を期待しているはずだ。
そういうRedmineが人や組織を変化させるような話や事例をもっと集めたいし、聞いてみたいと皆思っているはず、と思っている。

【追記】
akipiiさんはTwitterを使っています: 「#redmineT チケットを切る文化の話が定着すると、次に出てくる問題が放置チケットやチケット棚卸しになる。ぼくはここがマネジメント層の腕の見せ所と考えてる。アジャイル開発はこの辺りのノウハウが上手いと感じる。」 / Twitter


| | コメント (0)

2019/10/24

第3回astah関西勉強会の感想 #astahkansai

昨夜行われた第3回astah関西勉強会の感想をメモ。講演者、スタッフ、参加者の皆さん、ありがとうございました。

【参考】第3回astah関西勉強会「もやもやを分解しよう」 - connpass

「モデリング事例紹介」10月23日に大阪で開催 ? 参加申し込み受付中! | astah in 5 min

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

【1】ツイッターやastah blogぐらいしか流していないのに、狭い部屋に参加者が30人以上も来てくれました。懇親会でも、以前から勉強会の存在は検知していて、今回初めて参加できた、という人もいた。勉強会のターゲット層、議論するドメインは非常に狭いと思うのに、興味を持つ人が多くて正直嬉しかった。

僕は、astah関西コミュニティでは、プログラミングとモデリングの間をモデリングツールや事例紹介の観点で行ったり来たりする議論ができるといいな、と考えている。そういう思いに共感してくれる人たちが少なくとも存在する、と気づけたのはとても嬉しかった。

【2】以下、講演の内容で感じたことをメモしておく。

【2-1】@ogomorさんの講演PlantUML+RDRAの話は、以前から聞きたいと思っていた。過去に色々書いてきた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

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

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

RDRAについては、システム地図という考え方が重要と考えている。要件定義から論理モデルや実装モデルまで、要件をトレースする仕組みがシステム地図として実現されている。つまり、RDRAでは、トレーサビリティを重視した手法であると思っている。僕は、モデリングではトレーサビリティが重要と思っているので、RDRAの考え方は好きだ。

但し、RDRAでは、UMLを拡張した図を多用するので、astahなどのUMLモデリングツールでは、UMLの制約に引っかかって全ての絵を書くことができない弱点があった。そこで、PlantUMLを使うと、自由に描けるので、RDRAの技法を全て実現できる。しかも、テキストベースなので、設計書をMarkdownで書けば、プログラムから設計書まで全てGitで構成管理の配下に置ける。

akipiiさんはTwitterを使っています: 「#astahkansai RDRA はUMLを拡張してるので、astah などの普通のモデリングツールでは制約に引っかかって書きにくい時がある。plantuml なら自由に描けるので、RDRA の記法も問題ない。」 / Twitter

興味深い点は、PlantUMLのソースを見るだけで脳内にUMLモデルの絵がイメージできるし、逆に、UMLモデルの絵からPlantUMLソースをイメージできるようになる、ということ。
右脳と左脳で行ったり来たりしている点はすごいな、と思う。

akipiiさんはTwitterを使っています: 「Astahkansai 慣れてくると、plantuml のソースから、頭の中で絵をイメージできる一方で、UMLの絵からplantuml のソースが頭の中にイメージできる、と。なるほど、まさに右脳と左脳で行ったり来たりしてるわけだ」 / Twitter

講演では図書館モデルの事例紹介で、ユーザの要望をコンテキスト図で表す時に、アクターアイコンの吹き出しに要望を書くことで、あたかもユーザが声に出して要望を話しているように見える、という箇所は非常に興味深かった。また、VSCodeでPlantUMLをライブコーディングしながらUMLを書いていく説明も分かりやすかった。PlantUMLは奥が深そうなので、色々試してみたい、と思う。

【2-2】とくぢろうさんの講演ユースケースリファクタリングでは、ファウラーのリファクタリング本を元に、ユースケースのリファクタリングのカタログを作ってみよう、という話で、面白かった。

ユースケースの削除、抽象化、分割、共通化、などは、ソースのリファクタリングの手法と全く同じように考えられるので、理解しやすい。実際の場面でユースケースを使う利用シーンは少ないけれど、その考え方は要件定義に活かせると思う。

但し、リファクタリングはTDDと表裏一体なのに、ユースケースのリファクタリングはTDDがないので、その部分の弱みはある。他にも課題はあったが、思考は深められそう。

akipiiさんはTwitterを使っています: 「#astahkansai Cソースの依存関係をastah のユースケースで描くと、ユースケースの依存関係の機能を使えるので便利」 / Twitter

【2-3】高井さんの講演では、GSNを使って、組込みシステムのタスク実装の意図を残す事例。僕は、GSNはロジカルな手法なので、厳密に説明するもの、と思っていたが、事例紹介の話を聞くと、説明する人の立場で論理を組み立てるので、意外に緩やかに使える印象を持った。

僕は、GSNやフォルトツリー解析、STAMPなどの手法はどのような違いがあり、どのように使い分けられるのか、が分かっていないので、この辺りも考えてみたいと思う。

【2-4】細合さんの講演では、テストケースの組合せ爆発を、フィーチャーモデルを使って制約条件を表現し、astahを基盤とした開発ツールでテストケース生成を行った話。フィーチャーモデルはソフトウェアプロダクトラインにも出てくるが、実際の記法を見ていたら、原因結果グラフに似ているような印象を受けた。だとすれば、組合せたテストケースの精度は非常に高いだろうと推測する。

【3】2時間の勉強会にたくさんの講演を押し込んでしまったので、質疑応答の時間が取れなかったのは反省点だけど、熱心に聞き取る参加者を見て、開催できてよかった、と思った。とても小さなコミュニティだけど、今後も緩く長く続けられればいいな、と思っている。

| | コメント (0)

2019/09/21

第3回astah関西勉強会の見所「もやもやを分解しよう」 #astahkansai

第3回astah関西を1年ぶりに開催します。
興味のある方は、ふるってご参加ください。

【参考】
第3回astah関西勉強会「もやもやを分解しよう」 - connpass

(引用開始)
要件定義やシステム開発で袋小路に陥った時、何か「もやもや」していることはありませんか?
そこで、そんな「もやもや」をモデルに書き出して、どんどん分解して、もやもやの真因を突き止めていきましょう。

そんな時に役立つモデリング手法の実践事例を講演者から紹介して頂きます。 具体的には、下記になります。

・モデルベースの要件定義手法(RDRA)とPlantUMLを使った実践モデリング
・ユースケースのリファクタリング・テクニック
・設計やプロジェクトのゴールに関するモデリング技術:ゴール指向表現(GSN)
・フィーチャー図によるテストスィートのモデリング技術
(引用終了)

一番の見所は、@ogomrさんの「PlantUML Example for RDRA 2.0」 。
PlantUMLで要件定義や設計の作業をどれだけ書ききれるのか、に興味がある。

@ogomrさんの下記の記事はとても参考になる。
PlantUML Example for モデルベース要件定義テクニック - Qiita

UMLで全ての設計ができるわけではないだろうが、UMLを一部カスタマイズして、業務システムの要件定義やシステム設計に合わせるようなモデリング技法(RDRA)を組み合わせると、ほとんどの内容をモデルとして描くことができる。
さらに、PlantUMLでテキストベースにUMLモデルを書けば、設計モデルもソースも全てGitの構成管理の配下で管理させることができる。
そうすれば、自動デプロイすることで、最新の設計書とビルドモジュールがいつでもリリースできる流れになる。

このあたりのアイデアは以前色々考えていた。

PlantUML Example for モデルベース要件定義テクニックの記事のリンク: プログラマの思索

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

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

PlantUMLが優秀な点は、UMLだけでなくER図も書けるし、画面インターフェイスの部品を使って画面設計書も書けたり、マインドマップやガントチャートまで対応している点だ。
つまり、設計資料以外にも、PJ管理資料まで全てテキストで管理できる可能性がある。

また、VSCodeを使えばPlantUMLを簡単にプレビューできるので、開発環境も揃っているのも良い。
もしかしたら、astahでモデルを描くよりも、VSCodeの方が馴染む人もいるかもしれない。

設計者が自分の意図を開発者に伝えたい時、シーケンス図を書くときが多いだろうが、その時に、PlantUMLで書いたシーケンス図を渡す利用シーンも考えられる。

特に、シーケンス図の修正はPlantUMLでテキストベースで書いている方が、仕様変更の対応にも強い。

そんなことを考えると、設計というモデリング技法は、モデリングツールの開発という観点も含めて、まだまだ発展途上の技術のような気がしている。
そういう内容も合わせて、色々議論できると楽しいと思っている。

| | コメント (0)

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)

より以前の記事一覧