第7回ペパボテックカンファレンス～ minneアプリのミライ～ 整理されていないメモ

こちらの勉強会の整理していないメモです。
網羅性はないし、タイポもたくさんあって、自分にしか理解できない内容になってしまっています。
それではどうぞ。

19:35 TableView, CollectionViewのパフォーマンスチューニング minneで実践したこと minne事業部 プロダクトチーム 菊池 和紀（@kichikuchi）

発表資料

• CollectionView, CollectionView in TableVIew ネスト

滑らかタイムライン

• 無限スクロールの話
• もともとはFooterView表示されたらAPIリクエスト叩いていた
• 先読みしてreloadDataしたけど、reloadDataで画面が一瞬固まった
• 常にEndrefreshing読んでた。isRefreshingでチェックして必要な場合だけ呼ぶようにした
• cellの高さ計算をキャッシュした

カスタムカメラロール

• デフォルトカメラロールは１つずつしか選択できないので複数選択できるカスタムカメラロールを実装
• 選択時にreloadData読んでいたが古い端末でちらついた
• 対策
• visibleCellsをwillDisplayCellでCell更新するようにした。

19:45 minneとマテリアルデザインコンポーネント〜DesignSupportLibraryを添えて〜 minne事業部 プロダクトチーム 望月 美帆（@mochicon)

• TabLayout
  • 最初は独自実装していた
  • SupportLibraryが提供されてからはそちらを利用する
• FABとBehavior
  • Behaviorで位置0が返ってくる不具合？があり使わなかった
• BottomSheet
  • kkk
• Ripple
  • ViewにThemeを設定するだけで実装可能
  • v21

19:55 minne Androidアプリにおけるチーム開発 minne事業部 プロダクトチーム チーフテクニカルリード 久田 一輝（@hisaichi5518）

• CTLの人
• CTLは部署内の技術方針と技術者組織をマネジメント
• テックリードの役割も担っていく
• テックリードとしてチームの生産性を上げる。一人では無理。
• テストの日を設定。今はみんな慣れたので廃止した。
• 新しくメンバーが入ってきたらテストの日再開してもいいかも。
• Device Farm導入
• MVPアーキテクチャ採用
• テスト書きづらいとかがあったので
• リリース担当を設置
• 環境づくり
• Androidチームでふりかえり
• Androidチーム夕会
  • 実際にアプリを見ながらやる
• かんばん
  • アナログなかんばんを導入

20:05 minneのApple Pay開発 minne事業部 プロダクトチーム プリンシパル　中島 大地（@nakajijapan）

• Apple Payを導入した話
• ユーザにとって支払いがかんたん
• TouchIDでSecure
• 開発者にとってカード決済不要
• AppleIDの情報入力が結構ザル
• 配送コストを計算する時に名前は取得できない。
• 必要なものを必要なときにというAppleの仕様
• プロパティ更新しても状態変わらないので更新必要なときは毎回インスタンス化している
• ゲスト向けにContactsUIで住所の自動入力などを実装した
• 下記によくまとまっている。

20:15 トークセッション 《モデレーター》 執行役員CTO 栗林 健太郎（@antipop）

Cookpad TechConf 2017 整理されていないメモ

こちらの勉強会のメモを整理しよう整理しようと思い、数日経ってしまいました。
もう整理することを諦めて貼り付けてしまいます。
網羅性はないし、タイポもたくさんあって、自分にしか理解できない内容になってしまっています。
なお発表資料と動画はこちらにまとまっています。

それではどうぞ。

13:10 - 13:40 成田 一生 Cookpad under a microscope

• 毎日の料理を楽しみにする。つまり、毎日の料理が楽しくない。
• つくれぽは根幹。フィードバックがあることが重要。
• レシピを投稿する人、レシピを探す人、Cookpadの3者で成り立っている。
  • レシピを投稿する人：フィードバックが貰える
  • レシピを探す人：探せる
  • Cookpad：レシピを蓄積できる
• エンジニア90人以上
• エンジニアの行動評価を行っている
  • シンプルな設計を出来ているか
  • 社内外で情報共有しているか
• エンジニア課題共有階
• Tech Meatingを2週に1回開催

13:40 - 13:55 滝口 健太郎 Go Global

発表資料

• 海外事業担当。イギリス在住。
• 食品業界は海外進出する時に味付けを変えている
• 宗教もサービス開発に影響を与える
• 性や、グロの基準が違う
• かのうモデル
  • 最小限のコストで当たり前品質を満たし、魅力的品質にコストを掛ける
  • 当たり前品質は国ごとに番うので分析する
