onesword0618

## 概要 当プロジェクトは、商品を紹介した人に利益が出る仕組みを持ったECサイトがあり、そのサイトをモバイル化したいという要望から開始されたものでした。 ## 参画前のプロジェクト背景 既存アプリケーションは、オフショアを利用して構築されました。 完成したものとして提供されたものは、プロジェクト初期に提出されたデザインを踏襲したものでした。 その時点では決まっていなく仮で配置したもの、モバイル特有の機能を簡易的に表現したもの（例 : 写真選択画面など）を再現していました。 また、フォントサイズやカラーコードもデザインから推測されたサイズとカラーコードで、提案者が期待しているフォントサイズとカラーコードではありませんでした。 ## 課題 当アプリケーションの課題としては、下記が挙げられました。 - フォントサイズその他の要素を最新のデザインに合わせて変更する必要があること。 - 画面の要素をプロジェクトで横断している要素の分析や分類が進んでいなく同じ構成の要素が乱立されている状態であり要素の変更の横展開と調査が多岐に渡っていたこと。 - 画面のライフサイクルの考慮が足りていなく、ReactのuseEffectが乱立しており、hook処理の呼び出しタイミングによっては、何度も画面が描画されている状態であったこと。 - 画面及び、要素のstyleの当て方がインラインで記載されており、デザイン変更を行う際に、変更箇所の調査にコストが高い状態であったこと。 ## 取り組んだアプローチ 1. **上記の課題に対しての調査を行いました。** ReactやReact Nativeのディレクトリのアプローチとして機能単位でContainerとPresenterを分けるようにしていました。 しかし、チーム間で徹底されていなかったようで、下記の構成で作成されている機能が散見されていました。 ``` XXX // 機能 ├── Container // ボタンその他要素 └── Presenter // 画面 ``` のようにPresenterにUI部品が置かれていないことがありました。 Containerのディレクトリに機能特有の要素が配置されていましたが、機能特有の要素とプロジェクトで横断する要素に対して開発者間で情報が共有されておらず同じ構成の要素が乱立されている状態でした。 クライアントと相談をして、利用するユーズケースを洗い出していきました。 その中で、着手するタスクに落とし込み、クライアントと進み具合を画面で共有しながら説明をして意見をフィードバックするようにしました。 アプリケーション起動時に表示される画面からデザイン変更を行っていきました。 2. **デザイン変更とロジックの整理を行いました。** デザイナーの案をクライアントからどういう挙動を期待しているのかをヒアリングして現状からどういう風に変更を加えるのかを計画を立てました。 機能単位で利用する画面を並べてプロジェクト内で共通できる要素、機能単位で利用する要素、画面のみで利用する要素を分類して修正作業に取り組むようにしました。 ``` 1. 画面および要素に散らばっているインラインのstyleをまとめ影響範囲の特定と、不要なスタイルの削除、修正を対応した 2. デザインに合わせて画面の領域を定義し、ターゲットにしている端末のデザイン崩れに対応した 3. イベント処理を別ファイルに切り出して呼び出すようにして画面からイベントの実装を追い出した 4. useEffectをはじめとするhook処理の呼び出しタイミングをロガーを仕込み確認し、不要なものを削除、適切なタイミングになるように修正をした 5. 他の画面と共通にする要素のpropを定義してPresenterに配置するようにした 6. 他の画面からの遷移時のパターンを整理し、画面のpropを定義するようにした 7. Reduxから余分に問い合わせて取得している箇所を削除した 8. APIから取得する処理を見直して失敗したときの処理を追加した ``` styleについては、画面側が配置位置を管理するようにし、要素単位で適用されるレベルはその要素に持たせるようにし汎用性と、修正時に画面側のstyleに注力できるように定義をしました。 3. **画面遷移の課題を調査、解析をしました。** React Navigationという画面遷移を管理するライブラリを利用してアプリケーションは作成されていました。 しかし、上記ライブラリに対して有識者がいなかったのか試行錯誤をして作成しているように見受けられました。 具体的には、上記ライブラリでは、移動した画面に必要最低限のパラメータを渡すことを期待しています。 FYI: https://reactnavigation.org/docs/params#what-should-be-in-params 呼び出し先でAPIその他へパラメータを渡し、最新のデータを取得して描画することができず、サーバーに登録している情報と差分が生まれていました。 他の課題として、画面を管理するstackの塊が２重〜５重の入れ子状態になっているため、外部リソースからの呼び出し方法が複雑化をしていました。 外部リソースの例) - 仮会員登録時にメールのリンクを踏んだときにアプリケーションを呼び出すこと - SNSに貼ったリンクを踏んだときにアプリケーションを呼び出すこと - 通知領域にきた情報をタップしたときにアプリケーションを呼び出し、対象の画面を表示すること FYI: https://reactnavigation.org/docs/configuring-links#handling-nested-navigators クライアントへその原因と改善案を説明をし、ネストしているstackを整理してまとめ上げる修正作業を行いました。 ## 成果と知見 このプロジェクトを通して、React Native を利用したアプリケーションの構築の分析と調査から適切な方法を見出し、クライアントに提案して修正作業を行うことができました。 当プロジェクトのリリースに向けて乗り越えるべき課題を解決することができました。

## プロジェクト概要 当プロジェクトは、特定疾患を持っている患者同士が交流できるようプラットフォームを構築したいという要望から開始されたものでした。 ## 参画前のプロジェクト背景 クライアントがAWS S3 / AWS APIGateway を利用してサーバーサイドの処理を構築。 こちらは、アプリケーション側を構築する分業で当プロジェクトは進めるようになりました。 ## 課題 当アプリケーションの課題としては、下記が挙げられました。 - モバイルアプリケーションについて理解が深いメンバーがいませんでした。 - APIの完成度が未熟でトライアルアンドエラーを繰り返す状態でした。 アプリケーション部分のみが今回の依頼内容でしたが、サーバーサイド側で管理しているAPIの内容や項目についてもこちらで検証及び提案をする必要が発生しました。 ## 取り組んだアプローチ - プロトタイプを作りながらプロジェクト構成を見直して適切な構成を導出していきました。 当プロジェクトはプロトタイプを作成しながら、構築を進めていきながら適切なディレクトリ構成は何かを考察を深めました。 Githubで１００近いプロジェクトを眺め、当プロジェクトの性格に合致するディレクトリ構成を決めました。 FYI: https://atomicdesign.bradfrost.com/chapter-2/#the-atomic-design-methodology ``` components ├── atoms ├── molecules └── organisms event └── XXX // 画面に対応したイベント処理を定義したファイルを格納する pages // 画面 styles // 画面と対応したstyleを定義したファイルを格納する navigations ├── 認証周りのstack └── プロジェクト間のstack ``` Atomic Design 単位の要素を整理しコンポーネントを配置しました。 タップ時などのイベント処理も画面に記載していましたが、煩雑になるため、画面に対応したファイルを定義して外部から呼び出すようにしました。 - APIの呼び出しによる型変換と処理をまとめ上げて影響範囲を閉じ込めるようにしました。 APIを整理して同系統のAPIの呼び出しをaxiosを経由して呼ぶようにしてクラス定義としてまとめました。 また、メソッドとして呼び出せるようにしてAPIの取り回しを良くすることができました。 APIの呼び出し部分を仕様に合わせて型に合わせて型変換することで、データ不備を検知できるように対応いたしました。 その結果、サーバーサイドで発生した障害やミスを検知することができ、適切な対応を依頼することができるようになりました。 - navigationを浅く保つようにしました。 navigationを機能単位でまとめるようにしましたが、外部リソースを利用しアプリケーションを起動する要件があり、navigationを認証周りとそれ以外でstackを分けて呼び分けるようにしました。 これにより、ディープリンク処理などで特定の画面を呼び出す場合の実装難易度を引き下げることができるようになりました。 - 途中で発生した作業の見積もりの対応 構築途中で発生した仕様について相見積もりを行い、作業期間をすり合わせてクライアントと同意しました。 クライアントからの要望をヒアリングし、非機能要件を引き出して文章としてまとめ口頭で完結しないように取り組みました。 スケジュールの遅延が発生した場合に、クライアントに連絡をし、スケジュールの課題を共有し、善後策を提案し受け入れてもらうように交渉しました。 チケット単位で作業を振り分けるようにし、作業メンバーへの仕様への質問をWiKiにまとめて類似の質問を減らすようにし、また他の作業メンバーへの知見を共有できる環境づくりを行いました。 このことにより後から参画したメンバーへの引き継ぎがスムーズに行えるようになりました。 ## 成果と知見 このプロジェクトで、React Native を利用したアプリケーションの構築と知見を深めることができました。また、クライアントに提案してAPIの検証結果と修正案を提案することや、メンバーへの技術指導を行いリリースに向けて舵取りをすることができました。

## プロジェクト概要 当プロジェクトは、警視庁の工事案件を管理したいという要望から開始されたものでした。 ## 参画前のプロジェクト背景 何回かの更改を経て最後に納品して検収に失敗したプロジェクトを立て直すことが私の作業範囲でした。 クライアントとの関係性は悪化していました。 ## 課題 当アプリケーションの課題としては、下記が挙げられました。 - このプロジェクトについての経緯について理解が深いメンバーがいませんでした。 - データベースと画像リソースに差分があり、画像リソースがない案件を取得しようとするとアプリケーションが落ちる状態でした。 - クライアントへの納品が終わって運用しようとして上記の状態で関係性が悪化していました。 ## 取り組んだアプローチ - アプリケーションの挙動を確認して、影響範囲を切り分けるようにしました。 アプリケーションが落ちる操作を確認しながら、ボタン、フォームのデータモデルからデータ不備を想定し、データベースのデータが欠落していることが判明しました。 また、Windowsで運用していたアプリケーションをAWS EC２に配置していました。 文字化けにより画像パスが想定通り取得できないためアプリケーションが落ちていたことがわかりました。 その為、まずAWS EC2 及び AWS RDSの設定を確認し文字化けをサーバー側、データベース側で解消することを実行しました。 上記を乗り越えることで、アプリケーションが画像パスを取得できなくて落ちることがなくなりました。 - 不具合対応と追加機能の実装 トラブルへの補償対応として既存アプリケーションの不具合対応と、追加機能を対応しました。 不具合対応については、文章が残っていなかったのでクライアントにヒアリングを進めて期待している挙動を文章化しました。 確認環境を構築し、クライアントに挙動を確認してもらい本番環境に反映するように進めました。 不具合対応の内容を整理し、どのように実装するかを設計し、場当たり的に行うことをせずに取り組みました。 追加機能については、クライアントが保持している工場のシステムに渡すCSVファイルを出力するものでしたが、必要なデータ項目がない状態でした。 クライアントからヒアリングを進めて、要件を文章に書き起こし、どのようにCSVファイルに出力する内容を構築するかを設計し実装をしました。 その際に、コアドメインの考え方を取り入れ、計算処理を散らばらず一箇所に集めるようにしました。 進捗状態を共有できるように出力内容を項目単位でクライアントが確認できるように実装を進めました。 - クライアントの立場や状況を考えてタスクを決定し計画の実施状況を逐一伝えるようにしました。 プロジェクトマネジメントを遂行する上にあたり、クライアントとの関係性を改善しなければ必要な情報を引き出すことやヒアリングを進めることができないと考えました。 原因調査は複雑に要因が絡まった状態でした。 そのためクライアントにどういう操作をする想定だったのか、期待されている挙動のヒアリングを進めました。その際には、こちらの作業状況をクライアントに説明をし、状況を共有するように努めました。 スライドを作成したり、実際に画面を操作しながら、説明に努めてクライアントが実現したいことを文章化することに取り組みました。 また、判明した問題に対して見積もりを行い、クライアントに説明を行い、修正作業を受け入れてもらうことができました。 作業メンバーには、他の影響範囲がないか調査と報告をチケット単位で行い、データベースのデータ不備や、追加機能による項目追加の影響を確認してもらうようにしました。 作業途中で見積もりに対して実績が多くなる場合も、判明した時点でクライアントに説明を行い期間の修正を認めてもらいました。 最終的に、画面からデータベースへアクセスするSQLを含めてフロントエンドからバックエンド、アプリケーションを配置する環境周りを全面改修を行うようになりました。 ## 成果と知見 このプロジェクトで、Javaを利用したアプリケーションの構築と知見を深めることができました。 また、既存コードを改修するにあたり、業務知識をまとめて定義することで、そのあとの仕様変更および機能追加に対応することができるようにしました。