【開発者視点】プロジェクトを円滑に進める方法

テクノロジーパートナー本部開発部所属の山崎です。

現在iOSエンジニアですが将来マネージャーを目指しています。その関係で、普段から開発そのもののみならず、どうしたらプロジェクトが上手くいくか？と考える事が多いです。

f:id:iridge-tech:20200409192108j:plain

今回は、2020年1月〜3月に業務で経験した点に基づき、気づきをまとめてみました。

お願いされた作業の意味・意図を知っておく

単純に言われた作業のみやっていて意義を理解していないと、本来のその作業の意義が分からないため微妙にズレた方向に行ってしまう事があります。

尋ねて作業の意味が明確化されれば、もっと良いやり方などが提案できるかもしれません。

また逆に、このままでは目的が達成できないということに気付けるかもしれません。

(具体例)

アプリ内で用いている画像の差し替えをお願いされた。が画像の何が変わったかが一見して分からなかった（全く同じ画像のように見えた）。果たして画像の何が変わったのかをプロジェクトマネージャ（以後PMと言います）に尋ねた。何が変わったのかは説明してもらったが、その説明の過程の中でPM自身が、まだ足りてない部分がある事に気づく事ができた。あらためて、正しい画像を用意してもらった。
ある画面についてのデザイン（色、フォントサイズなど）をデザイナーに共有してもらった。それらはAndroid側のデフォルト画面に基づいてデザインされたもので、その画面をカスタマイズするにはふさわしいものだった。iOS側も可能な限りその指定に沿ってUIを作っていくこととなった。しかしデフォルト画面がもともとAndroidとiOSでだいぶ違っていた。Android側の画面を見て考えられたデザインがiOS側にそのまま適用すべきものか疑念があった。ひとまずiOS側のデフォルト画面をデザイナーに共有した。iOS側専用に色・フォントサイズなどを考えてもらったので、それを適用した。Android側へ指定されたものを機械的に適用するよりも、適切な見た目のUIとなった。

まだ全ての要件が確定していなくても、できる点があれば先に取り掛かる

プロジェクト全体の要件が確定していない時期というものがあります。しかしその際も、部分部分の機能やUIなどにフォーカスすると既に実装にかかっても良いくらいに具体化されている場合もあります。その場合は、早速作業を開始すべきと考えます。

ある部分は実装し、残りの部分は後回しにする、と言う事をするには、プログラムを機能ごとに分割し独立性の高いコードにしておく努力が必要になります。別々の機能が依存している（一方が無いと他方が機能し得ない）という状態だとこのような事はできないからです。

先に実装したのに、後から変更されて無駄になる可能性もないわけではありません。その事態をなるべく避けるためには、実装しなければならない全体のうちどこが固まっておりどこが流動的なのかを把握しておく必要があります。PM、デザイナー、他の開発者と相談するのはもちろんの事、お客様（居れば）の意向やアプリをめぐる事情や各自の立場などを可能な限り把握できるよう、積極的にコミュニケーションを図る必要があります。「開発の事だけ知っていれば良いや」では危ないと考えます。

(具体例)

未だ要件が確定しているわけではなく開発期間も始まってはいないが、今のうちにやっておけそうなことはないかをPMに尋ねた。一部のデザインはお客様と既に検討を重ねているコアな部分なので、変更の可能性が少ないとのことだった。そのためそこだけでも実装に着手した。

悩める時間には限度がある

開発作業を進めるうちに疑問や難点に差し掛かる事があります。しかし時間は無限にあるわけでは無いので、なるべく手早く解決して先に進むようにすると良いです。

以下、いくつか挙げているが、結局は自分の中でちょっと考えて解決しなかったら他の人の知恵を借りるという事に尽きます。それによって、自分が想定もしていなかった解決策が見つかる事も多いです。

技術的な面

技術的に分からない点があるときは

インターネットで検索する
同僚の開発者などに聞く
過去に実装例があれば、そのソースコードを見て参考にする
技術書を調べる

などいろいろ解決策があります。一つの手段に拘らず、時間をかけず最良のコードが描けるよう試すと良いと思います。

チェックボックスのついたアラートを実装する必要があった。この実装方法が不明だったので、以前見せていただいたサンプルのソースコードを見れないかPMに尋ねた。関連会社の方が書いていたコードであったが、ソースコードを渡してもらった。チェックボックス付きアラートの実装方法が分かり、時間の節約に繋がった。
利用規約画面を初回起動の最初に設けたいという要望があった。仕様の詳細についてリモートで（チャットで）話し始めた。１時間程度で仕様・デザインが固まり、午前中のうちに実装を終えるというスピーディな対応ができた。

要件・その他の問題

実装すべき要件がそもそも曖昧である、技術的に不可能に近いなどの問題点がある場合。その場合はお客様・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に伝えた。結局、漢字検索・部分一致検索に対応する方向で話がまとまった。お客様の要望に応える事ができた。