九州のベンチャー企業で、システム屋をやっております。「共創」「サービス」「IT」がテーマです。

アジャイリーなあなたへ

»

昨年秋から推進してきたプロジェクトが無事リリースを終え、燃え尽き症候群状態の今日この頃です。とくに、この2~3カ月が山場で、コラムの更新が全くできず心苦しい限りでした。

 また、早々に次のステップに着手しなければならないので(本当は既に始まっているとう噂もありますが……)、少し余裕があるうちに、コラムを更新しようと思います。

○当事者不在の開発プロジェクト

 このプロジェクト大きな特色は、これからできる会社の業務システムを構築する、という不思議なミッションをクリアしなければならないことでした。とある大手企業が、子会社を再編し新しい会社を作ることになったのですが、その会社の社内で使うシステムを、会社の事業開始に合わせて準備せよ、

 というミッションです。期間は約8カ月。

 我々は経理と給与を除くバックオフィス系システムのアプリケーションを担当することになりました。

 何が一番困ったかというと、そもそも、まだできていない会社のことなので、

  • 業務が何も決まっていない
  • システムを使う、当事者が分からない
  • 複数社が集まり各社がそれぞれやり方が違う

 これらが相まって、スケジューリングが非常に難しいプロジェクトでした。

 親会社のシステム担当者からは、スケジュールを詳細にしろ、課題を管理しろ等々尻を叩かれますが、例えば経理にて連係関係で新会社の経理の担当者(になるであろう人)に話を持っていっても、まだ勘定科目も決まっていないのでわからん! とけんもほろろ。

 勤務の関係で、人労の担当者(になるであろう人)に聞きにゆくと、就業規則を作っている途中で給与システムは選定中だから、と謝られ。実務担当者に話をしたいと思っても、組合との関係でまだ、内緒になっている、と何も教えてもらえず……。

 そんな状況で、どうやってスケジュールをつくれというのか! といった状況でした。

○メンバーにスケジュールを伝えない

 最初の頃は定石通り大工程をひいて、各チームに小工程を作成してもらって管理を行っていたのですが、先述の状況では特に小工程においてスケジュール通りに行くことは何ひとつなく、こちらがやらなければならないことは何もできず、それ以外のタスクがいろいろと湧いて出てくる状況で、なおかつ作成した工程が役に立たないということは、メンバーのモチベーションにも影響してしまいます。

 そこで途中から小工程の管理はやめることにしました。当然お客さまがいるので、全体のスケジュールと進捗報告は必要ですが、それはこちらがメンバーの状況を見ながら見ながら行い、各チームには中長期的な話はせず、1週間程度の作業量でタスクとして次に何やって、レビューはいついつだから、という感じで短期的な具体的なタスクと中期的なイベントを中心に開示してゆきました。

 もちろん大工程を隠しているわけではなく、大工程とお客さまに報告した内容はファイリングして誰でもいつでも見れるところに置いておきました。

 また、定期的な内部での進捗会議も行わず、毎朝一時間程度のミーティングを開催して、各人の予定と状況の確認と、次のタスクの指示を行うようにしました。

○今決まらないことは、今決めない。やれるところからやる。出戻りは覚悟の上

 プロジェクトでは自分たちで決められることと、決めれないことが存在します。自分たちで決めれないことは誰かに決めてもらわなければなりません。しかし本プロジェクトでは、

  • 自分たちで決めれないのに決めてくれる人がいない(分からない)
  • または自分たちが必要としているときには決まらない(決めてくれない)

 そんな状況の連続でした。

 しかし、これは無理をいっても仕方ありません。そういう条件下でのプロジェクトなのです。決めてくれないから、遅れた。は理由にならないのです。 だから逆に、

  • 今決まらないことは、決まらないこととして受け入れる
  • その代わり、自分たちで決められることは時間をかけずに決める
  • 加えて、やれることはさっさとやる
  • そして仮に間違っていても、やり直せる余力を持つ

 ということをチームの共通認識としてプロジェクトを推進してゆきました。

○メンバーからのトラブル報告はあてにしない

 それでもプロジェクトが進んでいくと、様々なトラブルが出てきます。よく、問題は早めに報告せよ、とお達しがでますが、ほとんどのトラブルの火種は、炎が上がってからでないと顕在化しないものです。

 トラブルの火種は、以下の3つのパターンがあると感じます。

  1. 火種ができると、即、引火し激しく燃えるパターン
  2. 火種ができると、くすぶり続け煙がでるものの炎は上がらずいつの間にか炭になっているパターン
  3. 火種はないが、部屋中にガスが充満し、何らかのきっかけで大爆発するパターン

 例えば今回も終盤近く追い込みの状況で、 ソース管理サーバがお亡くなりになる、といったトラブルなどが発生しました。

 皆、すぐに大騒ぎになりますが、復旧手順は明確なのですぐに鎮静化することができます。この様に一見派手で分かりやすいトラブルは、実のところ余り心配することがなく、粛々と消火活動を行えば意外と早く鎮火することができるのです。これはパターン1の典型ですね。

 パターン2の例としては、メンバーの1人が報告時には特に問題ないと言っていたのですが段々顔色がわるくなり、休みも多くなり、やがて戦線離脱することになり、その段階で成果物を見てみると、実は何もできていなかった、というトラブルがありました。こちらは代わりの人間を探したり、引き継ぎしたりと大変でしたが、戦線離脱が決まった本人は一気に元気になり、笑顔で去って行った、というトラブルがありました。

 プスプスと内部で燃え続け時間が経ちすぎると全てが炭になってしまう典型です。しかし、このパターンも何とかなく本人を見ていると、何らかの兆候(煙)は出ているもので、判断を

