ID:39200さん

2024年1月～現在

[システム概要]

DQM(Data Quality Monitor）システム：
　AML（アンチマネーロンダリング）でチェックした状況を可視化する。
やり取りした電文に対し、どのくらいチェックできているか、どのくらいチェックでエラーになっているかを把握するためのシステム。

[技術]

・Tableau
・JP1
・Oracle
・GitLab
・Jira

[規模]

10名

[主な役割]

・顧客要望によるダッシュボードの修正 / リリース

・フローの修正 / 改善

・ドキュメント整備
　現在、一部のフロー一覧しかない。運用に必要なドキュメントの候補を挙げ、整備中。
　現時点で必要と感じているドキュメント
　・フロー一覧（全量）
　・データソース一覧
　　どのデータソースが、どのフローで作成 / 参照されているか、どのダッシュボードで参照しているかなどを含め記述予定。
　　障害やデータ遡及時に、どこのダッシュボードに影響があるかの調査が迅速にできる。
　　顧客からの問合せがダッシュボード起点になる。
　　ダッシュボードの参照しているデータソースから、問題がどこにあるか、あたりをつけやすくするため。
　・ジョブフロー図
　　データの品質基準は４種類ある。
　　どのテーブルを基にどのように作成しているか、
　　フローの流れやデータの流れ全体を俯瞰できる資料がない。
　　障害発生時や顧客問合せ時に調査のあたりをつけやすくするため。
　・フロー障害発生時のリラン手順
　　障害発生ポイントにより、単純リランではNGのケースがある。
　　現状、フローでの障害発生時、どこから、どのようにリランすればよいか確認に時間がかかる。
　　障害発生条件（おもにどのフローで発生したか）によって、障害対応を迅速 / 正確に行えるようにするため。
　・フローの詳細（ドキュメントで起こさず、フローのコメントに記述することで代用予定）

・MX対応リリース後の整理
　・MX対応の１次開発分をリリースした後の、不具合 / 問題点の整理、推進。
　　本開発～リリースには参画しなかった。
　　が、色々な問題が発生したため、問題点を整理し、解決を推進していく。
　　・問題点の現象、原因、対策、対策状況の整理。
　　・上記より原因分析し、類似見直し観点や範囲の策定。

[課題 / 問題点]

　現行の運用で以下のような課題がある。
　・Tableauのフローで異常終了すると、リランが複雑で回復まで時間がかかる。
　　その場その場で確認するので、ミスが発生しやすい。
　・フローが複雑で全体の見通しが悪い。現状の動作を把握しづらい。
　改善するためにも現状把握をする必要がある。必要となるドキュメントをあげ、作成することを提案している。

保険会社　時価評価システム

2022年8月～2023年6月

[システム概要]

時価評価システム：
　徴収した保険料や支払った保険金などから、将来どのくらいの保険金が発生するのか、CSM（マージン）がどの程度あるのかなど予測するシステム。
予測のために実績を集計している。集計したデータを経理部に渡し、損益計算書と貸借対照表の元データとしている。

[プロジェクト概要]

IFRS（イファース）に対応するために、前システムをリプレース。
2025年に本番予定。
システムの開発は別ベンダが担当で、初期開発 / フェーズ２、３の開発が完了している。
テストを４段階で予定しており、これから３段階目の顧客テストを実施する。
２段階目のテスト終了後から参画。

[技術]

• SAS
• JP1

[規模]

4名

[主な役割]

本番をいい形でむかえれるよう、顧客と必要なことを調整し進める。
・JP1ジョブの登録・実行などの管理
・内部統制（J-SOX対応）会計監査用チェックリストの作成
・開発ベンダが作成したドキュメントや、テストケース、テスト結果エビデンスのチェック
・データの復旧
・リリースの準備や申請
・問合せ対応
・他

　Salesforceを主軸とした事情拡大

2021年7月～2022年7月

[概要]

2021年7月より、Salesforceを主軸とした受託開発ができるチームを造るための事業に参画。
案件が取れておらず、学習や社内業務が主。

[主な業務]

１．Trailhead やセミナー参加で学習し、スキルの向上・資格取得。

２．工数算出の検討他
①学習塾システムを、Salesforceで実装した場合の工数算出方針の検討
提示していただいた資料：
　・ER図
　・DBレイアウト
　・画面設計書（レイアウト、項目、アクションはあるが、処理詳細はなし）
　・バッチ処理一覧
方針：
　上記の資料を提示していただけた。しかし、システム構成図、業務フロー、機能一覧など、全体を把握できるものは少なかった。
　下記の方針とした。
　・DBレイアウトからおおよそのテーブル数を仮定し、Salesforceでのテーブル数＝オブジェクト数と仮定
　・１テーブルに１画面があると仮定（テーブル数＝画面数）
　・画面設計書（約700画面）から200画面をピックアップし、下記で算出
　　※参照系・更新系か、マスタ管理か請求などのコア業務かなど、バランスを考えピックアップ
　　・項目数で大・中・小を分類し、それぞれの割合を算出
　　・アクション数で難・中・易を分類し、それぞれの割合を算出
　　・項目数とアクションによる分類で、それぞれどのくらいの工数とするか仮定し、割合から工数を算出
②ApexでSalesforce⇔kintone連携を実装した場合の工数算出
　以下のように工数算出を進めた。
　・接続方式をRESTと仮定
　・シーケンス図を作成し、処理の流れや障害発生個所の把握
　・連携に必要となる管理項目の検討
　・必要な機能を検討
　・検討した機能間の各処理で、同時起動しないための制御
　・連携処理とユーザ入力の排他制御
③API参照名の項目名辞書の方針整理
　主に使用するのはキャメル式 （Salesforceの標準項目がキャメル式）or スネーク式なので、API参照名は２つに対応させる。
　項目の意図と、どの案件で使用しているかのプレフィックスも付加するようした。
　・辞書の項目を以下のように決定
　　・項目名
　　・よみ（ひらがな）
　　・項目の意味、意図
　　・API参照名（キャメル式、スネーク式の両方もつ）
　　・略称名
　　・プレフィックス（共通 or 案件固有）
　・運用ルールの策定
　　・案件ごとの方針決定：
　　　プロジェクト開始時点で、顧客にこだわりがあるか確認、なければ合ったものを決定（プレフィックスや命名方式）
　　・項目名の決め方：
　　　基本は英訳する。基本は翻訳を使うが、検索して意味に沿っているものを探す。
　　・辞書への追加・更新・削除方法
　　・辞書の場所：
　　　検索できれば運用できそうなので、操作の軽い Confluence にする。
　　　ただし、フィルタリングやソートする場面が多ければ box + excel に変更予定。

３．以下のような社内業務の整備など。
　・メンバーが日々どういった業務に何時間従事したかを分析するための、作業票の分類の整理
　・IPAの「DXアセスメント指標」を、お客様に回答していただくための翻訳や項目の整理

資格

• Salesforce 認定 Platform アプリケーションビルダー（2022/04）
• Salesforce 認定 Platform デベロッパー（2021/11）
• Salesforce 認定上級アドミニストレーター（2021/09）

０．家電修理コールセンターシステム　リプレース

2019年6月～2020年12月

[概要]

弊社でフルスクラッチで開発した下記「家電修理コールセンターシステム」をSalesforceに移行することになった。現行システムのユーザ側有識者としてプロジェクトに参画。

[工程]

要件定義～総合テスト、運用テスト、移行設計、移行

[主な役割]

要件定義～総合テスト、移行設計
・開発ベンダからの現行機能の調査依頼に対する回答。主に画面処理、バッチ処理の概要やテーブル定義項目の使用方法、設定値、設定箇所の調査など。
・業務フロー、ER図、機能一覧のチェック。
・オブジェクト定義、画面処理設計書、スクリプト設計書（バッチ処理）、帳票設計書、他システム連携フォーマットなどのチェック
・期間中で、現行システムで新たにエンハンスした内容を開発ベンダへ連携。
・oracle テーブルをSalesforceオブジェクト移行のマッピング。データの抽出クエリ作成。

[工夫した点]

・CTI（iCTNET、ライトニングFAX）とSalesforceの連携で、連携方式や役割分担を提案。
　・責任分界点を分かりやすくするためにDMZに連携サーバを置いた。
　・Salesforce（Dataspider)側から定期的に取りくる。FAXで受けたものをケースとして取り込むという方式。
・現行システムから新システムで変更になる点や、現行システムでのポイントとなる機能を整理。
　整理した点
　・いつまでECが主導で、いつからSCが主導となるかが曖昧。
　　受付完了でECからSCに責任が移るタイミングがはっきりしていなかった。対応する拠点が決まった時に受付完了とした。受付完了することで、それ以降はSCが主導となるように決定。
　・オペレーションの複雑化
　　現行システムでは、１つの画面のオペレーションで登録ができた。新システムではオブジェクトごとに画面から登録する必要がある。どの情報がどのオブジェクトにあり、どこから入力するか理解していただいた。
　・ポイントとなる処理の品質向上
　　・早期の段階から開発ベンダに促し、現行の処理をよく理解し設計してもらうようにした。
　　・影響の大きい処理・複雑な処理は、設計書を複数回レビューした。設計段階である程度の品質を確保。

