社内SEになりました

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

今週のお題「ホーム画面」

はてなブログ今週のお題「ホーム画面」

スマフォのホーム画面をいじれるって知りませんでした・・・

というより、どれがホーム画面なのかが分かりません・・・

IT業界にいながら超機械音痴で、スマフォデビューは 2015 年。

それまでは自分のポケベルも携帯も持ったことがなく、頑なに留守電機能さえない「おしゃれな」木の固定電話を貫き通していました。

スマフォを持った今でも、メールは PC のものしか使わず、電話することもほとんどなく、時計以外の機能では LINE を使っている程度。

スマフォの設定をいろいろいじるなんて、機械音痴のプライドが許さないのです。

新しいPC

今の会社に入って最初に驚いたのは、Chromebook でした。

恥ずかしながら、WindowsMac 以外に ChromeOS というものがあることを知らなかったので、それだけで先進的な会社だ!と驚いていました。

そして Chromebook を使って2年半・・・

ChromeOS に限界を感じ、WindowsPC に戻す判断がされました。

まだまだパッケージや SaaS で、ChromeOS に対応している製品が少なかったのが決定的な理由です。

そして今日、新しい WindowsPC が私の手元に。

自宅の PC は Mac なので、はじめて触る Windows10 。何はともあれ、新しいパソコンはうれしいものです。

今週のお題「サボりたいこと」

はてなブログ今週のお題「サボりたいこと」

昔から団体行動が苦手です。

小学生のときであれば遠足や運動会、中学・高校では体育祭や文化祭、大学であれば新歓コンパや学園祭、社会人になってからは、社員旅行とか忘年会とか自社ビルの大掃除とか。

社員旅行や忘年会などは、毎年、毎年、何か理由を見つけて欠席してました。

今はコロナ禍で、大人数の集まりができなくなったので、快適な世の中になったなあと感じています。

意外な反応

POS 再構築の企画をしています。

社長からは今までの業態の常識に縛られず、ドラスティックな提案をしろと言われているので、セルフレジに毛が生えたような超スリム化した POS の提案をすることにしました。

経営報告前に、業務部門の人たちにも話をしておこうと思い、本日、主要部門の部長たちに案の説明をしたところ、意外にも好反応。

偉い人たちは公の場ではネガティブ発言はしないので、炎上するとは思ってませんでしたが、まさか感謝の言葉までもらえるとは思いませんでした。

でも油断は禁物。

総論賛成各論反対がよくあるパターンなので、これからが正念場です。

今週のお題「好きな街」

はてなブログ今週のお題「好きな街」

2002年から毎年行っている石垣島

コロナ禍になって2年ほどご無沙汰してますが、一時は仕事を辞めて移住まで考えてました。

はじめて訪れてから20年。港が新しくなって、空港も新しくなって、都会風の建物が増えていって、少しずつサンゴが減っていって。

仕事を辞めての移住は断念しましたが、10年先、あるいは20年先のリタイア後には、石垣島で暮らす予定。

20年間、毎年お世話になっている海人家族が経営しているペンション。

今年は3年ぶりに帰省できそうです。

ゴールデンウィーク最高

小売業なので、ゴールデンウィークでも仕事です。

でもベンダーや取引先が休みなこともあって、本社の人間は結構、有給とっている人が多く、普段は打ち合わせでびっしりのスケジュールも、この3連休はほとんど打ち合わせがありません。

自分の仕事が超捗ります。

昼寝も捗ります。

在宅勤務なので、内職も捗ります。

溜まっていた仕事は今日で全部終わっちゃったので、残り二日をどうやって過ごすか、贅沢な悩みです。

RFPの書き方:工程定義、成果物

RFP の書き方の説明です。

第四回は、工程定義と成果物の説明です。

1.工程定義

開発工程は、ベンダーが決まってからベンダーとの話し合いで決まりプロジェクト計画書で定義されます。

