【就活&転職者必見】社内SEってどんな仕事？[#4]～現役社内SEだから語れるリアルな話～
多くの記事の中から選んで頂き、ありがとうございます。
初回[#1]の記事では、社内SEとは、
所属する会社で使われている『IT全般』の『面倒』をみる仕事
とお話しました。そして「IT全般」って具体的に何？について、少し掘り下げて書かせて頂きました。
そして、前回の記事では、それら「IT全般」の「面倒」を見る・・・この「面倒」を見るってどういう事？について、
1.戦略検討 ⇒ 2.企画 ⇒ 3.計画 ⇒ 4.予算管理 ⇒ 5.要件検討 ⇒ 6.設計 ⇒ 7.製造・構築 ⇒ 8.テスト・試験 ⇒ 9.運用保守
に分解し「1.戦略検討」「2.企画」についてお話ししました。
さて、今日は「社内SEって何？」第四弾として・・・「5.要件検討」から続きのお話しをさせて頂きます。
「面倒」をみるってザックリどういう事？
この記事では、「面倒」を見るを、システムではなく「花壇」と置き換えてご説明を始めました。
なんのこっちゃ？
の方は、先ずはサクッと前回[#2]記事の『「面倒」をみるってザックリどういう事』をご一読下さいませ。
５．要件検討
花壇の例では、「どんな花壇だと喜ばれるか？憩いの場になるか？整理してみよう！」と書きました。
この「要件検討」は、少し技術者っぽく書くと「要件定義」と言われる事が多い作業です。（「定義」と言われると突然、小難しく聞こえてきましたね・・・）
「要件定義」を少し表現を変えると「必要な条件を決める事」と言えると思います。突然ですが、ここで１つ、実験してみましょう！次の文章からイメージできる情景を想像してみてください。
【文章①】雪の積もった冬山に数人の登山者が山頂を目指して登っている。雲が眼下に広がり、雄大な山々の景色が広がっている。
さぁ、どういったイメージが描けたでしょうか？続いて、こちらの文章ではどうでしょうか？
【文章②】冬のエベレストを想起させる切り立った山峰を４人のプロの登山者が大きなリュックを背負い登っている。青空に浮かぶ山頂までは、まだ暫く時間を要する模様だ。
さぁ、どうだったでしょうか？
これが、どう要件定義につながるのか疑問をお持ちの方もいらっしゃるかと思いますので、種明かしをしていきましょう。
「システム」とは、目に見えない仕組みです。
「システム」を作るには、大勢の人が関わります。
そんな、目に見えない仕組みを、大勢の人が関わって作る時に大切になるのが、、、
「作るシステムのイメージが、みんな合っているのか？」と言う事です。
「要件定義」とは「必要な条件を決める事」と言いましたが、つまり、システム作りに関わる人が、同じイメージ（ゴール）を見つめて作業を進める為にする作業が「要件検討」であり「要件定義」になるわけです。
先ほどの、冬山の情景イメージの実験を思い出してください。実際は、次の絵を表現する文章を２つ示しましたが、どちらのイメージが以下の絵に近かったでしょうか？
恐らく、【文章②】の方が、上記のイメージに近い想像ができたのではないでしょうか？
要件定義の重要性は、これに尽きます。
如何に、目に見えない「システム」と言うゴール（成果物）を、共に作る関係者と同じイメージを持てるように、表現出来るか？
その為の「条件」を丁寧に書き出していく作業が「要件定義」と思っていただければ良いです。ただ、ここで「イメージ」と表現している点がポイントで、「要件定義」は、次にお話しする「設計」とは異なります。
何故なら「要件定義」とは、共に作る関係者と同じイメージを持てるようにする事が大切ですから、あまりITやシステムに詳しくない人にとっても、同じイメージを持てる条件の列挙である必要があるのです。
確かに、ITやシステムの専門家が、技術的な専門用語を沢山使って書けば、ブレの少ない、より具体的なシステムのゴール（成果物）が表現できるでしょう。
でも、それではITやシステムに精通していない人とは同じイメージが共有できず、結果、出来上がった後で「言っていたのと違う」と言う結末になってしまう訳です。これでは「要件定義」の目的を果たせないので駄目なのですね。
「要件定義」とは、あまりITやシステムに精通していない人でも理解ができ、専門家と同じイメージを持てるイイ感じの表現でなければなりません。だからと言って「小学生にわかる表現」まで崩すと、結局条件が伝えきれずに「要件定義」の目的を果たせないので、一定レベルの職業人が理解できる表現と言う事になります。
ちなみに、技術的な専門用語を沢山使って、SE（システムエンジニア）やプログラマが間違えなく作業を進められるようにする為のドキュメントは、次に説明する「６．設計」の作業になります。
６．設計
さて、次は「設計」です。
「５．要件定義」をお読み頂けたので「６．設計」のイメージもつかめておられるのではないでしょうか？
「花壇」の例では「花壇の大きさやデザイン、植える植物、必要な土など全て細かく具体化しないと。。。折角だし、自動で水や肥料を撒く機械も導入しちゃおう！」と書きましたが、要は、専門家として間違いなく「システム」を完成させる為の具体的な条件やロジックを整理したものですね。
設計にも、基本設計（概要設計と言ったりもする）、詳細設計と２段階の細かさ加減があります。
「基本設計」を「花壇」を例に書いてみると・・・
空き地に新設する花壇は６つで、それぞれ３平方メートル。各花壇には、パンジー、ビオラ、デルフィニウム、ベゴニア、コリウス、ヒューケラを植える。各花壇は、エコレンガをフランス積みで地表20センチの高さに積み上げた花壇とする。
みたいなイメージですね。所々、素人ではパッと理解が出来ない言葉が出てきますね。でも、要件定義ではないので、これで良いのです。専門家が実際に作業する際に、キチンと具体的に伝わる表現で書くのが「設計」なのです。
次に、「詳細設計」を「花壇」を例に書いてみると・・・
各花壇に植える植物は、
・パンジー：株間20cm、合計XX株、赤玉土5、川砂1、ピートモス4の配合土とする
・ビオラ：株間15cm、合計XX株、ハイポネックス培養土とする
・・・・
こんなイメージで、実際の「手配」につなげられる細かさに表現されていると思いますが、システムでも同じ事が言えます。
言葉だけでは表現しきれないものを表現する為に、フローチャートなど、システムのロジックを表現する記述様式がありますが、そういった表現方法も駆使して記述するのが「設計」の作業となります。
次の工程の「７．製造・構築」と「設計」の作業者が、同一の場合は「設計書」が多少、言葉足らずであっても行間を補いながら、製造・構築できるのでしょうが、実際は「設計」と「製造・構築」の作業者が異なるケースがほとんどだと思います。
何故なら、他社のビジネスパートナーに業務委託して作ってもらう事が多いからですね。場合によっては、外国の専門会社に業務委託するような事もありますが、その場合は一層、文化の違いなども意識して丁寧すぎるくらいの「設計書」を作る事が求められます。
「製造・構築」する業者は、「設計書」に従って作る事になりますので、「設計書」に書かれていない事は、作りませんし作れません。結果、製品品質の悪いシステムが納品され、後々、揉め事に発展する事もありますので、とてもシビアな工程でもあります。
ですので、設計書を書き終えたら、別の技術者にも見てもらい、表現や考え方の間違いがないか「レビュー」と言う形で点検してもらう工程を挟んで間違いの無い設計書に仕上げていきます。
また、実際にシステムを作り終えた後、少し手直ししたり、レベルアップさせたい要件が出てくるものです。その際には、この「設計書」を頼りに、どこのロジックをどう変更するか？その変更によって、他に影響を与えてしまって壊れてしまわないか？を点検してからでないと、手を加える事が出来ません。
なので「設計書」と言う成果物は、とても大切なものなのですね。
時折、聞く話なのですが、規模が大きくない会社では、社内SEが存在しないなんて事は、当たり前の事なのですが、そのような会社が業務改善や効率化施策の一環として、表計算ソフトにマクロ（複雑な計算ロジックなど）を埋め込んだ簡易システムを作って利用するようなケースがあります。
また、その簡易システムの制作依頼を、本業の空き時間に趣味の一環で、チャチャっと作業を請け負ってくれる便利屋さんみたいな方にお願いする事もあると思います。
その時、簡易システムだけでなく「設計書」も成果物として受領しておかないと、後々修正を加えたい時に、「設計書」が無いと、どういうロジックをどう変えたら良いのか、その変更がシステム全体に影響しないか？が検証できない為、同じ人に依頼できないと、最初から作り直しになるケースがあるんですね。
ただ、得てして、ITやシステムにあまり詳しくない担当者が作業依頼すると、当然、「設計書」の重要性など知りません。一方、作業を請け負う側も、面倒な設計書を書いて納品する事はせずに、頭の中の設計書ですべてを作り上げてしまう事も往々にしてあるでしょう。
安価に短納期でシステムを作るという事は、この「設計」のプロセスを省略して（頭の中だけで終えて）しまって、ドキュメントとして残さない事につながります。
当然、頭の中だけで組み立てた設計は、他の技術者には見えません。仮に同一の技術者に修正をお願いするにしても、大分時間が経過してから、以前どういった設計をしたか正確に記憶に残して思い出す事は不可能でしょう。
「設計書」を残さなかったが故に、後々、ちょっとした修正をするにも、結局、作り直しと同じくらい費用も時間もかかる事になる為、質の良い「設計書」も一緒に納品してもらう事はとても重要な事なのです。
次回の記事で紹介する事
今回の記事では、社内SEの仕事として「IT全般」の「面倒」を見る、「面倒」を見るとは？を切り口に、その全体像と「５．要件検討」「６．設計」について書いてみました。
次の記事では、今回の続き「７．製造・構築」以降について、なるべく分かりやすくザックリとお話していきたいと思います。
長文をお読み頂き、ありがとうございました。ご興味を持たれた方は「イイネ」「フォロー」頂けますと励みになります。
いいなと思ったら応援しよう！