• 属性よりコンテキストでユーザの課題を分析することが大切
  • 属性：性別。年齢
  • コンテキスト：どういう目的で料理するのかなど
• グローバル化で大切なこと
  • 検索
  • 翻訳
  • チーム
• OKRを採用している
• リリースは8割

13:55 - 14:10 sorah Building infrastructure for our global service

発表資料

• インフラの話

14:30 - 14:45 若月 啓聡 サービス開発におけるデザインの取り組み方

発表資料

• 投稿開発部
• デザイナーの仕事≠画面のデザイン
• 実データを使ってプロトタイピング
• デザイナがXcodeを使ってデザイン修正

14:45 - 15:00 加藤 龍 モバイルアプリのABテスト

発表資料

• Androidエンジニア
• WebとモバイルのABソリューションは事情は異なる
  • モバイルは通信環境がひ弱なことも影響する
• ABテストの要望に充実した社内ツールとの連携が多かったので内政することにした
• ABテストで得られた値の有用性が課題

15:00 - 15:15 丸山 亮 チームでプロダクト開発をするための取り組み

発表資料

• 料理記録のプロダクトマネージャ
• プロダクト、プロジェクト、チームをマネジメント
• 信頼関係、任せる。
• メンバーはどれくらいかかるか、どう作るかを任せられる
• リーダーは何を作るのか、どうまとめるかを担当する。
• OSSでプロダクトの最初から最後までを経験している
• 直ぐに応答留守
• 区切るをつける。メリハリ
• 外部からも新絵アイを得る
• 信頼を得ることを目的にしない

15:35 - 15:50 須藤 耕平 よりよい検索体験の為の情報設計とプロトタイピング

• 検索の動機とそれぞれの具体的なシナリオを分析、設定
• 設定に既存の機能をマッピング
• シナリオの優先順位を分析
• 継ぎ目の無い導線をデザイン
  • 流れが大事
• 実際の生活の中で試す

15:50 - 16:05 長 俊祐 チームでサービス開発するためのコミュニケーション

発表資料

• Cookpad料理教室担当
• リアル性が高いためインターネットリテラシが低い人も多い
• その中でチームのGithubを導入した話。
• 最初は高等コミュニケーションしてエンジニアがISSUEを立てて閉じてとしていた
• エンジニアが雑にISSUEを立てて心理的障壁を低くする。こんなんでいいんだって思ってくれる。

16:05 - 16:20 国分 崇志 快適なサービス開発を支える技術

• 開発効率の向上のために何をしているか
• 開発環境の工夫
  • セットアップを効率化。
  • コマンド一発
• 開発の工夫
  • 開発環境のデータを本番と同じにする
  • 個人譲歩は隠す
  • マイクロサービス化
  • サービス間で壊れにくいツールを用意
• テストの工夫
  • テスト失敗したらコミットした人にメンションん飛ばす
  • 高速な実行
• デプロイの工夫
  • チャットオプス。リリースの排他制御を行う
  • デプロイロック機能。AutoScale中はロックするなど
• 監視の工夫
  • リリースして終わりでない。エラーがないサービスを提供する必要がある。
  • 障害検知で担当者に電話かかる。

16:40 - 16:55 染谷 悠一郎 Real World Machine Learning

• ディープラーニングのオモテウラ
• 料理きろくにディープラーニングを利用
• ここからウラ
• 計算機環境構築の効率化
  • 結構色々大変
• ML Lunch
  • 週1回の勉強会
• ML Class
  • 外部講師を招いた月1回の勉強会

16:55 - 17:10 兼山 元太 行動ログでプロダクトを改善するには

発表資料

• 行動ログで検索成功率を計測（満足度の定量化）
  • キーワードのジャンル毎(材料、メニュー、目的など)に離脱率を測定
• セッション化（セッショナイズ）が便利。SQLで実現可能。
• 利用者のログはサービスに最適されている。
• 利用者に自然に貢献してもらうことで次の利用者に

17:10 - 17:40 庄司 嘉織 Cookpad awakens

発表資料

• 技術部長　兼　人事部長
• バックオフィスでも技術が分かる人がいることが大事
• ここから技術部長の話
• マイクロサービスで分割したけど、連携が難しい
• expeditorとpactの話
• 出力をJUnitフォーマットにするとCIで使いやすい
• hakoはデプロイツール
• 様々なツール群の話
• ジョブはWebアプリと共有したいものは多い
• cronの代わりのkuroko2
  • https://github.com/cookpad/kuroko2
