）の生産性に差が出たのです。
・・って難しいなと思う、今日この頃の管理人です。
最近、ちと火を噴きそうなプロジェクトにＰＭとして、途中から投入されました。Struts を使った Web 系のシステムですが、Struts は使ったことがないので、プログラムは絶対無理や！！ということで、純粋に管理に徹することになりました。実はある程度の規模のシステムで、まともに管理だけに徹するのは初めて色々と試行錯誤の日々だったりします。
で、とりあえず前任者から引き継いだ工程表に線を引き、消し、また引きみたいな事を中心にやっているのですが、それはそれで色々と課題を感じています。まー具体的にいえば以下のような感じでしょうか。
１）工程表の項目分け
通常、工程表の縦の列には、作業項目を列挙していくわけですが、その列挙の仕方です。よく見かけるのが、機能仕様ごとに番号を振って、適当に依存度を見ながら順番を決めて、列挙していく方法です。ただ、作業の段取りを考える上で、機能仕様以外にも、システム構成も考えないと、実用上難しいと思います。今のプロジェクトも機能仕様毎に実装担当者を割り振って、任せていましたが、明らかに立ち往生していました。それからシステムの方法論も考慮すればいいのかな。オブジェクト指向でやっているなら、クラス構成でスケジュールを組んでみるとか言うのもありだとは思います。
後は項目ごとの粒度でしょうか。明らかに項目が違うものは分けないといけないし、作業量が多いものは、分割しないといけません。この辺をちゃんとやろうと思うと、実は設計情報をちゃんと把握しないといけないのですが、トラブルプロジェクトに有り勝ちな、判断基準になるドキュメントが無いと言う状況で、結局線引きのために、逆順で処理の流れやクラス図を書いている有様です。
２）役割分担
項目わけとも関係が深いのですが、機能仕様毎に担当者を決めて、各自の責任でその仕様を実現するってのが、今のプロジェクトです。最近だと、製造業では役割分担が行き過ぎて、生産工程に柔軟性がないから、セル生産が注目を集めていて、ソフトウェアにも取り入れようという動きもありますが、明らかに弊害もあります。要は Web 系だとブラウザ側の JavaScript による、インタラクティブな機能の実現から、サーバー側の DB アクセスの部分まで、結構レイヤできれいに分けられるので、メンバーの適性に合わせて、もう少し分担を明確にしたほうが断然効率が上がると思います。（ってか、今各担当者の日報を見ながら、ヒアリングをしながら、その辺の再配分を検討している所だったりします。）
後は再利用できる共通部分の抽出作業をもう少し考慮して、動的に項目と分担を更新していく事も前提にスケジュールを考えていますが、その場合、明らかにレイヤごとに専門家を作るような体制を敷いたほうが効率は良さそうかなと思うしだいです。
３）線の長さ
とりあえず、項目を上げて、分担を決めてたら、線の長さを決めるわけです。理想を言うなら、担当者に105%〜110% の力を出させるのが理想かなと思います。100% では守りに入って、工夫や進歩が無いし、120% 以降は大抵の場合は無理が入るかなと思う次第です。線を引かれるとプレッシャーからストレスが溜まりますが、適当なストレスが無いとメリハリが出ず、納期なんて絶対守れないのも事実かなと思います。
ってな感じで、線引きもまじめにやると色々考えなあかん事がたくさんあるし、工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。ですが、ソフトウェア開発を対象に工程の最適化を主題に扱った、資料なり、本って探した範囲では全然見つかっていません。だれも研究対象にしていないのかな。IBM の研究所報告でも詳しく探せば出てくるのかな。元々、なぜか精度の低い工程表でもなんら問題にならないのが、この業界の体質なのかな。土木や建築なら積算やスケジュールリングだけでも、何冊も教本があるんですよね。さてこの差はどこから来るのでしょう。
ってな感じで、相変わらず思うところをだらだら書いてしまいましたが、皆さんの現場ではどんな感じでしょうか。御意見ください。
最近、ちと火を噴きそうなプロジェクトにＰＭとして、途中から投入されました。Struts を使った Web 系のシステムですが、Struts は使ったことがないので、プログラムは絶対無理や！！ということで、純粋に管理に徹することになりました。実はある程度の規模のシステムで、まともに管理だけに徹するのは初めて色々と試行錯誤の日々だったりします。
で、とりあえず前任者から引き継いだ工程表に線を引き、消し、また引きみたいな事を中心にやっているのですが、それはそれで色々と課題を感じています。まー具体的にいえば以下のような感じでしょうか。
１）工程表の項目分け
通常、工程表の縦の列には、作業項目を列挙していくわけですが、その列挙の仕方です。よく見かけるのが、機能仕様ごとに番号を振って、適当に依存度を見ながら順番を決めて、列挙していく方法です。ただ、作業の段取りを考える上で、機能仕様以外にも、システム構成も考えないと、実用上難しいと思います。今のプロジェクトも機能仕様毎に実装担当者を割り振って、任せていましたが、明らかに立ち往生していました。それからシステムの方法論も考慮すればいいのかな。オブジェクト指向でやっているなら、クラス構成でスケジュールを組んでみるとか言うのもありだとは思います。
後は項目ごとの粒度でしょうか。明らかに項目が違うものは分けないといけないし、作業量が多いものは、分割しないといけません。この辺をちゃんとやろうと思うと、実は設計情報をちゃんと把握しないといけないのですが、トラブルプロジェクトに有り勝ちな、判断基準になるドキュメントが無いと言う状況で、結局線引きのために、逆順で処理の流れやクラス図を書いている有様です。
２）役割分担
項目わけとも関係が深いのですが、機能仕様毎に担当者を決めて、各自の責任でその仕様を実現するってのが、今のプロジェクトです。最近だと、製造業では役割分担が行き過ぎて、生産工程に柔軟性がないから、セル生産が注目を集めていて、ソフトウェアにも取り入れようという動きもありますが、明らかに弊害もあります。要は Web 系だとブラウザ側の JavaScript による、インタラクティブな機能の実現から、サーバー側の DB アクセスの部分まで、結構レイヤできれいに分けられるので、メンバーの適性に合わせて、もう少し分担を明確にしたほうが断然効率が上がると思います。（ってか、今各担当者の日報を見ながら、ヒアリングをしながら、その辺の再配分を検討している所だったりします。）
後は再利用できる共通部分の抽出作業をもう少し考慮して、動的に項目と分担を更新していく事も前提にスケジュールを考えていますが、その場合、明らかにレイヤごとに専門家を作るような体制を敷いたほうが効率は良さそうかなと思うしだいです。
３）線の長さ
とりあえず、項目を上げて、分担を決めてたら、線の長さを決めるわけです。理想を言うなら、担当者に105%〜110% の力を出させるのが理想かなと思います。100% では守りに入って、工夫や進歩が無いし、120% 以降は大抵の場合は無理が入るかなと思う次第です。線を引かれるとプレッシャーからストレスが溜まりますが、適当なストレスが無いとメリハリが出ず、納期なんて絶対守れないのも事実かなと思います。
ってな感じで、線引きもまじめにやると色々考えなあかん事がたくさんあるし、工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。ですが、ソフトウェア開発を対象に工程の最適化を主題に扱った、資料なり、本って探した範囲では全然見つかっていません。だれも研究対象にしていないのかな。IBM の研究所報告でも詳しく探せば出てくるのかな。元々、なぜか精度の低い工程表でもなんら問題にならないのが、この業界の体質なのかな。土木や建築なら積算やスケジュールリングだけでも、何冊も教本があるんですよね。さてこの差はどこから来るのでしょう。
ってな感じで、相変わらず思うところをだらだら書いてしまいましたが、皆さんの現場ではどんな感じでしょうか。御意見ください。
|
|
|
|
コメント(23)
>機能仕様毎に実装担当者を割り振って
機能仕様っていうと(一応は)お客様視点ですよね。機能で仕様なんだから、お客さんが使ってて感じる「単位」が基準になる。
でも、中身で人の分担をわけるのにちょうどいい切り口って、中身(実装とか)の事情に応じて切るほうがたぶん効率が良くて、それはお客様視点とは直交、なような気がしたことがあります。機能仕様の各項目と、中身の構造の項目とは、多対多関係にあるというか。
個人的イメージ(ガントチャートじゃなく)では、機能仕様が「縦」、実装構造のレイヤが「横」、って感じかな。
そういや少なくとも「DBスキーマ」を「機能仕様」ごとに区切って担当わけすると悲惨なことになる…つーか、なった気がしました(わら
だってさー、機能ごとに(勝手に)DBのカラムや酷いときにはテーブルを増減／変更したりしようとするんだもん。それって「システム」と呼べるの？って疑問に思ったです。
>セル生産
目先のことじゃなく将来のことまで考える(＝投資？する)なら、セルだかアジャイルだかペアプロだか朝会だかで、スキルは(人間のあいだを)常時流しておくかたちにするのが良いのでしょうね。投資する余裕が有るかどうかの問題なのかなという気がしてます。もっとも、ずーっと投資できない状態が続くとすれば明らかに病的ですが。
機能仕様っていうと(一応は)お客様視点ですよね。機能で仕様なんだから、お客さんが使ってて感じる「単位」が基準になる。
でも、中身で人の分担をわけるのにちょうどいい切り口って、中身(実装とか)の事情に応じて切るほうがたぶん効率が良くて、それはお客様視点とは直交、なような気がしたことがあります。機能仕様の各項目と、中身の構造の項目とは、多対多関係にあるというか。
個人的イメージ(ガントチャートじゃなく)では、機能仕様が「縦」、実装構造のレイヤが「横」、って感じかな。
そういや少なくとも「DBスキーマ」を「機能仕様」ごとに区切って担当わけすると悲惨なことになる…つーか、なった気がしました(わら
だってさー、機能ごとに(勝手に)DBのカラムや酷いときにはテーブルを増減／変更したりしようとするんだもん。それって「システム」と呼べるの？って疑問に思ったです。
>セル生産
目先のことじゃなく将来のことまで考える(＝投資？する)なら、セルだかアジャイルだかペアプロだか朝会だかで、スキルは(人間のあいだを)常時流しておくかたちにするのが良いのでしょうね。投資する余裕が有るかどうかの問題なのかなという気がしてます。もっとも、ずーっと投資できない状態が続くとすれば明らかに病的ですが。
こんばんわ。早速のコメントありがとうございます。
戯音さん> 機能仕様の各項目と、中身の構造の項目とは、多対多関係にあるというか。
戯音さん>個人的イメージ(ガントチャートじゃなく)では、機能仕様が「縦」、実装構造のレイヤが「横」、って感じかな。
そうなんですね。完全に直交しているとは言えなくても、わりと独立していると思います。構造と仕様でみると、２次元なんですが、それを１次元に展開して列挙しないといけないので、苦労する所なんですよね。構造と仕様以外の要因が入ってきたら・・・・・
戯音さん>だってさー、機能ごとに(勝手に)DBのカラムや酷いときにはテーブルを増減／変更したりしようとするんだもん。それって「システム」と呼べるの？って疑問に思ったです。
・・・目のまえで、担当者が作業依頼先と電話で 「この DB のスキーマどうしようか」とか、実装作業のすりあわせ中にやり取りしていたりします。......orz......
えー、もう本当に大丈夫かと思うんですよね。 (ﾉ_-;)ﾊｱ…
全体みた設計ちゃんとやったんか。・・・・って、突っ込みいれたくなったこと、多々ありって感じです。
NAKA さん>ＷＢＳで検索してはどうでしょう。
WBS ですか、中々微妙なところですね。発想としては面白いですが。ちょっと勉強してみます。
NAKA さん>野球でいうと弱いチームが毎試合、打順を組み替えするみたいな感じです。
なんとも、味のある例えですね。試行錯誤のもどかしさが滲み出ています。
Kanabun さん>私の個人的な経験では Struts の工数見積はちときついです。
そうですね。フレームワークを使ったシステム開発って、フレームワークが対象となるシステムに十分メリットを出せるなら、やりやすいんですが、ミスマッチだと目も当てられない。
つまり、システムに求められる柔軟性、拡張性がフレームワークのホットスポットに適合していたら、良いのですが、要求されるカスタマイズがさりげなく、フレームワークの奥深いところまで引っ張ってこないといけない場合はしんどいですね。
戯音さん> 機能仕様の各項目と、中身の構造の項目とは、多対多関係にあるというか。
戯音さん>個人的イメージ(ガントチャートじゃなく)では、機能仕様が「縦」、実装構造のレイヤが「横」、って感じかな。
そうなんですね。完全に直交しているとは言えなくても、わりと独立していると思います。構造と仕様でみると、２次元なんですが、それを１次元に展開して列挙しないといけないので、苦労する所なんですよね。構造と仕様以外の要因が入ってきたら・・・・・
戯音さん>だってさー、機能ごとに(勝手に)DBのカラムや酷いときにはテーブルを増減／変更したりしようとするんだもん。それって「システム」と呼べるの？って疑問に思ったです。
・・・目のまえで、担当者が作業依頼先と電話で 「この DB のスキーマどうしようか」とか、実装作業のすりあわせ中にやり取りしていたりします。......orz......
えー、もう本当に大丈夫かと思うんですよね。 (ﾉ_-;)ﾊｱ…
全体みた設計ちゃんとやったんか。・・・・って、突っ込みいれたくなったこと、多々ありって感じです。
NAKA さん>ＷＢＳで検索してはどうでしょう。
WBS ですか、中々微妙なところですね。発想としては面白いですが。ちょっと勉強してみます。
NAKA さん>野球でいうと弱いチームが毎試合、打順を組み替えするみたいな感じです。
なんとも、味のある例えですね。試行錯誤のもどかしさが滲み出ています。
Kanabun さん>私の個人的な経験では Struts の工数見積はちときついです。
そうですね。フレームワークを使ったシステム開発って、フレームワークが対象となるシステムに十分メリットを出せるなら、やりやすいんですが、ミスマッチだと目も当てられない。
つまり、システムに求められる柔軟性、拡張性がフレームワークのホットスポットに適合していたら、良いのですが、要求されるカスタマイズがさりげなく、フレームワークの奥深いところまで引っ張ってこないといけない場合はしんどいですね。
戯音さん> ところでStrutsの場合、ほかと比べて何か特徴的な面が有るってことなのでしょうか？
私も Struts については余り詳しくないのですが、割とコーディングが細切れになりますよね。その細切れで上手くいく前提条件が崩れた場合とかな。例えば、・・・・
戯音さん＞＃個人的には「画面ベース」ならぬ「画面遷移ベース」のアーキテクチャは好きじゃないんだけど、それはあんまり関係ないんだろうな…
最近、RIA（Rich Internet Application） なんて略語が @IT などで、にぎわい始めていますが、 急に 画面の一割がFlash で構築することになり、画面表示用の HTML ではなく、中間データを XML をサーバーで生成して Flash へ送信しないといけなくなった場合とか。・・・
私も Struts については余り詳しくないのですが、割とコーディングが細切れになりますよね。その細切れで上手くいく前提条件が崩れた場合とかな。例えば、・・・・
戯音さん＞＃個人的には「画面ベース」ならぬ「画面遷移ベース」のアーキテクチャは好きじゃないんだけど、それはあんまり関係ないんだろうな…
最近、RIA（Rich Internet Application） なんて略語が @IT などで、にぎわい始めていますが、 急に 画面の一割がFlash で構築することになり、画面表示用の HTML ではなく、中間データを XML をサーバーで生成して Flash へ送信しないといけなくなった場合とか。・・・
戯音さん>個人的イメージ(ガントチャートじゃなく)では、機能仕様が「縦」、実装構造のレイヤが「横」、って感じかな。
でもう一つ、要因としてあげるなら、お客さんの要求仕様のうち、業務を実現するための要求と、使い勝手を良くするための要求の２種類がありますが、その辺が中途半端に関連していて、直交はしていないが、従属もしていないって感じですか。使い勝手の方は微妙にソフトウェアの構造にも影響していたりして・・・機能仕様で見ると簡単でも、画面仕様的に難しい部分の区分けって、分からせるのに案外と苦労しますよね。・・
なんて感じで、単純な機能仕様だけでは図れない部分も多いかな。最近の Web 系では。昔に比べると Web による制約条件がどんどん通用しなくなってきていますしね。・・・・
でもう一つ、要因としてあげるなら、お客さんの要求仕様のうち、業務を実現するための要求と、使い勝手を良くするための要求の２種類がありますが、その辺が中途半端に関連していて、直交はしていないが、従属もしていないって感じですか。使い勝手の方は微妙にソフトウェアの構造にも影響していたりして・・・機能仕様で見ると簡単でも、画面仕様的に難しい部分の区分けって、分からせるのに案外と苦労しますよね。・・
なんて感じで、単純な機能仕様だけでは図れない部分も多いかな。最近の Web 系では。昔に比べると Web による制約条件がどんどん通用しなくなってきていますしね。・・・・
咳さん> 基本的に全然同意できないのですが、
・・・・・うーん、どうリアクションを取ればよいのか良くわかりませんが、例えば、トピックの最初にも書いたとおり、
ハムレット>工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。
ってのは、「アート・オブ・プロジェクトマネジメント」あたりでも謳われているように思いますが。・・・勘違いしていますか。
結局、従来の工程表も、慣れ親しんだものなんで、説明に使うには便利だとは思うんですがね。（開発経緯を視覚的に表現して、これからを考えると言う意味では。・・・）
このトピックで問題にしているのは、最初から精度の高い工数見積もりを行うことではありませんが。なんか誤解されてるかな・・・・・・・
咳さん>* Scrum
咳さん>* 計画ゲーム
成功の要因が暗黙知である可能性が高いと、単に本に書いてあることを真似ても、火傷して終わりそうに思えてしまいます。・・・
メタファや見立で、プロセスを説明すると確かに物語を読むみたいな感じで分かりやすいし、東洋思想的に物事の本質を掴んで行くことも可能かもしれません。・・・が、なんか設計や製造の対象となるソフトウェアのその物の何かを見落としているような気もするのですが。・・・・
・・・・・うーん、どうリアクションを取ればよいのか良くわかりませんが、例えば、トピックの最初にも書いたとおり、
ハムレット>工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。
ってのは、「アート・オブ・プロジェクトマネジメント」あたりでも謳われているように思いますが。・・・勘違いしていますか。
結局、従来の工程表も、慣れ親しんだものなんで、説明に使うには便利だとは思うんですがね。（開発経緯を視覚的に表現して、これからを考えると言う意味では。・・・）
このトピックで問題にしているのは、最初から精度の高い工数見積もりを行うことではありませんが。なんか誤解されてるかな・・・・・・・
咳さん>* Scrum
咳さん>* 計画ゲーム
成功の要因が暗黙知である可能性が高いと、単に本に書いてあることを真似ても、火傷して終わりそうに思えてしまいます。・・・
メタファや見立で、プロセスを説明すると確かに物語を読むみたいな感じで分かりやすいし、東洋思想的に物事の本質を掴んで行くことも可能かもしれません。・・・が、なんか設計や製造の対象となるソフトウェアのその物の何かを見落としているような気もするのですが。・・・・
> 成功の要因が暗黙知である可能性が高いと、単に本に書いてあることを真似ても、火傷して終わりそうに思えてしまいます。・・・
「本に書いてあることを真似」ることを推してる本、
ありましたか？たぶん、そういうのは外して推薦した
つもりです。まちがったかな。
それから、成功の要因は圧倒的に暗黙知であると信じています。
どうやって暗黙知を育てるかがリーダの力量というか仕事です。
形式知は暗黙知を育てる養分の一つですね。
> 工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。ですが、ソフトウェア開発を対象に工程の最適化を主題に扱った、資料なり、本って探した範囲では全然見つかっていません。だれも研究対象にしていないのかな。IBM の研究所報告でも詳しく探せば出てくるのかな。元々、なぜか精度の低い工程表でもなんら問題にならないのが、この業界の体質なのかな。土木や建築なら積算やスケジュールリングだけでも、何冊も教本があるんですよね。さてこの差はどこから来るのでしょう。
教本を探しているのかと思いましたが、そうでしょうか？
だとすると基本的なところで同意できないです。
> システムの状況に応じて
具体的な開発の状況に合わせて最適化する、ということであれば
無数にある具体的な状況ごとの教本は手に入らないと信じます。
一方、もうちょっと俯瞰したようなメタな視点で議論している文
章は先ほど上げたように手に入れやすいと思います。また、
具体的な状況下での事例なんかもよく見つかります。
たくさんある「具体的な状況での事例」と自分の経験を元に
メタな視点での議論を参考にして自分で考えるのが好きです。
ハムレットさんはすでに自分で考えて自分でやってるよう
ですから、教本なんて要らないだろうし、なぜないのか、
っていうことにも気づいてるのではないでしょうか。
「本に書いてあることを真似」ることを推してる本、
ありましたか？たぶん、そういうのは外して推薦した
つもりです。まちがったかな。
それから、成功の要因は圧倒的に暗黙知であると信じています。
どうやって暗黙知を育てるかがリーダの力量というか仕事です。
形式知は暗黙知を育てる養分の一つですね。
> 工程表も生き物で、システムの状況に応じて、最適化させていく必要があるもんだと思います。ですが、ソフトウェア開発を対象に工程の最適化を主題に扱った、資料なり、本って探した範囲では全然見つかっていません。だれも研究対象にしていないのかな。IBM の研究所報告でも詳しく探せば出てくるのかな。元々、なぜか精度の低い工程表でもなんら問題にならないのが、この業界の体質なのかな。土木や建築なら積算やスケジュールリングだけでも、何冊も教本があるんですよね。さてこの差はどこから来るのでしょう。
教本を探しているのかと思いましたが、そうでしょうか？
だとすると基本的なところで同意できないです。
> システムの状況に応じて
具体的な開発の状況に合わせて最適化する、ということであれば
無数にある具体的な状況ごとの教本は手に入らないと信じます。
一方、もうちょっと俯瞰したようなメタな視点で議論している文
章は先ほど上げたように手に入れやすいと思います。また、
具体的な状況下での事例なんかもよく見つかります。
たくさんある「具体的な状況での事例」と自分の経験を元に
メタな視点での議論を参考にして自分で考えるのが好きです。
ハムレットさんはすでに自分で考えて自分でやってるよう
ですから、教本なんて要らないだろうし、なぜないのか、
っていうことにも気づいてるのではないでしょうか。
> 後は項目ごとの粒度でしょうか。明らかに項目が違うものは分けないといけないし、作業量が多いものは、分割しないといけません。
素晴らしい！
ただ分割コストをどうやって捻出するかが課題と思います。結構かかるので。
> 明らかにレイヤごとに専門家を作るような体制を敷いたほうが効率は良さそうかなと思うしだいです。
コレも素晴らしい！！
レイヤと業務の関心は競合しないので、マトリクス体制を組めます。
業務チームが苦しむ原因は実装の知識不足であることが多いので、レイヤチームの支援で作業効率は上がります。
そして、本当に素晴らしいのは、マトリクス体制により作業効率以上に品質が向上するということです。僕はむしろこちらの効果の方が重要と思っています。
さらに、レビューやペアプロを積極的に導入すれば、技術者のスキルやモチベーションも「確実に」アップします。コレも作業効率の品質の向上に貢献します。
良いことばかりです。
素晴らしい！
ただ分割コストをどうやって捻出するかが課題と思います。結構かかるので。
> 明らかにレイヤごとに専門家を作るような体制を敷いたほうが効率は良さそうかなと思うしだいです。
コレも素晴らしい！！
レイヤと業務の関心は競合しないので、マトリクス体制を組めます。
業務チームが苦しむ原因は実装の知識不足であることが多いので、レイヤチームの支援で作業効率は上がります。
そして、本当に素晴らしいのは、マトリクス体制により作業効率以上に品質が向上するということです。僕はむしろこちらの効果の方が重要と思っています。
さらに、レビューやペアプロを積極的に導入すれば、技術者のスキルやモチベーションも「確実に」アップします。コレも作業効率の品質の向上に貢献します。
良いことばかりです。
はじめまして。KZOO(清十郎)ともうします。
＞ちと火を噴きそうなプロジェクトにＰＭとして、途中から投入されました。
私と一緒ですね（ｗ
しかも、そのプロジェクトもStruts使ってました。
さて、私なんかは、現場叩上げで、独学で勉強したり、経験して、すっかり火消し屋になってしまっている訳なんですが、その中から、少しご参考になればと思い記載させていただきます。
まず、線引きですが、これに捉われると足元をすくわれます。
何故かというと、普通にWBSなり何なりを書いて線を引くと、作業が固定化されてしまい、リソースの柔軟な投入が難しくなるからです。簡単に言うと、火を吹いたプロジェクトでは、スケ線は、硬すぎてしまいます。
火を噴くということは、何か原因があるはずです。
まず、そのヒントを探る事をお薦めします。
＜要件の整理＞
・利害関係者が明確になっているか
・システムの目的が明確になっているか
・システムの満たすべき最小要件は何か
＜状況の把握＞
・使えるリソースはどれくらいあるか
・使えるリソース毎、どのくらいの技量／スピードを持っているか(特徴をつかむ)
・現在、各リソースが抱えている作業がどのくらいあるか
⇒各自、時間を作ってもらって、自分がやっている作業とシステムに関して感じるリスクをとにかくたくさん書き出してもらうといいと思います。
＜対応＞
・作業項目の整理は、WBSを基本的に構築する
・WBSは最初の内、作業粒度を安定させることが難しいので、大項目として扱い、後で、アクションレベルに分解すれば良い。(GTDの考え方を取り入れます)
・リスクの分析を行い、リスク潰しを行います。
・チーム内で、できる人間を遊撃隊として、遊兵化して、チーム内のリスク回避、突発的な問題点の回避、できない要員のサポート／教育に充当する
＜線引き＞
ここまで来てようやく線引きです。但し、バッファを上手に使う作ることをお勧めします。
私の場合、フェーズもしくは、イレテーション毎に、そのその作業量の0.5から1.0をバッファとして各作業に含有させます。
＜調整＞
これでできた線で、顧客と調整に入ります。
実際、期限に間に合うのか。間に合わないなら、何を先に提供するのか。等々、ここが、PMの交渉力の見せ所です。(営業とは、先にネゴをとって、同席してもらいましょう)
＜チームの生産性＞
チームの生産性を上げたいならば、とにかくコミュニケーションです。明るい職場を作りましょう。
後は、各メンバーに、ゴールを明確に定義してあげましょう。
ゴールのないマラソンは、モチベーションを絶対に下げます。
＜コスト＞
コスト面の工夫は、色々必要ですが、状況により異なるので割愛します。
あと、ちょっとしたテクニックですが、進捗の報告は、『後、何日(何時間)かかるか』という聞き方にした方がいいと思います。これにより、進捗が90％で足踏みすることが少なくなります。
書きながら思いました。。。
オイラが書いてるの、全然、ソフトウェア工学じゃないや（泣
＞ちと火を噴きそうなプロジェクトにＰＭとして、途中から投入されました。
私と一緒ですね（ｗ
しかも、そのプロジェクトもStruts使ってました。
さて、私なんかは、現場叩上げで、独学で勉強したり、経験して、すっかり火消し屋になってしまっている訳なんですが、その中から、少しご参考になればと思い記載させていただきます。
まず、線引きですが、これに捉われると足元をすくわれます。
何故かというと、普通にWBSなり何なりを書いて線を引くと、作業が固定化されてしまい、リソースの柔軟な投入が難しくなるからです。簡単に言うと、火を吹いたプロジェクトでは、スケ線は、硬すぎてしまいます。
火を噴くということは、何か原因があるはずです。
まず、そのヒントを探る事をお薦めします。
＜要件の整理＞
・利害関係者が明確になっているか
・システムの目的が明確になっているか
・システムの満たすべき最小要件は何か
＜状況の把握＞
・使えるリソースはどれくらいあるか
・使えるリソース毎、どのくらいの技量／スピードを持っているか(特徴をつかむ)
・現在、各リソースが抱えている作業がどのくらいあるか
⇒各自、時間を作ってもらって、自分がやっている作業とシステムに関して感じるリスクをとにかくたくさん書き出してもらうといいと思います。
＜対応＞
・作業項目の整理は、WBSを基本的に構築する
・WBSは最初の内、作業粒度を安定させることが難しいので、大項目として扱い、後で、アクションレベルに分解すれば良い。(GTDの考え方を取り入れます)
・リスクの分析を行い、リスク潰しを行います。
・チーム内で、できる人間を遊撃隊として、遊兵化して、チーム内のリスク回避、突発的な問題点の回避、できない要員のサポート／教育に充当する
＜線引き＞
ここまで来てようやく線引きです。但し、バッファを上手に使う作ることをお勧めします。
私の場合、フェーズもしくは、イレテーション毎に、そのその作業量の0.5から1.0をバッファとして各作業に含有させます。
＜調整＞
これでできた線で、顧客と調整に入ります。
実際、期限に間に合うのか。間に合わないなら、何を先に提供するのか。等々、ここが、PMの交渉力の見せ所です。(営業とは、先にネゴをとって、同席してもらいましょう)
＜チームの生産性＞
チームの生産性を上げたいならば、とにかくコミュニケーションです。明るい職場を作りましょう。
後は、各メンバーに、ゴールを明確に定義してあげましょう。
ゴールのないマラソンは、モチベーションを絶対に下げます。
＜コスト＞
コスト面の工夫は、色々必要ですが、状況により異なるので割愛します。
あと、ちょっとしたテクニックですが、進捗の報告は、『後、何日(何時間)かかるか』という聞き方にした方がいいと思います。これにより、進捗が90％で足踏みすることが少なくなります。
書きながら思いました。。。
オイラが書いてるの、全然、ソフトウェア工学じゃないや（泣
どうも、管理人です。
ちと、忙しかったり、体調崩したりで、何なのですが。気になった部分があるので。
おとんさん>ブルックス先生の人月の神話を引用するまでもなく、ソフトウェアが本質的に複雑で、同調的で、不可視で、柔軟だからでしょうね。
うーん、確かにブルックス先生は「銀の弾丸」は存在しないと言っていますが、だからと言って「狼男」は倒せないとは言っていないような。この「銀の弾丸」の例えは短絡的に誤解されやすいかな思います。
少なくともソフトウェアの開発プロセスが工学的な研究の対象に上がるなら、製品（プロダクト）開発の三要素である、QCD （品質、コスト、納期）に対して、もう少し定量的に真正面から向き合うような研究がもっと注目を浴びても良いのではと思うのです。
前にも別のトピックでも上げましたが、オブジェクト指向におけるデザインパターンが世の中に紹介されはじめた時、GoF の「デザインパターン」カタログによる博物学的なアプローチと、Wolfgang Pree らによる、メタパターンの導入による分析的なアプローチが在りました。どちらが上かという問題ではなく、互いにデザインパターンの理解を深め、発展させる上では相補的な役割を担っていたと思います。現状は、GoF の「デザインパターン」は版を重ね、W. Pree の「デザインパターン・プログラミング」は絶版の憂き目にあっています。なんか個人的には非常に残念なんですよね。ソフトウェアという抽象度の高い対象を扱う反動か、こうした分析的で、抽象度を上げた物の見方に対して、変な偏見があるように思えるのです。
私は偶然にも W. Pree の「デザインパターン・プログラミング」から、デザインパターンを学習したのですが、個人的にはこれが非常に幸いしました。オブジェクト指向のクラス間の継承と包括関係の組み合わせで、システム全体のホットスポットと固定点に着目したソフトウェアの構造設計の方法が分析的に解説されてました。この本を読んだおかげで、「あるパターンをどのような状況で使うのが効果的で、その効果を十二分に引き出すにはどのようにすべきか」そうしたことを考えるきっかけを得たのですから。
元ネタに戻して、話をするなら、要するにデザインパターンがソフトウェア開発における、納期と品質を同時に向上させるためのモジュール設計の方法論なら、単純なアンチパターンの提示だけで終わらずに、応用に関する検証や省察を行い、どうすればより効果を出すことが出来るか、Tips や How To ではなく、もっと体系的に示す努力が必要なんじゃないかな。
なんでこんなことを考えるようになったかと言えば、やはり会社で話を聞いていると「デザインパターン」の必要性については、みんな合意してくれるのですが、なんか「カタログ」引っ張ってきて、とりあえず使ってみると言う感じで、なんか使うことが自己目的化しているような気がするのです。「違うだろう」と突っ込みを入れたくなるのですが、どうも少数派みたいですね。そこで突っ込む必要性を実感している人は。
そう言う意味では、現在の「パターン」の列挙とそのカタログ化一辺倒のパターン研究のあり方については、個人的に疑問に思うことも多いです。（不要だとは言いませんが、偏っているように思います。）
いつ使うべきか、なぜメリットが出るのか。Struts のような Web 系での擬似 MVC モデルを使う場合でも、対象となるシステムの性質から、その特徴を生かしてどう効果を出すのか。それを具体的に考えるのは、多分、モジュール設計の結果を使って、工程の分担と線引きを行う場面だと思っています。
手始めに考えるなら、対象となるシステムの変更のある部分と固定的な部分を見極めた上で、MVC のフレームワークにその固定点をどう乗っけるかを考えたなら、システムの詳細仕様が固まらなくても、固定点を共通モジュールの実装として開始することも可能だと思います。
こう言うのって、線引きの問題だと思うのですが。どうなんでしょうね。まー現実、火を噴きかけたプロジェクトに途中から参加だと、やり直しになるので、手遅れな場合も多いのですが。ただ悔しいので、もし最初からやるなら、その辺で線引きの仕方を見直したいと思う今日この頃です。ただアイデアとして漠然でまとまっていないので、「ソフトウェア工学」のネタ
としてトピックを上げたわけです。
ではでは。引き続き、御意見をよろしくお願いいたします。
ちと、忙しかったり、体調崩したりで、何なのですが。気になった部分があるので。
おとんさん>ブルックス先生の人月の神話を引用するまでもなく、ソフトウェアが本質的に複雑で、同調的で、不可視で、柔軟だからでしょうね。
うーん、確かにブルックス先生は「銀の弾丸」は存在しないと言っていますが、だからと言って「狼男」は倒せないとは言っていないような。この「銀の弾丸」の例えは短絡的に誤解されやすいかな思います。
少なくともソフトウェアの開発プロセスが工学的な研究の対象に上がるなら、製品（プロダクト）開発の三要素である、QCD （品質、コスト、納期）に対して、もう少し定量的に真正面から向き合うような研究がもっと注目を浴びても良いのではと思うのです。
前にも別のトピックでも上げましたが、オブジェクト指向におけるデザインパターンが世の中に紹介されはじめた時、GoF の「デザインパターン」カタログによる博物学的なアプローチと、Wolfgang Pree らによる、メタパターンの導入による分析的なアプローチが在りました。どちらが上かという問題ではなく、互いにデザインパターンの理解を深め、発展させる上では相補的な役割を担っていたと思います。現状は、GoF の「デザインパターン」は版を重ね、W. Pree の「デザインパターン・プログラミング」は絶版の憂き目にあっています。なんか個人的には非常に残念なんですよね。ソフトウェアという抽象度の高い対象を扱う反動か、こうした分析的で、抽象度を上げた物の見方に対して、変な偏見があるように思えるのです。
私は偶然にも W. Pree の「デザインパターン・プログラミング」から、デザインパターンを学習したのですが、個人的にはこれが非常に幸いしました。オブジェクト指向のクラス間の継承と包括関係の組み合わせで、システム全体のホットスポットと固定点に着目したソフトウェアの構造設計の方法が分析的に解説されてました。この本を読んだおかげで、「あるパターンをどのような状況で使うのが効果的で、その効果を十二分に引き出すにはどのようにすべきか」そうしたことを考えるきっかけを得たのですから。
元ネタに戻して、話をするなら、要するにデザインパターンがソフトウェア開発における、納期と品質を同時に向上させるためのモジュール設計の方法論なら、単純なアンチパターンの提示だけで終わらずに、応用に関する検証や省察を行い、どうすればより効果を出すことが出来るか、Tips や How To ではなく、もっと体系的に示す努力が必要なんじゃないかな。
なんでこんなことを考えるようになったかと言えば、やはり会社で話を聞いていると「デザインパターン」の必要性については、みんな合意してくれるのですが、なんか「カタログ」引っ張ってきて、とりあえず使ってみると言う感じで、なんか使うことが自己目的化しているような気がするのです。「違うだろう」と突っ込みを入れたくなるのですが、どうも少数派みたいですね。そこで突っ込む必要性を実感している人は。
そう言う意味では、現在の「パターン」の列挙とそのカタログ化一辺倒のパターン研究のあり方については、個人的に疑問に思うことも多いです。（不要だとは言いませんが、偏っているように思います。）
いつ使うべきか、なぜメリットが出るのか。Struts のような Web 系での擬似 MVC モデルを使う場合でも、対象となるシステムの性質から、その特徴を生かしてどう効果を出すのか。それを具体的に考えるのは、多分、モジュール設計の結果を使って、工程の分担と線引きを行う場面だと思っています。
手始めに考えるなら、対象となるシステムの変更のある部分と固定的な部分を見極めた上で、MVC のフレームワークにその固定点をどう乗っけるかを考えたなら、システムの詳細仕様が固まらなくても、固定点を共通モジュールの実装として開始することも可能だと思います。
こう言うのって、線引きの問題だと思うのですが。どうなんでしょうね。まー現実、火を噴きかけたプロジェクトに途中から参加だと、やり直しになるので、手遅れな場合も多いのですが。ただ悔しいので、もし最初からやるなら、その辺で線引きの仕方を見直したいと思う今日この頃です。ただアイデアとして漠然でまとまっていないので、「ソフトウェア工学」のネタ
としてトピックを上げたわけです。
ではでは。引き続き、御意見をよろしくお願いいたします。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
ソフトウェア工学 更新情報
-
最新のアンケート
-
まだ何もありません
-
