タグ別アーカイブ: おすすめ

1技術者からマネージメントへ, 5プロジェクトマネージメント技術, プロジェクトマネージメント

例：バグを隠しているのではないか

コメントをどうぞ

大昔の話。
毎週進捗会議をして、各サブシステムから進捗をヒアリングします。シンプルな書式で、工程ごとに進捗率の目標と実績を報告してもらうものです。

各サブシステムごとに進んでいたり、遅れていたりするのですが、おおむねスケジュール通りに進んでいました。遅れているサブシステムは監視対象になって細かく進捗を見られます。それこそねほりはほり。

そんなこんなでサービスインを控え、ユーザ総合試験をすることになりプログラムを動かしてみようということになったのですが、あるサブシステムだけが何やら見てもらいたくなさそうです。説得して見せてもらったのですが、プログラムが動きません。それどころか、プログラムが完成していません。進捗上は内部の総合試験をほぼ終わっていて、動きそうです。どうしたことでしょう・・・実は報告者が、実態を見ておらず、期日に合わせて数字だけ更新した資料を毎週提出していたのでした。

虚偽報告です。ＰＭとしてはこれをされてしまうと手の打ちようがありません、さすがに嘘をつかれた場合には・・・
「運が悪かった！」のでしょうか？

解：発見できるか？
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

1技術者からマネージメントへ, プロジェクトマネージメント

例：必死のバグつぶし、バグは直っていくが・・・1/2

コメントをどうぞ

サービスイン真近のプロジェクトがあり総合試験も後半なのですが、バグが多くスケジュールに影響が出そうです。WEBをUIとしたDBのトランザクションシステムです。表示のための計算や表示のさせ方の複雑さはあります。高度に正規化されて、複数のテーブルを統合しないとデータを表示できません。投入履歴をスライスする感じでデータの反映時間をベースとしたリビジョンが作られ、どの段階でも検索により取り出せるように求められています。このようなシステムと仮定します。

ここでPMは判断を迫られます。スケジュール遅延をお客様に話して、SINを遅らせることを交渉するか、内部で無理してでも間に合わせる努力を最後までするか。

通常はスケジュール遅延をお客様に報告しつつ、最大限の努力をしている旨ご理解いただき、最悪、SIN日程が守れないことを報告します。本当にSINに間に合わないことがほぼ確実になった段階では、正直にそのようにいうしかないのですが、精神論で頑張ってしまった場合、お客様がSIN遅延の覚悟ができていないことがあります。

遅く報告した場合、次期によってお客様内部や外部への（接続関係や既存システムの停止撤去の工事日程、既存システムがリース契約であった場合リース延長手続きが間に合うか、延長のための費用が確保できるか？サービス開始を期待しているお客様へのプレスリリースの手配、損害賠償への準備など）様々な調整が間に合わなくなり多大な迷惑をおかけすることがあります。

この判断をするに当たって、この例では始末が悪いことに、「ものができていて、品質が悪いだけ、バグをつぶせれば大丈夫、」かのように見えることです。

すでに大量の人員を投入し、テストチームと開発チームに分かれていて、開発チームはサブシステムごとに方端からバグをつぶしていきます。チームリーダはPMのしんなりする人で構成されており、幾多の修羅場(大量のバグつぶし)をくぐってきた人たちです。

マネージメント層はバグの収束曲線を見ます。

バグの不収束曲線

バグは日々たくさん出るが直る数も多く、頑張ればバグはなくなるように見えます。ここでほんの少しSINを遅らせるだけで収束するように見えます。

「あと二週間徹夜すれば！！」本当にそうか？
続く・・・

実話かはノーコメントです

1技術者からマネージメントへ, プロジェクトマネージメント

PM：プログラミングと同じでセンスが必要

コメントをどうぞ

プログラマー経験があるとわかりますが、プログラミングってズバリセンスですよね。
センスが良ければ時間をかけずにそこそこのコードが書けるようになります。経験を積むと、人に迷惑をかけないソースが書けるようになって、さらに経験を積むと人のソースをみて、相手の考えていることがわかるようになりますよね。
PMも同じです。かなりセンスが要求されます。同じように経験を積むことでいろいろな管理方法論が確立されていって、怪しいところが犬のように臭いでわかるようになります。

いろんなPJをいろんな立場で経験していると、「その時どう考えていたかな？」「こういうことはありがちだな」などと思ったところは必ず記憶しておいて役に立てます。PG経験があるとPGの気持ちや落とし穴をよく知っていますから、管理するときでも「実はこういうことなのではないか？」という話ができてPJの真のもん亜ぢ店を明らかにして対策を打ったり、課題管理においても「この問題の解決策としてはこんなことがある」あるいは「この観点で調べるといいかも」などとアドバイスができたりします。(問題解決自体はマネージメントの仕事ではないのですが・・・)

たたき上げの嗅覚で対策した例を示します。
良い例かどうかはあれなんですが・・・

①必死のバグつぶし、バグは直っていくが・・・
②データの受け渡しの無駄
③バグを隠しているのではないか

これらについて述べていきます。
例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

チームリーダー, プロジェクトマネージメント, 開発工数見積

開発見積もり

コメントをどうぞ

