ID:32924さん

## プロジェクト概要 - **ターゲット**: NFTを適正価格で売買したいユーザー、NFTを購入したユーザー - **特徴**: NFTを通常のマーケットよりも高い価格で売ることができるプロトコル - **期間**: 1年半 ## チーム構成 - **Backend**: 4名 - **Frontend**: 2名 - **自身の役割**: 開発リーダー ## 開発環境・ツール - **Frontend**: Angular.js - **Backend**: Go Cosmos-SDK - **Infra**: Vultur, AWS EC-2 - **タスク管理**: Notion - **デザイン**: Figma - **ドキュメント**: Notion - **CI/CD**: GitHub Actions, 自作CI ## 開発手法・プロセス - **手法**: アジャイル開発 - **プロセス**: 週次同期ミーティングで各自のタスクを確認し、優先度を調整してタスクをこなす ## 工夫・取り組み - アサインされた当初は各々で開発していたため、週次同期ミーティングを設け、2日に1回メンバーとの相談時間を設けたことで、メンバーの情報格差が減り、開発効率が向上した - 暗号通貨業界の流れが速いため、週次同期ミーティングで優先度を都度変更し、ユーザーに最もインパクトが高い機能から開発を行った - 理論や仕組みが難しい部分は、詳しいメンバーに情報共有を依頼した - チャット上でのコミュニケーションは英語を主に使用し、時折日本語も使用した（海外のメンバーがいたため） - ミーティングは日本語 ## 成果・影響 - **開発部分**: デバッガーの設定、CIサーバーの設置、デプロイ環境のデバッグ手法の改善 特にデバッガーの設定は、インターネット上に情報がなく、画期的な成果であると考えています。 - **マネジメント部分**: 週次同期ミーティングやメンバー相談時間を設けて開発効率の改善を図った。また、メンバーが理解できない部分に対して技術的なサポートを行った。 マネジメント面: 個人の力を尊重し、ドメイン領域ではメンバーの誰かが必ず自分より優れていると考えた。これにより、メンバーが自分の強みを活かし、プロジェクト全体が円滑に進んだ。 ## まとめ 1.5年間にわたるNFT取引プロジェクトにおいて、開発リーダーとしてチームを統括し、アジャイル開発を採用してプロジェクトを遂行しました。 週次同期ミーティングやメンバー相談時間の導入により、開発効率が向上し、急速に変化する暗号通貨業界に対応する開発を行いました。 技術面ではデバッガーの設定やCIサーバーの設置など、革新的な成果を出しました。 マネジメント面では、各メンバーの専門性を尊重し、適切な役割分担を行いました。

