SEやプログラマの生産性は100倍差が出るという話を例を挙げて説明します。

仕事
この記事は約5分で読めます。

SEやプログラマの生産性は、有能と無能で10倍も100倍も差が出るで言われますが、そんなことありえるかという話。

あると思います!

これまで10年ぐらいSEをやってきた私が例えばこんなケースというのを挙げてみたいと思います。ただし、プログラムが超速いとかそういう話は今回はしません。

スポンサーリンク

前提として

生産性が何を指すかという前提について、これは単純に同じ時間でプログラムのソースコードを何行実装できるかという観点や、顧客に要求された要件をどれぐらいの工数で納品できるか、という観点など幅広い視点で考えることになると思います。

ケース

ケース1

100を100乗して、それをさらに100乗した計算結果を出力する関数を実装せよ。

Aさんの場合

for文を用いて100を100乗して、さらに100乗するプログラムを実装し、最後に処理が正しく動いているか単体テストした。

Bさんの場合

100を100乗してさらに100乗した計算結果を事前に計算し、計算結果を固定値で出力するだけのプログラムを実装した。

ケース2

1000行のエクセルデータがある。Webの入力フォームにみんなで手分けして入力して欲しい。

Aさんの場合

みんなで手分けして1行ずつ手打ちした。

Bさんの場合

自動で入力するツールを作成し、ツールを実行した。

ケース3

氏名、生年月日、住所、性別、メールアドレスを入力させるフォームを実装してほしい。

Aさんの場合

ネットで実装方法を調べながら、実装・テストして納品した。

Bさんの場合

今回の要件を満たすオープンソース、またはプラグインを探し導入した。

ケース4

ここに100ページの書類がある。紙媒体しか無く、電子データは無い。この書類の内容をホームページに掲載したい。ブラウザはIE11とEdge、グーグルクロームで正しく見えるようにしてほしい。

Aさんの場合

まずは書類のデータを手打ちでワードに書き出し、文字の誤字脱字を目視でチェックした。その後、htmlとcssでページを実装し、要件であるブラウザそれぞれで文字サイズやフォントが正しく表示されるか、チェックシートを元に動作チェックを行った。

Bさんの場合

書類をスキャナで取り込み、PDF化して掲載した。

ケース5

100万行ものユーザーデータを分析してレポートをエクセルにて出力後、自動で印刷まで行う既存プログラムがある。今回の業務では、今年度のデータをインプットし、出力したデータを納品しなければならない。また、簡単な機能改修も行う必要がある。納期は1ヶ月。

機能改修も完了し、実データをインプットしてレポートを出力しようとしたところ、想定外のデータが数行紛れ込んでおり、今回の改修箇所ではない既存処理の途中でエラーとなってしまいレポートが出力されなかった。納期まであと1週間で何とかしなければならない。

Aさんの場合

急いでログを確認してエラーの発生箇所を特定した。該当箇所に想定外のデータに関する処理を実装し、再度プログラムのテストを行い、何とか納期ぎりぎりにレポートを提出した。

Bさんの場合

急いで顧客に事情を説明し、想定外の数行のデータを削除する許可を得た。想定外のデータを削除したデータでレポートを作成し、すぐに提出が完了した。想定外のデータの処理は、次年度の改修内容として修正工数を予算に盛り込むことを顧客と約束した。

ケース6

社内SEに社員から電話で問い合わせが入ってきた。お昼休み明けから急に自社のオンラインシステムが使えなくなってしまったという。

Aさんの場合

電話にて詳細にユーザーの状況を聞きだした。いつから使えなくなったか、回りの人も同じ状況か、サーバーの状況やアカウントの状態、ウイルス感染の疑いなど様々な問題について1つ1つ切り分けを行った。

Bさんの場合

すぐに現場に向かい、抜けかかっていたLANケーブルをそっと差し込んだ。

ケース7

データ処理のシステム開発の請負で顧客のオフィスに常駐して作業している。大量処理が必要なテストケースが多く、処理時間が長いため待ち時間が多く発生してしまう業務だ。

Aさんの場合

そのままテストをもくもくと続けた。

Bさんの場合

検証に使う端末をスペックの良い端末に交換してもらい、処理時間を短縮した。また、あまっている端末が複数台あるということがわかったので、それらも借りて、複数台で同時にテストを行った。

さいごに

どうでしたでしょうか。
Bさんのほうが生産性の高いSE/プログラマとして書いてみました。具体的にかかる工数の比較は書きませんでしたが、かかる工数が圧倒的に違いそうというのは何となくわかると思います。

Bの対応は『それはズルい』と思いましたか?『まぁそうするだろ』と思いましたか?

『まぁそうするだろ』と思った方。ぜひ、一緒に仕事しましょ 笑

今回はミスリードっぽいケースで書きましたが、実際の顧客の要望もこんな感じです。

顧客からの要望というのは的を得ているとは限らず、本当に顧客が達成したいことに対して、効率の悪い方法を提示してくる場合がほとんどです。それも「こういうことをしてくれないか」という方法論だけを要求してくる場合があるので、それを鵜呑みにして行うととんでもなく非効率なことがあります。

そのため「なぜ、そうしたいのか。」「本当の目的は何か。」という点に思考を張り巡らせると、何倍も効率的な方法があったりします。

近い考え方にラテラル・シンキング(水平思考)っていう言葉があるらしいですね。

そこがSEやプログラマの生産性が100倍も変わってくるというポイントだと思います。

もし、Aさんの対応でやってしまうだろうなと思った方は、実際に手を動かし始める前に本当にそのアプローチで良いか、立ち止まって考えてみてください。

コメント

タイトルとURLをコピーしました