例)仕事中の飲食禁止。
頭使うと甘いものが食べたくなるのに。集中するにはコーラのカフェインが必要だ!
例)同僚が、JAVAをまるでスクリプト言語のように書いている。ソースコードの再利用云々の話をしたら、コードのコピペをしまくり、バグを散在させている。やつを隔離したい!
部屋にセパレータがないです。
だだっ広い大部屋に高密度に人が入っています。
個室とはいいませんが、せめて一人一人区切って欲しいもんです。
周りが気になって仕事に集中しにくいと感じます。
私の職場ではないのですが、友人のプログラマの職場が「自席で喫煙OKルール」でとても辛いそうです。
喫煙者の方は喫煙することでストレス解消をするそうですが、吸わない人は逆に副流煙でストレスがたまるそうです。
特に煮詰まってくると、チェーンスモーキングになりますしね。
ストレス保存の法則?のように、ストレスをやり合っている状態なので分離するのが(喫煙室を設ける)一番じゃないかと思っています。
http://blog.livedoor.jp/hibari_mori/archives/50571086.html
私が発見した法則のうちの一つに「ストレス保存の法則」という法則があります。これは「世の中のストレスはいつも一定である」という法則です。ですから自分のストレスは他人に移譲しなければ消滅しませんし、移譲されたらまた別の人に移譲しなければいつまでもそこに滞ってしまうというタチの悪い法則です。
ストレス保存の法則、面白いです。
メイン言語は今はPerlとJavaかな。さて、この関連は多いと思いますが昨今‥
個人情報・機密情報をだらだらやった人がわんさかいたから、しかたないっていえばしかたないですけどね‥
プログラマーとして腹立たしいことも多々あると感じます。
意味のない、くだらない会議。
プログラミングに一番大切な集中力を拡散させる憎き敵(笑)
くだらない会議、やっぱりあるんですね。ポイントは495件受け付けるまで用意しているので不満のある人はどしどし書き込んでください。
ご質問に対する直接的な回答にはならないかもしれませんが。
結局、プログラマとして優秀な人材、またはプログラマを信頼し、理解している人間がルールを作る側、つまり出世しないという文化そのものが根本的な問題なんですよね、結局。プログラマを理解していない人間はまと外れな環境を作り出しますし、プログラマを信頼していない人間は非効率なルールを作ります。
「ネット禁止」と答えてらっしゃる方がいたのには大変驚きました。ほぼ拷問とも言える状況だと思います。
漠然とした答えですみません。
なるほど。どこかのブログで「社長がプログラマだったから入社を決めた」というプログラマのエントリーを読んだことを思い出しました。
メインはJavaです。
・Eclipseが激重の低スペックマシンでの開発。
・仕事しないでリフレッシュコーナーで長時間喋ってる人(見るとやる気をなくす)
・やたらと空調の温度を調整する人
・Enterキーだけ打音が大きい人
・なぜか二重に管理番号がついてる書類・・・。
・「やればできる」しか言わない上司
・書類の内容より見た目にこだわる人(インデントとか)
単なる愚痴になってますね・・・。
「書類の内容より見た目にこだわる人(インデントとか)」こういう経験私にもあります。おかげでワードとパワーポイントが上達しましたが、時間の無駄でした。
私はプログラマーではありませんが、「プログラマのやる気を削ぐ10の方法(http://www.geekpage.jp/blog/?id=2006/12/22)」なる面白い記事がありましたので紹介します。
頑張ってください。
確かにやる気が無くなりそうです。
やたら室内が暑い。
なぜかPCがやたら重くてイラつく。
アクセス制限をかけすぎてCドライブの中身すら見れず
壁紙やツールバーの色すら変えられない。
毎日悶々としています…。
暑いのは効率下がりますね。クーラーが壊れた部屋で汗だくになりながらコードを書いたことがありますが、腕が机にぺたぺたくっつき不快だったことを思い出しました。
ご質問の趣旨がイマイチなのですが...
天国のような職場は、ありません。諦めてください。としか言いようがありません。
もしlifehacksさんが管理職の方で、部下の環境を良くしようとお考えなら、彼らにアンケートを取るべきだと思います。
何のためにこのような質問をなさっているのでしょう?
難しい質問ですね。
効果のない標準化ルール
私は標準化ルールを作る側にいましたが,これは一歩間違うと,大変な目にあいます。
私はソースコードを72列以内に改行しなければならないという「標準化ルール」を体験したことがありますが、書いている間は良いですが、読むのがしんどいコードになりました。
コードレビューのレビュー
ちょ、おま、それレビューしたら今までやってきたレビューの意味なくなるじゃんってかんじですね
コードレビューのレビューって、レビューを何度もするということですか?それとも、レビューの仕方を確認するということでしょうか?
今の自分の話ではないのが恐縮ですが、聞いている限り最も最悪なのが、
「残業の禁止」です。
社員の健康管理、福祉の面ではメリットもありますし、
1人の単独作業によるコーディングの場合は
スケジュール管理が厳密化される良い効果もあります。
しかし、大規模プロジェクトでこのルールがあると、チームの誰かが遅れて足を引っ張った時点で連携が取れなくなります。
・他の人の作業終了を待ってからでないと自分の作業が進められない。
・事態を把握していないリーダーからサボっているように見られる。
・やっと進められると思ったら強制的にオフィスを追い出される。
・なぜか翌朝には全体の遅れが自分のせいにされている。
・これを見越して早出をしたくてもそれも不可能。
……など、かなり高確率で誰かが不利益を被る事態となります。
残業前提で作られた納期は、結果目も当てられないことになることが多いですね。ただ、やらなければならないときに残業が禁止はスケジュールが厳しくなったらどうするんでしょうか?
メインはJavaです。
・フリーのソフトウェアをインストール禁止
別になんてことなさそうなんですけどこれが意外と。
ランチャーとか、前の職場で使いまくってたのに、
使えなくなると、すごく作業がやりにくいです。
あと不満なのは
・外部へのメール(WEBメール含め)禁止
他社の協力としてきているので
自社の勤怠や、連絡事項がすぐに送れないのは面倒ですねー。
セキュリティ上仕方がないといえばそれまでなのですが。。
私もランチャーは良く使います。エディタの起動とか。
前にあった会社の話ですがこんな感じでした。
・インターネットが社員のみ使用可能
→僕は外注として常駐していたのでネット検索できませんでした。
・ソフトウェアインストール禁止
→有償ソフトウェアはもちろんそうなのですが、フリーソフトウェアも
インストール禁止でした。(秀丸とかEmEditorが使いたかった。。)
基本、TeraTermのみインストールしてあり、開発はviでした。(でもこれはスキルアップになりました。)
・ソースファイルのバージョン管理をしない
→CVSとかファイルをバージョン管理をしていない。
ソースのバージョン管理が無いと何かあったときに大変そうです。ネットが使えないという環境は意外と多いですね。
メインはJava、PHPです。
今の職場ではなく、前の職場のことです。
さらに、ルールや決まりごとではないですが、私が思った「効率を下げる要因」を書いていきます。
【無駄に長い納期】
既存システムの移行に、納期2年。。長すぎでした。
最初の1年半は分析調査に費やし、半年で実装。
その一年半は、納期が先ということでダラダラ。今思えば何をしていたんだろう。
その間に作った、実装離れしすぎたコーディングルール、ネーミングルールは、実装の足を引っ張るだけで役立たず。
残り半年の実装は地獄。ほぼ毎月残業200h。
【誰もケツを拭かない体質】
複数の会社が同等の契約関係で関わったせいか、責任が曖昧。
「この話は○○だったんじゃないの?」「ここはあなたの会社の担当でしょ?」「いや、私達はちゃんと提案したはずだ。」などなど、責任の擦り付け合い。
最後の最後は、「これはこういう制約があるシステムです。」とユーザーにごり押しして逃げる始末。。
【「いい物を作る」なんてダメ、「仕様どおりに作れ」】
仕様どおりに作るのは「正解」だという意見の方が多いかもしれません。
でも私はあえて「仕様どおりに作れ」は最低のルールだと言いたいです。
ダメだと気づいても「仕様どおりだ」で一蹴。これじぁモチベーションはあがらない。
仕様出しの段階で完全に見えていれば、仕様どおりに作ればいいんだろうけど、、けっこうそこまで見える人って少ないと思います。そんな「超人」に期待するルールはやっぱりダメだと思います。
【親会社の天下りさんがマネージャーなプロジェクト】
コンピューターをまともに使えない、親会社の天下りがマネージャーのプロジェクトは、最悪に効率が悪いです。
UI部分の進捗だけ見て、
「お、綺麗になってきた。もうそろそろ完成しちゃう?」
「なんだこの骨組みみたいな画面!全然出来てないじゃないか!」
と素人丸出しの指摘を当たり前のようにする。しかもそれが「通ってしまう」ため、裏側のロジックを作成するフェーズなのに、なぜか合わせてUIも作りこむ始末。
「システムを作っている」というより、「一人の素人を納得させるための芝居をしている」感覚。
「実装離れしすぎたコーディングルール、ネーミングルール」時間があるとこんな無駄なことをしてしまうんですね。
「UI部分の進捗だけ見て、、、」はどこかで聞いたことがあると思ったらJoel on Softwareに似たような話がありました。
社内でいれている、セキュリティのチェックソフト。
(アンチウイルス系とは別)
とんでもなく重くなり、PCのレスポンスがわるくなることがよくある。
PCへの負荷も考慮して作られたわけでは無さそうですね。これはひどい。
メインはJavaですね。
会社の標準化がメインフレーム文化をベースにしていて、何かと制約とか多いです。
・ロジック(コーディング)を日本語にしたままの詳細設計書を描くことが前提になっている。
・ソースにコメントを描くことで、リビジョン管理をしようとしてる!?複数人が同じソースをいじることが想定されてない。
あと、空調の音がうるさい割にちっとも効いてない。とか。
「ソースにコメントを書くことで、リビジョン管理をしようとしてる!?」これは体験したことがあります。コード中もR1.Xといったコメントだらけで、可読性が下がってました。
VB.NETを使用しています。
社内で作られた、汎用性のない独自フレームワーク。
常時バージョンアップがされていればいいのですが、1年くらいほったらかしです。
しかも、.NET Framework 2.0の新しい機能などが使えない。
すでに、会社の資産となっているので手放せない。(上司発言)
新しい機能が使えないのはつらいです。
「会社の資産となっているので手放せない。」そんな資産はさっさと処分したらいいのに、変な会社ですね。
最近はC++、Java、C#、rubyあたりです。
excelで作られた重厚なテストケースとか仕様書とかレビュー表などですね。開くだけで1分かかります。
ちなみに開発PCはCore2DuoT7200 Memory2GBですが関係なく重いです。
excelで変に結合されたセルに、boost::testの実行結果等を張り付けてます。
また、テストシナリオ1つが1ブックで、全部同じ名前とかなんでwhereisとかできんのですわ。
テキストでいいよ。全く。
「最近はC++、Java、C#、rubyあたりです。」たくさんですね。テストケースとか仕様書、、、Excelしばり。私も一時期Excelでドキュメントを作ることが目的になっている環境にいたことがありますが同じような経験をしました。開発PCは豪華なので、「良い職場だ」という声が聞こえてきそうですが。
某お客さんのところでは
・Web利用できない(メールは可)
なのにお客さんから「ググればするわかるでしょ?」と…
・工程をものすごく細かくフェーズにわけて、それをすごく使いづらい工数管理システムに入力を強制される
・1行ソースを直すのもお客さんの偉い人がレビューに同席し承認が必要
なので腐ったコードでも書き直すとレビュー量が増える(テストのレビューも)のだが、その工数がないので、できるだけ少ない量での修正することになる
というわけで、実際にモノ作ってたのは作業時間の5%ぐらいのような気がします。
コントですな。
phpで開発をしていますが、「ルールが無いこと」が一番困っています。
立ち上げたばっかりのベンチャーで、入社してからこれまでシステム屋は私ひとり・・・。
しかも、たいして理解していない状況で、責任者をまかせられています。
プロデューサやデザイナーがプログラムへの配慮が全く無く、そのためのルールさえ何も無いので、毎回、やりとりが重複して無駄が多すぎで・・・。
彼らが悪いわけではないことは分かっているつもりなのですが、あまりの配慮の無さについついあたってしまいます・・・。
今、そういったルールを作っているところです・・・。
むしろ、そういったルールで参考になるものを教えていただきたいぐらい・・・。
頑張り屋のwildwellさんに愛の手を。良回答に期待。
前の職場は親会社が買収されたときにセキュリティの向上という名目で入退室が一日一回までになりました。それと同時にIDカードによる入退管理も始まりその結果、
・勤務時間中に外に出られない
昼食・飲み物は持ち込み。緊急の用件で客先に行ったらその日には戻ってこられない。
・部内喫煙解禁
喫煙者が仕事にならないという理由で解禁されました。
非喫煙者の私にとっては煙とニオイが何よりもストレスでした。
・残業できない
退室時間で申請外の残業がわかってしまう。給与にも影響する。
他にも承認を受けた相手以外とのメールのやりとり禁止とか正社員以外WEB使用禁止とかもありましたが、物理的な行動を制限されるのが一番効率が落ちると思います。
VB6とVB.NETがメインです。
・Norton AntiVirus Corporate Edition
スキャン激重。管理者スキャンというのが設定されていて、毎日12:00に全ドライブを強制ウイルススキャンする。
ローカルPCは重ければ手動で強制終了できるが、部内で共有しているファイルサーバはスキャンが止められない&スキャン対象ファイル多数のため、いったん始まると17:00前後までスキャンが終わらない。
よってサーバレスポンスが著しく重くなり、サーバ上ででかいファイルの開発資料を開こうモノなら1~2分は固まる。
セキュリティ上、スキャンが重要なのはわかる。でも、正直勘弁してくれ。
ファイルサーバーのスキャンは夜中にやったら良いと思いますが。
多人数なプロジェクトでマネージャーが一人しか居らず、
すべてその人を通さないと事を進めることができなくて
待ちがかなり発生しました。
ちなみに参加当日は忙しいからちょっとコレを読んでい
てくれと言われて、ツールか何かの小冊子を渡されて次
に会えたのは2日後でした。
何もせずに椅子に2日も座っているのはかなりキマス。
もちろんその小冊子は暗記してしまいました。。。
現場に充分な権限が無いということですね。「この件は全部君にまかせた」と言えない小心者マネージャーが良く無いということがわかります。
今いる現場の子会社の話なので当事者ではありませんが...
ネットはOKだけど、協力会社の場合プリンタが使えません。印刷したい場合、社員にお願いするそうです。
だから自己ソースチェックも目検が中心となるし、SEレベルになれば対外ドキュメントも作成するのに印刷が自由にできないというのはいかがなものかと。
中途半端な制約が業務効率とクオリティに支障をきたすのであれば、意味をなさないですね。
私は協力に行ったときにLANに入れず、PHSからメールでWordやらExcelやらのドキュメントを送っていたことがあります。もちろん印刷もできませんでした。充分な道具が与えられない環境は困りますね。最近はセキュリティ云々でそんな環境が多くなっているのでしょうか?頂いた回答を読んでそう感じました。
まじですか?「ネットが使えません」って。