20220410 システムエンジニアの仕事について
どうも、名探偵(meitantei)です
昨夜どんだけ考えても解決できなかったC#のマルチスレッドのバグがすんなり解決できたから、逆に他の仕事のやる気が無くなった者です、こんばんは
スレッド制御は難しいし、バグの温床となる臭いがプンプンするのでできればやりたくないですね
えーと、本日はですね、
といった声が届いておりますので、いつもと毛色を変えてIT業界のおしごとについて、ざっくり解説していきます
いわゆるウォーターフォール開発という開発手法しか経験したことがないので参考になるかわかりませんが、どうぞよろしくお願いします
上流工程から順番に解説していきますね、たとえ話はイメージがつきやすいよう「note」を題材とします
要件定義
といった要望、理想の形を顧客からヒアリングするフェーズです
簡単に言ってますが、めちゃくちゃ難しいです
システムエンジニアは相手が求めているものをあの手この手で聞き出そうとしますが、顧客自身が自分が何が欲しいのかよくわかってないor言語化できないことが多いです
もちろんシステムエンジニアのヒアリングスキルが低いことも多々あります
トラブルの根源になるのはだいたい要件定義
本番リリース後に以下のようなことを言われがちです
のちに言った言わんの話になったり、言わんかったけど察して欲しかった…などホントにめんどい
基本設計
要件定義で聞き出した要件を実現するために、各機能の役割を決めるのがこの「基本設計」というフェーズ
画面のレイアウトだったり、業務フローだったり、データベースの構成を考える
頭使うけど個人的にはわりと楽しいフェーズです
このように画面のボタンを1つ忘れたり、DBの項目を1つ忘れたりするだけでえらいことになります
あとここでお客さんと「こういう画面で作っていくけど文句ありますか~?」と認識合わせ、レビューを行います
だいたい要件定義の時に言ってたことと違うこと言い出すので腹立ちます
そんでこの段階で盛大にミスっていても意外とスルーされて、後日時間差で爆発
詳細設計
クソざっくり言うと基本設計で考えた機能をプログラミングに落とし込むための前準備である
基本設計で考えた内容をプログラミングするときどうやって作るのか、を考えるフェーズとなっています
ここで要件定義の時に決めとくべきだったこと、基本設計の検討漏れなどが浮き彫りとなり、着火されることもしばしば
プログラミング
ITの代名詞といっても過言ではない、プログラミング
全体の工程から見るとプログラミングするのはほんの少し
やりがいを感じるフェーズであり、線香花火のような刹那的な楽しさを感じるフェーズでもあります
結合テスト
プログラミングして出来上がったものをくっつけて、ちゃんと動くかどうかテストするフェーズとなります
びっくりするぐらいだいたい動きません
リリース
マジでやりたくない仕事の1つ、単純な作業ではあるが責任が重すぎる&データ移行とかあるとだいたいグダる
ユーザーに一生懸命作ったシステムをお披露目します
なんて言われることはありません、経験上
旧システムと比較されて、罵詈雑言を浴びせられたのち改善を求められますがこちらも慣れてるので「つかっとったら慣れるよ、それまで待て」といったスタンス
運用保守
作っておしまい、バイなら!
ではないので、本番リリース後しばらく地獄が続きます
鳴りやまない電話に必死で言い訳回答し続けて、熱が冷めるのも待ちます
「やっと終わった…のんびりしよ…祝杯上げよ!」
なんて感傷に浸る間もなく、次のプロジェクトに回され、まだ見ぬ地獄へ…
まとめ
見てもらったらわかると思うけど砂上の楼閣なんです、システムって
どっかのフェーズでほころびがあれば、次工程も間違った方向に進み続ける
魔界村もびっくりの無理ゲーに近い
俺がやりたくない作業TOP3は以下にまとめてますので是非
【ブログやってます】
新社会人の模範とならない男が書いたブログが以下です
みんな仲良くしてね
この記事が気に入ったらサポートをしてみませんか?