東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

「護送船団方式」と「属人性の排除」

ネタ元 → 1メソッドは 50行以内

んー...理解できるが納得できないルール。
縛りを与えておかないとヘタな奴がだらだらとベタ書きしますか。

護送船団方式てぇやつですわね。

護送船団 :
  船団の中で最も速度の遅い船に速度を合わせて、全体が統制を確保しつつ進んでいくこと

まぁ、いちばん遅い船にみんながあわせれば落伍者は出ないでしょうけどねぇ...

TechEd2008のBoFで「属人性の排除」の話が出たんです。
特定の誰とかさんじゃなきゃ知らない/できない事をなくしましょう、と。
それが望ましいことだとは思います。
が、ともすると護送船団方式になりそうで怖い。
誰もができる→ダメダメな奴でもできる→できん子に足並み揃える
てーことになりゃせんかと心配します。

[追記]
思うにそもそもcreativeな作業を必要とするところに
属人性の排除を求めていいものかしら。
それは個々のcreativityを押し殺せと命じるに等しいんじゃないかしら。
青写真通りに組み立てる製造ラインならともかくも、
研究部門から属人性を抜いたらそりゃまさしく"骨抜き"ですよね。
ソフト屋さんのお仕事には製造ライン的なとこもあれば研究部門的な
とこもありますよねぇ。

「誰にもできるはずのこと」を誰にもできるようにしようって意味での
属人性の排除であれば賛成します。
個々のcreativityを発揮するのに足枷となる(誰にもできるはずの)雑事
から開放され、「ヤツにしかできないこと」を存分にやらせてあげられるなら。

してみると「1メソッドは 50行以内」ってなルールが設けられるのは
「codingはcreativeな工程じゃない」ってことでしょか。
coding大好きなεπιには寂しいなー...

投稿日時 : 2008年11月21日 10:29

コメントを追加

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 12:30 ちゅき

ググレカス先生にお伺いしたら、下記のBoFが引っかかった。小高さんのセッション聞いてたorz。どんな話だったんだろうか。

■BOF ・プログラミング! プログラミング! プログラミング! .NET 3.5 時代のコーディング ~ これからの実装技術について考えよう ~

>が、ともすると護送船団方式になりそうで怖い。
>誰もができる→ダメダメな奴でもできる→できん子に足並み揃える

低いレベルに合わせて保護ってとこまではいかないかも...安くてそれなりの技術者って、世界で探せばそれなりにいるのである程度は切り捨てられるような希ガス。
#むしろ、創造性を排除する方向がどんどん進み、単純作業になって面白みがなくなっていく方がヤダ。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 12:37 Mr.T

この「できん子」にあわせるってのは
もうひとつセットにせんといかんと
思います。
「できん子を引き上げる」

これができなければ、属人性の排除は
意味がねーと思ってます。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 12:53 Ognac

プロマネ側にも言い分があって、下を引き上げるコスト負担と、期間を使うことの是非。
ソースの品質(コードの書き方の面で)は低くても、確実に動くものが、製品であるという認識が根強いためと思われ.....

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 13:15 みきぬ

「引き上げてもできん子は切り捨てる」という非情の決断も必要だよね。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 14:03 凪瀬

「属人性」と「属技能性」を一緒にしちゃダメだよね。「属人性の排除」という大義名分を掲げてテクノロジーを排除するのは反対だなぁ。

大型車両の免許が取れないから、10tトラックじゃなくて軽トラックを使いましょう、車の免許がとれないからトラックじゃなくて猫車を使いましょう、って言われても・・・。

ま、免許持ってる人が複数いるなら、その人らの誰でもできるようにしておく「属人性の排除」は望ましいと思いますけどね。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 14:04 επιστημη

笑えない話がありましてね。

多くの設計/実装を外注さん/派遣さんに依存し、
身内は管理にリソースのほとんどを費やすあまり、
技術的にできん子を切り捨てると身内がいなくなる、なんてな。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 17:02 ネタ好き未記入

