残業に対する現状の認識について疑問点があります。個人的に「残業」とは、予定の期間内に担当している作業を完了する事ができない場合に、それを補う形で行うもの、であると考えています。残業の要因としては大きく分けて２つあります。
前者は開発者の責任で、後者は管理職の責任において発生します。単純に考えれば優秀な開発者は仕事が早くこなせるはずであり、優秀な管理者は開発スケジュールをきちんと計画できるはずなのでどちらにしろ「残業」を行うと言う事は仕事上での何らかの不具合が発生しているということに他なりません。
しかしながら現状では「残業」するということの根本的な理由である「効率よく仕事ができていない」という事実は棚上げされ、単純に見た目だけの「仕事にとりくむ姿勢」であるとして、肯定的なニュアンスで取り扱われている風潮があります。「残業」しているということが即、「頑張っている」と見なされそれがそのまま「評価の対象」になっていることに強く疑問を感じます
また、このような風潮に伴ってか、残業を奨励、または強制したり残業している事を自慢するような場面が多数見られます。本当に実力のある人は仕事をすばやくこなし、残業をする必要は無いはずですしかし実際には、残業している人に対しては「頑張ってるなあ」という認識がなされ、早く帰る人に対して「もう帰るの？」「暇なの？」という皮肉ともとれるような発言がなされることも少なくありません。
この業界に５年以上勤めてきて痛感したのは「残業時間とソフトの品質は反比例する」ということです。各担当は自分に割り当てられた仕事を期間内に終わらせなければなりません。また、それと同時に生成されたソフトの品質についても責任があります。無茶な工程で作業を進めればそのソフトの品質は低下していきます。
火を吹いたプロジェクトを沈静化させるために開発期間の延長では無く残業時間の超過という対応を行った場合、どういう結果を招くのかを嫌と言うほど見てきました。混乱はさらに混乱を招きます。個人的なことですが＊＊＊＊＊＊＊＊＊＊＊Ｖ２．０の開発は開発期間とソフトの品質のバランスを保つには限界ぎりぎりの線でした。バランスを取りながら開発するということは仕事とはいえ至難の技です
ソフト開発という個々の技術力に非常に依存する仕事の性質上、残業やむなしといった側面があることは充分認識しています。もちろん頑張っている結果として残業している人も多く存在します。しかし、それに乗じて本来の意味合いを無視し、無条件に「残業するのは当たり前」「残業している人は頑張っている」という短絡的な考え方は改めるべきではないでしょうか。また、作業上やむなく残業や休日出勤を要請する場合には、その理由についての明確な説明がなされるべきだと思います。
最近、＊＊＊＊＊の導入と共に今までリーダーが行っていた作業を開発者レベルにも担当してもらおうという動きがあります。しかしながらその作業習得の手順として勉強のためのシュミレーションではなく、いきなり「実作業としての管理業務」を行うことから始められています。この「実作業」であるということが開発者と管理者の間に大きな誤解、不信感を招いています。
確かに次期リーダー候補と思われる人は存在しますし、僕自身も入社５年目を過ぎ、そろそろ管理業務とは何かを勉強しはじめてもおかしくは無いと思います。入社２年目の社員までもが「見積もり書の作成」や「外注発注」の処理をさせられているというのはどういうことなのでしょうか？ これも「将来リーダーになるための準備」なのでしょうか？
少なくとも今回の「管理業務の習得」についての目的や方法などについての「公式な説明」は何もなされていないと記憶しています。何の説明も無いまま、今までリーダーが行っていた作業を開発者に行わせるわけですから、「リーダーの業務を押し付けられている」と感じても不思議では無いと思います。多くの事が、なし崩し的に進められているように思えてなりません。
先に述べたように「実作業」とはシュミレーションではありません。それなりのリスクと責任を伴う実際の管理作業です。開発者には開発者としての責任とリスクが伴います。そこに管理業務としての実作業を行わせるという事は時間的にも精神的にも開発効率の低下が発生するのは明らかです。管理職の方々はそのことについて了解されているのでしょうか？
（＊）この件に関して、あまりにも納得のいかない点が多かったので ＊＊＊ＫＨに個人的なミーティングの場を設けていただきました。 以下、その時のセッション内容です。
Ｑ：今回の管理業務の移行に関する一連の動きの意図は？
Ａ：開発者各自が責任者として自立してもらうための第一段階である。
Ｑ：他のプロジェクトでもほぼ同時期に同じような動きがあったがこれは部としての方針なのか（部長からの指示か？）
Ａ：部長からの指示ではなく、あくまでもリーダーの裁量によるもの。時期がかさなったのは偶然である。
Ｑ：チーフ、サブチーフで無い者が管理作業を行うことに関して
Ａ：チーフ、サブチーフはあくまで肩書きでしかなく実際の管理作業とは関係無い。
Ｑ：いきなり実際の管理作業から行うのはなぜか？（最初にある程度教育してからの方が良いのでは？）
Ａ：本当は教育ＷＧを作って指導したいが、現状の体制では無理。
Ｑ：入社２年目の社員が見積もり作業、外注発注を行うことについて
Ａ：別におかしいことだとは思わない。外注発注は機器購入と同じである。
上記の解答の全てに納得したわけではありませんが、とりあえず管理業務を習得することの重要性については理解したつもりです。
個人的な現状としては、実際の業務において管理作業（見積書の作成等）が必要となったタイミングで逐一、マン・ツー・マンで指導を受けています。しかしながら教える立場としては＊＊＊＊＊操作の煩雑さや実作業であるということからくる時間的拘束などにより、なかなかスムーズには行きません。また教えられる側も複雑な一連の管理作業における「スポット的な理解」にとどまらざるを得ず、残念ながらあまり効率の良い方法であるとは思えません。
現在、管理業務の教育は各プロジェクトのリーダーに依存した形になっていますが、あまりにも説明不足、準備不足、非効率的であると感じています。やはり、部としての教育体制（ＷＧの発足、教育資料、カリキュラムの作成など）をきちんと整え、その時点で改めてリーダー候補となる人物を選別し合同での研修時間を設けるなどして効率的、段階的に進めていくべきだと考えます。
＊＊＊＊センターのレイアウトを変更すると（噂でですが）聞きました。現状のセンターに＊＊さんを含め複数名が移動するらしい、であるとかもう机が運び込まれている、などいろいろな話が（あくまで噂として）飛び込んできます。
しかし、自分の記憶では今回のレイアウト変更について、＊＊部長からもリーダーからも正式な発表は全くなされていないと認識しています。部内会議でもその件についての説明はありませんでした。個人的に確認したところ、レイアウト係の方も何も連絡は受けていないとの事でした。
どんな理由があるにせよ、端から見ている者としての印象では＊＊＊＊センターのレイアウト変更が管理職レベルで勝手に進められているように感じています。それは先に述べたように誰からも何の説明も無いからです。
この「何の説明も無い」ということによって開発者の間では管理職に対しての強い不信感が広がっています。
現状でも、センターが設けられたことにより作業に支障を来たしている面があります。ミーティングや連絡次項、諸係、コミュニケーションや情報収集、お互い今日来ているのかどうかさえ分からないわけですから当然の結果です。間違いなく作業効率が落ちていると感じています。
しかし最も疑問なのは「本当にセンターに人を追い遣らないと駄目なのか？」ということです。移動した人の分のフロアスペースが空くという事以外、これといってメリットが無いように思えるのですがこの件に関して明確なメリットが存在するのでしょうか？（個人的にはメリットどころかデメリットの方が心配です）
また、「朝番、遅番」のシステムについてもかねてから疑問があります。＊＊＊の社員契約では勤務時間 ９：００〜１７：５０（コアタイム１０：００〜１５：００）完全週休２日、一日あたり７．５時間勤務となっています。
もちろん先の残業の項で述べたように、作業が期間内に終わらないような状況であるならば時間外勤務、休日出勤をしてでも、それを完了させる責任があると思います。また社員規約がどうであれ仕事の内容によって臨機応変に勤務体系が変化するということも認識しています。
しかし「朝番、遅番」の場合は休日出勤や自宅での作業などが「デフォルト」として位置づけられており、規定の勤務時間外まで確実に「拘束される」という点で通常の残業とは決定的な違いがあります。
この仕事を受注する際、実際に作業をすることになる担当者レベルに対して「＊＊＊社員としての契約内容とは異なる勤務体系になる」というような明確な説明はなされたのでしょうか？また、それに対する正式な形での承諾は得ているのでしょうか？とにかく仕事だからという理由でこれらの重要な事柄は後回しにされ、なし崩し的に進められているように思えてなりません。
＊＊＊＊センターの仕事は従来の受託開発とは異なる新しい形態のサービス事業であるということは認識しています。しかし新しい試みであるならば、なおさらのことそれらの運営方針を明確にしておく必要があると思います。
また直接作業に携わっている担当者に対しては、通常の勤務体系の枠を超えているという事に対する何らかの優遇措置（特別手当の至急、シフト勤務の承認、確実に代休を取得させる等）を実施すべきではないかと考えます。
パッケージを取り扱う会社の開発部隊の一人としてその知識や情報量、スキルなどまだまだ足りない部分が多いと思っています。もちろん期待に添うように日々努力はしているつもりなのですが個人レベルではどうしても限界があります。
開発作業においては、いかに有効な情報を持っているかが重要な鍵になると考えます。ある事柄を実現するため、その手段の調査に長い期間を費やす事は珍しくありません。調べてみた結果、ソースコードに数行追加するだけで良かった場合も多々あります。これがもし、「数行追加するだけで良い」ということを知っている人と事前に情報交換ができていたならば調査の時間は大幅に短縮できたはずです。このような情報は「今は何を開発している」、「こんな環境でやっている」などの普段の何気ない会話によって伝えられる事がほとんどです。
少ない人数で他社の技術レベルに対抗していくには開発者同士の知識の共有、結束力が絶対に不可欠です。現在、開発環境が二つのフロアに渡って分断されていることでただでさえ貴重な情報交換、コミュニケーションの場がかなり犠牲になっており、非常に残念に思います。それぞれの技術を切磋琢磨していくためにも、また課のチームワーク、雰囲気を維持していくためにも開発者は可能な限り同じ場所で作業をすべきであると考えます。
また、フロア全体を見渡して見るとうちの課だけが異常に人口密度が高いような気がしてなりません。他の部署のことなので詳しい事は分かりませんが、ただマシンが追いてあるだけ、荷物が積んであるだけ、机はあるが人はいないなど無駄になっているようなスペースがかなりあるように思います。
個人的な話になりますが、自分の座席の空間は両サイドが席につくと伸びもできないくらいに接近しています。にもかかわらずこの場所はメインの通行路になっており人の往来が非常に激しく、通過する際に椅子を蹴られるなどして集中力を折られることしばしです。
座席の配置をフロア全体でもう一度見直すことで、無駄なスペースを排除しその空間割り当ての均等化し直すことはできないでしょうか？ また、喫煙ルームの設置、喫煙マナーの徹底化とともに再度検討をお願いいたします。
最後になりましたが、このような意見を述べる場を提供していただいた＊＊部長に感謝いたします。
以上。