2021.3.7(日)にモバイルアプリ開発技術アドバイザー情報共有会をオンライン開催しました。

発表スタイルは質問があれば随時答えながら発表するスタイルとして15分の発表＋バッファ5分で行うようにしました。発表しながら「これどう思いますか？」とか「こういう時どうやってますか？」とか聞く感じですね。

このまとめでは自分の発表2つ、『技術アドバイザーの分類』『契約と現場に求められることのすり合わせ』についてせっかくなのでまとめておきます。

技術アドバイザーの分類

パターン

まずは、技術アドバイザーっていうと何をやるのか、それを大雑把に分類してみました。

分類: 実装寄り
- 機能の実装や修正
- 機能の設計
- SDK利用のサンプルコードを作る
- アーキテクチャの整理
- 開発環境の自動化整備
- PRベースのコードレビュー
- 課題をみつけてコミットする
分類: 運営にも関わるコンサルティング
- チームビルディング
- 採用支援
分類: 受け身的
- 聞かれた質問に答える
- 読書会参加形式
分類: その他
- ワークショップ形式
- 講義形式
- 最新情報を共有する

もちろん他にもあるでしょうし、内容が重複していることもあるとは思います。さらにこれらはどれか一つをやるわけではなく、これらの中から複数もしくは一つ選択することを想定しています。

馴染みがない部分について下記補足します

ワークショップ形式とは？

例
- Clean Architecture/SOLIDのワークショップ
  - Clean ArchitectureやSOLIDについて、手を動かしてもらってコードを示すというワークショップ
    - 依存関係逆転の原則や閉鎖開放の原則など共通の知識にする
  - 長所
    - PRのレビュー時などに共通のワークショップで得た知識をベースにコミュニケーションしやすくなる
    - アドバイスする際に相手の技量や考えがわかる
  - 短所
    - 資料を用意する必要がある
      - モバイルアプリ寄りの資料にしてあげたい

PRのコードレビューをいきなりするという関わり方はよくあると思いますが、設計に対する共通の知識をちゃんと揃えるという役割として効果があります。単に知識として伝えるのではなく、まず設計の原則を伝えてそれを参考にワークショップとして設計をしてもらう。そうしてなるべく記憶してもらうというのが良いところでしょう。

講義形式とは？

RxSwift研究読本を参考にする例

（講義形式かはわからないけど）杉上さんはテクニカルアドバイザー業でRxSwift研究読本を使っているそうです。

#iosdc 懇親会で杉上さんに「RxSwift研究読本はオススメできます」いただきました！優勝！ベストトーク賞貰えなかったけど、この1年の努力の全てがここにあった！！https://t.co/uSXu9GKxsy pic.twitter.com/DggktpFJKz

— imajo (@yimajo) September 7, 2019

開発環境の自動化整備とは？

CIを導入したことがない人はCIの良さとコストのバランスを体感していないので、そこの壁を無くすのがよくある改善ですね。

CI
- Danger
  - 静的解析によるコードレビュー時の自動的なコメント挿入
  - CLIで特定のPRについて動作させることもできる
  - GitHub Actionsで(macOSでなく)Linux上で静的解析してDanger使う
    - 無料枠が Linux > macOS なため
    - SwiftのDanger
      - CLIで動かす時npm入れないといけない
        
        npmローカルでバージョンの手間がある
    - RubyのDanger
      - CocoaPods入れる文化あるならRuby入れる手順に沿う
- Bitrise
  - macOSでビルドしてテストコード実行
  - ベータのmacOSをいち早く使えるのがいい
SwiftFormat/SwiftLint
XcodeGen
SwiftPackageManager

いまのところ私はBitriseとは別にGitHub ActionsでLinuxでDangerを動作させ、Swift版ではなくRuby版を使っています。

キュリオシティソフトウェアだったら技術アドバイザーとしてできること

弊社キュリオシティソフトウェアのyimajoだったら、どういうアドバイザーパターンを組み合わせるのかというのも話をしました。

実装寄り
- [ ] 機能の実装や修正
- [ ] 機能の設計
- [x] SDK利用のサンプルコードを作る
- [x] 機能の実装や修正
- [x] アーキテクチャの整理
- [x] 開発環境の自動化整備
- [x] PRベースのコードレビュー
- [x] 課題をみつけてコミットする
運営にも関わるコンサルティング
- [ ] チームビルディング
- [ ] 採用支援
受け身的
- [x] 聞かれた質問に答える
- [x] 読書会参加形式
その他
- [x] ワークショップ形式
- [x] 講義形式
- [x] 最新情報を共有する

上記項目でチェックしているのがやること、ではありますがチェックしてない項目は応相談という感じ。なぜかというとコンサルティング関係でチェックしていないことについてはそもそも権限というやつがないとできないことだと思っています。

契約と現場に求められることのすり合わせ

契約形態は時給制か月額制か

次に契約形態は時給制か月額制かという話題、両方長所と短所がありますよねという話です。

時給制にして自分の時間を一日確保するパターン
- もしやることがないや簡単なことしかない場合
  - こんな簡単なことで請求して良いのかという良心の呵責があって請求書書きづらい
  - たまにクライアント側がやることを探そうとしてしまう
    - 課題を自分で見つけないといけないという新たな悩みを抱えさせてしまう可能性もある
      - 課題を自分で見つけられるレベルというのはそもそも習熟度がいる難しいこと
        
        仕事のための仕事ができあがってしまう
- やることがありすぎる場合
  - 一日にやれることをセーブできる
月額制
- もしやることがないや簡単なことしかない場合
  - 月額で決まってるので気にしない
- やることがありすぎる場合
  - 金額の計算が難しくなんか損してる気もしてくる
    - もしもらっている以上やりたかったら交渉しようという気持ちになる

上記雑に書いてしまいましたが、どちらが良いかはアドバイスするパターンとその人によるというのが今回の話の結論です。

現場に求められてることと依頼者との乖離 2021

最初からこうやってズレが生まれるという例

実際に契約してもズレがあるなと感じる場合についても話しました。下記のようなことはあるある話だと思っています。

依頼者から「フルでだめなら少しでもいいから参画してくれ」
- yimajo『じゃあ週イチで、アドバイスくらいなら』
  - 「それならアドバイスでいいです。必要だったら手を動かしてくれるぐらいでいい」
    - yimajo『じゃあそれでお願いします（必要だったら手を動かせばいいのはアドバイスより早い場合もあるし）』
      - 「今日から参画してくれるyimajoさんです。手が回らないところを手伝ってくれます」
        
        yimajo（そういう説明したらアドバイスじゃなくない！？）

こうやって参画してアドバイスしても、メンバーはそのアドバイスを受け入れることができないんじゃないかというのがあるある話じゃないでしょうか。

こうなってしまうことについては、最初の期待値のすり合わせがうまくいってないからでしょう。後半にどう解決していくかを書きますが、もう少しすれ違う要素を感じ取れる場合もあります。

クライアントからの「教育してほしい」というお願いは危険信号

他人からのアドバイスを素直に聞くことができる状態というのを、Coachableと言うそうなんですね。そのCoachableでない開発メンバーにアドバイスなんて意味がないわけです。クライアントのお願いで「開発メンバーを教育してほしい」といわれるのは危険信号だと思ってますというのも話題に上がりました。

前提
- 依頼してくるクライアントと開発メンバー複数という構成があるパターン
クライアントの権限のある依頼者による「教育してほしい」
- 何が危険信号か
  - 開発メンバーは開発してくれるメンバーが欲しい場合があり、アドバイザーなんて求めていない場合がある
- 危険信号を見かけたら
  - 開発メンバーと同意を得てからそれが必要かをメンバー各位に確認するべき
  - クライアント依頼者だけの要望ならだめ
    - なぜなら権限もないのにこちらが何かをやらせることはできないことを理解してないから
      - サラリーマン時代はいくらでも教育できたがそういう契約してないと赤信号
    - こちらに耳障りの良いことを言ってる可能性もある
      - 人手があればいいみたいな...?

