社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

今週のお題「オンライン」

はてなブログ今週のお題「オンライン」

オンラインとオフラインの違いが分かりません。

深い意味ではなく、直接会うことをオフラインと呼ぶことにどうにも馴染めず、いまだにオンライン、オフラインと言われると、どっちがどっちだったか迷います。

それはどうでも良いことですが、SNSが発達したおかげで音信が途絶えていた中学時代の旧友とも繋がることができ、数年前に毎年やっているという同窓会にも誘ってもらえました。

30年近く会っていなかった同級生にオフラインで会って、最初はお互いに懐かしがっていたのですが、時間が経つとあまり話題も無く、毎年会っている人たちの輪にも馴染めず、ちょっと居心地の悪い同窓会でした。

それからは毎年誘ってもらってはいるのですが、なんだかんだ言い訳をして、それ以降は参加していません。

コロナの影響でテレビ会議の仕組みが一気に浸透してきた今、オンライン同窓会なら居心地の悪そうな顔を見られることもなく、気軽に参加できるかもと思う今日この頃です。

f:id:SystemEngineers:20200405172844j:plain

クラウドのつもり

緊急事態宣言!!!

ついに緊急事態宣言が発令されました。

東京、神奈川、埼玉、千葉、大阪、兵庫、福岡の7都府県が対象なので、私の会社の店舗も大部分が休業・・・なんか世の中に不要な存在と言われているようで、ちょっと悲しいです。

これだけの店舗を休業にしてしまうと、もしかして倒産?倒産?倒産?

心配していたら、どうも雇用助成金というものが国からもらえるらしい。正確にはいろいろ細かい計算があるようですが、ざっくり言うと休業した従業員一人当たり一日8330円支給されるそうです。

8330円だと新入社員の人件費にも満たないですが、中途半端に営業しているよりも良いのかもしれません。

大部分の社員が明日から休みになる中、私は残念ながらテレワークできてしまうので、仕事継続です。

休日?

5日間働いて、土曜日の今日は仕事は休み。

普段なら特別なことが無い日でも、金曜日の夜や土曜日の朝はうれしいものですが、平日テレワークでずっと家にいたので、あまりうれしさがありません。

というより、休みなのか?と思うくらい、休みの実感がありません。

逆に言うと、平日の5日間が働いている実感が無かったせいだと思います。

というより、実感ではなく、実際に仕事あんまりしてないです・・・ごめんなさい。

今週のお題「しごとの思い出」

はてなブログ今週のお題「しごとの思い出」

20代の頃は、しごとで失敗してばかりでした。

改修すればバグだらけで、親会社の部長に呼び出されてお説教。本番環境のゴミ掃除を勝手にやって、誤って本番モジュールを削除してオンラインダウン。機密情報(全取引先の仕入情報の一覧)を社内にメールするはずが、あて先を間違えて他社に送付。

落ち着きが無いというか、注意力散漫というか・・・。でも不思議と凹んだ記憶は無く、同僚とも仲が良く、楽しく仕事をしていた記憶だけが残っています。

ITが急速に進歩して、複雑性と重要性が増して、ITガバナンスやセキュリティー、個人情報保護とかがうるさく言われ、ちょっとした失敗も許されなくなった今の時代。

もちろん今でもしごとの楽しさはあるけれど、失敗しても笑って許された(ような気がする)時代のおかげで、こんな私でも今でもこの業界で頑張っていられるのだと思います。 

f:id:SystemEngineers:20200329174817j:plain

オフィス

転職nendo×はてなブログ 特別お題キャンペーン #しごとの思い出

転職nendo×はてなブログ 特別お題キャンペーン #しごとの思い出
by 株式会社Jizai「転職nendo」

開発工程(基本設計)

開発工程の中の基本設計の説明です。

1.要件定義との違い

基本設計のINPUTは要件定義書です。要件定義書がユーザーの言葉で記載されているのに対して、基本設計書はシステムの言葉で記載されています。

要件定義との大きな違いは、ユーザー部門のレビューを受けるかどうかです。

基本設計は基本的にユーザー部門は関わりません。事業会社のシステム部門やシステム子会社がレビュアーになります。

ところがベンダーの考える開発工程は、以下のように定義しているケースが多いです。

要件定義:業務フローや機能一覧、主要画面の入出力項目を決定
基本設計:画面や帳票レイアウトを決定

つまり基本設計もユーザー部門の参画を前提としています。

たいていのベンダーはこの進め方でプロジェクトをはじめようとしますが、私は毎回それを却下しています。この進め方で上手くいくこともあるのかもしれませんが、ある程度の規模の会社では、この進め方では以下のような理由で炎上します。

①ユーザーは業務フローなど理解できない

「業務フロー」と呼んでいますが、あくまでもシステムのドキュメントです。ユーザーは普段、業務フローなんて作らないので、このドキュメントを見ても自分たちの業務をイメージできません。

ユーザーが自分ごととして見れるのは、画面や帳票レイアウトです。画面があってはじめて自分たちの業務がイメージでき、具体的な要望がでてきます。これを基本設計でやると手戻りが多くなり、ユーザーの要望も叶えられないケースも出てきたりして、関係が悪くなります。

要件定義で最初にやるべきことは、画面や帳票のレイアウトなのです。

②ユーザーは忙しい

ITエンジニアの都合で要件定義と基本設計の両工程に参加を依頼しても、ユーザーはシステム開発が本来業務でないので、長期間、打合せに参加することを嫌がります。しかも最初にやるのが業務フローとか機能一覧といった自分たちに馴染みの無いドキュメントばかりだと、肝心の基本設計に入る頃にはモチベーションが相当落ちています。

③ユーザーは要件定義と基本設計の違いなんて分からない

