Customer Product Dev Groupの北川です。 直近では主にショッピングアプリ「BASE」のiOSアプリの開発をしています。 私たちモバイルアプリエンジニアの所属するNative Application Teamでは、『チームで育てるAndroidアプリ設計』の社内読書会を行いました。 『チームで育てるAndroidアプリ設計』について peaks.cc この書籍は2021年3月30日にPEAKSより出版されたもので、公式のHPによると対象読者として以下を挙げています。 アプリ開発をこれから始める方 チーム開発をよりよくしたい方、技術的なチームビルディングに興味がある方 アーキテクチャの選択、設計の維持に難しさを感じている方 新規開発／継続開発などチーム開発に関わる方 引用: https://peaks.cc/books/architecture_with_team ショ

いま自分は開発組織の生産性向上に取り組んだ仕事をしているのですが、自分が新しくまた別の開発組織に所属したりお手伝いすることになった場合、どういうことを大体どういう順番でやるのか考えてみました。 根っこについて① そもそもなぜ自社で開発組織をもつのか？ への回答を持つ ② どういう人が活躍しているか？活躍して欲しいか？ を決める まずはそもそもなぜ自社で開発組織をもつのか？そこを明確にしていきます。この問いの答えがなければ、さらにはこの答えについて役員同士での理解がなければ、各施策の進みが格段に悪くなります。 また、どういうスタンスで仕事をする人がロールモデルとなりうるのかを決めます。これによって、採用や評価、チームのあり方が変わってきます。 採用について① 採用すべき人がどういう人物であるべきか決める ② 採用すべき人がどういう技術レベルであるべきか決める ③ 採用フローを決める ④ 人員

ソフトウェア開発界隈では、カジュアル面談を採用している会社が多くあります。しかし、観測範囲ではなんとなくカジュアル面談を採用しているところが多くあり、なかなかどういう効果につながっているのかわからないままだったりするところも少なくないのではないでしょう。 カジュアル面談をやっている会社で、改めてどういう課題があるのか真正面から書いてみると、次のような項目が上がってくるのではないでしょうか。 ・面談ではなく面接をしてしまう ・結果がでない ・うまくどういう時間にすればいいのかわからない 今回はそういった結果にならないように、どういうカジュアル面談であれば良いのかをじっくり考えてみました。 カジュアル面談は応募者のステータスによってゴールが違うまず、カジュアル面談は応募者のステータス（転職意欲や志望度）によって、その場のゴールが異なってきます。 応募時の対応は３パターン、そしてカジュアル面談を

[PR] 献本いただいた1「チームで育てるAndroidアプリ設計」を読んだので感想文です。 peaks.cc 全体を通して 本書は大まかに前後半に分かれていて、前半は新規開発について、後半は大規模チーム開発について、それぞれAndroidアプリ設計の勘所について述べている。よって、すでにAndroidエンジニアとして働いている人であれば大体どちらかは経験があるだろうし2、これからAndroidエンジニアとして働く人にとっては事前に勘所が予習できるので大きな価値があると思う。つまり対象読者がとても広い。Android開発に興味がある人だったら何かしらの共感もしくは知見が得られると思う。 以下、面白かった部分について書いていくが、普通に全部読んで欲しいのでほんの一部だけ紹介する。 前半パート：新規開発について MVVMとだけ決めたチームの例 (p.4) 本パートでは実際に開発を始める前に設計

ダイレクトマーケティングです。(PR) アフィじゃないリンクは一番下に置いておきます。 peaks.cc 全体的な所感 アーキテクチャのモチベーションからアーキテクチャとチームの育成、将来を加味した運用方針について、非常に分かりやすく構成されています。新規プロジェクトへのアーキテクチャの導入、既存アーキテクチャの方向性の手直しや作り直し、既存アーキテクチャの思想読み込みといった よく必要とされる行為でありながら、あまり言語化されていないもの をどういったモチベーションや理念を持って実行するのか、そして どうすれば独りよがりにならず、チーム・組織として運用することができるのか を学べる良い本だと思います。 本書は順番に読み進めるとテンポよく進んでいく章立てになっています。その一方で気をつけなければならないこととして、本中で利用されるアーキテクチャは チームのスコープで使用する汎用的な設計方針