RFP における工程定義は、主にマスタースケジュールと連動し、マスタースケジュールの各大タスクのボリューム感を掴むためのものです。

そのため一番重要なことは、工程定義の各工程が、マスタースケジュールのどの線にあたるのかが分かることです。1対1になっていればベストです。

また工程定義の各工程で重要なのは「単体テスト」です。

単体テスト」は一番認識違いが起きやすい工程です。

教科書的には「単体テスト」とは、プログラムが個々の機能を正しく果たしているかどうかを検証するテストで、 通常、関数やメソッドが単体テストの単位(ユニット)となります。プログラムテストとも呼ばれます。

ただ現実のプロジェクトでの「単体テスト」は、1画面内のバリデーションなどのテストや、バッチであれば1ジョブ内のテストを指すことが多く、教科書的には「結合テスト」に該当します。

どちらが正解というものではなく、工程の呼び方の問題なので、まずは RFP の中では「単体テスト」がどちらを指すのかを明記しておきます。

また忘れがちなのがアプリケーションの工程以外の基盤系の工程です。非機能要件定義、基盤設計、基盤詳細設計、環境構築などもきちんと定義し、マスタースケジュールと対比できるようにします。

特に開発環境など本番環境以外の環境を作る場合には、環境構築も本番環境と工程を分けて、本番と開発のどちらの環境を先に作るかをマスタースケジュールで明記した方が良いと思います。

スケジュールに余裕のないプロジェクトは、通常、本番環境から先に作ることが多いですが、会社によってはまずは開発環境で品質を担保して、その後、本番環境を構築するといったルールを決めているところもあります。それらは発注者がベンダーに RFP の中で伝える必要があります。

他にも教育や移行の計画、再構築の場合の既存システム凍結期間などがある場合にも、これらもマスタースケジュールに記載します。

2.成果物

各工程でどのような成果物を作成するかを記載します。

成果物に対しての認識合わせはベンダーが決まってから、プロジェクト計画を作る際に話し合い、認識を一致させる必要がありますが、RFP 段階ではそこまでのことはできないので、あまり細かい成果物名は必要ありません。

例えば、要件定義で作成する成果物で、「業務フロー」「機能一覧」「ビジネスロジック」など細かく成果物名を書いても、逆に漏れが出てしまうので、「要件定義書」と書けば十分です。

それよりも要件定義書以外の成果物を記載することが重要です。

議事録、要件定義完了報告書、進捗報告書、といったものです。

またここでも重要なのが「単体テスト」です。

テストケースは作るのか、工程完了報告はするのか、といった点で認識違いが起きやすいです。

前述のとおり「教科書的な単体テスト」は、通常は発注者はレビューしませんし、よほどの大規模プロジェクトでもなければ、品質報告も要求しません。

それに対して「実プロジェクトで多い単体テスト」は、画面でのチェックなどが対象になるので、発注者のレビュー対象となりますし、品質報告の対象ともなります。

それが都合のいい部分だけを解釈して、「実プロジェクトで多い単体テスト」なのに、発注者はレビューせず、ベンダーも品質報告をせず、といったプロジェクトが非常に多いのが実態です。

規模の小さいプロジェクトの場合、一番重要なテスト工程は「実プロジェクトで多い単体テスト」にも関わらずです。

ただ「実プロジェクトで多い単体テスト」は、テストケース数も多いですし、品質報告も大変なので、プロジェクトがはじまってから認識違いが発覚すると費用面で揉める可能性があります。

ベンダーはテストケースは通常作りますが、それを納品物にするとなると、やはり自分達だけで使うものと納品物とでは手間が違いますし、品質報告をするためにはきちんと障害の管理もしないといけないので、RFP の段階で「実プロジェクトで多い単体テスト」の成果物を明記しておく必要があります。

【振り返り】

今回は RFP に記載する工程定義と成果物の説明でした。次回は前提条件や課題等の説明です。

①はじめに(用語集や関連資料など)、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法