議論・開発・分析

2020/9/12

8 月 29 日から 8 月 30 日 にオンラインで開催された DeNA のサマーインターンシップ ソフトウェアエンジニアリングコース|エンジニア職 に参加しました。インターンシップの内 容は、改良の余地が多くあるアプリケーションをインターン生 4 人とメンターさん(DeNA のエンジニア) 2 人でチームを組んで改修していくというものでした。改良点を分析し、 優先順位を決めチーム内で同じ目標を目指して取り組んだことにより、優勝することがで きました。

スケジュール

スケジュールは以下の通りでした。2日間という短い時間で、チーム開発を行い、その 結果を発表(共有)するというものでした。

(開会式のときに公開されたタイムスケジュールでは、1 日目の 19:00 以降は (任意開 発)と書かれていて無言の圧力を感じたのは秘密です。)
自分たちのチームは、21:30 に解散して寝ました。

1 日目

時間 内容
9:30 - 10:00 開会式
10:00 - 12:30 開発
12:30 - 13:30 昼食
13:30 - 17:00 開発
17:00 - 18:00 中間相談会
18:00 - 19:00 チーム振り返り

2 日目

時間 内容
9:30 - 9:45 朝会
9:45 - 12:30 開発
12:30 - 13:30 昼食
13:30 - 15:59 開発
16:00 - 17:00 発表資料作成
17:00 - 18:30 審査会
18:30 - 19:00 チーム振り返り
19:00 - 20:00 1 on 1、休憩
20:00 - 20:30 結果発表

内容

改良の余地が多くあるアプリケーションが渡され、限られた時間のなかでアプリケーショ ンをチームを組んで改良するというものでした。アプリケーションの詳細は伏せますが、 機能面に限らず非機能面にも改修点が多いものでした。

活動

まず、このインターンの課題を確認しました。このインターンでのメインミッションと して、「課題を明確にしエンジニアリング力により各種課題を解決してください」、サブ ミッションとして、「UI/UX にこだわりより良くなるように改善してください」「新しい 価値を提供してください」という課題が与えられました。

インターンの課題が明確になったので、(アプリケーションの)「課題を明確にしエンジニ アリング力により各種課題を解決してください」という指示に従い考え始めます。

私たちのチームは、アプリケーションの問題点を列挙することからはじめました。渡され たアプリケーションは、そのままでは全く使うことができないもので、たった数分で数十 個の改善点が挙げられました。

課題が挙げられた次に、その課題の解決方法を議論します。この段階で、サーバ側で解決 するべき問題、クライアント側で解決するべき問題の分割や、どのように変更することで 短時間で改修できるかという議論も行いました。

解決するべき課題と解決方法が決まれば、次は優先順位の決定です。今回のインターンで は、2 日間という短い時間しかないので、当然全ての課題を解決することができません。 なので、「ユーザにとって何が必要か」ということを意識して優先順位の決定を行いまし た。

解決するべき課題が決まればあとは実行するのみです。チームメンバーは全員で 4 人、2 人がフロントエンド、2 人がバックエンドという役割が割り当てられました。自分はフロ ントエンドを担当しました。各自が得意な部分の開発をすることによって、開発の効率が 上がると考え、自分ができそうな作業は積極的に引き受けました。

開発がある程度区切りのいいところまで到達すると、実際に利用してみて、その問題点の 列挙、優先順位の決定、さらに開発という作業をひたすら繰り返しました。

