SE の業務においてプログラムがいかに重要で、また相対的に重要でないかについて説明します。
SE の仕事といって何を思い浮かべますか？もっともイメージしやすいのは、何やら暗号のような文字列（＝プログラム）との格闘でしょうか。プログラミング、はい、その通りです、と言いたいところですが、残念ながら、実際プログラムを触る[1]開発の現場ではプログラムはソースコード、或いは単にソースと呼ばれ、プログラミングをコーディングと呼ぶこともある。機会というのは全行程での 2割〜 3割程度と言われています。
ちなみに、システム開発では概ね以下のような工程を踏みます。[2]ここでは最もスタンダードな工程を洗い出しているが、実際スキップされる工程もあれば増える工程もある。
- 要件定義（業務要件の洗出し）
- 外部設計（利用者目線の設計）およびレビュー[3]成果物を第三者が確認すること。
- 内部設計（開発者目線での設計）およびレビュー
- 詳細設計（プログラミングのもととなるもの）およびレビュー
- プログラミングと単体テスト（プログラミングロジックの検証）
- 結合テスト（プログラム同士を結合する開発者目線のテスト）
- 総合テスト（実際にオペレーションを行う、利用者目線のテスト）
- 受入テスト（システムが業務要件を満たしているか確認する最終テスト）
- サービス開始
上記の通り、数ある工程の中でもプログラミングしている工程は全体から見るとほんのわずかなものです。但し、最近はアジャイル開発[4]細かな要件を短いサイクルで取り込んでリリースする開発手法。プログラムを正とするため、設計工程の多くが省略される。など、プログラミングをより重視する傾向があり、今後はもう少しプログラミングの比重が増えるものと考えられます。[5] … Continue reading
つまりプログラミングというものは出番が少ないわりに高度な技術なのです。誤解のないように申し上げますが、プログラミングはシステム開発において最重要であることに間違いありません。どれほど斬新な企業戦略があろうと、完全な設計書があろうと、動くもの（プログラム）がなくてはシステムは機能しません。ここで申し上げたいのは、プログラミングはシステム構築の最重要ファクタである一方で高い学習コストが必要[6]また、プログラミング言語は多様であり、ひとつの言語を扱えたところで、別のプロジェクトではほかの言語をはじめから学習する必要があるであるということです。
それと比較して、日常のタスクを省力化するために用いられる知識やスキルは学習コストが低く、しかしながら（特に中長期的に）大きな効果が期待できます。
例えば普段 Excel で頻繁にセルの色を変えるとしましょう。チェック NG でセルを赤に、チェック OK でセルを黄色にしたとします。その場合、セルを選択して上部リボンの塗りつぶしボタンで色を選択します。最後に選択した色が設定されているので、常にチェック OK だったら塗りつぶしボタン押すだけでよいのですが、途中で NG の赤となった場合、色を赤に選択する必要があり、その後再び OK であれば色を再び黄色を選択し直す必要があります。
これを赤と黄色の塗りつぶしをショートカットキーに割り当てたらどうでしょうか。マウスを操作することもなく、キーボードで完結することで、塗りつぶしに要する時間が数秒程度短縮されます。操作自体は数秒かもしれませんが、これを例えば 1回あたり 3秒の短縮だとして、この作業を毎日 100件実施するとします。その場合は、一日あたり 3 × 100 = 300秒（5分）の短縮となり、月 20営業日だとすると月間 5 × 20 = 40分、年間 40 × 12 = 480分、つまり 1年で 8時間、おおよそ一日の労働時間程度の短縮となるのです。
この例えではわずかな省力化ではありますが、これがそのほかの定型業務で同じような工夫をした場合、月単位・週単位でも大きな効率化となることは想像しやすいと思います。現在の業務を見直し、1日あたり 1時間以上の効率化も不可能ではありません。そしてその捻出した時間をもっとクリエイティブな時間に注力することでさらに高度な成果を生み出すことが可能なのです。これは IT 業界に限った話ではありません。
システム開発の現場ではスケジュールが厳粛で、1日単位で進捗を問われます。プログラミングのスケジュールも確保されておりますが、実際に必要な時間が必ずしも確保されているとは限りません。それはお客様から発注を受ける時点でプログラムを構築や改造することはないためです。そしてほとんどのケースでスケジュールされた時間を超過します。それを経験的に知っている技術者は効率化の工夫を施すことで、最重要工程であるプログラミングの時間をできるだけ多く確保するのです。
まとめ：
- システム開発でプログラミングは最も重要
- 日常にちょっとした工夫をすることで中長期的に大きな効率化が可能
- 効率化して捻出した時間で重要な業務に注力し、大きな成果を上げる
あ、うんちくだけで終わっちゃった…具体的なメソッドなどはまた今度ということで。
脚注
| ↑1 | 開発の現場ではプログラムはソースコード、或いは単にソースと呼ばれ、プログラミングをコーディングと呼ぶこともある。 |
|---|---|
| ↑2 | ここでは最もスタンダードな工程を洗い出しているが、実際スキップされる工程もあれば増える工程もある。 |
| ↑3 | 成果物を第三者が確認すること。 |
| ↑4 | 細かな要件を短いサイクルで取り込んでリリースする開発手法。プログラムを正とするため、設計工程の多くが省略される。 |
| ↑5 | 実際自社サービスなどの新規事業では事業そのものが不透明なため、設計に落とし込むことが難しい。また、ゲームソフトの開発で少人数だと、設計工程そのものがないこともある。 |
| ↑6 | また、プログラミング言語は多様であり、ひとつの言語を扱えたところで、別のプロジェクトではほかの言語をはじめから学習する必要がある |