• 頑張ってAWSのSpotInstance使ったらコストが6割減できた
• Redshift完全移行した
• アクセスログとアプリケーションログを同じDBに入れるといろいろ見れるようになった
• ディレクターだSQLを覚えだした

Androidの高機能なLayout

dex.fm 4: Support libraryの中でAndroidの高機能なLayoutが紹介されていたのでメモを残しておきます。

• CoordinatorLayout - FrameLayoutの高機能版
• ConstraintLayout - RelativeLayoutの高機能版
• FlexboxLayout - LinearLayoutの高機能版

http://dex.fm/post/146881710908/4-support-library

Xcodeでプロジェクトを作ってgitignoreを追加するまで

• Create Git Repository on Hogeにチェックを入れてプロジェクト作成
• 下記コマンドを実行し、.gitignoreファイルを追加。
  このコマンドを実行するにはこちらの設定をしておく。

$ git ignore osx swift xcode > .gitignore

アジャイルサムライからエンジニアのキャリアを考える

アジャイルサムライ−達人開発者への道−

本記事ではアジャイルサムライの中で紹介されている役割分担からエンジニアのキャリアについて考えてみます。

アジャイルサムライの中で定義されている役割

アジャイルサムライでは役割を以下の2つに分類しています。

• 顧客
• 開発チーム

そして開発チームについては更に以下のように詳細な役割について紹介しています。

• アナリスト
• プログラマ
• テスター
• プロジェクトマネージャ
• UXデザイナ

開発チームのメンバーはこれらの役割を複数こなしたり、日によって別に役割をこなしたりします。
ただ、全てを中途半端に身に着けてもキャリアを築いていくことは難しいと思いますので、それぞれ単体で考えていきます。

アナリスト

顧客と開発チームをつなぐ仕事をします。プロダクトの規模が大きくなると、顧客はプロダクト責任者が全体の方向性を決め、アナリストが詳細な仕様を決めていくことになるのでしょう。
アナリストにはエンジニアリングよりもビジネスサイドのスキルが求められる気がしますが、アナリストは様々なデータを駆使して分析する必要がある役割だと思います。
エンジニアリングの要素の中ではデータ分析のスキルを伸ばしていくと良いと思います。

プログラマ

プログラムの設計やコーディングを行います。
プログラマは組織内で優秀であってもその活動がオープンでなければ成果が見えづらくアピールしづらい環境にあります。
プログラマとしてのキャリアの築いていくには、OSSプロジェクトに参加し貢献していくなどの、オープンな場での活動が必要になると思います。

テスター

プロダクトのクオリティに責任を持ちます。
テスターはプログラマに比べてOSSプロジェクトでの活動が難しいと思います。なぜならあまり大きくないOSSプロジェクトであテスターが活躍する場がないからです。
テストの領域はアカデミック色が強く、様々な手法が一般化されており、それらをに身に付けていく必要があると思います。
そしてそれらの手法を実践に投入し、知識を向上させることで、キャリアを築いていけると思います。

プロジェクトマネージャ

開発チームの生産性が上がる仕事をなんでもやります。
プロジェクトマネージャの仕事の中にはコミュニケーションの改善や他部署との調整など、エンジニアリングが関係ない仕事もありますが、開発現場ではチームを見える化するツールや、CIツールなど、エンジニアリンングが求められる仕事もたくさんあります。
それらのスキルはプロダクト開発とは少し違うスキルになります。
また、生産性を上げるプラクティスもXPのように一般化されており、それらのプラクティスを身に付け、現場に投入し、知識を向上させることで、キャリアを築いていけると思います。

UXデザイナ

レイアウトだけではなくユーザ体験をデザインすることが求めれてきています。
UXデザイナにはソフトウェア開発に関係ない、一般的なデザイナに求められる、人間工学などの専門スキルが求められます。
また、現在や未来にどういうものがなぜ求められているのかというマーケティングも必要になります。
さらには、作り込んだUIがプログラムに落とし込めなかったり、想定外にコストがかかったりするなどの問題も出てきています。
UXデザイナとしてのキャリアを考える場合は、より抽象度の高いデザイナよりのデザイナか、プログラマよりのデザイナかのどちらかに軸足をおくことになると思います。

最後に

