ひがやすを blog

sabro 2008/03/25 19:57 大手SIerの下で働いている、できるプログラマ（のつもり）なので、大変共感しました。
自分の仕事は早く終わるんだけど、こんな単調な仕事を他の人の分まで引き受ける気にならないので、空いた時間で、プログラミングの勉強とかしてる毎日・・・。

taga 2008/03/25 21:31 できない人はやっぱりできないという点は些か異論ありですが、縛ることで優秀なプログラマーが力を発揮できないと言う点は同意。優秀な、というか、そこそこ出来る人も力を発揮出来ないと思います。
ただ、これは時代背景として技術が生産性を今ほど高めていなかったため、ソフトウェア開発=人海戦術に近い状況だったというのがあると思います。
技術が生産性を高めた現在、やり方を考え直さなければならない人たちが多くいるのですが。

m-matsuoka 2008/03/26 01:47 できる人に任せることに同意します。
大手SIerのプロジェクトに何件も参加しましたが、コードの品質以前にドキュメントの品質が低いことが多かったです。
プログラミングをする前にドキュメントのデバッグをしなければいけなかったので、プログラマに非常に負荷かかかっていました。
上流から下流まで、できるプログラマに任せた方が効率は良くなると思います。

takano32 2008/03/26 10:17 耳が痛い話ですな。C++をbetter Cとしてしか使えていない職場より。

通りすがり 2008/03/26 12:04 重要なのは、誰もが「俺がメンテナンスできるコード」を書くこと。そのために、コーディング規約は、俺が決めてみんなで守る、それ以上は、俺が困るのでがちがちに縛る必要はない。
今の大手SIerのやり方の問題は、俺の能力を殺してしまっているところにあると思います。だめな人に失敗させないように、がちがちに縛るんだけど、だめな人はやっぱり失敗するし、俺も「誰もがメンテナンスできるコード」に縛られて力を発揮できない。
「俺がメンテナンスできるコード」にするために、俺にとって必要十分なドキュメントと俺が決めたコーディング規約を守る以外は、俺の自由にさせた方が、俺の生産性はきっとあがるよね。

こうですか！？ わかりません！

kakkii 2008/03/26 18:54 ハイエクは「人々を平等に取り扱うことは自由な社会の条件であるのに対して、人々を平等たらしめようとすることは、隷従への道を意味する」と言いました。「誰が書いても同じコード」というのは後者であるように思います。すなわち、個人の発想力とか独自性を殺して、制度運用側の想定の範囲内に押し留めてしまうのだと思います。

Nobuo 2008/03/26 19:53 「誰が書いても同じコード」っていうことが実現するなら、「じゃぁ、一番原価の安い人に頼もう」ってことですよね。同じコードなら安い方がいいもの。
それが出来ないから、みんな給料が違うんだと思ってました(笑)

Kow 2008/03/26 21:31 １００点の能力で１つの仕事をする組織ではなくて、７５点の能力で３つの仕事をする組織
になるために、少数の精鋭ではなく多数の凡才の頭数をいかせる標準化を行うんだと思います。

just a reader 2008/03/27 03:44 製造業経験からいうと誰にでも同じ事ができることはコストを下げその製品を普及させたり、新しい技術を導入する上で重要ということですかね。工場で組み立てをするのにその技術がわからないラインの人がやってもきちんとした製品ができあがり、そういう人が出荷テストをして合否判定をしても製品は正しいものが出荷されて異常のあるものは出荷されない。テストをしている人は中身の技術の事はわからないけれど、誰がやっても組み立てた製品やその判定は正しい。こうすることで、技術がわかり高度な設計ができる人は組み立て作業やテストは他の人にまかせて、もっと新しい技術や製品の開発に集中できるようになる。
今、ソフトウェアの需要が高いのに「できる」人が限られている。できる人は忙しくなる一方で、できない人はできる人がつくったソフトウェアを組み合わせることもできないし本当になにもできない。職人のように極めることはすばらしいけれど、ソフトウェア産業そのものが大きくなって、たくさんの人がソフトウェアの仕事ができ、できる人は自分がやった過去の事は誰でも他の人にまかせてしまい、先の事をできるようにする。この基盤のもとには、誰が書いても同じ＝誰でも理解して組み立てられるということが必要なのだろうと思う。

大手ＳＩｅｒの中の人 2008/03/27 07:16 悪者扱いされてる中の人からの意見です。
1.気にするのは生産性と品質2点のみです。その品質の一部として、（CheckStyleなどをカスタマイズした）静的チェックツールでPrj標準化規約に従ったコードかどうかはチェックしますが。「同じコード」とか「メンテできるコード」なんていう定性的な言葉に意味はなく定量的に測定できるものしか意味なしです。少なくとも管理という意味においては。
2.何百人も開発者の中で優秀なプログラマかどうかはすぐ分かります。ほぼ間違いなくメタフレームワークを作ってきますから。押し付けF/Wのみならず、どんな最新のF/Wを使ったところで、特定のPrjへの適用を考えた場合、機械的に書かなきゃいけないところや使いにくいところは必ず出てきます。その弱点をカバーするメタなF/Wを作りながら開発を進める人は優秀だと考えます。
3.開発先には申し訳なく思っているところというと、設計書関連ですね。ぶっちゃけ詳細設計書などと言われる設計書なんて要らないと思っていたりするのですが、、理想の設計書のあり方の答えがないため古い書き方を押し付けている部分があります。UMLなどに期待しましたが、あれで設計書をすべて補うのは不可能でした。。まあ、UMLはコードリバース設計書としては役立ちますが。標準的な設計書を作れていない事に関しては管理側の怠慢と言っても良いでしょう。

smats 2008/03/27 09:36 コーディングも設計なのだ!
http://www.biwa.ne.jp/~mmura/SoftwareDevelopment/WhatIsSoftwareDesignJ.html
いわゆる詳細設計書だとかよりもさらに細かいレベルで最終的な動作を記述した設計書がプログラムコード、ですよね。
昔の人達がコンパイラを考案してくれたおかげで、設計書をそのまま実行ファイルに変換できるのだけれど、勘違いしてはいけない。
コーディング以前の設計はもちろん必要ですが、上流の設計と比較してコーディングの重要性が低いってのは大きな間違いだと考えます。

> 定量的に測定できるものしか意味なし
ソフトウェア開発において定量的に測定できる要素って本当にごく一部だと思います。その部分を「管理」することに意味が無いとは思いませんが、定量的に測定できる要素だけをもって「管理」あるいは「評価」されるとしたら、技術者は不幸です。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください