2006年02月13日

障害報告書のフォーマット

障害が起きたとき、なにが気分を重くするかっていうと、障害を顧客に伝える瞬間です。
ハードウエア不良なら自分の責任は少ないのでまだマシですが、プログラムのバグで、しかも本番機でトラブルとなると、営業や上司に押し付けて逃亡したくなります。

そうはいっても、技術的な話はSEに降ってくる宿命です。
そこで、障害報告書だけ書いて、客への押しつけちゃいましょう。 障害報告書は次の内容を書きます。

  • 概要
  • 現象
  • 原因
  • 対策
  • 経緯
■概要
障害の内容と対策を簡単に記します。顧客側の担当者は障害の詳細を知りたがりますが、上司や役員は概要だけで十分です。 そこで、概要を説明し、詳しく知りたい人には後の部分を読んでもらうようにします。
例:
2006年2月13日 22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。サーバの再起動、およびデータベースに対する同時接続数の増加を行い、当面の現象は回避。不具合を対策したモジュールの入れ替えを2月20日に行います。

■現象
障害の具体的な内容を記します。
いつ、どこで、なにが、どのようになったかを客観的に説明します。
例:
2006年2月13日 21:50より、XXXサイトへのアクセスが通常の100倍に増加。22:00-22:30の間、アクセス過多の影響でXXXサイトが無応答となりました。 XXXサイトを構成するサーバX、サーバYを調査したところ、サーバXのデータベースにアクセスするプロセスがダウンしていました。

■原因
障害の発生要因を記します。
障害の原因と現象の関連が分かるように書きます。
例:
21:50より、XXXサイトへのアクセスが通常の100倍に増加。同時接続の増加により、データベースでの同時接続アクセス数を超過。 データベースからエラーが返った時点で、エラーを想定しない処理となっていたため、サーバのプロセスがダウン(不良点)。 サーバのプロセスがダウンしたため、XXXサイト全体の処理が停止し、無応答となりました。

■対策
障害の対策を記します。
対策には暫定対策と、本対策の2種類があります。暫定対策は、とりあえず現象を回避するための対策です。回避策とも呼びます。 本体策は、障害の原因を取り除く対策です。
例:
サーバXを再起動し、関連プロセスを再起動することで、プロセスを復旧。同時にデータベースへの同時接続数を増やすことで障害の原因を暫定的に回避しました。
このままでは、アクセスが増大した場合に、全ユーザのレスポンスが悪化します。原因を対策したモジュールを2月20日に入れ替えることで本対策とします。

■経緯
障害の対応経緯を記します。
例:
2006/2/1321:50頃ユーザからのアクセスが通常時の100倍に増大。
22:00データベース接続プロセスがダウン。
22:10監視アプリケーションによりプロセスダウンを検知。御社オペレータに通知。
22:15御社オペレータより弊社に連絡。調査開始。
22:30ログ採取後、サーバXの再起動を実施。サービスを再開。
23:00データベースのログより同時接続数を超過した場合のエラー処理に問題があると判明。同時接続数の上限を変更。
2006/2/14プログラムでの障害発生箇所を確認。同様の不良がないか見直しを実施。
2006/2/20対策完了版への差し替え予定。


posted by まる at 23:34| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2006年01月17日

助け合いの精神を

プロジェクト管理なんて仕事をしてると,プログラマからいろんな相談を受けることになります。
機能要求が実装と合わないので,機能要求を実装に近くなるように調整してくれとか。実装アルゴリズムの相談に乗ってくれとか。果ては期日に間に合いそうにないので,助けてほしいとか。

アルゴリズムの相談のような,プロジェクトマネージャーの仕事じゃないと思える相談も混じっています。しかし,悲しいことに相談を断る権利はプロジェクトマネージャにはないのです。プロジェクトマネージャには仕事の範囲なんてありません。みんなの雑用係がプロジェクトマネージャーです。

その場では断れても,問題が顕在化した際に責められるのは筆者です。プロジェクトが失敗してから上司に怒られるよりは,プログラマと友好な関係を築いておいたほうが,精神的にも楽じゃないですか。ついでに貸しを一個つくれるわけですし。

プログラマの皆さんもプロジェクトマネージャが他のプログラマのことで困っていたら助けてあげましょう。きっと,プロジェクトマネージャからの信頼と,たくさんの仕事が待っていることでしょう。運がよければ給料をあげてもらえるかもしれませんよ。あ…そこ,逃げていかないで。

posted by まる at 01:24| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年12月05日

困ったときのリストアップ

プロジェクトが修羅場を極めてくると,作業がたくさん降ってくることがあります。 重大なバグの修正をしなきゃと思ってるうちに,顧客から仕様のクレームが来たり。 顧客のクレームに対応してると,部長から呼び出されて工程遅延による予算超過の説明を求められたり。 なんか,皆で自分をいじめてるんじゃないんだろうかと思いたくなる一瞬です。