# 使用した技術 **Nodejs：** ファイル操作などでを実装 **InnoSetup:** インストーラー作成に使用 **electron:** メインフレームワークとして使用 **Jenkins:** プロジェクトのビルドシステムとして使用 **Docker:** Jenkinsサーバーを立てるために使用 # プロジェクト詳細 - 業務用の写真を管理するデスクトップアプリを作成しました > メインフレームワークはelectronを使用し、自動テストにはAVAを使用した。 - 開発体制 - 日本 - オフショア # 私が主に担当した機能 - インストーラー > 設計、コーディング、テスト、運用 - 前バージョンのデータのマイグレーション > 要件定義、設計、コーディング、テスト運用 - バックアップ機能 > 要件定義、設計、コーディング、テスト運用 # インストーラー プロジェクトの成果物をユーザーの環境にインストールし、レジストリに指定ファイルクリック時の挙動や、特定のデータ、拡張子への画像の紐づけなどを行う ## 技術的な詳細 インストーラーはInnoSetupをを使い、拡張子の関連付けやクリック時の挙動などの動作はフレームワークの機能使って実装しました。 言語がPascalということとあまり、情報が無いため、実装には苦労しました。 Signやコンパイルを呼び出す動作はNodeで実装し、npmモジュールを使い、特定の環境に依存しないスクリプトを実装しました。 Signファイルやパスワードなどはソースに書いてはいけないため、対話式のスクリプトにしました、 また、自動化すると対話式だと問題があるので、引数に対応し、自動化した時にも動作するような構造にしています ## 問題 ### ビルドに時間がかかる 当初Nodejsに対する知見が浅く、ビルドはそれぞれのアーキテクチャで行いました。 特に32bitのビルドマシンはスペックが悪くビルドに1時間前後かかっていました NodeやNodistの情報を集めハイスペックなビルド用マシン1台ででそれぞれのアーキテクチャでビルドを行えるようにしました ### インストーラー容量の問題 InnoSetupではインストールを行うときに、容量不足でもユーザーがインストールできる問題がありました。 InnoSetupではインストールサイズの取得はできないため、Pascalでフレームワークの画面情報を取得しインストールサイズ取得後、画面制御をPascalを使って行いました。 ユーザーの要望でこの実装は無くなりましたが、リファレンスには無い情報などを調べ、応用して実装したのでとても苦労しました ## InnoSetupについて ### メリット 無料です。 メンテナンスされています フレームワークを理解すると比較的簡単に実装ができます ### デメリット 機能として提供されていないことをしようとするとPascalで記述しなければならない(難易度が高くなる) リファレンスが読みにくい 日本語の情報が少ない ## その他 ### 拘ったポイント 最新のソースですぐにビルドできるようにバッチファイルを作成し、半自動化まで対応しました。 JenkinsとDockerでビルドシステム構築、自動でチェックアウトからビルドの自動化しました ビルドスクリプトはアーキテクチャに依存しないように実装しました # 前アプリデータのマイグレーション 前アプリは違うデータ構造な為、新しいデータ構造に対応するような機能を実装しました ## 技術的な詳細 前アプリからデータを読みださなければならないところから始まりました。 読みだす部分はC+を使って実装し、それをNodeから制御しました。 前アプリデータのドキュメントも無いため、データの解析から始まり、データの吸い上げを行いました。 私がアサインした時はデータの吸い上げまで終了しており、新データ構造の整形を対応しました。 前データのドキュメントが無いため、バリューの担保が失われる事が多々ありました。 自動テストはAVAで実装しカバレッジは80％を担保しました。 Nodeの処理としては - ファイルコピー - ファイルリード、ライト - ファイルのメタ情報取得 - 不完全なXMLデータのパース - ファイルヘッダの識別 - C+構造体の解析 C+の処理としては - 独自XMのパーサー - 不完全iniファイルのパーサー - エラーハンドリング - データベースからの情報取得 ## 問題 ### 性能 要件になかった性能について問題になりました 機能別でPromise並列実行し同じ機能でPromise並列実行をしたところ、30倍まで早くなることができました。 特に機能別並列Promise実行は制御が難しく32bitOSでも動くことを考慮しなければならなかったので、nodeのオプションを使いメモリ消費量やメモリーリークが無いかなど何度も調査しました 機能別並列実行はボトルネックの部分の処理を常に動かし続けるように制御しました。 メモリ消費量を気を付けながら実装だったので、単なる並列実行をするのではなく、メモリにデータが乗るのを次のループまでの情報までにしボトルネックの処理部分を常に動かし続けました

# 概要 センサーデータを可視化して表示するシステム # 担当 1. 要件定義 1. 外部設計 1. 内部設計 1. 実装 1. テストコード実装 1. テスト設計 1. テスト # 使用技術 1. Laravel 1. Vue # 課題 プロジェクトにアサインした時点では、ある程度システムはできておりました 1. オフショア開発をしており、舵取りが上手くいっておらず内部のコードは、そのフレームワークの思想に基づいていない実装になっていない 1. オフショア開発の品質が悪くコードレビューしていない 1. モダンな開発環境ではない(手順書に基づいて各ソフトウェアをインストール) # 取り組み 1. オフショア開発をしており、舵取りが上手くいっておらず内部のコードは、そのフレームワークの思想に基づいていない実装になっていない - 内部設計時に、オフショア開発へ実装方法を指定し、コンポーネント化やDIなどを細かく指示、コードレビューで実現できているか確認する - 実装方法が分からない、伝わらない場合は、実際のサンプルコードを提示 1. オフショア開発の品質が悪くコードレビューしていない - 実装50％の状態で、コードレビューを行い、意図した実装になっていない場合は、すぐに指摘を行う - テストコードの実装も依頼し、そのテストコードもコードレビューする 1. モダンな開発環境ではない(手順書に基づいて各ソフトウェアをインストール) - Docker compose upで開発ができるように、開発環境を作成 # 工夫した点 - 要件定義 1. 要件定義が無かったので、それを顧客へ明示的に確認し合意を形成する 1. 見積もりに基づいた要件定義へスリム化を行った。コスト的に見合わない事はPMに確認後お断りする - 設計 1. プロジェクトの構造を踏襲しつつ、ドメイン駆動設計を意識した設計 1. 顧客の次の要望に耐えられる構造にした設計 - 共通のふるまいを定義し、それを継承したモデルの設計 - 継承したモデルの具体的な処理を実装し、リポジトリクラスは共通のふるまいを呼び出すだけ - 上記を設計することにより、テストが簡単に実装しやすくなり、生産性が向上し、変更が容易になりました - 実装 1. プロジェクトの慣習を意識しつつ、技術的な負債を残さないように実装 * プロジェクトの慣習のバランスを保ちながら、採用されているフレームワークの推奨実装、構造へ徐々に以降した * 単体テストや型を明示することによって、変更しやすいプログラムへ * 適切に関数分割を行い、同じような処理が複数の関数にばらつかないようにした

