アイリッジ開発者ブログアイリッジ開発者ブログアイリッジに所属するエンジニアが技術情報を発信していきます。開発部所属の山崎です。現在iOSエンジニアですが将来マネージャーを目指しています。今回は、2020年1月〜3月に業務で経験した点に基づき、気づきをまとめてみました。お願いされた作業の意味・意図を知っておく単純に言われた作業のみやっていて意義を理解していないと、本来のその作業の意義が分からないため微妙にズレた方向に行ってしまう事があります。尋ねて作業の意味が明確化されれば、もっと良いやり方などが提案できるかもしれません。逆に、このままでは目的が達成できないということに気付けるかもしれません。(具体例)アプリ内で用いている画像の差し替えをお願いされた。画像の何が変わったかが一見して分からなかった(全く同じ画像のように見えた)。画像の何が変わったのかをプロジェクトマネージャ(以後PMと言います)に尋ねた。何が変わったのかは説明してもらったが、その説明の過程の中でPM自身が、まだ足りてない部分がある事に気づく事ができた。正しい画像を用意してもらった。ある画面についてのデザイン(色、フォントサイズなど)をデザイナーに共有してもらった。それらはAndroid側のデフォルト画面に基づいてデザインされたもので、その画面をカスタマイズするにはふさわしいものだった。iOS側も可能な限りその指定に沿ってUIを作っていくこととなった。デフォルト画面がもともとAndroidとiOSでだいぶ違っていた。Android側の画面を見て考えられたデザインがiOS側にそのまま適用すべきものか疑念があった。iOS側のデフォルト画面をデザイナーに共有した。iOS側専用に色・フォントサイズなどを考えてもらったので、それを適用した。Android側へ指定されたものを機械的に適用するよりも、適切な見た目のUIとなった。全ての要件が確定していなくても、できる点があれば先に取り掛かるプロジェクト全体の要件が確定していない時期というものがあります。その際も、部分部分の機能やUIなどにフォーカスすると既に実装にかかっても良いくらいに具体化されている場合もあります。その場合は、早速作業を開始すべきと考えます。ある部分は実装し、残りの部分は後回しにする、と言う事をするには、プログラムを機能ごとに分割し独立性の高いコードにしておく努力が必要になります。別々の機能が依存している(一方が無いと他方が機能し得ない)という状態だとこのような事はできないからです。先に実装したのに、後から変更されて無駄になる可能性もないわけではありません。その事態をなるべく避けるためには、実装しなければならない全体のうちどこが固まっておりどこが流動的なのかを把握しておく必要があります。PM、デザイナー、他の開発者と相談するのはもちろんの事、お客様(居れば)の意向やアプリをめぐる事情や各自の立場などを可能な限り把握できるよう、積極的にコミュニケーションを図る必要があります。「開発の事だけ知っていれば良いや」では危ないと考えます。(具体例)未だ要件が確定しているわけではなく開発期間も始まってはいないが、今のうちにやっておけそうなことはないかをPMに尋ねた。一部のデザインはお客様と既に検討を重ねているコアな部分なので、変更の可能性が少ないとのことだった。そのためそこだけでも実装に着手した。悩める時間には限度がある開発作業を進めるうちに疑問や難点に差し掛かる事があります。時間は無限にあるわけでは無いので、なるべく手早く解決して先に進むようにすると良いです。以下、いくつか挙げているが、結局は自分の中でちょっと考えて解決しなかったら他の人の知恵を借りるという事に尽きます。それによって、自分が想定もしていなかった解決策が見つかる事も多いです。技術的に分からない点があるときはインターネットで検索する同僚の開発者などに聞く過去に実装例があれば、そのソースコードを見て参考にする技術書を調べるなどいろいろ解決策があります。一つの手段に拘らず、時間をかけず最良のコードが描けるよう試すと良いと思います。チェックボックスのついたアラートを実装する必要があった。この実装方法が不明だったので、以前見せていただいたサンプルのソースコードを見れないかPMに尋ねた。関連会社の方が書いていたコードであったが、ソースコードを渡してもらった。チェックボックス付きアラートの実装方法が分かり、時間の節約に繋がった。利用規約画面を初回起動の最初に設けたいという要望があった。仕様の詳細についてリモートで(チャットで)話し始めた。1時間程度で仕様・デザインが固まり、午前中のうちに実装を終えるというスピーディな対応ができた。実装すべき要件がそもそも曖昧である、技術的に不可能に近いなどの問題点がある場合。その場合はお客様・PMなどになるべく早く伝えましょう。そもそも曖昧にならないためには、仕様書などをきっちりと作ってもらってそれを共有してもらうのが重要です。時間の関係などで中々作ってもらえない場合もあります。その場合、曖昧さからあとで認識の相違が発生する可能性が飛躍的に高まってしまいます。PMなどに作ってもらえないなら、躊躇なく催促すべきでしょう。いう仕様で実装するかを自分で簡単にまとめて、「これで良いですよね?」と自分から積極的に共有するのも手だと思います。(具体例)電車の時刻表を扱うアプリで、駅の時刻表データは終電終了後にはなくなってしまうこととなる。空白の画面では寂しいので「始発の時間までお待ちください」という文言を入れようかという話になった。始発がまだだから時刻表データが取れないのか、データが誤っているからデータが無いのかの区別が困難である。始発・終電の時間は路線ごとに違うので判定などが複雑になるかもしれない。この懸念点をPMに伝えた。結局、「始発」などの文言は使わず、データが取れない場合一般に通用する文言にしていく方針となった。入っていないなど実装時に使えるか疑義があったのでPMに報告した。データについて再検討してもらった。今も正しいのかどうかPMに尋ねた。新しいスケジュール(一週間ほどテスト時期を伸ばす)を共有してもらい、余裕を持って開発の計画を自分の中で組む事ができた。コーディングがある程度終わったらレビューをしてもらう必要がある。Gitlabプロジェクトがないとレビューができない。そのため、PMにGitlabプロジェクトの作成を催促した。PMはすでに作成していたが、その事を伝え忘れていただけだったのですぐ教えてもらった。iOSアプリで、プッシュ通知を行うという仕様だった。受け取ったお知らせの一覧画面・お知らせ詳細画面などのデザインを検討している様子がなかった。確認のためPM・デザインの方に尋ねた。ことと確認できた(伝達漏れ)。アプリで生体認証を行う際、パスワードを保存する時などにアラートが必要かどうか設計書からでは必ずしも不明だったのでPMに尋ねた。Androidと仕様を合わせる必要があるので、あらかじめAndoroid側のエンジニアにも尋ねた。アラートは不要ということで統一見解ができた。テストでアプリのある挙動がバグとされた。そもそもその部分の要件に不明瞭な点がある事がわかったので尋ねた。そのままだとユーザーの意図に反する動きになる可能性が高かったので、開発者・PMで話し合った上、仕様を固めた。要件が不明確だとテストまで尾を引いてしまうことの一例と言える。生体認証を有効にするかどうかのアラートについて、詳細仕様が不明だったのでPMおよびAndroid側のエンジニアと口頭で認識合わせをした。アラートに「これ以降表示しない」とのチェックマークを入れることになった。チェックを入れると、アプリ再インストールをしない限りは、そのアラートを二度と表示しない仕様にする方向で固まった。レビューをもらうことで気づいていなかった観点でもコードが洗練されるコードを書く際、要件を満たせているかという点が一番大事です。それだけではありません。読みやすいコードになっているか、保守しやすいコードになっているか、後からの変更に強いかなど非機能要件でも考慮すべき点が多々あります。自分が気づいていない観点については、どれだけ考えても改善する事ができません。その意味で、他の開発者のレビューをもらう重要性は高いと言えます。具体的には、コードを書き終わったらマージリクエスト(gitlab)・プルリクエスト(github)を出し、そこで自分が加えた変更点についてレビューをもらうとよいです。レビューをする側にも自分自身の作業があります。そのためレビューをお願いするにしても負担にならないよう気をつけてする必要があります。その点から言うと、そもそもいきなりお願いするのではなく、最初からレビュアーを確保しておき、コードを書く前に大まかな設計について伝えるor合意をとっておきましょう。お願いしても、どういうプロジェクトなのか分からないため余計な時間を取らせる事になってしまいます。人ごとの知識の量・分野の差を認識し助け合う開発時には同僚の開発者、PM、デザイナー、お客様など様々な人と関わる事になります。それぞれが持っている知識の範囲は違います。自分が当たり前と考えている事でも、他の人には分からない場合が往々にしてあります。それに関して他人を責めるのは、よろしいことではありません。知識が無い人でも分かるように説明する・知識が無い人でも無理なくできる範囲のことをお願いする、など工夫をしましょう。知識が全く無い場合は、何かで間違っていたり非効率なやり方をしていても気付きようがありません。他人が何か間違っていたら、自分の知識を積極的に提供し、効率的にすむようサポートすると良いでしょう。iOS版のin-house配布(社内限定のアプリ配布)に必要な証明書・プロビジョニングプロファイルについて、別会社さんが用意してくれるとのことだった。必要なもの(プロビジョニングプロファイル・証明書から書き出したp12ファイル、push配信用のapns証明書から書き出したp12ファイル)を分かってくれているか疑義があった。そのため、これら必要な物をこちらから積極的に伝えた。のち、必要なファイルをスムーズにもらうことができた。apns証明書は開発用でなく本番用の必要があるのに、当初誤った開発用を渡してもらってしまった。製品用というところまで細かく伝えれば良かった、と後悔した。その一方、こちらから必要なものを伝えていなければ、もっとやりとりに時間がかかっていたかもしれないと感じた。したい旨の要望が上がってきていた。対応する方向で話がまとまった。お客様の要望に応える事ができた。後からプロジェクトに入ってくる人にとって分かりやすく記録を残す今はいない後からプロジェクトに入ってくる人もいます。プロジェクトが長期化すればするほどその可能性は高くなります。何年も経ってから保守などのためプロジェクトを見直したいという事もありうるでしょう。その他必要な周辺情報は、なるべく分かりやすくどこかに置いておくと良いです。忙しいと後回しにしがちですが、せめて手が空き次第後からでもやっておきたいものです。素材として使う画像の命名が被っていたので、デザイナーに尋ねた。画像の名前を適切なものに直してもらった。後で見返した人にとって、画像の名前が分かりやすくなった。終わりに以上の内容は社内でも共有していました。PMからは「PMもエンジニア視点でエンジニアの皆さんとコミュニケーションを取れるようになると、プロジェクトが円滑に回るようになると思いました。」というコメントをもらいました。確かに全ての職種の人が、他職種との差異を認識しつつ専門性を発揮することで、プロジェクト全体が上手く回るようになるのかもしれません。弊社の社内環境にご興味がお有りでしたら、ぜひ一度弊社ホームページをご覧ください。Fargateを置き換える存在になるかこんにちは!開発部でインフラエンジニアを担当している斎藤で...2022-03-14メーカー経営企画からエンジニアへ転職〜第二新卒の1年〜開発部第2グループの丸子です。作ってみた開発部の佐藤です。モックサーバ用テンプレート作ってみたテクノロジーパートナー本部開発部サーバサイドエンジニアの佐...2020-06-23複数人で取り組むテスト駆動開発のお話こんにちは、プロダクト開発グループの城山です。5引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。