すんすけ

# プロジェクト概要 - 医療廃棄物の登録・運搬をするシステムのリプレイス案件 - WEBシステムとAndroidバーコードスキャナーアプリがある - 廃棄物収集業者がオフィスなどでWEBシステムから廃棄物やその他さまざまな設定を行う - 廃棄物収集業者が現場でAndroidのバーコードスキャナーを使って廃棄物を登録する - フリーランスとして受託開発企業に参画 - 参画先企業のチーム人数はAndroid3人、WEB5〜7人 - 基本リモートで作業（必要に応じて参画先企業のオフィスで作業） # 使用言語・フレームワーク・ツール（Android） ## 言語 - Android Java - SQL（SQLite） ## フレームワーク・ライブラリ・その他技術 - Retrofit - Rx Java - Room - Shared Preference - Gradle - Butter Knife - starのプリンタのSDK ## その他使用ツール - Git - Git Bucket - Android Studio - Redmine - Excel - Word - Skype - Microsoft Teams # システム概要・アーキテクチャ - 基本的にAndroid内にDB保持（RxJava、Room使用） - 必要な分のDBデータを加工してWeb APIで送信（jsonでHttp通信、RxJava、Retrofit使用） - Activity、FragmentからUseCaseを作成してWeb APIやDBの処理を実行 - WEB側は関わっていないのでシステム構成は分かりません # 担当業務 - Androidバーコードスキャナー旧システムの把握 - 基本設計（参画先企業が作成した要件定義書を元に仕様書を作成） - 発注元企業との調整（質問表でのやりとり、画面イメージ図・遷移図・表などの作成） - Web APIの設計（送受信パラメータの決定など） - DBテーブルの設計 - 実装（参画先企業の他プロジェクトのソースをベースに新規作成、プリンタ印刷・DB・API・レイアウト・画面動作など3/4ぐらい作成） - テスト（参画先企業が作成したテスト項目書でテスト、不具合修正） # 取り組んだ課題など ## Room - Roomを使用するのは初めてだったがGoogle公式のドキュメントを参考にし、Web系のMVCのフレームワーク（Laravelなど）の経験も生かして実装した - 複数テーブルにまたがる場合の処理は、Roomのリレーション機能などを利用してなるべくSQL実行回数を減らすように工夫した。その結果、画面表示や処理の実行速度が早くなった。 - Roomを使用するためのベース部分を参画先企業のAPIの処理と似たような形（RxJavaでUseCaseを作成する形）で作成した。狙いは、参画先企業の社員でも後で改修しやすいようにするため。 ## プリンタ - プリンタSDKの仕様を把握していない人でも簡単に再利用できるようなクラスを作成した - プリンタSDKが幅が小さい用紙（指定された用紙）に対応していなかったので、旧SDK（低レベルでバイト単位でコマンドを送る形式）と併用して右寄せ・左寄せの機能を実現した # 反省点 - 仕様書を作成するとき最初から細かい部分まで仕様を記述したが、後ほど他の画面の仕様決定などによる仕様変更で再度記述するなどしなければいけなくなり時間がかかってしまった。今後は修正が発生しそうな場所はざっくり仕様を記述して、ある程度全体の仕様が決定してから細かい部分まで仕様と記載するようにして、作業時間が短くなるようにしようと考えている。 - 参画先企業の要望で実装が短時間できるように表の部分で再利用をできるクラスを作成したが、描画に1〜2秒ほどかかってしまい遅くなってしまった。実装時間削減を狙うなら狙い通りだが、ユーザビリティを優先する場合は個別にListViewやRecyclerViewで個別に実装した方が良いと感じた。個人的には納期に余裕がある場合は個別実装をしたい。

