iOSインターン生 山田の振り返りと学び 〜5月編〜
このページについて
このページは、インターンについて1ヶ月間の振り返りと学んだことをアウトプットしていく記事です。
今月の振り返り
長期目標（2022年3月末まで）
前回の最終目標の改訂版です。サマーインターンの期間を除くと、残り7ヶ月程度です。
- 納期を意識した開発をするため、見積もりと実働工数の差を減らす
- 見積もり通りにタスクを完了させた回数を30回達成させる
- 内部品質に関する理解を深めるため、自発的に行動する
- 自ら品質改善に関するissue、PRの提出、PRへのレビューを合計15回行う
- わかりやすく技術的な説明をするため、iOSアウトプットマンになる
今回の目標
目標に対する振り返り
1. 実装フローを基に見積もりを行い、実際の工数の2倍以下にする
結果：未達成
達成できなかった原因
- 見積もりというより理想の工数で考えてしまった
改善点
- 「自分が見積もりした工数」の3倍はかかると考えて、見積もりを行う方が良い
- 影響範囲を把握できていないため、実装箇所に関わる把握の時間は増やした方が良い
- 勤務時に当日のやるタスクと見積もりを定めて、勤務日ごとに評価した方が良い？
2. 1つのPRにつき修正箇所を5つ以内に抑える
結果：3PRのうち2PR達成
1PRだけ達成できなかった原因
- 可読性に関するのレビューが多く、冗長な変数名で宣言していた
- 修正範囲が広い分、コードの見直しが甘くなってしまった
改善点
- レビュー内容のレベル感に合わせて目標を再設定するべき
- ex) 誤字脱字に関するレビューは0件、可読性に関するレビューは5つ以内、など
- レビューの分析をしてみる → 原因を自身で深く理解することで同じミスを減らす
3. iOSな情報共有の記事をkibelaに4件投稿する
結果：達成
良かった点
- 以前より情報収集する習慣がついたこと
改善点
- iOSな情報共有会を毎週開催して、わかりやすい説明をできるようにする
長期目標達成まで
- 記事：4/30件
- 情報共有会：1/20回
学んだこと
自分一人で解決しようとしすぎて時間をかけてしまったこと
次回の目標（6/19〜7/19）
- 実装フローを基に見積もり工数（×3）を定めて、期限内にタスクを完了させる
- 基準※に沿って、自身で気づけるレベルのレビューを減らす
- 自ら品質改善に関するissue、PRの提出、PRへのレビューを合計2回行う
- iOSな情報共有を4本投稿 & 3回実施
※ 基準について
- 誤字脱字に関するレビューは0件に抑える
- 可読性に関するレビューは5件以内
余談
サマーインターン3社決まりました🙌
そのうち、2社はモバイル開発をやることになるので、 自分自身に活かせるような知識やノウハウを吸収していきます！
プロダクト開発報告
本記事について
先日ユニシス株式会社さんが主催する「DX HACK -User’s voice ”Solve the problem” -」というハッカソンに参加してきました。 そこで今回、どのようなプロダクトを開発したのかを紹介したいと思います！
「DX HACK -User’s voice ”Solve the problem” -」について
今回参加したハッカソンでは、自分たちがユニシス社員の方にヒヤリングを行い、そこから課題を見つけてプロダクトを開発する形式でした。
■日時
5月29日(土)・5月30日(日) 9:00～20:00
■開催場所
オンライン
■賞
- 最優秀賞
- 優秀賞
- CDO特別賞
- オーディエンス賞
■チーム構成
チーム決めについては、運営側がランダムにチームを決めて、当日発表という形でした。 4人チームであり、役割は以下の通りです。
- フロント：2名
- サーバーサイド：2名
（自分以外のメンバーは初ハッカソンでした）
開発したプロダクト
プロダクト名は「モーションブレイク」です。
オンラインでもモーションを交えて、アイスブレイクしようといった意図です。 詳しくは、発表スライドをご覧ください。
モーションの実装では、iOSのライブラリ「Core Motion」を用いて加速度センサを取得し、モーションを判定しました。
デモ動画
分かりにくいですが、「拳を前に突き出す動作」を行うことで、ユーザのスマホ画面に赤ちゃんの画像が共有されるようになっています。
おわりに
結果はオーディエンス賞という結果をいただきました！ （実は、これで入賞5つ目になります）
今後は、もう少し技術的なインパクトを出せるようなプロダクトを開発したいと思います。
iOSインターン生 山田の振り返りと学び 〜4月編〜
このページについて
iOSインターン生の山田です。 このページは、1ヶ月間を振り返りと学んだことをアウトプットしていく記事です。
前提
振り返りを行う理由として、 常に改善を繰り返して、今まで以上にレベルを上げるためです。
最終目標
※今後定量的なものにするためにブラッシュアップ予定です。
インターンを通して身に付けたいこと
技術
- 自ら問題を指摘して、改善提案、実施できるようにする
- 責務、可読性を意識してコードを書けるようになる
- 音声・ライブ配信周りを触れるようになる
技術以外
今月の振り返り
目標設定
- kibelaに振り返りを投稿する
- タスクごとに実装フローを作成して、見積もりを決める
- 自ら問題を指摘して、改善提案を行う
目標に対する振り返り
1. kibelaに振り返りを投稿する
省略
2. タスクごとに実装フローを作成して、見積もりを決める
見積もりと実働工数の差を減らすの最初の段階として、この目標を設定しました。
また、実装フローを作成することで、以下のメリットがあると考えました。
- タスクを細分化し、頭の整理を行うこと
- 社員さんから指摘をもらい、後戻りや不透明化を低減できること
- 見積もりが設定しやすいこと
甘々ですが、以下のように作成しました。
良かった点
タスクの細分化することで整理することができ、 実装する上で理解が不足している箇所を明確化できるようになりました。
改善したい点
見積もりの倍以上の時間をかけてしまいました。 原因は「このくらいで終わる」と想像しながら決めていたからだと考えます。
今までの経験上、実装時にエラーが起きて調査していたら倍以上の時間がかかったことが多々ありました。毎回、このような状況を加味していませんでした。
次回、実装時間以外の事も想定して、見積もりを決めたいと思います。 また、記録も必ず行うようにします。
3. 自ら改善提案を行う
自ら問題を指摘して、改善提案、実施することの最初の段階として、この目標を設定しました。
主に以下を行いました。
良かった点
小さい事ですが、自ら提案することができました。 提案することで、「じゃあやってみよう」と自分の意見が採用されました。
提案しようとすることで、提案箇所について責任を持つことになります。 そのため、責任感の意識が高まりました。（ダークモードや文字列管理も同様です）
また、コードの実装理由を聞くことで、自分が実装する上で気をつけるべき点、影響範囲などを意識することができました。
改善したい点
もう少し技術・ロジック面で改善提案できると良いと思いました。 自分はロジック面が得意ではないので、よく相談することが多いです。（とはいえ、レイアウトも...） だからこそ、そこに意識を向けたいと思います。
その他の学んだことのメモ
CustomViewの生成でクラッシュしたときに確認すること
- CustomViewの方のxibファイルでCustom Classを設定
- outletをfile’s ownerに紐付け
- 全体のViewのCustom Classを設定していないこと
今後，意識してメモしてまとめたいです...
次回のアクション
5/11 〜 6/7までの目標
- 実装フローを基に見積もりを行い、実際の工数の2倍以下にする
- 1つのPRにつき修正箇所を5つ以内に抑え、集計後の割合を80%以上にする
- 自らの質問や相談でコメントをもらうのはノーカウント
- 期間内にマージされたPRを集計して、割合を出す
- iOSな情報共有の記事をkibelaに4件投稿する
余談
私事ですが，3月の研究発表会で学生奨励賞を受賞しました🙌
【惨敗ッカソン】SPAJAMハッカソンの経験を無駄にはしない
こんにちは、Fuyaです。
今回は、SPAJAMというハッカソンを通して学んだことについて紹介します。 本記事の対象は、ハッカソンが好きな学生、または、ハッカソンの出場経験がある方としています。
（記事投稿日と開催した日にギャップがあるのは許してください）
概要
SPAJAMについて
SPAJAMは、温泉でハッカソンを合言葉に、モバイル端末上で動作するアプリケーションの開発という条件で行うハッカソンです。
SPAJAMの第一回予選大会に出場しました。
初めてのオンライン開催で、２日間非常に新鮮でした。
自分たちが作ったサービス
自分たちが考えたアイディアは、「クセツッコミ」というサービスです。
自分で無意識に行っている癖をアプリで検出し、音声のツッコミで注意するといったサービスです。
以下、イメージ動画です。
結果
12チーム中、4チームが入賞できます。 しかし、自分たちのチームは入賞すらできませんでした。
こんなツイートしていたのですが、 https://twitter.com/gamegamega_329/status/1299363145442418689?s=21
見事に返り討ちにされました。
ハッカソンを通しての学び
さて、ここからが本題です。 今回のハッカソンは、結果が出なかったものの、 多くの失敗や学びがありました。
特に、チームマネジメントやアイディア出し、設計・開発の観点から学ぶことができました。 本記事で紹介するのは、ハッカソンで活用することに限定せず、今後の他の場所でも活かせるような学びも含めています。
以下の3つです。 - 役割を明確にすること - 納得しても必ず疑問を持つこと - 技術選定の視野を広げる
役割を明確にすること
チームマネジメントの観点で説明をします。
ハッカソンの2週間前にミーティングの時間を設け、役割分担決めを行いました。当初は、ハッカソンで作成する上で、Webアプリケーションとネイティブを混ぜることで、アイディアの選択肢が広がると考えていました。
しかし、チームメンバーに上記の意図が明確に伝わっていないという問題が起きました。お互い曖昧なままで進めてしまい、途中まで複数のプラットフォームで準備しつつも、最終的にWebは使わないという結果に至りました。Webアプリの環境を準備したメンバーには無駄な時間を使わせてしまったのです。
この場合、相手が理解しているか注意深く伺うべきだったと思います。 チームをマネジメントする上で、相手にわかりやすく説明をして、合意を必ずとることが重要だと実感しました。
納得しても必ず疑問を持つこと
続いて、プロダクトオーナーの観点で説明をします。
アイディア出しは、強制的に短時間でアイディアを出すクレイジーエイトというフレームワークを利用しました。アイディア出しは昼ごろから始めたのですが、チーム全員が納得いかず、全部で4時間ほどかかりました。最終的にアイディアを決める要因になったのは、オズボーンのチェックリストを利用した時です。 自分が少し捻ったアイディアを出すことができ、上記で説明したクセツッコミを考案しました。
しかし、少し捻ったアイディアを出すだけで満足してしまいました。結果的に深堀りができず、エンタメ要素が薄いアイディアになってしまいました。
この場合、プロダクトのコアの部分を決めた後、エンタメ要素のある体験をするためにはどうすれば良いかを考えるべきでした。１つ目の学びでも関連しますが、Whyや「誰を」「どんな状態にしたいか」を考えるのが甘いと感じました。
技術選定の視野を広げる
最後に、設計・開発の観点で説明します。
「クセツッコミ」のクセは、貧乏ゆすりの癖と口を開ける癖を対象にしました。貧乏ゆすりはポケットにスマホを入れていることを想定し、スマホ内蔵の加速度センサから貧乏ゆすりの揺れを検出します。口を開ける癖はフェイストラッキングから口の特徴点を追跡し、特徴点の変化量から口を開けているかどうかの判定を行いました。これらを踏まえて、SwiftのARkitとCoreMotionというフレームワークを利用しました。
結果的に完成することができました。しかし、技術的なチャレンジ要素が弱いと感じました。センサ値の閾値判定で癖を検出していましたが、完成度を上げるために、機械学習を用いて個人差の対応をすることもできたと考えます。口を開ける癖に関しては、話す動作も混同しているため、分類精度の検証をすることもできたと考えます。このように技術の活用する幅を広げていくべきでした。
まとめ
今回はSPAJAMハッカソンに参加して、以下の学んだこと3点について説明しました。
- 役割を明確にすること
- 納得しても必ず疑問を持つこと
- 技術選定の視野を広げる
一つ一つ学んだことを改善していき、少しずつでも良いので今回の経験を成長に結び付けたいと思います。
【行動力の塊】育成&問題解決型のハッカソンを開催してみた
はじめに
どうも！Fuyaです。
約３ヶ月間にわたって、学内初のオンラインハッカソンを企画し、運営を行いました。
本記事では、運営として行った活動を振り返り、そこから得た学びについてアウトプットしていきます。
FunLocksとは
2020年、コロナ禍の影響により物騒なニュースが次々と流れ込み、自粛生活で人と交流する機会が格段に減りました。本来学生は仲間と交流を楽しみながら大学生活を過ごしますが、自粛生活によって自由が奪われてしまいました。
そこでこの問題を少しでも解決していけるように、以下の２点を目的としたハッカソン「FunLocks」を開催しました。
- 開発コミュニティの場を活用して，プロダクト作りを楽しんでもらうこと
- 情報大学として情報技術を活用し、コロナ禍の問題意識を持ってもらうこと
これらをもとに「コロナ禍に大学などで使いたいプロダクト」というテーマで行いました。
他の詳細については、下記のWebサイトを確認してください。 funlocks.github.io
開催経緯
なぜ運営をやろうと思ったか
まず、私がハッカソンの運営をやろうと思った経緯について説明します。
そもそもハッカソンとの出会いは、今から2年前（2018年）に開催されたP2HACKSという学内ハッカソンでした。P2HACKSを通して、私は今までにない悔しさや自分の無力さを痛感しました。 以下の記事に悔しさが溢れ出ているので、チラ見しても良いかもしれません。
P2HACKSから大きく成長したいと思い、血の滲むような努力をしてきました。 その結果、学外のハッカソンで優勝することができました。
この時、「未経験でも必死に努力することでいつかは報われることもあるのか」と思うようになりました。学生のうちに必ずハッカソンの運営をやって、人のために良い影響を与えたい。これがハッカソン運営をやろうと思った経緯です。
当時運営をやるとしたら、以下の2点を実現したいと考えていました。
学内ハッカソンとして企画
続いて、ハッカソンを企画するまでの経緯を説明します。
ハッカソンを開催するために、動き出したのは2020年7月くらいです。最初は連絡手段があったCode for Hakodateや未来大OBの方々と相談し、知見を吸収していきました。
スポンサーとの稟議やお金が絡むことから、学内ハッカソンでやる方がスムーズだということでお世話になったP2HACKSの関係者と打ち合わせをすることになりました。既に大学側から「コロナ禍を踏まえ、インドアロケーション技術を利用したプロダクト開発をして欲しい」という要望があり、私自身も問題解決型のハッカソンをしたいということから、これらを組み合わせたテーマで考えようという方向性に決まりました。
運営体制
どのような体制で運営をやっていたのか簡単にご紹介します。
ステークホルダー
FunLocksの関係者は以下の図の通りです。
本来は運営メンバーが6名いましたが、多忙により2名去ってしまうというアクシデントがありました。しかし、企画前に相談してくれたCode for Hakodateの方や未来大OBの協力もあってギリギリ運営していくことができました。
利用ツール
主な利用ツールは以下の通りです。FunLocksの準備期間・当日で利用しました。
- 基本的な情報共有：Slack
- 開会式&発表会：Zoom
- 開発期間中：Discord
ツールの導入コストやスポンサー企業の学習コストも踏まえ、大学でも日常的に利用しているSlackとZoomを利用しました。（最近よく聞くNeWorkやremoも一応検討していました）
今回はオンライン開催であり、開発期間中に参加学生の様子を可視化するため、FunLocks用のDiscordサーバを準備しました。開発中は自チームの部屋に入ってもらうように徹底しました。運営やメンターが待機することで学生が質問をしやすい環境作りも行いました。さらに、Discordにもテキストチャンネルがありますが、情報が分散すると運営が学生の動きを把握できないと考え、全てSlackで連絡を行いました。
結果としては、どの関係者も不満なく活動できたのかなという感触です。アンケートでも情報が分散していないところが良かったという評価をいただきました。
活動スケジュール
- 7月下旬：Slackのワークスペース設立
- 8月：スポンサー依頼資料のたたき台作成
- 9月下旬：エントリーフォーム作成、スポンサー募集開始
- 10月：エントリー開始，宣伝開始、勉強会の検討
- 11月上旬：勉強会告知、メンター確定、評価項目の検討、スポンサー企業確定
- 11月下旬：勉強会実施、商品検討、評価項目確定
- 12月上旬：スケジュール確定、スライド作成、商品確定
7月にワークスペースを作成しましたが、自分の研究や運営の勧誘などが上手くいかず、運営の活動開始が遅くなってしまいました。 また、全体的に情報の開示が遅いので課題となりました。
FunLocksの開催
当日スケジュールはこんな感じでした！
本番は司会進行はスムーズに行うことができました。（思っていた以上に企業さんから好評だった🤔）
評価項目について
一番悩んだ部分がハッカソンの評価項目です。ハッカソンでは肝となるので、慎重に議論を進めました。
学外のハッカソンでは、プロダクトの「完成度」を評価項目としていることが多いと思いますが、FunLocksは入れませんでした。
理由として、以下の2点があります。
- 開発未経験の学生のモチベーション維持のため
- プロダクト開発だけでなく、アイディアや問題解決方法にも意識を持ってもらうため
「完成度」は開発の経験値に比例してしまうため、自分たちが考えたアイディアはどのような問題を解決できるかという観点でプロダクト開発を考える人が少ないと思います。誰かのために技術を利用して問題解決を行うことを早い段階で意識して欲しいと考えました。評価項目に対する不満を持っている人がいなかったので比較的良かったと思います。
自己採点と今回の学び
自己採点
結論からいうと、75点でした。
内訳としては、やるべきことをやり遂げたので60点です。FunLocks当日の反応が思った以上に良かったこと、自分で立てた目標を達成したことでプラス15点です。減点したところは、参加学生やスポンサー企業への情報共有の遅さから不安を抱かせてしまった点です。
次にこれらを踏まえて、良かった点と改善点について詳しく説明します。
良かった点
良かった点は2点あります。
1点目は、目的や目標を持つことで、厳しい運営体制でも最後まで運営をやり切ることができた点です。
途中で人数が減ってしまったり、学会と重なって時間を割けない時期があったりと厳しい状況でした。しかし、なんとしても後輩に成長できる機会を提供したいという想いがあったため、なんとかやり遂げることができました。途中からは楽しみながら作業できていました。今までは目的や目標を持つことで得られる効果を実感できていなかったため、貴重な経験を得ることができました。
また、運営メンバーが少ないため厳しい体制でしたが、学生だけでなく社会人や教員にも協力してもらうことで対策していました。（人任せかよって思った方ちょっと待ってください） 基本は学生主体で進めますが、評価項目やスポンサー企業との稟議などは学生のみで決めるのは難しいため、サポートしてもらうことで進めていくことができました。良い意味で周りの人を巻き込むことができたと思います。
2点目は、苦手意識のある司会進行を克服した点です。
当初は人前で話すことが得意な同期にやってもらう予定でした。しかし、途中で脱退してしまい、代表である私がやることになりました。アドリブで話すことは非常に苦手でした。では、どのように克服したかというと、進行シミュレーションを沢山行いました。流れとしては以下の通りです。
台本を作成
↓
スケジュールごとに参加者からどのような反応が欲しいかを想定する
- オンライン環境でも盛り上がる雰囲気を作るため
- イベントを終えた後に運営側の目的が達成できるかの観点で確認
- 例: 8888とかのリアクションが欲しい、注意事項の説明は真剣に聞いて欲しいなど
↓
スケジュールごとに発生する可能性のある問題を洗い出す
- リスク管理のため
- 例: ネットワークの不具合、発表者の失踪など
↓
問題に対しての対応策を考える
- 即座に対応するため
- 例: 別PCの準備、司会者代行の準備など
これらを行うことで、当日の司会はスムーズに進行することができました。さらにアンケートにも司会が良かったというお声をいただきました。 当たり前のことですが、先を見据えて準備することが結果につながったと思います。
改善点
改善点は全体的に動き出しが遅かった点です。正直、これが全てだと思います。
原因としては以下が考えらます。
運営集めや個人のスケジュール管理が上手くいかないこともあり、徐々に予定が押してしましました。その影響で参加学生やスポンサー企業への情報共有の遅くなり、参加学生に十分な勉強期間を与えることができませんでした。
改善するならば、ハッカソン当日までの全体像の把握を早めに行うべきでした。当日までのスケジュールを作成しても、やるべきタスクが見えていない状況が多々ありました。ここを改善できれば、少ないリソースの中でも早めの情報共有ができたと思います。
今回の学び
良かった点と改善点を踏まえ、以下の項目について学びを得ることができました。
- 目標や目的意識の重要性
- 楽しむことの重要性と難しさ
- 先を見据えることの重要性
最後に
今回はハッカソン運営をやったことについて振り返り、その経験から得た学びについて紹介しました。
3年次にプロジェクト学習でリーダーを務めていましたので、その経験を活かす場にもなりました。自分で設定した目標を達成できたことは貴重な経験になりました。
今回の学びや経験を次に活かす事が重要だと思うので、これからも挫けずに前に進みます。
おまけ
イベント後のアンケート実施したのですが，参加学生とスポンサー企業共に満足度が6点満点中平均5.2という結果でした！
未来大学賞の受賞も決定！
↓公式サイトにも掲載されています。
今年の目標〜2021年ver〜
どうも、Fuyaです。
今年の目標について紹介します。
大きく3つあるので、それに対してちょっと届きそうなレベルの「お気楽な目標」と相当努力が必要なレベルの「気合な目標」を挙げていきます。
研究
お気楽な目標
- 自分の研究の具体的な手法を確立する
- 機械学習を全体的に学び、初めての人でも理解できる入門スライドを作成する
気合な目標
- 修士として学会で1度でも良いから受賞する
アルバイト
お気楽な目標
- 見積もりと実働工数の差を減らす
- UX周りの改善提案をして、実装する
- 毎月学びブログを書く
気合な目標
- 新機能を実装する（そもそもない可能性もあるけど...）
- バイトのブログに掲載する
iOS開発
お気楽な目標
- Combineを理解して、ブログにアウトプット&OSS公開
- Swift実践入門を見ながら、Swiftの知識をつける
- 自作ライブラリ作ってみる
気合な目標
- アプリをリリースする（アイディア・時間的に努力が必要）
この御時世で低迷期に？
感染症拡大が徐々に止み、ようやっと外へ！
と、思った矢先にまた感染者報道...。
いつまで続くのでしょうか。
夜の店での感染は多いと聞くせいで、飲み会へ行く勇気がありません。
そんな日々を過ごしているF Lifeのお時間がやって参りました。
最近は家に引きこもりがちで非常に危ない匂いがしています（変な意味ではありません）。
すごく憂鬱な気分に晒されているからです。これって低迷期なんですかね。
研究やバイトで上手く行かない日々に追われてしまっていたり、それらの両立ができていなかったりと全体的に上手くいかないんですね。
ただ、「これデファクトスタンダードですよね」と自己暗示をしているのですが、僕のメンタルは素直に受け止めてくれません。
そのため、稀に一日中寝たきり生活になることもあります（モチベ問題）。
さすがにうつ病などのストレス障害にはなりたくないので、多少は這いつくばっています。
そんなモチベ問題を改善するために色々対策を練ってきました。
大事だと思われる行動は、以下だと思います。
- 外の空気を吸うこと
- 軽い運動すること
- 楽しいことひたすら考える
- zoomとかでも良いから人と話す
- 朝に山岡家を食す
しんどいな〜〜って時は最低限これやると生き返ります。
特に朝山岡家。
（最近の僕は山岡家中毒&朝ラーにどハマりなんですが、これを注入することで生きてる実感が湧いてくる）
まあ、結局こういうのは意識や思い込みでどうにかなってしまうものです。
（環境によっては異なりますが）
上記の項目に読書などを追加するとさらに豆腐メンタルは改善できそう...。
頑張りすぎると良くないので、「頑張る」とは言いませんが、
諦めずにやることはやって、楽しんでいこうと思います。
以上ですが、こういう低迷期のような時こそ記録してどのように改善していくか考えるのも重要だと考えています。
さあ、明日は早く起きてラーメンを食べに行きます。
