|
|
|
|
コメント(120)
設計と実装をそれぞれ別の会社でやるから・・・？
っていうとこに落ち着けちゃうのはちょっと乱暴な気がします。
二次請の会社が設計〜結合テストを請けた場合だって内部的な体制として
設計チームと実装チームに分かれたりするんじゃないですか？
# 同じように一次請だって企画・提案チームと要件定義チームは別だったり
# します。もちろん工程が違うので両方に在籍する人もいます。
一般に上流工程の作業は下流工程に比べて少人数で詰めていく作業ですので
人海戦術的なことが通用しません。成果物の量も実装工程に比べればはるか
に少ないです。
実装工程は（きちんと設計ができていれば）人海戦術のメリットを最大に生
かすことができます。
実装工程の作業が簡単だとは言いませんが、業務知識・システム知識・実務
経験を一定レベルで要求される設計工程の作業に比べたら敷居が低いとは思
います。
もちろん実装工程で必要とされる技術も奥が深いので「極める」のは非常に
難しいですけど、全ての設計者が実装技術を極めている必要はないんじゃな
でしょうか。（これは少し上でがるサンも書いてましたね）
っていうとこに落ち着けちゃうのはちょっと乱暴な気がします。
二次請の会社が設計〜結合テストを請けた場合だって内部的な体制として
設計チームと実装チームに分かれたりするんじゃないですか？
# 同じように一次請だって企画・提案チームと要件定義チームは別だったり
# します。もちろん工程が違うので両方に在籍する人もいます。
一般に上流工程の作業は下流工程に比べて少人数で詰めていく作業ですので
人海戦術的なことが通用しません。成果物の量も実装工程に比べればはるか
に少ないです。
実装工程は（きちんと設計ができていれば）人海戦術のメリットを最大に生
かすことができます。
実装工程の作業が簡単だとは言いませんが、業務知識・システム知識・実務
経験を一定レベルで要求される設計工程の作業に比べたら敷居が低いとは思
います。
もちろん実装工程で必要とされる技術も奥が深いので「極める」のは非常に
難しいですけど、全ての設計者が実装技術を極めている必要はないんじゃな
でしょうか。（これは少し上でがるサンも書いてましたね）
>89
> 5人での詳細な設計を作るまでの時間＋100人での人海戦術コーディング時間
の方が長いという考え方なのでしょうか。
そのとおりです。
後者の「5人での詳細な設計を作るまでの時間」は、前者の「設計からコーディング完了までの時間」に匹敵すると思いますよ。
それくらい完成度の高い設計書を作らなければ、設計のできないコーダーはまともなコードを書けないはずなので。
#書けるなら、そのコーダーは設計もできるでしょう
さらに、設計書が少しでもあやふやだったとしたら、その100人のコーダーからの質問対応に設計以上の工数が必要になるでしょうね。
大人数のプロジェクトだとしても、小規模のサブプロジェクトに分割して、1チームは10人程度に抑えますよね。
> 5人での詳細な設計を作るまでの時間＋100人での人海戦術コーディング時間
の方が長いという考え方なのでしょうか。
そのとおりです。
後者の「5人での詳細な設計を作るまでの時間」は、前者の「設計からコーディング完了までの時間」に匹敵すると思いますよ。
それくらい完成度の高い設計書を作らなければ、設計のできないコーダーはまともなコードを書けないはずなので。
#書けるなら、そのコーダーは設計もできるでしょう
さらに、設計書が少しでもあやふやだったとしたら、その100人のコーダーからの質問対応に設計以上の工数が必要になるでしょうね。
大人数のプロジェクトだとしても、小規模のサブプロジェクトに分割して、1チームは10人程度に抑えますよね。
また凄い勢いで伸びていますね。
>75
>普通、実装作業ってプログラムのことでは？
>明確に区別できる状況を不思議に思う理由がわかりません。
作業の内容を区別できないという意味ではなくて、それらの作業の間の行き来が少ないことが不思議で仕方ないのです。
>76
まったく同意です。
>80
>意見を求めたのであれば、結論に至った経緯はフィードバックすべきではないでしょうか？
いつ私が結論を出しましたか？
今のところ、71さんの回答以外にはいまいち納得できていないだけの話です。
>83
>「設計者が実装者を兼ねたほうが効率がいい」というのと、
>「設計チームがそのまま実装チームになったほうが(以下同文)」というのとは、
>ちょっと意味が違うと思います。
>前者は、設計者以外の実装者も(普通は)いるわけですが、後者は実装者は全員設計者です。
>おとんさんは、前者のほうを言いたいのではないか、と思いました。
はい、正にその通りです。
フォロー有難うございました。
いったん、ここで切ります。
所用があって追いつけないので、また後でお返事させていただきます。
>75
>普通、実装作業ってプログラムのことでは？
>明確に区別できる状況を不思議に思う理由がわかりません。
作業の内容を区別できないという意味ではなくて、それらの作業の間の行き来が少ないことが不思議で仕方ないのです。
>76
まったく同意です。
>80
>意見を求めたのであれば、結論に至った経緯はフィードバックすべきではないでしょうか？
いつ私が結論を出しましたか？
今のところ、71さんの回答以外にはいまいち納得できていないだけの話です。
>83
>「設計者が実装者を兼ねたほうが効率がいい」というのと、
>「設計チームがそのまま実装チームになったほうが(以下同文)」というのとは、
>ちょっと意味が違うと思います。
>前者は、設計者以外の実装者も(普通は)いるわけですが、後者は実装者は全員設計者です。
>おとんさんは、前者のほうを言いたいのではないか、と思いました。
はい、正にその通りです。
フォロー有難うございました。
いったん、ここで切ります。
所用があって追いつけないので、また後でお返事させていただきます。
＃変なタイプミスがあったので消して書き直しました。
じつは76でNakaさんが引用されている「ソフトウェア設計とは何か？」という原稿は、ここでの私の疑問の背景にあります。この原稿は確かにアジャイル開発にも影響を与えているようで、マーティンファウラー氏の以下の文章の中でも引用されています。
「新しいソフトウエア開発手法」
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html
私は、Nakaさんが96でおっしゃったように、本質的には設計とは何かという定義がソフトウェア分野の中で成されていない、というよりまだ定義できる段階にないことが、この種の議論を難しくしている要因だと考えています。
しかし一方で、日本でも数々の巨大開発プロジェクトが実施され、そこで開発されたシステムが我々の生活や企業活動を実際に支えているわけです。そのような巨大プロジェクトでは、chunさんがおっしゃるように設計は明確にされているでしょうし、明確にできなければプロジェクト自体が成功しないでしょう。
想像するに、いくつかの条件が満たされれば設計は明確にすることができ、設計作業と実装作業の間の行き来も少なくできるのだと思います。その条件が何なのか？ということが私の疑問なのかもしれません。
といっても漠然としているので、設計を明確にできる条件の候補を私の思いつく範囲で列挙してみます。
1. 設計者集団の能力が非常に高い
2. 開発ドメイン（開発対象の領域）の歴史が長く変化が少ない
3. 新規開発が少なく保守開発が多い
4. 逆に後で再利用することを考えず、毎回、時間をかけて新規開発をしている
5. システムの各機能が比較的独立している（機能間の依存度が低い）
6. ハードウェアによる制約が強く、ソフトウェアの構成はハードウェアの構成に合わせるだけでよい
7. その他
3と6は、実際に大規模開発に携わった企業の方から聞いた話です。
逆にゲームなどの開発ではこれらの条件が満たされないようです。
じつは76でNakaさんが引用されている「ソフトウェア設計とは何か？」という原稿は、ここでの私の疑問の背景にあります。この原稿は確かにアジャイル開発にも影響を与えているようで、マーティンファウラー氏の以下の文章の中でも引用されています。
「新しいソフトウエア開発手法」
http://www007.upp.so-net.ne.jp/kengai/fowler/newMethodology_j.html
私は、Nakaさんが96でおっしゃったように、本質的には設計とは何かという定義がソフトウェア分野の中で成されていない、というよりまだ定義できる段階にないことが、この種の議論を難しくしている要因だと考えています。
しかし一方で、日本でも数々の巨大開発プロジェクトが実施され、そこで開発されたシステムが我々の生活や企業活動を実際に支えているわけです。そのような巨大プロジェクトでは、chunさんがおっしゃるように設計は明確にされているでしょうし、明確にできなければプロジェクト自体が成功しないでしょう。
想像するに、いくつかの条件が満たされれば設計は明確にすることができ、設計作業と実装作業の間の行き来も少なくできるのだと思います。その条件が何なのか？ということが私の疑問なのかもしれません。
といっても漠然としているので、設計を明確にできる条件の候補を私の思いつく範囲で列挙してみます。
1. 設計者集団の能力が非常に高い
2. 開発ドメイン（開発対象の領域）の歴史が長く変化が少ない
3. 新規開発が少なく保守開発が多い
4. 逆に後で再利用することを考えず、毎回、時間をかけて新規開発をしている
5. システムの各機能が比較的独立している（機能間の依存度が低い）
6. ハードウェアによる制約が強く、ソフトウェアの構成はハードウェアの構成に合わせるだけでよい
7. その他
3と6は、実際に大規模開発に携わった企業の方から聞いた話です。
逆にゲームなどの開発ではこれらの条件が満たされないようです。
何か面白いこと、話をしてますね。
個人的には、ソースコードが唯一の設計文書だって考え方は、オープンソースでは真実かも知れないが、お客さんから金貰って情報システム組む場合は論外だと思います。
私自身は設計重視派です。だからと言って設計者にプログラム技術は不要だとは思いません。設計したモジュールの内、難易度の高い構造を持つものやシステムのコアを担う部分については、こちらの我が儘な設計要求に応えくれる信頼できるプログラマが居ない場合は自分で組みます。少なくとも技術者として、プログラムテクニックを磨く動機付けは、自分の設計物を実現する術を身に付けておきたいと言うことでしょうか。
論議を見ていて思うのですが、これは日本のＳＩ系固有の問題かも知れませんが、ＳＥって設計とプロジェクト管理を兼ねている場合が多いですよね。この場合何かと犠牲になるのは設計品質のような気がします。
プログラマな方々が設計に対して不満を抱くのは、設計その物ではなく、実はプロジェクト管理な部分だったりしませんか。上流工程と称して、そこを混同して、切り分けがちゃんと出来ていないことの方が問題だと思うのですが。
どうなんでしょう。個人的には設計は好きですが、プロジェクト管理は苦手かもしれない。
ではでは
個人的には、ソースコードが唯一の設計文書だって考え方は、オープンソースでは真実かも知れないが、お客さんから金貰って情報システム組む場合は論外だと思います。
私自身は設計重視派です。だからと言って設計者にプログラム技術は不要だとは思いません。設計したモジュールの内、難易度の高い構造を持つものやシステムのコアを担う部分については、こちらの我が儘な設計要求に応えくれる信頼できるプログラマが居ない場合は自分で組みます。少なくとも技術者として、プログラムテクニックを磨く動機付けは、自分の設計物を実現する術を身に付けておきたいと言うことでしょうか。
論議を見ていて思うのですが、これは日本のＳＩ系固有の問題かも知れませんが、ＳＥって設計とプロジェクト管理を兼ねている場合が多いですよね。この場合何かと犠牲になるのは設計品質のような気がします。
プログラマな方々が設計に対して不満を抱くのは、設計その物ではなく、実はプロジェクト管理な部分だったりしませんか。上流工程と称して、そこを混同して、切り分けがちゃんと出来ていないことの方が問題だと思うのですが。
どうなんでしょう。個人的には設計は好きですが、プロジェクト管理は苦手かもしれない。
ではでは
>103 ほっつきむにゃむさん
>ソフトウェア工学的には設計・実装の分業ってどういう捕らえ方されてるんでしょうかね？
正確には文献を追っていかないといけませんが、オブジェクト指向の登場で捉え方が少しづつ変化してきていると思います。たとえば構造化分析、構造化設計、構造化プログラミングという分け方は、比較的厳格だったのではないでしょうか？もちろんその背景には、開発対象自体が、バッチ処理からGUIを備えたリアクティブシステムへと形を変えてきたこともあると思います。
>106 ハムレットさん
このコミュでは、はじめまして。
>設計したモジュールの内、難易度の高い構造を持つものやシステムのコアを担う部分については、こちらの我が儘な設計要求に応えくれる信頼できるプログラマが居ない場合は自分で組みます。
やはりそうですよね。本来そうするのが自然な流れだと個人的には思います。
で、ずっと、大規模なシステムには必ずそういった複雑な部分が存在するのではないかと想像していたのですが、実はそうでもないのかもしれないと思い始めて書いたのが100および101で列挙した、「設計を明確にできる条件」です。たとえば複雑な部分をフレームワーク化してきちんと再利用することができれば、それ以降のプロジェクトでは設計を簡単にすることができるでしょう。（というのは理想論で、フレームワーク化もそんなにうまくいくとも思えないのですが。。。）
>107 つねさん
>しかし、何故その意見には納得できたのか、根拠は書いていただきたいです。
>議論の場ではどちらが正しいかより、筋道の方が大事でしょう。
いえいえ、もともと議論というよりは大規模プロジェクトの経験のない私が皆様に教えていただいているという状況なのです。知らないことなので、疑問の持ちようがなければ納得するしかありませんが、71のsecretさんのご回答（と58のあき@多摩区さんのご回答）以外ではまだ疑問が残っているというだけの話です。疑問が解消すればもちろん納得するしかありません、知らないことなので。
>・設計者と実装者を分けるのは効率的か否か？
>・設計書は不要か否か？
>次元の違う二つの論点がごっちゃになっていませんか？
他にもいくつかの論点がごっちゃになっているようですね。私自身としては、今のところ「大規模プロジェクトにおいても設計者が実装まで担当する方が効率的なのではないか」という点のみ論点にしているつもりです。
>ソフトウェア工学的には設計・実装の分業ってどういう捕らえ方されてるんでしょうかね？
正確には文献を追っていかないといけませんが、オブジェクト指向の登場で捉え方が少しづつ変化してきていると思います。たとえば構造化分析、構造化設計、構造化プログラミングという分け方は、比較的厳格だったのではないでしょうか？もちろんその背景には、開発対象自体が、バッチ処理からGUIを備えたリアクティブシステムへと形を変えてきたこともあると思います。
>106 ハムレットさん
このコミュでは、はじめまして。
>設計したモジュールの内、難易度の高い構造を持つものやシステムのコアを担う部分については、こちらの我が儘な設計要求に応えくれる信頼できるプログラマが居ない場合は自分で組みます。
やはりそうですよね。本来そうするのが自然な流れだと個人的には思います。
で、ずっと、大規模なシステムには必ずそういった複雑な部分が存在するのではないかと想像していたのですが、実はそうでもないのかもしれないと思い始めて書いたのが100および101で列挙した、「設計を明確にできる条件」です。たとえば複雑な部分をフレームワーク化してきちんと再利用することができれば、それ以降のプロジェクトでは設計を簡単にすることができるでしょう。（というのは理想論で、フレームワーク化もそんなにうまくいくとも思えないのですが。。。）
>107 つねさん
>しかし、何故その意見には納得できたのか、根拠は書いていただきたいです。
>議論の場ではどちらが正しいかより、筋道の方が大事でしょう。
いえいえ、もともと議論というよりは大規模プロジェクトの経験のない私が皆様に教えていただいているという状況なのです。知らないことなので、疑問の持ちようがなければ納得するしかありませんが、71のsecretさんのご回答（と58のあき@多摩区さんのご回答）以外ではまだ疑問が残っているというだけの話です。疑問が解消すればもちろん納得するしかありません、知らないことなので。
>・設計者と実装者を分けるのは効率的か否か？
>・設計書は不要か否か？
>次元の違う二つの論点がごっちゃになっていませんか？
他にもいくつかの論点がごっちゃになっているようですね。私自身としては、今のところ「大規模プロジェクトにおいても設計者が実装まで担当する方が効率的なのではないか」という点のみ論点にしているつもりです。
>109 マイさん
>> 5. システムの各機能が比較的独立している（機能間の依存度が低い）
>大規模システムなら、この逆であることが多いでしょう。
やはりそうですよね。
>こういう時こそきちんと設計やテストの計画をしないといけないので、
>設計者が実装までやってる暇はありません。
実装段階では設計はいったん完了しているでしょうから実装中は主にテストの計画を立てているということでしょうか？それはそれで確かに重要な作業だとは思います。
ですが、機能の依存度が高い複雑なシステムの場合、ハムレットさんがおっしゃるような複数の機能が絡み合う難易度の高いモジュールがどこかに出来るはずです。そういった部分を設計だけ行って実装を他の人に任せるという方法でうまく作れるのでしょうか？
練りに練った設計であればあるほど、その情報を漏らさず他人に伝えることは困難になるはずです。複数の機能が絡み合う部分で情報伝達の漏れがあった場合、その影響がシステム全体に及ぶ危険性は高いでしょう。場合によっては大きな手戻りが発生する可能性もあります。
たとえ設計者が実装しないにせよ、そういった複雑な部分を担当する実装者は設計段階から議論に参加して、設計の背景や根拠を理解しておくべきだと思いますがいかがでしょうか？（結局これは、一部の実装者が設計作業を行っているのと似た話だと思いますが。）
>> 5. システムの各機能が比較的独立している（機能間の依存度が低い）
>大規模システムなら、この逆であることが多いでしょう。
やはりそうですよね。
>こういう時こそきちんと設計やテストの計画をしないといけないので、
>設計者が実装までやってる暇はありません。
実装段階では設計はいったん完了しているでしょうから実装中は主にテストの計画を立てているということでしょうか？それはそれで確かに重要な作業だとは思います。
ですが、機能の依存度が高い複雑なシステムの場合、ハムレットさんがおっしゃるような複数の機能が絡み合う難易度の高いモジュールがどこかに出来るはずです。そういった部分を設計だけ行って実装を他の人に任せるという方法でうまく作れるのでしょうか？
練りに練った設計であればあるほど、その情報を漏らさず他人に伝えることは困難になるはずです。複数の機能が絡み合う部分で情報伝達の漏れがあった場合、その影響がシステム全体に及ぶ危険性は高いでしょう。場合によっては大きな手戻りが発生する可能性もあります。
たとえ設計者が実装しないにせよ、そういった複雑な部分を担当する実装者は設計段階から議論に参加して、設計の背景や根拠を理解しておくべきだと思いますがいかがでしょうか？（結局これは、一部の実装者が設計作業を行っているのと似た話だと思いますが。）
おとんさん：
設計者が実装者を兼ねるのは、個人的には、信頼できる腕の立つプログラマが居ない場合です。個人的には、信頼できるプログラマとは以下の３つの条件を満たす場合を指します。
１）シンプルな（無駄の無い）コードを書ける。
２）ソースコードや設定ファイル、開発環境などの構成管理がちゃんと出来る。
３）合理的な理由をもったコーディングルールを設定して、それを尊守出来る。
といった所でしょうか。
但し、マイさんの指摘する通り、規模の大きくないプログラムならそれでも安全ですが、規模の大きなシステムの場合はそれなりにリスクヘッジを取る必要があります。私の場合なら、実装とそれに関する記述的な調整に専念するために、プロジェクト管理・制御の役割分担を他の誰かに担ってもらうような努力だと思います。規模のでかいシステムでは、設計内容によって、実装工程の順序や実装時の制約事項に顕著に影響を大きく持つようになるので、その実装工程の計画やコントロールを設計者か設計内容を十分に理解したスタッフが行う必要が有ると思います。
結局、難しい実装を担当するか、実装工程の管理につくか、又は検証工程の計画、段取りに入るかは、ケースバイケースで、どこで品質を作りこむかによるのでしょうね。重視すべき要件が、機能面だけでなく、性能や拡張性まで含むなら、コアモジュールの実装者に設計者が参加するのも、それなりに理に適っているかなという気もします。と言うか、実装担当者が設計に参加するという趣でしょうか。
ではでは
後は設計者にプログラム又はプロトタイプ
設計者が実装者を兼ねるのは、個人的には、信頼できる腕の立つプログラマが居ない場合です。個人的には、信頼できるプログラマとは以下の３つの条件を満たす場合を指します。
１）シンプルな（無駄の無い）コードを書ける。
２）ソースコードや設定ファイル、開発環境などの構成管理がちゃんと出来る。
３）合理的な理由をもったコーディングルールを設定して、それを尊守出来る。
といった所でしょうか。
但し、マイさんの指摘する通り、規模の大きくないプログラムならそれでも安全ですが、規模の大きなシステムの場合はそれなりにリスクヘッジを取る必要があります。私の場合なら、実装とそれに関する記述的な調整に専念するために、プロジェクト管理・制御の役割分担を他の誰かに担ってもらうような努力だと思います。規模のでかいシステムでは、設計内容によって、実装工程の順序や実装時の制約事項に顕著に影響を大きく持つようになるので、その実装工程の計画やコントロールを設計者か設計内容を十分に理解したスタッフが行う必要が有ると思います。
結局、難しい実装を担当するか、実装工程の管理につくか、又は検証工程の計画、段取りに入るかは、ケースバイケースで、どこで品質を作りこむかによるのでしょうね。重視すべき要件が、機能面だけでなく、性能や拡張性まで含むなら、コアモジュールの実装者に設計者が参加するのも、それなりに理に適っているかなという気もします。と言うか、実装担当者が設計に参加するという趣でしょうか。
ではでは
後は設計者にプログラム又はプロトタイプ
>113 マイさん
>実装者への情報伝達洩れであれば、プログラムだけ直せば良いですよね。
きっと心当たりがあるだろうと思って質問したのですが、何故か噛み合いませんね。プログラムだけ修正すればよいといっても、その修正する範囲が問題なのです。
システムの中にはたくさんの機能が依存する部分（モジュールやサブシステム）がありますよね。そういう部分の設計は慎重に慎重を重ねて行うべきです。なぜなら、その部分のミスが多くの機能に影響を与えてしまうからです。そういう部分で情報伝達漏れによって不具合が混入してしまうと、その部分に依存する多くの機能の実装も影響を受けてしまうでしょう。その影響がすぐにわかればよいですが、実装の最終段階やテスト工程まで発覚しなかった場合どうなるでしょうか？気がついたころには不具合がシステム各所に伝播して手の施しようがない状態になっているかもしれません。一箇所を修正すれば別の箇所で不具合が発生するといったように。
ソフトウェア工学ではこのような状況を影響波及といいます。設計者は当然、このような影響波及による混乱を避けるべく設計しているものだと思っていましたが違いますでしょうか？そうだとすれば、当然、影響範囲が広い範囲の設計は慎重に行うだけでなく、その設計どおりに実装が進んでいるか、情報伝達漏れがないかなどが気になるはずです。まず、そこが気になっていないという時点でちょっと理解できません。
>実装者への情報伝達洩れであれば、プログラムだけ直せば良いですよね。
きっと心当たりがあるだろうと思って質問したのですが、何故か噛み合いませんね。プログラムだけ修正すればよいといっても、その修正する範囲が問題なのです。
システムの中にはたくさんの機能が依存する部分（モジュールやサブシステム）がありますよね。そういう部分の設計は慎重に慎重を重ねて行うべきです。なぜなら、その部分のミスが多くの機能に影響を与えてしまうからです。そういう部分で情報伝達漏れによって不具合が混入してしまうと、その部分に依存する多くの機能の実装も影響を受けてしまうでしょう。その影響がすぐにわかればよいですが、実装の最終段階やテスト工程まで発覚しなかった場合どうなるでしょうか？気がついたころには不具合がシステム各所に伝播して手の施しようがない状態になっているかもしれません。一箇所を修正すれば別の箇所で不具合が発生するといったように。
ソフトウェア工学ではこのような状況を影響波及といいます。設計者は当然、このような影響波及による混乱を避けるべく設計しているものだと思っていましたが違いますでしょうか？そうだとすれば、当然、影響範囲が広い範囲の設計は慎重に行うだけでなく、その設計どおりに実装が進んでいるか、情報伝達漏れがないかなどが気になるはずです。まず、そこが気になっていないという時点でちょっと理解できません。
>114 ハムレットさん
>私の場合なら、実装とそれに関する記述的な調整に専念するために、プロジェクト管理・制御の役割分担を他の誰かに担ってもらうような努力だと思います。
設計者がマネージャも兼ねているわけですね。でも、マネージメント業務の多くは設計者じゃなくてもできそうな気がします。
>規模のでかいシステムでは、設計内容によって、実装工程の順序や実装時の制約事項に顕著に影響を大きく持つようになるので、その実装工程の計画やコントロールを設計者か設計内容を十分に理解したスタッフが行う必要が有ると思います。
なるほど、設計者によるそういうコントロールは確かに必要でしょうね。でも、それはむしろ設計者が実装チームと一緒に仕事をしているようなイメージですね。実装上の問題が発生しても設計者がすぐに対応できそうです。
>結局、難しい実装を担当するか、実装工程の管理につくか、又は検証工程の計画、段取りに入るかは、ケースバイケースで、どこで品質を作りこむかによるのでしょうね
うーん、もう一つしっくり来ません。確かに、「品質」や「効率」といった、プロジェクト全体を外部から評価するような尺度で考えると、そういういろんな選択肢が含まれるのかもしれませんね。とすると、「大規模プロジェクトにおいても設計者が実装まで担当する方が効率的なのではないか」という私の論の立て方自体がやはり不十分だったのかな？
>私の場合なら、実装とそれに関する記述的な調整に専念するために、プロジェクト管理・制御の役割分担を他の誰かに担ってもらうような努力だと思います。
設計者がマネージャも兼ねているわけですね。でも、マネージメント業務の多くは設計者じゃなくてもできそうな気がします。
>規模のでかいシステムでは、設計内容によって、実装工程の順序や実装時の制約事項に顕著に影響を大きく持つようになるので、その実装工程の計画やコントロールを設計者か設計内容を十分に理解したスタッフが行う必要が有ると思います。
なるほど、設計者によるそういうコントロールは確かに必要でしょうね。でも、それはむしろ設計者が実装チームと一緒に仕事をしているようなイメージですね。実装上の問題が発生しても設計者がすぐに対応できそうです。
>結局、難しい実装を担当するか、実装工程の管理につくか、又は検証工程の計画、段取りに入るかは、ケースバイケースで、どこで品質を作りこむかによるのでしょうね
うーん、もう一つしっくり来ません。確かに、「品質」や「効率」といった、プロジェクト全体を外部から評価するような尺度で考えると、そういういろんな選択肢が含まれるのかもしれませんね。とすると、「大規模プロジェクトにおいても設計者が実装まで担当する方が効率的なのではないか」という私の論の立て方自体がやはり不十分だったのかな？
横から失礼します。
＞設計者が実装まで担当する方が効率的なのではないか
本質的には、設計者が実装まで担当する方が効率的だとは思います。
ただし、
・担当者全員が要件・仕様を理解していること
・開発がスパイラル型行われ、仕様変更が「手戻り」でない。（設計変更で実装の手が止まっても大丈夫）
・設計の問題点を早期に発見するための施策が機能していること
・担当者が変わる場合も、いきなり引き継ぎ！ではなく、、仕様理解、ノウハウ継承が時間をかけて行える
・プロジェクトマネージメントは専任のものが行うこと
など、いろいろな制約事項が付くのではないでしょうか？
設計者としても実装者としても一定のレベル以上ないと、デメリットの方が大きい。
技術者としては、こういう「理想的なプロジェクト」で仕事してみたいものです。
＞設計者が実装まで担当する方が効率的なのではないか
本質的には、設計者が実装まで担当する方が効率的だとは思います。
ただし、
・担当者全員が要件・仕様を理解していること
・開発がスパイラル型行われ、仕様変更が「手戻り」でない。（設計変更で実装の手が止まっても大丈夫）
・設計の問題点を早期に発見するための施策が機能していること
・担当者が変わる場合も、いきなり引き継ぎ！ではなく、、仕様理解、ノウハウ継承が時間をかけて行える
・プロジェクトマネージメントは専任のものが行うこと
など、いろいろな制約事項が付くのではないでしょうか？
設計者としても実装者としても一定のレベル以上ないと、デメリットの方が大きい。
技術者としては、こういう「理想的なプロジェクト」で仕事してみたいものです。
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
Java 更新情報
-
最新のアンケート
-
まだ何もありません
-
Javaのメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- 千葉 ロッテマリーンズ
- 37146人
- 2位
- mixi バスケ部
- 37798人
- 3位
- Kis-My-Ft2
- 40857人