得意分野を活かせない中、悩んで足掻いた開発研修
誰もが通る道である仕事の開発研修が無事終了しました。 色々問題だらけで、自分自身の力不足を痛感する日々を過ごしました。 その分、収穫もたくさん得ることができたと思います。
そこで本記事では、仕事の開発研修を通して学んだことについて述べていきます。 何を作ったか？ではなく、自身の行動に焦点を当てて振り返りを行います。
研修内容
概要
あらかじめ定められた3つのテーマの中から一つを選択し、 そのテーマに沿ったプロダクトをチームで作り上げるといった研修内容です。
1チーム 9人でエンジニア6人、デザイナー3人で構成されています。 また、エンジニアはそれぞれ別職種でフロントエンド、バックエンド、SRE、MLなどです。
最終日には、役員に向けて発表を行い、フィードバックを受けます。（内容によっては社内で運用できるらしい）
作ったプロダクト
仕事でお世話になった社員や、対面で話したいと思う社員などが出社した時に、Slack上で通知してくれるプロダクトを開発しました。
プロダクトを作る背景として、普段からSlackやオンライン会議で業務を行っていることから、出社時に社員と交流しづらいといった問題がありました。
自身のやったこと
箇条書きでざっと述べます。
- チームリーダー
- フロントエンド（Next.js + TypeScriptでAPI通信周りを担当）
- プロダクトの課題深掘りのためのアンケート作成
- ミーティングのファシリテーター
- プレゼン資料やコードなどレビュー系
- 別職種のメンバー同士の調整
チームのメンバーが多種多様なアイディアを出し合うのに対して、私はそのアイディアをまとめる役を行っていました。
自身の取り組みにおける良い点 / 問題点
良い点
- 反対意見があった時に、メンバー同士で調整を行い、全員の合意を得たこと
- 会議のアジェンダで定めたゴールを必ず達成できたこと
- 議論を行った後にドキュメントを作り、認識を合わせを行ったこと
- 毎朝Slackの一言報告の際にユーモアを仕込み、数人のメンバーにユーモアを浸透させることで、チームの一体感を少し上げたこと
- メンバーからのコメントで、リーダーとして安定感があると言われたこと
問題点
- ミーティングの時間が長引いて、メンバーの生産性を下げたこと
- 問題が起きた時にすぐ対処できず、後回しにしたこと
- 自分の知らない領域のタスク把握ができていなかったこと（特にバックエンド）
- 時間の管理が甘いこと
- リーダーの立場を活かして、意思決定やリードする動きが少なかったこと
- 余裕がなかったため、成果物や議論に対する改善コメントが少なかったこと
- メンバーの意見を求めすぎて、優先度の低い事柄に対しても全員で決めようとしていたこと
次に向けて
まずは安定感を手に入れたいと思います。 まだ知らないことが膨大にあるので、早く現場に慣れて、安心して仕事を任せてもらえるようになる必要があります。 そのために自主的に行動し、小さくても良いので成功体験を積み重ねたいと思います。
さいごに
自身の得意分野を活かせない環境でも、チームに貢献することができました。
再現性のあるスキルではなくとも、今後の引き出しになれば良いなと思います。
全然ユーザに寄り添っていない件について
最近、私はユーザに寄り添っていないプロダクトを考案し、開発していることに気づきました。 私はユーザの課題やプロダクト視点で開発することが好きでしたが、アプローチベースでアイディアを考えることが多くなりました。
本記事では、ユーザに寄り添っていないプロダクトを考案した北海道アプリコンテストにおける活動・思考について振り返りを行い、自分の意識改善につなげたいと思います。
コンテストまでの活動
活動の流れは以下の通りです。
- 企画
- 設計・実装
- 発表資料の作成・当日発表
次に活動内容と反省点を紹介します。
企画
テーマ性に沿ったアイディアを考えるため、以下のmiroのように、カテゴリごとにアイディアを出しました。
カテゴリ間のアイディアを掛け合わせることで、より面白いアイディアを生み出す予定でした。
アイディア出しの様子
設計・実装
アプリデザインや実装は以下の通りです。
デザイナーがいないため、1つの画面のみで表現するシンプルな設計にしました。
iOSは1人、データ分析は1人という分担でした。
反省点
反省点は、2点です。
企画時の
- 課題の深掘り、分析が足りない
- 課題の解像度が低い
自分たちが開発したプロダクトには、ユーザがこのプロダクトを利用することで幸せになるかという点で欠けていました。
実際にロジックツリーで分析していく中で答えに辿り着きました。
以下の動画が、課題の解像度を上げるために参考になりそうです。
最後に
北海道アプリコンテストの振り返りを行いました。 この振り返りを通じて、冒頭に述べたアプローチベースでアイディアを考えてしまう原因として、「インパクト与えたい」という思いが先行したためと感じました。 ハッカソンやコンテストでは、アイディアのインパクトにも強く影響します。 しかし、課題ありきのアプローチになると思うので、どちらが先行しても、課題の深掘りを行う必要があると思います。
技術力に不安を抱えていた学生がたった一つの「悔しさ」を「行動力」に変えたことで得た気づき
Fuyaです。
タイトルにもある通り、私は元々技術力に不安を抱えていました。しかし、ある出来事によって生み出された「悔しさ」を「行動力」に変えたことで、私の人生は一転しました。
そこで今回、自身のエピソードと気づきをまとめてみました。最後まで目を通していただけたら幸いです。
目次
「悔しさ」を生み出したきっかけ
私が学部2年の終わり頃、学内ハッカソンに初めて参加した時に、「悔しさ」を生み出すきっかけとなりました。
当時私は開発経験もほとんどなく、プログラミングも得意ではなかったので、将来の就職が不安でした。どうしてもこの状況を変えたい、何か良いきっかけになるのではないかと思い、学内ハッカソンに参加しました。私はチームリーダとして、チームをまとめながらiOSアプリの開発を行っていました。しかし、ハッカソン中チームの連携が上手くいかず、未完成のまま発表し、悔いが残る結果となりました。
この時、私は人生の中で一番の「悔しさ」を感じました。周りの知り合いはたくさん受賞している中、自分たちは結果も残せず、プロダクトも未完成であり、チームメンバーも少し雰囲気が悪い状況だったからです。チームリーダだった私は責任を感じて、「自分は本当に何もできない人間だなぁ」と悲観していました。
それと同時に、「もし自分が誰よりも成長できたら、参加していた人たちを見返せるかも」という考えにも至りました。なぜこのような発想をしたのかは正直覚えていませんが、後から友人に言われて気づいたのですが、根っからの負けず嫌いだったのでは？と今は思っています。
この経験が自身にとって重要なターニングポイントとなり、今後自分を大きく成長させたのです。
「行動力」を発揮した経験
自身の成長につなげるため、私はどんなことにも挑戦しました。当時の私は、何が自分に向いているのかわからず、とりあえず迷ったら行動してみようという考えでした。
一つ一つ挙げていくとキリがないので、ここでは概要と別記事を紹介します。
- PBLで40人規模のプロジェクトのリーダーを務める
- ハッカソン9回参加
- 企業インターンに8社参加
- 学内ハッカソンを自身で主催
- 思い切って大学院進学 & 学会発表に3回参加
もう少し詳しい内容は、以下の記事に載っています。
正直、前述していた「悔しさ」がなければ、ここまで必死に活動していなかったと思います。 今改めて振り返ると、過去に自分にはない「行動力」を発揮できたなあと思います。
経験から得た気づき
「悔しさ」を「行動力」に変えて、多くの経験を積むことができました。
これらの経験をもとに、大きく3点の気づきを得ました。
- 自分の意志で行動し続け、最後までやりきること
- 常にWhyとHowを意識して言語化すること
- 関わる全ての人の幸せを考えること
エンジニアだけに関わらず、どの職種にも言えるようなことだと思います。人によっては当たり前すぎると思った方はご了承ください。
自分の意志で行動し続け、最後までやりきること
ハッカソンに何度も出場し続けたことで気づきを得ました。
私は冒頭で説明した「悔しさ」を常に感じており、どうしてもハッカソンの土俵で結果を残したいという意志（=目的）を持っていました。
最初に参加したハッカソンは散々でしたが、挑戦し続けることで、徐々に実装力も上がり、期間内にプロダクトを完成させることができるようになりました。少しずつ開発時の応用が効くようになり、ユーザ目線でプロダクトを考え、技術的に挑戦することでプロダクトの実現性を高められるようになりました。その甲斐あって結果にも結びついていきました。
私は今回の経験を通して、自身の意志の元で、長期的に何度も挑戦し続けたことに意味があったと思います。「最後までやり切ろう」なんてどこでも言われていると思いますが、実際自身の意志で継続できる人は少ないと思います。就活時に多くの学生と会いましたが、やはり自分で考えて物事に取り組み続けている人ほど優秀な学生が多いと思いました。
学生のうちは何か課題を与えられ、それ通りにこなすことを当たり前のように行ってきました。しかし、これからは正解のない世の中に対して、自身の意志で物事を決めて、やり遂げる必要があると思います。周りからの批判や馬鹿にされることもあると思いますが、それでも自分を信じ続けたものには必ず見返りがあると思います。
常にWhyとHowを意識して言語化すること
どの経験にも共通して言えることですが、今回は企業インターンの経験を踏まえて説明します。
業務を行う中で、自身で課題を発見し、改善提案を行う場面が出てきます。ただ、その課題に対して「なぜその課題を解決する必要があるのか」、「解決に向けてどのように実現するのか」を必ず明らかにする必要があります。さらに自分自身が理解していれば良いのではなく、相手に伝わるように説明を行い、納得してもらう必要があります。私はインターン中に何度か提案しましたが、上手くいきませんでした。原因の一つとして、WhyとHowの深堀り不足とそれに対する言語化が足りていなかったためです。目的を明確にしていれば良いわけではなく、それを実現して会社にどのような利益があるのか、やるべきタスクで溢れている中でそのタスクは本当に優先すべきなのかをさらに掘り下げていく必要がありました。また当時私は説明する際、話が長く、端的に何を伝えたいのかわからないような説明をしていました。伝えるべき内容があっても、相手には伝わらない状態がありました。
私はこれらの経験を通して、本質を捉えるための手段について経験することができました。実際の現場に出くわすと、意識しても実践することが難しいと考えます。
関わる全ての人の幸せを考えること
学内ハッカソンの運営の際にこの気づきを得ました。
最初私は学内ハッカソンの運営を行う上で、参加学生に満足してもらうことしか考えていませんでした。そんな時、ふと私は、「ハッカソン関係者への配慮が足りなすぎて、不満に思っているのではないか？」と考えました。相手の立場になった時、色々業務時間を割いて協力しているのに、得られるものがないまま終わるなんて...協力したいと思えない。そこで私は、ハッカソンの関係者全員がハッピーな状態を作りたいと思い、ハッカソン参加する上で不安感を与えないように、案内のドキュメント作成、学生との交流機会を提供を意図的に行いました。不手際な点も多かったと思いますが、それでも参加学生とスポンサー企業の双方から、「参加して良かった」「今後も続けてほしい」という声をもらいました。
私はこのハッカソン運営を通して、エンジニアの立場でも応用できることにも気づかされました。エンジニアも周りの開発メンバーや別領域のデザイナー、ビジネスサイドにも目を向ける必要があります。例えば、相手に伝わるように専門用語を噛み砕いて説明する必要だと思います。直接的に関わる相手だけでなく、その周りにも気を配ることができると、価値のある人間に成長できると思います。
気づきを踏まえ伝えたいこと
私は多くの経験を通して、たくさんの気づきや学びを得ることができました。
実装力や技術的な知識量は他の学生よりも劣っていても、私は今までの経験が武器になっているので、自信も少し持てるようになりました。
よく「技術力がないから、自分は無理だ」と言う方を何度か見てきました。
そのような方は、自分にこう問いかけて欲しいです。
そもそも技術力ってなんだろう？コード書くことが全てなのか？本当に自分たちでは成し遂げられない？って
コード書くこと自体は経験を積むことで補えます。それよりも重要なことは沢山あります。それを自分で探し求めて欲しいと思います。
さいごに
ちょっと長めで拙い文章だったと思いますが、目を通していただきありがとうございます。
技術力に不安を抱えていた私ですが、行動することで多くの経験や学び、そして自信を得ることができました。
この記事を通して少しでも誰かのお役に立てれば幸いです。
【充実界の総長】怒涛の大学生活を振り返る
はじめに
Fuyaです。
就活の幕を閉じたということで、自身の大学生活で得た経験を紹介しようと思います。
主に学部3年から修士1年の今日までを範囲としています。 結構殴り書きなのですが、ご了承ください。
大学生活で得た経験
ハッカソン
Why
ハッカソンに参加する理由は、チームで短期間で面白いと思えるプロダクトを作り切るところに面白さを感じていたためです。
What
ハッカソンは全部で9回参加しました。後半は受賞率高めです。😊
実際に作成したプロダクトは以下のようなものがあります。
How
後半になって受賞率が上がっていることがわかります。では前半と後半では何が違うのか。 以下の通りです。
- 圧倒的ユーザ目線で開発
- チーム全員が使いたいと思えるか徹底的に議論
- ユーザに価値を届けるために、発想力や実装力の強化
ちなみに、ハッカソンに対する熱量が高すぎて、自身で主催した経験もあります。興味ある方は別記事にまとめているので、目を通していただけると幸いです。
インターン
Why
- 技術的な知識や業務経験を積むため
- 就活に向けて会社を知るため
What
実際にインターンに参加経歴は以下の通りです。
他の学生よりもインターンに参加している回数が多いと思います。 単純に学生のうちに多くの会社を見ておきたいという考えでした。 ちなみに、技術力で採用されたというより、価値観や開発時の考え方がマッチして採用してもらったという認識です。
How
インターン中では、以下のような点を意識していました。
- 自分で考えて、解決を目指して、自走力を意識
- 提案して実践
- 情報の不透明さを解消
- FBをもらって改善・次の機会で活かす
- 巻き込み力
- 圧倒的な当事者意識を持つ
研究
Why
大学院に進学した理由は、大きく2点です。
- キャリアの幅を広げるため
- 陳腐化しないスキルを身につけるため
What
他の大学院生と変わらないと思いますが、以下のような活動を行っていました。
- 企画から実装、評価まで自分で考え実施
- 研究室メンバーへのレビュー
- 論文を書き、学会で発表
学会投稿・発表の実績
学会発表は3回行いました。
- 学部4年
- 修士1年
- マルチメディア，分散，協調とモバイル(DICOMO2021)シンポジウム
学部4年次では、ハッカソンの運営と同時並行で作業していたので、非常に大変でした。
おわりに
ざっと自身の経験と成果を振り返りました。 多くの経験を重ねるだけでなく、良い評価も得ることができたのは非常に貴重な機会でした。
次回、今回紹介した活動を行う上で、自身を突き動かした原動力、そこから得た気づきを紹介していきます。
Sansanで強みの活かし方を学んだサマーインターン2021
本記事について
2021年の夏に1ヶ月間、Sansanのサマーインターンに参加した山田楓也です。
私はSansan Engineering Unit Mobile Applicationグループに配属し、「会社フォロー」という案件を担当しました。
本記事では、インターンを通しての学びについてご紹介します。
目次
参加目的
Sansanのインターンに参加した目的は大きく2点あります。
1点目は大規模なプロダクト開発を経験するためです。特にSansanのiOSアプリは画面数100以上で構成されています。そのため、大規模の開発で自身の業務経験がどこまで通用し、何が足りないかを見つけたいと考えていました。
2点目はプロダクトに魅力を感じるSansanの雰囲気を体感するためです。プロダクトに魅力を感じる要素として、プロダクト1つで人脈管理から人脈データの活用まで可能である拡張性や、リモート環境におけるビジネスの人脈形成を可能とする将来性が挙げられます。
目標設定
目的達成のために2つの観点から目標設定を行いました。
以下の通りです。
学んだ技術や知識についてアウトプットしたいと考え、自己成長に向けた目標も掲げました。
業務内容
それでは、実際に行った業務内容についてご紹介します。
大きく2点行いました。
- 会社フォロー案件
- LT会の運営
会社フォロー案件
Sansanアプリは名刺管理を主軸にしており、名刺情報から人脈形成につなげる複数の主要機能が存在します。名刺交換以外の主要機能として、フィードという名刺交換した相手の企業情報を受ける機能があります。フィードから企業情報を受け取るためには、名刺交換をすることが前提となっています。
そのため、名刺交換せずとも相手の企業情報を受け取ることを目的として、会社をフォローする機能の追加を行いました。
処理の流れとしては以下の通りです。
フォローボタンのレイアウトの作成からAPI通信まで行いました。
クラス図の作成
また、全体像の把握やタスクへの位置付けを示すため、クラス図を作成しました。
クラス図を作成することは初めてだったため、メンターさんに教わりながら作成しました。
LT会の運営
LT会のテーマは、「効率化のための＜推しツール/推しポイント＞」です。
各々知らなかった効率化を取り入れてチーム全体の生産性向上につなげることを目的としています。
自身の役割は以下の通りです。
- 企画情報の共有
- 司会進行
- 発表者（テーマ：Notionメモツールについて）
業務以外の活動
業務以外にも他のイベントに参加したため、ご紹介します。
勉強会への参加
勉強会は毎日お昼休みの時に開催しています。
私が参加した勉強会の内容は以下の通りです。
- RxSwift
- modern autolayout
- Human Interface Guideline
- デザイナーの体験設計
- など
基本的には、書籍を読みつつ気になった点を参加者と議論し合いながら進めます。
デザイナーの体験設計は、デザイナーが普段どのような考えでデザイン作成しているか、他領域の方がデザイナーに質問し合う勉強会です。
勉強会に参加して、社員さんがSansanのプロダクトを主軸に議論しているところに強く印象に残りました。
マネージャー職の方とランチ
勉強会の他にも、社員の方とランチをする機会がありました。
私は自身のキャリアプランの解像度を上げるため、マネージャー職の方とのランチを希望しました。
結果的に、PdMやCTO、グループマネージャーなどの方々と話す機会をいただきました。
視座の高い方とお話ができ、とても貴重な時間となりました。
学び
続いて学びについてご紹介します。
今回のインターンで以下の学びを得ることができました。
- 強みの活かし方
- クラス図を用いた全体把握と活用方法
- VIPERアーキテクチャの理解
- テストコード
- など
特に苦労した点は、自身の強みの活かし方です。
まず自身が自覚している強みは「行動力」です。具体的には「自発的に改善提案する力」があると自負していました（自称）。しかし、今回のインターンでは、「自発的に改善提案する力」を生かすことができませんでした。
理由は、既にiOSチームの中でプロダクトに対する改善提案が行われており、自身の改善提案だとインパクトが弱いためです。インパクトのある改善提案を行うには、課題の重要性、具体的な改善策、改善に必要なコストなどを考慮する必要があります。強みを生かすためには、質を上げる必要があると感じました。
実際に改善提案を行った一例
他の強みを活かした場面も
インターン開始前にストレングスファインダーという診断ツールを行いました。
診断結果は、以下の通りです。
- 未来志向
- アレンジ
- 戦略性
- 最上志向
- 目標志向
大体納得できますが、アレンジだけいまいちピンときていませんでした。 アレンジとは、様々な要素を組み合わせて最適化することで成果を出していく資質のことです。
ただ今回、LTの会の運営を行った際、アレンジを活かすことができました。
以前、iOSチームではLT会を行った際、予定していた時間を超過してしまったという話を聞いていました。そのため、当日はタイマーを使って、盛り上がりを保ちつつ、時間内に収まるように司会進行を行いました。
結果的に、コメント欄も盛り上がり、LT会は上手くいったと思います。
この経験から、過去の司会進行の経験と改善提案を組み合わせて、アレンジを活かすことができたと思います。
成果
インターンシップの成果は、期日に案件を完了させたこととLT会で司会進行や発表を行うことにより、プロダクトの成長やチームワーク向上に貢献しました。
また、冒頭で述べた自身の目標設定も達成することができました。
実際にアウトプットしました
Qiitaの記事 qiita.com
最後に
業務経験だけでなく、自身の強みをどのように業務に活かせるか、将来どのようなエンジニアになりたいかなどを明確することができました。
参加前は「この強みを活かすぞ」と意気込んでいたものの、実際参加してみると想定していた環境と異なっていたため、柔軟に考える必要がありました。
今後は、強みを最大限に活かせるよう「未来を見据えて プロダクト と チーム を設計できるエンジニア」を目指したいと思います。
Sansanの皆様、1ヶ月間ありがとうございました🙌
Radiotalk iOSインターンで成長したこと
本記事について
2020年2月中旬から2021年7月まで RadiotalkのiOSチームでインターンさせていただいたFuyaです🍏
本記事では、 「インターンでどのくらい成長したのか」 ついて紹介します🙌
目次は以下の通りです。
インターンの主な活動
まずインターンの活動内容は以下の通りです。
🍎iOSな情報共有会🍎
知識共有を目的としたiOSの勉強会として、 「iOSな情報共有会」 を主催しました。
以下、勉強会の様子です😉
インターンでどのくらい成長したのか
実際インターンを通してどのくらい成長したのか...🤔 インターンの開始前と終了後のレベル感は以下の通りです。
インターン開始前のレベル感
- とりあえず動くアプリを作ることができる
- 記事に載っているコードをコピペして動かして満足する
- アーキテクチャ何それ、Fat(Fuya)ViewController
インターン終了後のレベル感
- 内部品質を意識した上でコードを書くことができる
- 他人の書いたコードに対して常に疑問を持ち、改善提案をすることができる
- アーキテクチャの選定基準を定めた上で個人でアプリを作ることができる
成長するためにどのように工夫したか
工夫した点は、以下の通りです。
- 自ら課題を発見し解決すること
- 定期的に振り返りを行うこと
- アウトプットできる環境を作ること
この3点について詳細に説明します。
1.自ら課題を発見し解決すること
1つ目を行った理由は、受け身の姿勢でタスクに取り掛かっても、物事の理解が深まらないことを実感したためです。
インターンを始めた頃、私は受け身の姿勢で決められたタスクに取り掛かっていました。「言われたことは言われた通りにやる」は当たり前のことですが、当初私にとって非常に難しいことでした。原因は受け身の姿勢でタスクに着手してしまうと、責任感が薄まり、理解が浅くなっていたためです。
そこで私は自ら課題を発見し解決するように意識しました。
具体的には、以下の通りです。
GitHubのissueを立てて社員と実装方針について議論する
違和感のある挙動を発見したら、改善提案を行う
結果として、タスクの理解が深まり、自主的に改善提案を行うこと ができました。
これにより、私は普段から常に疑問を持ち、積極的に問題解決しようとする意識が高まりました。
2.目標を定めて定期的に振り返りを行うこと
2つ目を行った理由は、成長速度を上げること と 同じミスを繰り返さないためです。インターンを始めてから1年ほど経過した際、「自分は成長できているのか？」と疑問を持つようになりました。
そこで私は、判定可能かつ定量的な目標 を定めました。
結果として、定めた目標に向けて計画的に行動できるようになりました。
大学生が長期インターンする場合、研究や課外活動の時間もあるため、時間管理が難しいと思います。（一時期、研究発表の準備&ハッカソンの運営準備&インターンが重なり、瀕死状態だった時がありました😇）
しかし、私は目標を立てることでモチベーションが上がり（個人差あり）、計画的に行動できるようになりました。
今後も目標を定めていき、成長速度の向上や同じミスの繰り返しの抑制に繋げたいです。
3.アウトプットできる環境を作ること
3つ目を行った理由は、継続的にアウトプットできていないことを課題に感じていたためです。（業務上のアウトプットは対象外）
私はアウトプットの重要性を理解していますが、継続的なアウトプットができていませんでした。1つアウトプットしても、次のアウトプットは2ヶ月後という状況でした。
そこで定期的にアウトプットできる環境作りを行いました。
具体的には、以下の通りです。
iOSな情報共有会の開催
これによって、定期的に情報収集する習慣が身につきました。
キャッチアップする際の情報源は、以下の通りです。
学んだ技術を個人アプリに落とし込む
実際の個人アプリの一部を紹介します。
業務でアーキテクチャを学ぶだけでなく、 自分で考えて実装することで、さらに理解が深まりました。
最後に
本記事では、Radiotalkのインターンで成長したことについて紹介しました。
Radiotalkのインターンに参加したことで、本当に大きく成長することができました。
特に改善提案しようとする意識は、今後も活用したいです。
最終的に私は指揮を取り、笑いも取れるような人間になりたいと考えているため、 今後も努力を続けていきます。
Radiotalkの皆さん、本当にありがとうございました🙌
🍎iOSな情報共有🍎
本記事について
iOS開発者によるiOSな情報共有を行うための記事です。 ※ 随時記事を追加するため、上から記載します。
タグの例
- [UI]
- [ロジック]
- [アーキテクチャ]
- [概念]
- [企業調査]
- [SwiftUI]
- [その他]
- など
記事一覧
[ロジック] これって良いコード？〜結合度編〜
概要
結合度：モジュール間の相互依存性の程度を表す尺度 →結合度が低いと、モジュールが独立し、可読性や保守性の面で良いとされる →結合度が高いと、モジュール間の依存が強く悪いとされる
関係性の整理
- 凝集度：モジュール内の評価
- 結合度：モジュール間の評価
- 凝集度が高いと結合度が低くなり、相関が強い
[ロジック] これって良いコード？〜凝集度を意識してコードみてみた編〜
参考資料から抜粋
[ロジック] これって良いコード？〜凝集度編〜
概要
凝集度：モジュールに含まれている機能の純粋さを表す尺度 →凝集度が高いと、機能が絞られていて、堅牢性、再利用性、可読性などの面で良いとされる →凝集度が低いと、関連のない処理が混同している状態
参考 - 良いコードとは何か - エンジニア新卒研修 スライド公開
議論ポイント
- 皆さんはどのくらい凝集度を意識していますか？
- ex)どの粒度で関数を切り出しているか？
- 皆さんが考える「良いコード」とは？
- レビューで意識しているところなど
[SwiftUI] データ管理のお勉強
SwiftUIのデータ管理についてQiitaの記事を書いてみました！ https://qiita.com/Fuyan777/items/d79eef243e2ded33780e
[企業調査] dely株式会社さん：クラシルの開発調査
概要
先日、dely株式会社のクラシルiOSアプリ開発を担当している方と面談する機会がありました。 面談の中で聞いてきたiOSな技術的な取り組みについて共有します。（外部に公開されている情報のみです）
- iOSの技術周りの共有の場として周1でiOS Lunch MTGを開催
- Stroyboard/xibファイルを使用しないコードベースのUI実装
- Autolayoutも含む（←標準APIらしい）
- Embedded Frameworkを活用したモジュールの切り分け
- 機能単位、機能ごとによるチーム構成のため
- Chatbotを活用し、Slackからアプリの審査提出まで行える仕組みの導入
- 週1回の継続的なリリースを実施し、スピード感重視
[アーキテクチャ] 業務で採用してみたいiOSアプリのアーキテクチャと技術
概要
MVVM + Layered Architectureを採用
抱えていた課題
上記の課題の対策
- Model内をLayerd Architectureに責務分割
- Embedded Frameworkを活用
※Embedded Framework：アプリのコードをターゲットに分割して、Frameworkとして扱うことができる技術です。
所感
将来的にEmbedded Framework化したい（マルチモジュール化）
利点
- テストコードが書きやすくなる
- レイヤー分割・依存関係の強制
- ビルド時間短縮（差分ビルドって効いています？）
モジュールの分割方針
- レイヤー単位（Presentation、Domain、Data）
- 機能単位（Home、ライブラリ、マイページの画面単位）
- 機能×レイヤー単位（HomeのVC，ViewModel，Modelなど）
議論ポイント
- Radiotalkでモジュール分割するなら？
- モジュール化することでRadiotalkへの恩恵は？
参考
[レイアウト] AutoLayoutのエラーログをしつかり読み解こう！
概要
AutoLayoutエラーログが出たときの対処法について
以下のログで [ 対象のUIやレイアウト箇所 ] がエラーログが出る原因となるそうです。
Will attempt to recover by breaking constraint <NSLayoutConstraint:0x6000035d9f90 [対象のUIやレイアウト箇所] (active)>
所感
至る所でエラーログが多発しているため、エラーログが出たらWTFで可視化したり、発見したら即座に対応したいです。
参考 - https://qiita.com/Fuyan777/items/9b8d915a29cff0d91165
[ロジック]「！」を使わないことが本当に安全なのか
概要
！を使わないことでアプリのクラッシュを避けることができます．
しかし，場合によってはアプリのバグ発見を遅らせることになるので，それを解消するためのいくつかのTipsが書かれています．
所感
assertionFailureはデバッグビルドのみクラッシュします。 これを利用することで、本番環境のクラッシュを抑えることができます。
参考
iOSな情報共有会について（終了）
詳細
目的
流れ：30分程度を想定
- 共有者確認
- 情報共有タイム（2分、5分程度 ※発表人数に応じて変更）
- 質疑応答 & 議論タイム
- 締め
iOSな情報共有会
第1回
- 5/11（火）15:00-15:30
- Fuya：アーキテクチャについて
第2回
- 6/22（火）11:00-11:30
- Fuya：これって良いコード？〜凝集度編〜
第3回
- 6/29（火）15:00-15:30
- Fuya：これって良いコード？〜凝集度のコード探してみた編〜
第4回
- 7/6（火）15:00-15:30
- Fuya：これって良いコード？〜凝集度の観点からリファクタしてみた編〜