[PR]

・移行元システムの開発ベンダであったが、顧客からの要望で参画。
・当初は設計フェーズのみの参画予定だった。新システムの仕様も把握したため、本番移行まで必要としていただけた。
・通常は開発ベンダ側で参画するが、ユーザ側という貴重な経験ができた。ユーザ目線で考えれるようになった。

1. コールセンターシステムCRM初期開発

2007年6月～2008年11月

[概要]

家電修理のコールセンターシステムをフルスクラッチで開発（フロントのCRM部分）。

[工程]

フェーズ１：基本設計～総合テスト
フェーズ２：機能追加

[開発規模]

約100Kstep（全体：150Kstep）
15名（全体：30名）

[規模]

コールセンタ拠点数：2拠点
オペレータ数：約500名

[役割]

PL

[工夫した点]

• コールセンター知識、CTI知識の補完
  　コールセンターシステムやCTIの知識が乏しかった。現場のSVの方に現状業務や問題点をヒアリングしたり、CTI開発元のベンダと定例会をしたりして理解した。
• 運用の統一
  　東西２つの拠点が存在し、違う運用をしていた。ヒアリングの結果、西の拠点の運用が統率が取れまとまっていたため、西の拠点の運用方法をベースに極力運用を統一して頂いた。

[反省点]

