プログラマーは皆、常に秘密や嘘を抱えている
プログラマーは皆、常に秘密や嘘を抱えている。
これは間違いない。
基本的には誰にも話さないが、
︵家族や友人などプログラムを知っていない人間に話しても分からない、という事もある︶
プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。
秘密や嘘の傾向には幾つかのパターンがある。
1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 ﹁ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？﹂ などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に相談するのがベストではあるが、 納期や現場の人間関係などの兼ね合いがあり気軽に相談できないような環境である場合 プログラマーは﹁自分の判断で適当にコーディング﹂する。 ・少しでも想定外だったらシステムごと停止するような頑固な処理を入れる ・適当なエラーメッセージを出す ・自分で﹁こうかな？﹂と判断して適当に対処処理をコーディングする ・もういっその事気にしない このようなコーディングは作った本人以外にはよく分からない、いわゆるブラックボックス化され 作った本人はそのことについては外部︵自分以外の人間︶に対し触れない。むしろ自身も忘れる。 ただ、これは人や内容によって受け止め方が異なる場合もある。 人や内容によっては﹁何勝手な事してんだよ。俺に一回相談しろよ﹂となる場合もあるし ﹁おお！そんな気回しをして対処プログラムを作ってくれていたんだね﹂となる場合もある。 また、細かに一つ一つ相談するにしても、相談対象の相手が ﹁そんな細かい事、てめーが考える事だろ？そんな事いってねーでどんどん次の機能作れや﹂ってなる人の場合もある。 このさじ加減も非常に難しい。 そんな微妙な判断のポイントが日常的に出現するのがプログラムだ。 ﹁だったらもういっその事全てを適当にやった方が楽だろ？﹂ という結論に至るプログラマーも少なくない。
2) 進捗報告 プログラムコーディングとは、とてつもなく複雑な作業である。 完成が100%とした場合、現在どこまでコーディングが完了しているのか？までは作っている本人以外には分かりにくい場合がよくある。 ︵特に画面の無いバッチ処理など︶ が、実は作っている本人にも現在の進捗状況がよく分かっていない場合もある。 ︵これは経験の浅いプログラマーに多くみられる︶ そんな感じなのでチームリーダーなどから進捗報告を求められた場合、思わず ﹁予定通り進んでいます！80％です！﹂ などと適当な事を言ってしまう場合がある。 しかしフタを開けてみれば実際には全然動く状態ではなく、 作った本人を問いただしてみても的を得た返答が得られない場合がある。 当たり前である。 何せ、作っていた本人自身が進捗状況が良く分かっていなかったのだから。 そこで、漠然とした不安の中で怒られるのを先延ばしにするために進捗報告で嘘を言っただけの事である。 これは実は本人ばかりを問いただす事はできない。 こういうものなのである。
デキの良い管理者であれば、事前に細かいチェックを入れたり 全体の完成だけにラインと結果報告を引かず、節目節目で単体的な成果物の提出を要求したり、 スケジュールも実際の納期よりも少し短い期間を本人に伝えたりするものである。 繰り返すが、嘘も含め作っている本人も良く分かっていない場合もある。 経験の浅い人間に﹁その傾向がある﹂だけでありベテランでも同じようなミスや嘘をする場合はある。 何せプログラムコーディングとは、とてつもなく複雑な作業なのだから。
3) 面倒な繰り返し作業やテスト プログラマーの仕事は頭を使ってコーディングを行うだけではない。 たいていの場合、作ったものに対するテストも仕事のうちに入る。 テスト、と一言にいってもその内容は多岐に渡り、 さっと終わるものもあれば、とんでもないパターンのテストを実施する場合もある。 例えば、同じような画面操作をひたすら1000回繰り返すテストの場合もあるし、 テスト用のデータを1000件手作業で作成する場合もある。 しかもこのような内容を、ひたすら一ヶ月間繰り返す場合もある。 コーディングよりは頭は使わなくても良いが︵ほぼ単純作業の場合が多い︶、はっきり言って考えただけでうんざりする。 この落差も、他業界にはなかなか見られない光景であると思う。 とてつもなく頭を使う一カ月間と、とてつもなく単調な作業の一ヶ月間・・・ このような単調作業を繰り返していると、たまにミスも起こす。 例えば Ａというボタンを押した後に Ｂという選択肢からβを選択し、 その後Ｃというボタンを押す。 というテストケースがあった場合、間違って最後にＤというボタンを押してしまう場合がある。 間違いに気付いた際、本来であれば一度戻ってＡボタンを押すところからやりなおせば良いのだが、 ﹁Ｄというボタンは実は、内部的には100件のデータを書き換える処理が入っており、Ａからやり直すには、その100件を全て手作業で元にもどしてからテストをしないと意味が無い。﹂ という場合がある。︵決して誇張では無い。よくある事だ。︶ そのような場合、はっきり言ってとても面倒くさい。 やる気がいっきに削がれる。 思わず声に出して﹁うああああーーーー﹂とか言っちゃう。 ただ、このテストは既に似たような事を既にテスト済みで、ほんの少しだけパターンを変えてのテストだった場合。 そんなとき、とっても真面目では無い人︵ほとんどの人が該当するだろう︶は、 ﹁テスト完了﹂にマルをして終わらせるだろう。 鋼鉄の意志でも持った人物でもない限りは。
4) 他人の担当箇所だからいいや 例えば自分の担当範囲であるコーディングをしていた際に、何かの拍子で別の担当者がコーディングしているソースを見るがある。 ふと目についたバグ。明らかにバグ。 でもそれを作った担当者は自分が嫌いな奴だった。 もしくは良く知らない奴だった。 こんな時、たいていのプログラマーは無視する。 ﹁まー、そいつの責任だからね﹂ その後、そのバグがシステム全体を停止させるに至り、 データリカバリーにチーム全員が徹夜を余儀なくさせる事を、彼はまだ知らない。
5) 後から気づく 作っていた当時は気づかなかったが、その後コーディングを終えてから気づくようなケースもある。 プログラマーはふと思い出すのである。 ﹁あれ？あの時のあのコーディングって、よく考えたらマズくね？﹂ もしくは、数か月後にでも、自分自身の知識量が経験によって増えた時に ﹁あーあんときのコーディング方法は間違ってたなー。あのままじゃバグるなー﹂
まだ開発段階のものであればすぐに治してしまえば良いだけの事であるが、 既に納品を終えて稼働しているシステムだったりすると、そんな簡単な話ではなくなる。 ましてや、システムのソースを更新する際にサーバ再起動が発生するようなシステムであった場合は、なおさらである。 自分自身がサーバ管理者になっていれば、夜中に誰にもバレないようにコッソリ修正してしまう事もできるかもしれないが、 そのような立場では無い場合・・・ サーバのソースを入れ替えるには、リーダーに相談して、営業が客先に説明して・・・ 客先の業務を数時間ストップして・・・ 考えるだけでも胃が痛くなる。 そんなとき、たいていのプログラマーがとる行動は ﹁忘れよう。﹂
6) 誰も知らないかもしれない仕様 大きなシステムになればなるほど、仕様はより複雑になっていく。 担当者も、開発当初からの担当者が変更になっていたりすると、もう訳が分からなくなる。 担当者がいたとしても、開発したのが数年前だったりすると細かい箇所については、誰も覚えていなかったりする。 なんてシステムは日常茶飯事である。 このようなシステムの改修を行う場合、プログラマーは過去のプログラムとの壮絶な戦いを繰り広げる事を余儀なくされる。 作った人間もいない、仕様が明確に分かる人間もいない、資料も無い となれば、頼れるのはシステムを動かしているソース、ただ一つである。 なんでこんな所でこんな事やってんだ？ なんでこんな所にこんな物があるんだ？ とめどない疑問と解決の繰り返しである。とてつもないストレスがかかる。 また、下手に修正を入れて、万が一システムが動かない状態になってしまうと自分の責任になってしまう。 ﹁でもこのソース訳がわからん。﹂
しかし、修正を繰り返しているうちに ﹁以前はうまく動いていたけれども、ある修正を入れた事によって一部の機能が消えてしまった﹂ なんて事があったりする。 しかも、その機能を復元させようとすると、今度は自分が今回入れた修正がうまく動かなくなってしまう。 なんて、もう訳のわからない状態にすら陥ったりする事がある。 そこでプログラマーが気付いた。 でもこの機能、実は隠れ機能みたいな感じだし、ひょっとしたら誰も気づいていないのかもしれない・・・ そして、そっと封印する。
もしバレたら ﹁あーすみません、その機能、隠れ機能みたいな感じだし気づきませんでした﹂ って言おう。 分かりづらい機能だし、ちゃんと謝るし、きっと納得してくれるよね。
バレずに、そのまま自分が別の案件や現場に移動するまで逃げ切れれば 万事解決なのである。
番外) 極端に有能なプログラマー これは上記までの嘘のパターンとは少々訳が違うパターンだ。 また、このような事が実際にできるプログラマーも私の知る限り、かなり少ない。 だが、まれにいる。 納期よりもかなり早い段階で実際には完成しているにも関わらず、 納期ギリギリになるまで﹁まだできていません﹂と発言するのだ。 この業界では能力が上と下の人間では、納品物完成までに30倍のスピード落差があると言われている。 つまり、とんでもない早さで、とんでもない効率的なコーディングができる人間が世の中にはいる。 これは一概には経験とは比例しておらず、若年プログラマーにも存在している。 もはや生まれもったものなのであろう。 管理者からしたら生唾ものの、とんでもなくたまらない人材であろう。 そして、能力の高い人間もそれは自覚している。 だから自己防衛をするのである。 仕事量の多い開発現場においては、早く自分の担当分を完了させた人間には 別の人間の作業を割り振る。 これには例外は無い。 まわりが残業まみれの状況で ﹁キミ、早く担当分が終わっているから早く帰っていいよ﹂ と言ってくれる管理者などまずいない。 管理者の立場からすれば当然であろう。 このような状況で割り振られる新たな作業とは、 出来の悪いプログラマーの手伝い︵いわゆる﹁ケツ拭き﹂である。︶であったり、難解な機能の実装を振られる場合が多い。 仮に、その作業を終えたとしても、待っているのは安息では無い。次のケツ拭きである。
30倍の効率格差を持ちながら、給料は大して変わらない。 ケツ拭きとは言え、担当する機能が増えればその分責任の範囲も広くなってしまう。 そのような作業を割り振られた有能な人間はどう思うだろう。 簡単な話である。 自分の担当分だけキチンとこなしたら、後は﹁終わっていない事﹂にするのだ。 あとは適当に回りにあわせて、ほどほどに残業し、 まわりにも﹁大変だよねー﹂とホラを吹いておけば、仕事面でも人間関係においてもバッチリである。 ただし、この嘘は ﹁自分の担当分を確実にスピーディーに終わらせる事の出来る人間﹂ であるという前提がつく。 そのため、仮に管理者や同僚であるあなたが気付いたとしても決して咎めてはならない。 稀であり貴重であり有能である人材なためである。
最後に と、プログラマー以外の人がここまで読んだなら、こう思うだろう。 ﹁おいふざけんなよ。社会人だろ？ちゃんと責任持って仕事しろよ﹂
また、プログラムを知らない名ばかりSEや、低能管理者・管理をするだけの自称ディレクター︵︶などは こう思うかもしれない。 ﹁なるほど。では管理を徹底し、そのような秘密や嘘のないキチンとした体制を作ろう﹂ 断言しよう。 本人達を縛るだけではプログラマーの秘密や嘘は決してなくならない。 どんなに進捗報告をマメにさせても、どんなにコードレビューを徹底させようとも 大した意味をなさないであろう。 いや、むしろ悪化するはずだ。
このような秘密や嘘が発生する一番の理由は、たいていの場合、その現場の体制にある。 プログラマーが隠し事をする一番のモチベーションは ・ストレスであり ・窮屈な環境であり ・疎遠な人間関係 なのである。
何度も繰り返すが、プログラムとはとてつもなく複雑な作業であり、 とてつもなくストレスを抱える作業なのである。 そのストレスに輪をかけてしまっては、本人達のパフォーマンスは低下の一途をたどるであろう。
最も効果的な方法はストレスを最小にするのである。 また、一人で仕事をしているような錯覚は持たないように最善の注意を払うべきである。 プログラマー同士のコミュニケーションが増えれば、秘密は自然に暴露されるだろうし、 そもそも秘密と化す前に、互いで解決策を模索するようになる。 また、解決策を模索できるだけの環境と時間も彼らには与える必要がある。
無理な納期や予算での仕事・プログラマーと同じ目線でリーダーシップのとれる人物のいない環境。 このような環境では秘密や嘘はひたすらに増えてしまう。 改善を目指すのであれば、この逆を行う必要がある。
1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 ﹁ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？﹂ などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に相談するのがベストではあるが、 納期や現場の人間関係などの兼ね合いがあり気軽に相談できないような環境である場合 プログラマーは﹁自分の判断で適当にコーディング﹂する。 ・少しでも想定外だったらシステムごと停止するような頑固な処理を入れる ・適当なエラーメッセージを出す ・自分で﹁こうかな？﹂と判断して適当に対処処理をコーディングする ・もういっその事気にしない このようなコーディングは作った本人以外にはよく分からない、いわゆるブラックボックス化され 作った本人はそのことについては外部︵自分以外の人間︶に対し触れない。むしろ自身も忘れる。 ただ、これは人や内容によって受け止め方が異なる場合もある。 人や内容によっては﹁何勝手な事してんだよ。俺に一回相談しろよ﹂となる場合もあるし ﹁おお！そんな気回しをして対処プログラムを作ってくれていたんだね﹂となる場合もある。 また、細かに一つ一つ相談するにしても、相談対象の相手が ﹁そんな細かい事、てめーが考える事だろ？そんな事いってねーでどんどん次の機能作れや﹂ってなる人の場合もある。 このさじ加減も非常に難しい。 そんな微妙な判断のポイントが日常的に出現するのがプログラムだ。 ﹁だったらもういっその事全てを適当にやった方が楽だろ？﹂ という結論に至るプログラマーも少なくない。
2) 進捗報告 プログラムコーディングとは、とてつもなく複雑な作業である。 完成が100%とした場合、現在どこまでコーディングが完了しているのか？までは作っている本人以外には分かりにくい場合がよくある。 ︵特に画面の無いバッチ処理など︶ が、実は作っている本人にも現在の進捗状況がよく分かっていない場合もある。 ︵これは経験の浅いプログラマーに多くみられる︶ そんな感じなのでチームリーダーなどから進捗報告を求められた場合、思わず ﹁予定通り進んでいます！80％です！﹂ などと適当な事を言ってしまう場合がある。 しかしフタを開けてみれば実際には全然動く状態ではなく、 作った本人を問いただしてみても的を得た返答が得られない場合がある。 当たり前である。 何せ、作っていた本人自身が進捗状況が良く分かっていなかったのだから。 そこで、漠然とした不安の中で怒られるのを先延ばしにするために進捗報告で嘘を言っただけの事である。 これは実は本人ばかりを問いただす事はできない。 こういうものなのである。
デキの良い管理者であれば、事前に細かいチェックを入れたり 全体の完成だけにラインと結果報告を引かず、節目節目で単体的な成果物の提出を要求したり、 スケジュールも実際の納期よりも少し短い期間を本人に伝えたりするものである。 繰り返すが、嘘も含め作っている本人も良く分かっていない場合もある。 経験の浅い人間に﹁その傾向がある﹂だけでありベテランでも同じようなミスや嘘をする場合はある。 何せプログラムコーディングとは、とてつもなく複雑な作業なのだから。
3) 面倒な繰り返し作業やテスト プログラマーの仕事は頭を使ってコーディングを行うだけではない。 たいていの場合、作ったものに対するテストも仕事のうちに入る。 テスト、と一言にいってもその内容は多岐に渡り、 さっと終わるものもあれば、とんでもないパターンのテストを実施する場合もある。 例えば、同じような画面操作をひたすら1000回繰り返すテストの場合もあるし、 テスト用のデータを1000件手作業で作成する場合もある。 しかもこのような内容を、ひたすら一ヶ月間繰り返す場合もある。 コーディングよりは頭は使わなくても良いが︵ほぼ単純作業の場合が多い︶、はっきり言って考えただけでうんざりする。 この落差も、他業界にはなかなか見られない光景であると思う。 とてつもなく頭を使う一カ月間と、とてつもなく単調な作業の一ヶ月間・・・ このような単調作業を繰り返していると、たまにミスも起こす。 例えば Ａというボタンを押した後に Ｂという選択肢からβを選択し、 その後Ｃというボタンを押す。 というテストケースがあった場合、間違って最後にＤというボタンを押してしまう場合がある。 間違いに気付いた際、本来であれば一度戻ってＡボタンを押すところからやりなおせば良いのだが、 ﹁Ｄというボタンは実は、内部的には100件のデータを書き換える処理が入っており、Ａからやり直すには、その100件を全て手作業で元にもどしてからテストをしないと意味が無い。﹂ という場合がある。︵決して誇張では無い。よくある事だ。︶ そのような場合、はっきり言ってとても面倒くさい。 やる気がいっきに削がれる。 思わず声に出して﹁うああああーーーー﹂とか言っちゃう。 ただ、このテストは既に似たような事を既にテスト済みで、ほんの少しだけパターンを変えてのテストだった場合。 そんなとき、とっても真面目では無い人︵ほとんどの人が該当するだろう︶は、 ﹁テスト完了﹂にマルをして終わらせるだろう。 鋼鉄の意志でも持った人物でもない限りは。
4) 他人の担当箇所だからいいや 例えば自分の担当範囲であるコーディングをしていた際に、何かの拍子で別の担当者がコーディングしているソースを見るがある。 ふと目についたバグ。明らかにバグ。 でもそれを作った担当者は自分が嫌いな奴だった。 もしくは良く知らない奴だった。 こんな時、たいていのプログラマーは無視する。 ﹁まー、そいつの責任だからね﹂ その後、そのバグがシステム全体を停止させるに至り、 データリカバリーにチーム全員が徹夜を余儀なくさせる事を、彼はまだ知らない。
5) 後から気づく 作っていた当時は気づかなかったが、その後コーディングを終えてから気づくようなケースもある。 プログラマーはふと思い出すのである。 ﹁あれ？あの時のあのコーディングって、よく考えたらマズくね？﹂ もしくは、数か月後にでも、自分自身の知識量が経験によって増えた時に ﹁あーあんときのコーディング方法は間違ってたなー。あのままじゃバグるなー﹂
まだ開発段階のものであればすぐに治してしまえば良いだけの事であるが、 既に納品を終えて稼働しているシステムだったりすると、そんな簡単な話ではなくなる。 ましてや、システムのソースを更新する際にサーバ再起動が発生するようなシステムであった場合は、なおさらである。 自分自身がサーバ管理者になっていれば、夜中に誰にもバレないようにコッソリ修正してしまう事もできるかもしれないが、 そのような立場では無い場合・・・ サーバのソースを入れ替えるには、リーダーに相談して、営業が客先に説明して・・・ 客先の業務を数時間ストップして・・・ 考えるだけでも胃が痛くなる。 そんなとき、たいていのプログラマーがとる行動は ﹁忘れよう。﹂
6) 誰も知らないかもしれない仕様 大きなシステムになればなるほど、仕様はより複雑になっていく。 担当者も、開発当初からの担当者が変更になっていたりすると、もう訳が分からなくなる。 担当者がいたとしても、開発したのが数年前だったりすると細かい箇所については、誰も覚えていなかったりする。 なんてシステムは日常茶飯事である。 このようなシステムの改修を行う場合、プログラマーは過去のプログラムとの壮絶な戦いを繰り広げる事を余儀なくされる。 作った人間もいない、仕様が明確に分かる人間もいない、資料も無い となれば、頼れるのはシステムを動かしているソース、ただ一つである。 なんでこんな所でこんな事やってんだ？ なんでこんな所にこんな物があるんだ？ とめどない疑問と解決の繰り返しである。とてつもないストレスがかかる。 また、下手に修正を入れて、万が一システムが動かない状態になってしまうと自分の責任になってしまう。 ﹁でもこのソース訳がわからん。﹂
しかし、修正を繰り返しているうちに ﹁以前はうまく動いていたけれども、ある修正を入れた事によって一部の機能が消えてしまった﹂ なんて事があったりする。 しかも、その機能を復元させようとすると、今度は自分が今回入れた修正がうまく動かなくなってしまう。 なんて、もう訳のわからない状態にすら陥ったりする事がある。 そこでプログラマーが気付いた。 でもこの機能、実は隠れ機能みたいな感じだし、ひょっとしたら誰も気づいていないのかもしれない・・・ そして、そっと封印する。
もしバレたら ﹁あーすみません、その機能、隠れ機能みたいな感じだし気づきませんでした﹂ って言おう。 分かりづらい機能だし、ちゃんと謝るし、きっと納得してくれるよね。
バレずに、そのまま自分が別の案件や現場に移動するまで逃げ切れれば 万事解決なのである。
番外) 極端に有能なプログラマー これは上記までの嘘のパターンとは少々訳が違うパターンだ。 また、このような事が実際にできるプログラマーも私の知る限り、かなり少ない。 だが、まれにいる。 納期よりもかなり早い段階で実際には完成しているにも関わらず、 納期ギリギリになるまで﹁まだできていません﹂と発言するのだ。 この業界では能力が上と下の人間では、納品物完成までに30倍のスピード落差があると言われている。 つまり、とんでもない早さで、とんでもない効率的なコーディングができる人間が世の中にはいる。 これは一概には経験とは比例しておらず、若年プログラマーにも存在している。 もはや生まれもったものなのであろう。 管理者からしたら生唾ものの、とんでもなくたまらない人材であろう。 そして、能力の高い人間もそれは自覚している。 だから自己防衛をするのである。 仕事量の多い開発現場においては、早く自分の担当分を完了させた人間には 別の人間の作業を割り振る。 これには例外は無い。 まわりが残業まみれの状況で ﹁キミ、早く担当分が終わっているから早く帰っていいよ﹂ と言ってくれる管理者などまずいない。 管理者の立場からすれば当然であろう。 このような状況で割り振られる新たな作業とは、 出来の悪いプログラマーの手伝い︵いわゆる﹁ケツ拭き﹂である。︶であったり、難解な機能の実装を振られる場合が多い。 仮に、その作業を終えたとしても、待っているのは安息では無い。次のケツ拭きである。
30倍の効率格差を持ちながら、給料は大して変わらない。 ケツ拭きとは言え、担当する機能が増えればその分責任の範囲も広くなってしまう。 そのような作業を割り振られた有能な人間はどう思うだろう。 簡単な話である。 自分の担当分だけキチンとこなしたら、後は﹁終わっていない事﹂にするのだ。 あとは適当に回りにあわせて、ほどほどに残業し、 まわりにも﹁大変だよねー﹂とホラを吹いておけば、仕事面でも人間関係においてもバッチリである。 ただし、この嘘は ﹁自分の担当分を確実にスピーディーに終わらせる事の出来る人間﹂ であるという前提がつく。 そのため、仮に管理者や同僚であるあなたが気付いたとしても決して咎めてはならない。 稀であり貴重であり有能である人材なためである。
最後に と、プログラマー以外の人がここまで読んだなら、こう思うだろう。 ﹁おいふざけんなよ。社会人だろ？ちゃんと責任持って仕事しろよ﹂
また、プログラムを知らない名ばかりSEや、低能管理者・管理をするだけの自称ディレクター︵︶などは こう思うかもしれない。 ﹁なるほど。では管理を徹底し、そのような秘密や嘘のないキチンとした体制を作ろう﹂ 断言しよう。 本人達を縛るだけではプログラマーの秘密や嘘は決してなくならない。 どんなに進捗報告をマメにさせても、どんなにコードレビューを徹底させようとも 大した意味をなさないであろう。 いや、むしろ悪化するはずだ。
このような秘密や嘘が発生する一番の理由は、たいていの場合、その現場の体制にある。 プログラマーが隠し事をする一番のモチベーションは ・ストレスであり ・窮屈な環境であり ・疎遠な人間関係 なのである。
何度も繰り返すが、プログラムとはとてつもなく複雑な作業であり、 とてつもなくストレスを抱える作業なのである。 そのストレスに輪をかけてしまっては、本人達のパフォーマンスは低下の一途をたどるであろう。
最も効果的な方法はストレスを最小にするのである。 また、一人で仕事をしているような錯覚は持たないように最善の注意を払うべきである。 プログラマー同士のコミュニケーションが増えれば、秘密は自然に暴露されるだろうし、 そもそも秘密と化す前に、互いで解決策を模索するようになる。 また、解決策を模索できるだけの環境と時間も彼らには与える必要がある。
無理な納期や予算での仕事・プログラマーと同じ目線でリーダーシップのとれる人物のいない環境。 このような環境では秘密や嘘はひたすらに増えてしまう。 改善を目指すのであれば、この逆を行う必要がある。
