Flutterを通して学べた開発スキル

こんにちは。ns_hohohohoです。

この記事は「NEXTSCAPE Advent Calendar 2022」の22日目です。

🎄はじめに

アプリチームに配属されて約1年が経ちました。今回は、私が積んできた学習と学習で感じたことを紹介します。

私は文系学部卒で新卒枠入社し研修で主にサーバーサイドとWebフロントエンドの開発を行った後に、チームに配属となったためモバイルアプリ開発は初めてでした。

🎄学習

◆学習の流れ

配属後は、まずモバイルアプリ開発の基礎を学びました。チームはFlutterを積極的に案件で使用しているため、KotlinでAndroidアプリを開発しながらAndroid Studioの使い方に慣れた後に、Flutterでのモバイルアプリ開発を学習しました。

Androidの公式ドキュメントはあまりにも豊富なので取り組むものを周りの方に相談して進めました。あとは日本語だと時々出てくるアーニャ*1みたいな文章への耐性か英語力があると良いです。

◆研修課題

公式チュートリアルでの学習に加え、チームの方に作成してもらった開発課題を解いていき、モバイルアプリ開発の理解を深めていきました。課題の一部を紹介します。

・ライフサイクル

ライフサイクルの課題では、スマートフォンのフォアグラウンド、バックグラウンドといった状態の概念や、アプリを起動したらどのようなメソッドが呼ばれるかといったライフサイクルについて調べ、実装方法を学びました。

・Push通知

Push通知の課題では、プッシュ通知の種類とシステム的な仕組みのレクチャーを受け、Firebaseと連携してPush通知を実装しました。また、サービスとしての活用方法について調べディスカッションしました。

　エンジニアの研修課題に、その機能がもたらすビジネス的価値について考えるというお題が盛り込んであることはユニークに思いました。また、スマートフォンは、今の新卒世代は子供の時から身近に触れていたもので、あって当たり前の状態となっており、ほぼ無意識に機能の恩恵を受けていたので、改めてそのビジネス的な意味について考えると発見が多くあり、アプリケーションを今までと違う角度からみられるようになったように思いました。

🎄アジャイル開発の難しさ

チームの開発はウォータフォールとアジャイルのハイブリットスタイルで進めます。アジャイル開発をやるということは、肩書きが意味する慣習的な担当領域に自分の役割を限定しない姿勢が求められることをだんだん理解しました。

　平たく言うと「エンジニアだからコーディングだけしてればOK」ではないということで、例えば、要件定義ではお客さんの要望を実現できそうな機能を自分も考えて意見を出す、UIUXも意見を出す、自分の実装範囲の詳細設計的なことは自分がリードして決め調整する必要がありました。

他の例をだすと、提案書のディスカッションに参加したこともありました。私は大学では商学を専攻していたこともあり、競合他社も含めたIR資料等を読み込み、業界の動向とRFPからクライアントのなりたい像と現状の状態の差分を考察して意見を述べました。

　チームの方は息を吸うようにコードを書くため、サーバーサイドからモバイルに転向した方や、Flutter初めての方も業務を難なくこなしたようです。対して私は、技術に関しては初心者であることとアジャイル開発の難しさが重なり、業務で大いにつまづきました。そして、私自身自分が何をわからないのかわからないし、周りの方も私が何をわからないのかピンとこないのです。

　この何がわからないのかわからない状態から、原因と思われるものにあたりをつけて、試行錯誤しながら解決していく過程は、効果的な施策を打てているか不明瞭なためモチベーションが下がりやすいという意味で大変でした。

試行錯誤は、結果的に下記の過程を辿りました。

1.コーディングスキルの向上

2.設計スキルの向上

3.チームと私の最適なコミュニケーション方法の模索

4.わからないへの切り口を作る

1.コーディングスキルの向上

私には、三項演算子と、関数の再帰的な使い方などラムダ式の様々な記述方法の理解が足りていないことがわかり、上記を学習したことで、ドキュメントや業務のソースコードが格段に読めるようになりました。

2. 設計スキルの向上

ここでの設計というのは機能の詳細を詰めていくことです。

例えば、下図のような画面デザインで任意のタイトルとURLを入力してブックマークとして管理できる画面を作るとします。

・どんな問題があったか

　Android Studioを開いて、どんなメソッドが必要か？を考え、IDEにコメントでメモし、メソッドを作成していきます。UIをデザインに近づけていき、動くものを作りました。レビューに出すとこんな質問をもらうかもしれません。

・同じ名称のブックマークも登録できるのか？

・初期値を削除するとどうなるのか？

・ブックマークを複数登録した時、リストを下スクロールして表示するが、読み込みの動作はどのようになっているか？

大雑把な説明になってしまいますが、要するに、初学者がいきなりコードを書き始めると大きい粒度での考慮漏れが起きる可能性が高いということです。大きい粒度での考慮漏れは、コードの修正範囲が広くなるので作業のベロシティが下がります。

・どのように解決したか

コードを記述する前に「日本語でプログラミングしましょう。自分ではない他の開発者に作業を依頼して実装できるような粒度にしましょう」というアドバイスをもらいました。自分の中でどういう資料が適切か色々検討した結果、フロー図が作りやすいという結論になりました。

フローを作成して分岐が発生するところは、依頼者との認識のずれが起きやすく、レビューポイントになります。

3.チームと私の最適なコミュニケーション方法の模索

　詳細設計スキルの向上に努める中で作成した資料は、私とチームにとって最適なコミュニケーション方法の1つとなりました。レビュアーが私の作業状業を把握するためのコストが減り質が上がったため、わからない部分の解消が容易になりました。

4.わからないへの切り口を作る

　　自分でその問題を解決できず作業を進められない状態というのは、大体が「何がわからないのかわからない状態」であるかと思います。何がわからないのかわかるのであれば、ジュニアエンジニアが遭遇する問題というのは大体検索で解決するからです。

　相談しにくいと感じることは、リモートワークの弊害かと思います。相談しにくいと感じる理由は、人によって様々です。チャットの質問文章を作成することが面倒に感じるという人もいれば、こんなことを質問してできない奴だと思われたらどうしようと不安が原因の人もいると思います。対面であれば、相手の表情や振る舞いといった非言語化部分から大丈夫であるという安心感を得て、不安を感じていなかったかもしれません。

　リモートワーク大好きですし、リモートワークを続けながらも、相談しにくさをノンバーバルコミュニケーション以外の方法で解消する手段を探す必要があると考えました。

　目標は、「◯◯はどうしたらよいか？」「何をしたらよいか？」というオープンクエスチョンをできるだけ具体化した質問にすることです。解決手段としては、わからないことをわかるにするための切り口を用意しようと思いました。

　私の場合は、メイン業務の設計フェーズと実装フェーズで使える切り口が必要です。設計フェーズは、「2. 設計スキルの向上」で記述した詳細設計資料作成が切り口です。実装フェーズは、なんとなく自分流のものが出来上がりつつある気がするのですが、うまく言語化できなかったので、参考にしたこちらの記事を貼らせていただきますw

qiita.com