こんな状態におちいると,どの作業から手をつけていいかがさっぱり分からなくなります。
あれもしなきゃ,これもしなきゃで思考がまとまらず,どの作業も中途半端になり,作業効率の低下を実感できます。
そんなときは,一回すべての作業を止めて,現在の作業をノートに書き出してみるのが意外と有効だったりします。

ノートに現在抱えてる作業と,作業の〆切,優先度,難易度をリストとして書いていきます。 リストアップが完了するころには,アタマの中も次第に整理されてきます。 なんかアタマで考えると大変な気がするんですが,リストアップするとそれほどでもないものです。 で,簡単なものはさっさと進めて作業数を減らします。 逆にリストアップすることで,〆切に間に合いそうもない作業があることも分かってきます。 〆切に間に合わないのであれば,別の人に作業を引き継ぐか,自分の時間を徹夜なり休日出勤を追加して確保するか, 〆切自体を伸ばすなり,〆切を破った際のリカバリや次の〆切を考えておきます。 混乱しながらすべての作業を並行して進めるよりは,心理的な余裕を確保できます。

リストアップした時点で,どうしようもないことが判明した場合は……。あきらめましょう。
次回はそうならないといいですね。

posted by まる at 22:34| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年11月15日

バグと品質の関係(その2)

信頼度成長曲線とはテスト項目消化数や開発日付をX軸に、不良の累積件数をY軸に関連させてグラフ化する手法です。バグ収束曲線とも呼ばれます。バグ収束曲線の名のとおり,開発初期の頃から次第に不良件数が増加していき,テスト中はグラフの傾きが最大となります。顧客に納品するころには不良が出尽くして傾きが緩やかとなります。テストが進むにつれて不良の発生確率が減少するからです。顧客環境を意識したテストを実施していれば,テスト時の不良摘出率が減少すると,顧客環境での不良発生率も減少します。
不良摘出率の減少がグラフの傾きとして可視化されることから,直感的に品質を把握しやすくなってます。

経験的な指標として信頼度成長曲線を使用するなら問題ないのですが,納品基準に信頼度成長曲線を適用されるといろいろなドラマが発生します。 納期ギリギリでテストを行っていると,ついついやっかいなテストを後回しにします。やっかいなテストというのは,境界条件であったり,正常系の条件でも一般ユーザはまず使わないような値を使用しています。そのためやっかいなテストというのは高い確率で不良を発生させてしまいます。そうなると,最後に実施するやっかいなテストのおかげで開発末期に不良が集中します。 信頼度成長曲線が開発末期になって寝るどころか,元気よく成長するのです。そのため品質が安定していないと判断されます。
やっかいなテストが終わったので品質が安定しているにも関わらず。

ここに信頼度成長曲線の問題があります。信頼度成長曲線では日程やテスト項目ごとの重みを考慮しません。そのため,現場の実感と外れた結果が出ます。このへんの定性的な事情に理解を示してくれる顧客であればいいのですが,そうでなければ顧客とバトルです。テスト項目の見直しと追加を要求されないように頑張るのが管理者の職務となります。

納期ギリギリの開発状況をどうにかしろや,とか,やっかいなテストを前倒しで実施しろや,といった意見が聞こえてきそうですがその辺は無視の方向で。

posted by まる at 08:21| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年11月08日

バグと品質の関係(その1)

バグの話題が出たので,ついでにバグと品質の関係を触れてみましょう。

ある程度の規模のプロジェクトでは,品質管理基準が決められています。 よく言われるのがキロステップあたりの摘出目標件数と,信頼度成長曲線です。

キロステップあたりの摘出目標件数というのは,キロステップあたりの不良件数と摘出目標件数を比較により品質を確認する手法です。
摘出目標件数は過去の類似プロジェクトの経験などから設定します。だいたい 10件/Ks ぐらいでしょう。
摘出目標件数よりキロステップあたりの不良件数が少ないと,不良の摘出が足りないとみなされます。テスト観点を見直し,チェックリストを増量し,摘出目標件数に届くまでテストします。
逆に摘出目標件数よりキロステップあたりの不良件数が多いと,品質に不安があるとみなされます。なぜ摘出目標件数より不良が多いかを分析し,チェックリストを増量しテストします。

たとえば,3キロステップの開発に対し,テスト工程で42件の不良を摘出したとします。
この場合のキロステップあたりの不良件数は 42(件)/3(Ks) = 14(件/Ks) です。
つまり,10件/Ksの基準よりも不良が頻発しているので,不良の原因を分析する必要があります。
コードを書いたのが初心者だからとか,GUIを用いたプログラムなので不良がでやすいとか,マルチスレッドのテストが不足しているとか,適当な理由を考えます。
対策もベテランにソースコードをレビューさせるとか,GUIまわりの遷移を網羅的にテストするとか,マルチスレッドの状態遷移と資源のロック取得状態について表にまとめてテストするとか,適当な理由を考えます。

