「 2010年02月 」一覧

休日出勤、など

マイルストーン前でいろいろと作業が立て込んでいたので、何週間かぶりの休日出勤。

ただし、労働時間の制限で長居できないので夕方から職場に顔を出すことにして、それまでは博多駅付近をウロウロと。

交通センターの紀伊國屋で、買い物メモ代わりのamazonカートに入っている本の現物確認。マネージメント系の本などを手に取る。amazonでは高評価だったりするのだけど、いま自分が読みたい内容じゃなかったり、読みにくいと思ったり似たような本はもう持ってるな、などで結局今日はどれも買わずじまい。

紀伊國屋を後にして博多駅へ。ふだんは自転車で家から会社へ直接移動なのであまり駅には頻繁には行かないせいか、行くたびにあちこち工事で店が閉まっていたり移動していたりしてよく分からない。

改札の横にあったパン屋も仮店舗の狭いところで営業してし、もう一件のバンテルンはヨドバシ寄りのちょっと奥まったところに移転してちょっと狭くなってた。久しぶりにそこでパンを買ってから会社へ。

会社で出勤しているメンバーに、残バグの状況や一部作り替えている部分の動作状況などを聞く。大きな問題は無さそうだが、他のレイヤにバグがあって少し上手く動かない機能があるようだ。

これから数回に渡るマイルストーンに、どの機能が載せられるか検討して報告のメールを書く。こちらが使うAPIがまだ提供されていなかったり、仕様が未決定だったりするところもあってリリース可能かどうか流動的なものが多いのだけど、来週は重いアイテムが目白押しだし祝日も挟むので工数と時間的にすべて間に合わせられるかどうか…。

買ったパンのうち、ちょっと高いカレーパンが旨かったな。あとフランスパンにカスタードはさんだのも。いつも残業の時はスーパーでパン買ってるけど、たまにはパン屋のもいいな。電車で通勤していたころは帰りがけによく買い物していたけど。

仕事のほうは3時間半くらい作業して引き揚げ。休日に出勤した甲斐はあったかな。


ATOK2010入れてみた

ATOK2008から2年ぶりのアップデート。

今回はWin/Macとも月額制にしてみた。と言ってもMacはまだATOK2009しか出ていないけどね。

正直なところ、ATOKは仕事で使いたい。会社PCのインストールポリシーが厳しくなってATOKを使えなくなってしまったけど、以前使っていたときは本当に誤変換とか語彙の間違いが少なかった気がする。メールやらドキュメントを毎日たくさん書いていると実感できる。

その後、会社はMS-IMEに戻したのだけど、だいぶ経った今でも、何度変換しても学習してくれない用語があったりしてとても残念。共同通信社記者ハンドブックの拡張辞書と組み合わせると似たような語句のニュアンスの違いとか指摘してくれてかなり最強だったのだけどなぁ…。

ATOK 2010 for Windows 通常版
ATOK 2010 for Windows 通常版
ジャストシステム 2010-02-05
売り上げランキング : 24

Amazonで詳しく見る by G-Tools


現場を守ろうと情報をフィルタリングすると裏目に出ることも

ときどき、そういうプロジェクトを見かける。

マネージャが現場のメンバーに余計な心配をかけまいと、プロジェクトにとって悪い話しや直近の作業では無いが少し先の話などをあえて黙っていることがある。

でも仕事に追われているうちに、いつの間にか「メンバーに話す適切なタイミング」を過ぎてしまい、「実は○月までに…」という爆弾発言になって現場から反発されたりするケースもあるように思う。

部下は風の噂ではすでにそういう話しを聞いていたりするのだが、マネージャに確認してもはっきりとは言ってくれなかったり、けっきょく釈然としないまま時間だけが過ぎていく。

もっとたちの悪いのは、本当は今からでも準備・検討・着手したほうがいいはずの話しも「現場が忙しそうだから」と現場に伝えないこと。後から蓋を開けてみて「なぜ早くその時に言ってくれなかったんだ…」とガックリするケース。

部下がある程度優秀で自分たちで何をすべきか考えて自主的に動けるチームなら、という前提は付いてしまうが、そういうチームなら多少今の作業が詰まっていようが忙しかろうが、長期スパンの話しや悪い話しをされても、きちんとそれを加味した行動を取ることは意外と可能だと思う。

逆に、今後すでに方向性や新しい案件など決まっていることがあれば積極的に情報展開して欲しいとも思っている。スキマ時間を使って、準備や検討、簡単な資料作りくらいからなら着手できるから。

