その道20年のベテランが徹底解説！システムエンジニアの仕事内容
システムエンジニア(以下、SE)の仕事とは、一般にはシステムを作り、維持・運用することに関わる全ての作業を行うものです。
現在は、日常生活や様々な仕事を行う上で、多くのシステムを活用することが当たり前になりました。さらに、企業が有するシステムの優劣が、ビジネスの成功や企業の行く末すら決定的に左右するようになりました。
そのようなシステムには全て、何らかの形でSEが関わっています。ですから、SEは現代社会において必要不可欠な、大事な仕事なのです。
この記事では、SEの仕事について、どんなことを行うのか、求められるスキルが何か、SEとして必要な心構えなどをお伝えします。
関連記事
１．システムエンジニアの仕事
SEの仕事は、システムを作ること、維持することの大きく二つに分けられます。ここでは、それらの作業の流れを見ていきましょう。
１-１．システムを作る仕事
システムを作る仕事は、プロジェクトチームが作られた後、要件定義、設計、製造、テスト、移行・立ち上げの順番に進んでいきます。これらの作業は流れ作業で進んでいきますので、前の作業のアウトプットが次の作業のインプットになります。
この全てがSEの仕事の範囲です。でも、各作業では作業の内容や要求される知識・スキルが大きく異なりますので、複数のSEでそれぞれが得意とすることを担当する、作業分担を行うことが普通です。
１-１-１．要件定義：どんなシステムを作るのか決める
- インプット：提案依頼書など
- アウトプット：要件定義書
要件定義では、お客様のシステム導入意図である「目的」に応えるために、どんなシステムを作ればいいのかを、お客様を交えて検討します。
お客様とどんなシステムを作るのかを決めた結果は「要件定義書」にまとめます。要件定義書は、このシステムでは誰が・いつ・何を・どうできればいいのか、つまりシステムの「あるべき姿」を明確にするものです。要件定義書はお客様のご要望をシステムの言葉に翻訳したものでもあり、お客様の業務改善が目的ならば、新しい業務の大枠での流れも含むことが普通です。
システムの目的や存在意義は、必ずお客様の目的・意図に沿ったものでなければなりません。具体的には、業務上の課題解決やビジネス遂行の基盤として適切なものであることです。そのため、要件定義書も目的を達成するためには、という観点の記述が多くを占め、技術的な観点の割合が比較的低いことも普通です。
要件定義では、特定の業界や業務に特化したSEが必要とされることが多いです。お客様業務の深い理解や、お客様が属する業界の専門知識・状況・トレンド・課題を把握していたり、技術面では投入技術がどんな課題を解決するものなのかを説明できる知識が必要なためです。
１-１-２．設計：どうやってシステムを作るのか決める
- インプット：要件定義書
- アウトプット：基本設計書、詳細設計書、テスト仕様書
要件定義でどんなシステムを作ればいいのかが決まりました。次にどうやってシステムを作ればいいのかを決める作業が「設計」です。
どうやってシステムを作るか決めるには、システムを細かい機能や共通する事柄に分解する作業と、それぞれの機能の詳細を考える作業を行います。前者を「基本設計」や概要設計、後者を「詳細設計」と呼びます。
基本設計では、要件定義書でお客様と決めたシステムの「あるべき姿」が、どのような機能・画面・帳票・データベース等から作られるかを考え、「基本設計書」を作ります。例えば、「この大きな機能はこのサブ機能から成る、画面・帳票は全体でこれだけある、データベースに格納すべき情報はこれだけあり、それぞれはこれらの項目からなる」といったことです。
詳細設計では、基本設計で決めた各機能をもっと詳細に考えて「詳細設計書」を作ります。詳細設計書は、製造を行うプログラマやSEが、それを見てプログラムを作ることができるくらいの内容です。具体的には、画面のレイアウトやボタンごとの処理、帳票のレイアウトと出力内容、それらの情報をどのデータベースにいつ保存する・いつ取り出すか、などです。
設計では、要件定義書にある理想的なシステムから、現実的なシステムを作るにはどうすればいいのか、という翻訳が行われます。システムの「あるべき姿」をはき違えるとシステムがいびつになります。それに、設計してみて初めて分かることも多いのです。だから、設計を行うSEには、理想と現実との間でのバランス感覚が必要です。要件定義に立ち戻って、システムのあるべき姿を見直すことも必要です。
設計作業と同時に、インフラエンジニアと共に、システムがどのようなコンピュータ・ネットワークで構成されるべきかも考えます。具体的には、要件定義書に記載されている性能目標を達成したり、トラブルに耐えられる構成を考えます。その結果を基に、システムを動かすためのインフラを準備するのです。
関連記事
１-１-３．製造：システムの仕様を動く形にする
- インプット：基本設計書、詳細設計書
- アウトプット：プログラム
設計作業のアウトプットを使ってプログラムを作る作業が「製造」です。システムを作る仕事の中で最もイメージが湧きやすいでしょうし、花形の作業であると想像されているかもしれませんね。
SEやプログラマー(以下、PG)は、設計書に書かれている仕様をプログラミング言語を使ってプログラムへと翻訳します。このプログラムがコンピュータで動くモノそのものであり、今までの作業はこのプログラムを作るためにこそ存在しています。
関連記事 関連記事
プログラムの品質は、プログラミングを行う個人の能力に大きく左右されます。プログラムは書かれたとおりにしか動きませんので、プログラムがシステムの全てと言っても過言ではなく、大変重要な作業です。品質の良いプログラムを作るための方法論や技法は数多くありますが、絶対的なものはないのが現実です。
意外に思われるかもしれませんが、実際には製造を行っている期間は、システムを作る上では、他の作業と比べて最も短いのです。システムを作る作業の全体から見れば、どのようなシステムを作るのか、作るべきシステムがきちんと作れたのかを確認している時間の方が、ずっと長いのです。
★システムエンジニアはシステムのライフサイクルを意識して製造する
SEがプログラムを製造する時に意識するのは「システムのライフサイクル」です。具体的には、システムを作ったり、運用・保守を行った経験が豊富なSEであればあるほど、システムが作られた後の運用・保守のことを考えて設計をしますし、そのようにプログラムを作ります。
運用や保守のことを考えたプログラムとは、簡単に言えば「読みやすく」かつ「修正しやすい」プログラムです。一般的なプログラミングスキルを持った人なら容易にプログラムの意図が分かるし、無意味に高度なテクニックも使われていないのですぐに直せる、そんなプログラムです。
実は、業務で使うシステムでは、プログラミングに求められるスキルそのものは大したレベルではないことが多いのです。それでも「なぜこれほど問題だらけなプログラムが作れてしまうのか…」と、問題のあるプログラムを作った人のスキルや仕事への姿勢にあきれ果てることは珍しくはありません。
SEなら一度くらいは、そのような不用意に作られたプログラムのせいで、大変な思いをした経験があるものです。ですから、そのようなことが二度と繰り返されないよう、強く意識して製造するのです。しかし、現実としては必ずしも全てのSEが意識しているとは言えませんし、PGが意識していないと言うつもりもありません。あくまで傾向です。
１-１-4．テスト：システムが要件・設計どおりに動くか確認する
- インプット：プログラム、テスト仕様書
- アウトプット：テストエビデンス
製造で作成したプログラムが、設計どおりに動くか確認する作業が「テスト」です。プログラムを設計どおりに最初から問題なく作れる人は存在しませんし、動かしてみなければわからないこともあります。ここがシステムとしての品質を確保する最後の砦となります。
テストは「単体テスト」「結合テスト」「性能テスト」に大きく分けられます。これら以外にも、例えばお客様が行う受け入れテストと呼ばれるものもありますが、SEが直接行わないことが普通ですので、本記事では省略します。
どのテストでも、テスト仕様書に基づいてプログラムを動かした結果を記録し、想定結果と一致しているか確認します。結果が一致していなければ、製造の担当者に伝えてプログラムを修正してもらい、再度確認します。これを繰り返してプログラムが設計どおりに動くようにするのです。
テストは地味で大変手間がかかる作業なのですが、システムを作る仕事では絶対に欠かせません。システムを作る仕事は期間が決まっていますから、許された時間の中でできる限りプログラムの品質を高めなければならないのです。
①単体テスト
画面やバッチ処理などの機能単位でテストを行うことを「単体テスト」と呼びます。
単体テストのやり方は数多くあります。例えば、テストをする人(テスターと呼ぶこともあります)が画面を直接操作して、画面の入力状態に応じたチェックが行われるか、などです。プロジェクトによっては、テストの自動化が進んでいて、画面操作を行うプログラムが自動的にチェックをするところもあります。
どちらにしても、テスト仕様書に記載されている内容と、プログラムの実行結果が一致することを確認するという手順は変わりません。大事なのは、確認すべきことが全て行われたか、業務で想定されるパターンが全て網羅されたかなどのテストカバー率です。
関連記事
②結合テスト
システムはたくさんの機能が組み合わさったものですので、それらの機能を繋げて動かした場合にも設計どおりに動くかテストをしなければなりません。これが「結合テスト」です。
結合テストでは、画面遷移やバッチ処理結果を画面に表示するなど、システムで行う業務の観点からのテストを行います。システムの全画面や処理でありうる組み合わせを網羅するとものすごい数になりますので、テストをやり切れません。そのため、主要な機能間のテストになることが普通です。
画面単独の動きや入力チェックなどの確認は単体テストで行いますので、結合テストは単体テスト後に行われるのが普通です。
③性能テスト
システムの動作が、要件定義書で決められた性能の目標値を満たしているか確認します。これが「性能テスト」です。
具体的には、システムが想定する利用者数や処理負荷がかかった状態を作り出して、画面の表示時間や帳票の出力時間、バッチ処理にかかった時間などを測ります。画面表示時間や帳票の出力時間はユーザの使い勝手に直結しますし、バッチ処理の時間は朝の決まった時間からシステムが使えるか、などのシステムの運用スケジュールに大きく影響します。
性能テストの目標値を満たせていないなら、SEは色々な手を打ちます。例えば、データベースやネットワークのパラメータ調整(チューニングとも言います)を行ったり、プログラムが動くコンピュータ(サーバ)の処理能力を増強したり、場合によってはプログラムの作り直しや設計のやり直しになるかもしれません。
関連記事
１-１-５．移行・立ち上げ：システムを使うための準備をする
- インプット：要件定義書、基本設計書、詳細設計書
- アウトプット：運用手順書、障害対応手順書、立ち上げ手順書、移行手順書など
システムを使い始めるには様々な準備が必要で、その準備を行うのが「移行・立ち上げ」です。今までの作業はプログラム側の話が多かったのですが、この作業で行うのはシステムを運用していくために必要なものの作成です。
この作業ではドキュメントの作成が中心となります。例えば、システムを使っていくのに必要なマニュアル類や手順書、利用者向けの使い方マニュアルや教育用資料なども含まれます。
特に重要なのが、障害発生時の対応手順の作成と、その手順のリハーサルです。ここで言う障害は、ソフトウェア的なものとハードウェア的なものの両方を含み、仮復旧状態から本格復旧状態とする手順も範囲内です。この手順がしっかり決められていて、かつその手順で大丈夫だと確認できていないと、実際に障害が発生した時には関係者は慌てふためくだけで、傷がどんどん深く・広くなっていくだけなのです。
さらに、古いシステムからの移行作業の手順書作成と、移行のリハーサルが必要になることがあります。現在は0からシステムを作る案件は減少し、システムの老朽化によるリプレース案件が多いです。その場合は、以前のシステムで行っていた業務の引継ぎ作業を行います。この作業の担当者には、新旧両システムの深い知識・理解が必要です。
これらの準備が全て整った状態で、システムの稼働開始日を迎え、本番運用が始まります。移行や立ち上げは稼働開始日を目標に予定作業を消化しますが、遅れると稼働開始日がずれ込むなどの大きな影響が出ます。稼働開始直後はシステムの監視を強化するなどして、システムがきちんと動いているか注意深く見守ります。
１-２．システムを維持する仕事
システムはただそこにあるだけでは価値がなく、運用し続けることで初めて価値が発揮されます。システムをトラブルなく運用し、維持していくこともSEのとても大切な仕事です。
ここでは、システムを維持する仕事にはどのようなものがあるのかを見ていきましょう。
１-２-１．運用：システムの定例・臨時業務を行う
システムをずっと使い続けていくために必要な作業を行うことを「運用」と言います。
運用では運用作業を行うチームが編成され、以下のような作業を行います。
- ヘルプデスク・問い合わせ対応：システムの利用者からの窓口業務。問い合わせに答えたり、システムに関するアナウンスを行う
- 定例作業：システムの動作監視や定期的な処理の実行、定例レポート・報告書の作成などを、日次、週次、月次、年次などのタイミングで行う
- 臨時処置：定例作業以外でシステムの例外的な操作やデータベースのデータ修正などを行う
- 障害対応：プログラムの不具合や、サーバやネットワーク機器の故障などへ対応する
運用作業の中では障害対応が大きな意味を持ち、SEの手腕や実力が強く問われます。障害が起きるとシステムで行うべき業務が止まってしまい、システムが価値を発揮できないからです。
障害で業務が滞っている間は、お客様へ損害が発生しています。だから、障害へは迅速・適切に対応しなければなりません。システムの規模にもよりますが、障害の影響は金額換算で数百万円～数億円以上になることも珍しくありません。障害の内容によってはお客様からの叱責では終わらず、損害賠償請求にも発展し得ます。
その他の作業も、問題が起きるとシステムを使った業務が滞るので、運用では一瞬たりとも気を抜けません。例えば、臨時処置で作業ミスをするとシステムのデータを壊してしまいますし、定例作業の監視をミスすると障害の発生に気付けず影響が大きくなるかもしれません。
運用を行うSEに求められる知識・スキルは、システムで行う業務知識の比率の方が、システムの内部構造やプログラムの知識よりも高いものです。ですが、システムがどう動いているか、どう作られているか分かっていなければ、障害対応などが行えませんので、システムに関する幅広い知識が必要です。そのため、自らと運用チーム全体の練度を上げていく活動もSEの大事な仕事です。
１-２-２．保守：システムをずっとメンテナンスしていく
システムに機能追加や改修を行う作業を「保守」と言います。
作った時のままの姿がずっと続くシステムはありません。システムを使っていく中では、お客様からのご要望による機能強化や追加、セキュリティ問題の発生、環境の変化(例えば法制度の改正)による改修を行います。システムを使っている中で見つかった不具合も直していきます。
保守は、システムを作る時と同じように、改修内容への要件定義・設計・製造・テストをより小さな規模で行います。機能強化なら今あるドキュメントやソースコードを修正しますし、機能追加なら必要なアウトプットを新しく作ってシステムへ付け足します。不具合を直すなら、対象のプログラムを直してその部分を再度テストします。
保守で最も注意すべきなのは「今あるシステムを壊さない」ことです。システムを作っている時は不具合が出たなら直せばよいだけですが、保守ではお客様が業務でシステムをもう使っていますので、保守でシステムを壊すと障害となり、大きな損害が発生します。
そして、システムを作った人と保守をする人は違うのが普通です。保守は、他者が作ったプログラムやドキュメントを読み込んで、システムの仕組みや作られ方を理解するところから始まります。そのため、意図を察する・読み解く力が必要です。また、不具合を作り込まないために、改修の影響範囲を事前にきちんと調査できる能力も必要です
関連記事
２．システムエンジニアとプログラマーの仕事の違い
SEとPGには、法律などで明確に決められた定義はありません。ですから、この業界の内でも外でもSEとPGはよく混同されますし、実際に仕事をする上でも似たような役割があります。SEはPGが行う作業を普通に行いますし、逆もあります。
しかし、SEとPGとでは、プロジェクトで求められる役割が違うのは確かです。人により解釈は違いますが、ここではその違いの一つの考え方をお伝えします。
関連記事
２-１．システムを作る上での立場が違う
SEとPGの仕事の違いは、システムを作る上での「立場の違い」だと言えます。
SEはシステム全体を見通す立場であり、システム全体が要件定義書どおりに作られているかに責任を持ちます。一方、PGは作業者としての立場であり、設計書どおりにプログラムが作られ、テストされているかに責任を持ちます。
プロジェクトチームでは、プロジェクトを管理する役割のSEから、PGへ作業を指示されることが普通です。これは「SEの方が偉いから」ではなく、立場が違うからですので、勘違いしないで下さい。作るべきシステムをきちんと理解している人でないと、PGからのアウトプットの確認や評価をシステム全体視点で行えないからです。
この立場の違いは重要です。SEとPGは両方ともシステムに関わる仕事ですから、要件定義～設計～製造～テストの知識やスキルは両者とも少なからず持っています。例えば、PGと同じレベルかそれ以上のプログラミングスキルを持つSEは普通にいますし、要件定義や設計などの上流工程が分かるPGも普通にいることは意識しておきましょう。
２-２．身に着けているスキルの範囲と深さが違う
SEとPGはその立場の違いから、身に着けているスキルの範囲と深さが違う傾向があります。
SEはシステムに関わる何でも屋として、スキルを「広く・浅く」身に着ける傾向があります。そうでないと、システム全体視点での仕事ができないからです。PGはプログラミングやテストの専門家として、スキルを「狭く・深く」身に着ける傾向があります。そうでないと、日々変わっていく技術に専門家としてキャッチアップできないからです。
この「広く・浅く」と「狭く・深く」は、どちらが正しいわけではなく、両者の立場が違うだけです。それに、個人が目指すエンジニアとしての姿にもよりますので、SEだから、PGだからと決めつけることは適切ではありません。全てを知りたいという旺盛な知識欲を持っていたり、スキルを満遍なく向上させたいという意欲を持つSE・PGは多いのです。
それでも一般的な見方をすれば、SEに不足しているプログラミングやテストの専門性を補うのがPGである、と言ってもよいでしょう。複雑な設計をきれいにプログラミングしたり、要件に合わせた高度な、特殊な専門技術を用いることは、PGが得意とする領域なのです。
ただ、SEとして仕事をする上で必要な努力の量は、PGより少なくて済むわけではありません。この記事の最初の方でもお伝えしたとおり、システムを作る仕事は各作業ごとの専門性が高く、しかも学習にはそれなりのコスト・期間が必要なため、全ての作業を「広く・深く」身に着けているSEはごく少数であるというだけなのです。
３．システムエンジニアの心得
SEの仕事はシステムとの付き合いです。SEには技術的なスキルや知識は必須ですし、関連する様々な資格を取っていくことももちろん重要です。でも、SEとして仕事に取り組む時の姿勢やポリシーの方が、実はより重要なのです。
システムは、システムに関係する多くのヒトと、プログラムやコンピュータ、ドキュメントなどのモノ、この二つが組み合わさって出来ています。これについては、この記事で今までお伝えしてきた中でも、何となくお分かりいただけたかと思います。
そんなシステムとずっと付き合っていくSEの心得は、当然ながら①ヒトと上手に付き合うための心得と、②モノと上手に付き合うための心得、この二つに分けられます。この二つの心得はどちらも大事ですから、SEであればバランスよく身に着けるべきものです。
ここでは、SEの仕事を行う上で必要な、それらの心得をお伝えします。
３-１．チームの皆と上手に付き合う：ヒューマンスキル
SEだからこそ、ヒューマンスキルを積極的に身に付けましょう。SEになる理由が、人付き合いが苦手だから、プログラムやコンピュータと付き合っていさえすれば済みそうだから、というのは良い理由ではありませんし、SEになってからきっと後悔するでしょう。
ここで言うヒューマンスキルには、SE特有のものはありません。社会人として普通に求められる、報告の仕方、身だしなみ、TPOに応じた適切な言葉遣いや態度、人との接し方、指摘への素直さなどです。でも、これらがきちんとできているSEは意外と少ないのです。ヒューマンスキルは自ら意識しなければ身に着きませんし、身に着けようとも思わないものだからです。
一方、事実として、他者より優れた技術を持っているSEなら、ヒューマンスキルが大きく欠如していても仕事は与えられますし、頼られます。でも、リーダーには「チームの和を乱すから本当は居て欲しくないけれど、代わりが居ないからやむを得ない…」と思われていることが多いですし、実際に代わりが見つかればすぐに交代させられます。これではお互いに不幸になるだけです。
逆に、技術が他者より少々劣っているSEでも、ヒューマンスキルがきちんと身に着いていれば大丈夫です。プロジェクトで必要とされるSEに必ずなれますし、活躍できる場所や役割が必ずあるのです。それに、きちんと仕事が出来ていれば、技術も後からついてきます。
優れたSEは大抵はヒューマンスキルも優れています。そうでなければ、チームとしてスムーズに仕事が出来ませんし、チームとしてよいアウトプットが出せません。あと、ヒューマンスキルがあることは「この人にもっと大事な仕事を任せても大丈夫だろうか」とリーダーが考える上での大前提なのです。
関連記事
３-２．自分のことは自分で管理する：マネジメントスキル
マネジメントスキルと言っても、別に難しいことをするわけではありません。自身に与えられた作業を納期どおりに終わらせていくには、そのためのスキルをきちんと身に着ける必要があるということです。
作業指示や進捗管理はプロジェクトリーダーやプロジェクトマネージャが行うのが普通です。それでも、自分に割り当てられた仕事は自分自身でマネジメントできるべきです。
SEの仕事は流れ作業です。上流の作業のアウトプットを下流の作業につなげていきますので、一人一人が納期どおりに仕事を終わらせられるかが、システム全体の作業進捗に大きく影響します。
SEはスムーズに仕事をするための工夫を自らすべきです。自分の仕事の段取りを考え、アウトプットごとに自分で納期を決めて、不明点は事前に整理して関係者に聞いておくなどです。SEとしての仕事のやり方は、普通は誰も教えてくれませんので、周囲のできる人を見て学ぶか、自分で学ぶ必要があります。
仕事をうまくマネジメントできる人が良いアウトプットを出せます。また、いずれチームリーダーやプロジェクトリーダーとして活躍したいのなら、自分自身のマネジメントが出来るのは当然で、併せて他者のマネジメントもできるようになりましょう。
３-３．お客様やユーザに興味・関心を持つ：業務知識・業界知識
お客様やユーザに興味を持ちつつ、彼らがシステムをどう思っているか、どう感じているかを理解しようと努める姿勢は、立派なSEとなるための条件の一つです。
システムはお客様がこうありたいと願う姿を現実にしたものですから、必ずお客様の仕事や業務とつながっています。お客様の「思い」をSEが理解できなければ、どんなシステムを作ればいいのか、どういうサービスを提供すればいいのかSEが分からないですし、そんな状態ではお客様の満足度は低いままです。
だからSEには、お客様・ユーザと上手に付き合うための、業務知識・業界知識のスキルが強く求められます。ここで言う知識とは、建設業、製造業、金融業、官公庁などの、お客様が属している業界の知識であったり、お客様が行っている業務そのものの知識です。
お客様やユーザは、自身が属する業界の専門知識や経験を持っていますが、普通はプログラムやコンピュータのことはわかりません。ですから、システム側の専門用語で話しても、わからないと言われるだけです。そのような人たちと上手にコミュニケーションするためには、SE側から歩み寄りましょう。
SEがお客様からの信頼を得るためにも、まずは相手のことを理解するための努力をSE側で始めましょう。
関連記事
３-４．全てをドキュメントに残し、最新の状態を維持する：ドキュメント重視
SEの仕事をする上で最も重要なのが、「ドキュメントを常に最新の状態に保つ」ことです。何においても、まずドキュメントを作り、維持していきましょう。
ドキュメントがきちんと作られ、維持されてさえいれば、開発・運用・保守のどの作業においても、これほど頼りになるものはありません。ドキュメントは何かが起こった時の拠り所であり、システムがある限りずっと維持されていかなければならない、大事な資産です。
ドキュメントはいつも軽視されがちです。極論として、ソースコードがシステムのありのままの姿なのだからドキュメントは書く必要がない…と言う人もまれにいます。でも、実務を知るSEならば、正しい意見ではないと考える人の方が多いでしょう。
なぜかと言うと、システムはどう動くことが正しいのか、そもそも何が目的のシステムなのかは、ソースコードからは読み取れないからです。ソースコードはただの結果でしかなく、その原因となった、システムを作ろうと思ったお客様の思いや意図こそが最も尊重すべきものであるからです。だから、システムが目指す姿・あるべき姿が書かれているドキュメントが非常に重要なのです。
優れたSEはドキュメンテーション能力も優れています。必要なことを最小限の言葉や図で明確に伝えられます。SEが作るドキュメントは、誰にでも分かりやすく維持しやすい内容で作ることが一番最初のスタート地点です。ドキュメンテーション能力は、自分で意識的に鍛えていく必要があるスキルなのです。
３-５．システム全体への興味・関心を持つ：全体視点
自分の担当している部分だけでなく「システム全体に興味・関心」を持ちましょう。また、自分の行っている作業がシステム全体からすると何のために行われているもので、最終的にどのようなことに繋がるのかも意識しましょう。
ここまで何回もお伝えしたとおり、システムを作り、維持するSEの仕事は全て流れ作業です。全ての作業に意味があり、意味のない作業はありません。これを意識しているか、いないかではアウトプットに大きな差が発生するものです。
例えば、設計をするSEは製造者の視点を持つべきです。なぜならソースコードとして作れなかったり、必要な性能を出せない設計をしても意味がないからです。製造をするSEは要件定義者の視点を持つべきです。なぜなら設計者の意図を汲みとり正しく動くプログラムを作るためには、そもそもシステムが何を目指しているものか知らなければならないからです。
このように、全てのSEが自分の担当範囲を超えて、大きなシステムの一部として自分の仕事を捉えられるなら、システム全体の作業がうまく回っていきます。
３-６．アウトプットに強いこだわりを持つ：成果物主義
SEの仕事は、一つ一つのアウトプットの積み重ねだからこそ「アウトプットへの強いこだわり」が必要です。
一つ一つのアウトプットの品質が落ちれば、後続の作業の品質が全て落ちるのです。システムを作る仕事の成否は要件定義で決まる、という言葉はこれを意味しています。だからこそ、上流工程(要件定義、設計)を任されるSEは優れたスキルを持つ人、経験が豊富な人が選ばれるのです。
だからと言って、下流工程(製造、テスト)のアウトプットの品質に手を抜いてはいけません。プログラムはシステムそのものであり、いくら要件定義や設計がしっかりしていても、システムを実際にそのとおりに作れていなければ意味がないからです。
ですから、プロジェクトに関係するSEの「全員」が、きちんとしたアウトプットを作るという強いこだわり・意思を持っていて初めて、きちんとしたシステムを作ることができるのです。そのようなシステムだけが、お客様からの高い満足度を得られるのです。
３-６-１．チームでアウトプットを確認し合う：レビューの徹底
アウトプットの品質確保は、SE自身のスキルを高めることと共に、アウトプットへの「レビュー」を徹底することが基本です。アウトプットを個人のスキルにだけ依存していては、プロジェクト全体のアウトプットの品質に偏りが出るからです。
レビューでは、指摘の理由を必ず尋ねましょう。納得できる理由でなければ徹底的に議論しましょう。議論した結果はチーム内で共有しましょう。レビューのチェックリストがあるなら活用しましょう。
そして何より、形だけのレビューでは全く意味がありません。実のあるレビューになるよう、レビュアー・レビューイの双方が積極的に参加しましょう。
レビューにより他者の視点を得て、アウトプットの品質を向上させていく取り組みは、必ず自分のためになります。場合によってはレビュアーとなることで、新たな気付きを得ることもあるでしょう。自分だけでは気付かないことを指摘してくれる場は、とても大切で貴重なものなのです。
３-７．ノウハウは全て蓄積して皆で共有する：チームとしてのアウトプット
SEとして仕事をしていく中で得られるノウハウは常に増えていき、減ることはありません。「ノウハウを蓄積し皆で共有する」ことで、チームとしてのアウトプットをきちんと出しつつ、品質を向上させていく意識がとても大事です。
システムに参加しているSE達は、多かれ少なかれ課題・問題意識を持っています。作業がしづらい、作業の仕方が非効率的だ、アウトプットをうまく作れないなど、何も問題はないと思って仕事をしているSEは存在しません。もし何も問題はないというSEがいるなら、格好をつけているだけなのかもしれませんし、もしかすると仕事への意識が少し低いのかもしれません。
個々のSEが持っているノウハウは、そんな課題を解決できる可能性があるのです。そして、SEは仕事柄プログラムに触れる機会があったり、プログラムを作れる人が多いので、色々な効率化のノウハウや具体策を、他の業界の人よりも有利な形で、潜在的に持っているとも言えるのです。
自分の殻を破り、「チームのために貢献する」という意思をほんの少しでもいいので持ち、それをチームの皆へ伝えましょう。そういうSEがチームに一人でもいれば、必ず皆にその姿勢や思いは伝わり、チームが良い方向へ向かい、結果としてチームとしてのアウトプットの品質が向上するのです。
現状を諦めるのではなく、いつも前向きに進む姿勢がSEには必要なのです。
4.さいごに
以上、SEの仕事をお伝えしてきました。もしかすると、この記事を読んだあとの方がかえって混乱されているかもしれません。ゆっくり理解をしてください。
それでも皆さんにご理解いただきたいのは、SEは難しい仕事ではありますが、その分やりがいがある仕事だということです。
システムへ、SEの経験・知見・スキルが及ぶ限りの様々な工夫を凝らし、お客様のご要望・ご期待を超える品質のシステムを提供し、高い満足度を得ていただく。システムの作り方に、固定された、決まりきった手順がないことは、良いシステムを実現するための工夫の余地が大きいということです。
SEには、なろうと志せば誰でもなれるのです。SEになるために必要な資格はありません。コンピュータとネットワークの基礎とプログラミング言語の知識、システムで実現させることへの興味、そして何より、素晴らしいシステムをお客様に提供するのだという強い意志があれば、立派なSEへの一歩を踏み出せるのです。
この記事をお読みいただいたことで、SEとしての仲間が増えることを期待しています。
コメント