技術に尖ったエンジニアでありたい。
技術に尖っていたい。
何が問題 / 課題なのか、何を解決すればよいのか、
解決すると何が嬉しいかを意識していく。
技術で、世の中の何か少しでも便利 / 快適になれば嬉しい。
機械学習 / AI に興味があり、関わりたい。
機械学習 / AI は、これから世の中を変えるインパクトがあるはず。
生成系のAIを使用すると効率が上がるが、任せてよいところ、人がもっと介入しないといけないところがあると感じる。
うまく使っていきたい。
DQM(Data Quality Monitor)システム:
AML(アンチマネーロンダリング)でチェックした状況を可視化する。
やり取りした電文に対し、どのくらいチェックできているか、どのくらいチェックでエラーになっているかを把握するためのシステム。
・Tableau
・JP1
・Oracle
・GitLab
・Jira
10名
・顧客要望によるダッシュボードの修正 / リリース
・フローの修正 / 改善
・ドキュメント整備
現在、一部のフロー一覧しかない。運用に必要なドキュメントの候補を挙げ、整備中。
現時点で必要と感じているドキュメント
・フロー一覧(全量)
・データソース一覧
どのデータソースが、どのフローで作成 / 参照されているか、どのダッシュボードで参照しているかなどを含め記述予定。
障害やデータ遡及時に、どこのダッシュボードに影響があるかの調査が迅速にできる。
顧客からの問合せがダッシュボード起点になる。
ダッシュボードの参照しているデータソースから、問題がどこにあるか、あたりをつけやすくするため。
・ジョブフロー図
データの品質基準は4種類ある。
どのテーブルを基にどのように作成しているか、
フローの流れやデータの流れ全体を俯瞰できる資料がない。
障害発生時や顧客問合せ時に調査のあたりをつけやすくするため。
・フロー障害発生時のリラン手順
障害発生ポイントにより、単純リランではNGのケースがある。
現状、フローでの障害発生時、どこから、どのようにリランすればよいか確認に時間がかかる。
障害発生条件(おもにどのフローで発生したか)によって、障害対応を迅速 / 正確に行えるようにするため。
・フローの詳細(ドキュメントで起こさず、フローのコメントに記述することで代用予定)
・MX対応リリース後の整理
・MX対応の1次開発分をリリースした後の、不具合 / 問題点の整理、推進。
本開発~リリースには参画しなかった。
が、色々な問題が発生したため、問題点を整理し、解決を推進していく。
・問題点の現象、原因、対策、対策状況の整理。
・上記より原因分析し、類似見直し観点や範囲の策定。
現行の運用で以下のような課題がある。
・Tableauのフローで異常終了すると、リランが複雑で回復まで時間がかかる。
その場その場で確認するので、ミスが発生しやすい。
・フローが複雑で全体の見通しが悪い。現状の動作を把握しづらい。
改善するためにも現状把握をする必要がある。必要となるドキュメントをあげ、作成することを提案している。
時価評価システム:
徴収した保険料や支払った保険金などから、将来どのくらいの保険金が発生するのか、CSM(マージン)がどの程度あるのかなど予測するシステム。
予測のために実績を集計している。集計したデータを経理部に渡し、損益計算書と貸借対照表の元データとしている。
IFRS(イファース)に対応するために、前システムをリプレース。
2025年に本番予定。
システムの開発は別ベンダが担当で、初期開発 / フェーズ2、3の開発が完了している。
テストを4段階で予定しており、これから3段階目の顧客テストを実施する。
2段階目のテスト終了後から参画。
4名
本番をいい形でむかえれるよう、顧客と必要なことを調整し進める。
・JP1ジョブの登録・実行などの管理
・内部統制(J-SOX対応)会計監査用チェックリストの作成
・開発ベンダが作成したドキュメントや、テストケース、テスト結果エビデンスのチェック
・データの復旧
・リリースの準備や申請
・問合せ対応
・他
2021年7月より、Salesforceを主軸とした受託開発ができるチームを造るための事業に参画。
案件が取れておらず、学習や社内業務が主。
1.Trailhead やセミナー参加で学習し、スキルの向上・資格取得。
2.工数算出の検討他
①学習塾システムを、Salesforceで実装した場合の工数算出方針の検討
提示していただいた資料:
・ER図
・DBレイアウト
・画面設計書(レイアウト、項目、アクションはあるが、処理詳細はなし)
・バッチ処理一覧
方針:
上記の資料を提示していただけた。しかし、システム構成図、業務フロー、機能一覧など、全体を把握できるものは少なかった。
下記の方針とした。
・DBレイアウトからおおよそのテーブル数を仮定し、Salesforceでのテーブル数=オブジェクト数と仮定
・1テーブルに1画面があると仮定(テーブル数=画面数)
・画面設計書(約700画面)から200画面をピックアップし、下記で算出
※参照系・更新系か、マスタ管理か請求などのコア業務かなど、バランスを考えピックアップ
・項目数で大・中・小を分類し、それぞれの割合を算出
・アクション数で難・中・易を分類し、それぞれの割合を算出
・項目数とアクションによる分類で、それぞれどのくらいの工数とするか仮定し、割合から工数を算出
②ApexでSalesforce⇔kintone連携を実装した場合の工数算出
以下のように工数算出を進めた。
・接続方式をRESTと仮定
・シーケンス図を作成し、処理の流れや障害発生個所の把握
・連携に必要となる管理項目の検討
・必要な機能を検討
・検討した機能間の各処理で、同時起動しないための制御
・連携処理とユーザ入力の排他制御
③API参照名の項目名辞書の方針整理
主に使用するのはキャメル式 (Salesforceの標準項目がキャメル式)or スネーク式なので、API参照名は2つに対応させる。
項目の意図と、どの案件で使用しているかのプレフィックスも付加するようした。
・辞書の項目を以下のように決定
・項目名
・よみ(ひらがな)
・項目の意味、意図
・API参照名(キャメル式、スネーク式の両方もつ)
・略称名
・プレフィックス(共通 or 案件固有)
・運用ルールの策定
・案件ごとの方針決定:
プロジェクト開始時点で、顧客にこだわりがあるか確認、なければ合ったものを決定(プレフィックスや命名方式)
・項目名の決め方:
基本は英訳する。基本は翻訳を使うが、検索して意味に沿っているものを探す。
・辞書への追加・更新・削除方法
・辞書の場所:
検索できれば運用できそうなので、操作の軽い Confluence にする。
ただし、フィルタリングやソートする場面が多ければ box + excel に変更予定。
3.以下のような社内業務の整備など。
・メンバーが日々どういった業務に何時間従事したかを分析するための、作業票の分類の整理
・IPAの「DXアセスメント指標」を、お客様に回答していただくための翻訳や項目の整理
弊社でフルスクラッチで開発した下記「家電修理コールセンターシステム」をSalesforceに移行することになった。現行システムのユーザ側有識者としてプロジェクトに参画。
要件定義~総合テスト、運用テスト、移行設計、移行
要件定義~総合テスト、移行設計
・開発ベンダからの現行機能の調査依頼に対する回答。主に画面処理、バッチ処理の概要やテーブル定義項目の使用方法、設定値、設定箇所の調査など。
・業務フロー、ER図、機能一覧のチェック。
・オブジェクト定義、画面処理設計書、スクリプト設計書(バッチ処理)、帳票設計書、他システム連携フォーマットなどのチェック
・期間中で、現行システムで新たにエンハンスした内容を開発ベンダへ連携。
・oracle テーブルをSalesforceオブジェクト移行のマッピング。データの抽出クエリ作成。
・CTI(iCTNET、ライトニングFAX)とSalesforceの連携で、連携方式や役割分担を提案。
・責任分界点を分かりやすくするためにDMZに連携サーバを置いた。
・Salesforce(Dataspider)側から定期的に取りくる。FAXで受けたものをケースとして取り込むという方式。
・現行システムから新システムで変更になる点や、現行システムでのポイントとなる機能を整理。
整理した点
・いつまでECが主導で、いつからSCが主導となるかが曖昧。
受付完了でECからSCに責任が移るタイミングがはっきりしていなかった。対応する拠点が決まった時に受付完了とした。受付完了することで、それ以降はSCが主導となるように決定。
・オペレーションの複雑化
現行システムでは、1つの画面のオペレーションで登録ができた。新システムではオブジェクトごとに画面から登録する必要がある。どの情報がどのオブジェクトにあり、どこから入力するか理解していただいた。
・ポイントとなる処理の品質向上
・早期の段階から開発ベンダに促し、現行の処理をよく理解し設計してもらうようにした。
・影響の大きい処理・複雑な処理は、設計書を複数回レビューした。設計段階である程度の品質を確保。
・移行元システムの開発ベンダであったが、顧客からの要望で参画。
・当初は設計フェーズのみの参画予定だった。新システムの仕様も把握したため、本番移行まで必要としていただけた。
・通常は開発ベンダ側で参画するが、ユーザ側という貴重な経験ができた。ユーザ目線で考えれるようになった。
このプロジェクト詳細は公開されていません
家電修理のコールセンターシステムをフルスクラッチで開発(フロントのCRM部分)。
フェーズ1:基本設計~総合テスト
フェーズ2:機能追加
約100Kstep(全体:150Kstep)
15名(全体:30名)
コールセンタ拠点数:2拠点
オペレータ数:約500名
PL
家電修理のコールセンターシステムのバックエンド部分をフルスクラッチで開発。バックエンド部分のサービスセンタ(修理を実施し売上請求など)向けの開発で、担当はバッチ処理。
フェーズ1:基本設計~総合テスト
約80Kstep(全体:400Kstep)
8名(全体:35名)
拠点数:約100
サービスセンタ作業者:約1,500名
PL
上記システムCRMのCTI部分を CTStage(沖電気製)から iCTNET(日立製)への変更および老朽化に伴うシステムリプレース。(oracleのバージョンアップなど)
要件定義~総合テスト
約15Kstep
5名(全体:20名)
コールセンタ拠点数:2拠点=>6拠点
PL
上記1~3での各工程での役割
要件定義:基本的にはシステム老朽化に伴うリプレースであったが、CTStageからiCTNETに変更することでのメリット、デメリットを提示。顧客の以前からの要望で、CTStageから変更することで実装可能になる機能などを提案。
基本設計:基本設計書の記述、レビュー。
詳細設計~組合せテスト:
上記システムの維持保守し機能追加。
5名
PL、PM
詳細設計~組合せテスト
詳細設計:詳細設計書作成
製造:スケジュール作成、コーディング
単体テスト・組合せテスト:スケジュール作成、チェックリスト作成、テスト実施、プログラム修正
上記で対応した案件が、問題点が多く再開発となり、Manager部分のPLとしてプロジェクトに参加。
基本設計~総合テスト
基本設計:スケジュール作成、基本設計書作成、レビュー
詳細設計:スケジュール作成・進捗管理、詳細設計書レビュー
製造:スケジュール作成、ソースコードレビュー
単体テスト・組合せテスト:スケジュール作成、チェックリストレビュー、テスト実施、プログラム修正レビュー
総合テスト:チェックリスト作成、実施、バグ票管理。
PL
保険会社様CRMシステムを保守し機能追加。
ホストと連携しデータ蓄積、オペレータが参照、帳票出力するシステム。
2名
PM
詳細設計~組合せテスト(要件定義、基本設計、総合テストを顧客にて実施)
詳細設計:詳細設計書作成
製造:コーディングレビュー
単体テスト:チェックリストレビュー、バグ票管理、品質評価
組合せテスト:チェックリスト作成、テスト実施、バグ票管理、品質評価
酒造メーカーの業務システムを保守し機能追加。
5名
担当、PM(後半2年)
詳細設計:詳細設計書作成
製造:スケジュール作成、コーディング
単体テスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
組合せテスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
TCP/IPソケットを使用し、他システムの稼働状況を取得・監視、他システムへのコマンド支持を行うシステムの開発。
5名
詳細設計:詳細設計書作成
製造:スケジュール作成、コーディング
単体テスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
組合せテスト:スケジュール作成、チェックリスト作成、バグ票管理、プログラム修正
・問題点 / 課題管理
・リスク管理
問題点の状況を共有できる状況にする。
解決しないといけない問題点の状況や、未解決問題の把握。
次工程に影響のあるものは解決(もしくはいつ解決するか目処をたてる)するが、
影響のないものは、リリースまでに解決するのか、課題として管理すればよいなどの色付け。
問題点をいつまでに解決しなければいけないのか期限、優先順位、担当、進捗状況など。
顧客向けと内部向けと2つで管理していた。
2重管理になるのは良くない。
が、顧客に関係ないものや、伝えたくない内容のものがあるため。
プログラムの内部的な作りなど、顧客に伝えてもあまり意味を持たない。
抜け漏れがないように、まずは内部向けに、内容によって顧客向けに記載していた。
致命的でなく、見直し範囲が広いものなどの扱いに困ることがあったりした。
(操作方法や、統一性がないなど)
問題点としてあがると、できるだけ早く解決したいし、フォローが入る。
修正しないといけないものの対応を優先し、
ある程度品質が確保できる組合せテストの後半で実施した。
品質管理
開発したアプリケーションの品質を上げ、リリース可能な状態にする。
・発生不具合の分析、類似見直しの策定を実施。
発生した不具合の原因、対策、直接原因、間接原因などから、類似見直しを策定し実施した。
規模の大きい開発の時、単体テストのバグもそれなりの数が出る。
そのため、発生した問題を修正した方に類似見直し~実施をしていただいていた。
が、個人によってかなり差異が出た。
慣れていて大丈夫な方のは軽めにチェック、慣れてなさそうな方の分を細かく見るようにした。
(とくに類似見直しの観点、範囲)
・品質評価、品質向上施策の策定~実施
工程後半で品質評価、状況により品質向上を実施した。
(単体テストや組合せテストで実施することが多い)
品質評価で、以下苦労した点。
・不具合発生時、バグ表に現象、原因を分類するためのコードがあり、使用して分析した。
が、コードの振り方が、個人により差異があるのが分かった。
結局、1つづつ不具合を見てコードを振り直した。
・単体テストでは、単純ミスのコードが多く振られていた。
(確かに、単純なミスのものが多かった。)
単純ミスだと分析できないので、極力別のコードに振り直し単純ミスを使用しないようにした。
・AI / 機械学習 / 深層学習
・プロンプト(生成系AI)
・テスト自動化
・クラウドを使用した開発、コンテナ、コンテナオーケストレーション
・顧客から感謝されている。
・興味が持てる業務に就ける。