amareloのブログ（仮）

IT系勉強会で感じた想いや知見をメインに書いていきます。

Redmine大阪 Online 参加レポート

7/11（土）Redmine大阪 Online に参加しましたので、レポートを書きます。Redmine.Tokyoは以前から参加していましたが、大阪の方は今回が初参加でした。Redmine.Tokyoの時と同じような雰囲気で楽しく勉強させていただけました！

目次

イベントページ

redmine-osaka.connpass.com

登壇内容と感想

Redmineの開発体制の現況2020 前田剛さん

  • 現状の課題

    • パッチをコミットするのは、Jean-Philippe Lang 氏と前田さんの2人だけ。
    • リリースを行うのはJean-Philippe Lang 氏だけだけど、最近忙しいく意思決定に時間がかかっている。リリース感覚が長くなってきている。

  • RedMica（ファーエンドテクノロジー版RedmineであるRedMica）によって課題の解決

    • Redmineのソースを基に半年ごとにリリースしており、次期バージョンの新機能が先行して使える。
    • RedMica公式プラグインと推奨プラグインにより、より多くの新機能を安心して利用できる環境を提供していく。
    • Redmin本体に追加されるのに時間がかかりそうな機能をRedMica公式プラグインとしてリリース
    • RedMica1.2（11月リリース予定）では、3つのプラグインを推奨としてリスト予定
      • Issue Templates、Messsage Customize、View Costomize

やはりどこの現場でも決裁権限を持つ人が忙しくて、なかなか先に進まないって良くある話。でも最新の機能をはやくユーザが使えるようにしたいという働きは、ユーザにとっては本当に嬉しいことだと思います。

こんなRedmineはイヤだ！　 @kazuhito_m（みうみう）さん
資料

www.slideshare.net

  • 「権限」「ロール」にやたら「ヒエラルキー」を持ち込む。
  • 過度な隠蔽があると、利用者に隠ぺいすべきかを考える意識を植え付けたり、疑心暗鬼になる。

  • いろいろ問題が重なると、何となく書かない空気になり、使われない、情報集約進まなくなる。

  • プロジェクトや組織の初期は人々が慣れてなかったり、個人がどんな価値ある情報を持つのか分からないので、まずは書いてもらうを重視した方が良い。質より量

  • 書くことのハードル下げて、気軽に書ける環境を作る。「制限する」は機会損失。
  • 人は「書いて」と言っても書かない。「書きたい」を邪魔しないこと。

インフラ勉強会ではお馴染みのみうみうさんでしたが、はじめてお目にかかれました！ホント話上手くて面白いなぁ～

Web会議のマナーじゃないけど、よくわからんルール決める人ってホントどこにでもいますね。 そのルールが成すことは何か、目的は何かが明確でないと、不要なルール、使われないツールになってしまうので、自分も注意して物事考えたいと思いました。

Redmineを使って高度なプロジェクト管理を実現したい！～学生フォーミュラのあるチームへの普及活動　@ak_iwasakiさん
  • 大学だとチームメンバの交代は一般企業より早い。
  • 車両費用に予算優先配分されて、管理側に予算を配分できない。
  • 目指す姿は、過去の設計ミスを繰り返さない。プロジェクトの管理上のミスを発生させないこと。
  • プロジェクト管理の重要性、システム管理（Redmine）で行うメリットをアピール
  • 短期的なメリットがないと動かない。データは鉱山だけど原石。見せ方が大事。

大学生は毎年メンバが入れ替わるから、ノウハウの引継ぎは重要。とはいえ、システム化してもメリットがないと動かないのは企業と同じ。ツールの導入が目的ではなく、メリットや実現したいことを意識することの大切さ、必要だなと思いました。

最速お届け！特盛 Redmine ～お好みプラグイン・テーマの Docker Compose 仕立て～　@juno_nishizaki さん
資料

docs.google.com

  • Redmine構築したくても手順がややこしすぎる！
  • いいプラグインがあっても、インストールが難しいと利用されず問題ではないか？
    • Dockerでインストール・更新。ホストOSにあまり左右されなかったり、構築手順をコード化できる。
  • どんなに素晴らしいものが作られていても、あまり使われていないんだったら意味がない。もっとガンガン使って作成者に感謝の気持ちを！

一度、自宅PCのVirtualboxにサーバ立ててRedmine入れてみたけど、確かに手間がかかる印象。やはり何にせよ、シンプルに事が進むのがいいですね。 Dockerも扱えるようになりたいけど手が回ってない…何処かで時間とって勉強したいと思いました。

そのテストの終了条件は大丈夫ですか？ Kogure_Yutaka さん
  • 定量化テスト手法ODC分析
    • 欠陥を8つの視点から分析する。
  • テスト進捗管理システムから障害をRedmineにチケット登録している。
    • タグ付け
    • バグ管理システムをカスタムフィールドで実装
