無料ブログはココログ

« 2015年8月 | トップページ | 2015年10月 »

意外と難しい進捗報告 - 進捗報告で気をつける事 -

進捗報告とはその名前のとおり進捗を報告することです。しかし、お客様や上長に報告する際は、朝会などの日々のミーティングで報告する内容(やったこと、やること、課題)とは異なります。

アジャイル開発における朝会は日々の作業のコミットしても、イテレーションのスコープの達成にはコミットしません(タイムボックスが終わればそこまでしかしない)。
#プロダクトオーナーの方に同じような苦労が集中するのでしょう。

しかし、従来型の開発では全体のスコープと納期にコミットしているので、その実現に向けての対策を説明しないといけません。また、進捗報告をきっかけに上長や顧客、関連組織は、問題の解決に向けてそれぞれの権限を行使しようとしますので、適切な報告が求められます。

進捗報告では(必要なら全体の中の現在の作業の位置づけを簡潔に説明したあと)、作業の状況(遅れ進み)とその理由を説明します。遅れていればそのリカバリ策とリカバリの見込みを説明します。

その際には、以下のような点に注意した方が良いでしょう。

必要以上に不安を与えない

課題の共有をする場合は、それが自分たちで解決できるか、それとも誰かの助けが必要なのかを明確にします。自分たちで解決できる事に上長や顧客が関与し出すと作業が遅れてしまいますのでお互いにメリットがありません。

逆に助けが必要な際は、手遅れにならない様に早めに連絡します。上長に掛け合ってもらいたいのに、出張に行ってしまってタイミングを逃すなんてことの無い様にします。対応の必要性が見えてきた状況で説明しておくと、相手もその準備ができるでしょう。

必要以上に不安を与えたり、手当が遅れない様にするには、状況説明の際にその理由をきちんと説明すると良いでしょう。

例えば、増員が2週間遅れたものが1週間の遅延までに取り戻したものを、単に「1週間の遅れ」と言うと不安をあおってしまいますが、「2週間の遅れを半分取り戻した。今月中にはリカバリできます」と言えば、不安はあまりないでしょう。

見積もりミスと思われない

予定よりも進捗が進んでいるからと、お客様に自慢げに話すのもよくありません。当初の見積もりに対してお客様は費用を払っているからです。きちんと説明する必要があります。

これから問題になりそうなリスクがあって、残業して少しでも前倒しにしようとしているなら、そのように説明すれば良いでしょう。本当に見積もりミスならお詫びするしかないですが、間違った理由は説明すべきです。

責任をなすり付けられない

複数チームで開発する際にありがちなのが、責任をなすり付けられることです。特にライバル会社がいる場合は、相手を出し抜こうとチョットした事でもとんでもない事の様に言われる事があります。

負けずに言い争っても何も解決しませんので、謝るべきは誤ってゴールに向けてどうすべきかを話します。責任を押し付けるようなチームは大抵は問題を隠していますので、結合時期を遅らせる等の譲歩を求めると意外と合意してくれるものです。

相手によって表現を工夫する

同じ状況でも相手によっては表現を工夫した方が良い場合もあります。長期的な視点からアピールする事も必要ですし、予算措置が必要になるなら早めに言った方が良いでしょう。

危機感をあおりすぎてもいけませんが、リスクは共有しないといけません。相手の立場や個性にあわせて、表現の工夫は必要です。初めてのお客様なら、周りの人の話し方を参考にすると良いでしょう。

嘘をついてはいけない

そのような場合でも守らないと行けないのは、嘘をつかない事です。一度、嘘をついてしまうと、状況が変わらない限り嘘に嘘を重ねることになります。

見積もりが甘かったのに嘘をついて残業以外の対策をとらないなら、いずれ破綻します。自分で解決できない問題は早めにデシジョンして、対策を取らないといけません。

多くの対策には調整が必要で、時間がかかるものが多いです。追加予算には稟議が必要かも知れませんし、仕様の削減ならステークホルダーに納得してもらわないといけません。タイミングを逃さず報告すべきです。

相手に合わせて表現を工夫しても、嘘をついてはいけません。

おわりに

若い人の指導を始めると色々と気になるものです。 自分ではそれほど経験値が高いと思ってなくても、それなりにあった様ですのでまとめてみました。少しでも参考になれば幸いです。

このエントリーをはてなブックマークに追加

完璧なプロジェクトなんてない

サブリーダーをやり始めた若い人に「完璧なプロジェクトなんてない」と話したら目が点になっていたので、こちらの方が驚きました。

結果的にうまくいくことはあっても、どんなプロジェクトもそれなりに苦労する事はあるものです。こうすればうまくいく、なんていう王道はなく、その時点、その時点で、ゴールに至る道のりをイメージして、順に課題を解決していくしかないと思います。

完璧を目指す?

完璧を目指すということは理想のプロジェクトがあり、それとのギャップを埋めていく事になるのでしょう。しかし、理想のメンバーが集まるとは限りませんし、理想のメンバーが揃っていても仕様が変わったり、ミドルウェアのバージョンアップ等で問題が生じる事もあるでしょう。

そもそも理想のプロジェクトの状態になったなら、力を抜いて開発するのでしょうか?それはおかしいでしょう。余裕があるなら速く完了すれば良いですし、そもそもそんな事はめったにないので、効率的な開発が求められる事がほとんどでしょう。