見積もりは重要な仕事の一つです。これはすべての計画に関わる問題になりますので正確にできる必要があります。
かかった工数だけあとから清算してよいという契約であれば、無駄がないことを証明するだけでよいのですが、通常は実現する機能に対して見積もりを行い、その金額がいくらになるかを提示したうえでその金額で契約となります。見積もりに誤りがあったとしても、お客様の責任でない限り費用の増加は認められません。
ここでいうチームリーダに求められる見積もりは「作業工数見積」です。見積もりには物の原価・管理費・リスク費・作業工数・経費・運用工数・機能外作業・外部委託作業などを積み上げた原価積算による原価見積などもありますが、ＰＭになる段階で学べばよいでしょう。まずは工数見積もりです。工数見積もりには大体、開発見積もりと構築作業見積もりがあります。(ほかにも管理や運用がありますがそれは別途)
工数見積もりの場合「まーこのくらいだろう！」という感じで見積もることも多いと思います。最終的にはそれでいいのかもしれませんが、だめです。
チームリーダとしての見積もりは、実現する機能単位の詳細な積み上げによる見積もりになります。個別見積もりの積み上げですね。
前提条件として、何を作るかわかっていることが必要です。ここに関してはお客様業務をわかっていること、お客様の言葉が理解できること、仕様の行間が読めることが重要です。これらができて初めて見積もることができます。「そんなこと言ったら初めての案件は何も取れないじゃないか！」とおっしゃるかもしれませんが、わからない案件はとらないでください。お互いに不幸になります。
業界の人をＰＪに入れるとか、類似システムを作ってきた人で構成するなどできないのであればやめるべきです。と！このレベルはマネージャレベルのはなしでしたね。(その案件をとるかの営業戦略だからです。)

開発見積もり手法を紹介していきます。どこぞのマネージメント本やコンサルの言うかっこいい書き方ではありません。
実態としてどう見積もるのかを書いています。わかりにくかったら解説しますので詳細は質問してください。こうあるべきだというあるべき論はあまり書かれていないのであしからず。(個人の見解です)

開発工数見積もり手法
(イ)規模生産性からの見積もり
(ロ)機能分割による見積もり
(ハ)類似類推による見積もり
(ニ)ＦＰ法
(ホ)相見積
(ヘ)タスク積みあげによる見積もり

その他見積もりをするうえで考慮すべきこと
スキルレベルの考慮
スケジュール
リスク
見積もり検証

について述べていきます。例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。

4リーダーシップ, プロジェクトマネージメント

リーダーシップとは

コメントをどうぞ

プロジェクトマネージャーはプログラマーと違いたくさんの人を導いていかなければならないことがわかりました。その能力が「リーダーシップ？？」です。

社員教育を重視している組織では管理職になるとき、リーダシップが重視され、リーダーシップ関連の教育等を受けることがあります。リーダーシップとはなんでしょう？必要なのでしょうか？
プロジェクトマネージャなどのハウツーではこのリーダーシップに重点が置かれていたり、管理職試験ではリーダーシップがあるかを見られたりします。
正直わかりません。
と思った人は、いい機会ですからここでリーダーシップについて考えてみましょう。

自分が部下であった時にどういう上司がよかったか？どうしてくれるのが理想だったか。を思い返してみてください。

どれが正しいというのはあまりない気がします。どのリーダでも成功するし失敗します。自分にあったリーダー像(自分の理想とする、ではない)を作りそこを目指して何が自分に足りないか、どうしたら足りないところがカバーできるかを考えます。

リーダーシップの色々

今回は３タイプを紹介しますが、日々リーダーシップに関する書籍や考え方などが発表されたりしてこの類型に当てはまるものばかりではありません。
いろいろ情報を集めて、自分のリーダー像を作り上げてください。
悪い例を入れてますが、これは、管理手法として似ているが非なる管理をした場合の弊害を示しています。どの管理手法も適切に行えばよい結果を生みます。
どれがよい悪いを言っているものではありません。それぞれのマネージメントスタイルです。

１リーダーシップのいろいろ
①こうしろあーしろ型
②みんなでやろう型
③見守るからやってみなさい型
④強引にぐいぐい引っ張る型

リーダーシップのあり方として
２責任をぷことは、任せきることではない

リーダに必要な行動として
３要員の意識を管理する

PJだけでなく自分も管理しなければなりません
４自己管理

例によって、気ままに書きますので
順番の前後等あります、気長にお待ちください。

チームリーダー, プロジェクトマネージメント

技術力

コメントをどうぞ

ここでいう技術力はIT技術力を指します。
チームリーダを任されるためには技術力が必須です。プログラマとして技術力がなければプログラマのリーダを任せてみようとは思わないからです。
プログラマーの技術は表現するのが難しいですが、

開発エンジニアですと
・要件を理解して設計をすることができる
・バグの少ない品質の良いプログラミングができる
・バグがあった時に他人が作ったところでも解析を行って原因の特定修正ができる

基盤エンジニアですと
・要件を理解してサーバあるいは機能の設計をすることができる
・特定の製品に詳しく、それを利用した機能の構築ができる

というレベルになろうかと思います。
単に指示に従ってできるというだけではだめでその一歩だけ先のものが求められます。
指導できる技術力です。

技術の優れている人は信頼されますから上に行きますが、大抵の場合、それらの技術力を身に着けるのはこの段階です。
偉くなってしまうと細かい知識が不要になったり、ノウハウ的なところを人に任せてしまうということも多いです。本当の技術力を身に着けるのはしーむリーダの時期と理解して技術力を磨きましょう。

ここでは
①ＳＩ技術
②開発技術
③システム基盤技術
④運用技術
について述べます

例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。