ブラウザさんを眺めてみよう @akiko_pusu さん
  • RedmineはWebアプリケーション。ブラウザがおともだち。
  • セッション管理はCookieがしている。セッションIDが知られると、自分になりすましてログインされる（セッションハイジャック）
  • Redmineセッション用Cookieはリクエスト単位で発行されている。

  • 取られると怖いので、ブラウザさんに注意をして送っている。

    • 別のドメインには送らないように。
    • HTTP/HTTPSのみに送信する（HttpOnly）。
    • RedmineではSecure属性（HTTPSのみCookieを払い出す）がデフォルト設定されてない。
      • httpアクセスだとhttpヘッダが見えちゃう。
      • httpからhttpsへのリダイレクトでも注意。sessionIDを保持したユーザが初回httpアクセスするとその通信が見えちぇう。
      • secure属性の設定（config/application.rb）が可能。
    • autologinは慎重に設定しておこう。
      • Secure属性がつくけどcookieの有効期限がデフォルト1年

  • GitHubはかなりガチ（CSPの設定、Cookie設定、X-Frame-Option）に設定されている。

  • アプリは作られたとおりに動くが、悪意あるアクセスかどうかは判断できない。

    • 安全に使うよう設定を心がけて。

たかのさんの資料は柔らかくて優しい絵でいつもとても和みます。 が、内容はかなりガチな内容で見につまされる思いでした。自分は仕事でWebセキュリティについてよく関わるので、Secure属性やCSPという言葉はイヤというほど見ます。本当にWebアプリケーションは作られたとおりにしか動かないので、Redmineに限らず設定不備や脆弱性は残さないよう気をつけないといけないし、それを啓蒙しなければと改めて思いました。

「Redmineプラグイン開発スタートガイド2020年版」 @yebis0942 さん

プラグイン開発できるようになれば、Redmine利用を便利にできて仕事を便利にできて良いなぁと思います。自分はプログラミングで何か作るという経験に乏しいですが、小さくても便利に仕事できる仕組みを作って貢献できればなぁと思いました。今更だけど、何かプログラミング言語を身に付けようかな。

「Redmineパッチ会の告知」@agilekawabata さん

  • Redmineパッチ会の目的

    • Redmine本体の改善をできる人を増やしたい。

  • オンラインでも継続するために、第０回をRemoを使って開催した。

  • オンライン開催でも十分できることが分かった。
パネルディスカッション　「チケット駆動で成長し組織文化を変える」
門屋さん　予防型PMOからの目標
  • PM × TM
  • 難敵への対処モデル

  • アウトプットを出すための必要条件からの考察

    • PM技術力が高くツールの利用度も高い。この位置のメンバを増やす。
    • できる人の活動をまねる
    • 今のままでいい、めんどくさい、何でやってるのか分からないなど言う難敵が出てくる。作戦を使って自律的ナレッジを作れるようになっていけるように。
    • チケットを切れるようなるには、整理すべきことがある。
      • 測定がしやすいのはアウトプット。そこからプロセスを逆算して目的・ゴール、インプットを考える。
      • どれもが整理されていないとチケットを切れないのでは？段階的にレベルアップしていく必要がある。
正月さん 駆け出しシャドーITエンジニアからの目標
  • チケット駆動で成長し組織文化を変え、良くするためには
    • チケット駆動はツール。ツールの使い方を明確にする。
      • 楽になるという目的だけでは、何に使うかが無いので活用しなくなる。
      • スモールスタートで成功を積み重ねる。最初はバグ管理のみに使った。
    • 絶対的指導者が必要。チケット文化を定着される。
      • ルールが分からない。決まらないから、結果活用されなくなる。⇒全部オレが決めたらいいんじゃないか？
      • 誰かが引っ張らないとやらない。日本人組織のあるある。とにかく最初はバグ出たらチケットを書かせた。
    • 無理をしない、色々とやめない、仲間を増やす。
      • スモールスタート。ルールを決めながらできるところからやる。一足飛びにはやらない。
      • 無理はしないで意見を聞きながらゆっくりと。
      • 仲間は何処かにいる！社内にいなければ社外に！
        • 愚者は経験に学び、賢者は歴史に学ぶ。
あきぴーさん ソフトウェア社会学から
  • Redmineの導入成功パターン
    • ノーチケット、ノーコミットを徹底させた。
    • システム保守にはなじみやすい。

  • アジャイル開発者とRedmine（他のオンラインチケット管理ツールも）に否定的な見解が多い。

  • チケットは2つの顔を持つ仮説

    • ストック型チケット（記憶媒体）
      • 過去の障害情報などをストックして検索できるようにする。

    • フロー型チケット（流通媒体）

      • 今誰がボールを持っているか？ステータスは？を見たい場合。

    • チケット文化になじむ人は、ストック型とフロー型の性質、両方をうまく見せることができている。

全体の感想

Redmineを定着するには組織文化を変える活動も必要だと思いましたが、「プロジェクト管理したいからRedmine導入する」だけだと、組織文化によってはうまくいくところもあれば失敗するところもあるのかもしれません。もっと、導入する目的と何を実現したいか、Redmineで何を解決できるのかを深堀りして考え、運用設計した方が良いのかなと思いました。それはRedmineだけではなく、クラウドサービスなどすべてのツールにおいて共通の考え方ではないかと思いました。

東京と大阪、雰囲気は似ていてもそれぞれ違った観点の収穫を得られることに気付きました。これからは東京も大阪も両方とも参加したいと思いました！

ちなみに、初めてみうみうさんのお顔を拝見できたことが、個人的には最大の収穫だったりしますｗ

あと最後に、いつか大阪行きたい！