ビジネス・個人事業アーカイブlife人生はドラマである。トラックバック(0)Twitterで拾ったネタですが...チーム内でやる進捗会議はムダ(agnozingdays.hatenablog.com)社会で行われている“会議”とされるものの8割は無駄!...というような話も昔聞いたような気がしますが。チームで行うソフトウェア開発におけるそれは多くの場合、わりと大きな意味を持っていたりします。最終的な出来上がりが酷いことになる、なんてことはこの業界でやっている人なら痛いほどわかるでしょう。いえ、やらなくても良いだろうという打ち合わせも率直に言って実は結構多いだろうと思う。上記記事でも槍玉に上がってるチーム内の進捗会議。スケジュールやマイルストンを立てたり、人繰り調整したり仕事量の分散やメンバの進捗を管理するのはプロジェクトリーダ(PL)なりマネージャ(PM)がやれば良いこと。別にみんなが把握してる必要ないことでしょ?って話。開発メンバがそれぞれ把握してないといけないのは、ソフトウェアの要件であり仕様であり実装すべき機能です。それを決めたり意識統一を図ったりする打ち合わせはものづくりをする上でもちろん必要。進捗に関する話を全員で集まってやる必要はない。それはPL(PM)が各メンバの負荷や状況を把握して、それをPL(PM)が対メンバでやっていけば良いことでしょう。その状況はグループウェアなりトラッカーなり全体回覧できるような手段で知らせておけば事足ります。ある程度大きなプロジェクトであれば、PL(PM)ひとりが全体をみることが困難になってきますが大規模になれば大抵小割りチームをつくるでしょうから、そのチームごとのリーダを設けてリーダ会議をやればOK。開発メンバは、基本的には自分に割り振られた仕事をいつまでに仕上げれば良いか、を知っていれば良い。それが無理そうだったり余裕だったりということは個々でPL(PM)に伝えて、あとはそのPL(PM)が調整する。問題把握も、基本的にリーダーが把握してれば良い。リーダーは問題解決にあたらないといけないけど、それは基本的に開発メンバ個々の仕事ではない。ここ重要ですが、その前提条件としてPL(PM)は、そのプロジェクト管理以外の仕事をしないこと。PL(PM)が開発とかテストとか実務をやっちゃダメです。人手が足りなくなったり、PLが開発者上がりだったりするとそのPLまでが開発やテストに入ってくるケースも私の経験上多々あったんですが、大体うまく回ってません。PL(PM)はプロジェクト管理に専念する、というのがキモ。会社方針とかISOとかでやらにゃならんということであれば、百歩譲って週1がいいとこでしょう。毎日は......あり得ない。(ほぼ)毎日進捗会議やってるようなプロジェクトでそれが上手くいってるようなケースがあるなら、その会議でどんな話をしてるのか、非常に興味ありますね。トラックバック(0)久々に仕事ネタでも書こうかと。受注型のシステム開発、カスタマイズなんていう仕事をかれこれもう10年以上やっているのだけど、その経験や現在進行中のプロジェクトをやってる中で私が個人的に思ってること、感じたことを書いてみる。何をつくればいいのか、という開発の動機であり最も根本。ここがしっかりしてないと大抵のプロジェクトはガタつく。お客さんも“本当につくって欲しいもの”のイメージを要件定義の段階で持っていないことが多いから面倒。そこでキモなのは、システムを使って何をしたいのか?ということをお客さんから聞き出すこと。既存システムのリプレースの場合は何を改善したいのか、何を効率化したいのか、ということ。一致した最終形のイメージをしやすいのではないかと。システムは、“仕様ありき”ではなく“要件ありき”だ。冗長化やDMZの設置を省略したり...それで開発段階はまだ良いけど、実運用の段階でそのケチったツケが回ってくることになる。後々の保守コストを考えたときにどちらがお得か。あと、ソフトのチューニングにコストを割くよりも、ハードで解決できるならそうした方が安上がりなことも多い。予算が許す限り、下手にケチるべきでない。○基本設計を固めてから実装しろ当たり前ですが...。これが意外と守られない。製造、テストのフェーズになってから基本設計が変わる、ということが多々ある。2、30人規模のプロジェクトでその状態になると経験上それはほぼデスマの始まりです。プログラムの詳細設計は良い。...いや、どうでも良くはないけど、プログラム設計は開発者の機転で何とでもなるところで最近のRADフレームとか簡易なスクリプトをもってすればちょっとしたルーチンや構造の変更ならどうにかなる。