工程を分けると、ユーザーはどこで何を決めればいいのか迷います。要件定義でいろいろ要望を出しても、「それは基本設計で決めます」と言われてしまうと、どのタイミングで要望を出せばいいのか分からなくなってしまい、基本設計に入る頃には言おうと思っていた要望を忘れてしまい、基本設計が終わってから、最悪のケースでは受入テストになって思い出すといった事態になります。

要件定義:ユーザー部門と決めること
基本設計:システム部門と決めること

という定義にすることで、早期に仕様をFIXすることができ、ユーザーにとって分かりやすいプロジェクトになります。

プロジェクトの一番の目的はQCDではなく、顧客満足です。ユーザーが、あの人たちに頼んで良かったと思えるようなプロジェクトの進め方をすることが重要です。

2.基本設計でやること

要件定義は、ユーザー部門を相手にするので

・画面レイアウト
・画面遷移図
・帳票レイアウト
・ビジネスルール

といったユーザーの目に見える部分を決めるドキュメントを作ります。これらを総称して要件定義書と呼びます。

それに対して基本設計は、システムのプロだけで進める工程なので

・テーブルの論理設計
・ER図やCRUD
・画面や帳票の入出力設計
・機能分割
・ビジネスルールのシステムロジックへの置き換え

といったシステムの作りの概要をまとめるドキュメントを作ります。

画面や帳票、ビジネスルールといった情報を元に、必要な機能を定義して、テーブルを設計します。画面で入力した情報をどんなテーブルに格納して、格納した情報をどんなタイミングで更新したり画面に出したりするのか、またテーブルに入出力する際に適用するビジネスルールをシステムのロジックで表現し直したりします。

規模の大きいシステムの場合、全体設計で機能の定義やテーブルの設計を行い、その後、個々の機能ごとに個別の基本設計を進めます。

3.基本設計の例

紙で回付している稟議書のワークフロー化の要件をもとに基本設計を考えてみます。

要件
「社外秘は、同じ部署の人は全員が参照、ダウンロード、印刷が可能」
「機密は、稟議を回付した人だけが参照、ダウンロード、印刷が可能」
「厳秘は、稟議を回付した人だけが参照のみ可能で、ダウンロードや印刷は不可」

要件定義で階層構造化した組織のテーブル、ユーザーのテーブル、権限のテーブル等を設計します。

また稟議の機密区分の違いによる権限の違いをどのようにコントロールするかを考えます。

ユーザーが稟議を検索した際、
・ユーザーが回付ルートに含まれる稟議
・ユーザーと同じ部署のユーザーが起案して、かつ、機密区分が社外秘の稟議
この2つのロジックで検索をすれば、参照の要件を過不足無く満たすことができます。

 では、この2つのロジックをどのように実現すれば良いでしょうか?稟議のテーブルにユーザー情報や組織情報、機密区分を持たせることで、対象の稟議を過不足無く抽出することができます。

ここでもう一歩、考えなければいけないことは、稟議のテーブルに本当に組織情報を持たせて良いかどうかです。ユーザーのテーブルにはユーザーが所属する組織情報があるので、稟議のテーブルに組織を持たせなくても、テーブル同士を結合することで、要件を実現することはできます。

稟議のテーブルに組織情報を持たせるかどうかは、異動時の扱いで決めることができます。

例えば総務部で起案した稟議は、他の部署のユーザーからは参照することはできません。もし稟議のテーブルにユーザーの組織情報を持たせず、ユーザーのテーブルから組織情報を参照する設計とした場合、どうなるでしょう。

極端な話し、総務部で起案した稟議に携わった人たちが全員人事部に異動してしまった場合、その稟議は後から総務部に異動してきた人たちから参照することができなくなってしまいます。

これが稟議のテーブルにユーザーの組織情報を持たせていれば、起案時点の組織情報を持つことになるので、異動による影響を受けなくてすみます。

基本設計は、このような感じで、自分の頭の中でシステムを動かしながら設計をしていきます。

【振り返り】

今回は基本設計の説明でした。次回は詳細設計の説明をしていきたいと思います。

①戦略・企画
②要求定義
③要件定義
④基本設計
⑤詳細設計
⑥製造
単体テスト
結合テスト
⑨総合テスト
⑩受入テスト

初テレワーク

小池東京都知事の要請もあり、ついに在宅勤務が実現!

昨日、出社してテレワークの準備をして、今日からしばらく在宅勤務です。

コロナは困るけれど、在宅勤務は最高です。

普段からテレビ会議を多用しているので、思った以上に仕事に支障がありません。

コロナが終息しても、このままずっと在宅勤務を続けたいです。

今週のお題「わたしと英語」

はてなブログ今週のお題「わたしと英語」

絶望的なほど、英語が喋れません。

学生時代はバブル真っ最中で、半分本気でいつか日本語が世界の標準語になるだろうと思っていたせいか、勉強にも力が入りませんでした。

社会人になって、少しは英語を喋ってみたいと思い、英会話教室に通うことも考えたのですが、どうも教室で英語を喋らされている自分を想像すると、抵抗感があって・・・。

額に手を当てて「オーマイガー」と言ったり、両手を広げて「ブラボー」と言ったり、握った拳の親指を立てて「ナーイス」と言ったり・・・。オーバーアクションが苦手です。

きっと英語に対して、何か偏見を持っているのだろうとは思いますが、私にとっての英語は、オーバーアクションに眉を八の字に曲げて「ハード」なのです。 

f:id:SystemEngineers:20200324074645j:plain

アルク #トーキングマラソン 特別お題キャンペーン「わたしと英語」

アルク「トーキングマラソン」×はてなブログ 特別お題キャンペーン
by アルク「トーキングマラソン」