• 担当ではなかったためCTIの管理ツールをどのように運用にあてはめるかに関われなかった。（担当分しか見れなかった）

[その他]

• 開発言語の選択
  JAVAとC#との選択肢があった。本プロジェクトの開発では、社内および協力会社の開発者に Visual Studioや.NET経験者が多かったこともありC#.NETを採用した。
• フェーズ２機能追加
  フェーズ１で不足していた点や改善要望をよくヒアリングした。リリース後に現場のSVやオペレータから感謝され非常に嬉しかった。担当者にも顧客から便利になり感謝されたことを伝えて喜びを共有できた。
• 習得できた知識
  　下記を 自分で構築はしていないが、概要や使い方は理解できた。
  　　・oracle
  　　・CTI（サーバ、通録）
  　　・VMware
  　　・Active Directory　
  　　・WSFC

2. コールセンターシステム　バックエンド部分初期開発

2008年12月～2011年9月

[概要]

家電修理のコールセンターシステムのバックエンド部分をフルスクラッチで開発。バックエンド部分のサービスセンタ（修理を実施し売上請求など）向けの開発で、担当はバッチ処理。

[担当工程]

フェーズ１：基本設計～総合テスト

[開発規模]

約80Kstep（全体：400Kstep）
8名（全体：35名）

[規模]

拠点数：約100
サービスセンタ作業者：約1,500名

[役割]

PL

[工夫した点]