これって、出来ない子を保護していたら技術力が落ちるんじゃ・・・
出来ない人にあわす技術者って何なんだろう・・・
プロは学習して当たり前。
出来ない子にあわすのではなく、出来ない子が学習しないのならばクビにすればいいと思います。
こんなことしていれば、技術者なんて要りません。
コードジェネレータで十分です。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 17:16 ネタ好き未記入

>笑えない話がありましてね。

心当たりがあります
。もうありすぎて困るぐらいです。
私に丸投げしてくる自称IT会社が殆ど情報について何も知らないのはこれだったのですね。
この業界って何もしないほうが儲かりますよねorz
実質作業時間0で億単位のお金が簡単に儲かるのですから止められませんよね。
私は死んでも真似したくありませんがw

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 17:22 HiJun

だから、会社からは 底上げの為に教育しろと
いわれるわけですね。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 18:12 ネタ好き未記入

ところで、こういった「レベルを下げる」行為はどこまで進むのでしょうね・・・
以前 επιστημηさんが「調理が出来ない新人に合わせてレトルトをお客に出すのか?」というふうな事を言っていたのが頭を過ぎりました。
先週「漢字が読めない新人で困る」ととあるIT会社がコメントしたというニュースを耳にしました。
極端な話し護送船団方式で行けば、設計書を全てひらがな、もしくは、全ての漢字にルビを振り、全コードにコメントを書く羽目になりそうです。
実際はこんな極端な事は起きないでしょうが、どこまで低レベルに合わすのかと疑問に思えてなりません。
それに、50行以内にするって事は、馬鹿新人がメソッドを50個ぐらい作ったりする恐れがありますね。
そんな被害はどうするのでしょうか・・・
ああ、馬鹿馬鹿しい。
レベルの低い方にあわせて本気を出せない技術者って一体何なのでしょうか・・・

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 19:06 Ognac

規約に「読みやすいコードで記述せよ」というのがありますが、読みやすさの判定って難しいでしょう。
初心者に読みやすいのと、ベテランに読みやすいのでは、違いますし。
テクニカルなエレガンス性が高いと、読める人か少なくなります。それを読みやすいと評価するか、読みにくいと評価するかは分かれます。
業務アプリ界では、「読みにくい」と判断するようです。

ソフトウエアー工場化計画というのが昔あって、誰が作っても同じ品質を目指そうとした形跡があります。
無意味で無駄な感じですが、当事者は真剣に議論したようです、過去のΣ計画もそうでしたが、技術の進歩を考慮しない行為だと考えます。
家内制手工業であるうちは、人が資本であり、人の技術度が製品を左右すると考えます。
 一部のSIerはそうではなく、ソフト工場を目指しているようですが、内実はお寒いようですよ。

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 19:28 菊池

追記を見て思ったのですが…

「属人性の排除」が「人間性の排除」にまで行ってしまってるケースが結構ある気がしますね。

機械的にやればできるよ! =人間性なくても大丈夫

こんな場合は、それを人にやらせるんじゃなくてコードジェネレータを作る自分はあまり苦しまずに済んでますけど。
機械でできる事を機械にやらせるためにプログラマになったのに機械のように扱われる、そこのギャップの様な気がします。

1メソッドが50行以内という基準そのものはあまり悪くないと思います。それを超えるようなら創意工夫してメソッドの括りだしとかしてコードの整理という作業をしましょうよっていう線引きとしては非常に妥当な値じゃないでしょうか。
コードの整理作業っていう事を言われないとできない怠惰な人が居る事を前提にすれば基準つけとかなきゃ駄目だろうし、居ないならそんな基準は要らないとも思いますけど。

ルールはできない奴の為に作られるって面では規約の項目数は駄目な人の数に正比例すると思います。駄目な人の割合はどこでもたいして変わらないとすると、人数の多い大手にはそれだけ人数が居るので、無意味な規約も含めて多くあるのは仕方がないと思います。

# できるヤツから離れていく 2008/11/21 19:31 何となく Blog by Jitta

できるヤツから離れていく

# re: 「護送船団方式」と「属人性の排除」 2008/11/21 21:46 ネタ好き未記入

そもそも生産性を上げるためのチーム開発で生産性を下げてどうするのでしょうか?
出来ん子に合わすのは勘違いも甚だしいと思います。
というか「出来ん子」を何時までも放置していれば、生産性と品質が低下する一方です。
#でも人月単価だから儲かるかw
出来ん子をちゃんと育てましょう。
それにそもそもお客不在の視点だとしか思えません。
お客様が出来ない人の作ったものを望んでいるとは到底思えません。
お客を無視していたらこの業界が見限られると思えてなりません。

# re: 1メソッドは 50行以内 2008/11/22 0:17 Ognacの雑感

re: 1メソッドは 50行以内

# re: 「護送船団方式」と「属人性の排除」 2008/11/22 13:10 biac

「属人性の排除」 ってのは、 誰がやっても、 同じ時間・同じリソースの消費で、 同じ品質のものが出来あがる、 ってことです。 それが可能ならば、 誰が読んでも同じことが出来るという、 マニュアルが書けるハズ。 ということは、 それを自動化することも原理的には可能なハズ。

一定の品質を求められる大量生産工場では、 属人性の排除が、 コスト削減と並んで大きな目標のひとつです。 それが可能なことは、 完全無人化工場が存在することで証明されていると思います。

さて、 ソフトウェア開発も属人性を排除できるのか? もしも排除可能であるとなれば、 テスターやプログラマの仕事から要件定義をやる SE の仕事まで、 すべて自動化可能であるということになりまする。