逆に着手しないと間に合わないギリギリのタイミングで「実はこんな案件が…」「こんな要望が…」と話しを切り出されるほうが辛い。マネージャと現場で作業ボリュームの感覚が違うことも多い。

マネージャ「6月から3名3ヶ月くらいでできるだろう」

と思って、5月の終わりくらいに話しを切り出されても、

現場「3名体制なら4月から着手してないと、検討事項が多すぎて間に合わない!」

ということにもなりうる。そして、当初の想定より作業が増えて残業・休出することになり、現場は余裕が無くなるので検討漏れ、作業の取りこぼしが出て後工程で火を噴くことになることがほとんど。

マネージャの良かれ、が裏目に出ることもあるのですよ…。


iPhoneOS 3.1.3

バッテリーの表示が改善だと。

朝、満充電して会社に行きそのまま夜まで待ち受けにしてるだけでも、日によって95%だったり60%だったりと電池の消費にとてもバラツキがある。

これが表示の問題なのか本当に消費してるのかってところだなぁ。


ソフトウェアの受託開発と商品開発の違いって?

まだ考え始めたばかりで、まったくまとまっていないのだけど。

おそらく一部を除いては、劇的に違うってところはそれほど無いんじゃないのかなと思っているのだけど…。でもずっとやってるところはノウハウってのがあるんだろうなぁ。

とりあえずざっと書いてみる。まだまだ薄すぎるので、掘り下げて考えたい。

要件定義と企画

最初のフェーズは、受託なら要件定義、商品開発なら企画ということになろうか。

要件定義なら、顧客の要望や現状分析というようにある程度の方向性のベースがある。

企画だと、商品の方向性、販売ターゲット、価格、機能、市場ニーズ、先見性、競合製品など考慮すべき点が多い。ここで間違えると商品力は下がってしまう。商品開発のキモの一つか。

見積もり

これはどちらもほぼ同じか。

作るもののスコープが固まったら、工数を見積もる。当然、精度は高いほうが良い。

商品の形態によっては(ライブラリ群など)、リファレンスとなる環境やハードウェアを想定しておく。

回収計画

商品開発の場合は、算出した開発コストをベースにどれくらい売ればペイできるかを考える。

ここで企画段階での市場ニーズや競合製品などの有無を考慮に入れる。どれくらいのスパンで回収するかというのもあるだろう。

設計・製造

組み込みの商品開発で、ポーティング対象(ハード、プラットフォームなど)が幅広い場合は、いかにコア部分と移植層を分けて設計できるかが重要。

また将来の拡張なども考慮に入れて設計する必要あり。

原価管理

受託も商品開発も見積もった予算内でこなさなければならないのは同じ。アーンドバリューのように、直接的な数値を週単位なり半月に一回なり集計してプロジェクトメンバに開示したほうがコスト意識は高まるのかもしれない。

かろうじて受託の場合は「費用交渉」というものもあるが、これは受託側に正当な理由が無いと…。

テスト

成果物に対するテストは、受託も商品も大きく変わらないと思う。

商品の場合でかつ、リファレンス環境がある場合はその環境で。

営業、契約

商品の場合はこれもキモ。

販売チャネルが少ない場合はまずは商品の露出から…か?

契約はライセンス形態、イニシャルコスト、バージョンアップ時の費用、カスタマイズ費用など、有利な条件を結べるか。ここで上手く行かないと、対象製品はたくさん売れているのに、実入りが少ないなどの事態に。

保守

瑕疵保証、カスタマサポートなど。保守体制をどれくらい用意するかは考えどころ。

継続開発

次のバージョンの開発や、新機能の搭載など。

初回バージョンが売れて予算が取れればいいが…。また継続開発用の要員を確保するためのコストなども課題。


うまくいってないプロジェクト・マネジャーは「反応型」が多い

ベースラインで成功する プロジェクトマネジメント P86より。

うまくいっていないプロジェクトのプロジェクト・マネジャーは、よく見ているとたいてい「反応型」といえる状況です。要は、一定以上起こりうることを想定したうえでの”次の一手”を決めておらず、何か新たなことがわかったり、ステークホルダーから問題視されて、初めてそれらに反応する形で行動を始めます。

つまり、常に後手に回っているのです。これは、「プロジェクト・マネジャー自身がプロジェクト完了時のイメージを最初にしっかりと頭に描いていないまま行動している」ことから引き起こされているのがわかります。