こんにちは、@kgmyshin です。 Androidやモバイル開発においてのアウトプットをメインとしている自分ですが、別の一面も今回はアウトプットしてみようと思います。 ここ数年、開発しながらも、前職でも現職でも副業でも開発組織にコミットする割合が大きくなってきました。 結構がむしゃらにやってきてしまっていたので、自分なりにそもそも「開発組織にコミットする」ってなんだっけ？というのを整理してみました。 良い開発組織って何？ 「開発組織にコミットする」っていうのは言い換えると「開発組織における課題を見つけて解決する」ことです。 で、「課題を見つける」にはまず「（理想の）良い開発組織」がどういう状況なのかを把握することが必要です。 なのですが、良い開発組織って何？という問いは結構難しいです。 この問いに関しては、「良いエンジニア・デザイナー採用できてる組織は良い開発組織」、「良いプロダクトを

あけましておめでとうございます。今年もよろしくお願いします。 新年になって、多くの方々が今年の抱負として新しい目標をたてたのではないでしょうか。本記事では自分の目標の立て方を紹介したいと思います。加えて目標を立てるためのツールも作った（ている）ので紹介の場所とさせてください。 今までの私の目標の立て方今までの自分の目標の立て方は「目標をマインドマップで細分化して、細分化された目標からタスク一覧を作ること」でした。たとえばこんな感じです。（いつもはこれよりかなり細かく砕いてます。あと字が汚くてごめんなさい。） 目標を構造的に俯瞰できるところとすごく漠然とした目標でも最終的にちゃんとタスクまで落ちるところが気に入っていました。マインドマップは coggle というサービスを使っていて、タスク一覧はその時々で変えていました。 しかし、このやり方にも問題点がありした。それは「毎日xxxする」や「週

こんにちは、 kgmyshinです。 本記事はSHIROBAKOアドベントカレンダー24日目、ラストの一つ前の記事となります。 adventar.org 今回は「立石考一」というキャラクターを、深掘ってみたいと思います。 「だれだろう？」と思う読者の方がいるかもしれませんが、無理もありません。 劇中で、彼は数える程しか出ておらず、しかも名前で呼ばれた回数は0回です。 どーなつ＠くいんてっとの一人である藤堂美沙ことみぃちゃんは、途中転職してしまうのですが、その転職前の会社がスーパーメディアクリエーションズです。 ここの社長を務めるのが「立石孝一」です。 劇中では「社長」としか呼ばれてませんが、初回テロップとみぃちゃんの書いた退職願に名前が出て来てます。 立石孝一さんの遍歴について 昔は海外でCGクリエイターをやっており「ズーパークストーリー」などの作品に関わっていたようです。 「ズーパークス

｜DMM inside

今日は、日本の代表的なソフトウェア開発手法について紹介しよう。 その名も、メテオフォール型開発である*1。 第一節 通常のウォーターフォール型開発におけるプロジェクトはこのような形を取るが、 メテオフォール型開発ではこのような形が取られる。 そしてこうなる。 これはアジャイル型開発手法におけるサイクルであるが、 神の前では無力である。 神の一声は全てを崩壊させ、 民は一生懸命これを再建す。 これが、メテオフォール型開発*2である。 第二節 全てのスケジュールは天界の都合によって決まる。これを黙示録と呼ぶ。 ソフトウェア開発においてフィードバックは重要なファクターだが、 神にフィードバックは届かない。 ただし、祈りを捧げることはできる。この祈りはごくまれに届く。 神は様々な姿を取る。 外から現れることもあれば、 内に棲んでいることもある。 あるいは、まだ会っていない or 会うことすらできな

｜DMM inside

｜DMM inside

