ここ半年くらいに、社外活動で少人数でのプロジェクトみたいなのを2つ回した。時期はオーバーラップして無いし、目的みたいなのは大きく違う。片方はプロジェクトと言うよりも運営で小さな課題が五月雨的に出てくる感じ。別の方は、プロジェクト管理の要素が大。メンバーが10人~20人程度で、主メンバーが2,3人というのは似てる。自分のロールは、プロジェクトマネージャではなくて主要メンバーだけどPMOみたいな感じかな。
昔会社勤めでのプロジェクトでは、勉強会の類ではもっと大掛かりのプロジェクトマネジメントツールもあったが、自分でのツールの主はMS-Project。でも変な話だけど、実際参加した大きなプロジェクトとかでも全体での利用は無く、自分たちのサブプロジェクトを自分が作成してメンテナンス。中くらいの場合は、ソフト系は自分が主でその時も自分が率いつつMS-Projectで管理も行う感じ。
多くはMS-Projectでそれなりにうまく行ったが、規模がさらに小さい時とか、他の要因で大きくプロジェクトの見直しになる時が悩ましかった。あるいは、余り期限までに行うことが主目標ではなくて、課題管理を主とした方が良い時もあった。MS-Projectで進捗度合いを見るイナズマ線という表示があるが、その利用は減り、逆に期限が融通できるためMS-Projectでの仮期限でのワーニングが煩わしい時があった。
課題管理では、BTS(Bug Tracking System)の利用が多かった。テストチームとしての利用だったり、テストチーム構築の一部を利用させてもらったり、、、。雑談だけど、今では韓国のグループの方がBTSとしては有名。
ソフトウェア開発の流れが、次第にアジャイル手法の取入れが進んで、カンバン方式というかポストイットで進捗把握することも出てきた。キーマンらとのやり取りではポストイットでやり取りしたが、その後実行段階というかメンバー含めて一挙の時は、自分としてはMS-Projectで確かめとくケースがいくつかあった。
ある意味、課題管理とスケジュール管理を、うまくマージできれば良いのにとの思いはその頃から。社外活動でも発生して、その時も2つが悩ましい時があった。
色んなケースがあり、そもそも課題管理とスケジュール管理自体を行わずに済むこともあったが、フリーのプロジェクト管理のツールなども利用した。直近での2つが、なかなか面白かったので紹介。
【Facebook利用】
そもそも複数人で、Facebookのグループ機能を利用して色々検討してた。主な書き込みの人は少なかったが、そのアイデア良いね~とか、採用(実施へ)、却下、継続審議、、。アイデアが出て、それが却下とか採用がすぐに決まれば良いが、時間がかかったりアイデアが複数平行して検討進む事態になって、どうにかして管理しようとの思いになった。
つぶやきで意見交換、このネタは”課題管理対象にしよう”みたいな利用に適した方法。
キーは、「ハッシュタグ」と「トピックス」。ハッシュタグは、Twitterでおなじみだが、文中に”#”の後ろに文字列を続けることで、その文字列が(勝手に)タグとして識別される。なお、そのためには「 #ブログ 」のように、前後にスペースが必要である。
で、Facebookのグループでは、メニューに「トピックス」なるものがあり、グループで使用されてるハッシュタグの一覧が表示される。以下のようなハッシュタグを使うようにして、進捗等を管理した次第。(あくまで例。)
・ #ブログ掲載検討
・ #ブログ掲載完了
・ #ブログ掲載断念
・ #ブログ掲載継続検討
ハッシュタグは文中に自由に書き込める。なので、最初文中に #ブログ掲載検討 と記載したものを変更して #ブログ掲載完了 に出来るが、スレッド(書き込みコメント)の流れとしておかしくなるので、先頭スレッドで概要を述べて、その先頭スレッドでの記述を変えるようにした。
なお、Facebookの暗黙?のルールとして、書き込み内容の修正は書き込み本人のみしかできない。なので、先頭スレッドで検討中として、その人がグループ辞めたら完了などへ変更できなくなる。グループとしては起きた時に考える程度。いざとなったら、別メンバーがコピーして新しいスレッドとして議論継続。
また、スレッドは、Facebook全体が検索対象となる。トピックスでの該当スレッドをクリックするとグループ内のそのスレッド(ハッシュタグ)が検索結果に表示されるが、一般的な用語だと公開つぶやきもその結果に含まれる。なので、グループ内と分るような用語にした方が良い。本件は、FacebookではTwitterほどハッシュタグが使われておらず、後になって判明することがあるので注意、
【Trello利用】
もう一つのTrello利用は、自分だけの利用。ちょっとした社外活動でのプロジェクトに参加。自分はオーナーでもリーダーでもなくて、以前少し検討した事項に関連したので参画。少し進捗的なことが気になって、プロジェクトマネジメントの視点ならどうするかと、自分なりにケーススタディに役立つかもと思って検討してみた。端的には、昔MS-Projectを使いながら悩んだことの再来みたいな感じ。時代は流れて、アジャイルソフト開発系のツールがいっぱい出てるし、規模からいっても今さらMs-projectでもない。(そもそも個人持ちのMS-Projectは買い替えてなくて、現OSじゃ使えない、、。細部を覚えてないが、以前利用したフリーのプロジェクトマネジメントソフトも似てて断念したと思う。)
プロジェクトマネジメントの視点で考えると、キーポイントはスケジュール通りに達成できるか? 昔携わったプロジェクトとかでは、バグ管理というか対策能力を加味しながら、いくつかのチェックポイント(マイルストーン)を通過できるか、そして最終ゴールに間に合うかを検討してた。(自分の携わったのは、最終ゴールはある程度流動的なことがあり、厳密にイナズマ線辺りに一喜一憂するのは考えものの時もあったが。)
どんなツールで可視化するか悩んだ。アジャイルソフト開発系のツールが今は多く、カレンダーとか「カンバン」方式を意識したツールも多い。最初それらがしっくりこない。どうも、タスクの依存関係、あるいは2つ(以上)が依存しなくて平行に進められるのが分りにくいからと自分なりに理解した。後者は、担当者に割り振れば、カレンダー的には依存しないと分るわけだが、最初の頃に2つが無関係と図示しておく手段が欲しいという訳だ。
最初、結局自分は、MS-Projectなどのスケジュール管理ソフトでの、タスクの依存関係を記述できた方が良いとの思いだろうと気付いた。
いわばガントチャートを書けると良いとの構想。ところが、それが厄介。Webサービス系でも、出来ないことはないけど、他との連携とか話が大きくなるし有料。自分のローカルPCでとも考えたけど、それも価格やフリーのものが今やメンテナンス無し。
やはり認識が甘かった、あるいは原点に戻ってとの思いになった。スケジュール到達の必達度がさほどでもない、というかあいまい。となると、タスクの列挙の方を優先しようと、チケット管理系の(無料)サービスを利用しようと思うようになった。多少検討したが、勉強会で時々(というか最近は特に)目にすることが多かったTrelloに落ち着いた。
なおチケット管理系と表現したが、これらのツールはアジャイルソフトウェア開発でのScrumを意識していると言え、バックログ管理では優先順位で、デイリースクラムなどでは、各自が分担するチケットの終了などを見える化する。したがって、バックログなりチケットを、バックログレベルの大きな塊で並列に並べるとの発想が無い。あと、あくまでスプリント管理なので、プロジェクト管理でのマイルストーンみたいな考えが無い。マイルストーンではなくても、フェーズとか、事業部長承認、社長承認といった区切りの概念が無い。
なお、後者の類は、一般的なアジャイル関連の講演題目とかでは目にしないが、自分が参加したり視聴した講演とか会合で、それぞれのチームでの創意工夫のネタとしては多かった。人によってはそれはスクラムじゃないと言い出すかもだけど、それはチーム内で結論すれば良い話しと個人的には思ってる。
Trelloを前提にして、マイルストーンと、チケットというか作業が並列でもOKの旨を表示できないか色々考えた。一見が良さそうと、以下に。
Trelloでは”リスト”と”カード”と言う概念があり。カードがチケットに相当する。リストで、Scrum(というかカンバン)での「To Do」、「進捗中」 などを表すことになる。今回は、そのリストに、チェックポイントのものを設けて、リスト内のカードの区分として、平行にできることを明示的に示したものである。チェックポイントは文言で、並行でできる旨は、カードに画像を付けてそれなりに分るようにした。(個人的な要望としては、マイルストーンは半分幅とか点のようなリストがあれば良い、リストに区切り線みたいなのもあれば良いとか考えたが、まっ仕方なし。)
なお、図で分るようにラベルと呼ぶ色をカートに付けられる、これで平行に処理できるというのを示そうかと思ったが、担当者のために利用したり進捗度合いを示すのが良さそうと思ってやめた。なお、ラベルでの担当者よりも、本Trelloに実メンバーも参加すると、そのメンバー割り当てで行ったり、日付などを明示的に入力してより厳格/あるいは現実的に運用することができるだろうが、今回はそれが目的ではないので、止め。
キャプチャはブログ掲載のための、いわばサンプル。実際に気にしているプロジェクトの概要を入力してみると、漠然としてた問題点が具体的にわかってきた。キャプチャでは新規発行に区切りを設けてないが、実プロジェクトで想定している区切り(グループ分け)でカードを分けたり、ラベルでフェーズが分るようにやってみた。
Trello利用での注意点を。無料版では、メンバーの権限管理ができない。ワークスペースと呼ぶメンバー参画の場の、公開/非公開レベルの設定変更が誰でも行える。今回社外活動と言いながらも、間違って公開としてしまう危険性を考えると有料版が良いと考えた。ただしがあって、今回は自分の情報整理のみだったので、むしろメンバー招待を行わない方法とした。(他のツールでも大同小異で、有料版への誘導はあるわけで、商売上手。^.^; )
【まとめ】
以前の企業内での経験や、今回のFacebookとかTrelloの利用を通じて感じたことをまとめると以下辺り。
・昨今のアジャイル関連を含め、ツールが色々出ている。ただし、有料/無料を含め色々検討事項は多く、各組織体での工夫は必要な事が多い。これらツール選定や、創意工夫の改良的な適用とか発生する作業を想定しておくべきと言える。
・組織体のより上位というか管理的な部門が絡むと、ツール選択も1つの鬼門となる時がある。管理的な部門全体の場合もあるが、その管理部門からの助っ人による場合もある。助っ人の考える理想像なのか、一方的なアドバイスになってしまうケースがあり、相当な気苦労に。これはプロセス改善などの時も同様で、注意点と言える。
・上記の管理部門と関係するが、ツールの有料版利用とか、外部とのアクセスはその組織体(さらに上の会社そのもの)の方針に影響する。無料ツールでも、ネットワーク管理部門からしたら、不用意なソフトウェアインストールは認めたくない。社内サーバーを用意して構築するか、一般的なWebサービスを利用するかは大きな岐路。
昨今は社外メンバーのアクセスが前提なる頻度が高い。一時よりも雑誌などでの出現頻度は減ったものの、オフショア開発などでも検討事項だった。思い切ってVPNを利用するなども良く耳にした。そして最近は新型コロナウイルス対策の関係で、リモートワークが増えている。その一環で、正規社員以外のアクセス方法も採用できる手段が増えて来ていると思う。
各自のグループのためのツール選びと言えるが、採用を見送ったとしても、先々を見越して検討してくれる組織体の構築を提案するなどは行って良いと言える。
ジャンル的にはソフトウェア工学を学んだ人たちは、上での3つを前向きに実施したり、アドバイスできるべきと考える。