摘出目標件数より少なくても,多くても文句を言われるのがこの方法のミソです。キロステップあたりの不良件数が多い場合は適当な理屈をつけやすいのですが,少ない場合はテストが足りないと怒られます。

現在のキロステップあたりの摘出目標件数の問題点は,全体の統計情報に頼りすぎ,個別の状況を勘案していない点にあります。

実際にあった話ですが,Aさんというスーパープログラマの不良件数は2〜3件/Ksでした。腕がいいので不良がでないのです。
ところが,摘出目標件数よりも不良件数が大幅に少ないので品質が悪いということになり,顧客よりテストの増量を要求されました。
顧客とやりあっても,摘出目標件数より少ないの一点張りでラチがあきませんでした。そこで,最終的には不良を捏造して納品しました。それから数年たちますが,Aさんの担当した箇所から不良は1件も発生していません。

逆にマルチスレッドや,GUIがからむ部分は,不良が出やすく,摘出目標件数をオーバーします。

この問題の解決策として,筆者を指導した上司は,対顧客用の摘出目標件数と,プロジェクト/個人の摘出目標件数を分離して管理していました。過去の実績などを勘案して,プロジェクトおよび個人ごとに摘出目標件数を割り振るのです。
この方法は過去の実績が必要なので,どのプロジェクトでも適用できるわけではありません。しかし,いったん適用できれば,プログラマの実感に近い数値が摘出目標件数となるので,プログラマにとっては納得しやすい数値となります。

筆者も自分がプロジェクトを管理するようになってから実施してみました。やはり,顧客をちゃんと納得させるかがカギです。顧客を納得させるためには過去の実績が必要なので,実績を蓄積して計算する必要があり,結構苦労しました。

分量が多くなったので,信頼度成長曲線の話は来週にします。

posted by まる at 06:39| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年10月25日

負担のババ抜き

小規模の開発では自社と顧客との関係は一対一ですが,中規模以上の開発では同業他社が絡んできます。
この際に重要となるのが,同業他社との関係です。

同業他社を味方につけて顧客の無茶な要求を断ったり,面倒なところを他社におしつけるのです。
例えば,ショッピングサイトなどのWebとDBを使用したシステムにおいて,Web側のプレゼンテーション層を自社であるA社が,DB側のビジネスロジック層をB社が受注したとします。

当初の顧客の要望は買い物カゴに入れる商品は一度に1点まででした。
コーディング・テストと進め,開発も終盤にさしかかったところ,顧客の一言がプロジェクトに火をつけました。
「うーん。やっぱりまとめ買いできたほうがいいね。」

凍りつく担当者。
複数の商品を買い物カゴに入れる機能は,当初の顧客からのヒアリングにより実装しない方針で進めてきました。
ここで取れるコマンドは3つ。さあ,どうする。

  1. たたかう
  2. かわす
  3. たてにする

1の「たたかう」は顧客と戦い,仕様変更そのものをナシにしてもらうか,値増しと開発期間増加を認めてもらいます。
2の「かわす」は修正工数の少ない別の方法を提示します。これが選択できればベストですが,選択できない場面の方が多いでしょう。
3の「たてにする」はB社に仕事をおしつけて自分は逃亡します。

A社,B社,顧客という3者が,負担という名のジョーカーをめぐってババ抜きをするわけです。
ババ抜きに負けた会社が負担をかぶります。

このような局面では,B社の出方を観察するのが賢明でしょう。
JavaScript等を用いてWeb側で複数点の商品を買いものカゴに入れる手段を,B社が提案する危険性があるからです。
この仕様であればDB側は一度に1点のままなので,B社に被害はありません。そうなると,顧客とB社の双方を相手に戦うことになります。このままではピンチです。なんとかB社と連携して「たたかう」を選びたいところです。
B社にしてもA社がDB側の問題と主張して,A社と顧客の双方と戦うのを警戒しているハズです。
そこで,B社と協力して顧客と戦えればベストなんですが,競合他社はライバルなので,相手の失点にしようとして責任のなすりつけあいをすることになりがちです。 そうならないのがベストなんですが…。

posted by まる at 00:28| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年10月03日

こわ〜いソースの著作権

最近はオープンソースなアプリケーションであふれています。あのシステムはLAMP(Linux/Apache/MySQL/Perl)で組まれたという話を聞く機会も増えました。
営業の視点から見れば,オープンソースなアプリケーションにより安価な提案をできるというメリットがあります。
しかし,プログラム開発に視点を転じると目を覆いたくなるようなお寒い状況です。

よくあるのが,別の顧客に納品したソースを使いまわしている例。
次に多いのが,Webで公開されているサンプルソースをプログラムに組み込んでいる例。
最後に,ライセンスを意識せずにライブラリを製品に組み込む例です。

どの例も全くのNGではありません。別の顧客に納品したソースの場合は,そのソースに対する著作財産権を放棄しない契約を結んでいれば問題ありません。Webで公開されているサンプルソースもサイト管理者から使用許諾をもらえばいいだけですし,ライセンスのあるライブラリは,ライセンスを遵守すればよいのです。

