【システム開発・SIer】SI(受託開発)において、作業品質が改善しにくいたった一つの理由
【今回の紹介】
タイトルはつりです。
たったひとつの理由
なんてないです。
ごめんなさい。
ただ、１年半ほどSIの現場にいた経験を通じて
作業品質が改善していきにくいという現状と改善していきにくい理由について
「大きな理由の一つなのではないかと思うもの」
について
まとめたので、もし興味があれば読んでみてください。
【内容】
■結論
最初に結論を載せておくと、作業品質が改善していきにくい理由は、
「pj構成員の雇用形態」
にあるのではと考えています。
■現状
現状として、
「SIにおいては作業品質が改善していきにくい」
のではと思っています。
以下のようなことを現場で痛感しました
・依頼された作業を依頼されたままやる
・pjを途中で去っていた人が残した冗長的なコード
・本番障害を受け止める態度の違い
※正直、１年半ほどしか現場でキャリアを積んでいないのに、えらそうなことをと思いつつ、
経験が浅いからこそ、第三者的にSIerの状況が見える部分もあるのかなと思います。
■理想
本来は、工程を進める中で作業の進め方、管理の仕方やより効率的に
なるように改善されていくのが理想だろう。
個々の工程ごとの特性のある作業に加えて、pj全般を通して
・ドキュメント管理の仕方
・構成管理
・意識合わせの仕方
・作業管理
・スケジュール管理
・開発全般（開発規約・共通化）
・ドキュメント作成のルール（どこまで行えば完了かなど）
等々の作業がある。
その中で、作業のミス（漏れやずれによる手戻り）の度に、
pj全体でふりかえりと原因分析と再発防止対策を行い、検証し、また対策をうつ。
これを管理側からではなく、pj構成員から自発的に改善していけるのが理想なのかなーと。
※工程ごとに構成員が入れ替わったり、pj人数が大きくなるとなかなか大変ナノではとも思うが。
※ここでいう「効率化」とは以下のことをイメージしています。
・同じ時間で、より質の高い作業をする
例）コーディングでいうと、
同じ時間で、より質の高い（保守のしやすいコードを書く）作業をする
・共通化されている（冗長的でない）
・可読性がたかい
・障害が少ない
・同じ時間で、より多くの作業をする
同じ時間で、より多くの（より多くの機能を実装する）作業をする
■なぜ「SIにおいては作業品質が改善していきにくい」のか
頭でも載せましたが、
雇用形態にあるのではと考えています。
以下のような特徴があるから、本気でpjの作業プロセスの改善を考えないのではないか、
または本気で改善を考えるインセンティブ（誘因）がないのではないかと思います。
①月の労働時間が決まっている（暇でも忙しくても関係ない）
作業時間を短くするような改善をしても、別のタスクが割りあたる
②所属pjへの責任が軽い（上流からリリースまでいるとは限らない）
自分のコードを保守しないため、今バグが出なければいいという風潮
顧客には直接は怒られない
③請負という契約形態のため、頼まれたことしかやらないという意識がある
頼まれたこと以上をやるという発想がなくなってくる。自分で考え、工夫していかなくなる？
（少し飛躍してるかも）
