◆SEとは
システムエンジニアの略。
プログラミングするのではなく、システムの設計をする人。
設計と言っても範囲は広いので一概には言えませんが、
・データをどんな形でどうやって渡すか?
・データをいつどこでどんな風に加工するか?
・ユーザーが使う画面をどんな風にするか?
みたいな事を設計します。
◆PGとは
プログラマの略。
SEが作った設計書を元にしてプログラミングしていきます。
要は動くものを作ります。
ちなみに、現場ではプログラミングの事を「実装」とか「make(メイク)」とか「coding(コーディング)」とかって言う事が多いです。
※たまに「製造」と言う人もいますが。
SEとPGの違いは?という質問には、
「システム開発を家の建築に例えると、SEは設計図を書く人、PGは大工さん」
という回答が一般的かと思います。
これは間違いないんですけど、では、現場でSEとPGが明確に分かれているのかと言われると、(私が経験してきた現場では)NOです。
SEとPGを明確に分けている現場は無かったです。
任された範囲の「設計&実装&テスト」は一人で一貫してやることが多かったです。何なら「客先折衝&要件定義&技術調査&見積もり作成」なんかも加わってきます。
一人に任す方式はメリットもデメリットもあるので良いのか悪いのかは分かりませんが、現実的にはこういう方式が多いようです。
※テストは自分が実装したものではなく他のPGが実装したものをテストするパターンもあります。
なので、SEでもPGでも現実的には違いなんて無いと思います。
※当然の事ながら、会社によって違いますよ。
◆設計についての一例
まぁ、プログラミングできない人がSEをやっても現実的な設計を作れないし、設計できない人がPGをやってもまともな実装なんてできませんしね。
結局のところ、プログラミングと言うのは「設計力」と「プログラミング技術」が合わさって初めて良いものが作れます。
まぁ、そもそも設計やらずにプログラミングをすると行き当たりばったりなプログラミングになってしまいます。地図を見ずに知らない街を歩くようなものです。
趣味で作るのであれば設計力なんて要らないでしょうけど、簡単でいいので設計書を作るようにしておくといいですよ。
仕事ではやっぱり設計をしっかりやっておかないとプログラミングをやっちゃダメです。
・・・とか言いながら、時間がなくて実装先行して設計書作成を後回しにすることはよくありますけど(笑)
じゃ、どんな設計書を作るべきなのか?
まぁ↓これぐらい作っておけばいいんじゃないかと思います。(必要な物を取捨選択すればOK)
・状態遷移図
・シーケンス図
・データフローダイアグラム
・インターフェース仕様書
・フローチャート(難しい/ややこしい部分のみ)
・バッファの使われ方(特にリングバッファの時)
・処理全体を俯瞰できるようなドキュメント
設計の方法や種類なんて実際には会社によって違いますし人によっても違います。
なので「設計とはこれだ!」と言い切れませんが、上記のものは覚えておくと役立つんじゃないかなと思います。
※細かい事は調べてね。
あと、フローチャートですが、私が専門学校の授業で習ったときはやたらと重要視されていましたけど、現場でフローチャートなんて殆ど書かないですよ。
※会社によって違いますけどね。
フローチャートで表せるなら実装した方がいいじゃんって話しですよ。
理解しやすい実装して、適切なコメントをちゃんと入れればそれがフローチャートとして使えるはずです。
って言うか、読んで分からないソースコードはアウト!
それに、全実装のフローチャート書いてたら時間が掛かりすぎていつまで経っても終わりません。
オブジェクト指向のフローチャートなんて書くの大変っす。
なので、難しい/ややこしい部分のみ書けば良いでしょう。
あと、やたらとフローチャートの形に拘る必要はありません。長方形と分岐の菱型の2種類ぐらい使えばいいと思いますよ。あとはせいぜいループ記号ぐらいかな。
ってな感じで、これまで幾つものシステム開発の現場を経験してきました。
会社によって設計手法は違いますので一概には言えませんが、上記に挙げた設計書を実際に作る作らないは別として、考え方としては持っておくと良いと思います。
Boot Tech Programming School ではある程度プログラミングができるようになってからご希望があれば上記の設計書についてのレクチャーもするようにしています。
興味のある方はぜひお問い合わせください。
コメントを残す