この本の著者の回し者でもなんでも無いのだけど、私が思っていたことと同じ事がけっこう多く書かれていて、私が感じていたことは(少なくともまったくは)間違ってなさそうだな、と。


2/8のISIT交流会はandroidがテーマ

九州先端科学技術研究所(ISIT)という団体があるのも初めて知ったのだけど…。

2/8に定期交流会というのがあるらしく、そのテーマがandroidなんだそうで。

ISIT Exchange Meeting

第67回 ISIT 定期交流会のご案内
■日 時
平成22年2月8日(月)
講演会 14:30〜17:00
交流会 17:00〜18:00

■会 場
福岡SRPセンタービル(ももちキューブ)2階 SRPホール
(福岡市早良区百道浜2丁目1−22)

■テーマ
「Android、その技術と広がるビジネスチャンス」

ブリリアントサービスさんの講演とか聞いてみたいなぁ…と思いつつ、平日の開催だと仕事があるので、とても微妙。

会費払ったりする雰囲気から考えて、申し込んでドタキャンって駄目そうだしなぁ…。80名っていう定員もどれくらい埋まるんだろ。ドタキャンしても怒られず、定員オーバーで行きたい人が行けなかった、とならないなら登録だけしておきたいけども。

androidの会福岡支部長のしかじろうさんも喋るらしいので行ってみたいなぁ。


プロジェクトの負のスパイラル

ベースラインで成功する プロジェクトマネジメント P24より、”プロジェクトの負のスパイラル”

→無理な計画
|↓
|間に合わない
|↓
|徹夜作業(ヘトヘト)
|↓
-最低限のことだけやって、あとは謝って許してもらう
(成功ではないが失敗でもない→ムリな計画が検証されない)

ありすぎて困る。

よくあるケース

プロジェクトが始まる前、見積もりもしてない提案段階から、いつのまにか価格がお客に提示されている。しかもスケジュールは非常に短い。

開発部隊はそれを見て「この期間と予算ではムリ」と言うのだけど「すでに価格とスケジュールはお客に提示してるから」と言われ、仕方なく十分な人数も揃えられないままプロジェクトを始める。

予想どおり、途中で遅延し始める。この頃から残業と休日出勤が増え始める。

マイルストーン直前になって、マネージャがようやく状況確認をする。そして「この品質ではリリースできない。どうするつもりだ」などと言い始める。

かといって応援要員が追加されるわけでもなく、単に残業が酷くなり、徹夜も出てくる。

マイルストーン当日、十分な成果物がリリースできない。大抵、お客に頭を下げて日程をずらすか、機能を落としてリリース。

最終的な納期はそう簡単に変わらないので、マイルストーンは謝って乗り切っても問題を先送りしたに過ぎない。

重要なリリース日の少し前くらいに、またもやマネージャが状況確認に入る。そしてまた「できてないじゃないか」と大騒ぎになる。

さすがにこれでは、ということで追加要員が投入されるが時既に遅し。要員の立ち上げ期間を考えてないので生産性はあまり上がらないし、投入されたほうは無茶な稼働を強いられる。

この頃になるとマネージャも進捗確認会と称して毎日長時間の会議を設定するが、状況を延々と聞くばかりで何かが解決することは少ない。「対策はどうするんだ」「結局いつできるんだ」くらいしか言われない。

お客に頭を下げつつ、何度か期日を延長して最終リリース。予算はとっくにオーバーしているし、みんな疲れ切っている。

でもまたすぐに納期と予算がどこかで勝手に決まったプロジェクトが立ち上がり…。

謝ればなんとかなる。ただし反省もしない。

…つきあいのある顧客だったり、日本企業同士だと「謝ればどうにかなる」という部分がそれなりにある。あまりにもクリティカルなケースでは無理だけど。

あとはマネージャが経験してきた道にも大きく影響されるような気がする。

マネージャがPGやSEだった時に残業、徹夜当たり前の仕事スタイルでやっていると、一線を離れたマネージャになっても部下に同じ感覚で指示を出してしまい、「休日出勤すればいいよね」「1日12時間としてスケジュール計算すればいいよね」というのが”当たり前”かのように扱われる。

もうマネージャ自身は休日出勤も徹夜もすることがない立場で、そんな無茶な指示を出しても自分の腹は痛まないというのもあるのかもしれないけど。

往々にしてそういう現場はどこにでもあるし、そして何度も繰り返される。

「忙しかったのは仕方ない」「仕事があるだけ有り難いと思え」「次の案件で取り返す」…。

現場の一人一人が自衛するしか無いと思う。


スポンサーリンク