見出し画像

Redmine Japan Onlineに参加しました

お疲れさまです。inoです。
前回の投稿から1ヶ月以上空いてしまいました。。すいません。

さて、9/18(金)に開催された
Redmine Japan Onlineに参加させて頂きました。
今回も記憶と備忘の意味で、拝聴させて頂いたセクションの感想を
執筆させて頂きます。宜しくお願い致します。

開催趣旨

↓ここを参照

https://redmine-japan.org

togetter

https://togetter.com/li/1594971

A02 基調講演1 Rubyにみる分散開発OSSコミュニティ

講演者:まつもとゆきひろ(@yukihiro_matz)さん※資料のリンクなし

多様化する選択肢
コロナ禍になって、働き方が多様化。
リモートワークが現実的な選択肢になった。
ー自分は基本出勤ですが、友人達は基本リモートワークになりました。
 しかも、「コロナを凌ぐ」ではなく「コロナだからこそ造る、新たな働き方」として。
 IT以外でもリモートワークで働き方が変わっていってる事を痛感してます。

ソーシャルコーディング
「良い」と感じるのは人により様々。そのため「良い」を定義する
ーリモートでの作業でgitを使った分散開発が可能になったと
 仰ってましたが、そうなると多様な考え方を持つ方が
 参画されて「良い」感覚の差分が産まれるのですね。
 だから「良い」を定義すると。なるほど‥

大事なのはコードより知見
エゴレスプログラミングという考え方。
自我と仕事の区別を意識する
ーコードを書き換えられることで人格も否定された気になってしまう。
 なるほど。。
 調べてみました。1971年の著書からある概念なのですね。
 リンクの記事から、抜粋して記載します。

エゴレスプログラミングの十戒
2「あなたの書いたコードはあなた自身ではない」
10 「人ではなくコードを批評せよ ? コーダーには優しく、コードには厳しく。」

…にしても、別の勉強会でも話題になりましたが
事実と感情をごっちゃにする人、指摘すると不機嫌になる人、
開発に限らずどこにでも居るんですね‥(汗)

A03 招待講演 次期バージョン Redmine 4.2 の注目新機能

講演者:前田剛さん(@g_maeda)
資料リンクはこちら

Redmine4.2の新機能についての紹介。
個人的にピンと来た機能をピックアップします。

二要素認証に対応
遂に来ました認証強化。
この実装で今までRedmineの導入や乗り換えを躊躇してた層が
動き出しそうです。
チケットをクローズ出来ない理由を表示
これ良い!
他のチケットシステムも、似たようなのが導入されてなかったら
是非導入してほしい。
クローズ出来ない時って、親チケットがあること以外の可能性も含めて
総ざらい的に漁っていくことになるので面倒くさいんですよ‥

B04 RedmineをDockerに載せてみた

講演者:藤田 優貴さん(@aruneko99)
資料のリンクはコチラ

RedmineをDockerに乗せて試行錯誤してみた話。

まだRedmineの環境構築をしてなかったのですが、興味本位で視聴。

githubを解説
事前に用意したgithubの内容を講演の中で解説して下さったのが印象的でした。githubへのリンクがあっても、後で内容を確認する手間が発生してしまいますし、だったら‥と考えると内容の解説は合理的ですね。

資料がわかりやすい
・資料自体がわかりやすくで良いです!Dockerの理解の為に何度も読み返したくなりました。

休憩後に午後の部が始まったのですが、トラブルで順番が前後‥オンライン配信ならではですね。

A06 あなたの行動を記録し、記憶につなげよう

講演者:高野明子さん(@akiko_pusu)
資料のリンクはコチラ

冒険の書を作ろう
この業界は新しいことを身に付け続けなければいけないが
特に歳を取ると、頭だけの記憶は難しくなってくる。
(僕は35才をだいぶ前に超えましたが、如実に感じます…)
だから、記録を取ろう。
記録は自身の記憶を呼び起こす、繋げる助けになるだけではなく、同じ苦労をさせたくない若手のためにもなる。自分の、誰かの冒険の書になる、と。

ふと自省すると、もう40歳が目前に迫っているにも関わらず
いまだに脳の記憶を頼りにしてるところがあるな‥と。
僕も生き残るために、記憶の辿り方を見直そう。そう思わされる素晴らしい内容でした。。
あと、「冒険の書」って表現のされ方が良いですね。。

