第21回 Redmine大阪 Onlineに参加しました。
お疲れ様です。inoです。
今日は、昨日参加させて頂いた、第21回Redmine大阪 Onlineのレポートを
執筆したいと思います。
よろしくお願いいたします。
togetter
https://togetter.com/li/1557539
Talk1 Redmineの開発体制の現況2020 前田さん(@g_maeda)
資料のリンク⇩
https://t.co/j0eYJJIJa7
ー開発現状ー
・現状は7人で開発。アクティブメンバー(3人)は企業関係者が多い
・パッチ投稿の頻度が高い人たちの多くは企業所属
(ファーエンドテクノロジーさんとかPlanioさんとか)
・新バージョンのコミットは主にオーナーと前田さんが担当
ー課題ー
・コミットは2人だけ
・リリースを行うのは1人(Jean-Philippe Langさん)だけ
・↑このかたが最近忙しそう
→そのため、リリース間隔が長くなってきている
→意識決定が必要な大きな変更は時間がかかる
ー☝上記の解決方法提案ー
・ファーエンドテクノロジー版Redmine「RedMica」リリース
・RedMicaの公式プラグインおよび推奨プラグイン
ーRedMicaについてー
・半年ごとにリリース
・次期バージョンの新機能が先行して使える
・Redmineと高い互換。相互に置き換え可
・オープンソースライセンス
・Redmine本体に追加が時間がかかりそうなものは
RedMica公式プラグインとしてリリース
ー公式プラグイン紹介ー
「チケットパネル」
→チケット一覧を看板風に表示
ー推奨プラグインとはー
・利便性を高めるのに極めて有効なオープンソースのプラグインを
厳選してリスト化
・CIでのテストを対象とし、エラー検出した際はissueの方向や
プルリクエストを行い修正に協力
・11月リリースのRedMica1.2で3つリリース予定
Talk2 こんなRedmineは(個人的に)イヤだ！ 三浦さん(@kazuhito_m)
資料へのリンク⇩
https://www.slideshare.net/miurakazuhito/redmine-redmineosaka
ー静的情報と動的情報ー
・静的情報としてはRedmineを考慮。
ITS/BTSは動的情報として
ーチケットを書く、ということー
・「初期は」、質より量
「慣れていない」
「関係する方々がどんな有益な情報を持っているか、わからない」
ため、書いてもらうこと自体を重要視する。
・自由意志による起票は、まず無理。
自由意志の一部によって、
あるいは命令やルールと言った"制約"や
書けばこんないいことあるよーﾑﾎﾎといった"利得”
といったバイアスによって、成立し得る
→起票へのハードルを下げ、気軽に書けることを煽ることはするが
起票の制限は機会損失になる
ーこんなRedmineプロジェクトは嫌だ(鉄拳風に)ー
※ここからの話はフィクションですよ？
3-ケース① アクセスする自体に時間がかかる
【事象】
・VPN/多段トンネルなど、Redmine以前の接続時点の問題
・RDPなど、待機/他者への忖度を要する
【対策】
・スクリプト/ショートカットで簡易化
・SaaS
【最終手段】
・自チームだけ使わない
3-ケース② 「ロール」にやたらヒエラルキーを用いる
【事象】
・見る書くレベルで操作に制約
・システム/人間で厳守
・notロール(役割)but地位
【起こった】
・「～さんに頼んで」間接作業増加
・ルール外の暗黙のタブー
・「それは失礼だ」無意味な階級意識/権限主義
【対策】
Redmineのフル権限を付与
3-ケース③ 過度な隠蔽
【事象】
・プロジェクト/ロール分けによるマイクロコントロール
・2つ目/内向け/外向け などの用意
・裏Redmineってなんやねん…おぉ！？
【起こった】
・利用者への隠蔽意識の植え付け
・情報同士の関連(リンク)喪失
・(隠蔽されてる側の)疑心暗鬼
【対策】
なし
3-ケース④ カスタム入力の爆増/全入力
【事象】
・issueのチケットに、やたらカスタム入力が多い
・ルール上は必須だが、多くの場合「一番入力の多いプロジェクト」
に合わせてるので、無意味な入力
・テキトーに入力すれば、怒られる
【起こった】
・入力する側が、書く意味自体を疑問視した
意味の薄い入力の時間増加
【対策】
入力側が自身チームの入力シートを作成
3-ケース⑤ 常時ポーリング
【事象】
・issue管理の発生/追記/変更を、担当分は(リアルタイムで)全部見とけ
・見ていないと、強権者により叱責される
【起こった】
・人的ポーリング
・本来の仕事への時間を奪う
・ストレス
【ただし】
超人的な(…人間辞めてるような)
視点であるが、弊害が無ければ望ましいっちゃ望ましい
【対策】
・自身チームに振られたときだけ検知して通知が来るようにした
3-ケース⑥ クロージングにルールなく、スイープもしない
【事象】
・issueのチケットを「作成する」ことは定着したが
「終わらせる」仕組みがない
【起こった】
・解決しない課題の蓄積
・これでよくね？の常態化
【ただし】
・書くことを妨げない
【対策】
・「どうすれば終了か」を定義
・自チームレベルで「定期的にスイープ(未Close洗って終わらせる)」を
仕事のプロセスに組み込む
3-99 いろいろやったけど、最終的には・・
・書かない空気、使われない、情報収集進まない
・～の目に触れるからー※おそらく強権者？
・書くことが一大事だ！みたいな、ね、空気感(察してよ)
・ホントに書かない、一部の選ばれし場所、みたいな世界観の定着
ーそして何よりー
・三浦さんが、この現場でRedmineのissueもwikiも書きたくない！(そこかい)
→だから書きたくない！と思わないようにしてくれよー、頼むよ世界ー
・・・という妄想の話でした。おしまい
LT1 Redmineを使って高度なプロジェクト管理を実現したい！～学生フォーミュラのあるチームへの普及活動 岩崎さん(@ak_iwasaki)
学生フォーミュラ活動として
企画→設計→製作→試験→大会の流れがあるが
この一連の流れを、目指す姿を↓と考えRedmineを導入。
①設計ミスを繰り返さない
②管理上のミスをしない
etc
導入にあたっては、プロジェクト管理の重要性をアピール
①日程管理の重要性
②システム管理で行うメリット
③ExcelスケジュールからRedmineに移行したい
→勧めた結果
①Redmineへの申し訳なさ程度にログイン
②放置チケット増加、ユーザ離れる
ここで対策！
KnowledgeBaseプラグイン導入
・動画をNASサーバへ
・勉強になるものをピックアップ、Redmineへ
→利用増加
データは鉱山！でも原石でもある。見せ方が大事なんだ。
LT2 最速お届け！特盛 Redmine ～お好みプラグイン・テーマの Docker Compose 仕立て～ にしざきさん(@juno_nishizaki)
資料へのリンク⇩
http://u0u1.net/HVjR
( ﾟдﾟ)＜みなさん、構築やったことありますかー？？
実際構築しようとすると、DMSFプラグインやFullTextSearchPluginを
入れたり、、インストール自体が大変ですよね。ややこしスギィ！
そこで今回紹介するのはこちら！
Dockerを利用して、環境構築してみよう！
クライアント側の要因を排除できますし、WSL2やVirtualboxで
ubuntuやCentOSなどを経由して、Docker Composeを使ってインストールすれば良いんです！
ね？かんたんでしょ？？
ナウなヤングにバカウケ！なこどもRedmineも入ってますよー。
だがしかし！
複数プラグインを入れていると気になることが出てくる…アレ要る、これもう要らない…
→そういったお悩みは！Dockerで構築すると入替が楽ちんなので解決！！
最後に‥
どんなに素晴らしくても、使われないなら意味がないので
(セットアップめんどいとかなら尚更)プラグインをガンガン使おう！
そして、プラグインやテーマのメリットを享受して
各製作者には、最大限の感謝を！
LT3 そのテスト終了条件で十分ですか？こぐれさん
資料へのリンク⇩
https://www.slideshare.net/yutakakogure92/introducing-odc-analysis-for-redmine-osaka-community
・ソフトウェアテストとして量的な目安だけで充分か？
→ODC分析の紹介
・ODC分析とは…
ソフトウェアの品質を向上させる、洞察と方向性を得るための
測定と分析の方法論(直交欠陥分類法と訳される)
・複数の担当者で層別/分析
・Redmineを使った場合は、テスト実施者がRedmineへテスト結果を
バグとして入力
・テスト進捗管理システムと連動させれば、バグの自動起票も可能
LT4 ブラウザさんをながめてみよう！（仮）(@akiko_pusuさん)
資料のリンク⇩
https://www.slideshare.net/akiko_pusu/20200711redminelt
・こどもRedmineのテーマでスライド
・IE11死すべし。慈悲はない。
なお、edgeはギリギリ許される模様
・セッション用Cookieはリクエスト単位。
期限切れか、ログアウトするまで有効。
・Redmineのセッション用Cookieはリクエスト単位
・Secure属性
デフォルトはついてない
httpは平文見える
httpからhttpsでのリダイレクトも、
セッションIDを保持してると見えちゃう。
・オートログインの場合は、1度発行されたものを使い続ける
・GitHubはガチ
・iFrameは要注意
透明度0のものに気づかない
・まとめ
アプリは作られたとおりに動く
悪意あるアクセスかどうかはわからない
安全に使う！
・※今回資料はRedmineのプレゼンテーションモードで作成しました。
→LTが終わったので、チケットをclose！
凄くいいなーと思ったのが
資料にふんだんに自前の図やイラストが挿入されていること。
可愛らしくてホンワカする上に
インフラ系の資料は、図の有無で見る側/聴く側のわかりやすさが
段違いに変わるので、内容も図もイラストもスゲェ…と感嘆してました。
LT5-1 Redmineプラグイン開発スタートガイド2020年版」 (@yebis0942)さん
資料のリンク
http://u0u1.net/ipXw
・プラグイン開発トピック
・tutorial更新
3．x4.x向けに更新
継続的インテグレーションの発展
・CIの設定を再利用しやすくなった
・Railsバージョンアップに伴う非互換
4対応を謳いながらalias_method_chain相当の処理を使っているのもある
SystemStackErrorがエラーログに出ていたら要注意
・プラグインを作ってみる
・ブックマーク機能がRedmineにも欲しい
→時間がないので3分クッキング方式で。
LT5-2 「Redmineパッチ会の告知」 かわばたさん(@agilekawabata)
・Redmineパッチ会、始めます！
・開催の目的
・タスクを消化したい
・新しい開発者を増やしたい
・楽しく開発して、モチベを得られる場を
・オンラインでやってみた
・Remoで、3時間で
・自己紹介
・やりたい課題 etc
・第1回
7/23 海の日！
1回目は10人程度募集
QAのおじかん
(ここには一部私見を入れます)
①(三浦さんへ)
書いたらいいことがある→何かを承認されるの流れはむずかしい？
→とにかく褒めることで書いてもらう。
評価をつけてしまうと、書く内容がそれ向けになってしまう
ほめ駆動ですね。
僕の話になるのですが、そもそも誰が旗振り役をやるか不透明な
状態になったときに
率先して業務をやってくれたメンバーには
皆が見てる前で褒めます。なんなら褒め殺す勢いで褒めます。
承認とか、そういう将来なんらかの負荷が想定されることに対しては
誰もがやりたがらないので、率先してやってくれたことに対して
精一杯の感謝の言葉をかけ、その気持ちを尊重するのが一番かなと思います。
そうすると、次に同じような場面になったときに旗振りをやってくれたりするので。
②(岩崎さんへ)
大学生の雑談はどうやって？
→slack。前は掲示板。
前の話題をどうやってまとめるか、が課題
ナレッジ蓄積はRedmineになるのかな？
じゃあ、Redmine移行前の課題はどうするか？ってことですかね。
③(にしざきさんへ)
プラグイン大量に入れると、Gemfileが散らばってキャッシュを効かせられなくて辛くないか？
→つらみ。そういった場面は想定していない…
発表内容を拝見して思ったのは(Redmineマジで何も知らないですが)
資料のターゲット層は、そもそもRedmineの導入を躊躇している、
三浦さんの資料で言うところのユーザ層に向けたものではないかな、、と
感じました。
テーマもプラグインも一杯入れられる一括インストーラー的なのを
Dockerインストールしたらできるよ？どや？やってみんか？？
…的な感じで。
だから、Gemfileがぐちゃぐちゃになってしまっても
そこはこの資料の目的が達成できてるからヨシ！としたのでは、と
やりとりの中で考えてました。
④（まえださんへ）
RedMIcaのプラグインで、2要素認証/多要素認証のプラグインは？
→データベースとマイグレーションがあるので、Redmine本体への実装時に本体テーブルに影響が出そう。
ハードルが高い。慎重にやりたい
パネルディスカッション 「チケット駆動で成長し組織文化を変える」
・いかに楽をして(簡単にではなく、楽しく)業務をするか
・かどやさん(@Madowindahead)予防型PMOからの目線
PM×TM(プロジェクトマネジメントとチームマネジメントの相乗効果)
難敵への対処
アウトプットを出すための必須条件からの考察
PM力は中堅ほどだが、ツール利用度は千差万別。
この層をツール利用度が高い方へ育成していく
目的、インプット、ゴール、プロセス どれかがカオスでないか？？
→カオスだと、チケットは切れないのでは？？
→段階的に進化させていく
・@正月さん(@seizukio)駆け出しシャドーITエンジニアからの目標
チケット駆動はツール。
絶対的指導者が必要。
無理をしない、いろいろとやめない。仲間を増やす
「Redmine ってのがあって、なんか色々できるらしい」
「仕事が楽になることだけを期待して入れる」
→大体失敗する→何に使う、がないので活用されない
改善！
スモールスタート
わかる範囲での、小さな成功体験の積み重ね
結局、全部自分が決めたらいいんじゃないか？
業務量が多い→できるところからやる
チケット更新が苦痛→ちょっとずつ、、無理はしない
あれもこれもひとりで→仲間はどこかにいる！
社内がだめなら社外！
他者から学んで前向きに！
愚者は経験に学び、賢者は歴史に学ぶ
・あきぴーさん(@akipii)ソフトウェア社会学からの目線
導入成功パターンは経験上2つ
チケットは2つの顔を持つ仮説
Redmineと組織の因果関係
・Redmineは組織に従う
・Redmineで組織文化を変える
No Ticket, No Commitが徹底されていた
→下請け時代、自家製BTSで運用を経験。
運用プロセスのイメージがあったので、Redmineに乗せるだけだった
システム保守が多い
→毎月のルーチン作業と、日々発生する突発作業に追われる。
チケットは変化の多いタスク管理に強い
→Redmineなら2つが並存できる
不思議事例
アジャイル開発者は、オンラインの
チケット管理ツールに否定的な意見が多い
タスク看板の経験者は、Redmineを使いたがらない→なぜ？？
→三浦さんへ振られる(突如ｗ)
→回答 適材適所。業態に合わせて導入計画を立てないと
ヘイトばっかり集まってしまう
三浦さん「道具がプロセス曲げたらアカンとおもいます」
Redmineを使いたいがために、Redmine導入したらそらヘイト集まるよ。
チケットは2つの顔(仮説)
・ストック型チケットは記憶媒体
・フロー型チケットは流通媒体
1個のチケットは場面によって、ストックとフローの2面性を持つ
チケット文化になじむ人は、故意に
2つの性質をチケットに同時に持たせて使いこなしているはず。
・あるときは進捗状況を確認に使用し、またあるときは集計用に使用したりしてるのではないか
・アンチパターン
WBS駆動チケット
→中身がスカスカ、チケットに情報が蓄積されない
感想
・RedmineOsaka初参加＆オンライン懇親会初参加でしたが
皆さん温かく受け入れてくださって、本当に
ありがとうございました！！
・ツールはツール。
あくまで手段であって、それを使いたいがために
実運用が破綻しているケースは、Redmineのみならず
見受けられると思います。
ssmjponline#2(←僕のレポートのリンク先です)でも
似た議題が挙がってましたが、SaaSだろうとRedmineだろうと、
それを導入して終わりではなく
そのあとにどうやって活用し課題を解決していくか、それに当たり
どうやって周りを教育/啓蒙していくか。
そこまで含めた事を運用設計の時点で考慮すべきでは…と感じました。
・Redmineの界隈は、やはり熱量がすごいです。Togetterを見ていても
東京のときも大阪のときも、為になる/今までと違う観点に気づける話が
非常に多いと感じています。
今後も引き続き、東京/大阪の会に参加します！
・超個人的にですが、、三浦さんのお顔を拝見できて良かったですｗ
以上です。
だいぶ長くなりましたが、最後まで読んで頂きありがとうございました！