「SEの基本」の感想

本書はSEを目指している方、SEになったけど今一度復習したい方向けの内容です。

SEの基本

第0章 SEって、いったい何をする人？

SEとは?

SEとはシステムエンジニアリングの略です。具体的にはウォーターフォール開発に準じた場合、どんなシステムを開発するかを検討する「システム化企画フェイズ」(要件定義とも言う)からサービス後の安定稼動を実現する「運用保守フェーズ」までを一気通貫で担当する職種です。

SEとプログラマーの違い

SEとプログラマの違いはウォーターフォール開発での各フェーズに照らし合わせると分かりやすいと思います。 　　　　　　　　　　　　　　　　　　　　　　　　　　　

SEは上流から要件定義→外部設計→内部設計と進んで内部設計でのアウトプットであるプログラム設計書を作成します。

プログラマーはプログラム設計書をもとにコーディングを行い、プログラムを作成します。今度はSEが再びプログラムをインプットとし単体テスト行います。その後、サービスリリース後の保守運用までSEが担当します。

※厳密にはSEと一口に言ってもプロジェクト管理に特化したSEもいればテクニカル面に特化したSEもいます。SEとプログラマーの役割の範囲もプロジェクトによって異なる場合があります。

 第1章 SEには、どんなテクニカルスキルが必要か

業務分析（ビジネス課題の明確化）の重要性 

システムは無事開発しても、思ったような効果を得られない、抱えていた問題を解決できないことがあります。これは対象業務の現状分析が不十分だった場合に起こりえる問題です。このような問題が生じないためには業務分析、つまりビジネス課題の明確化が重要です。業務分析では現場業務の問題点を洗い出しどのようなシステムを導入すれば問題を解決するかを検討します。

業務分析に役立つコンサルティングツール

正しく業務分析を行うにはコンサルティングツールの使用が推奨されます。本書ではトップダウンアプローチの際に用いられるツールを紹介しています。ここでは各階層とツールの位置関係を大まかにまとめます。

実際には目的に応じてコンサルティングツールの組み合わせ、業務分析を行います。

トップダウンモデルでの各ツール一覧

第2章 ソフトウェアエンジニアリングを意識したスキルを形成する

開発プロセスモデルとは

どのようなシステムを開発するにしろ、いくつかのプロセスを経て構築されます。その一連のプロセスを「開発プロセスモデル」と言います。主に、分析工程、設計工程、プログラミング工程、テスト工程、運用・保守工程に別れています。実際のプロジェクトではどのような開発プロセスモデルを検討し、適用します。以下では代表的な開発プロセスモデルを紹介します。

①ウォーターフォールモデル

ウォーターフォールモデル（以下WFモデル）とは、1970年代初頭の職人芸的なソフトウェア開発を作成方法から工業製品としての作成方法に変える方法として提唱された開発プロセスモデルであり、現在最も主流となっています。開発プロセスをいくつかの段階に分割し滝のように上流から下流へと設計を行い、各フェーズでの設計に対応したテストを行った後、サービスリリースします。（第0章の図を参照）

②スパイラルモデル

スパイラルモデルはWFモデルの後発で、WFモデルのような工程を順番に進める、ということができない問題に対する解消アプローチとして提唱されています。スパイラルモデルはシステムを独立性の高い部分に分割し、以下の4工程を何度も繰り返し行う開発手法です。各工程はPDCAサイクルの各工程に対応します。

⒈ 目的、代替案、制約の決定 (Plan)

⒉ 代替案の評価・リスク選別と解決 (Do)

⒊ 次レベル製品の開発・検証 (Check)

⒋ 次工程の計画 (act)

スパイラルモデル概要図

上記のように何度も①～④の工程を回すスパイラルモデルはWFモデルの弱点だったオープン化に伴う手戻りリスクなどに効果的です。

③反復型モデル

反復型モデルはシステムを顧客から見た機能で分割し、機能ごとに要件定義、分析、設計、実装、テストを繰り返す手法です。

④各開発手法の特徴

WFモデル、スパイラルモデル、反復型モデルそれぞれの特徴をまとめました。 

各開発手法の比較

 第3章 プロジェクトに必要なリーダーシップとチームワーク

システム開発力=技術力+人間力

システム開発においては技術力が不可欠ですが、プロジェクトとして見た場合仕事での普遍的なスキルである人間力も必要です。メンバーが問題に直面した際に、速やかにリーダーにエスカレーションを行う、リーダーはメンバーが報告しやすい雰囲気を心がけることが大切です。

リーダーがメンバーのためにすべきこと

各メンバーのまとめ役としてリーダーは以下のことを実行することがプロジェクト推進の鍵となります。

① メンバーの情報収集を怠らない

メンバーが突然倒れてしまうなど突然のトラブルが発生しないよう、常に状況を把握しておきます。

② メンバーのモチベーションをキープする

メンバーは仕事に対するモチベーションを向上させることで、作業品質も向上します。例えばシステムが開発が社会の基幹に関わっていることを知っているかどうかで精神的なコンディションも変わってくるでしょう。リーダーは各メンバーにこのような「価値の合意形成」を実施することが重要です。 