A05 Redmineでコミュニティサイトを運営しています

講演者:小林慎治さん(@skoba) ※資料のリンクなし
※うろ覚えなので箇条書きに。

・お医者さんの登壇
・勢いあまってドメイン取得(openEHR.jp)
・TracはPython、RedmineはRuby
・RedmineはRubyで書かれているからプラグインも作れていいよね!
 ※実際に作る、とは言ってない

A07 Redmineと出会う前と出会ってからの7年 そしてこれから

講演者:門屋浩文さん(@MadoWindahead)
資料のリンクはこちら

プロジェクトマネジメントの活動とは
 わがままを良い感じに対応して結果を出すこと
 
 雰囲気的に良い!と感じるのですが
 そもそも話されていた「PMBOK」って‥?
 言葉しか知らなかったので、下記でざっと調べてみました。
 Wikipedia
 PMBOKを理解しよう

 なるほど‥プロジェクト管理を体系化したものなのですね。
 体系化したものだとITILがありますが、確かに体系を理解してると
 現場の課題の把握に使えたり、要所で概念を導入できたりして良いんですよね。
 以前、チームリーダーとプロジェクトPMO(PMOで一括にしても良いかもしれない)の掛け持ちをやってましたが、その時は我流でやってました。。
 この時に体系化されたものがあると知ってたら、また違ってたかな。

さくせん「コツコツやろうぜ」
マネジメントに限らず、心理ですね。
育成や技術研鑽でもやってく内にどんどん時間だけが過ぎていって
成果も見えなくて、時に特効薬的なものが欲しくなるのですが
目的と、それまでに何をすれば良いのかが見えてれば/わかってれば
結局は積み重ねが一番の近道なのかな‥と。

B09 Redmine データベースのテーブル構造を紐解いてみる

講演者:Juno NISHIZAKIさん(@juno_nishizaki)
資料のリンクはこちら

Redmineのデータベース構造って、一体どうなってるんだろ‥と興味本位で視聴。

入れ子構造
ほへー、となった話。
この構造の採用によりサブブロジェクトの検索がしやすくなる。
この構造が無いと、隣接リストだけを採用すると
階層が深くなると検索が辛くなると‥勉強になりました。

これ(資料)は…いいものだ。
ちょっと脱線するのですが。
資料全体が整然としててわかりやすい、と感じました。
データベースは座学で齧った程度ですが、実際にRedmineに関わることになったらこの資料を読み返そうと思います。

A10 事例紹介(アジャイルウェア)Redmine導入時のあるある

講演者:平川隆仁さん/神谷円さん
資料のリンクはこちら

難しいことこそ改善のきっかけ
わかります。難しいから出来ない/辞めるんじゃなくて、なぜ出来ないのか?
出来ないなら別の方向でやれないか?
そういうことを考える切っ掛けになると思います。
ピンチはチャンス。

Redmine導入時あるある③ 組織単位でチケット→プロジェクト単位でチケット
主語をどこに持ってくるか?なのかな…と解釈。
関係者を主語に持ってくると複数部署が跨ると混乱、煩雑‥
プロジェクトを主語に持ってくると○○のプロジェクトのなかでこの部署は進捗このくらい、あの部署は進捗これくらい、、となってわかりやすそうですね。

B11 パネルディスカッション テレワークでチャットとRedmineをどのように使い分けるか

講演者:岩崎さん(@hiroiwsk6)、楠川 智久さん(@tkusukawa)、齋藤 誠さん(@saito0119)