# 使用した技術 **Python：** バックエンドサーバー **Vue.js:** フロントエンド **HTML,CSS,JS:** フロントエンド **C:** センサーデータ収集のために使用 **Docker:** 開発環境、クロスコンパイル環境の為に使用 **InnoSetup:** インストーラー作成に使用 # プロジェクト詳細 - 産業用ゲートウェイに接続されている機器からセンサーデータ収集しウェブブラウザからデータを閲覧できるシステム - メインフレームワークはフルスクラッチでCで実装されている - 開発体制 - 日本 # 私が主に担当した機能 - Windows移植 - 設計、コーディング、テスト、運用 - インストーラー - 設計、コーディング、テスト、運用 - 追加機能実装 - 設計、コーディング、テスト運用 - 既存機能改善 - 設計、コーディング、テスト運用 # Windows移植 ## 技術的な詳細 Linux向けに作られたメインフレームワークをWindows向けに移植する作業 メインフレームワーク内のLinuxでしか使えないライブラリをWindows相当のものに移植した ## 問題 ### Threadやプロセス関連について Linux向けに作られていたため、thread系やプロセス生成系のAPIが互換が無く、実装が難しかった マルチプラットフォームに対応している比較的大きなライブラリなどを見ながら勉強して実装を進めました Cはあまり経験がない状態でアサインされたのもあり、とても難しい作業でした ### エラーの数が多すぎて対応にかかる工数が読めない 作業着手した当初はWindows向けにビルドすると大量のエラー表示があり、それらを潰してもまた追加でエラーが発生して終わりが見えない状況でした その段階でリーダーと相談し、1週間は工数見積もりという形で作業を進めある程度目途が着いた段階で工数を見積もりました ## その他 ### 拘ったポイント Linux用の特有の機能を使い移植が難しい部分を比較的新しく実装されたWindowsAPIを利用し、新規実装せずに移植できました こちらは、Windows公式サンプルコードしかない状態で手探りの実装になりました # インストーラー プロジェクトの成果物をユーザーの環境にインストールし、Windowsサービスとしてバックエンドで動作するようにした インストーラー作成スクリプトなど含めマニュアルの表示やアプリケーションのショートカットなども作成した ## 技術的な詳細 インストーラーはInnoSetupというFWを使って作成しました 拡張子の紐づけなどがなかった為、レジストリ登録など無く比較的簡単に作成できました ## 問題 ### Windowsサービスとして登録するのはそれ専用にアプリケーションを作成しないといけない Windowsのアプリケーションは何度も作成して慣れていたのですが、今回初めてWindowsサービスとして登録し、ユーザーの操作が無くバックエンドで動かす必要がありました その場合は、CやC++などでWin32APIを使用しないといけないため工数が膨らむ可能性がありました そこまでの工数はなかった為、調査を行いWinSWというOSSを発見しました WinSWを使い簡単にWindowsサービス実装することができました 機能しないオプションがあったり、マニュアル記載通りにやってもできないなどもありましたが、ISSUEなどを見て実装しました ## WinSWについて ### メリット コーディングしなくてもWindowsサービスとして登録できるOSSです 比較的メンテナンスされています ### デメリット バージョンが混在していて動作しないオプションがあったり、ISSUEやドキュメントのバージョンなど手探りで使わないといけない場合がある

実験的プロジェクトで屋外のロールカーテンを制御するシステムを作成しました これはandroidアプリと機械のセンサーで制御できるアーキテクチャでした 私が担当したのは主に機械側(arduino)の制御です モーターや雨水センサー光センサーなどを主に制御しました 雨水センサーは自作されていたものがあり、それを実際に水にぬらしたりして閾値を取り実装しました。 光センサーも同様です。 何度も計測し、制御するのはとても面白かったです。 モーターの制御はうまくいかずとても苦労しました モーターが通常通り動かすとモーターの力で暴れて筐体への負荷が高くなりました そこでモーターを徐々に動かしたり、止めるときに惰性をつけて止めるようにしました。 これがうまくいきモーターがなめらかな動作になりました。 このプロジェクトでC言語やセンサー、モーターの制御の知見が高まりました