前回は、ラズパイに Redmine を Docker を使ってインストールしてみました。タスク管理ツールも割と、「ただ入れただけでは使い切れない」系ツールでした。プロジェクトマネジメントはその更に一段上の、（通常複数人の）タスクや期日の束であり、ステークホルダーやスポンサー（要するに上司だの社長だの株主だの）とのコミュニケーションを包含する概念なので、より面倒くさいです。
ということで、 Web サイトのリニューアルという、比較的シンプルなプロジェクトマネジメントを考えながら、 Redmine の使い方を模索して見ます。
この記事の目標
- Redmine の基本的な使い方を学びたい（著者が）
- できるだけ PMBOK にあわせたい（見るからに無理っぽいですが）
- とりあえず伝統的なウォーターフォール型のプロジェクトを扱う
- WBS(ワークブレイクダウンストラクチャー)やPDM（プレシデンスダイアグラムモデル）っぽいものをチケットやガントチャートに反映させる
書いている人
元 Web 系エンジニア。バックエンドからフロントエンド、デザイナーを経て中小企業診断士を取得。いわゆる一人 SE も経験。
プロジェクトマネジメントについては、 Web サイトの構築・中小企業診断士の実務従事を通して痛感。一方で、経営のプロたる中小企業診断士にもぜんっぜん、プロジェクトマネジメントの概念がないことに愕然として PMBOK を勉強中。
そも、プロジェクトマネジメント とはなんぞや？
そも、プロジェクトとはなんぞや？
プロジェクトってなんでしょう、 生まれて初めてエディタではなく、 Visual Studio でプログラムを書いたときに、いきなりファイルではなく、プロジェクトファイルを作らされ、テキストファイルでない部分で大量に設定を書かされて、初心者の心を折りにくるアレでしょうか？
ある意味では、それもあっているかもしれません。通常の業務ではタスクが個人でも見えています。一方でプロジェクトになると全体的なタスクは参加者ひとりひとりには不明瞭なこともよくあります。目的や進捗の管理はありますが。
辞書を引いて見ると、事業とか計画とか出てきますが、事業というと、もっと大きい仕事の単位というか会社の業務全体を指してしまいます。特に中小企業では事業すなわち企業全体であることもあります。計画というのはどうでしょうか。確かにあっているような気もしますが、旅行計画とプロジェクトは何かが違うような気がします。
いつもならできるだけ和訳を探す楽介ですが（基本的に、横文字でごにょごにょ言うのが嫌いです）、こればかりはプロジェクトと横文字にしてしまった方がいいように感じています。
さて、楽介が勉強中のPMBOK – Project Management Body of Knowledge – プロジェクトマネジメントの技法や知識をまとめた技術体系の第7版によると、
独自のプロダクト、サービス、所産を創造するために実施される有期的な業務。
とされています。意味分かんないですね。
有期的とは、つまり「期限がある」ということです。期限がなければそれはすなわちプロジェクトではないということですね。時々、ブラック企業化を怖れてプロジェクト的な業務にも関わらず期限を設定しようとしないマネジメントもいますが、撤退の判断・投資効果などの判断ができなくなるのでちゃんと設定しましょう。
もう一つ重要なのが「独自のほにゃららを創造する」ということです。量産品ではありません。たとえば、 「WordPress のブログ構築」であっても独自の写真を挿入したり、企業理念を入れたり……といった独自性が含まれていることが要件です。イメージは掴めたでしょうか？
言い換えると、「特製の何かを作るための、一時的な一連の仕事」と言えるでしょう。
じゃあプロジェクトをマネジメントするとは？
こちらも、PMI による PMBOK の定義を引くこととします。
プロジェクトの要求事項を満たすために、知識、スキル、ツールと技法をプロジェクト活動に適用すること。
となっています。なんとなく言っていることは分かりますが、ちょっと意外かもしれませんね。期間までにタスクを達成させるとか、予算を守るとかが書いていません。これらの要素が含まれないということではないのですが、それは「プロジェクトの要求事項」内になります。プロジェクトの要求事項にタスクの達成や予算がなければそれはプロジェクトマネジメントの範疇ではありません。もっと言えば、サボらずに働かせるとか、監視とかは全然関係ありません。
プロジェクトごとに異なる要求事項（QCD だったり、社会的責任だったり）を満たすために、ありったけの「知識、スキル、ツールと技法」を適切に適用することがプロジェクトマネジメントです。
まあ、もっとも、スケジュールを守るとか、予算を守るとか、一般的な要求事項に対するツールと技法は PMBOK にも含まれているのですが。この辺りが凄く、コンピュータープログラム的定義で分かりづらいです。
Redmine をどう使えば プロジェクトマネジメントの役に立つか？
では、本記事の主題である Redmine の立ち位置はどうでしょうか。PMBOK の言う「知識、スキル、ツールと技法」には実は含まれません。ここでいうツールとは、ソフトウェアやハードウェアではなく、考え方やフレームワークのことで、個々のプロダクトではないからです。
とはいえ、「ツールや技法」をサポート・実現するためのソフトウェアと考えて差し支えないでしょう。
意識したいのは、（PMBOKの言うところの）プロジェクトマネジメントのすべてを網羅するツールではないということです。PMBOK の定義するパフォーマンス領域のうち、関わりが深いのは、
- チーム
- 計画
- プロジェクト作業
といえます。計画については非常に幅広いですが、残りの2つと関連する計画パフォーマンスが主体だと考えられます。後は、プロジェクトマネジメントに関わる各成果物（資料とか、ノウハウとか、ドキュメントとか）を保存・格納する場所として使用できます。これはそれこそ、オンプレミスに保存したいなら Nextcloud とかでもいいのですが、プロジェクト単位で保存できたり、直接リッチなドキュメントを編集できたりするので、運用ルールが徹底できれば便利です。
他の領域をプラグインなどで内包しようという試みもありますが、それは PMBOK に限らずプロジェクトマネジメントの全体像が見えているからできることであって、「プロジェクトマネジメントをしよう、よし、 Redmine を覚えれば完璧なはずだ！」ではありません。「プロジェクトマネジメントするけど、 Excel ポチポチだと面倒臭いし OneDrive で共有してもイマイチ評判悪いな……チームで使えるツールとして Redmine を入れよう」というのがアプローチとしてはただしいと言えるでしょう。
まあ、楽介は一人で使いますが……（練習です、練習）
じゃあ Redmine をいじってみよう
前置きが長くなりました。 Redmine に全ては任せないということを意識しながらやっていきましょう。
プロジェクトの体制
想定するプロジェクトは、
- WordPress で構築された Web サイトのリニューアル
- 画像素材の作成は、デザイン会社に外注（デザイン d社）
- 顧客からの写真などの素材は、社内の営業 c が受け取り管理し、デザイン d社に受け渡し。
- WordPress の構築はプロマネの楽介が行う
みたいな感じです。割とありがちな体勢かなと思います（特に Web いじれる人間がプロマネを兼任しないといけない辺り）。WBS は作るほどではないと思うので、今回は作らないです。
Redmine にトラッカーの追加
トラッカーの単位を考える
Redmine のトラッカーとは、チケット（タスクなどの単位）で使用する入力項目や、ステータス（状態、チケットが着手されているとか）を定義するもので、カテゴリではないとされています。
PMBOK ガイド第6版（第7版はアジャイル型プロジェクトを意識し原理・原則ベースに変更されたため、個別の技法などは省略されていることがあります）では、スケジュールモデルとして、プレシデンスダイアグラムモデル(PDM)が紹介されています。これには、それぞれのタスク・アクティビティ（PMBOK の表現）の相互依存関係として
- 終了-開始(FS)：先行タスクが完了するまで、後続タスクが開始できない関係を示す。一般的なフローのつながり。
- 終了-終了(FF)：先行タスクが完了すると、後続タスクも完了できる関係を示す。開始はできる。
- 開始-開始(SS)：先行タスクが開始すると後続タスクも開始できる関係を示す。
- 開始-終了(SF)：先行タスクを開始すると、後続タスクが終了できる関係を示す
このうち、 Redmine のチケットでできそうなのが、
- 終了-開始(FS)：次のチケットに先行・次のチケットに後続
- 終了-終了(FF)：ブロック先・ブロック元
残り2つの 開始-開始、開始-終了関係については、チケットの親子関係で擬似的に表現する（内包する）か、単に「関連するチケット」として設定することが考えられます。
一方で PDM はそれぞれの順序を示すことに重点を置いた技法なので、実際の細かな作業・タスクを全て記載すると煩雑です。
例えば、Web サイトの内、会社概要のページを作成するという大きなタスクを考えて見ます。このうち、「企業理念の作成」「代表挨拶の作成」「代表の写真撮影」「地図の作成」などは順不同で行っても（複数人で手分けしても）問題ありません。それぞれが PDM における SS 関係であると言えます。そして、全てが「会社概要ページの作成」タスクに対して FF 関係を持っています。
これを正直に Redmine 内で表現しても仕方がないので、チケットの親子関係としてしまうのがいいでしょう（チェックボックスでもいいかもしれませんが、写真の撮影とテキストの作成は通常、担当者が異なりますのでチケットは分けた方が管理しやすいでしょう）。
また、更に大きな単位として WBS を作成することを考えて、トラッカーは
- WBS レベル
- PDM レベル
- タスク レベル
としてみます。
WBS レベルのチケットの中に PDM レベルのチケットを格納し、さらに PDM レベルのチケットの中に タスクレベルのチケットを格納するとして運用します。
目的としては、タスク・アクティビティの分析を WBS からのトップダウンアプローチで考えるにしても、タスクレベルからのボトムアップアップローチで考えるにしても、Redmine 内で一括で管理できる点がメリットです。
プロジェクトをマネジメントするという視点では、正直「タスクレベル」まで分解することは多くないと思います。しかし、リーダーシップ理論の一つ、SL 理論で教示的なリーダーシップを取る場合はタスクレベルまで分解が必要になるでしょう。また、大規模プロジェクトでチームリーダーに PDM の各アクティビティを割り当てた後、チームメンバーにタスクを割り当てるといった運用をする場合はタスクレベルのチケットが必要になります。
WBS と PDM のレベルを分ける意義ですが、 WBS をしっかり作る必要性のある大規模プロジェクトというのがなかなか難しいのですが……、PDM がプロセスの順序に重きを置いている一方で、 WBS は成果物をベースとして考える方法もあります（飛行機を作る場合、パーツ単位で WBS を割るとかですね）。また、標準の入力項目をコントロールする効果もあるのでそういう意味でも細かく分けてみましょう。
RACI チャートを実現できるようにする
続いて、 アクティビティに関する責任を考えて見ます。
Redmine のトラッカーのフィールド（入力項目）では、「担当者」というものがあります。ただ、これだけだと実行する責任はありますが、誰に報告するとか、誰が完了を承認するかといった責任が不明確で曖昧になりがちです。
そこで、PMBOK では(特に第6版までかな？)責任分担マトリックスと RACI チャートが紹介されています。この RACI チャートは、責任分担を明確にするために、「列に人物」「行にタスク」をとり、それぞれが交わるところに責任を記載します。責任はそれぞれ、
- Responsible 実行責任者。いわゆる担当者。タスクの実行に責任を持つ。
- Accountable 説明責任者。タスクについて説明責任と完了などの承認責任を有する。小さいタスクでは実行責任者と兼任することも多い。
- Consulted 相談者。タスクを進めるときに相談を受ける。その分野の専門家などが担当する（例えば、採用情報ページ作成タスクにおける、人事部など）。
- Informed 報告先（PMBOK第7版だと情報提供者と真逆の訳）。タスクの進捗状況などを1方向の情報提供を行う先。スポンサーや外部のステークホルダーなど。
に分類されます。「担当者」は実行責任者に該当しますね。ということで、まずは、「説明責任者」「相談者」「報告先」を作成することにします。
Redmine メインメニューから、「管理」を開き、カスタムフィールドを開きます。
カスタムフィールド画面右上の、「新しいカスタムフィールド」リンクをクリックします。
どのオブジェクト（ファイルのジャンルのようなものと考えてください）にカスタムフィールドを追加するか訪ねられるので、タスクに相当する「チケット」を選択し、次へボタンをクリックします。
人を入力対象としますので、形式を「ユーザー」。
名称は
- 説明責任者
- 相談先
- 報告先
を作成します。
また、大体全てのプロジェクトで使用するはずなので、右下にある「全プロジェクト向け」にチェックします。
作成は「作成」ボタンでもいいですが、今回のように複数のオブジェクトを一気に作りたいときは、「連続作成」が便利です。
チケット作成などでも活用でき、作成後の画面遷移が同じオブジェクトの作成となり、一部を除いて入力フィールドが消去されるので、その名の通り連続してオブジェクトを作成しやすくなります。
RACI チャートでは、タスクとステークホルダーが交わる場所に、それぞれ責任を示す R, A, C, I の文字が入ります。これにより、それぞれの責任者を複数設定できたり（説明責任者は責任を明確にするために一人）、一覧して責任者が見られたりします。
これを実現するためには、（プラグインを使う以外は）プロジェクトごとにステークホルダーの名前でカスタムフィールドを作り、そこにR, A, C, Iを入力する方法があります。
ただし、毎回やるのはちょっと面倒なのと、デジタルであればフィルター（Redmineのカスタムクエリ）で自分の担当範囲を確認可能ですし、複数の担当については子チケットに分割する方法が考えられるため、今回は簡単にこの方法にしています。
今度こそ トラッカーを追加する
「機能」を「タスク」「作業」にするなど、色々あると思いますが、今回は新規トラッカーを作ります。
まずは、 Redmine全体 の「管理」を開きます。
トラッカーをクリックし、トラッカーの管理画面を開きます。プロジェクトごとに使用するトラッカーを選択できるので、「システム開発」と「Web 制作」、「コンサルティング」で必要なトラッカーを作るといったことができます。とはいえ、 Redmine ではトラッカーはカテゴリーではないとしているので、この記事では抽象度を上げて、 WBS, PDM, タスクという段階で作ってみます。
まずは、WBS トラッカーを作って見ます。
標準で用意されているトラッカーがあります。邪魔であれば削除してもいいですが、今回は参考にするため、残しておきます。プロジェクト単位で使用するトラッカーを選択できるので、そこまで邪魔になりません。2. の新しいトラッカーをクリックします。
名称を WBSとし、標準フィールドを「カテゴリ、開始日、期日、説明」のみにします。カスタムフィールドの RACI チャートは、すべてチェックを外していいでしょう（画像はチェックがついてしまっていますが）。ワークフローもコピーせずに新規に作成します。
「対象バージョン」は、 Redmine 上ではマイルストーンのように使われるらしいので悩ましいですが、 WBS のように大きなアクティビティの単位では、ある意味ではこの期日がマイルストーンと言えるので外してしまっています。問題ありそうなら、編集で追加すればいいでしょう。
続いて、 PDM を作成します。個別の細かなタスクをまとめる役割と、アクティビティの順序を整理するために使う予定なので、フィールドは全て入れます。ワークフローは、標準の機能から追加します。
最後に、個別のタスクのトラッカーを作ります。
ここでは、とても「小さい」タスクを扱う予定なので、予定工数・進捗率は省きました。開始していたら50%、という扱いです。
また、 RACI チャートを再現するフィールドのうち、使用するのは担当者と相談先のみにしました。小さいタスクなので、実行責任者と説明責任者は同一とし、他に専門家（例えば開発チーム外の専門家など）がいることを考慮して相談先は残しました。報告先は、 PDM レベルの親チケットのオーナーか、その報告先となるのが通常でしょう。
ワークフローは、標準の「機能」からコピーします。
ユーザーを追加する
Redmine を使用するユーザーを追加します。
「管理」を開いて、一覧から「ユーザー」をクリックします。
メインパネルの右上から「新しいユーザー」リンクをクリックして、新規ユーザーの追加画面を開きます。
以下は、 Redmine インストール直後の Admin アカウントと同様の手順となります。
*がついた必須項目を入力し、パスワードを設定すれば問題ありません。次回ログイン時にパスワードの変更を強制しない場合は、パスワードはパスワードマネージャーなどで共有するといいでしょう。
今回は、他のユーザーにはログインさせず、管理のためだけに追加するので適当です。ただその場合でも、メールアドレスの重複は許可されないので、実際にログインしない場合は適当なダミーメールアドレスを作成するか、gmailなどを活用するといいでしょう。
今回は、Admin アカウントの他に、営業アカウントと、デザイナーアカウントを作成してチケットの担当として割り当てられるようにしています。
プロジェクトの作成
お待たせしました、やっと、プロジェクトの作成です。
Redmine のメインメニューから「プロジェクト」を選択し、更に「プロジェクト」タブ内の右上にある「新しいプロジェクト」のリンクをクリックします（そろそろ、 Redmine の UIの法則にも慣れて来ましたね）。
タブを見てもらうと分かる様に、プロジェクトの他、「チケット（他ツールでいうタスクとほぼ同義）」「ガントチャート」「カレンダー」などがあります。これらは、プロジェクト横断的に状況を把握するのに使えます。
プロジェクト作成時に重要なのは、名称はもちろんですが、後から変更出来ない識別子（ID）と、「公開」プロジェクトか否かです。
識別子は名前からある程度自動で入力されますが、日本語は使用できないため、手動で分かりやすいものに設定するといいでしょう。画像では、リニューアルプロジェクトなので、本来なら web-renewal-pj などのほうがわかりやすく、管理しやすいかもしれません。
また、公開プロジェクトはメンバー以外もアクセスできてしまうので、秘匿性の高いプロジェクトでは間違えてチェックをつけないようにします。特に、匿名ユーザーが許可されている環境では注意が必要です。もちろん、 Web に向けて公開されているサーバーの場合には、通常は絶対にチェックをしないというくらいの気持ちでいいと思います（オープンなコミュニティでの開発ならともかく）。
モジュールについては逆に、特別な理由がなければすべてにチェックをいれておくといいでしょう（ソフトウェア開発がなければ、リポジトリは不要かもしれません）。
プロジェクトを作成したら、さらに設定画面にうつります。
まずは、「チケットトラッキング」タブで、先に設定したトラッカーとカスタムフィールドを割り当てます。
自分で作ったトラッカーのみにチェックをいれます。また、カスタムフィールドは作成時に「全プロジェクト向け」にチェックを入れていれば、画面のように標準でチェックが入り、外せない状態になります。
設定したら、保存して「メンバー」タブに移ります。
メンバータブでは、「新しいメンバー」リンクが左上にありますので、これをクリックして新規メンバーを追加します。メンバーに追加できるのは、作成済みの「ユーザー」を選択する必要があります（プロジェクトメンバーからいきなり作成はできない）。
最初はメンバーが誰もいないので、まずは Admin を管理者として追加します。
メンバーの追加は、追加したいユーザーと、そのロール（権限）にチェックをいれて「追加」ボタンをクリックします。ロールの異なるメンバーを一気に追加はできないので、最初に Admin を管理者ロールで追加、
続いて、デザイナーと営業を、開発者として追加します。
Redmine の標準的なロールは「管理者」、「開発者」、「報告者」ですが、おそらくこの報告者というのが、バグレポートなどを行う人だと考えられます。今回は、営業も素材獲得というチケットを進めるので、開発者ロールにしています。
チケットを追加してみよう
ではいよいよ、 PMBOK っぽくセッティングした Redmine にチケットを追加してみます。
「チケット」タブから「新しいチケット」リンクをクリックします。
最初は、最上位の WBS チケットをコンテナ代わりに作成します。正直、この規模であれば WBS は必要ないと思いますが、イメージを掴むために作成します。
設定するのは、名前と開始日・期日で充分でしょう。実際の各タスクの管理は、もう少し下の階層で行います。連続作成ボタンをクリックしてチケットを作成。更にチケットを作成します。
続いて、「トラッカー」を「PDM」にしてチケットを作成します。トップページのリニューアル作業ということで、ヒーロー画像（トップページのカバー的な大きな画像）をスライドにして作り直すというチケットを作成してみます。
今回は、 WBS チケットの子どもにしたいので、親チケットに「トップ」と入力します。すると、作成済みのチケットが検索されますので、該当するチケットを選択して入力します。上図の例でいえば、チケット ID の 74が入力されます（ID が分かっている場合、直接数字を入力しても問題ありません）。
RACI チャート風を実現するために「担当者」「説明責任者」「報告先」「相談先」も入力します。実際にはもっとユーザーとメンバーを追加して、報告先は「顧客（ダミーユーザーを使うといいでしょう）」、相談先は別プロジェクトにいる、オリジナルサイトを作った Web デザイナーなどにするといいかもしれません。
再び「連続作成」ボタンをクリックして、より細かなタスクを作って行きます。個人で作業する Web デザインであれば、このヒーロー作成だけでも充分に細かい粒度と思われるかもしれません。ただ、分解できなくもないので、例としてやってみます（どこまで分解するかは、人・プロジェクト・リーダーシップのスタイルによるでしょう）。
トラッカーをタスクとして、チケットを作成していきます。親チケットは PDM として作成した「ヒーロースライド作成」にします。
- スライド用素材調達、担当者：営業、相談先：デザイナー
- スライドスクリプト選定、担当者：自分
- スライド用画像作成、担当者：デザイナー、相談先：自分
- ヒーロー実装、担当者：自分
としてタスクチケットを作成します。
こうしてみると、スライド用素材の調達が終わっていなければ、スライド用画像が作成できないことが分かります。また、通常はモックアップやワイヤーフレームで決まっているとは思いますが、スライド用のスクリプト選定も画像の仕様に関わるのでスライド用画像作成に先行して欲しいです。
ということで、この関係を Redmine 上で実現しましょう。
まずは、「チケット」タブをクリックしてプロジェクト内のチケットの一覧を表示します。「スライド用画像作成」チケットをクリックして、チケットの詳細を表示します。
- 「関連するチケット」右側の「追加」リンクをクリックして関連するチケットの追加 UI を表示します。
- 「次のチケットに後続」を選択します。
- 「スライド用素材調達」と、「スライドスクリプト選定」を入力します。親チケットと同様、部分検索も、ID を直接入力もできます。親チケットと異なり、複数のチケットを, 区切りで入力できます。
- 先行するチケットに遅れて何日後に開始するか、を入力します。
- 「追加」ボタンで追加します。
さらに、ヒーロースライドの実装は、スクリプトの選定が済めば（仮画像などを用いて）実装を開始できますが、完成するには「スライド用画像」の完成を待つ必要があります。
この関係も実現してみます。
- 関係を「ブロック元」として「スライド用画像作成」チケットを関連するチケットに追加
- 関係を「次のチケットに後続」として、「スライドスクリプト選定」チケットを関連するチケットに追加
このように、異なる関係のチケットも一つのチケットに複数追加できるので、複雑なタスクの関係・複数人のタスクの関連性も整理できます。
最後に、ガントチャート上でどのように見えるかプレビューしたいですが、期日や工数が設定されていないとガントチャートで上手く表示されないので、適当に設定します（制約条件にに反する設定はできません）。
最後に、ガントチャートタブを開き、見やすい大きさまで「拡大」ボタンをクリックします。ソフトウェア開発用なので、結構長めのプロジェクトが想定されているので標準の拡大率ではこのように小さいプロジェクトは見えづらくなってしまいます。
最大まで拡大して見た画面がこのようになります。
青色の線で「後続」する関係が表現され、赤色の線でブロック関係が表示されています（PDM 的には、ヒーロー実装の後ろに矢印がついてほしいのですが、これはガントチャートなので判別できるということでよしとします）。
また、チケット一覧の「…」メニューからチケットのステータスを変更できますが、
「ブロック元」のチケットが終了していない場合、上図のようにステータスに終了がなく、終了させることができなくなっています。
チケットの割り方はこれでいいの？
今回は急ごしらえのサンプルだったのでこのように分けましたが、このようなウォーターフォール型のプロジェクトの場合、先にウェブサイトの仕様を決定するため、「スライドスクリプト選定」は PDM のレベルで前段階に含まれ、その PDM 自体が先行する形になるでしょう。
また、素材調達も同様で、「素材調達 PDMチケット」があり、その中に「スライド用素材調達 タスクが含まれる」といった形式になると思います（あるいは、素材をまとめてもらい、どの素材をどこに使うか決定するアクティビティが入るでしょう）。
ただ、ウェブサイトの作成もアジャイル型やハイブリッド型のプロジェクトになる傾向があります。特に、Webサイトに日頃から触れているため色々希望があるものの、制作に詳しくなくて要求仕様をなかなか固められない場合などはその傾向にあります。
その場合は、 Redmine もアジャイル開発に適した形式にする必要があるでしょう（スクラムなどに対応させるプラグインの導入・チケットの定義）。
次は？
スケジュールの定義はできましたが、実際にプロジェクトが動き出してからのマネジメント、ベースライン管理などが今の時点では期日くらいしかありません。
本来なら、アーンドバリューマネジメントなどで、プロジェクトの制約と現状の乖離を把握する必要があり、当然、 Redmine にもその機能を期待したいところです。
終わりに
PMBOK はプロジェクトマネジメントの国際的なデファクトスタンダードで、 IPA のプロジェクトマネージャー試験にも影響が強くあります。
が、あんまり PMBOK っぽく Redmine を使おうとか、プロジェクトマネジメント用のソフトウェアを使おう、みたいな発想の記事がなくとても苦労しました。もちろん、 PMBOK 自体が各フレームワーク・ツールについて推奨などを設けているわけではなく、大枠を示して、各分野で適用できる具体的な方法論をいくつか提示しているに過ぎない面があります。
なので、 PDM とか、 WBS とか、意識しないで Redmine を使っても全然構わないのでしょう。ただ、勉強中の身としてはできるだけ近づけてみて、その上で最適解を探していくのが大事かなと思います。
楽介でした。
