以前経験したプロジェクトマネジメントを通して学んだことがいろいろあるのでふりかえっておくとよい財産になるなぁと思いここにまとめる。プロジェクトはメンバー6人で9ヵ月ほど。既存サービスの作り替え。プロダクトオーナーが大まかな方向性を決めて僕は1から10を作ることを任された。それまでなんちゃってアジャイルだったので本格的にアジャイルを取り入れるのが目標。■Keep:良かったこと『スプリント導入』1週間のスプリントを導入。プロダクトオーナーの気が変わるサイクルに合わせると1週間がちょうど良かった。週初めにスプリントミーティングを行いメンバーと今週のやるべきことについて意識を合わせる。同時に週初めに次のスプリントの計画ミーティングを行う。計画立てから実装完了までは2週間。顧客チームと開発チームとで1週間ずれてサイクルが回る。リリースを行う週はテスト/改善用に確保。『スタンドアップミーティング』スプリントミーティングだけだと日々発生するちょっとした情報共有がうまくいかないので途中から毎朝スタンドアップミーティングを採用。汎用的なクラスやメソッドの共有、個々が抱えている問題の相談、本日のタスクの整理など。最初ウォーターフォールを中途半端に取り入れたため要件が膨らみ過ぎて進捗が遅れがちになる。それを解決するために優先順位を意識するようになる。ミニマム/マスト/ベターで優先順位付けすることをチームの文化とした。ミニマムでサクッと作って顧客チームと調整しながらスプリント内にマストなものを実装。余裕があればベターも取り入れる、余裕がなければベターはやらない。早い段階で最低限のものが出来ているので進捗に遅れが発生することが減る。『マネジメント業務を顧客チームリーダーにいくつか委譲』マネジメントをしながらプログラミングもしていたので僕の負荷が上がってきた。無理と思たのですべてを自分で管理するのをやめ管理業務を冗長化するようにした。要件の調整などは顧客チームリーダーに委ねた。丸投げではなく概要レベルでは把握しておくが詳細は完全に委ねた。負荷分散だけでなく脱属人化にもなった。上記のとおり僕の負荷が上がってきて個々のメンバーの面倒も見れなくなってきた。そこでメンバー個々のタスク管理はメンバー自身で行うようにした。スプリント内にやるべきことができていればそれでいいわけで。悪く言えば丸投げなのだがそれがかえって個々の主体性を産んだ。実装者と顧客チームとのコミュニケーションが密になった。顧客チームとは顧客の立場で考え行動する要件定義者やテスターのこと。タスクをメンバーに丸投げするようになってから開発チームと顧客チームのコミュニケーションが密になり放っておいても回るようになった。これによってマネージャーとしての僕は細かいことを気にせず全体の流れを見ながら注力すべきことに注力できるようになった。最初は既存サービスのメジャーバージョンアップということもあり「今までやりたくてもできなかったことを実現しよう」という気持ちが強かった。したアイデアも要件定義しておくと後々役立つと考えやってみたいことを全部詰め込んだ。今思えばいくつかのアイデアはパーキングロッドしておくべきだった。慣れない内からすべてアジャイルにすると良くないと考え中途半端にウォーターフォールを取り入れ最初は要件定義をしっかり作っていた。まで要件として定義した。繰り返し改善していくことでどんどん変わっていく。いう不確実なものに時間をかけるのはもったいないし早い段階で詳細や設計を詰めてしまうとそれらに囚われてしまい柔軟性を失う。最初はワードで要件定義書を作ってチケットでタスク管理するという方針だったが要件定義書の更新が滞ってしまいズレが生じてきた。ワードの要件定義書を捨てチケットですべてを管理するよう方向転換。チケットの運用ルールをしっかりしておけばチケットで“今”の仕様の確認やこれまでの経緯の確認などできる。チケット管理ツールはドキュメントとしても使える。要件も肥大化し具体的なゴールを設定しなかったため、いつまでにどこまでやるのか?どこまでやればローンチできるのか?が曖昧に。ローンチ基準とスコープ管理が出来ていなかった。そのため後回しでいいものに時間を取られたりやらなくていいことをやってしまったなど多くの無駄が生じた。ローンチ基準を設定しておくとスコープが管理でき無駄を省いてスケジュール通りに進めれたはず。ローンチ基準とスコープ管理を取り入れた後半はうまく進捗したが、肥大化した要件に優先順位を定義してスコープを設定していく作業のコストは大きかった。実装もそうだが要件定義から小さく始めるべき。優先順位を意識して優先すべきものから作る。「あった方がいい」は必要ない。「あるべき」ことのみ必要である。要件定義書のようなものからじゃなくユーザーストーリーくらい曖昧な要件から開発開始したい。細かい仕様よりもユーザーが何をしたいのかが重要。ユーザーストーリーをチケットとして登録し実装を進めながらチケットに仕様を記載していく。チケットの説明欄に現時点での仕様をまとめておくとそれが仕様書となる。チケット管理をタスクの管理ではなくユーザーストーリーの管理として使い仕様を管理したい。的なものを用意したい。いうのも、エンジニア間での情報共有は各ミーティングで行っていたが、後から参画してきたエンジニアと共有できない。削ることの難しさを痛感。膨らんだものから取捨選択するより最初から小さくしておいた方が楽。常に必要最低限を考えることでコストはかなり抑えられる。アジャイルをメンバーに浸透させるのに結構手間取った。与えられた要件で実装するのではなく顧客チームと一緒に自分で考えながら実装することに最初は戸惑っていた。慣れたらなんてことはないんだけど。あと、アジャイルはメンバーにある程度の力量が求められる。「全員がシステムエンジニアでなければならない」「全員が判断できなければならない」「全員が主体的でなければならない」ひとりでもこれらからブレるとそこが足を引っ張る。とりあげることでもないけど、マニュアルの自動生成システム構築に失敗。要件定義書から自動でマニュアルを生成できればいいなと思っていたけど要件定義書が肥大化によって破綻。今はチケットに現在の仕様を記載する箇所を設けておけばそれで十分だと思ってる。取り消しコマンドいろいろ[PHP]PHPExcelとLibreOfficeでPDF作成がかなり良いアジャイルと5SかわのくんとはWeb系IT企業でプログラミングやマネジメントをしています。kawanotron.。