今回は「アプリケーション設計」という仕事に焦点を当てていきます。
皆さんはシステムエンジニア(SE)とプログラマー(PG)という職種が、厳密には違った仕事をしていることをご存知でしょうか？同じIT人材であっても、SEかPGかによって仕事内容は大きく変わります。ちなみにアプリケーション設計を担っているのがSEです。
まずはこのSEとPGの違いから確認していきましょう。
SEという名の「建築士」、PGという名の「大工」
SEとPGの関係を明確に言い表すならばそれは「建築士と大工のような関係」です。たとえば一つの住宅を建築するにあたって、建築士は住宅そのものを設計します。住宅内部の構造や外壁の種類、壁紙などあらゆる要素を設計し建築のための土台を作ります。大工はその設計に従い、実際に住宅を建築していきます。建築士と大工の関係は信頼の上に成り立っていると言えるでしょう。
SEとPGもこれと同じです。システム開発という一つのプロジェクトにあたりSEが設計し、PGが構築します。建築士と大工同様に、SEとPGにも信頼関係が大切です。
ただしSEとPGという境界線は企業やプロジェクトの規模によっても変わります。小規模なプロジェクトや人手が足りないときは、SEがPGを兼任することもあるでしょう。また逆もありえます。
プロジェクトにおけるSEとPGの役割
システム開発というのは一つのプロジェクトとして様々な工程を持ちます。ここでは一般的なウォーターフォール開発モデルを参考に、SEとPGの役割を確認しましょう。
①要件フェーズ
要件分析(SE)…クライアントからシステム開発の目的などを聞き出し現状課題を整理します
要件定義(SE)…ヒアリングした内容をもとにシステムに必要な要件を定義します
②設計フェーズ
基本設計(SE)…ユーザーや運用管理者視点から見た機能やインターフェースなどを設計します
詳細設計(SE、PG)…基本設計をもとに開発者の観点でシステム内部を設計していきます
③実装フェーズ
コーディング(PG)…詳細設計をもとにして実際にプログラムを記述します
④テストフェーズ
単体テスト(PG)…プログラム単位でテストを実行してバグがないかを確認します
結合テスト(PG)…各プログラムを結合し一つの機能として動作するかを確認します
システムテスト(PG、SE)…全体の動作を確認し設計通りに構築できるているかを評価します
運用テスト(SE)…クライアントと共にシステムの動作を確認します
各工程ごとの役割を見てみると、SEはクライアントとコミュニケーションを取る機会が多くマネジメント要素が強く求められる職種です。PGはクライアントと接する機会は少ないですが、SEと積極的にコミュニケーションを取ってクライントが求めるシステムを常に意識することが大切です。
SEとPG、それぞれに求められる能力
役割が違えばそこに求められる能力も当然違います。同じIT人材であっても、SEに向いている人とPGに向いている人がいます。では、それぞれに求められる能力とは何でしょうか？
≪SEに求められる能力≫
クライアントとかかわる機会が多いためコミュニケーション能力は強く求められます。単に会話できるかではなく、クライアントから上手くシステム要件を引き出すための業務知識なども重要でしょう。プロジェクトの途中で要件変更が起きると手戻りが大きくなるため、要件フェーズでクライアントの課題をうまく引き出せるSEは優秀といえます。
マネジメント能力に関しても求められるシーンは多いでしょう。SEは設計者でありプロジェクトの監督者でもあるため、スケジュールがスムーズに進行するように管理するのも仕事です。
これに加え、実際にシステムを実装するPGとも正確にコミュニケーションすることも大切なので基礎的なプログラミングスキルは欠かせません。
≪PGに求められる能力≫
プログラミングに限らず技術というものは日進月歩で発展し続けています。昨日までトレンドだった技術が今日には廃れているかもしれません。プロジェクトにおける技術者であるPGは、こうしたトレンドに対応するため常に新しい技術を吸収しようという気構えが大切です。優秀なPGは得てして学ぶことの喜びを知っています。
また手間がかかることは自動化するなど、いわば効率化の精神も求められる能力の一つです。プログラミングで大切なことは極力少ないコードで的確な機能を実装することです。コードが少なければその分保守性が上がりシステムの品質が向上します。
専門的なプログラミングスキルについては言うまでもなく重要です。広く浅くではなく、特定の言語について深い技術を持っているPGの方が重宝される傾向にあります。
日本ではPGよりもSEの方が平均収入が高い傾向にあります。これはマネジメント要素を含む職種が高収入という風潮があるためでしょう。そのため、PGのキャリアパスとしてSEが位置付けられていることも多いでしょう。しかし海外ではプロフェッショナルなPGの方が重宝され、収入も高い傾向にあります。今後日本でもSEとPGの関係は変わってゆくかもしれません。
[RELATED_POSTS]システム開発におけるアプリケーション設計の重要性
システム開発プロジェクトの要件定義のあとのフェーズにあるのが設計です。このフェーズにて実施されるアプリケーションの基本設計と詳細設計は、プロジェクト全体から見てもかなり重要な位置にあります。
学校での図工の授業では様々なものを作ったと思いますが、作る事に集中してしまい、設計の重要性についてはあまり教えてもらったことはないかもしれません。しかし思い出してみると、どんな図工の授業でもまず最初に設計を行ったはずです。絵画なら下書きから始まりますし、何か立体的なものを作るときは必ず設計書を書きます。つまりものづくりの基本は設計にあるのです。
システム開発も同じです。PGはあらかじめ作成された設計に従ってプログラムを構築していくわけですから、設計が無ければチグハグなシステムが完成してしまいます。要件に沿った合理的な設計無しにクライアントが望むシステム開発は不可能でしょう。
もう一つ設計には後工程でのミスを事前に確認するという役割があります。設計書の内容を一つひとつ細かく確認していくと、その中にミスがあることも少なくありません。こうした早期段階でミスを発見できることはとても良いことです。実際にプログラムを構築してからミスが発生すると、設計段階での手直しよりはるかに大きい手戻りが発生するでしょう。
このようにシステム開発プロジェクトにおいてアプリケーション設計はとても重要な役割を持っています。成果物の品質は設計に依存すると言っても過言ではないのです。
アプリケーション設計の課題
多くのシステム会社ではアプリケーション設計において「属人化」という課題を持っています。属人化とは、設計書の内容について特定の人物しかその内容を理解できない状況です。ちなみにプログラミングにも属人化の課題はあります。
設計やプログラムは属人化してしまうと、担当者が変更になった際などに大きな問題が発生します。標準化されていないことで設計への理解が遅れ、その分生産性が低下したりミスを誘発してしまうのです。最悪のケースとしては、属人化によって誰もその設計を理解できなかったために、大規模な作り直しが発生したという事例もあります。
属人化という課題を排除するためには、標準化のためのツールが必要です。システムインテグレータが提供するSI Object Browser Designerは、アプリケーション設計において標準化を支援し、属人化による問題をなくして品質の向上や保守の効率化などを実現します。
システム開発においてその中心ともいえる設計の成果物管理を起点に、システム自体はもちろんプロジェクト全体の品質を向上したいというニーズにお応えします。SI Object Browser Designerの導入をぜひご検討ください。