はじめに こんにちは，ふなちです！ 1週間以上前になるんですが，技術書店で入手した 「大きめのAndroidアプリでの設計について考えてみる ~pocket~」 を完走させていただきました． booth.pm 頭が悪いのにも関わらず，設計のお話は好きなので，楽しかったですし，とても勉強になりました． ありがとうございます！ あと，この本の土台となっているリポジトリのコード github.com も何度も読ませて頂き，参考にさせて頂きました．（実はDroidKaigiの釘宮さんのセッションの影響もあって，本を買わせていただく前からこのリポジトリは何度か拝見させて頂いてました） これ以降技術的に間違えた内容があるかもしれないです． 間違えの指摘，アドバイス等はhttps://twitter.com/_hunachiにお願いします:bow: ※ これ以降は，「大きめのAndroidアプリでの設計

｜DMM inside

Support Library 28.0.0 alpha新APIのrecyclerview-selectionを使ってみた

こんばんは。釘宮です。 この記事はSHIROBAKOアドベントカレンダー24日目 の記事です。 今回は新人アニメーター久乃木愛にフォーカスを当て、彼女の魅力を紹介したいと思います。 久乃木愛の役割 SHIROBAKOにはリアルっぽく描かれている(おそらくモデルがいる人)キャラクターとアニメっぽく描かれてるキャラクターがいます。 キャラクターデザインを担当した関口さん曰くこの二種類のキャラクターをうまく同じ絵にあてはめるに困難したといったような旨をどこかのインタビューで言っておりました。 今回フォーカスする久乃木愛は後者です。後者のキャラクターにはいわゆる名前のないモブキャラも含まれてますが、彼女にはしっかりと名前が与えらています。 前半には一回きりしかも静止画でのみの登場だった彼女が後半がっつりと存在感をあらわにしてきたのはなぜでしょうか。 アリアに希望をもたらすためにルーシーというキャラ

そういえばよくレビューで指摘してたなぁと思い出したのでメモ書き。 例えばこういうコード。 fun findContent(): Maybe<Content> { val connectivityManager = application.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager return if (connectivityManager.activeNetworkInfo.isConnected) { apiRepository.find() } else { localRepository.find() } } Content を取得したい時に、オンラインだったら apiRepository を使って、オフラインだったら localRepository を使うというコード。 このコードには

これはFOLIO Advent Calendar 2017 1日目の記事です。 株式会社FOLIOというテーマ投資型オンライン証券サービスを提供している会社でバックエンドエンジニアをしています、よこなです。 会社のことをブログに書くのは5月の入社エントリ(リンク)以来。おかげさまで入社して半年以上たちました！毎日クソ楽しいです。自慢。 今日は入社以来開発の傍ら取り組んできたFOLIOのブランディングについて書いてみます。「ブランディング」が何かはこのエントリ内で徐々に明かしていきますが、OSSに貢献したりイベントで登壇したりQiitaに記事を書いたり、そういった「社外でのアウトプットに関するなにか」だと思って読み進めていただければ幸いです。設立2年目のスタートアップということもあって、いけいけどんどんの精神でがむしゃらに活動しています！という話ではありません。既視感ある内容だと侮ることなか

ここからはサーバーサイドにフォーカスした大規模改修の詳細についてご紹介します。 大規模改修前のサーバーサイドの構成 当時はこのようなレイヤードアーキテクチャを採用していました。縦はController、UseCase、Repository、データ層で区切り、横はコンテキスト毎にパッケージで区切られています。当初から複雑な仕様・要件でしたが、それぞれの影響範囲は明確となっているので、新規に参画するエンジニアにとっても十分に見通しの良いものとみなしていました。 事実、この設計で２年ほどエンハンスを続けてきましたが、大きな問題が発生することはありませんでした。 なぜ大規模改修が求められるようになったのか 『TOEIC対策コース』の新設が決まり、その仕様を詰めていくうちに次のことが浮き彫りとなってきました。 TOEIC対策コースと日常英会話コースとでは『レッスン』と『トレーニング』のツリー構造が根

(c) Recruit Co., Ltd.