【IT業界の病理学】IT業界のあるあるやその対処法を紹介！IT業界で起こりうる問題を頭に入れて適切に対処しよう

「IT業界の病理学」という書籍から、IT業界のあるある話を厳選して、その対処法などを解説していきます。

「IT業界の病理学」から問題を厳選して、その問題から解決策と私のこれまでの経験を交えました。

現在、IT業界で仕事に悩んでいる方やこれからIT業界で働きたいと思っている方はぜひ参考にしてみてください。

開発編

まずは開発における問題です。

開発現場では時に混乱を招くようなことが起こります。

これは様々な要因が関係してくるのです。

開発編では下記3つを取り上げます。

仕様が決めれないユーザ

参考：IT業界の病理学　P10　司馬著

仕様がなかなか決まらないと、納期が遅れたり開発に着手できなかったりと、様々な問題が起こります。

開発現場にとっては大問題ですね。

上記にもあるように、まずはユーザの状態（誰が責任者で決定権があるのか）を把握する必要がありそうです。

責任者にも要件定義の打合せに参加してもらって、仕様を決めていく必要があります。

予防法でも記載した通り、「仕様確定日」を明確にユーザに展開してしっかりと問題に向き合ってもらうことがよいでしょう。

なんちゃってアジャイル開発

参考：IT業界の病理学　P32　司馬著

アジャイル開発については、私は経験したことがないので明確には語れません。

ですが、アジャイル開発を行う上で大切なことがあるのは知っています。

それは顧客との対話です。

アジャイル開発では米国を中心に流行り、最近の日本でもアジャイル開発を取り入れる企業が増えました。

ですがアジャイル開発がよくて、ウォーターフォールモデルが悪いというわけではありません。

一長一短で、それぞれあったモデルを選択する必要があります。

例えば、システム開発に協力的なユーザならアジャイル開発があっているでしょう。

反対にユーザがあまりシステムについてわからないことが多い場合、または打合せに積極的ではない場合はウォーターフォールモデルの方が良いと思います。

アジャイル開発を導入するなら、まずはアジャイル開発について学ぶことが重要です。

さらにユーザにもアジャイル開発を導入していることを伝えて、短いサイクルで開発を繰り返すことを説明する方がよいでしょう。

絶対にされないソースコード

参考：IT業界の病理学　P41　森著

すでに現場で動いているシステムのソースコードを触るのは勇気がいります。

私が携わったプロジェクトで、ユーザからの要望が多くその都度対応していたら、スパゲッティコードになってしまいました。

要望が多く重なると、他が動かなくなることを恐れて、共通化することをためらったり、動いているものを止めたくないという心理から、プログラムを書いた人しか読めない状態になってしまうのです。

このような場合、リファクタリングをしようにもできない状態のため、そのまま放置しがちとなります。

これらを解決するには、開発時から汎用性の高いプログラムを組むことです。

コメントを書くことはもちろんのこと、関数同士を疎結合とすることで、それぞれの処理が依存しないように作ります。

ユーザからの要望の対応方法として、関数を追加するだけで対応できるようになれば、要望が多くても関数が増えるだけで、他のところに影響は及ばない。

レビュー・テスト編

参考：IT業界の病理学　P60　都築著

腐敗したテスト仕様書

単体テストや結合テストを終えて、いざ導入となった時、不具合が出てもテスト仕様書まで遡って修正することはあまりないかと思います。

ましてエビデンスまで取り直すということもなく、不具合を修正するだけで手一杯です。

プロジェクトにおいて、開発には工数をかけるもテストにはそこまでの工数を割けないというリーダーもいます。

ですがテスト工程は非常に重要で、導入後の不具合をゼロにすることはできませんが、多少なりとも減らすことはできるでしょう。

必要のないテストを行うのは無駄ですが、ありとあらゆるケースのテストを行うことはとても重要なことです。

私がおすすめするのは、ユーザ目線になってテスト行うこと。

できれば、出荷前のテストをリーダーなり開発者以外が行うことをおすすめします。

きっちりとしたテストではなく、ユーザが行うであろう動作を確認するための最終チェックです。

開発者が行うと、どうしても開発者側の都合のいい風に動かしてしまいます。

それを避けるためにも、開発者以外がテストや動作確認を行うのがよいでしょう。