ズレをなくし期待値を合わせるために

契約をするまえ
- 期待値をすり合わせましょう
  - 最初に自分が何ができるか/何を求められているかの期待値をすりあわせする
    - お品書きチェックリストを見せる
      - お品書きから選んでもらうのもあり
  - 開発メンバーがCoachableな状態かどうか判断する

Coachableかどうかを判断する方法

開発メンバーと話をするときに、Coachableな状態なのか判断する手段が人それぞれあります。下記に良さそうと思っているものを共有します。どうでしょう？

書籍『1兆ドルコーチ』から
- 「君はコーチングを受け入れられるか？」という質問をする
  - 「コーチしてくれる人によりますね」と回答するとCoachableではないと判断される
”コーチャブル”かを見極める方法村上僚さん
- 「今まで受けた、最も手厳しいアドバイスはなんですか？それに対してどう反応しましたか？」など

Coachable というのは状態でありインタフェースやプロトコルではありません。つまり私自身Coachableな時もありますしCoachableじゃないときもあります（もちろんCoachableでありたいとは思うものの）。他の人もそうだと思います。Coachable な状態は認知の歪みにより影響されることもあるんじゃないかと思ってもいます。

認知の歪みはないか
- 課題に楽しく向き合えているか
- メンバーを尊重できているか

私自身も認知が歪むことがありますが、そうなると歪んでるのかどうかって自分ではわからないんですよね。なのでとても難しい。

まとめ: 弊社キュリオシティソフトウェアの私だったらどうするか

さいごに、あくまで私の性格上ではこうするよというのを共有しました。

時給制か月額か
- 単価を2万くらいにできるなら時給制、そうでないなら月額制
契約をするまえに
- 期待値をすり合わせましょう
  - 最初に自分が何ができるか/何を求められているかの期待値をすりあわせする
    - お品書きチェックリストを見せる
      - お品書きから選んでもらうのもあり
- iOSアプリの開発チーム全員と話す
  - アドバイザーの意見で改善しようと思っているのかがそもそも大事
  - Coachableかどうか/認知が歪んでないかを判断したい
はじめは
- 何を知っていて何を知らないのかを把握する
  - 自分が思っている正論を前提に話しても意味がないのでいきなりコードレビューは難しい
    - ペアプロ
    - 例えばSOLIDの原則/関数型プログラミングについての1時間くらいのワークショップを開く
- 考えられる中でより具体的な指摘を選ぶ
  - コードが綺麗とか汚いとかで指摘しない
技術アドバイザーをやめる基準をあらかじめ共有する
- 中長期的な課題が改善できたらやめる
  - 改善できる余地やそもそも改善する要求がないこともある
- 一年以上とか時間がかかりすぎるのもやめる
  - 私の課題設定が間違えてることもある

感想

発表はリアルタイムに意見を聞きながら発表するスタイルだったんですが、@akio0911さんからの感想をまとめておきます。

前半の発表は俯瞰してて基調講演として良い
こういう内容はアウトプットしてみてもらうのが良さそう
コーチャブルの概念が知れてよかった
別の人を誘ってまたクローズドにやりたい

次回に向けて

実験的にモバイルアプリ開発技術アドバイザー情報共有会第一回をやってみましたが、次の第二回もやろうとは思っています。またクローズド（オフレコ）にするかどうかは考え中です。クローズドにすると細かい話がしあえて良いんですよね。でもオープンにやってたくさん意見もほしいところです。

私から次回情報共有したいことは次の3つです。

アドバイスのはじめにやりたいこと
コンフォートゾーンから抜けたいよね
アドバイザーの心得編

参加者全員発表者というのは崩したくない気持ちです（視聴者枠のオンライン接続状態を気にしてしまうから）。

モバイルアプリ開発技術アドバイザー情報共有会の第1回目を開催しました