1.客との折衝
客からコンピュータに何をさせたいのかの要望を聞いて、出来る出来ないの判断、またもっといい方法もあるよ的なアドバイスを含めて、 必要な技術や、納期までの期間、費用などを見積もり客と交渉する。
ちなみにこの部分は営業部隊が行う事もある。この場合SEとしてこの部分のスキルや交渉術は不要。 営業部隊が不安な場合、例えば営業先で客から難しい事を突っ込まれそうな雰囲気の場合は、SEが営業に同行することもある。
この場合、基本的なトークは営業任せで、尋ねられたら答えれば良いだけだ。

2.仕様書の作成
客の要望に応じて仕様書を作る。仕様書とは、例えば「このボタンを押したら、これが表示される」 「このメニューをクリックすると、この画面が表示される」要するに設計書だ。
これはSE職の大事な作業になっていて、仕事を割り振る人達はこの仕様書に沿って作業が行われる。 だいたい全体像が踏襲されていればそれでＯＫな所もあれば、ハードディスクからデータを読み取る時のデータ型まで指定しろ、 と言う所もある。特に大規模でない場合は、仕様書なんかイラネー的な所もある。これも会社によってまちまちだ。

3.スケジュールを引く
誰がどの工程を担当するか、スケジュールを引くのもSEの仕事だ。以下は実際のものだが多少修正してある。


クリックすると大きく表示します
このスケジュールによると、HTMLがデザイナーから納品されてから作業開始となる。 製造タスクでは、各種機能の追加が「Masa」によって行われ、その期間は2月19日〜2月26日。 で、「サンクス画面」の製造は本来2月23日に終了していなければならないため、やや遅れ気味と言うことになる。 結合テストは「Masa」と「MasaB」の２人かがりで１日で行い、デザイナーの確認、営業部隊の確認を経て晴れて本番リリースとなる。
SEがプログラマーを兼務するケースもあるが、この場合は自分でスケジュールを立てて、その通りにこなして行くと言うスタイルになる。 自分でスケジュールを引くと、どうしても残業回避なコースになっちまうのは、まぁ、しゃーない。
スケジュールの引き方は、だいたいこんな感じ。

4.結合テスト仕様書を作る
プログラマーの人達が一通りプログラムの製造を終えて、動作確認をするためのテストを単体テストと言い、 すべての総仕上げのテストが結合テストとなる。
単体テストはプログラマーに任せることができるが、結合テストの仕様書はSEが起こす。
結合テスト仕様書は、「何をやったら、どうなる」の一連のテストケースをまとめたもので、 例えば、「左メニューのFLASH → Masaについてを選択 → DBからMasaについてのリンク一覧を降順で表示する」 と言ったようなもんだ。
これをエラー動作を含めてすべて記述して、ＯＫまたはＮＧでテスト結果を必ず残す。 結合テスト仕様書とテスト結果は本番リリース後も必ず残しておいて、客からのツッコミがあった場合に備えた方がいいだろう。

1.客の要望が二転三転
仕様書作る段階だと、まだ何とかなるが、スケジュールを組んだ後では大問題になる。
ちなみに客と交わす契約書には、だいたい納期が示されていて、納期が守れないと損害賠償が発生することもある。 なので、基本的には納期絶対なのだが、客の都合で機能を追加したり削ったりする場合、今のスケジュールで何とかなりそうなら組み込み、 そうでなければ別案件として新たに契約、のいずれかになる。
できればしっかり煮詰めた上でスケジュールを組みたいもんだ。

2.へっぽこSE
客とプログラマーをつなぐSEがへっぽこな場合、客の要望がプログラマーに伝わらず、結果として客の要望とは全然ちゃうものが出来たりする。
このケース、SEが複数いる場合は担当者を変えてケツを拭かせる事もあれば、責任を持たせて最後まで担当とすることもある。 基本的に重要なことは口頭だけで済まさず、メールを使用して指示した上で、口頭で補足することが大切。後で言った言わないの話になった時は、メールの送信履歴が証拠になる。 SEプログラマー間のトラブルで一番多いのがコレだ。お互いに随時確認し合う雰囲気を持ちたい。

3.へっぽこPG
プログラマーがへっぽこな場合もある。一番多いのが自分で「これなら、このくらいの期間でできます」とスケジュールを申告したのに、 蓋を開けると作業が追い付かないケースだ。
この場合は、プログラマーが複数いる場合はヘルプを付けてペースを上げるか、スケジュールを伸ばして組みなおすのいずれかの措置となる。 これをリスケと言う。ちなみに予定通りうまく行っている時はオンスケ。
別にスケてる訳ではない。
前述のへっぽこSEでもリスケが発生するケースが多々ある。工数を見積もる時は慎重に。

4.JavaScript多用
ページ制作や改修の場合、デザイナーが作った画像入りのHTMLページを受取り、これにリンクやらボタンやら押した時、 次のページへ遷移するための仕組みなどをプログラムを使って当て込むのだが、ページを受け取った時点でJavaScriptが埋め込まれていると非常にヘコむ。
JavaScriptはブラウザ依存であり、セキュリティーソフトによってはブロックが規定値となっていることがある。 また、ページデザインを崩さずに当て込まなければならないので、HTML文法やJavaScriptの仕様によっては、
「見た目リンクなのに、実はJavaScriptでPOST送信」
などと言う手法を使わなければならないケースがある。 実際にあった話だが、セキュリティーソフトによってJavaScriptがブロックされていた結果、「カード決済して金が落ちたのに、ダウンロード出来ねーぞコラ」的な問題が発生。
また、IEでは問題なく表示されるが、Mozilla系ではスクリプトエラー出まくりと言った問題もある。 どちらにしても、ブラウザによって動作が変わると予測されるものは極力使わず、デザイナーにもそう言った事象があることをわかってもらいたいもんだ。