間違わない限り意外と被害が少ない段階で消化することができます。

 そして、一番やっかいで怖いのがパターン3でしょう。今回は、1つのチームが全然間違った方向へ開発を進めていた、というトラブルがありました。画面やデータは増えてゆくのですが、システム全体としては全体的な思想を失い、動かなくなる方向へ進んでいっていたのです(メルトダウン、と呼ぶ)。

 本人たちは間違った方向に進んでいる自覚はないので、報告時は正々堂々と、問題ありませんと心底言っていることでしょう。だから報告だけからではトラブルが起こっていると気づくことはできません。気づかないままプロジェクトは進み、最終段階でやがてそのトラブルは大爆発を起こします。

 この手のトラブルを防ぐためには、メンバーからの報告のみを当てにしていてはダメです。必ず自分の目でできているモノをみて、本当に火種はないか、ガスは充満していないか確認する必要があります。現場、現物、現人が大切なのです。
 

○結果、どうだったか

 プロジェクトの評価自体は難しい所もありますが、結果的になんとか運開を迎えられた、という点からみると、開発プロジェクトとしては合格点に達したのではないか、と思います。 

 しかしシステムの評価はこれからで、ユーザーが徐々に使い始め、最終的に満足していただけるよう、これからのフォローが大切になってきます。運用上の障害、改善要望対応、機能拡張、それらを踏まえてユーザが最終的にシステムを使って効果を出してゆけるか、それに耐えうるシステムかが今後の評価基準になってゆくことでしょう。

○今回のやり方を振り返ってみた

 今回は、プロジェクト管理としてはかなり特殊なやり方になったのではないかと思います。

 一方で、これこそが、「まさにアジャイル」と言ってよいのではないかとも思っています。

 動くものを信じ、イテレーションを回しながらスパイラルアップさせてゆく、というのはアジャイルの原則論に則っていると思います。

 ただし今回の合格点は、ただ単に運が良かったのか、それともアジャイルの方法論をとっから合格点をとれたのか、他のやり方だともっとうまくいったのか、それはわかりません(歴史に"もしも"がないのと同じく、プロジェクトの評価は比較できません)。

 そこで、今回のプロジェクトを少し離れていて見ていた方の評価も少し紹介しておきます。

  • 見ていてハラハラした。ゴールにたどり着けたのは綱渡りだ
  • メンバーの中には全体を見渡せず、次に何をすればよいのか分からずフラストレーションを感じているの者もいるのではないか
  • なんだかいろいろあったけど、悲壮感とか焦燥感とかなく、楽しそうにやってたね

○そして、アジャイリーなあなたへ

 今回のプロジェクトは少し種明かしをすると、苦労するのは分かっているが勝算はあって始めた、というのが正直なところです。会社は新しいですが、親会社の業務システムには

 長年携わってきたこと。新しい会社の同規模、同業種のシステムは何度か開発経験があり、ベースを持っていたこと。

 アーキテクチャに関して全て見渡せ、大概のトラブルには対応できるハイレベルな開発メンバーがいたこと。が挙げられます。それでもプロジェクトとしては、短納期かつ、何も決まらない、分からない、という混沌とした世界でのマネジメントを強いられる難易度の高いプロジェクトだったのではないかと思います。

 そしてこのような条件下では、モノづくりとマネージメントが融合した、アジャイルというやり方は有益で、今回のプロジェクトがその成功事例の片端にでも乗っかればうれしい限りです。

 そして最後の評価、

 なんだかいろいろあったけど、悲壮感とか焦燥感とかなく、楽しそうにやってたね

 これが一番の褒め言葉のように感じます。

 しかしこのやり方は絶対に、ツボにはまる人と拒絶反応を起こす人の両極端に分かれてしまいます。ツボにはまれば楽しいプロジェクトになりますが、拒絶班を起こせば地獄を見ることは間違いありません。きっと、毒にも薬にもなるやり方なのです。

 どうでしょう。今回、簡単ではありますが事例を紹介してみました。これを読んでもし、”楽しそうだ” と思えたならば、一度試してみては。

Comment(0)

コメント

コメントを投稿する