• 他システム連携
  　連携システムの中には汎用機もあったため、連携方式やコード体系、連携レイアウトは気を遣い連携先とよく協議した。連携先の処理も確認し項目に不足がないようにした。
• バッチリランの考慮
  　・バッチ処理が担当であったたため、DBにコミットするタイミングやリラン方法を考慮しながら設計を進め、後戻りしないようにした。
  　・各処理でのエラー発生時、業務影響や特性を理解した。そこで処理を止めるべきか、そのデータのみ無視(またはエラーファイルによけておく）して後続を実行するべきか検討し、どう振舞うかを顧客と調整した。
• 画面処理との競合・排他処理の注意
  　オンラインバッチ処理があり、画面処理や他のバッチ処理と同時に動作する。デッドロック対策としてテーブル間やレコード間での更新順を決めたり、同一レコード更新の排他制御に気を付けて設計した。
• 重要・複雑な処理の考慮
  　・売上・請求や支払い処理（お金にかかわる処理）が最重要と考え、重点的に設計段階から注意してみるようにした。
  　・テストではクロスチェックを実施し、勘違いや凡ミスが出ないようにした。
  　・結果として、売上・支払いの連携処理で大きな問題は発生しなかった。

[PR]

• 連携するシステムが６システムと多く、顧客や連携先システムと調整力が必要な案件だった。

[反省点]

• 連動テストでの反省
  連携テストで、１つの連携先との摘出不具合が少なかった。顧客・連携先システムに追加テストを依頼した。しかし、顧客と連携先システムの判断で実施しなかった。本番稼働してから問題点が多数発生した。ただ依頼するだけでなく、どのような観点での追加テストが必要かなど提示して依頼するべきであった。

3. コールセンターシステム　CTIリプレース

2013年3月～2014年4月

[概要]

上記システムCRMのCTI部分を CTStage（沖電気製）から iCTNET（日立製）への変更および老朽化に伴うシステムリプレース。（oracleのバージョンアップなど）

[担当工程]

要件定義～総合テスト

[開発規模]

約15Kstep
5名（全体：20名）

[規模]

コールセンタ拠点数：2拠点=>6拠点

[役割]

PL

[工夫した点]

• CTI相違によるリスク緩和
  CTStageと iCTNETで同じ機能を実装するのに方式やイベントの考え方に違いがあった。リスクを減らすため開発元に設計段階は入ってもらい、後で大きな変更が起こらないようにした。

[PR]

• 下流工程での問題点に緊急で対応できた。
  　CTIの要件で伝えていたことが、総合テスト工程でできないと分かった。
  　正確には、できるが運用として現実的でない方法であった。
  要件：
  　・１人のオペレータやSVが複数のグループに所属する。
  　・所属するグループのパターンは多数ある。
  問題点：
  　オペレータごとに複数グループをひもづけできるイメージでいたが、そうではなかった。
  　所属するグループのパターンを全て定義し、パターンをオペレータにひもづけるような方法だった。
  　（パターンの組み合わせを定義するには多くて管理できない）
  解決策：
  ・オペレータと所属するグループを紐づけする運用ツールを作成した
  ・顧客に、運用ツールで紐づけする手順を追加していただいた
  理由：
  ・製品側で仕様追加するのは困難。
  ・追加してもらえたとしても、期間とコストが見合わない。

上記１～３での各工程での役割

[各工程での役割]

要件定義：基本的にはシステム老朽化に伴うリプレースであったが、CTStageからiCTNETに変更することでのメリット、デメリットを提示。顧客の以前からの要望で、CTStageから変更することで実装可能になる機能などを提案。
基本設計：基本設計書の記述、レビュー。
詳細設計～組合せテスト：

• スケジュール作成・進捗管理。
• アウトプット（設計書・ソースコード・チェックリスト）の確認、レビュー。
• 単体テスト・組合せテストでは、テスト方針作成、バグ票の管理、品質評価。
  総合テスト：テスト方針作成、チェックリスト作成、レビュー、バグ票の管理、品質評価、連携テストの調整。

4.コールセンターシステム　保守・運用

2014年4月～2019年12月

[概要]

上記システムの維持保守し機能追加。

[規模]

5名

[役割]

PL、PM

• 顧客要望の抽出および、どのような機能を追加するかの調整、設計。
• スケジュール作成・進捗管理。
• 設計書、ソースコード、チェックリストのレビュー。
• 総合テスト調整、チェックリスト作成。（テストは顧客が実施）

[工夫した点]

• 保守以外でも別案件（別チームでプロジェクトを立ち上げ進める）として機能追加の要望が何度かあり、要件ヒアリング、見積、基本設計実施、各工程のアウトプットのレビューに参加した。上流工程では顧客打合せには必ず出席し、各工程でのアウトプットをよくチェックした。この案件のプロジェクトチームに丸投げしなかったことで、品質を確保することおよび顧客に安心感を与えたことができたと考えている。

[PR]

• リリース後も頻繁に（１回/月のペース）で機能を追加を実施。
• 社員以外にも派遣、オフショア（中国）の管理。

[反省点]

• PMを引き継いだ直後に、ランサムウェアの被害を受けシステム復旧に１週間くらいかかった。
  　以前からマメにパッチ更新していなかったため。引き継いだ時に良くないと思ったが、面倒だと思い放置してしまった。気になったことは早目に行動し、やるべきことはやらないといけない。その後は毎月パッチを充てるようにした。

[その他]

• プロジェクトに新人が配属された際に新人教育も兼ね、新規機能追加時はテストを自動化し Nunit を導入した。

１．伝送パッケージ開発

2005年3月～2007年6月

[概要]

• 別部署で受託した伝送パッケージ開発が炎上し、ヘルプでプロジェクトに参加し１機能分の開発を実施した。
• 実際に伝送するServer部分と、Serverへの指示や状況確認をするManager部分とで形成。担当はManagerの１機能。

[担当工程]

詳細設計～組合せテスト

[各工程での役割]

詳細設計：詳細設計書作成
製造：スケジュール作成、コーディング
単体テスト・組合せテスト：スケジュール作成、チェックリスト作成、テスト実施、プログラム修正

[工夫した点]

• 主業務との両立
  下記プロジェクト「酒造メーカー業務システム保守・運用」を担当していたが、案件が炎上して緊急ヘルプで招集された。それまでの担当プロジェクトの窓口（要件確認や打合せ、設計）は行い、他社に実装・テスト作業をしてもらった。自分は本ヘルプ作業対応をした。
• 再帰処理の採用
  伝送経路の表示時、全体の伝送経路がわからない。接続先のサーバを見て次があるのか、そこが末端なのかを判断して伝送経路を描画する必要があった。（ディレクトリと以下のディレクトリとファイルを末端まで検索するイメージ）終了条件などを考慮し再帰処理を使い実現した。
• 描画処理の性能改善
  指定されたサーバの伝送状況をモニタリングする処理で、検索後に再描画するのに表示リストをすべてクリアしてから表示内容を作り直す処理とした（処理が単純であるため）。この方法だと表示時間がかかるのと、再描画処理で固まってしまう問題点が出た。前回の状況を保持し差分をとり、差分のあったところだけ更新するようにした。

[PR]

• 炎上した案件できっちりした設計書がなかったが、要求されているものを想定し良く確認して進めた。
• 厳しい工程だったが、３カ月間で詰め込んで作業し納品には間に合った。
• 自分の担当分についての品質は確保できたと考えている。顧客からの指摘はバグよりも要望が多かった。
• 元々は別の外注業者が担当していた処理だが、方式が難しく全然進捗しなかった個所をヘルプ作業で担当した。

[反省点]

• 実装での反省点
  C#で実装した。オブジェクト指向での開発は初めてであったため、プログラムの動作としては問題なかったが、オブジェクト指向の経験がなかったため構造化プログラミング的な実装をしてしまった。

２．上記伝送パッケージの再開発

2005年9月～2007年4月

[概要]

上記で対応した案件が、問題点が多く再開発となり、Manager部分のPLとしてプロジェクトに参加。

[担当工程]

基本設計～総合テスト

[各工程での役割]

基本設計：スケジュール作成、基本設計書作成、レビュー
詳細設計：スケジュール作成・進捗管理、詳細設計書レビュー
製造：スケジュール作成、ソースコードレビュー
単体テスト・組合せテスト：スケジュール作成、チェックリストレビュー、テスト実施、プログラム修正レビュー
総合テスト：チェックリスト作成、実施、バグ票管理。

[役割]

PL

[PR]

• 重点対策プロジェクトとしての対応
  品質が問題となったためプロジェクトを基本設計から再スタートした。開発メンバーとして参加しManager側のPLを担当した。他のプロジェクトに携わっていたが（総合テストの後半）、本プロジェクトが優先的にクローズする案件となりPLとして招集された。

保険会社様CRMシステム　保守

[概要]

保険会社様CRMシステムを保守し機能追加。
ホストと連携しデータ蓄積、オペレータが参照、帳票出力するシステム。

[規模]

2名

[役割]

PM

[担当工程]

詳細設計～組合せテスト（要件定義、基本設計、総合テストを顧客にて実施）

[工程ごとの役割]

詳細設計：詳細設計書作成
製造：コーディングレビュー
単体テスト：チェックリストレビュー、バグ票管理、品質評価
組合せテスト：チェックリスト作成、テスト実施、バグ票管理、品質評価

[工夫した点]

• 手順書等の可視化
  ・引き継ぐときに作業が俗人化していた。手順書（顧客要望～リリースまで、月の作業報告の手順・方法など）を作成し可視化。
  ・組合せテストを顧客環境で実施していた。バックアップ取得、環境構築、テストデータの作成、テスト実施、エビデンスの取得方法、テスト観点などをまとめた。

[その他]

• 初期システム開発リリースし、その後の追加エンハンス開発も終了。保守フェーズに入って数年経過しているシステムにPMとして参加。
• パッケージに Dynamics CRM を使用していたシステムの保守を引き継いだ。

酒造メーカー業務システム保守・運用

[概要]

酒造メーカーの業務システムを保守し機能追加。

[技術]

• COBOL、CORAL（汎用機。COBOLを日本語でコーディングするイメージの言語）
• ADM（RDB）

[規模]

5名

[役割]

担当、PM（後半2年）

[担当での役割]

詳細設計：詳細設計書作成
製造：スケジュール作成、コーディング
単体テスト：スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
組合せテスト：スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正

[PMでの役割]

• 顧客要望確認、基本設計～組合せテストを実施。総合テストのみ顧客が実施。
• スケジュール作成、設計書作成、コーディング、チェックリスト作成、テスト実施、リリースまでほとんどの作業を実施。
  ・課金処理、端末追加などの顧客対応。顧客要望の確認と定義グループへの要望をまとめていた。実際の定義は定義グループが実施。

[PR]

• PMとしての後半2年は大きな追加要望開発がなくなり、人員削減され１人で運用・保守していた。追加要望があると仕様確認、設計、実装、テストを一人で実施。
• 入社時より汎用機での開発を担当してきた。アセンブラの低級言語も扱ってきた。
• 汎用機での開発では制御系に携わったこともある。OSに近い部分であったため、そのOS自身でのデバッグができないため、他のOSテストデバッグを使用してテストを実施した経験がある。

[その他]

• 既存の機能への機能追加がほとんど。画面処理のプログラムだと１本5,000Step以上のものも多かった。現状の動作や追加することでの影響を良く確認して作業した。

ヘルスチェックシステム開発

[概要]

TCP/IPソケットを使用し、他システムの稼働状況を取得・監視、他システムへのコマンド支持を行うシステムの開発。

[規模]

5名

[役割]

詳細設計：詳細設計書作成
製造：スケジュール作成、コーディング
単体テスト：スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
組合せテスト：スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正

[その他]

• システム起動時に立ち上がり終了時まで動作するデーモンとしての処理も作成した。
• デーモンとして行う処理、signal処理、syslogなどの知識を習得できた。