SEで8年間経験した事をパソコンインストラクタで生かせないか・・・
とずっと思っていて、ようやくその目標が達成できました＾＾
でもね、SEだから・・・という理由だと思うけど、1回だけ悲しい思いをした。
まず、面接で採用担当の方に私の経歴を話した。
採用担当の方から、
「・・・はぁ・・・色々経験なさってますが、
コミュニケーションは出来ますか？
インストラクタの仕事は、主に接客業です。
そのところ、大丈夫ですか？」
って、何か私が話すたびに何度も何度も質問してきた。
それってさ、私がSEで、「SEはコミュニケーション取れない人が多い」
って一部で言われているのを信じてるんだねって思った。
私の会話、そんなに分からない？って思った。
結果、不採用となった。
確かに、SEをして仕事してきたとき、話が通じない人、多かったよ。
でも全員じゃない。
私と議論出来ない人も居たけど何十分も議論して、
システムのバグが見つかったりしたとき、お互いに喜んだりした。
SEだってお客様と会話して、システム概要話して、
どういう仕様なら要件満たせるかを説明したりしている。
一部の業務では、接客業もあるんだよ。
ちょっと専門用語が出てきたので、
何となく、システムが出来るまでの流れを書いてみます。
①要件定義書
1) システムの事分からない人がシステム化してほしい事を考えて、
「こういうシステムを作ってほしい」っていって書く.。
2)それをSEがお客様にシステム化できるように、
誰がそのシステムを使うのか、システムの流れ、必要メモリ、
アクセス速度（リンクやボタンを押したときに
何秒後にページ遷移できるかを示した数値）、使用ブラウザ、
使用OS等をお客様とヒアリングして出来る定義書。
②基本設計書
要件定義書を基に、SEがシステム作成に関するルールを決めたり、
画面デザインや画面で処理できる事、データの取り扱い等を考える。
これは、お客様に見せて、要件定義書通りになっているか、
イメージ通りかをヒアリングして出来る設計書。
※これに記載する内容に不備があると、
システム障害が発生する確率は高くなります。
つーか、この内容がおかしいとシステムは正常に動かない。
③詳細設計書
基本設計書を基にプログラムが書きやすいように、
詳細化させた設計書。
これは、要件定義書、基本設計書を書いたSEとヒアリングし、
基本設計書通りになっているか、システムの処理が正しいか、
整合性はどうか等、本当に詳細な事を決める為の設計書。
※プログラマーは、この設計書を元に、
プログラミングを書いています。
・・・と言いたいとこですが、多くの現場では、
プログラムと詳細設計書はイコールではありません。
プログラマーは、
「実際に動作しているプログムが正、設計書は誤り」
と判断するものの、納期までの期間が足りない事を理由に、
設計書の修正はしません。
でも、私は、納期後の後処理で自分が担当した分だけですが
設計書の修正してましたよ～
④テスト仕様書
実際にプログラムが要件定義書、
基本設計書とあっているかどうかをテストするために
何を確認するためにどんなテストをして、
その結果どういう結果が出るかを記載した設計書。
・・・ここまででいっかな。
本当は、この先に、システムを公開するための手順書を作成したりするのですが・・・
とにかく、
この時点で、「ヒアリング」という言葉は3回出ています。
なので、コミュニケーション取れないとダメな事もあるんですぅ～(>_<)
なのに・・・なのに・・・
本当に悲しかった。
でもね、それから自分自身も考え、
一部の人でも、「SEに対してコミュニケーション取れない」っていう認識をしているなら、
コミュニケーション取れるんだぜっていう部分をアピールしなきゃって思い、
頑張った結果、3社目で採用もらえました～＾＾
しかも、そこは、私が社員採用で不採用となったけど、どうしても諦めきれなくて、
リベンジでパート採用枠から「書類だけで判断しないで、私と面接して、私の人間性を見て」
ってお願いしたところ。
本当に嬉しくて・・・
色々大変だったし、「SEだったから無理かも」って思ったけど、
諦めなくてよかった。
でも、これからが大変なので、初心に帰って頑張らないとo(^ ^)o
とずっと思っていて、ようやくその目標が達成できました＾＾
でもね、SEだから・・・という理由だと思うけど、1回だけ悲しい思いをした。
まず、面接で採用担当の方に私の経歴を話した。
採用担当の方から、
「・・・はぁ・・・色々経験なさってますが、
コミュニケーションは出来ますか？
インストラクタの仕事は、主に接客業です。
そのところ、大丈夫ですか？」
って、何か私が話すたびに何度も何度も質問してきた。
それってさ、私がSEで、「SEはコミュニケーション取れない人が多い」
って一部で言われているのを信じてるんだねって思った。
私の会話、そんなに分からない？って思った。
結果、不採用となった。
確かに、SEをして仕事してきたとき、話が通じない人、多かったよ。
でも全員じゃない。
私と議論出来ない人も居たけど何十分も議論して、
システムのバグが見つかったりしたとき、お互いに喜んだりした。
SEだってお客様と会話して、システム概要話して、
どういう仕様なら要件満たせるかを説明したりしている。
一部の業務では、接客業もあるんだよ。
ちょっと専門用語が出てきたので、
何となく、システムが出来るまでの流れを書いてみます。
①要件定義書
1) システムの事分からない人がシステム化してほしい事を考えて、
「こういうシステムを作ってほしい」っていって書く.。
2)それをSEがお客様にシステム化できるように、
誰がそのシステムを使うのか、システムの流れ、必要メモリ、
アクセス速度（リンクやボタンを押したときに
何秒後にページ遷移できるかを示した数値）、使用ブラウザ、
使用OS等をお客様とヒアリングして出来る定義書。
②基本設計書
要件定義書を基に、SEがシステム作成に関するルールを決めたり、
画面デザインや画面で処理できる事、データの取り扱い等を考える。
これは、お客様に見せて、要件定義書通りになっているか、
イメージ通りかをヒアリングして出来る設計書。
※これに記載する内容に不備があると、
システム障害が発生する確率は高くなります。
つーか、この内容がおかしいとシステムは正常に動かない。
③詳細設計書
基本設計書を基にプログラムが書きやすいように、
詳細化させた設計書。
これは、要件定義書、基本設計書を書いたSEとヒアリングし、
基本設計書通りになっているか、システムの処理が正しいか、
整合性はどうか等、本当に詳細な事を決める為の設計書。
※プログラマーは、この設計書を元に、
プログラミングを書いています。
・・・と言いたいとこですが、多くの現場では、
プログラムと詳細設計書はイコールではありません。
プログラマーは、
「実際に動作しているプログムが正、設計書は誤り」
と判断するものの、納期までの期間が足りない事を理由に、
設計書の修正はしません。
でも、私は、納期後の後処理で自分が担当した分だけですが
設計書の修正してましたよ～
④テスト仕様書
実際にプログラムが要件定義書、
基本設計書とあっているかどうかをテストするために
何を確認するためにどんなテストをして、
その結果どういう結果が出るかを記載した設計書。
・・・ここまででいっかな。
本当は、この先に、システムを公開するための手順書を作成したりするのですが・・・
とにかく、
この時点で、「ヒアリング」という言葉は3回出ています。
なので、コミュニケーション取れないとダメな事もあるんですぅ～(>_<)
なのに・・・なのに・・・
本当に悲しかった。
でもね、それから自分自身も考え、
一部の人でも、「SEに対してコミュニケーション取れない」っていう認識をしているなら、
コミュニケーション取れるんだぜっていう部分をアピールしなきゃって思い、
頑張った結果、3社目で採用もらえました～＾＾
しかも、そこは、私が社員採用で不採用となったけど、どうしても諦めきれなくて、
リベンジでパート採用枠から「書類だけで判断しないで、私と面接して、私の人間性を見て」
ってお願いしたところ。
本当に嬉しくて・・・
色々大変だったし、「SEだったから無理かも」って思ったけど、
諦めなくてよかった。
でも、これからが大変なので、初心に帰って頑張らないとo(^ ^)o