# プロジェクト概要 - 顔認証での勤怠管理システムのAndroidアプリ - 既存の勤怠システムアプリに顔認証機能を追加 - フリーランスで受託開発企業に参画 - 発注元企業の工場で働く従業員に対して手洗い場で顔認証を行い、国籍別に手洗い解説動画を流し、出勤を記録するシステム - 参画先企業のチーム人数は2〜3人 - 基本リモートで作業 # 使用言語・フレームワーク・ツール ## 言語 - Android Java ## フレームワーク・ライブラリ・その他技術 - 顔認証SDK（オムロンのOKAO Vision、JNIでC++で記載） - Camera2（Androidの動画処理API） - Gradle - Shared Preference - Butter Knife ## その他使用ツール - Git - Git Bucket - Android Studio - Redmine - Excel - Skype - Microsoft Teams # システム概要・アーキテクチャ - 事前に登録した社員の顔で顔認証を行い、検出した社員の国籍の言語の手洗い解説動画を流して、既存の勤怠管理システムと通信を行う - Camera2を使ってカメラでキャプチャした動画をモニタに流し、さらに同時に顔認証SDKにも流して顔検出や顔認証を行う - 顔認証SDKはオムロンのOkao Vision（C++で記述されていてJNIで組み込み）を使用 - 勤怠管理システムとの連携はWindowsのSocket通信でデータ形式はXML（古いシステムだったので） - アーキテクチャは通常のActivityを作成して処理を記述する形式 # 担当業務 - 工数見積もり（一部） - 基本設計（簡単な仕様のため実装しながら要件定義書を見て設計書を作成） - 顔認証SDKのマニュアルなどでの機能把握 - 実装（顔認証SDKを使用しての顔検出・顔認証・顔登録処理の実装、Camera2での動画のキャプチャや動画加工・再生処理の実装） - テスト（テスト項目書の作成、テスト項目書による手動テスト、不具合修正） - 顔認証SDKのJNIでの組み込みや、質問表での発注元企業との調整は他の方が担当 # 取り組んだ課題など - 元々は参画先企業の他の社員が実装していたが難しくてできなかった案件。難しかった要因は、顔認証SDKが実装例や参考ソースなどがなくSDK制作元に問い合わせても答えてもらえない、動画処理を扱うAndroidのCamera2 APIもほぼ英語しか解説がないため。 - よって顔認証SDKはマニュアルをよく読む、メソッドの戻り値を確認する、まずは簡単に顔認証処理を作成する、Camera2 APIも主にGoogle公式の英語の解説をよく読むなどして、なんとか実装を完成させた。 - 性能が悪いAndroidだと処理が遅れてしまってモニタに移る映像が遅れてしまう現象が起こっていたので、現在のフレームで重い顔認識処理中に次のフレームの処理が開始する場合は次のフレームの処理をスキップするようにして、性能が悪いタブレットでも画像表示が遅れないようにした。

# プロジェクト概要 - ビーコンのパラメーター設定の設定を行うAndroidアプリ - 先行開発したiOSアプリのAndroidへの移植 - フリーランスとして受託開発企業に参画 - 発注元企業の大規模スマートシティプロジェクトの一部 - 参画先企業、発注元企業、ビーコン通信SDK提供企業の３社で共同開発 - 参画先企業のチーム人数は3人 - 基本リモートで作業（必要に応じて参画先企業のオフィスで作業） # 使用言語・フレームワーク・ツール ## 言語 - Android Java - swift（iOS版のコード読解） ## フレームワーク・ライブラリ・その他技術 - Retrofit - Rx Java - Gradle - Google Map SDK（GCPも含む） - Shared Preference ## その他使用ツール - Git - Git Bucket - Android Studio - Xcode - Redmine - Excel - Word - Skype # システム概要・アーキテクチャ - AndroidでビーコンとBluetooth（BLE）通信してビーコン本体の設定値を変更し、さらにWebAPIで設定情報をサーバーに送るシステム - BLE通信部分は他社開発のSDKを利用して通信 - Web APIはjsonでHttp通信、RxJava、Retrofit使用 - AndroidのアーキテクチャはMVP - Google Map SDKとGCPを使用して現在地の座標や住所をGoogleMapで表示 # 担当業務 - 技術調査（GoogleMap利用の調査） - 既存仕様の把握（先行開発のiOS版の仕様書やソースコードの把握、Web Apiの仕様やDB構成の把握） - 発注元企業との調整（質問表作成など） - 実装（参画先企業の他プロジェクトのソースをベースに新規作成、レイアウト・画面動作、ビーコンやWEBとの通信部分を作成） - テスト（テスト項目書の作成、手動でのテスト実施、不具合修正） - Google Playでのリリース（App Bundle、リリース用の文書の作成など） # 取り組んだ課題など - 参画先企業の要望でもあるが先行開発のiOS版と細かい部分で機能に差が出ないようにするために、仕様書だけでなくiOSのコードを細部まで理解してAndroidに移植した。 - Google Map（Android側のSDKやサーバー側のGCP）を利用するのは初めてだったが、公式サイトの説明をよく理解してコード例を参考にして実装した。 - Google Mapの仕様を把握して無料の範囲内で収まるように、発注元企業とアプリの設計を調整した # 反省点 - 参考にしたiOS版のコードが複雑だったので（機能の整理ができていない、コピペ多用などいわゆるスパゲッティーコードだったので）、Android版も処理を共通化するなど改善できる部分は改善したがコードが複雑になってしまった。あまりにもiOSのコードがひどい場合はAndroid独自に実装した方が良い場合もあると思った。

# 倉庫・在庫管理システム（Webバックエンド、Android、Windows） ## 期間 - 2021/1〜2020/8（約8ヶ月間） ## プロジェクト概要 - 棚販売会社の倉庫・在庫管理システムのカスタマイズ（ベースのソースからの機能追加や修正） - 入荷に関する入荷予定の設定・入荷検品・棚入れ、出荷に関する引当・ピッキング・配送、在庫状況把握などの機能があり - ユーザーはオフィスで使うWindowsアプリ、現場で使うバーコードやタグをスキャンできるAndroidアプリを使う - フリーランスとして自社開発企業に参画 - 参画先企業のチーム人数は4〜6人（さらに一時的にベトナムのオフショアを利用） - 基本リモートで作業 ## 使用言語・フレームワーク・ツール ### 言語 - PHP - Visual C# - Android Java - kotlin ### フレームワーク・ライブラリ・その他技術 #### Web - Laravel - PHP Unit - Apache - MySQL - Docker - AWS（EC2、Aurora、CloudWatch） #### Android - FRIDタグリーダーのSDK - ### その他使用ツール - Git - Git Hub - Postman - Php Storm - Android Studio - Visual Studio - Slack - Zoom ## システム概要・アーキテクチャ ### 全般 - クライアント側がWindowsアプリとAndroidアプリ、サーバー（API）側がLaravel、MySQL使ったシステム ### Webバックエンド - AWS使用でサーバーはEC2でApache+Laravel、DBはAurora（MySQL）、CloudWatchでCPUやメモリ使用率やエラーログを監視してSlackに通知 - デプロイはサーバーにログインしてgit操作（自動化はされていなかった） - 開発は個人的にDockerのコンテナを使用 - DB設計は複合主キー（参画先企業のやり方だったので） ### Windows - C# - Windows Formsを使用 ### Android - Android Java（ごく一部 Kotlin） - アーキテクチャは通常のActivityに書く手法 - API通信部分もライブラリを使うことなく低レベルで書いていた（先に開発していた方が書いていた） ## 担当業務 - Web、Windows、Android全ての実装を担当 ### Webバックエンド（API） - 実装（機能の追加・改修） - テスト（テストコードまたはPostmanでの手動による結合テスト） - Dockerでの開発環境の整備 - AWSは主に他の方に整備していただいたが1つサーバーを建てるなどをした - 保守・運用（障害時の原因解明と修正、ユーザーからのフィードバックによる機能修正） ### Windows - 実装（新規機能追加、改修） - テスト（手動での確認） ### Android - 実装（新規機能追加、改修） - テスト（手動での確認） ### 全般 - APIの設計（新規機能追加、改修） ## 取り組んだ課題など - 参画先企業が複合主キーのDB設計を使う企業だったので、初めてだったが実践で使い方を把握して一ヶ月ぐらいで改修できるようになった。参画前まで参画先の企業でlaravelでの改修ができるのが一人だけだったが、参画先企業が案件を多くこなせるようになった。 - WindowアプリとC#は初めてだったが、事前に書籍で予習するなどして一ヶ月ぐらいで実装できるようになった。C#はJavaに似ていたのであまり苦労はしなかった。 - 参画先企業がベトナム企業で一部機能をオフショア開発をしていたが改修要件がうまく伝わらず（在庫管理システムの用語や仕様が難しかったので）要件を満たしていないコードを納品した。そのため、納品されたLaravelやkotlinのコードを解析して、改修案件に合うようにソースを改修してなんとか納期に間に合うようにした。 ## 反省点・思ったこと ### ベトナム企業へのオフショアの失敗 - 参画先企業がベトナム企業にオフショアを依頼し、納品されたコードが要件を満たしていないという失敗が起きたため、その原因を考えました - 主な原因は、オフショア先のブリッジエンジニア（日本側の要件を日本語で聞いてベトナム側のエンジニアに要件を伝える役割の人）が、要件や仕様を理解できていなかったことが原因だと考えました - ただし、要件が、よくあるWeb開発の要件ではなく、倉庫管理の独自の仕様や専門用語があり、日本人エンジニアでも慣れるまで時間がかかる難しいものであったことも原因の一つでした - また、ブリッジエンジニアの方も、単に日本語とベトナム語を翻訳できる人であり、システムの要件を理解できるエンジニア的な思考を持った人ではなかったようです - ただし、オフショア先のソースコードの品質は高かったため、Android側はGoogleが推奨するコードの書き方をしており、WEB側のLaravelもLaravelが推奨するコードの書き方をしていたことが確認されました - そのため、簡単な要件のシステムを発注する場合など、オフショアは活用できると感じました - 余談ですが、納期が決まっていたためベトナム側の失敗をカバーするために、日本側は残業などをして一からシステムを作り直し、何とか納期に間に合うようにシステムを完成させました。 ### 複合主キー - 複合主キーを初めて使用してみましたが、改修に弱いと感じました - 仕様の変更がある場合、主キーを追加・変更しなければならない場面が多く、困難な状況が続きました - また、Laravelも複合主キーではなく、サロゲートキー（単一主キー）を前提として作成されたライブラリのため、ORMなどを使用することができず、SQLを生で書かなければならず、相性が悪いと感じました - このような理由から、今後は複合主キーの使用を避けたいと考えています。

# プロジェクト概要 - 印刷会社の約15年前のWEBシステムのリプレイス案件 - 受注（印刷形式、支払い、書類作成）、生産（印刷状況、データ）、出荷、在庫管理（紙、その他材料）、発注（材料、外部生産）などを管理するシステム - 旧システムからの仕様の大規模変更はなく、使いにくい部分は仕様変更して改修する形 - フリーランスとして受託開発企業に参画 - 参画先企業のチーム人数は7〜8人 - フルリモートで作業 # 使用言語・フレームワーク・ツール ## 言語 - PHP - JavaScript(ES6) ## フレームワーク・ライブラリ・その他技術 - Laravel - PHP Unit - Composer - Apache - jQuery - PostgreSQL - Docker - Apache - AWS（EC2、S3） - HTML&CSS3 - Bootstrap ## その他使用ツール - Git - Git Hub - Php Storm - Slack # システム概要・アーキテクチャ - Laravelを使用しているのでアーキテクチャはMVC - DBはPostgreSQL（旧システムからそのまま）、DB操作にはLaravelでORM、Migration、Seedersを使用 - 開発はDockerでサーバーやDBのコンテナを作成してローカルPCで開発 - デプロイはGithub ActionsでAWSのEC2にデプロイ - テストは手動でテスト - 旧システムは生のPHP、jQuery、PostgreSQL - DB構成は基本的には旧システムをそのまま使用して、仕様変更部分を変更 # 担当業務 - 旧システムの把握（設計書やマニュアルはなし、ソースコードを読んだりDB構成を見ての把握、把握した内容は設計書にフィードバック） - 実装（設計書（画面図）を見ての実装） - サーバー（AWS）やDocker、デプロイの設定などは他の方に整備してもらいました - 発注元企業とのコミュニケーションは参画先企業の方を通して行いました # 取り組んだ課題など - Laravelが初めてだったので事前に書籍などで勉強したりお試し実装などをしたりして案件に参画した。参画中は詰まることなくスムーズに実装でき、参画先企業の方にlaravelは初めてだと話したら驚かれた。 - 旧システムの把握が仕様書やマニュアルがなかったので、ソースコードを読んだりDB構成を見て把握したりなどして大変だった。把握した旧仕様は参画先企業の方に相談して新システムの仕様にフィードバックした。 - 旧システムの処理速度が遅かったので（レコードを1件取得しては更新を行う処理をfor分で回して行う、表示に不必要なレコードまで取得して表示するなどしていたので）、新システムの同じ場所ではレコードは必要なデータの分を一度のSQLで取得するなどして速度を改善した。また、テーブルにインデックスを貼る（主にWHERE区で使われているカラムなどに貼る）などをして速度を改善した。 - LaravelのORMのwithメソッドなどを使用して、リレーション先のテーブル取得時のSQLの実行回数を減らすようにした。その結果、処理速度がwithを使用する前とくらべて速くなった。

# プロジェクト概要 - 写真スタジオの撮影写真の閲覧や注文などをするアプリ（Android、iOS）のアルバム機能部分の追加・改修の案件 - フリーランスとして受託開発企業に参画 - 発注元企業がAndroid・iOSアプリのクライアント部分を参画先企業に、Web APIのサバー部分を他社に依頼 - 参画先企業のチーム人数は2人 - 参画先企業のオフィスで作業 # 使用言語・フレームワーク・ツール ## 言語 - kotlin ## フレームワーク・ライブラリ・その他技術 - Retrofit - Rx Java（Rx Kotlin） - Dagger2（DIライブラリ、ほぼ使われていなかった） - Gradle ## その他使用ツール - Git - Git Lab - Android Studio - Slack # システム概要・アーキテクチャ - Web API（json形式でHttp通信、Rx Kotlin、Retrofit使用）でサーバーと通信して、写真の閲覧・DL・プリント注文・その他商品の購入を行うシステム - Androidのアーキテクチャはクリーンアーキテクチャ（MVPでUseCaseを使う形式） - Web APIのサーバー側は他社が開発したAPIでレスポンスパラメータが多く複雑だった # 担当業務 - 既存の仕様やAndroidのソースコード、Web APIの把握 - 改修内容（画面の遷移図やレイアウト図）の把握 - Androidの実装（Androidのアルバム機能の改修を担当） - 発注元企業との調整は参画先企業の方が担当 - テストも参画先企業の方が担当してくださいました # 取り組んだ課題など - Activity上とダイアログ上で同じ画面を表示する要件だったので、共通部分はFragmentを作成してレイアウトに埋め込むことによって実装時間の短縮や機能に異差がでないようにした。 - 既存ソースでRx Java（Kotlin）が使用されていたが初めてだったのでプライベートで勉強して実装に遅れが発生しないようにした。 - MVPのソースコードも初めてだったので、プライベートで勉強して実装で遅れが発生しないようにした。 # 反省点・思ったこと - 他社開発のAPIの仕様が複雑で（パラメータが多く未使用パラメータなども沢山あり）機能が把握しにくく、アプリ側とあまり連携が取れてないように感じた。APIもアプリも元々は別の会社が作成したものを引き継いだもの（さらにアプリとAPIは別々の会社に引き継ぎしたもの）なのが複雑になった原因のうよだった。APIとアプリは同じ会社で開発した方が連携がとれるし良いものが作れると思った。 - DIライブラリであるDagger2は初期にコードを作成した部分以外は殆ど使われておらず、ビルド時間が長くなるだけの結果となっていた。実装する人のレベルが高くないと使いこなせないライブラリだと感じた。自分がライブラリを導入する場合は実装する人のレベルも考慮して選定しようと思った。

# プロジェクト概要 - 既存の銀行アプリに振り込み機能や収支・残高グラフなどの新規画面を追加するプロジェクト - AndroidとiOSの同時開発 - フリーランスとして受託開発企業に参画 - 発注元企業が一次受けで参画先企業が二次受けで、参画先企業は主にレイアウトや画面動作の実装を担当 - 参画先企業のチーム人数は6人（一次請け企業の開発体制は不明） - 参画先企業のオフィスで作業 # 使用言語・フレームワーク・ツール ## 言語 - Android Java - swift（ソースを参考に読むぐらい） ## フレームワーク・ライブラリ・その他技術 - MPAndroidChart（グラフライブラリ） - JUnit - Gradle ## その他使用ツール - Git - Git Lab - Android Studio - Slack # システム概要・アーキテクチャ - 二次請けのためデータのやり取り部分などでソース非公開部分があった - 通常のActivityやFragmentに処理を記述（一次請け企業の要望により） - グラフ部分はAndroid、iOSの両方に対応しているライブラリのMPAndroidChartを使用 # 担当業務 - 新規追加画面の基本設計（画面のレイアウト図や遷移図）の把握 - Androidの実装（振込み画面の画面作成、収支・残高グラフ作成、コードレビューによる修正） - グラフ部分のライブラリの選定。さらにライブラリの仕様を把握した上で一次受け企業と参画先企業とミーティングをし、縦軸の金額メモリの自動表示やどういったデザインが実現できるかなどの話し合いをして仕様を決定した # 取り組んだ課題など - グラフライブラリのMPAndroidChartについての記述がほぼ英語しかなかったので、公式ページの英語の解説を読んで機能を把握して実装した。また、公式サイトに記載がない仕様はソースコードを読んで把握した。このライブラリを導入することでグラフ表示部分を自前で作成するよりかなりの時間を節約できた。 - グラフの金額メモリ部分の制御を実装したが、色々な表示パターンがあって画面では確認しにくかったので、JUnitでテストコードを記述して正確に実装できているか確認した。 - iOSの担当の方がグラフ部分で苦戦していたので、一部swiftでコードを書くなどして実装を手伝った。 # 感想・その他 - 一次受け企業の方にソースが良いと褒めていただきました。

# プロジェクト概要 - 企業向け印刷物の発注サイトの新規開発 - 発注側システムとして、商品一覧、カート、社内認証、発注履歴、印刷データアップロードなどのシステムがある - 受注側システムとして、印刷工程や出荷の管理などのシステムがある - フリーランスとして受託開発企業に参画 - 参画先企業のチーム人数は2〜5人 - 参画先企業のオフィスで作業 # 使用言語・フレームワーク・ツール ## 言語 - PHP - JavaScript ## フレームワーク・ライブラリ・その他技術 - FuelPHP - PHP Unit - Composer - amazon linux - AWS(EC2、S3) - Apache - jQuery - MySQL - Docker - Redis - npm - HTML&CSS3 - Bootstrap - SCSS ## その他使用ツール - Git - Bit Bucket - Php Storm - Slack - Backlog # システム概要・アーキテクチャ ## バックエンド - FuelPHPを使用しているのでアーキテクチャはMVC - DBはMySQL、FuelPHPのORM、Migration、Seedersを使用 - 開発はDockerでサーバーやDBのコンテナを作成してローカルPCで開発 - サーバーはAWSのEC2とS3を使用 - デプロイはAWSのEC2サーバーにログインして手動でデプロイ - テストは一部個人的にユニットテストを書いていたが、手動でテスト ## フロントエンド - HTML&SCC周りはBootstrap、SCSSを使用 - javascriptはjQuery # 担当業務 - DBテーブル設計 - FuelPHPでの実装（設計書（画面図）を見ての実装、機能の半分ほどを実装しました。ORMなどを上手く使って実装しました。） - DB周りの実装（FuelPHPのMigration、Seedersの実装。たまに生SQL文を書いたりした。） - jQueryでの実装 - コードレビューによる修正 - 少しだけHTML、SCSS、Bootstrapでレイアウトを修正 - テスト（個人的にPHPUnitでユニットテストを書いていた、結合テストは手動でテスト項目書などは書いていなかった） # 取り組んだ課題など - FuelPHPが初めてだったので事前に公式サイトなどで勉強したりお試し実装などをしたりして案件に参画した。参画中は苦戦することなくスムーズに実装できた。 - Dockerが初めてだったので、案件参画中に書籍で勉強したりプロジェクトで使用しているDockerfileやcomposeファイルを解析したりして、個人的にDockerを勉強した。後のプロジェクトでDockerを使用するときにこの経験が約だった。