親プロジェクトはサブプロジェクトになることはできません。 システム管理者が設定した プロジェクトのカスタムフィールド があれば、「公開」のチェックボックスの下に表示されます。 トラッカー.

フリーランスエージェントおすすめ16選と選び方の注意ポイント, Webでの発信や自己探求が好きです。『周りの人と自分が生きたい人生を生きる』というのが人生のテーマで、今は妻に「仕事をしない選択をしてもらう」ことを目標に仕事をしています。これまでの略歴としては、東京の四大の文系学科を卒業後、独立系SIerに就職し社畜SEを4年した後にフリーランスエンジニアを5年。現在はフリーランスエンジニアしつつWebマーケターとして生計を立てています。. ※ 主にSI業界に関するチケット管理のお話です。 プログラミングスクールおすすめ7選!徹底比較した失敗しない選び方, 人気No.1プログラミングスクール

Copyright © 1978-2020 「世界」旅と子育てを愛するアジャイルコーチのブログ All Rights Reserved. 今回はRedmineでプロジェクトを削除・アーカイブする方法を見ていきます。前回【Redmine】プロジェクトを作成する方法をわかりやすく解説にてRedmineでプロジェクトを作成する方法を見てきました。 ①管理者IDでログイン後、上記のメニューより管理画面へいきます。, ここではサラッと説明しましたが、次で新しいプロジェクトを作成する時の設定項目について詳しく見ていきます。, プロジェクトの作成は簡単にできますが、上記の通り色々と設定することができますね。適切な設定をして使っていきましょう! プロジェクトの他の使い方については下記をご参照ください。, Redmineのプロジェクト管理の使い方をわかりやすく詳しく解説します。プロジェクト作成・コピー・削除などについてまとめてありますので参考にしてみて下さい。, Redmineの使い方まとめになります。Redmineを初めて触れた方でもすぐにわかるように画面ショットを使いながらわかりやすく解説しています。, スキルを身につける もう少し言うとアーカイブは復元できますが、削除は復元ができません。仮に復元したいとなったら事前にバックアップをとっておいて、リストアするという手間が発生するのでしっかりと判断した上で行いましょう。, プロジェクトを削除したりアーカイブしたりするにはシステム管理者の権限がついている必要があります。もしついていない場合は、権限を付与するか権限が付与されている管理者にやってもらうようにしましょう。, 管理→ユーザー→対象ユーザーを選択して下記の通り「システム管理者」にチェックを入れることでプロジェクトの削除やアーカイブができるようになります。, プロジェクトを削除するには、アーカイブの時と同様に管理画面よりプロジェクト管理画面より削除していきます。, ②物理的に削除して問題ないことを判断した上で、「はい」にチェックを入れて削除を押下します。, ③プロジェクトが削除され、ステータス:すべてにしても該当のプロジェクトが表示されなくなります。(データベース上からも削除されます), ここまで見て頂いたプロジェクトを削除する方法とアーカイブする方法を下記の動画にて画面で追っています。音はなしなので気軽にご覧下さい。, 今回はRedmineのプロジェクトを削除する方法、アーカイブする方法を見てきました。繰り返しになりますが、一度削除するとプロジェクト内のチケット含めデータを復元することはできません。 Redmineを使ったチケット管理をしている方必見!ジワジワとredmineを壊して失敗させていく方法を公開しちゃいます。, チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー, こちらの記事の便乗ですが、私の今までのチケット管理経験から「こうすると失敗するよ」という実例を挙げてみようと思います。私はほぼredmineしか触っていないので、今回はredmineでのお話となります。, ※ 冒頭の記事と被る内容も多々有りますが、気にせず列挙していきます。 Redmineのプロジェクトを削除する方法. Copyright - プロテク, 2019 All Rights Reserved. 簡単に言うと削除は物理的に消す、アーカイブは一時的にゴミ箱に格納するイメージです。 しっかりと吟味した上で作業を行うようにしましょう!, [box03 title=”本記事のテーマ”]RedmineのプロジェクトについてRedmineのプロジェクト管理で抑えるべき点について[/box03]Redmineにおいて、プロジェクトは欠かせない存在です。 プロジェクトの概念を知っているかどうかでRedmineを使いこなせるかどうか変わって, Redmineの使い方まとめになります。Redmineを初めて触れた方でもすぐにわかるように画面ショットを使いながらわかりやすく解説しています。, スキルを身につける 基本的なRedmineの使い方を、シンプルなプロジェクトで見てみよう。 ログイン. ンタックスハイライトの対応形式, 「はじめてのRedmine使いこなし術」を電子書籍で出版(無料ダウンロード可), Redmineヘッドライン 月刊まとめ(2020å¹´10月), 【毎月更新】リリース前の新機能を先行チェック!「プロジェクトの削除」権限追加など(2020å¹´9月コミット分), Redmineヘッドライン 月刊まとめ(2020å¹´9月), Redmineヘッドライン 月刊まとめ(2020å¹´8月), ファーエンドテクノロジー株式会社, アクセス解析ツールの利用について, 誰でも閲覧可能(ログインも不要)。Redmineのデフォルト設定です。, Redmineにログイン中のユーザー全員が閲覧可能, Redmineにログイン中かつプロジェクトのメンバーに登録されているユーザーのみ閲覧可能, 「ユーザーは自分で登録できる」を「無効」に設定 (推奨), 「パスワードの再発行」をオフ (推奨). 50人の体験によるテックアカデミーの人気おすすめコース!副業したい人必見, フリーランスで収入上げる 今回はRedmineでプロジェクトを作成する方法を見ていきます。以前【超簡単】Redmineのインストール手順・方法(Windows・Linuxに対応)にてRedmineのインストール手順も紹介していますので、合わせて見て頂ければと思います。, プロジェクトはRedmineにおいて分類するための一番大きな単位で、チケットをはじめすべての情報はプロジェクト内にあるのでとても大事なものです。ここでプロジェクトを作成する方法をしっかり見ていきましょう!, 下記は音なしでプロジェクトを作成する画面を追っていますので、動画の方が良いぞと言う方は是非ご覧下さい。, 動画はちょっと…と言う方に下記は画像で手順を追っていきます。各項目の設定内容については後述しますが、プロジェクトを作成する流れを掴むために参考にしてみてください。 redmineはサブプロジェクト形式で複数のプロジェクトを1つのredmineに相乗りさせる事ができます。 相乗り ... に更新が必要になった時にいちいちゴミ箱ボタンで既に添付されたファイルを全部手動で削除していって新たに更新版を添付する、それを10回繰り返すの、何とも思わないのかな? gitやsvn wikiにまとめないといけない程のフローになってしまった時点で、その運用フローは破綻しています, 小技(0.9): チケットのステータスで進捗率を更新する | Redmine.JP Blog, Visual Studio Codeの謎ペインの仕様はユーザ離れを起こす原因となり得そうな件, amazon product advertising api for Java(SOAP):調査編, Ionic React+CapacitorでElectron利用時にstaticがずれる件に対応する, REALFORCE R2 TKL・HHKB Pro2 TypeS・NIZ 2019 Waterproof Seriesを使ってみた, react-redux v7.1+TypeScriptでconnect, mapStateToProps, mapDispatchToPropsを撲滅する, material-ui v4+TypeScriptでwithStylesからmakeStylesに移行してシンプルにする.

