1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

株式会社ゆめみ様のコーディングテストのフィードバックと振り返り

Posted at

はじめに

この記事は、株式会社ゆめみさんのコーディングテストを受験し、その際に頂いたフィードバックをまとめたものです。
試験には落ちてしまいましたが、今後の学習のためのアウトプットとして記入します。

株式会社ゆめみ様には、貴重なフィードバックの機会をいただき、誠にありがとうございました。

注意:
この記事では、具体的な試験問題の内容や、企業の機密情報に触れる可能性のある記述は避けています。あくまで個人の経験と所感に基づくものであることをご了承ください。

  • 受験時期: 2025年4月頃
  • テストの概要: GitHub APIを使用してリポジトリを検索できるモバイルアプリケーションをFlutterで作成する。

頂いたフィードバック

選考後に頂いたフィードバックを、項目別にまとめました。

良かった点 (Good)

  • README.mdを充実できていた
  • 検索結果が空の場合のUIが、ユーザーにとって分かりやすく工夫されていた
  • 機能ごとにクラスを適切に分割しようと意識できた
  • 設定値を環境変数から読み込む仕組みが導入されていました
  • リポジトリ一覧のソート機能を実装した
  • 多言語対応やダークテーマ対応を実装した
  • 画面の横向き表示にも対応した
  • 役割ごとにディレクトリを分割し、プロジェクト構成を整理した

改善点 (More / Issues) と自己考察

頂いたフィードバックから見えてきた、自身の課題と改善点は以下の通りです。

1. アプリケーションの設計とコード品質における課題

アプリケーションの可読性、保守性、堅牢性を高める上で、以下の点に課題があったと認識しています。

  • Widgetの状態管理とUIの分割が不十分だった点

    • 現状の課題認識: モデル、スクリーン、サービス、ウィジェットといった役割ごとの分割は意識していましたが、特に検索画面(SearchScreen)において、UIと状態管理の分離が徹底できていませんでした。結果として、SearchScreenが多くの状態ロジックを抱え込み、ファットウィジェット(肥大化したWidget)になってしまっている状態でした。
    • 具体的な問題点:
      • SearchScreenで多くの子Widgetの状態を一元管理しようとしたため、見通しが悪くなっていました。
      • 子Widgetが必要な状態やメソッドを親Widgetから受け取る際に、引数のバケツリレーが多発し、コンポーネント間の依存関係が複雑になっていました。
    • 今後の改善方針:
      • UIを担当するWidgetと、状態やビジネスロジックを担当するNotifier(またはそれに類するクラス)へ明確に責務を分割することを意識します。
        • 例えば、検索条件・ソート順・検索結果といった関連する状態を一つのNotifierに集約し、各WidgetはそのNotifierを購読する(consumeする)形にすることで、依存関係を整理し、見通しを良くしたいです。これはテーマのDark/Lightモード切り替えで状態を共有するアプローチに近いと理解しました。
      • 発展的なアプローチとして、riverpodのような状態管理ライブラリの活用を検討し、ローディング中やエラー発生時といった非同期処理の状態管理とUIへの反映をよりシンプルかつ堅牢に実装できるよう学習を進めます。
  • ソート機能におけるUI更新の不備と型定義の甘さ

    • 現状の課題認識:
      • 実装したソート機能において、ソートオプションを変更した際に、関連する状態変数(_currentSortOption, _isSortAscending)の更新ロジックに不備があり、UI(選択状態を示すチェックマークなど)が正しく反映されないというバグを埋め込んでしまっていました。
      • ソートオプション(_currentSortOption)の型をString型で管理していたため、文字列比較による判定が必要となり、コードの可読性や安全性の面で改善の余地がありました。
    • 今後の改善方針:
      • 状態変数がソート実行時に正しく更新されるよう、ロジックを確実に見直します。
      • ソートオプションのような固定値を扱う場合は、String型ではなくenum(列挙型)で管理することで、タイプセーフにし、可読性の向上を図ります。

2. 開発プロセスと環境設定における課題

