ID:65733さん

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー # 業務概要 ①業務指示管理システム運用、保守 ②新規プロジェクト開拓 - 期間：2023年4月ー2024年7月 - プロジェクト規模：要員3名（全体11名） - 実行環境：Azure Cloud Service　（App Service、Function、SQL server、DevOps、Logic Apps） ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 担当フェーズ SRE保守運用の開発、CSM顧客問題支援と提案 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 業務内容 - SRE保守運用の開発 - デプロイ自動化デモ作成（CI/CD、IaC） - 運用レポート作成、レポート標準化 - CSM顧客問題支援と提案 - 既存削除バッチ（Azure Function）のリファクタリングとテスト自動化 - openAI活用した音声認識アプリケーションデモ作成 - グルプウェアシステム移行 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 課題と成果 - システム性能改善: 2年分のデータを削除するバッチを開発。データベース容量を削減し、システム性能を改善。 - 自動化推進: Azure DevOpsを用いたIaCデモを作成し、テスト自動化の重要性を啓蒙。運用レポートの自動化アーキテクチャを提案。 - 新規事業創出: 音声認識デバイスとopenAIを組み合わせ、新たなソリューションを提案。 ## -----------------------以下課題と成果の詳細説明----------------------- ### ①システム性能改善 - 【背景】 システム運用から2年を経過し、データベースの容量はお客様と契約した上限に迫った。システムの削除バッチは稼働履歴がないため、起動前の整備が必要となった。 - 【対策と工夫】 - システムの開発が続いているが、削除バッチの整備が停滞したため、まず削除対象となる関連機能の依存関係を明確にした。 - ネスト化になったSQL文の分析を行い、単純なSQLに修正と重複ロジックの共通化に努力した。 - データ削除の正確性を証明するため、ロジックの依存関係を基づいたストアドプロシージャを構築し、テストを自動化にした。 - 本番同等なテスト環境を構築し、各削除条件のSQL server性能監視レポートを作成した - SQL serverの性能を担保したリリースシナリオの作成と実施を行った。 - 【成果】 2年間に貯め続いている8000万件を超えたデータから、新旧登録ロジックを配慮した削除バッチのリリースができた。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ②自動化推進 - 【背景】 システム運用から、機能修正と保守業務が山積み、新規開発と技術のキャッチアップができなくなった。 - 【対策と工夫】 - デプロイとテストが手動ベースになったため、テスト自動化にアプローチする。Azure DevOpsを用いたIaCデモを試作し、開発チームにフィードバックした。 - 運用レポートの作成手順を平準化し、自動化アーキテクチャを提案した。 - 【成果】 - テスト自動化とテストコードの重要性を社内に喚起ができ、Teamsチャットbotでデプロイ自動化ツール開発の発足ができた。 - 外部ツールを連携したレポート自動作成アーキテクチャから、自動化とセキュリティー両立に関する議題に発展し、ソリューションチームと保守チームの認識齟齬の軽減に繋がった。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ③新規事業創出 - 【背景】 他部門の主力製品、音声認識デバイスが特定領域に特化し、汎用性な運用に壁打ちした。 - 【対策と工夫】 - オフライン環境に抗雑音のような特定の領域に展開となり、アプローチできる業界が限らる、汎用性があるOpen AIと融合するアプローチを試みした。 - 他部門の連携となるため、デバイス技術とクラウドサービスの知識交換をし、製品のコンセントを理解してからイノベーションを創出するように意識をした。 - 現場での測定データ記入作業にAIを導入した。 - 現場のフォーマットを参考した回答テンプレートを作成し、AIの揺らぎがある回答をテンプレートで制限することで、データ収集せずでも、音声から正確性が高いフォーマット記入デモを作成した。 - 【成果】 セキュリティー重視と音声認識率が高い特徴を持つ音声デバイスの特徴を活かし、AIを情報整理の役割にイノベーションを創出することで、セキュリティー重視する現場とクラウドサービスの活用例を求めるお客様に向け、どちらでも提案ができる材料になった。 ## -----------------------ここまで詳細説明の内容----------------------- ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー # プロジェクト概要 お客様に長年サポートしたPortalサイトがバージョン切れを機に自社製品の業務指示管理システムに移行する - 期間：2021年10月ー2023年4月 - プロジェクト規模：要員7名（全体11名） - 実行環境：Azure Cloud Service（AppService、Azure Function、Azure SQL server） ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 担当フェーズ CRM顧客関係管理（上流工程） ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 業務内容 - テスト設計、実施 - システム全般の結合テスト設計、実施 - システム一部のシステムテスト設計、実施 - Azure Application Insight活用、システム監視 - 新規案件開拓 - 拡張機能設計と開発マネジメント - お客様の要件を定義し、社内の技術者にアウトプット - WBS管理 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 課題と成果 - テスト駆動開発推進：眠っていたシステムをテスト駆動で喚起し、属人化軽減を実現 - 案件開拓：繰り返しの定例会議と提案活動で、開発案件を獲得 - 既存機能拡張：既存機能からテンプレート、署名機能を追加し、短期かつカスタマイズされた機能のリリースを実現 ## -----------------------以下課題と成果の詳細説明----------------------- ### ①テスト駆動開発推進 - 【背景】 システムの開発は外部会社に下請けで構築した、長年触っていないシステムは特定な有識者しか仕様把握しないため、システムのあるすべき姿を理解出来ない。仕様が属人的なものとなり、機能修正するたびに、仕様の検討が討論や打ち合わせとなり、開発効率が低下した。 - 【対策と工夫】 - 設計書がなくても先にテストを設計と実施を行うことで、有識者と技術者のギャップを埋めた。 - このような状況で、関連した機能の一連を優先に考量しテストシナリオを作成した、その後、単独な機能テストの内容をシナリオごとに分散しシステム全体の網羅性を高めた。 - 基本設計書に基づいたテストケースを作成することにより、誰でもテストケースに沿ってテストができることでテストの平準化が出来、品質指標になった。 - 【成果】 品質指標が可視化するプロセスを構築した結果、お客様との定例会議にリリース前、後の品質報告が定期的に行えるようになり、お客様に安心材料のご提示ができた。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ②開発案件開拓 - 【背景】 受託開発の依頼は一段落になった見込みがあるため、開発案件の開拓が必要となった。 【対策と工夫】 - 以下三つの方法から提案材料を生み出した。 ①技術者（保守と開発）からのフィードバック ②お客様の要望確保 ③営業からのヒアリング - 提案材料から新規案件を取得目標数より多い提案書を作成した。 - 提案書の技術検討を社内外の技術者と打ち合わせを行い、提案書に絞り込んだ。 - お客様に提案とフィードバックの整理をした。 - 提案を繰り返し実施し、提案プロセスを構築した。 - 【成果】 定例会議にお客様に新規機能のアプローチをし続けた結果、テンプレート、署名機能が便利な意見を引き出すことができ、新規機能の追加案件を受注した ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ③既存機能拡張 - 【背景】 運用している業務指示システムから新規機能追加案件を受注した。 - 【対策と工夫】 - お客様の要望をヒアリングができた直後、既存機能から拡張したUX設計を社内にフィードバックした。 - 基本設計書に画面遷移図とフォロチャートを追加することで技術者との会話を可視化に意識した。 - 社内技術者とお客様の斡旋で、開発前から認識齟齬の軽減に意識した。 - 開発のスケジューリング、WBSの調整をした。 - 【成果】 動的に技術とお客様の要望を合わせることで、既存指示の種類を選択するカテゴリ機能から、テンプレート、署名機能を追加し、短期かつカスタマイズした機能のリリースができた。 ## -----------------------ここまで詳細説明の内容----------------------- ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー # プロジェクト概要 早朝、深夜の時間帯にタクシーを利用する特殊な状況の中、コストと勤怠管理をDXする要望により、社内の業務指示システムから発展したサブシステム開発 - 期間：2020年4月ー2021年10月 - プロジェクト規模：要員6名（全体9名） ・実行環境：Azure Cloud Service（AppService、Azure Function、Azure SQL server） ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 担当フェーズ - プログラマー（下流工程） - 保守サービス ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 業務内容 - 利用者の打刻機能の詳細設計、実装、結合テスト設計、実施 - タクシー配車画面の詳細設計、テスト、結合テスト設計、実施 - Eclipse統合開発環境構築、機能実装、GitLabのコード管理 - テスト仕様書の作成 - 定期的な実績データ取得、データ分析によるお客様課題解決 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ # 課題と成果 - 未経験からプロジェクト参入：積極的なアプローチ、チームメンバーとの繋がりを深めた - 開発の取り込み：仕様書の深堀、不具合を事前に防いだ - 納期が間に合わない：タスクの優先度付けで、柔軟にタスクの共有ができた - 保守サービスの取り組み：保守プロセスを平準化により、問い合わせ対応効率の向上に繋がった ## -----------------------以下課題と成果の詳細説明----------------------- ### ①開発未経験から、プロジェクト参入 - 【背景】 学生時代にC言語などを触れたことはあったが、システム開発の経験はゼロ - 【対策と工夫】 - 自分で解決できない問題に直面したとき、伝わりやすいように問題を共有した。 - 自分が困っていることを文章に直し、整理してから質問した。 - 常に質問、仮説をリストアップし、タイミングがよい際に質問、検証をした。 - アウトプットで自分の勉強を深めるため、質がよい発信をし続ける勇気を保つ。 - 自分の情報を検索する方法にフィードバックを求めた。 - 【成果】 質問をよく行うことにより、プロジェクトメンバーに受け入れられ、社内外に限らず、業務委託の方とも良いコミュニケーションをとることができ、外部パートナーとの信頼強化にも繋がった。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ②顧客にとっていいプロダクトを作るための取り組み - 【背景】 初めての開発に、どのようにいい製品を作るか模索中 - 【対策と工夫】 - 自分が納得できていないままでは、いいプロダクトが作れないと考え、システムの仕様を深掘り、予想できる課題を洗い出した。 - システムや仕様などを深く考えることで、起こり得る問題などをリストアップすることが出来、それがいいプロダクトにつながるし、効率的にコーディングができた。 - 【成果】 お客様の便利性を考慮した機能が実現でき、コーア機能の安定稼働に繋がった。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ③納品期間が短い中、柔軟な対応が迫れる - 【背景】 予定していたスケジュールが遅れ、予定とした自分が実装する部分は外部リソースを投入により、引き継ぐ状況に迫れる - 【対策と工夫】 - なるべく早く詳細設計を作って社内の人にレビューしてもらうように意識をした。 - 1から10まで設計書を埋めていくと間に合わないため、優先順位を付けし、重要な部分を早期に記載し、レビューを優先にした。その結果、時間の短縮ができ、期日通りに引き継ぎができた。 - レビューを通して分からないところを徹底的に潰し、仕様や注意点を理解できた。 - 設計書に冗長な部分を削減し、新しい設計書フォーマードを提案した。 【成果】 既存設計書フォーマード再設計、作業効率向上に繋がった。 ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～ ### ④システム監視作法を試行錯誤 - 【背景】 システム開発に関して初めての保守サービス運用のため、保守プロセス構築するが必要 - 【対策と工夫】 - 保守対応に関するドキュメントやマニュアルがなかったため、運用が属人化、非効率と気づいた。 - 自分自身の作業効率化、作業の平準化を意識し、他の人も作業できるように、Azure Application Insightのログ監視方法、問題の対応方法などをドキュメントにまとめた。 - 【成果】 平準化によりログの設計に欠陥があることを発見、既存システムのログ再設計、及び、問い合わせ対応効率向上に繋がった。 ## -----------------------ここまで詳細説明の内容----------------------- ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー # プロジェクト概要 GNU bash(v3.2)をシミュレーションしたminishellを実装 - 期間：2023.1~2023.02 - 規模：2名 - 言語：C # 担当フェーズ - シグナルハンドラー、ビルドインコマンド実装 # 工夫&成果 【工夫】 - シェル動作の整理とドキュメンタリー - シグナルハンドラーのデザイン（シグナルによる子プロセス管理） - 環境変数とビルドインコマンド（echo, cd, pwd, export, unset, env, exit）実装 【成果】 - ドキュメントの共有でチームメンバーとの意思疎通を図った - GNU bash公式サイトと動作確認を重ねてサービスの分析能力を培った - コマンドの仕様に必要なデータ構造設計、要求を明確ができ、パーシングを担当メンバーとの分担、並行設計を遂行 # GitHub > https://github.com/minishellakirawchen/minishell_rev1/edit/main/Readme.md # 実装概要 - 新しいコマンドを待っているときにプロンプトを表示する。 - プロンプト履歴保存 - PATH 変数に基づいて、相対または絶対パスを使用して、正しい実行ファイルを検索して起動する。 - バックスラッシュ (\) 引用符で特殊文字を解釈しない。 - ' (シングルクォート) を処理し、メタ文字を解釈しないようにする。 - " (ダブルクォート) を処理し、メタ文字を解釈しないようにする (ただし、$ (ドル記号) を除く)。 - リダイレクトを実装する: - `<` should redirect input - `>` should redirect output - `<<` should be given a delimiter as here-doc - `>>` should redirect output in append mode - 演算子を実装する。 - パイプ |: 次のコマンドの入力に接続する。 - 環境変数 ($ の後に文字のシーケンスが続く) を処理し、それらの値に展開する。 - $? を処理し、直前に実行された終了ステータスを展開する。 - ctrl-C、ctrl-D、ctrl-\ を処理し、インタラクティブモードでの bash と同様に動作する: - ctrl-C は新しい行に新しいプロンプトを表示する。 - ctrl-D はシェルを終了する。 - ctrl-\ は何も行わない。 - 以下の組み込み関数を実装する: - echo オプション -n 付き - cd 相対パスまたは絶対パスのみ - pwd オプションなし - export オプションなし - unset オプションなし - env オプションまたは引数なし - exit オプションなし

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー # プロジェクト概要 ブロックチェンのハッカソンに参加し、ブロックチェンを一般消費者に普及するイノベーションを創出。 スマートコンストラクトで第三者を経由しないEscrow仕組みを実現 - 期間：2024.9（2ヶ月間のハッカソンだが、残り25日間の時点で参加） - 規模：5名 - 言語：Rust、JavaScript、TypeScript - 提出物：pitch deck、プレゼン動画、Xアカウント、トラクション実績 # 担当フェーズ - プロダクト・プロジェクトマネージャー # 工夫&成果 【工夫】 - チームメンバーが全力疾走できるように、チームメンバー各自のビーションを聞き出し、志が共有されることを優先し、意見を言い合える関係を構築 - 開発テーマの導きと検証の繰り返しでビジネスモデルを創出 - アンケート設計しサービス料金の計算を試み - 役割、WBS、マイルストーンを開発前に明確に定義し、ビジネスモデル創出組とデモ作成組を分けて管理 【成果】 - チームメンバーの特徴とビジョンを重視したアプローチで、初心者でもブロックチェーンのインフラ改善に挑戦し、返金保証サービスのプロトタイプをリリースした。 - 情報を収集よりも仮説を立て検証することに価値があることを実感した。 - 1週間から50通のアンケートを集め、サービスの対象となるsellerとbuyerを特定でき、客観的な料金体制を構成した。 - 明確な目的と主体性を重視した結果、プロジェクトの開始が遅れてもバッファーが残っている状態でハッカソンを遂行した。 - Xアカウント：https://x.com/JinInfra - プロトタイプ：https://jin-mu.vercel.app/ - GitHub：https://github.com/YungTatyu/Jin - Pitch Deck：https://docs.google.com/presentation/d/1fFllofGvP5lxsi75hM4dFXn6zFxNYEBKDQ7dbkIMLPQ/edit#slide=id.g2838479de40_0_32 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー