nickotaのあうとぷっと。

ため込むだけだった情報を世に発信する。

開発意欲が上がる記事紹介

日々開発していると、度々プログラムを書いている目的が分からなくなったり
純粋に楽しめなくなる瞬間が来る。

そういったタイミング用に過去に衝撃を受けた、
やる気が出る記事をまとめておく。

時間が経っているものもあるが、
こんなにプログラミングって楽しめるものなんだなと
改めて実感できるものを抜粋。

1.機械学習の勉強を始めて1年以内にkaggleで2位になったので、やったこと全部書く

ブログ名「趣味日記」で補足が「機械学習について書きます」
そして記事が一つ。もはや勉強と捉えていない。

普段はWebエンジニアをしていた作者がkaggleと出会い、
コンペを通してのめりこむ記事。
アウトプットがかなり多く、「楽しさ」を実感する方法として非常に参考になる。
aryyyyy.hatenablog.com

2. 【転職エントリ】Googleに入社します

最初読んだ時、経歴がお化けすぎて声出して笑ったのを覚えている。
当時の会社の日報にリンクを貼ったほど楽しめた。

将来の夢はゲームを作るプログラマーになることだったが、
プログラマーとして働く自分が想像できなかったらしく、理三から医師になる。

間に数学オリンピック出ていたり、
しっかり医師の資格とったり、
ポーカーが激強だったり、
競技プログラミング出たり して
未経験からGoogleのエンジニアになる話。

頭の違いは置いておくとして、転職期間(3ヶ月)で学んだ量と速さは
もはや自分が定義する「人間」の域を超えている。
何だかスカッとする。
note.com

3. 化学系研究者が完全未経験からWeb系自社開発企業に転職するまで

上の二つとは違い、死ぬほどのめりこむ系ではないが、
非常によく考え、淡々と努力を積み重ねているのが分かる。
コツコツ積み重ねるという点で参考にでき、学ぶべきことが多い。
qiita.com

まとめ

未経験からエンジニアを目指すタイミングって一番勉強が捗るし、
エンジニアに対して夢を抱いていることが多い。
初心に戻るという意味でたまに見返すと元気が出る。

随時追記していく予定。

エンジニア副業Night 〜キャリアと年収アップのリアル〜参加レポート

findy.connpass.com

対象読者

高スキルじゃないとできないの?
どこで案件見つけるの?
相場は?
が知りたい副業に興味のある人。

はじめに

エンジニアの副業のリアルな話を求め、
ファインディ株式会社主催のこちらのイベントに参加してきました。

全く情報を集めていなかった自分としては
ざっくりとした概要だけでも想像できるようになって有意義な時間を過ごせました。

最後にスピーカーのジャンボさん(@jumboOrNot)と
お話した、自分のプロダクトとしての商品価値をどのように世の中に発信するか、
という直接副業とは関係ないお話が個人的には一番ためになりました。

スピーカーのご紹介

羽田 健太郎 さん(レアジョブ) @jumboOrNot
須藤槙 さん(Timers) @akatsuki174
大原和人さん (ファインディ株式会社) @kaacun
桑原 宜昭 さん(フリーランス エンジニア) @bouzjp


本題

単価

  • 2-3000円/hくらいが多い。5000円/hはテックリードレベル。

副業の探し方

  • スタートアップからの仕事が7,8割を占める(裁量を持てたり、土日でできたり、人手が足りてない点が副業に向いている。)
  • yenta
  • 興味のあるスタートアップをtechcrunchで常に探しておいて、関係者が登壇するところに行って実際に話す。
  • 知り合いの紹介

副業はやりたい人多いけど受け入れる企業がまだまだ少ない。
直接人と会って案件を見つけている人が多い印象。
仕事一覧が載っている訳ではないので、いろんな人・場所でいろんな接点を持っておくが大事

どれだけの経験値が必要か?

  • 企業は即戦力を求めている。質問はそんなにできない→要求レベルは高い。
  • しかし、技術的な面でボーダーラインはない。
  • 未経験でも、使ったことのあるアウトプットがあったり、近い技術を使っていたら大丈夫。

楽しさ

  • 純粋にコードをたくさん書ける。

魅力がある副業案件とは?

  • 有名な人のコードレビューが受けられる。
  • 新しい技術を触れる。
  • プロダクトに魅力があって自分の興味と合致すると面白い。
  • 本業でできない経験ができる。

工夫点

  • 本業の方々が滞らないような気遣いは副業側がしなければならない

  × どうしたら良いか?と毎回聞く→止まる
  ○ 自分で仕様を調べ、「〜しておきました。」自走力大事!!

  • 「自分はこういうのが得意です」「このようにコミットしようと思います。」が言えるようにしておく、ネットに発信しておく。

税金回り

  • 副業に関係なく、自分の利益を最大化するために知っておくべき。
  • 確定申告は最初は税理士に見てもらっていた(1.2万円/月)。途中から自分でやるようになった。
  • 確定申告はfreeeだけで十分(3000円/月)。(副業している人向けの解説動画もよく出している)
  • freeeだけだと確定申告作るのに1-2週間かかったりする。副業用の口座、クレジットを作っていたら1,2日で確定申告作れる。

副業する上で持っておくべき知識

  • 契約書はきちんと書いておくと、後々の問題に対応できる。
  • 契約書のレビューをしてくれるサービスとかあるらしい。
  • 請負契約と準委任契約の違いくらいは知っておく。 

クライアントと直接会う?

  • 会わなくてもできるが、週一くらいで会っておかないとモチベーション続かないこともあるらしい。

最後に

ジャンボさんとのお話。

技術は上を見ればいくらでも上がいる。
一向に自信が付かなくて行動に移せないなら・・・

最初に技術力(or自分より格上だが手の届く距離にいる人)のベンチマークを設定し、そこまでたどり着いたら副業を一件受注する。
と決めておく。

ゴールと現時点の差分を必ず言語化し、何ができていないのか、埋めるには何をすれば良いのか。を日々振り返る。
差分を埋める作業としてQiitaへの投稿などのアウトプットは非常に有効。

加えて、

自分のプロダクトとしての商品価値をいかに世の中に発信するか

どのような点がフックとなるかを意識する。
(ある程度の技術力を前提に、+αで自分のラベルとなる物を作る。)

といったお話をしていただきました。

Udemy 「JavaSE8 インタフェース ラムダ式 ストリーム 集中コース」セクション3

セクション3 インタフェース

関数型インターフェース:SE8から追加された機能

関数型インターフェースの特徴

  • 抽象メソッドは1個のみ
  • インターフェースの名称と抽象メソッドの名称が1対1で対応している
  • シグニチャ(戻り値と引数)によって処理内容の概要が決定される
  • 関数型インターフェースのオブジェクト化を「抽象メソッドを実装する」方法で実現可能

レクチャー01 SE7までのインタフェースの特徴

  • 複数個の抽象メソッドが設定可能
  • 継承にて利用されるのが一般的
  • 定数はpublic static扱いになる
  • オブジェクトにはなれない
  • プログラミングよりも設計段階にて利用される
public interface Se7Interface {
    // 定数(public static は省略可。)
    public static int fromHeiseiYear = 1898;

    // 抽象メソッド(abstract は省略可。)
    abstract String getData(String data);
    abstract Integer getInteger(Integer integer);
}

Se7Interfaceは抽象メソッドを複数持つため関数型インターフェースではない。

SE7→SE8の変更点:オプジェクトになることができる(new ~~Interface)

レクチャー02 SE8インターフェースの特徴

  • 複数の静的(static)メソッドが設定可能
  • 複数個のdefaultメソッドが設定可能
  • 複数個の抽象メソッドが設定可能

 (利用時:実装化か必須)
 (再確認:関数型インターフェースの抽象メソッド数は1個

  • new演算子によるオブジェクト生成が可能
  • 関数型インターフェースはSE8インターフェースにおける一つの特殊な形態である。

レクチャー03 インターフェースのまとめ

f:id:nickota:20200108151421p:plain

レクチャー04 SE8を利用したサンプルプログラム

Java7までは匿名クラスを作るか、インターフェースを実装したクラスを作るしかなかった。

public interface SampleInterface {
    // 静的メソッド
    static void printStatic() {
        System.out.println("静的メソッド");
    }
    // defaultメソッド
    default void printDefault() {
        System.out.println("Defaultメソッド");
    }
    // 抽象メソッド
    abstract void printAbstract(String inStr);

    // 実装されているメソッド → コンパイルエラー
    //    void printMethod() {
    //        System.out.println("実装されているメソッド");
    //    }
}
public class S03L04 {
    public static void main(String[] args) {
        // 静的メソッドはnewしなくても実行可能
        SampleInterface.printStatic();
        // 抽象メソッドが未オーバーライドなのでコンパイルエラー
        // SampleInterface si1 = new SampleInterface(){};

        // 匿名クラスを用いたオブジェクト生成
        SampleInterface si2 = new SampleInterface() {
            @Override
            public void printAbstract(String inStr) {
                System.out.println(inStr);
            }
        };
        // defaultメソッドの実行
        si2.printDefault();
        // オーバーライドされたメソッドの実行
        si2.printAbstract("オーバーライドされた抽象メソッド");
        // S03L0402オブジェクトにて実行
        S03L0402 s = new S03L0402();
        s.printAbstract("オーバーライドされた抽象メソッド2");
    }
}

class S03L0402 implements SampleInterface {
    @Override
    public void printAbstract(String inStr) {
        System.out.println(inStr);
    }
}

レクチャー05 関数型インターフェース

@FunctionalInterface
public interface CheckWonLottery {
    // 抽象メソッド
    abstract public String check(Integer inNnumber, Integer winNumber);
}

[補足事項]

  1. @FunctionalInterface:関数型インタフェースを意味するアノテーション
  2. abstract:抽象メソッドを意味する、省略可能
  3. 静的メソッド、defaultメソッドの有無には捕らわれない

[構文解説]
シグニチャ:
引数:二個のInteger、戻り値:String

[関数型インタフェースの特徴]
CheckWonLotteryとcheck(抽象メソッド)が1対1に対応している

レクチャー06 関数型インタフェースのオブジェクト生成と利用方法

public class S03L06 {
    public static void main(String[] args) {
        CheckWonLottery cw = new CheckWonLottery() {
            @Override
            public String check(Integer n1, Integer n2) {
                if (n1 == n2) return "的中";
                else return "外れ";
            }
        };
        String result = cw.check(10555, 105559);
        System.out.println(result); // 外れ
    }
}

注意:

  1. check(Integer n1, Integer n2)で”int” のような基本型は使わないと覚えておく。
  2. “CheckWonLottery” のような特定の場合だけに使うような名前は避ける。より寛容的な名前をつけよう。

レクチャー07 SE8にて利用できる主な関数型インタフェース一覧

f:id:nickota:20200108152638p:plain

これらのインタフェースはJava8から組み込まれている。普通に使って良い。
それぞれのシグニチャはバラバラ。

新たな関数型インタフェースを作ることは稀。
適切なものを上記から選んで使うのが好ましい。

レクチャー08 関数型インタフェースJavaAPIドキュメントの参照方法

!!!!JavaAPIは見る癖をつけましょう!!!!!
Consumer インタフェースのAPI参照する。
andThenというメソッドがあるからどのような挙動か確認してみる。

import java.util.function.Consumer;

public class S03L08 {
    public static void main(String[] args) {
        // 構文:abstract void accept(T t)
        Consumer<String> cs1 = new Consumer<String>() {
            @Override
            public void accept(String inStr) {
                System.out.println("cs1" + inStr);

            }
        };
        cs1.accept("の実行");

        Consumer<String> cs2 = new Consumer<String>() {
            @Override
            public void accept(String inStr) {
                System.out.println("cs2" + inStr);

            }
        };
        cs2.accept("の実行");

        Consumer<String> cs3 = cs1.andThen(cs2);
        System.out.println("以下、cs3の実行結果");
        cs3.accept("の実行"); // cs1とcs2のオブジェクトが連続実行
    }
}


次回から今まで書いた匿名クラスをラムダ式に変換していく。

Udemy 「JavaSE8 インタフェース ラムダ式 ストリーム 集中コース」セクション1、2

今更ながらJava8を本格的に勉強する。

 教材URL:

https://www.udemy.com/course/javase8-h/

セクション1

コース全体の説明。割愛。

セクション2 型パラメータとジェネリクス

書き方のまとめ

//型パラメータが指定されたクラス
class Base01<T>{}
//境界値パラメータが指定されたクラス
class Base02<T extends Super01>{}
//Stringが指定されたコレクション
List<String> list02 = new ArrayList<>();
//型パラメータが指定されたコレクション
List<Base01> list03 = new ArrayList<>();

0201 型パラメータの種類と誤例

1. 型パラメータを表す文字の種類→処理対象

E: Element → 要素オブジェクト
K: key → キーオブジェクト
V: Value → 値を表すオブジェクト
T: Type → 一般的なクラスのオブジェクト
?: 型を指定しない → 全オブジェクト

型パラメータの使い分けに明確な判断はない。

2. プログラミング不可例
new T();

これはコンパイルエラー。
「EKVT?」 のような大文字は実際にクラスが存在しているわけではない。

List<E> list = new ArrayList<>();

Eというオブジェクトを保存するArrayListという意味。
同様に「E」というクラスは存在しないため、コンパイルエラー。

0202 型パラメータサンプルプログラム

public class Base01<T> {
     private T t;
     public Base01(T t) {
         this.t = t;
     }
     public T getT() {
         return this.t;
     }
     public void setT(T t) {
         this.t = t;
     }
     @Override
     public String toString() {
         return "Base01";
     }
}

Tが例えばString なら全てのTをStringと読み替える。

public class Base02<T extends Super01> {
     private T t;
     public Base02(T t) {
         this.t = t;
     }
     public T get() {
         return this.t;
     }
     public void set(T t) {
         this.t = t;
     }
     @Override
     public String toString() {
         return "Base02";
     }
}

T extends Super01 → 拡張型パラメータ
意味:「Super01というクラスであっても、Super01というクラスを拡張したクラスであっても”T”として保存できる。」

例)
    Super0102 extends Super0101
    Super0101 extends Super01

の時、Super0101もSuper0102もBase02のTになることができる。

0203 型パラメータを利用したオブジェクト生成

型パラメータの利点

  1. 同処理を行うクラスを、処理対象となるオブジェクトごとに作らずに済む。
  2. Javaの構文として利用。(後章にて解説)
public class S02L03 {
    public static void main(String[] args) {
        Base01<String> b01_1 = new Base01<>("Base01_String");
        Base01<Integer> b01_2 = new Base01<>(100);
        Base02<Super01> b02 = new Base02<>(new Super01());

        System.out.println(b01_1.get()); // Base01_String
        System.out.println(b01_2.get()); // 100
        System.out.println(b02.get()); // Super01

        System.out.println(b01_1); // Base01
        System.out.println(b01_2); // Base01
        System.out.println(b02); // Base02
	}
}

0204 型パラメータの構文

1.型パラメータ
<E> → Eのみ
<K,V> → KとV
2.境界値パラメータ
Super01  //スーパークラス
Sub0101 extends Super01  //サブクラス
Sub0102 extends Sub0102  //サブクラスのサブクラス

の時、適用範囲は

<E super Sub0102> → Object, Super01, Sub0101, Sub0102
<E extends Super01> → Super01, Sub0101, Sub0102

0205 境界値パラメータを利用したオブジェクト生成

public class S02L05 {
    public static void main(String[] args) {
        // 事前知識 class Base02<T extends Super01> {
        Base02<Super01> b02_super01 = new Base02<>(new Super01());
        Base02<Sub0101> b02_sub0101 = new Base02<>(new Sub0101());
        Base02<Sub0101> b02_sub0102 = new Base02<>(new Sub0102());

        System.out.println(b02_super01.get()); // Super01
        System.out.println(b02_sub0101.get()); // Sub0101
        System.out.println(b02_sub0102.get()); // Sub0102
	}
}

0206 コレクションの基本的な操作