問題なのは,手続きを全く意識していない人がたくさんいるという現実です。これが顧客にバレると,該当ソースの除去ですめばよいほうで,最悪は契約解除のうえ出入り禁止というペナルティが待っています。一般の人に販売する製品でGPL違反が発覚した場合などは,会社のイメージダウンは避けられません。

自分のためにも法律は守りましょう。

posted by まる at 20:51| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年09月26日

テスト観点のレビューを

納品の時期がやってまいりました。
夏休みの宿題よろしく納入直前に頑張っていますか。

協力会社にプログラムの発注を出すと,プログラムがバグだらけだったという苦い記憶はありませんか。
筆者は「なぜこんな簡単なテストを実施していないんだ」とよく思ったものです。 協力会社の技術レベルが低くてテストをテスト観点として気づかなかったこともありますし, 実は発注者の頭にしかない仕様を前提としたテストだったこともあります。
発注側と受注側の意識のズレを減らす方法を検討し,ひとつの結論にたどりつきました。

テスト実施前にテスト観点のレビューを実施するのです。

本当は単体テスト,結合テストのすべてのチェックリストを確認できればベストですが, チェックリストの量が多すぎてとてもチェックできません。 そこで,チェックリスト作成時の観点をまとめて提出してもらい, 発注側の意識とズレがないかを確認するようにしました。