完璧を否定する管理法の参考になるものにCCPM(Critical Chain Project Management)があります。CCPMが従来の開発法を非効率だとするのは、計画通りの開発を実施しようと、様々なバッファを持とうとしてしまう点だとされています。

プロジェクト全体で共通のバッファを持てば十分です。その上で、なるべくバッファを使わずに済む様にリスクを低減すれば、よりプロジェクトを効率化できるでしょう。

計画的という言葉の妖しさ

計画的というと良い事の様に思えますが、必ずしもそうではありません。計画的に進める事で生じる問題もあります。

  • 達成が目標になり、状況の変化に気付きにくくなる
  • メンバーが従順になり、考えなくなる、言わなくなる
  • より多くのバッファをとろうとして、改善しなくなる

このような問題を防ぐには、完璧を目指さない事です。

  • 管理は必要最低限のものにする:標準プロセスで必須とされているものを基準に、ないと困るものだけ実施します。
  • リスクに合わせて管理方法を変える:問題になりそうなポイントを見極め、他チームとの連携を強化する、チーム内の情報共有ルールを決める、などします。
  • インフォーマルコミュニケーションが活発になるような環境を作る:お菓子を置く、食事会や飲み会を実施する、などコミュニケーションの環境を整えます。

基本的な考え方はこのようなものですが、実際にどの程度までするかは一概に言えません。状況を見ながら、規模や対象業務、メンバーによってバランスを変えてください。

完璧なプロジェクトなんてないのですから、、

このエントリーをはてなブックマークに追加


[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -

ソフトウェア品質シンポジウム(SQiP)2015の併設チュートリアルであきぴーさんと講演をしてきました。

一人当たり2時間の講演でしたので、これまでの講演のベストチョイス3本を再構成したものに、アダプタブルウォーターフォールの講演を組み合わせました。

アダプタブルウォーターフォールの講演では、問題の多いウォータフォール型開発を変化に対応できる方法として、補完型チケット駆動開発を中心にウォーターフォール型開発をアダプタブルにする3+1Ultimate Agile Stories Iteration 5に寄稿した記事に書いた内容を説明しました。

質問を受けた内容を総合すると、比較的大規模なプロジェクトに完全型チケット駆動開発を導入してみたものの、チケットを更新してくれない、管理が大変、といった問題で皆さん困られている様です。

やはりチケット駆動開発の導入はプロセスを改善する作業なのですから、管理の都合でルールを導入するのではなく、障害管理、補完型チケット駆動開発と段階的に導入を進めていき、現場がメリットを感じる形で進めていくこと、小規模な単位に分割して管理をすることが大切だと思いました。

ウォーターフォール型開発における完全型チケット駆動開発に関しては、いずれまとめたいと思います。

このエントリーをはてなブックマークに追加


続きを読む "[#TiDD]ウォーターフォール開発をアダプタブルにする(チケット駆動開発) - SQiP2015チュートリアル -" »

[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

RxTStudy #13で「Redmine再入門 〜達人に学ぶRedmineの徹底指南〜」と題して、お話をしてきました。

今回は Redmine再入門ということでしたので、チケット駆動開発でどのような点に注意すれば良いかをお話ししました。

説明会は開くべきか

パネルディスカッションでは、モデレータのあきぴーさんの質問に対する議論の形で進められました。中でも気になったのは、Redmineの導入時に説明会が必要かどうかです。

説明会が必要だとする方が多かったのですが、何のためにRedmineを導入するかによると思います。たぶん、大きなプロジェクトや組織の中にRedmineを導入するような想定なのでしょう。

この場合、Redmineに期待するのは、障害管理などの管理作業をRedmineに移行して効率化をはかると言う目的なのでしょうね。情報共有がリアルタイムになり、プロジェクトがうまくいく算段なのでしょう。

説明会の功罪

説明会を開くと知識の底上げと共通化ができます。Redmineの使い方やルールを知る事で、一定の知識を持つ事ができるほか、運用ルールを徹底する事ができます。

説明会を開くと、「こういう時はどうすれば良いですか?」と積極的な質問が出るでしょう。良い事です。

このような大人数の説明会では、質問は出ても改善案はなかなか出ないでしょう。もし出ても「こうして下さい」と共通ルールに従う事をお願いすることになるでしょう。仕方ありません。管理のための導入なのですから、、

Redmineをチーム作りに使う

Redmineには、もう一つの使い方があります。「チーム作り」です。チームで気付きを共有し、作業を共有し、同じゴールを共有して行動します。いわゆる自律的組織です。

多くの人は教えられると考えるのをやめます。その方が楽だからです。ならば、基本的なルールをWikiに書いておいて、問題のある時だけ指導してはどうでしょう。

Wikiに書かれている事を理解して、考えないと行動できませんん。なぜそのようにしているかを考えて、より良い提案が出てくるかも知れません。

管理のあり方

Redmineを管理に使うととても便利ですが、自律的なチームの可能性を押さえてしまいますし、工事進行基準では様々な問題があります([#TiDD] チケットのエクセル連携は工事進行基準と相性が悪い)。

より外乱に強いプロジェクトを実現するには、管理者は組織パターンの「門番」として外界とのインタフェースをとると良いと思います。コミュニケーションの視点でチケット駆動開発を考える事が自律的なチーム作りには重要だと思います([#TiDD] チケット駆動開発による「ソフトウェア開発の現場力向上」を終えて)。

このエントリーをはてなブックマークに追加


« 2015年8月 | トップページ | 2015年10月 »