アジャイルサムライでは今回紹介した役割以外にも、データベース管理者、システム管理者、テクニカルライター、トレーナー、業務改善担当、インフラ管理者、ネットワーク管理者、などなど様々な役割があると書かれています。
それらについてはアジャイルサムライ内でも詳しく書かれていませんでしたので、今回は考察しませんでしたが、これらについてもどこかの機会で考察してみたいと思います。

以上です。

Scrumからエンジニアのキャリアを考える

本記事ではエンジニアのキャリアについてScrumで定義されているロールから考えてみます。

3つのロール

Scrumでは3つのロールが定義されています。

• プロダクトオーナー
• 開発チーム
• スクラムマスター

それぞれのロールをエンジニアのキャリアという視点で考えていきます。

プロダクトオーナー

プロダクトオーナーとは

• プロダクトオーナーはプロダクトの責任者
• エンジニア以外が担うこともある

プロダクトオーナーとしてのキャリア

一般的なエンジニアに求められるスキルよりも、マーケティング等のビジネスサイドのスキルが求められると思います。
ただし、プロダクトの全体のリスクに占めるエンジニアリングリスクの割合も高いと思いますので、エンジニアの知識があるとよい場面も多いと思います。
また、プロダクトオーナーはエンジニアに比べてその人の能力が見えづらいため、具体的な成功実績がエンジニアよりも重要になると思います。
成功しているプロダクトの一部のプロダクトオーナーとして経験を積めばこのようなリスクをヘッジできるかもしれません。

開発チーム

開発チームとは

• プロダクトの生産者

開発チームとしてのキャリア

開発チームはいわゆるエンジニアのキャリアとして考えればいいと思います。
インフラ、ソフト、DB、ネットワークなどの専門知識をより深く伸ばしていったり、これを全て身につけるように知識を増やしていったりスルことになると思います。 それらの領域はスクラムでは定義されていませんので本記事では開発チームの詳細については考察しません。

スクラムマスター

スクラムマスターとは

• スクラムのプロセスが上手にまわるようにします。
• スクラムのプラクティスを熟知

スクラムマスターとしてのキャリア

スクラムマスターという名前ではありますが、スクラムではあまり多くのプラクティスが定義されていないため、開発を生産的に行うためのプラクティスを多く身に着けておく必要があると思います。
生産的にするための手法の中には、CI環境等のエンジニアリングの要素も多くあるため、エンジニアのスキルが必要になる場面は多いと思います。 ただ、自己組織化された開発チームでは、スクラムマスターの必要性が低くなります。
スクラムマスターとしてのキャリアを考えるならば、様々なプロダクトに関われる環境にいる必要があると思います。
従って、組織内のプロダクトが少ない場合は、スクラムマスターだけのキャリアを考えることは難しいかもしれません。

まとめ

• プロダクトオーナーとしてのキャリアはエンジニアよりもビジネスより。
• 開発チームとしてのキャリアはいわゆるエンジニアのキャリア。
• スクラムマスターとしてのキャリアを考える場合、様々なプロダクトに関われる環境にいる必要がある。

参考にした書籍

SCRUM BOOT CAMP THE BOOK

アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ)

「学習する組織 改訂版によせて」読書メモ

学習する組織――システム思考で未来を創造する

改訂版によせて

サマリ

学習する組織の本題に入る前に全体像について触れられている。

• 学習する組織の5つのディシプリン(FIFTH DESCIPLINE)
• 5つのディシプリンの分類
• 学習する組織の前提になるその組織の単位について。

メモ

• 学習する組織の3つの中核的な学習能力と5つの領域。
  • 志の育成
    • 自己マスタリー
    • 共有ビジョン
  • 内省的な会話の展開
    • メンタル・モデル
    • ダイアログ
  • 複雑性の理解
    • システム思考
• 組織の基本的な学習単位は仕事チーム（ある結果を生み出すためにお互いを必要とする人たち）
• 学習する組織の弊害となるマネジメント体型
  • 評価によるマネジメント
  • 追従を基盤にした文化
  • 結果の管理
  • 「正しい答え」対「誤った答え」
  • 画一性
  • 予測とコントロールが可能であること
    • 変化をコントロールするのではなく適用するって感じだろうか？
  • 過剰な競争と不信
  • 全体性の喪失
• 何よりも変化にエネルギーを与えるのは、開放性、内省、より深い会話、自己マスタリー、共有ビジョンであり、システム全体を見て問題の原因を理解することが決定的に重要である。