私が考えて行動したこと

  • 目的、目標をまず考える
    研究室でよく言われいていることですが、目的を明確にしなければ無駄な作業が発生する 可能性が非常に高いです。なのでまず、何のために開発するのか、何を実現したいのかと いったことを明確にしました。

  • 正確な日本語で記述する
    目的や目標を考える際、まず、考えを日本語で記述すると考えが整理されます。日本語 で記述すると、その誤りや不完全さを確認することができます。

  • ユーザをよく見る
    ユーザをよく見ることで、そのサービスのどのあたりに価値があるか改めて知ることが できます。その価値を捨てることなく、サービスを改良することが大切です。

  • 予想するな計測せよ
    予想で行動したり、考えたりしたとしても、それは予想でしかありません。事実、すな わち、計測した結果から考えるべきです。

  • 一人のエンジニアとして、公平な技術選定
    複数人が集まって開発するとき、得意な言語や読みやすい改行位置など、個人の趣味嗜 好は分かれることがよくあります。そこで、自分の意見を押し通すのではなく、他人の 意見を取り入れ公平な技術選定をするべきです。

  • いろんな人の意見を聞く
    特に、デザインを考える際に役立ちます。つくるサービスはおそらく、自分以外の人も 使うものです。自分が使いやすいと感じたとしても、他の人が使いにくいと感じる可能 性もあります。自分のデザイン案より、他者の方がよりよいデザイン案を持っている可 能性もあります。

  • タスクを管理する
    開発を行う際、多くのタスクが発生する場合があります。実際の開発では時間的制約に より、こなすことができるタスクは限られています。優先順位付けをすることにより、 限られた時間での最大の効果を得られます。

  • 実際に動かす
    実際に動かすことにより、新たな問題点を見つけたり、理解を深めることができます。

評価された点

2 日間のインターンにおいて、フィードバックが行われました。

私に対するチームメンバーの評価

  • 意見が偏りそうになったとき戻してくれて助かる
  • チームをしっかりと導いてくれて本当にありがたい
  • 冷静でドキュメントや議論の整理がうまい
  • コミュニケーション量を増やしてそれぞれスピード上げられるようにしたい
  • 情報共有をもっとしたい
  • もっと話かけてきてほしい

2S2B(ツーストライク・ツーボール)1 日目の結果 2S2B(ツーストライク・ツーボール)2 日目の結果

チームに対する審査員の評価

  • 審査員 A

    • 課題の取捨選択までシッカリと出来、一個一個のクオリティはたしかなものだったと 思います。
    • 一個一個のアウトプットのスピードが丁寧かつ早い状態になれるともっとスムーズに 多くの課題をクリアできたと思います。
  • 審査員 B

    • 負荷試験もその分析もしながら進めていたようでしたが、そのような地に足付いた 進め方からか、実際のアプリの挙動はバグらしい挙動もほとんどなく安定していたよ うに感じました。
    • 十分とはいえないまでも着実なチューニングが行われており、トラフィックが少ない 中での体感速度は十分でした。
    • 他のチームの実装したアイデアも参考にしてみるといいでしょう。
  • 審査員 C

    • チーム全体が議論を通じて同じ方向を向いて、みんなで取り組めていた様子でした。
    • 技術的には手堅いところをしっかりと固めて、アウトプットはとても安定したものに なっていました。
  • 審査員 D

    • 短い時間の中で何をして何をしないのかを丁寧に取り組めていた安定感のあるチーム でした。
    • 今後いろんな考え方を吸収して高みを目指して貰えばと思います。

振り返り

今まで私が学んできた「目的、目標をまず考える」や「ユーザをよく見る」ことを実践で 発揮する機会となりました。優勝できたのはこれらの考えを理解し、議論・開発・分析し てくださったチームメンバーのおかげだと思います。この場を借りてお礼申し上げます。
審査員方は「どのチームを優勝とするか非常に悩んだ」と言われていました。私から見て も、どのチームも素晴らしい開発をされていました。同じタイミングでインターンに参加 できたことを誇りに思います。

今後の課題

オンライン開催であったから仕方がないのかもしれませんが、チーム内での情報共有に課 題があると感じました。「他の人が何をやっているかわからない」という問題を解決する 方法として、「もう少し積極的に自分から声をかける」「タスクの進行状況が見えるツー ルを用いる」など、いろいろ考えられます。もし今後オンラインで開発する機会があれば 意識して行動したいです。

リンク

今回、別のチームになりましたが、素晴らしい開発をされていた Nakajima さんもインタ ーンの参加記を書かれています。ぜひこちらもご覧ください。
DeNA のインターンは"何が課題なのか"に向き合う場所だった

記事一覧ページヘ