プレイングマネージャーとしてプレイヤーとマネージャーを両立させるためにやっていること
これはコネヒトアドベントカレンダー2021の20日目の記事です。
これまでずっとエンジニアとしてやってきましたが、昨年の9月からマネージャーとしてのロールもやることになりました。(マネージャーとしておまえなにやるのよという点についてはこちらにしたためましたので興味あればご覧ください） マネージャー専任ではなく、エンジニアとの兼任といういわゆるプレイングマネージャーです。エンジニアとしての業務がなにか減るわけではなく役割が加算されることになるので普通にやると全体としての業務量がものすごく増えてしまいます。ぼくは絶賛子育て中でもあり業務時間を増やしてカバーという力技は不可能なので工夫する必要がありました。プレイングマネージャーとしてプレイヤーとマネージャーを両立させるためにやっていることを書いてみようと思います。
そもそも両立可能なのか？
まずはそもそもできるのかといったところを判断して無理そうだったらどちらかを諦める必要があると思います。 プレイングマネージャーとしてある程度のプレイヤーとしてのアウトプットを残すには時間は絶対に必要で、どれだけの時間が実装にとれそうかわかならいとやれるかどうか判断できないかなと思います。
なので、まずはちゃんと実装する時間がとれるのか計算します。週の稼働時間から、定例MTG、1on1などを差し引いてどれだけの時間が実装にさけそうか見てみましょう。一回スケジュールを仮に埋めてみるとわかりやすいかなと思います。
個人的には10人以内くらいが両立の限界かなぁという印象です。この人数はチームメンバーの成熟度によって変わってくると思います。セルフマネジメントがそろっていればもっと増やせるかもしれないですし、逆にそれができないメンバーが多ければもっと少なくなると思います。
そして、プレイヤーとしてどの程度コミットできそうかは上司と認識合わせておいたほうがよいです。
なにかを諦める
マネージャーとしてもプレイングマネージャーはフルコミットのマネージャーやエンジニアほどはマネジメントや実装にコストがかけられるわけではありませんので、なにかを諦める必要があると思っています。
例えば開発プロジェクトの場合、納期ががっちり決まっていたり売上などのインパクトの大きいプロジェクトについてはしっかり目にリスクを注視し対応していきますが、逆に制約やインパクトの小さいプロジェクトについてはメンバーにまかせ、たとえ失敗したとしてもそこから学んで成長してくれよなくらいの気持ちで最低限の関わり方にとどめたりしています。
エンジニアとしても、がっつり腰を据えて技術検証をしたりといったことは厳しく、方針を決めたり最終的な意思決定をする場面に参加し、それ以外のところは他のメンバーにまかせ、主にサポートにまわったりといった立ち回りになります。まかせられるメンバーがいない場合は、自分がやりつつ、今後はできるようになるように教育していきます。自分が先頭に立ってゴリゴリやっていくわけではないので面白みはかけるかなとは思いますが、プレイングマネージャーではなくてもシニアなエンジニアになるほどそういった役割が求められるので仕方ない面もあるかなとは思います。
あえて放置する といったことも行っています。マネージャーがなんでもかんでも拾って対処していると、メンバーがマネージャーがやってくれるとおもって拾わなくなることが結構あるのではないかと思っています。なのでslackでなにか見かけてもwatchだけしておいてなにもせずに放置しておくようにしています。そうすることでマネージャーが余計なことをやらなくて済ませられるケースもあるかなと思います。ただ、マネージャーの仕事はチームのパフォーマンスをあげることではあるのでメンバーの手をわずらわせるまでもないものは率先して拾っていくべきかなとは思います。
時間の有効利用
時間が確保できたとしても、細切れの時間がたくさんあったのでは実装を効率的にすすめることはできません。なるべく時間が細切れにならないように調整しています。
今やっているのは午前か午後にMTGや1on1を集中させることです。こうすることでまとまった時間が取れやすくなります。 またslackやメールなどのチェックといった短時間でできることはMTGとMTGの隙間時間にチェックし、まとまった時間内ではなるべく見ないようにしたほうがよいと思います。
期初、期末はマネージャーに専念する
期初、期末はどのマネージャーにとってもとても重要な時期で、部署やチーム、個人の目標をたてたり成果を評価したりする時期です。目標設定や評価次第でかなりやる気に影響し今後のパフォーマンスだったり離職につながってしまいます。ここにはものすごく時間をかけて納得のいく目標や評価になるよう気をつけたほうがよいと思いますので、期初や期末はその時間を考慮にいれ、プレイヤーとしてはコミットできないことを前提に計画したほうが良いと思います。
以上でした！
2020振り返り
2020年の振り返りです。
仕事
- 今年はずっとiOSエンジニアの採用を頑張ってました。
- マネジメントの役割もやりはじめました。
アウトプット
GitHub Actionsをいくつか作って公開しました
- GitHub - yanamura/ios-bump-version
- GitHub - yanamura/git-flow-merge-action
- GitHub - yanamura/git-merge-diff: Github Actions: generate merge diff between tags
- GitHub - yanamura/draft-to-ready-schedule-action
コネヒトでpotatotipsを開催しLTしました
コネヒトの開発者ブログを書いたり
tech.connehito.com tech.connehito.com tech.connehito.com tech.connehito.com tech.connehito.com
コネヒトのアドベントカレンダーを書いたりしました。
しょぼい変更ですが、OSSにコントリビュートしました
- DroidKaigi/conference-app-2020
- Quick/Nimble
インプット
- Machin Leaning
- CourseraのStanfordのMachin Learningを修了しました
- Flutter
- appbreweryのThe Complete Flutter Development Bootcamp Using Dartを修了しました
本
ここ１，２年読みたい本全然ないと思ってましたが、今年は豊作で特にアジャイル系の本が異常に多かったので読むのが大変でした。
その仕事、全部やめてみよう――１％の本質をつかむ「シンプルな考え方」
SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ
シリコンバレー式 最強の育て方 ―人材マネジメントの新しい常識 1on1ミーティング
プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち
他にもモダン・ソフトウェア・エンジニアリング、More Effective Agileなど買いましたがさばききれてないので来年がんばりろう
プライベート
子供が四歳になりました。二人目の子供が誕生し、二児の父になりました。
来年はまた子育てで手一杯になりそう。
iOSエンジニアがFlutterを勉強するのにやったこと
こちらはコネヒトアドベントカレンダー2020 23日目の記事です。
普段はSwiftでiOSアプリを開発しているわたしがFlutterを入門するのにつかったものなどを紹介します。
Dartについて
Dart Language Tour(https://dart.dev/guides/language/language-tour)を読んで勉強しました。
忙しい人にはDartはSwiftと似ていて雰囲気で理解でもわかるので飛ばしてもよいかもしれません。 ですが、雰囲気では理解しずらくここだけはちゃんと勉強しておいたほうがよいのが以下です。
- 定数のfinalとconst
- 名前付き引数
- Classコンストラクタ
定数のfinalとconst
- finalはSwiftのletと同じと思って良い
- constはコンパイル時に確定する値でfinalと異なりメモリの参照先も変更できません
名前付き引数
Dartで関数を普通に定義するとこうなります。
void enableFlags(bool bold, bool hidden) { ... }
この関数を利用するとこのようにSwiftと違って引数名は指定できません。
enableFlags(true, false);
Dartで名前付き引数を利用するには{}をつける必要があります。
void enableFlags({bool bold, bool hidden}) { ... }
こうすることでこのように関数の引数を名前付きで利用できます。
enableFlags(bold: true, hidden: false);
コンストラクタ
コンストラクタの定義を普通だったらこう書くのを
class Point { double x, y; Point(double x, double y) { this.x = x; this.y = y; } }
Dartだとsyntax sugarが用意されていてこのように省略して書くことができます。(https://dart.dev/guides/language/language-tour#constructors)
class Point { double x, y; Point(this.x, this.y); }
さらに名前付き引数を利用する場合はこのように書きます。FlutterのWidgetとかはこの書き方になっているのでこの書き方を覚えておいたほうがよいです。
class Point { double x, y; Point({this.x, this.y}); }
Flutterの勉強
appbreweryのThe Complete Flutter Development Bootcamp Using Dartをやりました。
このコースですが、UdemyとApp Breweryの両方でたぶん同じものが開講されています
Udemy
App Brewery
2020/12/21時点ではUdemyは1500円で、App Breweryは10$でした。私はApp Breweryを利用しました。
こちらのコースでは、環境構築、基礎知識だけでなく実際に手を動かして簡単なアプリをいくつか作成まで行います。Android Studioの便利なショートカットなども教えてくれたりするのでとても参考になりました。
全編英語ですがとても聞き取りやすく内容自体もiOSの経験者だと特に難しいことはないので理解できました。リスニングに自身のない方は英語字幕も用意されているので字幕をONにすると良いかと思います。
全部で17章あり結構な量がありますが、プログラミング初心者向けの内容（関数、クラス、リストなど）も結構あるので、その辺りはスキップするとよいかなと思います（わたしはスキップしました）。子育てであまり自由な時間のないわたしでも一ヶ月程度で完了しました。
気をつける点としてはちょっと古いAPIを使っているものなどがあるので、調べて対応する必要があります。たいていの場合はコメントのところに解決方法が書かれてたりするので大丈夫かなと思います。
修了するとcertificateも発行されます。
感想
FlutterはiOSとReactの知識があれば入門はとても楽でした。ホットリロードもとても便利でいい感じでした！
ただ、クロスプラットフォームのアプリとしてつくる場合はプラットフォームごとにUIを変えるのは簡単にはできないので同じUIにする前提にしないといけなさそうなところや、ライブラリを追加などするとホットリロードは効かなくてビルドしなおさないといけなかったり（ビルドはかなり遅い）と開発序盤ちょっと時間かかるとか、課題もいくつかありそうでした。
今後Flutterに適した使い所があれば積極的に使っていきたいです！
Invalid bitcode version (Producer: 'xxx' Reader: 'yyy')になったときの対処方法
iOSアプリのreleaseビルドを行った際にlinkerでinvalid bitcode versionで怒られることがあります。
ld: could not reparse object file in bitcode bundle: 'Invalid bitcode version (Producer: '1103.0.32.62.0_0' Reader: '1100.0.33.17_0')', using libLTO version 'LLVM version 11.0.0, (clang-1100.0.33.17)' for architecture arm64
上記の場合だと、雑に解釈するとclang1100.0.33.17_0使っているんだけどclang1103.0.32.62.0_0でビルドされたbinaryが混じっててbitcodeのバージョン合わないから駄目ですという意味になります。
大抵の場合、原因は使っている3rd partyのライブラリが同梱しているbinaryのビルド時に使ったclangのバージョンが合ってないということが問題です。
対策としては、原因となっているライブラリを以前使っていたバージョンに戻すか、原因となっているライブラリの使っているclangバージョンに合わせてXcodeのバージョンをあげるかになります。
後者の場合、clang1103.0.32.62.0_0と言われてもどのXcode？となってしまいます。
その際は以下のgistにXcodeとclangのバージョンの一覧がのっているのでここでProducerのほうに書かれているバージョンにXcodeを探しましょう
npmの特定のパッケージのみ最新にアップデートする
npm i -g npm-check-updatesを入れておくと便利
npm-check-updatesをインストール
$ npm i -g npm-check-updates
特定のパッケージを最新にする
$ncu -u styled-components
これを実行するとpackage.jsonが更新される
--- a/package.json
+++ b/package.json
@@ -18,7 +18,7 @@
"next": "^9.1.6",
"react": "^16.12.0",
"react-dom": "^16.12.0",
- "styled-components": "^4.4.1"
+ "styled-components": "^5.0.0"
},
"devDependencies": {
"@types/node": "^13.1.2",
あとはnpm installするだけ
2019振り返り
2019年の振り返りです。
仕事
去年の5月からコネヒトに出向していましたが、今年の5月にSupershipからコネヒトに転籍となりました。
アウトプット
まだちゃんとつくりきってはいないんですが、変更のあったファイルにのみlintとかformatterを適用するSwiftのライブラリを一応公開しました。
久しぶりに外部の勉強会でLTしました
コネヒトの開発者ブログを書いたり
コネヒトのアドベントカレンダーを書いたりしました。
しょぼい変更ですが、OSSにコントリビュートしました
- onecat/FengNiao
- typicode/husky
インプット
11月にScrum Inc.認定資格スクラムマスター研修を受けて試験もパスして、Licensed Scrum Masterになりました。
本
今年は人材育成やチームリーダーのロールもあったりしたのでマネジメント系が多かったです。
CAREER SKILLS ソフトウェア開発者の完全キャリアガイド
HIGH OUTPUT MANAGEMENT(ハイアウトプット マネジメント) 人を育て、成果を最大にするマネジメント
読んだ中でもエラスティックリーダーシップが自分の思っていたあるべきリーダー像に近くてとても共感がわきました。
久しぶりにリーダー的なことやプロジェクトのマネジメントに近い感じのこともしていたので、以前読んだ本を読み返したりと復習も多かったなと思いました。一回読んだら忘れない技術を身に着けたいです。
健康
納豆を食べるのを習慣としたのと、食べても太らない体質なのでこれはもしかしたら栄養の吸収がよくないのではないかという仮説のもとサプリメントを摂取してみたところ、全然風邪をひかなくなりました。 ただ年初にインフルエンザの家庭内パンデミックに巻き込まれてインフルエンザにはかかってしまいました。
プライベート
子供が三歳になりました。 相変わらず子育てが最優先で対応中です。
まとめ
振り返ってみると微妙な一年だったので今年はちゃんとOKRたててやりたいなとおもいます
iOS開発の年末大掃除
この記事はこの記事はコネヒト Advent Calendar 2019 18日目の記事です。
開発を重ねるとプロジェクト内についつい使っていないコードやリソースが残ってしまったり、開発環境にゴミが残ったりします。 今回はそれらの掃除に役立つツールを紹介します。
使っていないコード検出ツール
unused.rb
rubyのscriptを実行するだけで使ってない変数、関数を検出できます。
periphery
Swift製の使ってないコードを検出するツール
- 利点
- ただ文字列を検索してるのではなくSourceKitを使ってるのでご検出が少なさそう
- 欠点
- 結構遅い
- TypeAliasなどが誤検出されたりとまだ発展途上
- Xcode11対応版がリリースされていないので今年の大掃除に使うのは厳しそう（xcode11というブランチをとってきて自力でビルドすると一応動きはしますが誤検出しまくるのでオススメできません！）
使っていない画像、リソース検出ツール
FengNiao
CLIで使っていない画像などのリソースを検出ツール
- 利点
- optionで色々指定できるので快適に使える
LSUnusedResources
GUIで使っていない画像などのリソースを検出ツール
- 利点
- GUIでポチポチするだけなので誰でも使える
開発環境のゴミ掃除
DevCleaner
手動だけどやっておきたい
おまけでお掃除ついでにやっておきたいことも書いておきます！
warningの修正
Xcodeのissue navigatorに出てるwarningを直しましょう！
並び替え
ファイルが順番に並んでない場合はSort by Nameしてやると見やすくなって良いかなと思います。
typoの検出
Xcode11からSpell Check機能がついてるのでONにしておくとよいです。 ただ、どこでひっかかってるかは一括で見れたりはしないです。

一括でやりたい場合は有料ですがAppCodeのinspect機能を使うとよいです。
最後に
もうすぐAppStoreの審査は23~27まで休みの期間でiOSエンジニアも開発に一区切りつきやすい時期ですね。 こういった時期にこれらのツールをつかってお掃除してみてください！
そしてコネヒトではエンジニアを募集しておりますので少しでも興味のある人はお話だけでも聞きにきてください！ www.wantedly.com
MacBook Proの電源アダプタ
MBPを会社と家で使っている場合に、ただでさえMBPが重いのに電源アダプタまで持ち帰りたくないですよね。
ですが、純正の電源アダプタ(85W)を買うと8000円もするわけです・・
そこで色々探してよさげだったのがAnker PowerPort Speed PD 60です。
出力は60Wと私の使っているMBP15インチでは少々足りないですがこれを購入して使っています。
3ヶ月ほどMBP15インチ 2018のフルスペックのマシンでつかっていますが、これといった不満はありません。 当方はiOSエンジニアなのでXcodeでCPUぶん回してビルドとかしてますが、60Wでも充電されます。
値段も純正の半額以下とお手軽なのでおすすめです
SwiftUIのViewで条件によってViewを出し分ける方法
potatotips #64でLTした内容です。
SwiftUIのViewで条件によってViewをだしわけたいことがたまにあるかと思います。
SwiftUIでこのように条件によってViewを出し分けるようなコードを書いてみます。
var body: some View { if imageName.isEmpty { return Text("no image") } else { return Image(imageName) } }
そうするとこのようなコンパイルエラーになってしまいます。
! Function declares an opaque return type, but the return statements in its body do not have matching underlying types
なぜかというとbodyの戻り値の型がOpaque Result Typeなので、条件によってTextを返したりImageを返すといった複数の型を返すことができないからです。
ちなみにどちらの条件でも同じ型を返す場合はOKです。
var body: some View {
if imageName.isEmpty {
return Text("no image")
} else {
return Text(imageName)
}
}
解決方法
解決方法はざっくり3つあります
1. Group / HStack / VStack / ZStack
1つはGroupやZStackなどをつかってwrapしてやる方法
var body: some View { Group { if imageName.isEmpty { Text("no image") } else { Image(imageName) } } }
2. @ViewBuilder
もう1つは@ViewBuilderアノテーションをつける方法
@ViewBuilder var body: some View { if imageName.isEmpty { Text("no image") } else { Image(imageName) } }
3. ViewBuilder.buildEither()
最後はViewBuilder.buildEither()を使う方法です。（こちらの場合は3項演算子にする必要があります）
var body: some View { imageName.isEmpty ? ViewBuilder.buildEither(first: Text("no image")) : ViewBuilder.buildEither(second: Image(imageName)) }
※この3つの中でどれが一番よいかは最後に紹介します
以上３つの書き方を紹介しましたが、どれもViewBuilderの力によるものです。
なぜViewBuilderを使うと条件分岐が使えるのでしょうか？
ViewBuilderを使うと条件分岐が使える理由
ViewBuilderの仕組みを説明すると ViewBuilderはfunction builderを用いて実装されています。
このfunction builderはコンパイル時に構文解析をしてif文のchainだったらbuildEitherというfunctionを使うというふうになっています。
つまりどういうことかというと
こういうコードをコンパイルすると
@ViewBuilder var body: some View { if imageName.isEmpty { Text("Hello") } else { Image(imageName) } }
このような感じにコンパイル時に解釈されるということです。
var body: some View { imageName.isEmpty ? ViewBuilder.buildEither(first: Text("no image")) : ViewBuilder.buildEither(second: Image(imageName)) }
ここでViewBuilderのbuildEitherの定義がどうなっているか確認してみます
extension ViewBuilder { public static func buildEither<TrueContent, FalseContent>(first: TrueContent) -> _ConditionalContent<TrueContent, FalseContent> where TrueContent : View, FalseContent : View public static func buildEither<TrueContent, FalseContent>(second: FalseContent) -> _ConditionalContent<TrueContent, FalseContent> where TrueContent : View, FalseContent : View }
このように_ConditionalContent<TrueContent, FalseContent> を返すようになっていました。
確認のためにこのようなコードを書いて実行してみると
@ViewBuilder var body: some View { if imageName.isEmpty { Text("Hello") } else { Image(imageName) } }
戻り値の型は_ConditionalContent<Text, Image> になっていました。
このようにViewBuilderが条件分岐を_ConditionalContent<,>に変換してくれていたので、bodyの戻り値がopaque result typeであってもコンパイルが通るようになっていたわけです。
現時点で解決できない条件分岐
しかし、現時点(2019年8月)ではViewBuilderでは解決できない問題があります。
このようにswitch文やif let, if caseのようなif else以外の条件分岐を使うとコンパイルに通りません。（ちなみに@ViewBuilderをつかうとコンパイルは通りますがちゃんと動きません）
var body: some View { Group { switch foo { case a: Text("a") case b: Text("b") case c: Text("c") } } }
これを解決するには面倒ですがif elseに書き換えましょう
var body: some View { Group { if foo == .a { Text("a") } else if foo == .b { Text("b") } else if foo == .c { Text("c") } } }
ですが、どうしてもif else 以外で実装したい場合はAnyViewで、返すViewをwrapしてやると動かすことができます。
var body: some View { switch foo { case .a: return AnyView(Text("a")) case .b: return AnyView(Text("b")) case .c: return AnyView(Text("c")) } }
まとめ
ViewBuilderのおかげでView内で条件分岐が使えるということがわかりました。
ただし、現在はif elseのみ対応していて、それ以外のswitch文などは使えません。
しかし、最悪AnyViewを使って型を消してやればif else以外の条件もつかうことができます。
最後に、条件分岐を使う場合は紹介した3つのやり方の中だとGroupやZStackなどでwrapする方法が一番オススメです。理由は@ViewBuilderを使うと利用できないswitch文などを使ってもコンパイルに通ってしまうので間違いに気づきにくいためです。buildEitherは直接使う用途ではないと思うのであえて使わなくて良いかなと思います。
アプリのDark ModeをOFFにする
既存のアプリでいきなりダークモードに対応するのは大変です。 しかしXcode11でビルドするとデフォルトでダークモードが適用されてしまいます。
もちろんダークモードをOFFにすることは可能となっています。
アプリ全体でダークモードをOFFにする方法
Info.plistのUIUserInterfaceStyleをLight にしてやります。
<key>UIUserInterfaceStyle</key>
<string>Light</string>
UIで設定したい場合はこうします
デバッグ
ダークモードのデバックはXcodeで簡単に切り替えて確認できるようになっています。
デバッグのツールバーにEnvironment Overridesというボタン(トグルスイッチみたいなボタン)が新たに追加されていてこれを使います
このボタンを押すとこのような画面が表示されます
Interface StyleのところのトグルスイッチをONにして
Dark のほうを選択するとダークモードになります。
Nimbleでtupleの比較
Nimbleでtupleをequal()で比較してもコンパイルに通りません。
let tuple = (1, 2) expect(tuple).to(equal((1, 2)))
原因
これはtupleがEquatableではないからです
対策
これはどうしようもないので以下のようにequalを使わずに回避するしかなさそうです
expect(tuple == (1, 2)).to(beTrue())
Add ability to compare tuples · Issue #227 · Quick/Nimble · GitHub
ERROR ITMS-90784
2019/6/28ころから急にAppStoreConnectにipaをアップロードするときに以下のエラーがでるようになった
ERROR ITMS-90784: "Missing bundle name. The Info.plist key CFBundleName is missing or has an empty value in the bundle with bundle identifier ''
読んでそのとおり、info.plistのBundle name(CFBundleName)が未設定だったり空の文字列だった場合に発生するので、info.plistのBundle name(CFBundleName)を設定すればエラーは解消します。
flutter doctorのエラーの解決方法 Verify that all connected devices have been paired with this computer in Xcode
このようなエラーがでてbrew xxxをしても解決しない場合
[!] iOS toolchain - develop for iOS devices (Xcode 10.2.1)
✗ Verify that all connected devices have been paired with this computer in Xcode.
If all devices have been paired, libimobiledevice and ideviceinstaller may require updating.
To update with Brew, run:
brew update
brew uninstall --ignore-dependencies libimobiledevice
brew uninstall --ignore-dependencies usbmuxd
brew install --HEAD usbmuxd
brew unlink usbmuxd
brew link usbmuxd
brew install --HEAD libimobiledevice
brew install ideviceinstaller
@propertyDelegateと@propertyWrapperの違い
2019/06/25 現在の情報
Swift EvolutionのProperty Wrappersを見ると@propertyWrapper ですが、
AppleのドキュメントのStateを見ると
@propertyDelegateになっています。
原因
仕様策定段階で名前が変わった
詳細
ここに書いてあるように最初はproperty delegatesだったのがproperty wrappersに名前が変わったそうです。
The name of the feature has been changed from "property delegates" to "property wrappers" to better communicate how they work and avoid the existing uses of the term "delegate" in the Apple developer community
AppleはWWDCに間に合わせるために未fixの段階で実装していれこんじゃったために古い名前になっているようです。
Renamed the value property to wrappedValue to avoid conflicts.
こちらのvalueがwrappedValueに名前が変わる変更もbeta2の段階では反映されておらず、valueにしないとコンパイルに通りません。