togetterから。
・チャットは流れてしまうもの。通知など気づかせるものに対して
 決定事項はRedmine。その後も続くようなタスクに対して(ソース:私
・「〇〇さんにメールしました。」「〇〇さんに電話しました。」 (ソース:ほか
・メールで思い出したけど
この前、Teamsに書いたのですが…てやりとりを電話でしてる人がいたなぁ。
Redmineみたいなタスク管理システムをうまく活用しないと
こういう手間はなくならないんだろうな。(ソース:私

棲み分けの話。
普段の会話でTeamsを使って、長期化しそう/重そうなタスクは旗振り役がRedmineでチケット切って、て感じですかね。
メールしました関連は、環境をうまく使いこなせないもんですかね。。Redmineに限らず。
単にメール/電話しましたっていう記録だけじゃ、詳細を別で調べなきゃならなくて効率的じゃないですし。。
せっかくコラボレーションツールを使ってるのになぁ…と残念なお気持ちです(現況を顧みながら

A12 パネルディスカッション なぜRedmineによるタスク管理が失敗するか

講演者:松谷さん、蘇田さん、ぼうこばさん

togetterから。

・起票したことで安心して、あとは放置…よくあるやつだな…参考書買って安心する、みたいな。(ソース:ほかの方
・リーダーシップとる人がいない、タスクの棚卸をしない‥
どこもあるんですねぇ(ソース:私
・チケットのタイトルを DO の内容にする(ソース:ほかの方
・ふと思ったけど、Doの形での表現は報告するときの内容にも
応用効きそうだな。完了形を相互に認識しやすい意味で(ソース:私

タスクがうまく回せないのはなぜ?な話。
やって終わり、更新は放置‥本当によくありますね。
ツールを導入した、コロナで仕事のスタイルが変わったから回せなくなった…とかそういうわけではないと思います。
誰かもおっしゃってましたが、前はうまくいってるように見えてただけで
実は潜在的に課題は潜んでで、それが表面化しただけかと。
Doの形でチケットを切る(Doneを意識する)。良いですね。お話を伺ってからタスクを文章に起こすとき、報告するときに応用してます。

A13 基調講演2 withコロナ時代のアジャイルとコミュニケーション 〜効果的な場作りとツール〜

講演者:平鍋健児さん(@hiranabe)
資料のリンクはこちら

場の力
平鍋さんが好きとおっしゃる電磁気学になぞらえて説明。電荷の歪みで(磁)場が出来、周りに広がっていく。
では、これをチームの場作りで考えると何が起こっているか?を説明されました。
一人ひとりの力が及ぼす関係ではなく場に力が蔓延していて
その場の力が個人個人を動かす‥とのこと。
Redmineの勉強会で考えると、

①Redmineを使用している「機会」があって
Redmineが好きになる
内部外部のRedmineの勉強会に参加して
・意欲を高めていきたい
・Redmineを拡めていきたい 意味で意見が一致し
「場」が出来上がる
そして、Redmineの勉強会に参加された方々が
場の力に影響されて、Redmine界隈が盛り上がっていく

…と、考えました。

コミュニケーションの一番の基礎は信頼関係

キャプチャ51

OSI参照モデルになぞらえて説明。
日本語でも英語でも、言語の下に信頼関係がある。そしてその間に
共感がある。
ただし共感と信頼関係は相互関係にあり、信頼関係がなければ共感はできず
逆に共感がなければ信頼関係はできない、とのこと。

チームづくりの変化
アナログからデジタルへの移行。
黎明期に一度集まって合宿的にチームを作るのではなく、継続してチームを作り上げていくContinuousチームビルディング
今まさに(同時性)、同じ空間で(同場性)、感じられる(身体性)、イマココ性(hear-now-ness)をどれだけ作れるか?試されてるのでは、と。
タックマンモデルについてもお話されていました。調べてみよう…

A14 Redmineコミュニティの活動報告と今後の抱負

講演者:あきぴーさん(@akipii)
資料のリンクはコチラ

過去のRedmine東京、大阪の歴史と登壇内容を振り返り。
過去には気象庁やJAXAの方が活用事例紹介で登壇されていたと。凄い‥!
コミュニティの方向性としては、参加者の多様化とエコシステム確立を目指すとのこと。

感想

登壇者の方、参加者の方、運営の方お疲れ様でした!
場の力で影響を受け、これはレポートを書かねば‥と思い
執筆させて頂きました!…の割に書き上げが遅れました。ごめんなさい。。
正直、Remoはスパチャみたいな懇親が目的であれば有用なのかな‥と感じました。
誰が喋っているかわかりますし、画面共有で何の資料を説明してるのか見えれば、今後の可能性は感じるな‥と。
発展途上のツールで通信の安定を求めるのは酷かな‥?と思いますが、他の方の感想を拝見すると
今回の不安定でRemoが嫌いになりそうな人も出てきてるようなので、ちょっとでも改善されればなぁ…と。

以上です。
最後まで読んでいただき、ありがとうございました!