③リーダーとしての立ち位置を意識する

リーダーはチームを統率し、プロジェクトの推進のために各種責任と権限を持ちプロジェクトを運用します。メンバーはそれぞれの役割を持ち統率される立場にあります。このような上下関係が明確な状況では、円滑なコミュニケーションや情報がスムーズに流れることは難しいです。そのためにリーダーはメンバーと「想いを共有すること」が重要です。責任と権限で違いはありつつも、組織的にフラットな関係の立ち位置を保つことで、コミュニケーションが活性化され、プロジェクトが円滑に進みます。

第4章 プロジェクトを成功に導くマネジメントスキル 

PMBOK（Project Management Body of Knowledge）とは

PMBOKとは、PMI（米国プロジェクトマネジメント協会）が定めたプロジェクトマネジメントに関わる知識体系のことです。プロジェクトマネジメントの目的は「システム開発における様々なリスクを考慮し、ソフトウェアを質的に向上させる」ことです。PMBOKという体系だった知識を活用することにより、プロジェクトマネジャーは個人の経験だけに頼ってしまい、生じてしまう考慮の抜け漏れを防ぐことができます。

WBS作成 → スケジュール決定 → 進捗管理

プロジェクトをより管理しやすくするためにタスク単位にプロジェクトを分割したものをWBS（Work Breakdown Structure）と言います。WBSを作成することにより、すべき作業の抜け漏れや作業範囲の認識齟齬を防ぐことができます。またWBSにより分割された各タスクの工数、前後関係を見積りガントチャートによりスケジュールを決定することができます。更に各タスクの担当者を決めることで進捗管理をすることができます。プロジェクトのどの部分が遅れているか、それがどう皇族に影響を及ぼすかをすぐに追うことができればそれはプロジェクトとして管理されていると言えるでしょう。

第5章 これだけはマスターしたいヒューマン系スキル

コミュニケーションスキルの重要性

SEという仕事において技術をより知っているかが多く見られがちですが、コミュニケーションスキルはプロジェクトを推進する上で非常に重要なスキルです。しかし、コミュニケーションスキルの向上は劣後されることが多く、実際の業務で培っていくためにはある程度の業務経験が必要です。プロジェクトにおいて問題が発生した場合、担当者が最初に発見することは多々あります。そこからプロジェクトマネジャーにエスカレーションするまでの時間でプロジェクトへの影響度が変わることもあります。その時、プロジェクトマネジャーにエスカレーションがしやすいかどうかで問題の大きさが変わっていきます。どうしても数字に見えづらい部分が大きいですがコミュニケーションスキルは不可欠なスキルです。

目的を明確に

第4章でWBSで分割された各タスクは担当者に振られます。担当者にはそのタスクの行為だけでなく目的も明確に伝えなければいけません。これは担当者の成長という観点で見た場合、目的と行為が対になって初めてその行為の意味が理解できるからです。逆に行為のみ伝えた場合は担当者はその指示の重要性を理解できないことに加え、経験を得ることができないため、何度も誤った行動を繰り返すことになります。

第6章 SEとしての自覚と心構え

SEであるというプロ意識を持つ

プロ意識を持つかどうかでSEとして成長できる度合いが変わっていきます。SEの業務を通して要素技術を学びたいと思う方は沢山いると思います。しかし第0章で述べたように、SEとはシステム開発検討～サービス開始後の安定稼動の実現まで一気通貫でみる職種です。そのため、自分の興味がある分野の周辺知識も積極的に吸収することが必要です。そのためにプロ意識を持つことが不可欠でなのです。

 プロ意識を持つには

SEである以上、何らかのドメイン（公共分野、金融分野、法人分野など）に所属しているはずです。プロ意識を持つには自分が所属しているドメインに誇りと興味を持つことが重要です。興味を持てば、対象をより深く知ろうとします。誇りを持てば、プロ意識の醸成に繋がります。

本質を理解する

ITの技術は発展を繰り返していきます。そのため、自分が得た知識やノウハウが数年経つと時代遅れになってしまう可能性もあります。そうならないためには「本質」を抑えることが何よりも重要です。例えば、ソフトウェアの技術ではまずソフトウェア工学から学ぶのがおすすめです。ソフトウェア工学の目的は複雑したソフトウェアを質的に向上させることだからです。それを理解できればこれからの開発手法や技術が何の目的で定められているかを理解できるからです。

最後に

本書はSEの基本として専門的な話ではなく、その入り口を示してくれる本であり、ヒューマンスキルに焦点を当てた内容でした。ヒューマンスキルは仕事を進めて行く上で基本的なスキルですが若手社員でもベテラン社員でも不可欠なスキルです。SEというと「技術屋さん」というイメージが強いかもしれないですが、本書で紹介されているヒューマンスキルを疎かにしてしまえば大きなトラブルに発展する可能性もあります。そういった意味で今一度SEとして (社会人として)  再確認すべきことを教えて頂いた内容でした。