SEやプログラマの生産性は、有能と無能で10倍も100倍も差が出るで言われますが、そんなことありえるかという話。
あると思います！
これまで１０年ぐらいSEをやってきた私が例えばこんなケースというのを挙げてみたいと思います。ただし、プログラムが超速いとかそういう話は今回はしません。
前提として
生産性が何を指すかという前提について、これは単純に同じ時間でプログラムのソースコードを何行実装できるかという観点や、顧客に要求された要件をどれぐらいの工数で納品できるか、という観点など幅広い視点で考えることになると思います。
ケース
ケース１
100を100乗して、それをさらに100乗した計算結果を出力する関数を実装せよ。
Ａさんの場合
for文を用いて100を100乗して、さらに100乗するプログラムを実装し、最後に処理が正しく動いているか単体テストした。
Ｂさんの場合
100を100乗してさらに100乗した計算結果を事前に計算し、計算結果を固定値で出力するだけのプログラムを実装した。
ケース２
１０００行のエクセルデータがある。Webの入力フォームにみんなで手分けして入力して欲しい。
Ａさんの場合
みんなで手分けして1行ずつ手打ちした。
Ｂさんの場合
自動で入力するツールを作成し、ツールを実行した。
ケース３
氏名、生年月日、住所、性別、メールアドレスを入力させるフォームを実装してほしい。
Ａさんの場合
ネットで実装方法を調べながら、実装・テストして納品した。
Ｂさんの場合
今回の要件を満たすオープンソース、またはプラグインを探し導入した。
ケース４
ここに100ページの書類がある。紙媒体しか無く、電子データは無い。この書類の内容をホームページに掲載したい。ブラウザはIE11とEdge、グーグルクロームで正しく見えるようにしてほしい。
Ａさんの場合
まずは書類のデータを手打ちでワードに書き出し、文字の誤字脱字を目視でチェックした。その後、htmlとcssでページを実装し、要件であるブラウザそれぞれで文字サイズやフォントが正しく表示されるか、チェックシートを元に動作チェックを行った。
Ｂさんの場合
書類をスキャナで取り込み、ＰＤＦ化して掲載した。
ケース５
100万行ものユーザーデータを分析してレポートをエクセルにて出力後、自動で印刷まで行う既存プログラムがある。今回の業務では、今年度のデータをインプットし、出力したデータを納品しなければならない。また、簡単な機能改修も行う必要がある。納期は1ヶ月。
機能改修も完了し、実データをインプットしてレポートを出力しようとしたところ、想定外のデータが数行紛れ込んでおり、今回の改修箇所ではない既存処理の途中でエラーとなってしまいレポートが出力されなかった。納期まであと1週間で何とかしなければならない。
Ａさんの場合
急いでログを確認してエラーの発生箇所を特定した。該当箇所に想定外のデータに関する処理を実装し、再度プログラムのテストを行い、何とか納期ぎりぎりにレポートを提出した。
Ｂさんの場合
急いで顧客に事情を説明し、想定外の数行のデータを削除する許可を得た。想定外のデータを削除したデータでレポートを作成し、すぐに提出が完了した。想定外のデータの処理は、次年度の改修内容として修正工数を予算に盛り込むことを顧客と約束した。
ケース６
社内ＳＥに社員から電話で問い合わせが入ってきた。お昼休み明けから急に自社のオンラインシステムが使えなくなってしまったという。
Ａさんの場合
電話にて詳細にユーザーの状況を聞きだした。いつから使えなくなったか、回りの人も同じ状況か、サーバーの状況やアカウントの状態、ウイルス感染の疑いなど様々な問題について１つ１つ切り分けを行った。
Ｂさんの場合
すぐに現場に向かい、抜けかかっていたＬＡＮケーブルをそっと差し込んだ。
ケース７
データ処理のシステム開発の請負で顧客のオフィスに常駐して作業している。大量処理が必要なテストケースが多く、処理時間が長いため待ち時間が多く発生してしまう業務だ。
Ａさんの場合
そのままテストをもくもくと続けた。
Ｂさんの場合
検証に使う端末をスペックの良い端末に交換してもらい、処理時間を短縮した。また、あまっている端末が複数台あるということがわかったので、それらも借りて、複数台で同時にテストを行った。
さいごに
どうでしたでしょうか。
Ｂさんのほうが生産性の高いＳＥ/プログラマとして書いてみました。具体的にかかる工数の比較は書きませんでしたが、かかる工数が圧倒的に違いそうというのは何となくわかると思います。
Ｂの対応は『それはズルい』と思いましたか？『まぁそうするだろ』と思いましたか？
『まぁそうするだろ』と思った方。ぜひ、一緒に仕事しましょ 笑
今回はミスリードっぽいケースで書きましたが、実際の顧客の要望もこんな感じです。
顧客からの要望というのは的を得ているとは限らず、本当に顧客が達成したいことに対して、効率の悪い方法を提示してくる場合がほとんどです。それも「こういうことをしてくれないか」という方法論だけを要求してくる場合があるので、それを鵜呑みにして行うととんでもなく非効率なことがあります。
そのため「なぜ、そうしたいのか。」「本当の目的は何か。」という点に思考を張り巡らせると、何倍も効率的な方法があったりします。
近い考え方にラテラル・シンキング（水平思考）っていう言葉があるらしいですね。
そこがＳＥやプログラマの生産性が100倍も変わってくるというポイントだと思います。
もし、Ａさんの対応でやってしまうだろうなと思った方は、実際に手を動かし始める前に本当にそのアプローチで良いか、立ち止まって考えてみてください。
＜関連記事＞