たとえば,文字コードの変換を扱うプログラムでは文字コードのチェックがあるか確認します。
それも,「表示される文字が正しいか」といった抽象的な言葉ではなく,具体例を出して記述しているか確認します。
筆者であれば次の文字が入っているか確認します。

  • 「〜」(UnicodeとWindowsのSJISで扱いの異なる文字)
  • 「表」(SJISの2バイト目に'\'を含む文字)
  • 「ア」(半角カナ)
  • 「@」(NEC拡張文字)

この内容がチェック観点になければチェックリストに追加してもらいます。
こちらのテストしてほしい内容を事前に協力会社に伝えることでテスト漏れを減らすわけです。

お互いにWin-Winの関係を築けるように努力しましょう。

posted by まる at 00:31| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年09月12日

お互いに幸福になる値切り方

システム構築やプログラムの見積もりを依頼したら想定より高額な金額を提示されたことはありませんか。
高いという感覚だけで値切っても受注側も安くしてくれません。受注側にしてみれば生活かかってますから当然といえば当然ですが。
そこでどのようにしたら値切れるか(または発注側の意識を修正するか)になるわけです。

自分の想定した金額と異なるということは,発注側と受注側に意識のずれがあります。 意識のずれといっても,いくらでも払ってくれるからふっかけてやれという考え方から,発注側の見積もりミスまで原因はさまざまです。
筆者の体験では次のようなパターンがあります。

  1. 管理工数などの隠れた工数を見落としているから
  2. 依頼された分野に詳しくないから
  3. 発注側の想定しているアルゴリズムが受注側が想定しているものと違うから
  4. いくらでも払ってくれるカモだから
どのパターンの場合にも共通で言えるのは,見積もりの根拠を細かく提示してもらうことです。 見積もり根拠が明確であればどのパターンに当てはまるかの見当がつくでしょう。

1の場合は発注側が見落としていた作業項目が見積もり根拠にあるはずです。ありがちなのはシステム調査や仕様作成などの工数が漏れているとか,管理工数のつみ忘れといったあたりでしょうか。 作業項目ごとに要・不要を判断し,発注側の見積もりを高めに設定するか,受注側に作業を省いてもらうことで対応します。

2の場合は仕様作成の工数やコーディングの工数が発注側の想定より高めにでます。仕様の詳細や実装方法をヒアリングすれば受注側の理解度を判断できるでしょう。 しょうがないと思えばそのまま発注しますし,高いと思ったら他の会社からも見積もりをとりましょう。他の会社がよければそちらに出してもいいですし,他社の見積もり金額をネタに最初の会社に値下げ交渉をしてもいいでしょう。

3の場合も2と同様に仕様の詳細や実装方法をヒアリングします。遠回りなアルゴリズムを適用していないか,発注側の予想と異なるアプリケーションを使用していないかをチェックします。 違う場合は発注側の想定を伝えて費用を圧縮できないか検討してもらいましょう。
ITProでも『「より良いシステムをより安く」---そうならないのはなぜ? 』(購読には登録が必要)という記事がありました。

4の場合は1〜3のどれにもあてはまらない場合です。カモだと思われてます。他社から見積もりを取りましょう。

この方法で値切ろうとすれば発注側も技術力を要求されます。勉強していない人はカモにされるのが世の宿命です。勉強あるのみです。

posted by まる at 22:58| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年09月06日

徹夜の減らし方(実践編)

徹夜のご利用は計画的にでは余裕を持ってスケジュールを組めばよいと書きました。実際には余裕を持ったスケジュールはなかなか難しいでしょう。
そんな余裕があれば最初から余裕を持ったスケジュールを組むに決まってるでしょう。または部長や課長という名前のひとさらいがやってきてあなたの同朋や先輩,部下をさらっていくことでしょう。スケジュールに余裕があるなーとのんびり構えていたら,ひとさらいにさらわれてデスマーチ化したプロジェクトをいくつも知ってます。
ひとさらいの目を逃れつつ,自分たちのスケジュールを破綻させないためにはどうしたらいいか。

メンバーに予定よりも少しだけ早いスケジュールを教えるのです。

スケジュールどおりに進んでるのに喜んで残業する人はほとんどいませんが,スケジュールより遅れているとなると頑張って残業します。その心理を利用する非道の技なのです。

例えば9月末がデットラインだとしたら,9月の3週までに全工程を完了させなければならないと嘘を教えます。
メンバーがスケジュールをまったく把握してなければ,〆切を早めにいえばいいだけです。メンバーがある程度のスケジュールを把握しているのであれば,受け入れ検査があるとか,接続確認のために早期に提供しなければならないとか,別のプロジェクトに入ってもらわなければならないとか,適当な理由を考えてスケジュールを繰り上げるのです。
このようにすることで自分たちは目標とするスケジュールより進んでいないという危機意識を植え付けることができ,メンバーに進んで残業してもらうことができます。我ながらヒドい思考をするもんです。

注意事項を一つだけ。
今回の技は邪道です。10個のプロジェクトのうち,どうしても成功させたい1個にだけ適用すべきです。10個のプロジェクトのうち10個すべてに適用しているといずれ見破られます。リーダーとしての信用を失い,以降のプロジェクトは以前より厳しい立場となってしまいます。9個のプロジェクトの真実が1個のプロジェクトの嘘を補強してくれるのです。
立派な詐欺師を目指して頑張りましょう。

posted by まる at 07:15| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年08月29日

徹夜のご利用は計画的に

皆さんは進捗管理をしていますか。
納期に向けてなんとなく仕事を進めていたりしませんか。
なんとなく仕事を進めていると,他の仕事に時間を取られて直前で徹夜したりしていませんか。
恥ずかしながら筆者もその一人です。

昔だったら2日や3日の徹夜をこなして飲み会に参加したりしたのですが,年齢のせいか無理がきかなくなってきました。 だんだんと体の無理もきかなくなってきたし,部下に徹夜させるのも酷な話です。
そこで,徹夜を回避するための方策を考えました。
時間的な余裕を持ったスケジュールを組むことです。

予定を余裕なく組んだ場合にアクシデントにが発生して予定から遅れると,予定に間に合わせるために徹夜や休日出勤をしなければなりません。 最初からアクシデントに耐えうるようにスケジュールが組めれば,徹夜の回数を減らすことができます。
心の余裕と一緒にスケジュールの余裕もいかがでしょうか。

posted by まる at 00:00| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年08月15日

優秀なSEの捕まえ方

@ITの会議室で,協力会社さんとの上手なつきあい方を聞いてみました。
そのときに私なりにまとめた意見を載せてみます。

1.簡単な作業から依頼する

雇用契約を結んだら最後まで面倒を見なくちゃいけない自社の社員と違う
短期契約の特色を活かした手法です。
発注する側には技術力があるかとか,変な人じゃないかとか不安があるわけですし,
発注される側にも見下したりしないかとか,契約外の作業を強制してこないかとか不安があるので,
簡単な作業を一緒にすることでお互いにうまくやっていけるかを確認する,と。


2.育成する

優秀なSEが少なく,ハズレのSEがあふている現状では正攻法でしょう。
ただ,短期契約の特徴である「すぐに逃げられる」という影響を減らすため,長期的におつきあいできると判断したSEにのみとどめておくべきです。


3.定着してもらう努力をする

協力会社のSEさんを見下さないといった基本的なところから,
難度の高い作業を依頼して仕事のやりがいを考慮するとか
継続して仕事を発注するといったところでしょうか。


個人的な意見としては最後にモノをいうのはお金です。
・ハズレのSEをつかまされても仕事が狂わない体制
・育成コストを負担できる体制
・継続して仕事を発注できる体制

どれにしてもお金が必要なので,やっぱり大きな会社はいいなーと感じる今日このごろです。

posted by まる at 11:30| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年06月13日

日本一短い上司からのメール

筆者があるデスマーチに放り込まれたときの出来事です。この案件は他社と仕様の扱いで揉めており,部課長を含めてメールが飛び交っていました。

他社「御社の提供したライブラリは弊社の要求どおりに動作していない」
筆者「弊社は2ヶ月以上前に仕様書を提出している。御社の指摘は仕様書に記載済みの事項である。」
他社「御社では仕様と言うが,御社の仕様は弊社の要求事項を満たしていない。仕様不良ではないか。」
筆者「そのような指摘は仕様書のレビュー時にすべき事項である。御社として問題ないと判断したから合議したのではないか。」
他社「そうは言っても御社の…」

この議論に負けると自分たちのチームが悲惨な目にあうことは確定です。
プログラムの根幹に関わる仕様変更なのでソースの修正量がハンパじゃありません。ソースを修正すると今までのテスト成果もパアです。テストを一からやり直す羽目になります。今でも休日も会社に来てるし,平日の帰宅は午前様なのです。これ以上の作業が増えると徹夜以外に選択肢がありません。
自分だけならまだしも同僚たちも同じ目にあいます。負けるわけにはいきません。他社も同様の状況らしく担当者は相当熱くなってました。

こんな状態のある日,幹部からメールが届きました。事態を打開する素晴らしいメールに違いないとワクワクしながらメールを開きました。
せっかくなのでこの素晴らしいメールの本文を全文引用します。

To: 関係者各位
Subject: XXXの扱いについて

よろしく。

肝心な部分を省略しているわけではありません。本当に5文字です。全文を引用してもたった5文字です。
誰に何を指示してるんでしょうか。意味不明です。幹部もボケたのでしょうか。
徹夜の後でもあり相当頭にきました。いっそ幹部に文句を言おうかと考えたぐらいです。

しばらくすると,部長から信じられないようなメールが返ってきました。

To: 幹部
Cc: 関係者各位
Subject: Re:XXXの扱いについて

指示いただきありがとうございます。
次のように対処します。

(1) XXXの扱い
弊社の見解は仕様です。
ただし,プロジェクト完遂のため要望事項にあわせて仕様を変更します。

(2) 対策期日
ソースの修正が必要となるため提供を○月に延期します。
他社でのテストが滞らないようにテスト用のモジュールは別途提供します。
日程は別途相談します。

(3) 要員
テスト工程以降に人員をX名追加します。
...

メールの内容自体はこちらが譲歩した場合の案であり違和感はありません。 しかし,先ほどのメールのどこに指示があったのでしょう。筆者には全然分かりませんでした。
あまりに不思議だったのでタバコ部屋に部長が行ったときに直接聞いてみました。

筆者「さっきのメールのどこにそんな指示があったんですか?」
部長「今の状態だとお互いに不幸だよね。だからこっちが泥をかぶって相手に貸しを作るわけ。今回の相手とは今後もつきあうので,ここで貸しを作っておけば後で困ったときに有利に働くしね。」
筆者「それは分かりますけど…」
部長「君たちのチームが厳しいのも分かるけど,相手の会社にも余裕がないみたいだね。実はテストに割り振るチームの当てはあるけどこの案件で使っていいか迷ってたんだ。そこにさっきのメールが来たでしょ。あれはテスト用のチームを使っていいという幹部からの許可なんだよ。」
筆者「はあ。」
部長「事態が膠着するまで放置するとは何事だ。相手との信頼関係の問題にもなる。さっさと対処しろというプレッシャーもあのメールにはこめられてるんだよ。」
筆者「そうは読めませんでしたが。」
部長「似たような局面で『何事だ!』と怒鳴り散らしたことがあったからね。幹部が課長の頃からのつきあいだから,あれで十分な指示なんだよ。」

まさに以心伝心というやつでしょうか。

posted by まる at 22:45| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年03月06日

担当者の脳内時計

そろそろ3月末です。いわゆる期末が近づいてきています。学生であれば期末というとテストを連想しますが,会社員は期末というと業績という単語が脳裏に浮かびます。
業績を達成するためには,納品物を〆切までに仕上げる必要があります。しかし,夏休みの宿題と一緒で〆切間際にならないと追い込みがかかりません。
上司やお客様から追い込みをかけられた場合に担当者は期日を言わされますが,期日は一般的な時計ではなく担当者の脳内時計を基準としています。 担当者の脳内時計について考察してみました。
朝一までに
夜に頑張るつもりのようです。かなりの確率で朝一に出てきます。 とはいいつつも油断は大敵で,筆者はこの言葉を聞きながら次の日の朝一に提出されたことがあります。


午後一までに
この言葉どおり昼食後に提出される可能性は低いです。定時ぐらいに提出してもらえればいいと割り切りましょう。


定時までに
一日頑張るんでしょうが,切羽詰まってるときは見積もりが甘くなります。日付が変わるまでに提出してもらえるかが勝負どころです。


今日中に
この場合の今日というのはいつまでを指すのでしょうか?会社における一日は一般的な営業時間である9:00-17:00を指すのが一般的なんですが。
今日中というのは言い換えると次の日に出社してチェックするときには出来上がっているということです。基本的に上の朝一までにと同じと考えたほうが失望しません。 そう思っていないと自分自身の精神状態に悪影響を及ぼします。


金曜日中に
金曜日だけに通用するマジックです。第二次大戦中に月月火水木金金という軍歌がありましたが,それを彷彿とさせてくれます。きっと担当者の頭の中は月月火水木金金ですらなく,月火水木金金金なのでしょう。似たような事例として金曜日の72時までにというのも聞いたことがあります。

自分自身でも似たようなことを言ったことがありますし,担当者に言われたこともあります。あなたはどうでしょうか。
posted by まる at 23:11| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年02月28日

実践的見積もり手法

実際に自分が見積もる際にどのように考えているかを記述してみます。

(1) 作業項目を洗い出す
自分達がする作業に漏れがないか洗い出します。
この時点で作業項目に漏れがあると後の作業がすべて無駄になります。
絶対に項目の漏れがないようにしてください。
基本は顧客や上司に提出した費用請求用の作業項目一覧を洗い出しのベースとすると,この時点での作業項目漏れを減らせます。

(2) 作業項目の内容を詳細化する
洗い出しただけの作業では実際の作業を想定できないことが多いため,(1)が終了した時点での見積もりは誤差が大きいのが一般的です。
そこで見積もりの精度をあげるために,作業項目を詳細化します。
たとえば,「CRMシステムを構築する」といったシステムを構築する場合
・どのパッケージ製品を利用するのか
・システム構成はどうするのか
・どの程度のコーディングが発生しそうか
・多重アクセス,障害回復,セキュリティの考慮は万全か
といった具合に考えなければならない項目がいろいろあります。

さらにCRMシステムの中で「あるファイルを開いて別のファイルに書き出す」という作業がある場合,
・排他制御が必要か
・ファイルが存在しない,ファイル内容が不正といったエラーケースをどの程度考慮しなければならないか
・ファイルサイズの上限と一般的なサイズはどのぐらいか。ファイルサイズが大きい場合は処理を検討しなければならないか
といった具合に考えなければならない項目がいろいろあります。

最終的には仕様書とプログラムという成果物になるわけですが,仕様書を記載するまえに仕様の検討が必要です。
仕様の検討は見積もり後にも実施しますが,見積もり時点から仕様を検討することで見積もり精度が向上します。

(3) リスク要因を考慮してマージンを設定する
過去の見積もり実績から検討漏れ,見当違い,別の作業による作業着手遅延などによるリスクを織り込みます。
(2)の作業の合計を積み上げてリスク要因分だけの日数を追加すると見積もりの完成です。
見積もりを提示する際にリスク要因を明確にしておくことで,上司や顧客と見積もりの前提を変える条件が何かを明確にしておきます。
見積もり時点で提示しておけば,のちのちトラブルになった際に見積もりが自分を助けてくれることもあります。

(4) 見積もりに対する実績を記録する
見積もるだけでは駄目です。見積もりをしたら実績を記録するようにしましょう。
見積もりに失敗した場合は何が原因で見積もりが失敗したかを分析し,次回は同じ失敗をしないようにしましょう。
最初はうまくいきませんが失敗を見直すことで見積もり精度が次第に向上してきます。

見積もりは大変ですが見積もりどおりに作業が完成できたときの達成感は格別です。
正確に見積もって,定時で退社できるようがんばりましょう。
posted by まる at 00:27| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年02月21日

見積もりの必要性

駆け出しのプログラマから成長するに従い,コーディング以外のことも必要となります。
最初の頃はコーディングができればいいのですが,次第にシステム全体の構造や,アルゴリズム,自分の活動している業界の知識,発注元(お客様)との折衝,工程の管理など要求される項目が増えてきます。
プログラマに要求される項目の中でも重要度の高い作業の見積もり方法について考えてみましょう。

コーディングをするとバグが出るのは当たり前です。バグが出ればバグの修正も時間がかかります。
コーディング着手時に考えていたロジックに漏れがあり,再設計をしなければならない場合もあります。
また,仕様の変更があり当初の予想どおりにならない場合もあります。
このように,プログラム開発時にはいろいろなトラブルが発生するのが当たり前なので,予定はあってないようなものです。
プログラムが出来上がった日が完了日だと主張したくなります。
では,作業の見積もりはなぜ必要なのでしょうか?

それはプロの開発者としてお金をもらうためです。
発注元のお客様には予算と時間という制約があります。
発注元の会社のスケジュール(ECサイトのオープンや,銀行のシステム入れ替えなど)のスケジュールはプログラムの開発期間だけで決まるものではありません。
むしろそれ以外の要因の方が多いでしょう。

発注元は発注元から見たお客様(顧客や社内の部署)に対してスケジュールどおりシステムを提供する責任があります。
システムをスケジュールどおり提供するには,プログラムの制作期間を把握する必要があります。
しかし,発注元は自分でプログラムを作成しないので,プログラムの制作期間は分かりません。
そこで,実際のプログラムの開発者に対し,どのくらいでできるかを質問するのです。
このような理由から,開発の担当者が見積もりを間違えると発注元が発注元から見たお客様に対しスケジュールどおりにシステムを提供できません。みずほ銀行のシステム統合トラブルのように大問題になる可能性があります。
また,見積もりに失敗すると,発注元との調整,残業時間の増加,メンバーの追加など当初の予定よりもコストが発生します。
会社として考えると仕事から利益がでないことになり,最悪の場合は倒産してしまいます。

見積もりはプログラマの重要な能力です。
日々磨きをかけましょう。
posted by まる at 01:27| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2005年01月17日

名前と内容

外注に作業を依頼する際に仕様書など文書の作成を依頼することがあります。
文書の作成を依頼する場合は,必ず文書の中身についても説明しましょう。
作業を依頼する際に,仕様書として何を記述すべきかを説明しなかった場合,
自分の考えている仕様書をもらえる可能性は限りなく低いでしょう。

外注先に対して仕様書として発注側が何を書くべきと考えているかをはっきり説明する必要があります。
以前に作成した仕様書があり渡しても構わないのであれば,それをサンプルとして渡して
どのような内容を記述するべきかのイメージを発注元と外注で一致させましょう。

その上で目次のみを作成してレビューを実施し記述項目の確認をするなど,
お互いの理解不足による作業の手戻りを最小限にするように努力しましょう。
レビュー回数を増やすのは面倒ですが,作業の手戻りが発生することを考えると安いものです。
お互いに努力してよいものを作りましょう。
posted by まる at 00:00| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2004年10月07日

管理の一歩は記録から

進捗を管理していて担当者の申告から日程がずれることはありませんか?

担当者は遅れる理由を説明して日程を延ばすことが出来ます。
しかし,管理者は遅延までを見込んだ日程を考慮する必要があります。
素直に担当者の言う日程をまとめて提出すると,一週間ごとに工程が遅れ,管理者の提示する日程を誰も信用しなくなります。

では,担当者の主張以外何を信じればいいのでしょうか?


信用すべきは担当者の過去の実績です。
仕事の内容が変わるごとに微妙に変化しますが,次に示すようなデータはあまり変わりません。
・一日あたりに記述できる新規/変更ステップ数,
・一日あたりの単体/統合テストの消化項目
・不良摘出率
・申告日程との乖離率

まず実績を記録しましょう。
次の仕事では過去の実績を考慮して見積もりをたてることで見積もり精度をあげましょう。
記録をとるのは面倒ですが,信用されるための対価と思ってがんばりましょう。
posted by まる at 00:32| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2004年10月03日

3種の〆切

〆切には3種類あります。

表の〆切,裏の〆切,真の〆切です。

表の〆切は正式に決められている日程です。
顧客との折衝等により決定されたり,営業や偉い人の鶴の一声で決まったりします。
政治的な意図がいろいろ働くので,最初から無理と分かっている〆切でも平気で設定されます。

裏の〆切は担当者に教える〆切です。
表の〆切が無茶苦茶な場合,担当者に表の〆切を守らせること自体が無理です。
その場合も,管理者が考えているだけのパフォーマンスを実現するためには,
〆切を設定する必要があります。
そこで,表の〆切を一切無視して担当者の力量に見合った〆切を設定します。
〆切が存在しないと,担当者は〆切が存在しないと目標がなくなるので,実現可能な〆切がない場合に比べてパフォーマンスが悪化します。
そこで,担当者の身の丈にあった〆切を設定してあげるわけです。
裏の〆切は後述の真の〆切よりも少し余裕を持って設定します。

真の〆切は,担当者に対して絶対に守らせなければならない〆切です。
表の〆切が無茶苦茶だった場合,〆切を再設定することになります。
その際に手元に見積もり資料がないと,顧客を納得させるのは難しいでしょう。
また,〆切を再設定して,再度〆切を破るというのは,相手の心象を悪くします。

そこで,顧客を納得させれる日程を真の〆切としてもっておき,裏ではこの日程で話を進めます。
ただ,真の〆切を担当者に知られると,担当者が真の〆切を目標に作業するので,担当者には知られないようにします。

なるべくなら,表の〆切一つですませたいのですが,〆切を使い分ける生活は続きそうです。
posted by まる at 01:21| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

2004年09月04日

たった一つの冴えたやり方

工程が切羽詰まってデスマーチになりかけたとき,遅れを取り戻す方法は,大きく二つあります。

(1) 追加人員を投入する
(2) 実現機能を削減する

どちらもよく語られる内容ですが,実際はどちらも難しいでしょう。

(1)の場合,そもそもそんな予算がない場合が大半です。仮に予算があったとしても,「人月の神話」,「ピープルウエア」等でも語られているようにコミュニケーションコスト,初期教育コスト等がかかります。そのため,人が増えたせいで仕事が増えるという悪循環に入り,結局デスマーチに突入する場合もあります。
(2)の場合,そもそも削減できる機能があるのなら既に実施しているでしょう。お客さんに機能削減を提案しても受け入れてもらえないかもしれません。

そこで,このBLOGを読んでいただいている皆さんにだけ,第三の方法を教えましょう。
続きを読む
posted by まる at 03:31| Comment(0) | TrackBack(0) | 管理者 Chips | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。