絶対に見ないエビデンス

参考：IT業界の病理学　P63　森著

テスト後にエビデンスを確認しますか？

私はあまり確認しません。

不具合が起きても、その不具合を特定するためにプログラムを動かします。

エビデンスまで遡ることは滅多にしないです。

この原因はエビデンスに取り方にあると思います。

エビデンスをきれいに、テストの流れを詳細に記載していれば後から確認しやすいです。

そのためには、エビデンスのテンプレートやエビデンスをとる手順を見直しましょう。

テンプレート一つ見直すだけで、かなりエビデンスを改善することができます。

そうすることで、不具合が発生してもエビデンスを確認してすぐに原因を突き止めることができるでしょう。

テストケース肥大病

参考：IT業界の病理学　P72　鈴木昭著

テストケースを最大いくつ作成しないといけないなどの決まりがあると、このような問題が発生します。

テストケースのノルマを達成するために、必要のない同じようなテストケースを作成してしまう。

結果的に工数が無駄になり、テスターも何を目的にテストをしたらよいのかが見えない。

これらを解決するには、テストケースの最低限のノルマを決めない、またはバグ検出率に焦点を当ててテストを行うことです。

どれだけバグを検出できるでテストの品質が決まってくるので、テストケースを増やすのではなくバグを検出できるテストを想定しましょう。

保守・運用編

「運用でカバー」依存症

参考：IT業界の病理学　P89　司馬著

「運用でカバー」はまさに魔法の言葉で、開発側もユーザ側もよく使ってしまいがちな切り札です。

要件定義で漏れてしまうものが、この運用でカバーとなってしまいます。

まず第一として、要件定義でユーザの運用を把握すること。

システム化するところと、従来通り手作業で行うところを明確にする必要があります。

導入後に、一部が「運用でカバー」となってしまった場合は次のシステム改修か保守で対応を行うのがよいでしょう。

マネジメント編

プログラマのモチベーションが一番大事病

参考：IT業界の病理学　P124　司馬著

プログラマのモチベーションは確かに大事です。

プログラマに限らず、モチベーションが低いとシステムの品質が落ちてしまいます。

なのでいかにプロジェクトメンバーのモチベーションを下げないようにするかが、リーダーやプロマネの仕事です。

人間関係なので、人それぞれモチベーションの上がる要因が違うと思いますが、密にコミュニケーションをとることでモチベーションを上げることが少なからず可能でしょう。

永遠の進捗90%

参考：IT業界の病理学　P135　司馬著

メンバーに進捗率を聞いても、いつも同じ進捗率が返ってくることがありますか？

ずっと進捗率が90%から動かない場合、何かしらの問題が発生しています。

プロマネはその問題を突きとめなければなりません。

しかし、メンバーに聞いても反射的に隠されてしまう場合がありますので、できるだけ正直に話しやすいようにしましょう。

何かプロジェクトに大きな影響を及ぼす可能性のある問題が隠れているかもしれません。

業界の病気編

勉強会は業務ですか？

参考：IT業界の病理学　P148　秋山著

会社が外部のセミナーなどを積極的に取り入れて行うと、社員からは「これは給料でますか？」という質問が出ることがある。

仕事は忙しい時はなおさらです。

では、このような問題にはどうしたらよいか。

セミナーを強制するのではなく、自由参加にすることです。

仕事が繫忙期の時は、誰だって他のことはしたくないはず。

そこで会社からセミナーなどをするように言われると、社員としてはやる気を失ってしまいます。

学生のキャリアアンマッチ病

参考：IT業界の病理学　P166　司馬著

企業説明会ではありのままを伝える方がよいでしょう。

良質な学生を採用したいがばかりに、誇張して業務内容を話してしまうと、結局は双方によってよくない結果となります。

採用するにしてもお金がかかりますし、入社した新入社員のモチベーションが低いと、余計にコストがかかってしまう。

さらに新入社員にとっては時間の無駄だと感じてしまうかもしれません。

お互いがプラスになるように、企業側はありのままの姿を見せることが必要です。

まとめ

本記事ではIT業界の病理学を元に、私の意見を述べました。

IT業界では、本記事で挙げた以外の問題も山積みで、困っている人も多いでしょう。

本記事によって、少しでも解決の糸口になればと思います。

関連記事

参考文献