↓このへんにも、 おなじよーなことを書きました。 f(^^;
http://d.hatena.ne.jp/kkamegawa/comment?date=20080830&section=p1#c
http://bluewatersoft.cocolog-nifty.com/blog/2008/07/post_0236.html

# re: 「護送船団方式」と「属人性の排除」 2008/11/23 1:26 biac

ヱビス飲んでる勢いで、 エピさんとこで、 もうちっと f(^^;

あとね。 「属人性は排除できるハズだ!」 って主張は、 もう一歩進めるとね、 「属社性も排除できるハズだ!」 ってことになるんですよ。
つまり、 どこの会社でやっても、 同じコストで同じモノが出来上がるハズだ …とね。

どこのソフトウェア開発会社に依頼しようと、 同じ値段で同じ品質のプログラムが完成するわけですよ。 属社性が排除できればね。

それを工業製品の新製品に当てはめて想像してみてください。
トヨタもホンダも、 同じカタチの新型車を同じ値段で発売する。 ソニーとパナソニックが、 同じ機能の新製品を同じ値段で発売する。 …そんな世界が来ると思えますか?

さて。
前のコメントでは、 「大量生産をする工場では、 属人性の排除が可能」 と書きました。 しかし、 ここでは、 属人性を発展させた属社性の排除は、 ありえないだろうというようなことを書きました。
矛盾したことを言ってると思いますか? それとも、 ここが違うから結論も違うんだ、 という理由を見つけられますか?

# re: 「護送船団方式」と「属人性の排除」 2008/11/23 9:34 Ognac

「属人性は排除」の矛盾問題を説明出来ないのですが、感覚的には、
同じ機能定義書で「松下とソニー」や『日産とトヨタ」に依頼したとして、同じものが納品されるか....ですよね。
属人性を排除すれば、同一の定義書から作成したら、(AさんもBさんも)色・形・重量か同じものを創出する...ことになりますよね。
コメントにありましたように、こうなると、製品ジェネレータになってしまいます。
独自性や個性というメンタル面を持ち出すと、論理がブレルのですが、思考や意思と作業を切り離して、マニュアル化が可能な分野は、製品形態が完成された分野だと考えています。
標準化という媚薬が足を引っ張る結果になる例は多くあります。
非論理的に大仰表現すれずメーカー各社の付加価値の否定は全体主義に繋がります。業界発展を止めます。
世界規約を結んでも、 OracleとMSで解釈や実装か異なり混沌を招きます(Unicodeなども)
 人を拘束するのは不可能............うん。 なんかピント外れのコメントになってしまいました。ゴメンナサイ。

# re: 「護送船団方式」と「属人性の排除」 2008/11/23 12:48 ネタ好き未記入

biacさんが仰ったことは可能だと思います。
私自身がジェネレーターの特許を出願したことがありますので(新人レベルぐらいならば)可能である事が分かっています。

# re: 「護送船団方式」と「属人性の排除」 2008/11/23 12:50 ネタ好き未記入

だから、新人教育が大事なのです。
私ごときが作れるものが、他者が作れないとは思えません。
来年にでも製品ジェネレーターが発売されても私は「思ったより遅かったね」と思うだけです。
私が発明を思いついたのは2002年ぐらいなので今でも実現されないことが不思議だと考えています。

# re: 「護送船団方式」と「属人性の排除」 2008/11/25 11:16 ちゅき

>ソフト屋さんのお仕事には製造ライン的なとこもあれば研究部門的なとこもありますよねぇ。

その役割を分離する方向で進んでいるのだと思われ。


# re: 「護送船団方式」と「属人性の排除」 2008/11/25 12:45 biac

さて… と f(^^;

> TechEd2008のBoFで「属人性の排除」の話が出たんです。
> 特定の誰とかさんじゃなきゃ知らない/できない事をなくしましょう、と。

なくしましょう、 っていうのを、 「全員が同じことをできるように」 って意味に捉えると、 「属人性の排除」 となり、 完璧なマニュアルのもとに全員が同じことをやる、 ってことになっちゃいます。

でもね。 実際の開発チームは、 そんな必要ないのよ。 たとえば、 プロジェクトリーダーは、 一人居ればいいわけ。 全員がプロジェクトリーダーの仕事を同じように出来ないとダメですか? そんなバカな。

しかし。 「特定の誰とかさんじゃなきゃ知らない/できない事をなくしましょう」 というのが、 「トラック・ナンバーが 1 じゃマズイよね」 という意味なら、 わかります。

「トラック・ナンバー」 というのは、 物騒な言い方なんですが、 そのチームのうちの何人がトラックに轢かれたらプロジェクトが止まってしまうか、 という数字です。 例えば、 プロジェクトリーダーが轢かれたとき、 代りを務められるメンバーが居ないなら、 トラック・ナンバーは 1です。 開発用の DB サーバーを触れる人が 2人しかいなかったら、 トラック・ナンバーは 2です。

# re: 「護送船団方式」と「属人性の排除」 2008/11/25 12:59 biac

あ。 エピさんのココには、 突っ込んでおかんと… f(^^;

> ソフト屋さんのお仕事には製造ライン的なとこもあれば研究部門的なとこもありますよねぇ。

製造業のラインってね… わずか 3ヶ月しか経験ないけど。 f(^^;
班長以上を別とすれば、 ラインの人ってアタマはヒマなんですよ~。 もうね、 暇で暇で、 まるっきり仕事と関係無いことを考えてるの。 流れてくる品種が変わるときは、 「あ、 こいつはナニするんだっけ?」 って、 ちょっと考えるけどね。 それくらい。
※ だからこそ、 QC 活動のネタは勤務時間中に考えられるわけだけど。

さて。 まるっきり他のことを考えてて OK、 手だけ動かしてれば OK ってなソフト屋さんのお仕事って、 どんなのが…? f(^^;

# re: 「護送船団方式」と「属人性の排除」 2008/11/27 10:52 επιστημη

思うにcodingは製造工程じゃなく設計工程じゃないんかな。
どこぞのAgile本にあったんだけど、製造工程てーのは
青写真を基にモノを作る作業。codeという名の青写真を
コンパイラに食わせると実行可能なロードモジュールが
できるんだから製造工程は"build"ボタンを押してから
戻ってくるまでのわずかな時間であって、キーボード
パコパコ叩いてcodingしてるのは青写真描いてる、つまり
(粒度の細かい)設計工程じゃないのか? なんてな。

# re: 「護送船団方式」と「属人性の排除」 2008/11/27 23:40 ネタ好き未記入

LISPと同じ考え方ですね。
私も機械語こそが製造工程だと思います。

# ゆるふわ護送船団方式 2008/12/02 9:54 東方算程譚

ゆるふわ護送船団方式

# ???????????? – 2012???04???24??? « ???????????????????????????????????? 2012/04/24 10:17 Pingback/TrackBack

???????????? – 2012???04???24??? « ????????????????????????????????????

タイトル  
名前  
URL
コメント