コレクションの型パラメータにスーパークラスを指定すると、
そのスーパクラス、および、スパークラスを継承するクラスのオブジェクトがコレクションに保存できる。

public class S02L06 {
    public static void main(String[] args) {
        List<Super01> list01 = new ArrayList<>();
        list01.add(new Super01());
        list01.add(new Sub0101());
        list01.add(new Sub0102());

        System.out.println(list01.get(0)); // Super01
        System.out.println(list01.get(1)); // Sub0101
        System.out.println(list01.get(2)); // Sub0102
        System.out.println(list01); // [Super01, Sub0101, Sub0102]

        Super01 s01 = list01.get(2); // 取り出すときはスーパークラス
    }
}

JavaAPIドキュメントを見るとArrayList< E>のようにちゃんと「E」と書いてある。
意味:Super01をスーパークラスにもつ要素は全て保存できる。

取り出す際(s01)はスーパークラスを書いておけば、
継承している全てのクラスを記述する必要がなくなる。

0207 ジェネリックス型に型パラメータを利用したプログラム

目的:以下のようなコレクションを一個のクラスで実現したい
ArrayList<String>
ArrayList<Integer>
ArrayList<Super01>

注意点:万能ではない。三つで共有できるメソッドのみを実装できる場合のみに有効。

public class BaseList01<E> {
    private List<E> e;
    // 新規作成
    public void create() {
        this.e = new ArrayList<E>();
    }
    public List<E> get() {
        return this.e;
    }
    // boolean add(E e)
    public void add(E element) {
        e.add(element);
    }
    // 初期化
    // static<T> List<T> asList(T...a)
    public void setArray(E[] array) {
        this.e = Arrays.asList(array);
    }
    @Override
    public String toString() {
        return e.toString();
    }
}

これらのメソッドはString, Integer, Super01三つどれでも使えるメソッド

0208 型パラメータを持つコレクションのオブジェクト生成および要素表示

public class S02L08 {
    public static void main(String[] args) {
        // 1. Stringのみを保存するArrayListの生成
        BaseList01<String> list01 = new BaseList01<>();
        list01.create();
        list01.add("DOG");
        list01.add("CAT");
        System.out.println(list01); // [DOG, CAT]

        // 2. Super01およびSuper01を継承するオブジェクトを保存するArrayListの生成
        BaseList01<Super01> list02 = new BaseList01<>();
        list02.create();
        list02.add(new Super01());
        list02.add(new Sub0101());
        list02.add(new Sub0102());
        System.out.println(list02); // [Super01, Sub0101, Sub0102]
    }
}

こうすることで複数のクラスを作る必要がなくなる
ちなみに一つのlistで複数の型を持てるわけではない。