前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。

一度作ったプロジェクト、しばらく使わないとか今後二度と使わないだろうというものも出てくるかと思います。, まずはRedmineのプロジェクトの削除とアーカイブの違いについて見ていきます。 動画はちょっと…と言う方に下記は画像で手順を追っていきます。各項目の設定内容については後述しますが、プロジェクトを作成する流れを掴むために参考にしてみてください。 ①管理者IDでログイン後、上記のメニューより管理画面へいきます。 ②管理画面が開くのでプロジェクトを選択します。 ③プ … 確か Redmine 標準設定だとプロジェクト管理者のロール設定でプロジェクトやサブ プロジェクトの追加が有効になっているのだが、これは明示的に無効化する。 このようにすることでプロジェクトを追加する窓口はシステム管理者に一元化される。 プロジェクトの一覧には、デフォルトではすべての有効(アクティブ)なプロジェクトが表示されます。アーカイブされたプロジェクトも含むすべてのプロジェクトの一覧を表示するには、「フィルタ」内の「ステータス」を「すべて」に切り替えてください。 なお、プロジェクトの一覧としては、通常のユーザーでもトップメニュー内の「プロジェクト」をクリックすると表示されるものもあります。この画面では、システム管理者ではないユーザーでも新しいプロジェクトを作成できます(また、プロジ… プロジェクトを削除するには、アーカイブの時と同様に管理画面よりプロジェクト管理画面より削除していきます。 ①プロジェクト管理画面にて、削除するプロジェクトの削除 … Redmineのプラグインのインストール方法(WindowsとLinux各々解説)... Redmineのプラグインのインストール方法(WindowsとLinux各々解説).

Redmine 運用について書いてみるシリーズ 2/3。今回は職場の Redmine を運用するためのルールと諸設定をまとめる。守秘義務に抵触しそうな内容を避けるため、ぼかして書いているところもあるが主旨には影響していないはず。, システム管理者とは Redmine のユーザー管理画面においてシステム管理者が有効になっている状態を指す。プロジェクトの管理者とは別なので注意すること。この権限を持つユーザーは Redmine のあらゆる設定を変更できる。, Redmine を運用するにあたり、少なくとも 1 名 (1 ユーザー) は必要になる。, 任命するのであれば Redmine のインフラと機能の両面に通じているユーザーであることが望ましい。とはいえ Redmine の動作環境は Ruby だけでなく Passenger や HTTP サーバー、DBMS も絡み複雑。もしこれらの知識に不安を感じるなら My Redmine のようなホスティング サービスを利用するのもありだろう。, インフラも担当するなら Redmine 本家のロードマップや Redmine.JP Blog あたりを巡回して最新動向をおさえておく。最近のバージョンではあまり破壊的な変更はないものの UI 変更はインパクト大きいので、更新前に利用者へ通知するぐらいの配慮はほしい。, システム管理者が 1 名だと運用に関する知見が属人化して代替をたてるのが難しくなる。負担も大きくなるため、複数のシステム管理者を確保しておきたい。現職の場合、, という体制にしている。メインが私でインフラも担当、サブはユーザーやプロジェクト追加など設定面の管理だけ実施という感じ。, インフラについては将来 Ansible で構築できるようにして DB や files だけ引き継ぐとか、そういう管理を考えている。現在はこのあたりの情報を Redmine の Wiki にまとめており、それを読みながらであればサブでも実行可能ではある。, Redmine を業務管理に利用するのであれば、認証を可能な限り厳しくしてアカウント操作もシステム管理者のみに許可することが望ましい。管理と依頼窓口を一元化することで不測のトラブルを防止できる。, OSS プロジェクトなら不特定多数のユーザーを募ることになるだろうから、パスワードの文字数を長くするぐらいで他は標準設定のままでもよさそう。例えば Redmine 公式はユーザーによるアカウント登録を許可しており、テーマ作者自身が Theme List を更新できる。私も登録しており、このページを編集することがある。, Redmine 上で自身の関係するチケットやウォッチ対象が更新されたとき、メールで通知する機能がある。詳しくはメール通知 - Redmine用語解説を参照こと。, 地味ながら非常に重要な機能なので必ず有効にしている。Redmine はチケットや Wiki をコンテンツとする一種の CMS と見なせる。CMS を浸透させるためには、そこに関心事があることを積極的に通知することが重要。コンテンツ更新を把握するため同期的に張り付くなんて、いまどきありえない。非同期に更新通知がきて好みのタイミングで反応するのがあるべき姿ではないか。, メール通知対象とする動作は大量にあるけれど、標準設定であるチケットの追加と更新だけ有効にしている。他の操作で通知するのは過剰だ。例外としてニュース機能を利用していならその性質上、メール通知したほうがよさそう。, 要するにエコシステムがうまく回っていない。インストールに一発で成功して動作するとガッツ ポーズを取ってしまうぐらい事故に見舞われたので、もうお腹いっぱいである。WordPress がいかによく出来ているかを実感する。, 優れたプラグインもあるため、このあたりの問題に Redmine として対策されたなら改めて導入を検討したい。, 一方、テーマは CSS と JavaScript だけで構成されており、それ自体で完結しているため問題には遭遇しにくい。少なくとも Redmine がクラッシュすることはないはず。そのため過去には A1、現在は自身で開発している minimalflat2 を採用している。, さきほど WordPress を引き合いに出したが、あちらはテーマが HTML の DOM 構造まで操作するので問題が起きやすい。逆にプラグインは基本的に WordPress 本体の提供する API のみを使用するようになっている。共通してどちらも PECL は使用せず、動作環境は配布されるイメージだけで完結している。, Redmine もこのようにすれば公式リポジトリからの自動インストールなどをサポートしやすくなるだろう。プラグイン開発でも本体 API だけ追従できれば互換の問題も起きにくくなるのになぁ、と思う。, 少ない案件を何年も回すなら単純にプロジェクトを追加してゆくだけでよい。数が増えてきたら見通しをよくするためルール化された階層化を推奨する。, 顧客から請け負う案件は受託に分類。その下へ顧客となる企業名、案件名というように階層化してゆく。顧客があまりにも多いとか類似案件が大量にある場合は、それをあらわす系へまとめてもよい。例えばひとつのパッケージ製品があり、ほとんどの案件で作業が似通っているなら、, 社内向けの作業などは自社に分類。配下は事業や部署単位で階層化する。特別なプロジェクトとして社員個人を提供。この配下に社員単位で個別のプロジェクトを用意する。, ここはいわゆる砂場。クライアントや部署とは隔絶された安全圏だから社員の裁量で自由に利用可能。Redmine を導入するにあたり、いきなり実案件でチケットや Wiki を書いてもらうより個人プロジェクトで練習する機会を与えて苦手意識を克服させるのが狙い。, 現職だと個人的なブックマークや Tips 集として利用されることが多い。チケットはあまり活用されていないが Wiki でメモを取る需要はそれなりにあるようで、管理者として活動を眺めているとけっこう積極的に更新されている。, Redmine のシステム管理用プロジェクトがあると便利だ。前述の階層構造であらわすと自社の直下にRedmine 管理といった名前で用意する。, 新規にプロジェクトやユーザーを追加したい場合、このプロジェクトのチケットで依頼してシステム管理者が対応する。確か Redmine 標準設定だとプロジェクト管理者のロール設定でプロジェクトやサブ プロジェクトの追加が有効になっているのだが、これは明示的に無効化する。, Redmine を運用しているとシステム管理者の関与していないところで無尽蔵にプロジェクトが作成されて見通しが悪くなりやすい。階層構造にルールを設けてもたやすく破壊される可能性がある。こうした事態を防ぐため、システム管理者だけがプロジェクトを増減可能にしておく。, プロジェクトやユーザー追加をチケット化は手続きを可視化するための施策。依頼方法を別立てするより Redmine 内で管理するほうがわかりやすい。例えばプロジェクト作成依頼ではチケット作成フォームの入力内容は, という感じ。プロジェクト追加に必要な情報は Wiki にテンプレートを用意して、それを埋めてもらう。Textile のテーブル記法は慣れないと難しいから単純なプレーンテキストを書き換えるようにした。, 顧客名、案件名は前述のプロジェクト階層に対応。はじめての顧客なら、その階層から作成する。企業内で案件を管理する番号などがあれば、それを追加してもよい。このような管理には企業文化が反映されるものだ。, プロジェクトの初期メンバーは管理者と開発者に列挙されたユーザーにしておく。以降、メンバーを増減する場合はプロジェクト管理者が実施。時間トラッキングなどプロジェクトに必要なモジュール設定なども同様。基本は分割統治である。, プロジェクトを作成したら、その URL をコメントしつつチケットのステータスを解決に変更。担当者を依頼者に設定して内容を確認してもうらう。問題なければ依頼者はステータスを終了にする。なにか設定に過不足があればフィードバックしてから、このやりとりを繰り返す。, プロジェクト管理者が変更できる設定なら、誤りがあってもそちらで対応してもらったほうがよい。そのためプロジェクト追加の依頼者をメンバー設定でプロジェクト管理者にしておくと作業がスムーズに進む。, プロジェクトで使用するモジュール (各種機能) などは管理者へ委ねる。基本は分割統治だがシステム管理者としてはプロジェクトが公開されていないか?だけ注意すること。, これはプロジェクト設定の情報タブにある公開というチェックボックスで切り替えられるのだが、その権限はロール設定でも無効にできない。そのため定期的に Redmine 管理画面のプロジェクト一覧で公開がチェックされていないことを確認したほうがよい。, なお、Redmine 管理画面の設定からプロジェクトを選び、デフォルトで新しいプロジェクトは公開にするのチェックを外すことで、プロジェクト追加時の初期値を非公開にできる。, ロードマップは期限を持つ工程に名前をつけて管理するための機能。画面によってロードマップやバージョンなど呼称がバラバラなので注意する。というか混乱するのでいい加減、どちらかへ統一してほしいものだ。, ロードマップを利用する場合、ソフトウェア開発なら Semantic Versioning に従って v1.0.0 のようにバージョン番号で命名するとわかりやすい。v1.0.0 未満の新規プロジェクトであれば, のようにしてもよい。ソフトウェア開発以外でも何らかの工程管理を実施しているならば、それらに名前を付けていると思われるから流用するとよいだろう。, ロードマップを設定してチケットを関連付けると、それらを集計してロードマップ全体の進捗率を表示してくれる。例えば Redmine v3.3.1 をみると 2016/7/27 時点の進捗率は 64% になる。, 時間トラッキングや期限を設定すれば予想工数と実作業時間や残り日数も教えてくれる。これはプロジェクト リーダーやマネージャーが現状をざっくり把握するのに有用。そのため更新や運用フェーズのないプロジェクトでもロードマップは設定しておいたほうがよい。, チケット作成において粒度はなるべく小さくすることを推奨している。プロジェクトやロードマップに比べて個人差が出やすいので、 iki にガイドラインやサンプルを掲載しつつ、地道にアドバイスして慣れてもらう必要あり。, Redmine 標準のトラッカー、ステータス、優先順位は細か過ぎる。なので必要なもの以外は削除して簡素化するのも有効だ。チケット分類のためにトラッカーやステータスを増やしたがるユーザーもいる。例えばトラッカーに「設計」、「資料作成」、「顧客折衝」、ステータスに「検証」、「顧客待ち」など。, こうしたものはカテゴリで解決することを提案する。ある状態を定義できれば十分というケースが大半だろうし、それはプロジェクト固有の事情であったりするからカテゴリで十分なはず。トラッカーとステータスは全プロジェクトに影響するため、ひとたび設定すると廃止が難しい。そのためよほど汎用なものでない限り避けたほうがよい。汎用の判断基準としては業界で標準的な概念とか業態で必須の工程だろうか。, 入門Redmineに呉服屋の受発注を Redmine で管理する例が掲載されているけど、こうした業界であればその用語でトラッカーやステータスを定義してもよさそうだ。, Redmine のチケットはそのまま利用しても便利だが、時間管理を組み合わせると更によい。プロジェクト設定のモジュールで時間管理を有効することで利用を開始できる。実際に運用する場合、以下のようになる。, 作業時間を入力する都度、チケット全体の作業時間に累積されてゆく。この情報は実際の作業時間と見なせるため予想工数との乖離をみて見積もり精度の目安にするとか、管理職への日報の代りにするなどの用途に使える。, ロードマップ画面には全チケットの総計として予定工数と作業時間が表示される。この情報は進捗率とあわせてプロジェクトの状況を大まかに把握するため役立つ。進捗率は問題ないが、予定工数を作業時間が超え始めたならば、危険の兆候と判断してよいだろう。, 時間管理の単位について。この設定は基本的に時間単位で入力するのだが小数点も設定可能。そのため私は以下の基準を設けている。, 最小を 30 分として 1 日を標準労働時間である 8 時間で換算。半日はその 1/2、数日かかる作業なら 8 の倍数にする。予定工数を 1.5 日 = 12 時間とか細かく設定しだすとキリなく厳密さを求めたくなるため 1 日を超えるものは日単位でざっくり決定。逆に作業時間はベンチマークとして重要なので可能な限り細かく設定しておく。, 記録の更新は作業でキリのよいタイミングにしている。進捗率と一緒に更新することが多い。なるべく注記も一緒に書いておくと後で振り返るのに便利だ。私は作業の考察などを結構マメに書いている。Twitter へつぶやく程度の気持ちでガンガン書くのがよい。, Redmine の検索は Wiki だけでなくチケットも対象になる。よってある機能や業務に関連づいたメモ書きというのは後に有用な資料となることが多い。私はこれに幾度となく助けられた。, 職場の Redmine は Git リポジトリと関連付けている。設定についてはさくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub で書いたとおり。GitHub でプライベート リポジトリを運用するか迷ったが、, という理由により Gitolite を採用した。Redmine と共に Git (Gitolite) リポジトリ管理も私が担当。リポジトリの追加頻度は高くないためなんとか回せている。しかし hook 周りの設定とか Redmine との関連付けが面倒。なのでこの辺を Shell Script か小さな Web サービスで自動化したいと考えている。, Redmine と連携される際にひとつ、大きな問題が。Redmine のチケット番号はシステム全体で連番となる。そのためプロジェクト単位でリポジトリを作成しても、コミット時のコメントに書くチケット番号を 1 から開始できない。, そのため GitHub へリポジトリと issue を 移行したい場合、コミット ログを書き換えてチケット番号を整理するなどの面倒な作業が必要。やろうとは思わないが、このチケット番号の仕様は Redmine における Vendor Lock-In 問題のひとつと認識している。, ユーザー、プロジェクト、チケットの削除は原則禁止。削除を実行するとこれらを参照している部分に影響するため、削除を求められた場合は以下のように対応している。, 記事を書くにあたり職場の Wiki に掲載したルールを見なおしたのだが、判断基準も添えて書いているうちによくない部分が可視化されて棚卸しにつながった。特に認証設定は緩かったので本記事のとおり厳し目に変更している。これだけでも書いた価値があった。, 次回は職場に Redmine を普及させるための施策と課題について書く予定。数日、間が開くかもしれない。, さくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub, Redmine 2.1新機能紹介: プロジェクトの「終了」機能 | Redmine.JP Blog, 手動ログインを必須化。いまどきの Web ブラウザならセッション維持機能が標準搭載されているだろうから、実用上の問題もないと判断。, 登録はシステム管理者が担当する。「手動で〜」にしてもよいが結局は内容を精査して許可することになるため、設定もシステム管理者に一任したほうがよい。, 勝手に削除されては困るので無効。そもそもユーザー無効化は削除よりロックのほうが好ましい。, 旧 Redmine からのアカウント継承により標準のままとなっているが、近いうちに 32 文字へ変更する予定。複雑度を設定できないのが残念。職場では, パスワードの管理はユーザー個人に委ねているため、紛失からの復旧手段も提供する必要がある。そのため有効にしておく。, 標準のまま。こんなに要るだろうか。自社でドメインを取っているなら、それに紐づくひとつで十分かもしれない。, 導入済みで migrate なら動作するが新規インストールには失敗する、とかあって怖い, テーマ開発してるとき特定プラグインで表示がおかしくなるという issue が報告されたのでインストールしてみた時に遭遇, gem 未使用または静的に包含することを強制するとか、本体と隔絶した設計にしたほうがよいのではなかろうか, RTM (Release To Manufacturing), GM (Gold Master), 業務タスクも GitHub に移行する場合、Redmine の過去資産と分断されて管理しにくい, どうしても削除したい場合はチケットと Wiki ページを別プロジェクトに移行してから実施する, Redmine のチケット番号はシステム全体で連番となるため、存在しない欠番が発生すると管理的にややこしい, 誤りよりもそれを直さないことが問題、誤りは記録することで初めて顧みる機会を得られる.