よいコードを書くようにチームを説得するには？ 101
ストーリー by headless
納得 部門より
納得 部門より
本家/.「Ask Slashdot: How To Convince a Team To Write Good Code? 」より
私は会社で非常に重要なコンポーネントの保守を担当するチームの一員だ。しかし、わが社ではコードや全般的な技術面でのクオリティに対する関心はとても低い。バグの多いリリースも頻繁で、我々の待ち時間は突出しており、テストのカバー範囲はないに等しいといえる。不要な複雑さのため、チームの新しいメンバーが1か月以内に仕事ができるようになるのはほぼ不可能だ。私を含む数名はこの状況を変えたいと考えており、技術的には現在よりもよいコードレビューとリリースのプロセス、ビルドツールなどが必要なことがわかっている。それでもコードや設計のクオリティーは改善せず、スケジュール通りのリリースを維持するという名目で、低品質のコードがリリースされ続けているのが現状だ。常に適切な作業をしていれば、現在の問題点を排除しつつ、これまで通りのペースでリリースが可能だと私たちは考えている。彼らに何が良いのか理解させ、改善に向けて行動してもらえるよう社内の雰囲気を変えるには、どうすればいいだろうか。
できる人を雇う (スコア:5, すばらしい洞察)
経験的に言って、「スケジュール通りのリリースを維持する」などを口実にして、悪いコードを書いてる人は、
スケジュールがあろうとなかろうと糞コードしか書かない。その人達には良いコードを書くスキルが全く欠けてる
ことが多いから。
だから結論としては「できる人を雇って、その人達と入れ替える」以外の答はないだろう。
Re:できる人を雇う (スコア:2, 興味深い)
すば洞がついてるけど、本気でそう思う？
可能なら確かに素晴らしいけど、お花畑なファンタジー回答に見えるね。
「会社の経営状態が良くありません」「経営者と社員を優秀な人に入れ替えましょう」
# 改善ってのはもっとリアルで地道なものじゃないと役に立たないよ。
# 言い放つのが気持ちいいのは分かるけどさｗ
Re:できる人を雇う (スコア:3, 興味深い)
#2313312 の方がリアルだよ。
＃というか、結局シリコンバレーで勝ってる会社は大抵そうやってるわけで。
日本の負け組企業／ブラック企業たちの言ってる、
「素人を１０0人集めれば，プロ顔負けのスゲー野球チームができるんです（キリッ）」
の方が非現実的。
無能な営業や経営者が，そういう夢を信じたくなるのは知ってる。
でも現実はそんなに甘くないんだよ。
Re:できる人を雇う (スコア:1)
玄人10人を集めることはできないから、仕方なく素人100人集めて何とかしている
ってのが、現実なのではないだろうか
＃ま、実際のところ何とかなっていないんだけどね
素人を100人集めて、出来る人にする (スコア:1)
「できる人を雇って、その人達と入れ替える」「素人を100人集めれば」どっちも駄目だろ。
お前らは社会人というのは全て自動的に出来る人になると思ってるのか？どっかの会社にまず新卒で採用され、経験を積んでそれから出来る人になるんだろ。
（ごく稀に最初から優秀な人も居るだろうが、特殊な例として除く。）
会社1社に対して雇用者1名失業者99名とかならともかく、そうでない以上全ての会社が出来る人を中途採用できるわけじゃない。
じゃあどうするのがベストか。もちろん「素人を100人集めて、出来る人にする」がベストだ。
教育コストなり、そもそも教育する側に知識がなくてできてないってのが現在の状態なわけだが、問題点はそういう話であって、出来る人を雇うとか素人でどうにかするとかはどっちも社会的に見て間違ってると言わざる得ない。
（もちろん、小さな一社が多数の犠牲の上に自分だけどうにかしようというのなら、出来る人を雇うでどうにかなるだろうが。
あと学校教育でやるべきだとかは無茶いいなさんな。学校でいろんな業態に特化した教育までは行えないがな。）
Re:できる人を雇う (スコア:1)
「できる人を使う」と「できる人になりうる人を教育する」しか答えは無いだろうな。
the.ACount
次は (スコア:5, おもしろおかしい)
「私のチームには見当はずれな方向に努力してプロジェクトを泥沼に引きずり込もうとしているメンバーがいるのだが、こういうときどうしたらいいだろうか?」というストーリーがタレコまれるのですね。
個人的なことですが (スコア:5, 参考になる)
同じ年に入社した新人が二人いました。
二人とも情報系の大学を出ており、基礎知識の部分は殆ど一緒で、研修で出した課題の成果物の評価もそんなに変わりませんでした。
Aくんはちょっと言語の機能を使って書いていくのが好きなようで、Bくんはできるだけ簡易な方法で書くのが好みなようでした。
そして二人のプログラミングで、もっとも大きく異なっていたのは、
「Bくんは、変数名や関数を命名するときは、意味が通じるように辞書で確認していた」
ということでした。
2年後、二人が作ったソースを修正することがあったのですが、Aくんのソースコードがとんでもないものでした。
「Get_SettHeddarInfo_tableメソッド……変数名gettTebel……なにこれ？」
奇妙な命名規則（？）にさらに拍車をかけたのが、定数や列挙体の多用でした。
確かに定数として定義しておいたほうがプログラミングの作法として正しいのでしょうが、定数にもその理解不明な命名規則を使用していたのです。
Aくんにこの奇妙な命名規則（？）について聞いてみたところ、変数名のおかしな表現については認めたものの、
「これは固定値なんだから、定数として定義しておいたほうがいいでしょ」
という主張をしておりました。
一方、Bくんのソースコードは定数や列挙体などは多様せず、定数的な変数に対してはコメントに詳しく書かれており、また命名規則には推察できる統一性がありました。
「定義はしておいたほうがいいと思ったんですが、時間的に余裕がなかったので、すいません」
と謙虚に、謝られてしまいました。
一応、二人には、以下のページを読ませています。
間違ったコードは間違って見えるようにする
http://local.joelonsoftware.com/wiki/%E9%96%93%E9%81%95%E3%81%A3%E3%81... [joelonsoftware.com]
チームへ説得する方法？ 途中まで作ったコードを他人に渡してみたら、みんな考えるんじゃないかな。
経営や営業にコストの話してみる (スコア:4, すばらしい洞察)
ちゃんとコーディングした場合
低品質なコーディングの場合
それぞれにかかる費用を算出して、上から命令してもらい
その命令をあるべき形で実行するというのでいいんじゃないだろうか。
Re:経営や営業にコストの話してみる (スコア:5, すばらしい洞察)
理想論はそれが正しいとは思う。が、そうはいかない。
確かに、製品が使われなくなるまでの期間までの総期間で見ると、
低品質なコーディングの場合の開発費＋後始末費用 ＞ ちゃんとしたコーディングの場合の開発費＋後始末費用
ではあるんだけど、最初のリリースの時点（出荷開始や運用開始）までを見積もると、
低品質なコーディングの場合の開発費 ＜ ちゃんとしたコーディングの場合の開発費
になっていて、さらに開発期間も
低品質なコーディングの場合の開発期間 ＜ ちゃんとしたコーディングの場合の開発期間
になっていて、拍車がかかる。
ここでプロダクトライフトータルをみるのが本来のマネジメントだと思うんだけど、そんなことを
中間管理職や雇われPMが言ってみたってトップマネジメントからは「低品質なコーディングの
場合の開発費と期間でちゃんとしたコーディングをやれ」って言われるだけ。しかし、そんな策は、
できない奴を抜いて、できる奴に置き換えるくらいしかないが、日本ではそれは不可能。
おっと、「じゃあ、初めから『低品質なコーディングの場合の期間費用』を言わなきゃいいじゃな
いか」と言ってみたところで、大抵の場合は競合他社（相見積り）というのが存在していて、
その中には大抵DQNな会社が１社くらいいて低品質開発の見積りをだしたりしてるので、無駄です。
そして、客も薄々わかってるのに、DQN会社の価格と日程に合わせさせようとするので、
各社どこかを低品質にする競争が始まる。
で、見た目の仕様を落とすのは見積り時点では受け入れられませんから、中身の品質を落とす・・・
というという流れになって、デスマーチプロジェクト一丁上がりです。
トータルで余計に金がかかることがわかっていても、
・目の前のキャッシュが欲しい請負側のトップマネジメント
・先のことは知らぬ存ぜぬで売上立てたい請負側の営業
・目の前の損益改善しないと職を追われる発注側のマネジメント層
がいる限り、この構造は続くんじゃないかな・・・。
＃長文すまぬ
Re: (スコア:0)
まあ、これですよね。
コーディングルールなり、レビュー体制なり、開発環境なり、それがどれだけの損失につながっているかを示して、組織の方針に組み込んでもらうのがいいはずですよね。
ボトムアップでも限界はある。
講座等 (スコア:3)
私が昔いた会社とかは、品質のことも含めて、ソフトウェア技術に関する
様々な講習会とかがあって、新入社員の頃は当然として、働きはじめて
何年かたっても、年に何回かは講義を受けてましたね。
当時でも時代遅れな内容も多かったとは思うんだけど、無駄ではなかったですね。
今は、ソフトウェア業界から離れちゃったので、事情があまりわからないんですけど、
そういうあたりまえに思えることとかは、やってないんですかね。
なんとなく召喚魔法を受けた気がした (スコア:3)
gltyは逃げ出そうとした。しかしまわり込まれてしまった。
ん～、基本的に立場は全然違うけど、言いたい事は分からないでもない。
でも正直、この「私」は何かを誤ってる気がするんだよなぁ。
それがなんだろうって考え続けた結果・・・
この人、「コーディング技術」が低いとしか言ってないって思った。
実際のプロジェクトだと、それ以前に設計書だったり要件定義だったり、
上流過程がそもそも間違ってる事もあるんだけど、
その辺りについて考慮した事はあるのだろうか？
な～んて思っちゃった、ＩＴＩＬ合格してご機嫌のgltyでした。
＃え？合格自慢したかっただけじゃないかって？
＃ぶっちゃけ、その通りです！（ドヤ顔）
手本を見せる (スコア:2)
自分で手本を見せて、それを真似るように指示する。
もちろん自分がお手本になるくらいのスキルがあればの話だけど。
Re:手本を見せる (スコア:1)
私コレかも。5-6 人のチーム + オフショア数名の構成での話。
自分がリーダーのプロジェクトで、布教用に 10 ページ程度のコーディング ガイドラインを作って配ってチーム内で共有しました。読み物としてそこそこ面白くなるようにまとめて、興味を持ってもらいました。実践ではコーディング規約でガチガチにしばることはしませんでしたが、レビューで要所要所の書き方の『なぜ？』を深めることで、設計思想らしいものはわりと共有できたと思います。
Re:手本を見せる (スコア:1)
運用やると業務の1/3くらいこれだったりしますね。
メンバーの最低レベルを併せないといけないので、「そうすると思っていた」、という手前勝手な常識には余り頼れないので。
入れ替わりの人の話を聞くと経験や文化、常識やルールが違って、併せる必要性は感じますね。
あともう一つやるのが、作成資料の早期確認。
資料の良し悪しもありますが、細かい書き方や確認事項、要求レベルをすり合わせておく為です。
面倒ではありますが最初にやっておくとレベル合わせ以外にも、顔を合わせる機会が多くなりその後のコミュニケーションが楽です。
プログラムの現場で使えるかはわからんけど。
#やってみせ、いって聞かせて、させてみて褒めてやらねば人は動かじ
Re: (スコア:0)
「それを読むこと」が仕事のうち, だと納得してもらえればすごく効果的でしょうね
全員が全員怠け者で, 余計な仕事は絶対にやりたくない, という環境だと厳しいかもしれない.
あるいは火消し要員として配置されたときとか,
これをやってもかなりの確率で手遅れかもしれない
# マネージャはさっさとスケジューリングし直せ,
# という話はホントにその通りだけどね
まー無理だな (スコア:2)
彼らは愚かなことまで含めてそれが仕事だと思ってる。
仕事のやり方を変えることは感覚上仕事をしなくなることに近い。ましてやそれで省力化できるならなおさらだ。
故に、設計書が仕様書になり、各種レビューは重箱の隅つつきになり、プロセスは形骸化し、ツールは現在の間違ったやり方へ捻じ曲げられた間違った使い方をされて混乱を助長する。
せいぜい独立性の高い島を作ってその中を整備するしかないだろうな。
Re:まー無理だな (スコア:1)
そんな前提は記事のケースにはないのでそのコメントは言葉通りに新しい設定であると受け取るとして、そりゃナンボか努力はしてみるはな。
ま、元コメントの最後の行に大雑把にだが書いてあるわけだが。
何かの長でないと島作るのは難しいだろ？
Re:まー無理だな (スコア:1)
そりゃ偽装派遣と派遣の違いもわからない誰かさんとは違うわなw
早寝早起き朝ごはん (スコア:2)
Re:早寝早起き朝ごはん (スコア:1)
Re:早寝早起き朝ごはん (スコア:1)
Re:早寝早起き朝ごはん (スコア:1)
命令できる立場になればいいんじゃないかな (スコア:1)
あるいは首を切る立場。
Re: (スコア:0)
そうだな。バグを含めておけば、次の仕事が回ってくるなんて理想的な職場じゃないか。
そもそもよいコードってなに？ (スコア:1)
命名規則やある程度はちゃんと守るのは当たり前として、本当によいコードとはなんなんだ？
行儀がよければよいコードってわけでもないだろうしコードも細かいところまでいけば処理に対して千差万別のコード書くだろうし
そもそも読んでいるかぎりコードというより開発現場全体に問題がある気がする。
技術がない人間をうまく割り当てていくのは、管理職の仕事だし
開発者に良質なコードの設計と意識がないというならば、開発者同士が解決する問題ではなく技術コンサルタントと人材コンサルタントの仕事だし
その改善の費用と日程を捻出するのは経営者の仕事だし
まず彼らだけで解決しようとしているのが良くないとおもうわ
力の伴わない正義は正しいだけ (スコア:0)
たいとるおんりー
Re:力の伴わない正義は正しいだけ (スコア:2, すばらしい洞察)
まあそうですよね。
・「私」を含む数名の高慢ちきは、チームの現状水準と到底かけはなれた品質を望んでいる。
・望んでるだけだから当然改善せず、ベストエフォートなりの低品質コードがリリースされ続けている現状。
・常に適切な作業をしていれば、従来のペースで問題も排除可能と思う。(そりゃそうだ)
・「私」達自身は何が良いのか理解した気にはなってるが、そのための行動規範をどうすればいいかわからない。
わが身を棚に上げたないものねだりじゃないですかね。
まず、せめて自分のテリトリーだけでも堅牢かつ効率的な状態に保つべきですね。
その上で、自分がきっちり満たしている改善項目を数値として周囲に見せ付ける。
それが出来ないのならば、主観的なひとりよがりで周囲を見下してるだけだと思います。
Re: (スコア:0)
> まず、せめて自分のテリトリーだけでも堅牢かつ効率的な状態に保つべきですね。
> その上で、自分がきっちり満たしている改善項目を数値として周囲に見せ付ける。
10年後も同じことをいってられるでしょうかね？
そんなきっちりしたことを続けられるなら、力があるなら・・・・と管理職やPMに
煽てあげられるのが普通。適性があるかないかに関係なく・・・・ね。
その時により大きく見えてくるのがチーム全体の問題点なのよ。
＃いかなる要請があっても周囲とは協調（協力）しない、というなら話は別
決済? or 決裁? [オフトピ( -1)] (スコア:1)
文脈からおそらく後者だと思うけどそれだけ。
その会社を辞めて (スコア:0)
Re:その会社を辞めて (スコア:1)
「あそこのマネージャーは、よっぽどメンバーを脅して仕事させているんだな」と思われたりして。
Re: (スコア:0)
そうです。会社を変えるか、社長を替えるか。それ以外に解決方法はありません。
でも、結局コードの質が悪くても安い方を客が選ぶのかな。
それには、脱デフレ。総理大臣は替えたよね。
Re: (スコア:0)
だが俺は変わりたくない、そんな痛みはいらない！ 少なくとも俺はね。
とりあえずコストの圧縮を説明したら？ (スコア:0)
わが社ではコードや全般的な技術面でのクオリティに対する関心はとても低い
開発速度、リリース速度を第一としていた場合、ありえるんじゃないですか？日本のソーシャルとかはそんなイメージですね。
我々の待ち時間は突出しており、
どこと比べて待ち時間が突出しているんだろう？保守は待ち時間があるのは健全な状態だし、
このプロジェクトはバグが多いんですから、待ち時間がないはずですよね。
技術的には現在よりもよいコードレビューとリリースのプロセス、ビルドツールなどが必要なことがわかっている。
何を基準としてよいと言っているのか、どうして必要なのかを説明した方がいいです。その上で理由があって使っていないこともあります。
常に適切な作業をしていれば、
ああ、これはダメですね。そもそも適切な作業ができないことに原因があります。
どうしたら適切な状態に戻れるかを、議論しないといけないのです。あと、適切な状態のビジョンも共有しないと。
具体例があがっておらず、机上の空論で終わりそうですね。
Re:とりあえずコストの圧縮を説明したら？ (スコア:1)
> 開発速度、リリース速度を第一としていた場合、ありえるんじゃないですか？
いやいや、技術者を名乗るのがおこがましい連中と来たら、低い生産性と低いコード品質を両立してくれますよ。
うちの会社の話とすると、近々退職してしまうピカイチの人と１０年選手の並の人を比較すると、、コード量：約半分、コード記述速度：約４倍、総合試験バグ数：約10分の１、と言う指標値が出てます。
ピカイチ君のコードはきれいで読みやすいですよ。的確な制御構造、末広がりの機能分割、コメント行及びコメント付きコード行の比率が７０%、などなど。
まあ、コードをきれいに書くには時間が掛かる、と主張する人には、コードを書かせてはいけないと言う事なんでしょうね。
Re: (スコア:0)
原文は「our latencies are shooting up」だから「待ち時間」というより「遅延」が発生しているといった意味ですかね
外的要因を加える (スコア:0)
うちのそれほど大きくない顧客が制定前にISOxxxに注目していて、それを社内で紹介してもふ〜んだったけど、
大手顧客がそれに準拠して欲しいとお願いしてくると、即座に専門部署まで立ち上げたりする。
会社ってそんなもんだ。
そういう顧客を獲得するよう営業と組むとかそれが早かったりするかもしれん。
サンプルコードをパーツとして活用できる開発環境を作る (スコア:0)
使いやすい環境があれば、それを使って楽するようになるものです。環境整備は結構、大変だけど、やった部分では確実に効果が出ますね。出来ないと嘆くだけじゃ、進歩なんてありゃしませんので。
Re: (スコア:0)
品質の話と全然関係ないね。
よくわからんサンプルをやっつけで使える環境なんか作ったら、むしろ助長しそう。
Re: (スコア:0)
そこはサンプルコードをただの参照用としか使わないというレベルだと、品質に繋がりにくいだろうね。そこからもう1〜2段階進めてこそ、威力を発揮するものだよ。品質改善は個人の能力頼みじゃなく、会社システムとして、どの位置を占めるか？そして、どの順番で整えていくか？がキーでもある。でも、いきなり高度なことを始めようとしても、挫折するのがオチ。簡単なことから始めてこその、改善だわね。
#で、実際効果出てるので、更なる高みを模索中。
高品質がどういうものかわからない (スコア:0)
こういうのが高品質で、
こういう風にすると楽でしょ？
というのを教えないといけない。
ところで、
コードの品質を高くすることと、
テストやレビューをちゃんとすることは、
関連はするけど直結はしないよね。
低品質コードでもテストやレビューを徹底することはできる。
スケジュールが遅れる？
必要な手順（テストやレビュー）を除外したスケジュール立ててるからじゃないの。
Re: (スコア:0)
> コードの品質を高くすることと、テストやレビューをちゃんとすることは、関連はするけど直結はしないよね。
そうそう、直結しない。
> 低品質コードでもテストやレビューを徹底することはできる。
これは違うな。まず、テストやレビューを徹底するなんて事は絵空事で、現実世界では到底無理な事だ。更に、糞コードのテストやレビューは、問題点の飽和攻撃を食らった様になる。そうなると問題は直らない。これらの結果、未検出バグ、潜在バグ山盛り大盛り状態で、テスト/レビュー終了となるだろうね。
残念ながら能力には差がある (スコア:0)
できる人とできない人では、１０倍の差がある、と何かで見ました。
できる人に任せるしかないです。
問題になるのはできない人をどうするかですが、
できない人が仕切っているケースも多々あり、
手間ばかり増える傾向はあると思います。
なにしろ、できる人が正しく評価されない事が多く、
ひどい扱いをされているケースもありますから。
上司ができない人だと最悪ですね。
ほとんどがそうした環境なはずなので、
できる人も（できない人も）絶えるしか道はなく、
本当の生産性向上や、世界的な改革を成し遂げることの難しさが
ここにあると感じます。
Re:残念ながら能力には差がある (スコア:3, すばらしい洞察)
できる奴ができない奴の何倍なんてのは、間違った考えです。
できない奴はマイナスです。自分のミスを自分だけで解決できないのができない奴です。
Re: (スコア:0)
> できない奴はマイナスです。自分のミスを自分だけで解決できないのができない奴です。
さらに、他人に解決してもらっている間に、次の地雷を埋めやがる。
＃海外なら「ファイヤーッ！」もんなんだろうけど、日本じゃそうはいかないから雪だるま式にコストが膨らむ。
Re:残念ながら能力には差がある (スコア:2, 参考になる)
「ソフトウェアにおける高音域 - The Joel on Software Translation Project [joelonsoftware.com]」では、
何倍とかそういうレベルの問題ではないと書かれています。
Re:残念ながら能力には差がある (スコア:1)
Joel は間違ってはいないと思うが、諦めるべきだとは思えない。
「サリエリのミサ曲にはこれだけ支払っている。君のレクイエムが同じ値段なら買おうじゃないか。」
などと仮に言われたとしても、それでも質を落とさず書き続けられる人だったからこそ、彼はモーツァルトになれたのだろう。
「長年にわたって、僕ほど作曲に長い時間と膨大な思考を注いできた人は他には一人もいません。有名な巨匠の作品はすべて念入りに研究しました。作曲家であるということは精力的な思考と何時間にも及ぶ努力を意味するのです。」（モーツァルト）
天才は自らを天才とは言わず単なる努力家とみなすが、そこまでの努力ができないのが凡人なのだ。
そして、天才にしかできなかったことを凡人にもなんとか真似られるようにするのが技術であり、工学であるのではないか。
Re:残念ながら能力には差がある (スコア:1)
> 工学ってのは同じものをいっぱい作る技術の学問です。
ちと違うな。
工学ってのは「問題解決や課題実現に対する効率的かつ反復的な方法の追求および確立」だろうね。だから、同じものをジャカジャカ作れる様にするのは工学の範疇だけど、それだけじゃない。機能の具現としてのソフトウェアというものを何時でも効率的に作る手法の確立も工学の範疇だよ。そういうのはcpコマンドじゃ出来ないだろ？
> だからソフトウェア開発は工学ではないのです。
前提はめちゃくちゃだが、「ソフトウェア開発は工学ではない」は正しい。工学の域に達していない、と言うべきだが。機能の具現としてのソフトウェアは、意図した機能が動作する事と、意図しない要因で機能が動作しない事が無い事で成り立つ。前者は実現可能だが、後者の実現は難しい、と言うか出来ない。だから、機能の具現としてのソフトウェア自体が常には成立しないんだね。だからソフトウェア開発は工学じゃないし、ソフトウェア工学と言われているものはエセ工学なんだよ。