BaseList01<String> list01 = new BaseList01<>();
list01.create();
list01.add("DOG");
list01.add("CAT”);
list01.add(1);

は最初に

BaseList01<String> list01 = new BaseList01<>();

のように初期化しているからString縛り。

BaseList01<E> list01 = new BaseList01<>();

も思いつくが、「E」というクラスは存在しないため、コンパイルエラー。
同じBaseList01というクラスでStringもIntegerもSuper01も扱えたのが注目ポイント。

0209 型パラメータ(?)を利用したプログラム

0208からの続きで、list01とlist02を同時に引数として扱えるようにする方法。

public class S02L09 {
    public static void main(String[] args) {
        BaseList01<String> list01 = new BaseList01<>();
        list01.create();

        String[] Data01 = { "DOG", "CAT" };
        list01.setArray(Data01);
        printList(list01); // [DOG, CAT]

        BaseList01<Super01> list02 = new BaseList01<>();
        list02.create();

        Super01[] Data02 = { new Super01(), new Sub0101(), new Sub0102() };
        list02.setArray(Data02);
        printList(list02); // [Super01, Sub0101, Sub0102]
    }

    public static void printList(BaseList01<?> pData) {
        System.out.println(pData);
    }
}

ちなみに

public static void printList(BaseList01<E> pData) {

は同様にコンパイルエラー。

0210 メソッドの構文について

なし

0211 戻り値の型宣言が指定された構文

以下の構文における先頭<R>は戻り値の型宣言。

<R> R getR2(T t, R r){}

以下はコンパイルエラー。クラス内では「T」しか使わないと宣言しているため。

class SampleType01<T>{
    R getR1(T t, R r){}
}

以下はコンパイル可能。
<R>はこのメソッド内で「R」を使いますよーという宣言

<R> R getR2(T t, R r){}

ちなみに以下のようにするとメソッドの最初にがついていなくても
コンパイルが通るようになる。 

class SampleType01<T,R>{}

pmconf2019 二日目メモ

二日目のメモ。

一日目は

nickota.hatenablog.com

 

 

 

参加セッション一覧

  • 変化の激しいプロジェクトを成功に導くには - 会議ドリブンなプロジェクトマネジメントメソッド --- 定金 基
  • 太平洋をまたいで手をつなごう:日本におけるグローバルプロダクト開発 --- Brad Ellis
  • プロダクトアウトな新規事業立ち上げのリアル --- 棚橋 寛文
  • PDMのFlexibilityについて --- 熊谷 亘太郎
  • ともに考え、ともにつくる --- 市谷 聡啓
  • 『突破するプロダクトマネジメント ~ 実践編』 --- 坪田 朋
  • コネクティドカーにおけるプロダクトマネージメント --- 海老澤 雅之
  • ないものをつくるための作法 〜体感からの逆算とデザイン"試行"〜 --- 佐藤 文彦
  • 若者の熱狂を生む「オリジナルヒットコンテンツ」へのこだわり --- 谷口 達彦

 

変化の激しいプロジェクトを成功に導くには - 会議ドリブンなプロジェクトマネジメントメソッド

まとめ

  • 無駄になりがちな定例会議に対して色々なフレームワークを用意した。
  • 「会議を活用することでプロジェクトを推進できます!」
  • PjMメイン

 

PjM仕事とは?

Ans.仕事を動かす仕事

物事を動かすカギは会議にある。会議を見るとプロジェクトがうまく行っているかわかるらしい。

 

無駄な会議が多い

  • 社会はダイナミックに変化。会議が追いついていないのでは?という仮説。
  • 働き方の変化
  • 会議に対してもトライアンドエラーというアジャイル的な発想
  • ビジネスと同様に会議も常に変化するもの捉える
  • 必ずタスクを実施してから議論を進める

会議ドリブン

  • 会議のフレームワークをProject Sprint と読んでた。
  • 色んな本からアイディアを受けていて、机上の空論だけで終わってないのが印象的
  • アジェンダは参加メンバー全員から集めている。議論しないアジェンダを決めるのも大事。
  • 会議での役割はローテーションしましょう。

 

ブログ

blog.copilot.jp

 

太平洋をまたいで手をつなごう:日本におけるグローバルプロダクト開発

あんな経歴自分も欲しい

f:id:nickota:20191116160448j:plain

 

01 You Are Not The User

メルカリがアメリカに進出して苦労したとこ

  • FedExの配達スピードが遅い→"Economy"と"Priority"当直までの早さを価格を変えて表示した

   ↓

  現地に行く大事さを学ぶ。

 

  • UserInterview する。「自分が欲しいと思ってもユーザーは使ってくれない。」

   UserTest.com→ユーザーテスト募集するサービス。便利そう。

 

02 Diversity Teams are Powerful

  • 主張できる文化が大事
  • 恥ずかしかったら会議で手を上げるところや、事前にアジェンダに意見を書いておくことから始める。

 

03 Learning from Japan

  • 日本が経験していること(高齢化)は必ず海外もいずれ経験する。
  • 動画視聴のモバイルへの移行も日本が初めてだった
  • 海外に持って行ってそこで人気だった機能を日本に持ち帰ることもある

   → 例)値段交渉機能

日本での当たり前を海外に持って行ってサービスになった事例:

 配達と送金の早さは日本すごい!!

 アメリカは平気で2−3日かかる。

 ということでInstant Payという送金を一瞬でするサービス始め、大ヒット。

 日本の当たり前を海外に持っていくとヒットすることがある。

 

メッセージ

「海外からのコピーだけじゃなく日本からもぜひ発信して欲しい。」

 

Q&Aセッション

Q. PMとしてフローバルに活躍するための重要なマインドセット

Ans. 日本のマーケッっとはなぜ必要か?を説明するのが大変。実際に現地にいって感じることことが大事。

 

Q. 主張できる文化を日本で醸成するには?

Ans. 心理的安全性。言ったことをみんなが受け止めてくれる雰囲気づくり大事。

   話すと特をし、話さないと損をする環境づくりも大事。

  責任を渡しちゃった方が主張を引き出せる。

 

Q. 失敗を恐れすぎる日本人に一言を。

Ans. 日本人に限った話じゃない。外人も恐れている。

   素直に謝ること!!同じ失敗は繰り返さない。失敗は自分ほどみなは気にしていない。

 

プロダクトアウトな新規事業立ち上げのリアル

  • PdMはフェーズや事業によって求められるものが変わるよ
  • プロダクトアウトであり続けるために大事なことは?

   →ミッションや思想レベルの目線を合わせる。

   →壊すことを恐れない

   →失敗から学習する

PdMはどこまでの範囲の仕事をすべきか

正解はわからない。と前提に置いた上で、

でもそのフェーズのタイミングで最もレバレッジが効くと思うことをやり続けた

いい答えだなと感じた。

 

PDMのFlexibilityについて

フレームワークやハード面の話ではなく、

人間関係やコミュニケーションにフォーカスしたセッション。

 

What's PdM??→Do Anything for Product Success

 

PdMになってから一週間目の実体験

当初はエンジニア組織の改修のためアサインされたが、

最終的には経理部を変えて全体が良い方向に向かったお話。

 

経緯:

経理が毎週エンジニアあてに緊急でデータ要求してくる。

経理は忙殺、フロー改善考える暇もない。

普段のオペレーションのヒアリングからはじめた

当初は開発のテコ入れが必要と思ったら経理に問題があった。

→使われないデータ

→無駄に重複する業務

→背景知らずに仕事

    ↓ 経理の仕事を丸ごと変えた

経理もhappy、緊急タスクなくなって開発もHappy

他の部署に踏み込むFlexibilityも大事だよ

 

細かいコミュニケーションのコツ

傾聴

  • ◯一旦「なるほど」と返してから深い話を聞いていく
  • ◯「こうやって理解したけどあってますか?」
  • ×なぜ?と聞き返す

Sympothy

 相手の気持ちになって考えましょう

Suggest:PdMが一番真価を発揮するところ

  • 「もしかしたらこうしたらうまくいく?」
  • 「こんなアイディアあるんですけど」

 人間は自分の考えたアイディアを支持したくなる。

Solve Issue

 ×自分のアイディアと自慢する。十分色んなところに顔だしてるから目立ってるはず。

Thanks

 感謝する気持ちを口にだす。「なんかすみません。」を口癖に。

 

そのように気をつけていくと

↓↓↓↓↓↓↓

Trust

信頼される。常に他の人のおかげで仕事できていると認識する。

相手を尊敬する。尊敬しているかどうかは必ず伝わる。

 

ハーマン脳優勢度調査

脳のタイプによって話かたを変えている。

www.herrmann.co.jp

プロジェクトに関わるひと全員の脳タイプを事前にゲーム感覚で把握しあって、

人によって説明の仕方を変えているらしい。

 

最後に

PdMが一番楽しんでいないプロジェクトは何かがおかしいはず。

 

ともに考え、ともにつくる --- 市谷 聡啓

エンジニアとPOの境界線を無くして、チームとして仮説検証していくお話。

変にまとめるよりスライド参照すべき

www.slideshare.net

 

セッション後に個人的な質問

Q. エンジニアとPOの境界線をなくすと言っても、ドメインに関する知識の深さに差が大きく、仮説検証がエンジニア側には厳しい。どのように足並みを揃えば良いでしょうか。

Ans. 内部探索と外部探索

 

内部探索:

サイトをユーザーになったつもりでPO、エンジニアでモブ形式で触る。

POとしての解釈をエンジニアに説明する。

みんなで問題を見つける。

仮説キャンバスを頭に浮かべながら(実際埋めるの大変だから)仮説を立てる練習をする。

 

外部探索:

ユーザーに使ってもらっているところを実際に見てみる。

最初は観察するだけで、後から「なぜその操作をしたのか」と質問する。

 

『突破するプロダクトマネジメント ~ 実践編』

モノ作りのおける100点の基準をチームで合わせましょう。

以上。

 

コネクティドカーにおけるプロダクトマネージメント

www.slideshare.net

 

  • 3年周期のWFで出来上がるハード(クルマ)とそれに合わせてアジャイルで作るソフトウェアの融合のお話。
  • クルマ開発者とIT開発者が同じチームにいて、コミュニケーション取れたのがすごいよかった。

  •  

    ソフトを作るのにハードの知識が必要。ソフトウェア開発が車を含めた体験になる。 

ないものをつくるための作法

  • Goalは体感であり、Techではない。
  • 「新しいテックを使って新しいことをしよう」は危険
  • テクノロジーは手段でしかない
  • 体験のコアを決めるまではビジュアルに逃げない(Pinterest禁止)
  • 会議より実感。実感もよりリアルに近いもので判断する。

若者の熱狂を生む「オリジナルヒットコンテンツ」へのこだわり

Product(ソフトウェア)とContent(中の番組)の比率が変化した

今まで

 Product:Content

 9.0 : 1.0   →UI・UXが良ければはやる

動画時代

 5.0:5.0

 

若者が求めるもの

「共感・リアリティ・眼福」

単に過激・エロを求めているわけではない。

pmconf2019 一日目メモ

 

pmconf2019に参加してきた。

 

https://2019.pmconf.jp/

 

参加セッション一覧

ORDINARY PEOPLE, EXTRAORDINARY RESULTS

www.slideshare.net

まとめ

  • リーダーとチームの信頼(本日の頻出単語)が足りていない。
  • 機能を作るだけではなく、顧客に与える価値にフォーカスしましょう。

 

個人的に一番面白かった。 ⬇︎書いた人。

 

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

 

 

途中Leanスタートアップのような話が出てきた。

  1. 我々が解決しようとしている問題に消費者は気づいているか?
  2. 解決策があれば消費者それを買うか?
  3. 我々から買ってくれるか?
  4. その問題の解決策を我々を用意できるか?

 

一番伝えたかったスライド

f:id:nickota:20191112193431j:plain

FeatureチームとProductチーム

Feature Team(ITチームとも呼ばれる)

  • "Only care about delivery. Don't care about the results"らしい。
  • 想いの矛先が顧客に向いていない。
  • × value △ usability ◯ roadmap to develop だけを考えている。 

True Product Team

・顧客に与える価値を第一に考えている。

・こっちを目指しましょう。

 

多くのリーダーたちはプロダクト開発の本を読んでいるのになぜ実践しないのか?

Ans. チームを信頼していないから。

トップダウンで指示していてチームへの信頼が足りていない。

そのような組織はスケールしないし、機能しない。

 

↓ (補足)"Best book" としてオススメしていた。

Start-up Nation: The Story of Israel's Economic Miracle (English Edition)

Start-up Nation: The Story of Israel's Economic Miracle (English Edition)

 

 

Product Manager と Project Manager の違い

Ans.

PdM:Cares about the product and customer. Needs true product team.

PjM: Cares only about the feature. Needs only feature team.

 

ほとんどのPdMはPdMの仕事をしていないらしい。

プロダクト開発をきちんとするためにもPdMはPdMの仕事をきちんとしましょう。

 

Amazon Apple Google のお話

どこもプロダクト開発上手だけど中身は全然違いますよ。

共通なことととして、上記の企業のCEOは同じ人がコーチしている。

↓ の人

 

Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Bill Campbell (English Edition)

Trillion Dollar Coach: The Leadership Playbook of Silicon Valley's Bill Campbell (English Edition)

 

 

Leadership VS Management

The Role of Leadership

  • Product Vidion
  • Product Strategy
  • Product Principles
  • Product Priorities
  • Product Evangelism

The Role of Management

  • Staffing
  • Coaching
  • Objective

 

PdMは人のマネジメントをすべきでない。そんな暇はないはず。

それはマネージャに任せよう。

何度も言うがPdMはPdMの仕事をしろ。

 

名言っぽいこと言ってた

"Great products don't come from people. They come from teams"

 

その他重要な発言↓

 

f:id:nickota:20191112200756j:plain

f:id:nickota:20191112201050j:plain

 

↓ 最も大事

f:id:nickota:20191112201121j:plain

 

Special Session

話し方のせいだろうか、びっくりするほど内容がほとんど頭に残っていない。

他のブログを参考にするように。

 

海外の現場を訪問してわかったコード中心ビジネスの時代におけるプロダクトオーナーシップ 

個人的に最近一番熱いアジャイルとかスクラムのお話。

 

speakerdeck.com

まとめ

  • スクラムは海外が先行していて、直の声を聞きたいと言うことで川口さんが直説聞きに言った話
  • ここ3-4年で業務系(病院とか)が開発者を抱え始めた。
  • あとは、よくあるアジャイルウォーターフォールの比較(ディス?w)

うまくいくと分かっているのに経営陣はどうしてプロダクトチームを信頼しないのか

ここでも信頼 のお話。

Ans. はげちゃぴん問題

この発表面白いらしい。直で聞いてみたかった。

 

speakerdeck.com

 

↓ 誰かに説明したり教育するときによく見かける本

教育心理学概論 (放送大学教材)

教育心理学概論 (放送大学教材)

 

 

プロダクトディスカバリー 

アジャイル界隈で要件定義の代わりに最近よく聞く言葉。

プロダクト開発で以下のことが重要

  • 価値がある
  • 使いやすい
  • 実現可能

それぞれよく

  • 事業部門
  • デザイン部門
  • 開発部門

で分岐してプロダクト作りされるが、びっくりするくらい部門間で情報落ちする。

→だから全ての要素を全部まとめて対応するプロダクトオーナーシップチームを作成するのが良い。

↓ に詳細書かれている

ユーザーストーリーマッピング

ユーザーストーリーマッピング

 

 

AgileとWFの違い

「WFは別に悪くはないんですけど。」と毎回断りを入れながらも終始ディスが入るのが面白い。

リソースのお話

多くの事業の責任者は

要件定義→開発→保守

という流れで、開発が一番リソースを使い、保守になるとそこまで使わないと考えている。(WF

問題点:保守段階でようやくサービスを使い始めたユーザーがフィードバックを本気でしてくるが、そのときにはリソースはあまり使わない前提になっている。

 

だからこそ、ず〜っと作ると言う考えが必要(Agile)。ユーザーが本気になったタイミングでも対応ができる。

 

ピクシブのプロダクトマネージャー、自己組織化されたチーム、チームを支える組織

docs.google.com

 

まとめ

PdMとチームで信頼関係がなければいけない。

以上。

 

“失敗事例で学ぶ” 失敗しないプロダクトマネジメント- PMの必須スキルと、自走する組織のつくりかた -

↓ のブログをメインに説明した。

medium.com

 

note.mu

 

PdMで必要なスキルや、どのように評価するかを明文化できたことが素晴らしい。

  • PdMと言う職業の定義が不明瞭であり、離職者が多かったため以下を整えた。

  ①PMの役割を明確

  ②PMが持つべきスキルの明確化

  ③どこでも通用する人材の育成

 

  • PdMはSQLかけるのは当たり前らしい。
  • PdMは作る能力と拡める能力両方が必要。

 

PdMはスーパーヒーローでなければならないのか

Ans. No。って言うか不可能。

でも、プロダクトの成長と成功を推進できる人材でなければならない。

 

PMHEX

  • プロダクトトライアングルだとわかりにくいからPMHEX作った。
  • 上から一方的に導入は難しい。
  • 現場と一緒に1ヶ月くらいかけて作り上げた。
  • 興味を持たせて自分で作ったと言う考えに巻き込むのが導入成功の鍵。
  • 人事評価にはまだ繋げていない。→1on1の際のコミュニケーションのツールとして利用。

 

WebDirectorとPdMの違い

Ans.

WebDは作ったら終わりと感じている人が多いが、PdMは拡める方にも責任を持つ。

 

責任とは??

×自分でやる。

◯あらゆる助けを得て、誰よりも成功を願って行動を取ること。

 

プロダクトマネージャになるには

15分だけであまり記憶にはない。

 

PdMを目指すエンジニアがあるといいスキル 

  • デバック力
  • エラーログをみて原因が頭にすぐ浮かぶくらい
  • プロダクトに対して責任を持つ
  • ドメイン知識は入って3ヶ月でつければいい
  • プログラムを書くことを本気で頑張る

最後を強調していたのが印象的だった。

きちんとした技術力がバックグラウンドにあるのは強みになる。

 

企業が求めるプロダクトマネージャーとその人材戦略

エンジニア→PdMに興味ある自分にとっては面白かった。

三社の対談方式。会社によって回答がまちまち。

  • ニューズピックスCTO杉浦さん
  • グッドパッチCEO土屋さん
  • クライス&カンパニー代表取締役丸山さん

 

求めるPdM像

  • miniCEO
  • プロダクトへの愛
  • スーパーマン出なくても何か一つ強みを持つ
  • 信頼貯金はPdM個人で作り上げるものだけど、そのお膳立ては企業として必要。

  • PdMがCL側にいるからその右腕になれる
  • Whatを提示できなければならない
  • 会社の文化をどれだけ理解しているか
  • 創業者との意思疎通
  • 価値観近くないとだめ

 

  • 失敗事例:外部からPjMをとってきた。チーム回らない
  • 信頼貯金>権限。いきなり権限渡すは失敗する

 

  • どのようにPdMを育てるか→プロダクトの目的は抽象的で捉えづらいから、スクラムの振り返りなどで一緒に考えることで視座、視野の共有をする

  • 圧倒的に人足りてない
  • 採用したい企業の傾向:人事が理解していないことが多い
  • PdMの育て方→最初は週一で1on1

 

PdMとCEOの違い?

PdM:ユーザーの満足度にフォーカス

CEO:ビジネスモデルをどう構築するか考える。ユーザー満足度が高い状態をいかにしてビジネスとして成り立たせるか。

 

どのスキルのPdMが不足?

突破力がキーワードとして出てくる(海外ではGTDとも表す)

=なんとかする力

 

誰が突破力持ってる?

新規事業とか経験してると良いかもね。

杉・土

自分で何かプロダクトを作った経験を持つのが手っ取り早い。

突破力ある人材探すの大変だから面接で「あなたの突破力を用いて解決した問題は何か?」って聞いてその回答に納得が行くかどうかで良いのでは。

 

PdMの報酬

報酬下げずに平からスタートがやりやすいはず。

一つの事業で1000万〜、全事業統括で2000万〜とか。

自分が採用された時にいくらの価値を生み出せるかを考えなければならない

これから5年で2倍になるよ

 

Keynote Session

zoomの宣伝がほとんど。いっぱい似たようなサービスはあったけどまともに動くものはなかった。

だから宣伝文句も"~~~ And It Works!!!!"みたいな感じ。

 

"Think clients as partners. Not clients."

"Partners is successful = We ourselves are successful."

などなど顧客のことは本当に大事に考えましょうという趣旨。

 

ここでも信頼は本当に大事ですよという話もあり。

 

 

 

初心者が客先常駐の最初の一ヶ月で、少しでも自分好みの仕事ができるように工夫したこと

現状

初めて客先に常駐して、Webエンジニアとして働き始めて一ヶ月ほどが経ちました。

 

「ただ言われることだけをやるだけじゃ面白くないな。」

「周りとも気軽に話せる良い関係性を築きたいな。」

 

と思い、

コミュニケーション

長期的な目標

を意識してきました。その結果、

想像より自分好みの仕事ができるようになりました。

 

 

客先常駐に入る前のイメージ

  • 一人で黙々と作業
  • 言われたことをひたすらこなす
  • 実装経験は積めそう
  • 他の人と仲良くなることはない
  • 一緒につくるという団結感は得にくい

 入ったあとに待っていた現実

  • 話し合いながら進める
  • 問題解決は自ら発信できる
  • 実装経験は積める
  • 毎日誰かとランチ
  • 不具合を直すことによって得られる謎の団結感

 

ご覧の通り、

かなり差がありました

 

 

コミュニケーション

おそらく、自分のスタンス次第では入る前のイメージのままになる可能性もありました。

 

 実際そのような働き方をする人もいます。

 

今回は「入った後に待っていた現実」のような働き方を好む人にとって

少しでも参考になればなと・・・

 

 

仕事を割り振る人とコミュニケーションを取る

今の現場には大きく案件をもってくるPMと、

その仕事を細かく分けて実際に割り振る人がいます。

 

同じ案件の中にも、

  • 機能追加の仕事
  • テストの仕事
  • 保守の仕事

などたくさんの種類が異なる仕事が入っていて、

そのどの仕事を自分の元に引っ張ってこれるかが大事となってきます。

 

したがって、自分は

この仕事を細かく分けて実際に割り振る人に対して、

自分は何の仕事がしたくて

何を勉強しているか

というのをアピールしました。

 

案外エンジニアで自分から発信できる人は少ないと思います。 

そのため、発信することで、より好みの仕事が舞い込んできやすくなります。

 

 

挨拶、ランチは自分から

現場の雰囲気的に挨拶をしない人や他の人とランチに行かない人はたくさんいるのですが、

自分は人付き合いを楽しみたいと思ったので、

自ら話しかけることを意識しました。

 

そして案外ランチに行ってみると人それぞれ趣味や思ってることを聞きだせるため、

仕事の相談、ヘルプ、要求がかなりしやすくなり、

どのような仕事をしていけば良いかというヒントになりました。

 

長期的な目標 

自分の将来の方向性を考えておく

これが一番大事だと感じます。

ある意味、「作業員」と捉えられがちなため、

雑用からスキルアップに繋がらない仕事までいろいろ降ってきます。

 

それは、普通の正社員と比べて長期的な目線で育てる必要がないからです。

必要とされているのは、今ある仕事をこなしてくれる人材であって、

長期的に会社の戦力となる人ではありません。

 

そのため、普通の正社員と比べて

自分がどの方向に進みたいのかを意識し続ける

ことが必要となります。

 

自分の成長は自分が握っているということを、

絶対に忘れてはいけません。

 

まとめ

こんな感じで一ヶ月なかなか良いスタートを切れました。

人の出入りも激しいため常に自分も臨機応変に対応していかなければならないですが、

コミュニケーション

長期的な目標

というのは絶えず意識していこうと思います。