開発効率の向上、チーム開発の円滑化、コード品質の一貫性を保つ上で、以下の点への意識と実践が不足していました。

  • コードフォーマットの徹底と自動化への取り組み不足

    • 現状の課題認識: プロジェクト全体を通して、コードフォーマットを徹底できておらず、部分的に未適用の箇所が残ってしまっていました。
    • 今後の改善方針:
      • Dart標準のフォーマッター(dart format)の利用を習慣化し、エディタの保存時自動実行機能を設定することで、常に整形された状態を保ちます。
      • GitHub ActionsなどのCI/CDツールを導入し、フォーマットチェックやテストを自動実行する仕組みを構築することで、手作業による漏れを防ぎ、コード品質の一貫性を高めたいと考えています。
  • Flutterプロジェクトのバージョン管理の未実施

    • 現状の課題認識: プロジェクトのFlutterバージョンを固定する取り組みを行っていませんでした。
    • 今後の改善方針: fvm (Flutter Version Management) などのツールを導入し、プロジェクトごとにFlutterバージョンを明確に管理することで、チーム開発時における環境差異による潜在的な問題を未然に防げるよう努めます。

3. ドキュメンテーションの正確性と明確性における課題

プロジェクトの理解を助け、他の開発者がスムーズに参加できるような配慮が足りませんでした。

  • README.mdにおけるAPIトークン記述の不備
    • 現状の課題認識: README.mdにGitHub APIトークンに関する記述をしましたが、プロジェクト内で実際にそのトークンを利用する箇所や、利用目的について明確に説明できていませんでした。
    • 今後の改善方針: ドキュメントに記載する情報は、実際のコードや挙動と一致させ、特にAPIトークンのような重要な設定項目については、その目的や具体的な利用箇所を明記することで、誤解や混乱を招かないようにします。

学んだこと・今後のアクション

今回のコーディングテストとフィードバックを通して、多くのことを学びました。

学んだこと

  • [今回の経験で最も重要だと感じた学び1]
  • [今回の経験で得られた技術的な知見や気づき]
  • [その他、マインドセットや学習姿勢に関する学びなど]

今後のアクションプラン

上記の学びと頂いた改善点を踏まえ、以下のように今後のアクションプランを立てました。

  • 短期的な目標 (1〜3ヶ月程度):

    • 状態管理手法の習得と実践:

      1. riverpodの基礎学習: 公式ドキュメントや解説記事を読み込み、NotifierProvider, FutureProvider, StreamProviderなどの基本的な使い方を理解し、サンプルアプリを作成して手を動かします。
      2. バグ修正と型改善: ソート機能のUI更新漏れを確実に修正し、関連する状態の型(例: ソートオプション)をenumに変更します。
    • 開発環境とプロセスの整備:

      1. エディタ設定の見直し: 使用しているIDE(VS Code/Android Studio)で、Dartファイルの保存時に自動でdart formatが実行されるように設定します。
      2. CI/CDの導入体験: 個人プロジェクトにGitHub Actionsを導入し、最低限のフォーマットチェックと(もしあれば)テストが自動実行されるワークフローを構築してみます。
      3. バージョン管理ツールの導入: fvmをインストールし、今後の個人プロジェクトでFlutterのバージョン管理を実践します。
    • ドキュメントの改善:

      1. 今回のプロジェクトのREADME.mdを修正し、APIトークンに関する記述を実態に合わせて明確化、または不要であれば削除します。
  • 中長期的な目標:

    • Flutterアプリケーション設計力の向上:

      1. テスト駆動開発(TDD)の学習と実践: Flutterのユニットテスト、ウィジェットテスト、インテグレーションテストの書き方を学び、カバレッジの高いテストコードを書く習慣を身につけます。
      2. ポートフォリオアプリの作成: 今回学んだ設計原則や状態管理手法を活かし、より実践的で複雑な機能(例: Firebase連携、ローカルDB、より多くの外部API連携など)を含むポートフォリオアプリケーションを企画・開発します。
    • 開発コミュニティへの参加と貢献:

      1. 技術記事のアウトプット: 学習した内容や、開発中に遭遇した問題と解決策などを、Qiitaや個人のブログで定期的にアウトプットし、理解を深めるとともに他者へ貢献します。
    • 継続的な学習習慣の確立:

      1. FlutterおよびDartの公式ドキュメント、主要なパッケージのアップデート情報を定期的にチェックし、最新の技術トレンドを追いかけます。

おわりに

改めて、株式会社ゆめみ様には貴重なフィードバックを頂けたことに感謝申し上げます。
今回の経験を糧に、今後も技術力向上に励んでいきたいと思います。

この記事が、少しでも誰かのお役に立てれば幸いです。
最後までお読みいただきありがとうございました。


ご意見・ご感想などありましたら、お気軽にコメントください。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?