Go言語の勉強でありがたい指摘を頂いた

はじめに

前回のGo言語の勉強記事を書いた時、通知で例のブログSlackに流れるようになってるのですが、その場で、いろいろと指摘いただいたので、忘れないために、それをブログにまとめようと思いました。

消して記事数を稼ごうとしているわけではありません。

指摘事項

1. ローカル変数に関しては、型を指定できず、宣言も := で行う

どのスコープの話しているのかわかりませんが、ローカル変数でも型指定できますよ。

参考

他言語プログラマがgolangの基本を押さえる為のまとめ

これは、自分が勘違いしていたのですが、 := で指定するものが、ローカルの変数で、varを指定したものがグローバルな変数だと勘違いしていただけでした。

実際は、そうではなく、参考で記載されているとおり省略して書ける書き方として := があるみたいです。

fun main() {
    var data01 string = "ぼくはローカル変数だよ "

    data02 := "ぼくもローカル変数だよ varとか型宣言を省略できるよ"
}

2. package package_test というパッケージ名

｀XXX_test｀っていうパッケージ名は通常ビルドに含まれない特殊なパッケージ名なのでやめましょう。

参考

https://swet.dena.com/entry/2018/01/16/211035

パッケージ名_test をテストコードを記述するパッケージ名として利用することもできます。 パッケージ外に公開したAPIを通してのみテストしたい場合は、こちらを利用するとよさそうです。

まだ触ってなかったのですけど、Go言語でtestコードを書くためのtestingパッケージというのがあるらしいのですが、本来はそちらで使用されるべきパッケージ名で(XXX_test)というパッケージ名をつけるようです。

なるほどでした！

3. var data_array

Goでスネークケース書くのはやめましょう。フォーマッタでも怒られます。

参考

これからGolang開発を行うRubyistたちへ

Goでは、変数と関数は最初が大文字で始まるキャメルケースが使われています。

つまりUpperCamelCaseでかく必要があるってことのようです。

golintというのを入れて、実際にsnake_caseで書かれている変数を使用しているgoファイルをチェックしてみるとたしかにエラーが出ました！

$ golint struct.go 
struct.go:34:6: don't use underscores in Go names; var data_array should be dataArray

4. if player.is_die() == true {

bool関数の戻り値を比較するのはやめましょう。 ｀if player.is_die() {｀でいいです（これはあまりGo関係ない

これが一番なるほどと思いましたw

これは自分の今お仕事している案件が、phpかつ、5.6系のプロジェクトであることに起因しているかもしれないなと思いました。

そもそもスカラ型の型指定がないphp5系のプロジェクトだと、自分は明示的に今回のように == true (phpの場合は === true)とつけて、確実にbooleanが返ってきてるよっていうのをコード上で示してあげる癖がついてました。

冗長だから必要ないという話もありますが、それよりも可読性のほうが重要かなと思ってそうしていました。

ただ、Go言語(phpも7系から)はそもそも戻り値の型の指定ができるのだから、booleanであることは明白なので、そもそも必要ないですよねということでした。

5. そこまで大規模に使うものでもないのかもしれません。

一応Goは大規模開発用(多人数開発用)に作られました（だから型があって予約語が少ない。formatterとかもろもろ標準装備されている） GAEとかLinuxじゃなくてGo製の疑似OS(gVisor)のコンテナーで動いてます。あとメルカリなどはPHP全部Goに置き換えてますね。

完全に僕の知識不足でしたｗ

終わりに

いろいろと指摘していただいて、とてもありがたかったです！

また、おすすめの本まで紹介してもらいました！

基本的なところを勉強した後、早速1冊購入してみようと思います！

また、このslackチームもいい循環ができていて、作ったかいがありました。

これからも頑張ろう。

Go言語 勉強(基礎編1)

はじめに

こんばんは。 今年も早くも10ヶ月たって、全く成長してない僕です。

今年のはじめに決めた目標はブレブレになってしまって、どれもこれも中途半端という不甲斐ない結果になっております。

まぁ嘆いてもしょうがないので、今月から気を引き締めて、またやっていこうと思います。

とりあえず今年10月から来年も踏まえて、Go、Python、Javascriptの３つを重点的に勉強しようと思ってます。

比率的には

Go: 4 Javascript: 4 Python: 2

といった比率で勉強しようと思ってます。

なんでこの比率かというと、

Goは、もともと勉強したいというのがあったのですが、知人からGoの案件を紹介してもらったことがきっかけでした。その時は実務経験も勉強もしてない状態だったのでスキル的にミスマッチだったので断ったのですが、せっかくのお誘いを自分のスキル不足で台無しにしてしまうのが悔しかったので、やろうと思いました。

Javascriptは、今年の目標の一つで、フロントエンド側の知見を貯めるというのに続いています。何回かReactやVue.jsの勉強やりましたが、実践で使えるほどの知見は全然溜まってないので、もう少し踏み込んで勉強をしていこうと思っています。FWはReactに絞って勉強しようと思ってます。

Pythonに関しては、唯一成長したというか、調べつつ書けるようになってきている実感があるので、ある程度勉強は続けていこうと思いこの比率です。

あとはSwiftも個人的にやってた時期があるので、どうにか滑り込ませたいなと思ってますが、時間的に厳しいかも。。。

とりあえず今回はGo言語の勉強ですね。

大昔にTour of Goやったくらいなので、さっぱり忘れてます。

さっそくいきます。

やってみた

定番のHello World

package main

import "fmt"

func main() {
    fmt.Println("Hello World")
}

go build goファイルで、ビルドされたバイナリが作成されて、そのバイナリを実行すれば、Hello Worldが表示される

$ go build hello.go
$ ./hello
Hello World

$ ls -la
total 3920
drwxr-xr-x   4 kojirock  staff      128 10  3 00:07 .
drwxr-xr-x  21 kojirock  staff      672 10  2 23:54 ..
-rwxr-xr-x   1 kojirock  staff  1999368 10  3 00:07 hello
-rw-r--r--   1 kojirock  staff       72 10  3 00:01 hello.go

go run goファイル名で、ビルドと実行が同時に行われるけど、対象のバイナリは作られない

$ go run hello.go
Hello World

$ ls -la
total 8
drwxr-xr-x   3 kojirock  staff   96 10  3 00:03 .
drwxr-xr-x  21 kojirock  staff  672 10  2 23:54 ..
-rw-r--r--   1 kojirock  staff   72 10  3 00:01 hello.go

制御構文

1. 繰り返し処理はforのみ、while, foreach, do whileなどはない。でもforのみで再現できる。

// 普通のfor
for i:=0; i < 5; i++ {
    fmt.Println(i)
}

// while
count := 0
for count < 10 {
    fmt.Println(count)
    count++
}

// foreach的なやつ
data_list := map[string]int{
    "aaa": 10,
    "bbb": 20,
    "ccc": 30,
}
for key, value := range data_list {
    fmt.Println("key => ", key, " value => ", value)
}

衝撃だったけど、forしかないことで逆にシンプルだと思った。

break continue は通常通り使えるとのこと。

関数とか変数とか

1. 頭文字が小文字のメンバは、同パッケージ内からのみアクセス可能
2. 頭文字が大文字のメンバは、別パッケージからもアクセス可能
3. 基本的に変数はvar, 関数はfuncで定義
4. 変数は型推論があるので、型の省略も可能
5. ローカル変数に関しては、型を指定できず、宣言も := で行う
6. const定義も可能で、かつ、型を持たない定数が可能。また、関数内でも定義できる。
7. iotaという列挙型みたいなものをconstでは指定できる。

テストのために自分で作成したローカルパッケージを作成してimportする

test_01.go

package package_test

// All package_testの全メソッドを呼ぶ
func All() {
    aaa()
    bbb()
    ccc()
    ddd()
    println(bbbvar)
    println(dddconst01)
}

func aaa() {
    println("aaa")
}

test_02.go

package package_test

var bbbvar = 100

func bbb() {
    println("bbb")
}

test_03.go

package package_test

func ccc() {
    cccvar := 200
    println("ccc")
    println(cccvar)
}

test_04.go

package package_test

const dddconst01 = "dddconst01"

func ddd() {
    const dddconst02 = 2
    println(dddconst02)
    println("ddd")
}

hello.go

package main

import "./package_test"

const (
    Red = iota
    Blue
    Yellow
)

func main() {
    package_test.All()
    println(Red)
    println(Blue)
    println(Yellow)
}

$ go run hello.go
aaa
bbb
ccc
200
2
ddd
100
dddconst01
0
1
2

いろんな型

配列型

固定長の配列を作成する。

// 定義1
var data_array [3]int

// 定義2(初期値を指定できる)
var data_array = [3]int{10, 20, 30}

// 定義3(初期値を指定すると、長さの宣言は...で省略できる)
var data_array = [...]int{10, 20, 30}

// 定義4(indexを指定して初期値を設定できる)
var data_array = [...]int{0: 10, 1: 20, 2: 30}

スライス型

可変長の配列を作成する。

// 定義1
var data_array []int

// 定義2(初期値を指定できる)
var data_array = []int{10, 20}

// 追加方法はappend()
var data_array = []int{10, 20}
data_array = append(data_array, 30)
println(data_array[2])
// => 30

マップ型

phpでいう連想配列かな

var data_array = map[string]int{"aaa": 10, "bbb": 20}
data_array["ccc"] = 30 // 代入は簡単

型宣言(type)

独自の型を作成できる。

reflectパッケージの TypeOf() で指定のものがなんの型がわかる。

package main

import "fmt"
import "reflect"

type TestType int

var param1 TestType = 100
var param2 int = 200

func main() {
    fmt.Println(param1)
    fmt.Println(param2)
    fmt.Println(reflect.TypeOf(param1))
    fmt.Println(reflect.TypeOf(param2))
}

$ go run type.go
100
200
main.TestType
int

学生時代C言語やってたときにこんな事やった記憶があるような気がする。

構造体(Struct)

Goはクラスがないから構造体。めちゃ懐かしい。

1. math/randパッケージを使用して乱数を生成している
2. strconvパッケージを使用して、数値から文字列へのキャストをこなっている

package main

import (
    "fmt"
    "math/rand"
    "strconv"
    "time"
)

type Player struct {
    life   int
    attack int
    luck   int
}

func (p *Player) is_die() bool {
    return p.life == 0
}
func (p *Player) damege(point int) {
    p.life -= point
    if p.life < 0 {
        p.life = 0
    }
}

type Enemy struct {
    life   int
    attack int
    luck   int
}

func (e *Enemy) is_die() bool {
    return e.life == 0
}
func (e *Enemy) damege(point int) {
    e.life -= point
    if e.life < 0 {
        e.life = 0
    }
}

func main() {
    var player Player
    var enemy Enemy

    player.life = 10
    player.attack = 1
    player.luck = 5

    enemy.life = 10
    enemy.attack = 1
    enemy.luck = 5

    // 無限ループはこの書き方
    for {
        player_attack_offet := 0
        enemy_attack_offet := 0
        rand.Seed(time.Now().UnixNano())
        if player.luck >= rand.Intn(10) {
            // 会心の一撃出す
            player_attack_offet++
        }

        if enemy.luck >= rand.Intn(10) {
            // 痛恨の一撃出す
            enemy_attack_offet++
        }

        enemy.damege(player.attack + player_attack_offet)
        fmt.Println("プレイヤーの攻撃！敵に" + strconv.Itoa(player.attack+player_attack_offet) + "のダメージを与えた！")

        player.damege(enemy.attack + enemy_attack_offet)
        fmt.Println("敵の攻撃！プレイヤーに" + strconv.Itoa(enemy.attack+enemy_attack_offet) + "のダメージを与えた！")

        if player.is_die() == true {
            fmt.Println("敵の勝ち！")
            break
        } else if enemy.is_die() == true {
            fmt.Println("プレイヤーの勝ち！")
            break
        }
    }
}

$ go run struct.go
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの勝ち！

ダラダラと長くなってしまったけど、こんな感じなのかな？

ポインタ型

C言語でお馴染みのポインタ。確か僕が挫折したのがポインタ。

ただ、ロジックの見通しよくするためには、必要だし、苦手意識は克服しなければ。

func main() {
    var player Player
    var enemy Enemy

    player.life = 10
    player.attack = 1
    player.luck = 5

    enemy.life = 10
    enemy.attack = 1
    enemy.luck = 5

    // 無限ループはこの書き方
    for {
        battle(&player, &enemy)
        if player.is_die() == true {
            fmt.Println("敵の勝ち！")
            break
        } else if enemy.is_die() == true {
            fmt.Println("プレイヤーの勝ち！")
            break
        }
    }
}

func battle(player *Player, enemy *Enemy) {
    player_attack_offet := 0
    enemy_attack_offet := 0
    rand.Seed(time.Now().UnixNano())
    if player.luck >= rand.Intn(10) {
        // 会心の一撃出す
        player_attack_offet++
    }

    if enemy.luck >= rand.Intn(10) {
        // 痛恨の一撃出す
        enemy_attack_offet++
    }

    enemy.damege(player.attack + player_attack_offet)
    fmt.Println("プレイヤーの攻撃！敵に" + strconv.Itoa(player.attack+player_attack_offet) + "のダメージを与えた！")

    player.damege(enemy.attack + enemy_attack_offet)
    fmt.Println("敵の攻撃！プレイヤーに" + strconv.Itoa(enemy.attack+enemy_attack_offet) + "のダメージを与えた！")
}

$ go run struct.go
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに1のダメージを与えた！
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
プレイヤーの攻撃！敵に2のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
プレイヤーの攻撃！敵に1のダメージを与えた！
敵の攻撃！プレイヤーに2のダメージを与えた！
敵の勝ち！

おわりに

とりあえず今日はここまでです。

やってみて思ったけど、すごくシンプルで覚えることも少なそうだけど、シンプルだからこそ、設計力が求められそうな感じだと思いました。

でも、Go言語でガッツリwebサービス作るっていうよりはAPI的な立ち位置で使ってるケースが多いからそこまで大規模に使うものでもないのかもしれません。

でもGoのフレームワークもあるみたいだし、せっかくだからwebサービス作る方向で勉強してみようとおもいます。

おすすめの本などあれば教えてください。

そういえば、最近やっとsublimeからvscodeに乗り換えたんですけど、すごくいいですね。同じElectronで作られてるAtomとはえらい違いです。

php or jsはphpstorm

pythonはspyder

それ意外のものに関してはvscode

って感じで定着しそうです(もはやpythonもvscodeになりそう)

おやすみなさい。

Ruby勉強その2(基礎の基礎)

はじめに

前回の続きです。

CODEPREPでRubyやってます。

やってみた

空Hashの作成方法

hash_data = Hash.new()

new Hash() かとおもったら逆だった。

配列からのHash化

array_data = ['AAA', 'aaa', 'BBB', 'bbb', 'CCC', 'ccc']
hash_data = Hash[*array_data]
p hash_data

=> {"AAA"=>"aaa", "BBB"=>"bbb", "CCC"=>"ccc"}

これ結構便利だなぁ。

phpではこの関数なさそう。たぶん。

array_combineとかならあるけど。

Hash(key, valueの組み合わせ)の配列化

hash_data = {'AAA' => 'aaa', 'BBB' => 'bbb', 'CCC' => 'ccc'}
p hash_data
=> {"AAA"=>"aaa", "BBB"=>"bbb", "CCC"=>"ccc"}

p array_data.to_a
=> [['AAA', 'aaa'], ['BBB', 'bbb'], ['CCC', 'ccc']]

簡単に変換できるのは楽だ。

こういうところも人気なひとつなのかな。

Hashのkeyやvalueをすべて取得

key

hash_data = {'AAA' => 'aaa', 'BBB' => 'bbb', 'CCC' => 'ccc'}
hash_data.each_key do |key|
  p key
end
=> 'AAA'
=> 'BBB'
=> 'CCC'

p hash_data.keys
=> ['AAA', 'BBB', 'CCC']

value

hash_data = {'AAA' => 'aaa', 'BBB' => 'bbb', 'CCC' => 'ccc'}
hash_data.each_value do |val|
  p val
end
=> 'aaa'
=> 'bbb'
=> 'ccc'

p hash_data.values
=> ['aaa', 'bbb', 'ccc']

keys と values は、 array_keys() や array_values() なんかと一緒だけど、一個ずつ取り出せるってのもあるようだ。

Hashの各存在確認

Hashが空かどうか

hash_data = {}
if hash_data.empty?
  p "empty!"
end
=> empty!

Hashに指定のkeyが存在するか

hash_data = {'AAA' => 'aaa', 'BBB' => 'bbb', 'CCC' => 'ccc'}
if hash_data.key?('AAA')
  p "exists!"
end
=> exists!

phpではisset() とか empty() を使う感じだけど、rubyでは ? を使うのか。

なんかかわいい。

終わりに

細かいところが違うけど、続けてやるとある程度わかってきた。

次もRubyやろう。Goの勉強はある程度Rubyやってからだな。。。

続けてやらないとすぐ忘れる。

あ、シュタゲゼロ始まる。

ではでは。

勢いで作ったslackグループで書いていない人にメンション送るようにした。

先日作ったslackグループにどんどん人が入ってきてくれて、若干引いています。

それはそれとして、書いてない人にリマインド飛ばせるようにしたいなと思ったので、lambda + cloudwatchで定期的に通知飛ばせるようにしました。

SlackにRSS登録してその通知を受け取って、通知がきていない = 書いていない人とみなして連絡するようにしました。

この手法のデメリットは毎回RSSを登録してもらう必要があるんですよね。。。

書いたコードが実際に動くのが来週なので、もしかしたらバグってる可能性ありますが、一旦公開しておきます。

実際動いてバグってたら修正します。

# coding: UTF-8
import os
import sys
sys.path.append(os.path.join(os.path.abspath(os.path.dirname(__file__)), 'vendor'))

import urllib
import requests
import json
import datetime
import yaml


def getMessageApi():
    u"""
    Slackの特定チャンネルからメッセージを取得する 
    特定の投稿のみを抜き取るのが難しいので、1週間単位で取得するようにした
    @return array
    """
    config_data = getConfigData();
    latest      = datetime.datetime.now()
    oldest      = latest + datetime.timedelta(weeks=-1)
    params      = urllib.parse.urlencode({
        'token'   : config_data['slack_token'],
        'channel' : config_data['slack_get_message_channel_id'],
        'oldest'  : oldest.timestamp(),
        'latest'  : latest.timestamp(),
        'count'   : 1000
    })

    results  = []
    response = requests.get(config_data['slack_get_message_api_url'] + '?' + params).json()
    for message_data in response['messages']:
        if 'username' in message_data:
            results.append(message_data['username'])

    return results



def sendMessage(message_data):
    u"""
    Slackの特定チャンネルにメッセージを投稿する
    @param array message_data
    @return none
    """
    config_data = getConfigData();
    requests.post(config_data['slack_send_message_api_url'], data = json.dumps({
        'text'       : makeSendText(message_data),
        'channel'    : config_data['slack_send_message_channel_name'],
        'link_names' : 1
    }))



def makeSendText(message_data):
    u"""
    Slackへ送信するようのメッセージを作成する
    @param array message_data
    @return string
    """
    config_data  = getConfigData()
    target_users = []
    for config in config_data['mapping_table']:
        if not config['blog_name'] in message_data:
             target_users.append("<@" + config['user_name'] + ">さん")

    text_data = "<!channel>\n今週ブログを書けていないユーザーがいます！\n今週中に書けるようみんなで煽りましょう！\n書けていないユーザー\n================\n" + "\n".join(target_users)

    return text_data



def getConfigData():
    u"""
    コンフィグデータを取得する
    @return array
    """
    with open('./config.yml', 'r') as yml:
        config_data = yaml.load(yml)

    return config_data


def lambda_handler(event, context):
    message_data = getMessageApi()
    sendMessage(message_data)

勢いで週一ブログ書くslackグループを作った

例に漏れず、@kakakakakkuさんの影響でブログ書き始めて9ヶ月くらい立ったけど、書いているときとか結構孤独で、時々週イチで書けなくなるときがあります。

同じような人がもし入れば、お互いに応援というかいい意味で煽りあって、プレッシャーを与えあい、書き終えたらみんなでいいねと言い合う感じの健全な場があればいいなと思いました。

そんなときtwitterで以下のサイトをしりました。

shu-1blog.com

需要があるかどうかわかんないし、完全見切り発車ですけど、slackでもグループ作ってみるかなーとおもって作りました。

https://join.slack.com/t/write-blog-every-week/shared_invite/enQtNDQwMjM1MjU3NTU2LWMzOGJkMTcyODQ1YTU3NDE2M2E3ZDUwMDNmODFhMDhmMTdhZGM0ODU1NDFhOTIyODRlYzg0ZDU2YjExZmZkMGI

人数が急激に増えたため、現在新規募集を締め切っております。

詳細はこちら

とりあえず細かいルールはなしで、

週イチでブログ書く。 書けてなければ煽る。 書いた際は褒める。

この３つだけできるグループでいいかなと。

全然需要なかったとしても一人slackとして活用しときますｗ

興味があれば入ってくださいー。

Ruby勉強その1(基礎の基礎)

はじめに

こんばんは。Go言語の勉強やりたいんですが、積本がやまほどあるのでそれを消化するのと、今後はRubyの案件もとっていけるようにRubyの勉強をしようと思っています。

ちなみにGoは別日でちゃんとやる予定です。本も買ってるしね。

とりあえず、phpしかメインで触ってなかった僕ですが、pythonはまぁまぁわかるようになったし、rubyへの言語ジャンプも、頑張れば可能かなと思っています。

チュートリアルやオンラインの学習サイトなど見ながら気になった点を忘れないように上げときます。

主にphpとの違いを列挙してみました。

やってみた

べき乗

phpでは pow() 関数を使って表現するけど、rubyは演算で可能みたい

puts 10 ** 5
# 100000

型変換

to_s とか to_i とかでやるみたい

puts "test => " + 10
# Traceback (most recent call last):
    1: from test01.rb:1:in `<main>'
test01.rb:1:in `+': no implicit conversion of Integer into String (TypeError)

puts "test => " + 10.to_s
# test => 10

if文

目新しい感じはなかったけど、elsifが面白かった。

elseifにしなかったのはなんでだろう。

message = "BBB"
if message == "AAA"
    puts "Yes"
elsif message == "BBB"
    puts "No"
else
    puts "???"
end
# No

unless

条件が正しくない場合に使うっぽい。

つまりif の否定式ってことだと思うけど、使い分けはどうやるんだろう?

rubyで動いているプロダクションコード見てみたい。

message = "AAA"
unless message == "BBB"
    puts "BBBではありません。"
end
# BBBではありません。

case

switchみたいな感じだと思うけど、switchより便利っぽい

score = 70
case score
    when 0..30
        puts "留年決定"
    when 31..60
        puts "追試決定"
    when 61..85
        puts "合格ライン"
    when 86..100
        puts "天才だ！"
end
# 合格ライン

times

数値の回数繰り返し処理を行う

forとの使い分けを知りたい

10.times{|i|
    puts i
}
# 結果
0
1
2
3
4
5
6
7
8
9

upto

数値から指定した数字まで繰り返し処理を行う。

これはtimesよりはforとのすみ分けができてそう。

10.upto(15){|i|
    puts i
}
# 結果
10
11
12
13
14
15

downto

uptoの逆

10.downto(5){|i|
    puts i
}
# 結果
10
9
8
7
6
5

redo

繰り返し処理をもう一度やり直す。

これが一番へぇとなった。

○○の処理の場合、繰り返すみたいな処理って結構あったりするから、これは地味に使えそう。

phpだとどうやってるかな・・・

同じ値で上書きしたりしてお茶を濁したりしてそう。。。

count = 0
10.times{
   count += 1
   if count == 5
       redo
   end

   puts count
}
# 結果
1
2
3
4
6
7
8
9
10
11

終わりに

phpとの違いがいろいろあっておもしろかった。

次も多分Ruby関係になりそう。

もしくは本読んだ書評。

まとまりないなこのブログ。

でもいいよね。備忘録だし。

sayonara sayonara

FEARLESS CHANGEを読んだ

はじめに

こんばんは。

FEARLESS CHANGE をよんでみました。

昔に買って、ずっと積本になってる本でした。。

今月・来月くらいまでは集中してGo言語の勉強をしようと思ってたんですが、先に積本消化しようと思い、重い腰を上げてやっと読めました。

Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン

社内(チーム内)に新しいアイディアなり、ルールなり、サービスなりを広めて定着させるには、どのようにすればよいかという方法をパターン化して紹介されてます。

導入前に実践すべき方法や、導入中、導入後など現在の状況に応じて適用できるパターンが存在していて、知らず知らずのうちに実践していたというものもありますが、参考になるべきものばかりでした。

1〜48のテクニックの中で自分が、「お、なるほど」と思った、文章を抜粋して紹介したいと思います。

引用部分は各テクニックで僕が印象に残った文章というだけなので、引用部分がそのテクニックで伝えたいことではないです。

感想

1. エバンジェリスト

あなたの組織において、そのイノベーションがもつ可能性についてもっと学ぼう。しかし、あなた自身は専門家でないことを、常に認識しておこう。あなたが専門家の役割を担えると売り込んだり、できると思い込んではいけない。

人数が少ないスタートアップ企業だと、その導入したいアイディア(サービス)を本人しか知らないって状況はザラにあると思う。

なのである程度、自分が答えられるよう知識を蓄える必要がある。

ただ、自分以外に詳しい人が現れても、そこで悲観することはない。自分は「専門家」ではないから。

あたり前のことだけど、プライドが高い人とかは、ここに引っかかりそうな気もして、なるほどと思った。

2. 小さな成功

私たちはつい、成功を決定づけるドラマティックな「大きな勝利」イベントに、力を入れすぎてしまう。これは本当によくあることだ。最終的に求める目的地へ導いてくれる継続的な改善よりも、魔法の銀の弾丸に気が向いてしまうのだ。その結果ほとんどあらゆる仕事では、勝者として認識してもらえる機会なんて、ほんのわずかだ。

この小さな成功自体は、やる気を長持ちさせる方法として、よく言われてる手法だとおもうけど、仕事として置き換えたときに、ちょっと見え方が違った。

この改善のタスクはあんまり評価されないけど、実際に売上が大幅に上がったこのタスクは、すごく評価されて、その結果給与が上がったみたいなことってあると思う。

インパクト的に薄いタスクの評価も、きちんとしてもらえるほうが、こちらもありがたい。

↑は仕事の各タスクの話だけどw

アイディアを広めるために適用するとすると、例えばチームで持ち回りでブログ記事やQiita記事を書くってなった時とかに、はてぶ数とか、いいね数が例え少なくても、「いいね！」とかチーム内で言い合うことが大事って感じかな？

認めてもらえたことで次のアクションの起爆剤になると思う。

こういった「成功」を見逃すなよってことかな。

承認欲求的なところとも関わってきそう。

3. ステップバイステップ

チェンジエージェントが犯すもっともよくある失敗は、あまりに急いでたくさんのことをやろうとすることだ。彼らは、植物を上から見下して「成長しろ！もっと頑張れ！君たちにはできる！」と命令している庭師のようなものだ。しかし、どんな庭師でも、成長する意欲をもたせるために植物を説得するようなことはしない。そのかわり、大きな変化はゆっくりと始まり、時間をかけて着実に進化するということを理解している。

このたとえは、2の小さな成功とともに、なるほどと思った。

2の例えで言えば、いきなり社外に向けたカチッとした記事を書く前に、社内だけ共有されるQiitaTeamとかEsaとかで社内向けの記事を書くところから始めようぜ！って感じかな。

4. 予備調査

時にアイデアは組織で受け入れられるには、新しすぎたり、急進的すぎることがある。また、ベンダーや製品の好みなど、他の制約と衝突するかもしれない。強硬に進めることよりも、組織が変化を受け入れられるまで少しだけ待ってあげるほうがよいかもしれない。適切な効果が得られる時期まで、あなたのエネルギーをとっておくのだ。

4番目に来てるけど、このパターンが一番最初にやるべきことっぽい。

例えば新しい開発言語を導入するとき、当然だけど予備調査が必要になる。

でも、引用したとおり、開発メンバのスキルなども関係してくるから、よいと思って導入を急くよりも、今のチームにマッチするかなど、そのような調査が必要。

...当然か。

5. ふりかえりの時間

学習する組織を作るためには、プロジェクトについて議論する習慣を身につけなければならない。同様に、個人としても学習するため、私たちはふりかえるための時間を取らなければならない。リンカーン大統領はこう言っている。「我々は正しく行ったことより、正しく行えなかったことからより多く学ぶ」そして、そのための時間が確保できなければ、学ぶことはできない。

チームでのふりかえりというとKPTとかだけど、最近のKPTは「ふりかえりから学習する」というよりも、「ふりかえること」だけをやっている気がする。

いい気付きができた。せっかく振り返りの時間を設けてもらっているのだから、そこから学習することしなければ、あまり意味がない。

6. 協力を求める

常に完璧な信頼性と確実性を示すリーダーは、結果的に現実をやや歪曲する空間をつくりだす。一方で、自分の弱点を認めるリーダーには、人々は心を動かされ、驚くほど惜しみない手助けをしてくれる。

わかる。圧倒的なリーダーシップを持ってる人には、ある程度盲信してしまうっていうのはあると思う。

そのリーダーの方向性にチームが傾いちゃうので、そのリーダーがイノベーターだと、メンバーは疲弊しちゃいそう。

チームは一人で動くのではなく、みんなで動くもの。

7. ブラウンバック・ミーティング

午前中や午後よりも、昼どきのミーティグングの方が多くの人々の関心を引く一方で、ランチミーティングには参加したがらない人たちもいるだろう。彼らはランチタイムを休憩時間としてとらえているからだ。そんな人たちのために別のイベントをアレンジする必要があるだろう。

よくわかる。熱量的に同じ人であれば、たとえ休憩時間と捉えていても参加してくれるけど、そうではない人は参加したがらない。

自分がいるチームの場合は、昼よりも定時後酒飲みながら、ミーティングと言うスタンスではなく話し合いという感じが一番マッチしてそうだった。

これもステップバイステップでどんどん本格的なミーティングに移行できればなおいい。

8. コネクター

新しいアイディアがもつ価値を確信してもらえるよう、個人的な接触を試みるのだ。インフルエンサーたちが相手なら、説得はたやすいはずだ。たとえ説得が難しくても、時間を掛けるだけの価値はある。ひとたび彼らが興味をもてば、彼らの持つコネクションが、あなたが情報を広めるためにかけなくてはいけない努力を減らしてくれるからだ。

すごいわかる。

自分は社交性が低いから、自分がアイディアを広める場合はコネクターの存在が絶対必要。

身近にコネクターがいるのはとても心強い。

9. 何か食べながら

贅沢にする必要はない。たとえ食べ物がシンプルでも、このパターンにおける影響力は揺るぎない。食べ物は小さいミーティングにも影響力がある。二人の間であっても。

このあたり、飲み会とかただの宴会的なところとの差を明確にしておかないとだめだと思った。

そのために、酒はなしで、あくまで簡単な飲み物とお菓子くらいが一番いいとお思う。

10. 電子フォーラム

そのメディアを監視すれば、そこで得られるデータを変化にむけた活動の今後の動きに十分関心がある身近な支援者や経営層の支持者の説得に利用できる。

slackとかの特定チャンネルで情報を発信していくような感じだと思うけど、個人的には新入りの人たちにはハードル高い印象がある。 その点でWorkplaceは、書き込みの敷居が低いいいサービスだと思う。

11. アーリーアダプター

アーリーアダプターは、単なる改善よりも根本的な進捗について考えるビジョナリーだ。新しいというだけの理由でアイデアを歓迎する熱狂的なイノベーターとは違い、アーリーアダプターはそのアイデアの有効性をよく考え、アイデアをビジネス上のゴールに結びつけようと試みる。結果として、彼らはしばしば同僚からの尊敬を得て、よいオピニオンリーダーとなる。

イノベーターとアーリーアダプターの役割が違うのは理解できたが、自分の経験上、イノベーターのような動きをしている人は結果的にアーリーアダプターにもなっているような気がする。

自分は比較的スタートアップの企業で働いていたから、限られた予算・時間内で、なにがサービスにマッチするかというのを、探してきて試みるという、イノベーターとアーリーアダプターの2つの役割を担っている人ばかりだった。

そういう人達を見ていたので、自分もその立場になれるよう頑張っている。

12. 外部のお墨付き

成功の匂いに敏感な人たち向けに、可能ならば成功事例を含めてみよう。その出版物が対象者から信頼されていることを確認しよう。経営者は技術雑誌ではなく、ビジネス雑誌を読む傾向があるという例からも、対象者に注意することは重要である。

これはなるほどと思った。

当然だけど非エンジニアの人とはコンテキストが合わないのは当然。

こちらが伝える側の場合は、こっちが合わせてあげないと伝えたいものも伝わらない。

その上で、対象者が信頼をおいている外部資料などから成功事例を集める。

その資料には細かい技術の話はおそらくないけど、そのかわり、サービスにおいてどんなインパクトがあるということをストレートに書いてくれていると思うので、説得材料として効果が高い。なるほどー。

13. グループのアイデンティティ

変化への活動に名前を与えると、変化の存在と、なにを実現しようとしているのか、気付かせる助けとなる。人々がその名前を見聞きする機会が増えれば、彼らの関心が増して、より深く関わるようになる。

名前をつけるという当たり前の行為なので、全然意識したことなかったけど、グループ以外の人達には大事なものだと理解できた。

なるほど。

14. 達人を味方に

達人には謙虚さをもって近づこう。あなたは彼らから学ぶために近づくのであって、イノベーションのニュアンスすべてを彼らに教えるわけではないのだ。彼らに新しいアイデアを叩きつけるのではなく、徐々にアイデアを提示できるようちょうど十分となるようにして、達人に意見を求めよう。

大きい会社ならばこういう達人っていると思うけど、小さい会社だと難しいよね。

でも例えばフリーランスとかで働いてくれる人たちとつながれば、小さい会社でもこういう場面は出てきそう。

その際の話し方で、ここでも言ってるけど謙虚な姿勢ってのがめっちゃ大事になると思っている。

この辺できてない人って多いと思う。今のチームにもいるけども。

謙虚さっていうのってチームワークの中でとても大事だと思う。

「あの人謙虚だよね」っていう印象は与えるとは思うけど、決して嫌な印象ではないはず。

15. 空間を演出する

このパターンは、人々が新しいアイデアに関する最新情報について目にしたり議論したりする場所をつくり出すものである。「その場所に」留まってもらい、考えていることを分かち合ってもらうのである。その場所を訪れた人は新しいアイデアを進める仲間に加わることに興味をもってくれる可能性がある。

目に見えている場所を用意するのが重要みたいだ。

結構Slackのチャンネルつくって適当に招待するみたいなので終わっちゃっているケースがある。

それだと確かにあんま長続きしないケースがあった。

16. イノベーター

しかしながら、あなたはイノベーターに長い間、頼ることはできないだろう。イノベーターは次から次へと新しいものに興味をもつので、違う方に興味が移ってしまうのである。さらには、イノベーターは新しいアイデアをすぐ受け入れてしまうので、他の人には疑念を抱かせることにもなる。したがって、一般的にはイノベータはよいオピニオンリーダーにはなれないのである。イノベーターからの協力は、短期の門番のようなものと考えよう。もしそれ以上の働きをしてくれたら、ラッキーだと思おう。

あんまり出会ったことないイノベーター。アーリーアダプターのところでも話したけど、自分が今まで出会った人は、イノベーターとアーリーアダプターを兼務している人たちが多かった。

人数が少ない会社あるあるなのかもしれないけど...w

本当はイノベーター思考だけど、限られたリソースで自分の興味のある新しいことを試すために、導入可能かどうかまで検討する必要があるから、結果アーリーアダプターもやっちゃっているって感じなのかな？

17. やってみる

多くの人が、やればできるはずなのに何もしようとしないのは、まだ知識が十分ではないと思い込んでいるからだ。しかし、新しいアイデアを実際に試してみるまでは、学びの機会は得られない。自分自身で研究しよう。経験不足はライバルたちの絶好の攻撃材料になるが、うまくいった経験があれば反論は難しくなる。さらに、新しいアイデアの限界がわかってくるにつれ、過信を避けることができ、アイデアを有効利用するためのより現実的なアプローチ方法が見えてくるだろう。

これはそのまんま。

最低限チームにハマるか、プロジェクトにハマるか的なところの予備調査は必要だけど、それがOKならば、実際まずやってみようってことだ。

一人でやってもいいし、もし協力者がいれば一緒にやってもいいし。

とにかく実践してみよう。

18. 感謝を伝える

仕事なんだからやって当然、と考えるのは簡単だ。だってお給料もらってるんだから！しかし、人が幸せを感じたり貢献できたと思えるのは、認められたり元気づけられたりしたときなのだ。協力してくれた人にお礼として提供できるものが何もなくても、感謝の気持ちを表すだけならコストもかからないうえに、相手にとっては大変意義深いものとなるのだ。

基本的なことだけど難しいことだと思う。

最近プログラムとかでなにかを教える状況が多いんだけど、なかなか伝わらなかったり、何回も同じミスしてる人をみてるうちに、例えばその人になにか簡単なバグ対応をやってもらったときも、感謝を伝えるって気持ちがでなくなる時がある。

でも最近は、育ってきた環境が違うから、みんなが俺とおんなじじゃない。

って考えるようになって、少しだけ頭と心が柔らかくなった(個人的にセロリ思考とよんでいる)

どんな状況でも謙虚さと感謝って大事。

19. 次のアクション

学んだことを実際に仕事に適用できるかどうかを考えると、参加者は疲弊し、圧倒され、不安に陥ることがある。イベントがうまくいけば、参加者の行動をさらに刺激できる。参加者たちが部屋を出て行くまでに、その興奮をうまく利用しよう。参加者たちが、望ましい未来の明確な見通しを得てやる気になっていたとしても、次に何をすべきかわからなければ、進歩はわずかしかないか、もしくはまったくない。

せっかく勉強とかやったとしても、単発で終わっちゃうと、もったいない。

継続は力なり。

宿題っていいシステムだと思う。

20. 個人的な接触

全員と話そうとして、あなた自身を疲弊させてはいけない。あなたは誰をも納得させられるだけの力も個性ももっていないと自覚するのだ。あなたの話を聞きたがらない人がいたら、橋渡し役を探そう。

個人的な接触は一番抜けてたなと思った。

結構自分のアイデアを広める際は、いきなりチームにMTGで伝えたりしちゃってた。

でもやっぱりメンバーそれぞれのやる気だったり、時間だったりがあるわけで、俺がどんだけやったほうがいいよ！っていっても、なかなか伝わらない。

やっぱり一人ひとりと話でどんな形ならみんなが参加できるかってのを話し合うべきだった。なるほど。

21. 便乗

組織に長い時間を経て受け入れられた既存の習慣があり、新しいアイデアを受け入れるために、それらが役に立つかもしれない。もし、あなたのアイデアを既存の慣習の追加機能(add-on)として提案できれば、まったく新規で既存と異なるアイデアを導入する場合に比べれば、一部のルールや手続きを迂回できるかもしれない。

面白い考え方だと思った。

アイデアの種類によるけど、確かに既存の社内 or チームのルールにすでに混ぜることも可能なものもある。

自分が導入したいと考えているアイデアがこのパターンを使えるかどうか、最初に考えるのがいいなと思った。

22. 種をまく

人は無料のネタは手に取るものだが、ごく一部の人だけがそれらを読んだり新しいアイデアに興味を持ったりするものだ。しかし、その影響力というものを過小評価してはいけない。「種」はごくまれにしか興味をかきたてないものだが、それが主要人物、たとえばコネクター、アーリーアダプター、あるいは達人を味方にといった、あなたの代弁者となるような人たちに届くかもしれないのだ。

目立つところに自分のアイデアの資料なり何なりを置いておこうってことらしい。

あまり効果がないかもしれないけど、効果が得られた人がたまたま影響力のある人であれば、その効果は跳ね上がるってことだ。

これも同じで、とにかくやってみるってことだな。

23. 適切な時間

人はみな忙しい。しかし、比較的忙しくない時期もあるのだ。新しいアイデアに興奮していると、即座にみんなに話したがるものだ。しかし、現実に戻り、熱意を覚ますべきだ。よくないタイミングであなたの情報が飛び交うと、説得したい相手の人々を苛立たせて、あなたの目標への改宗者を失ってしまう危険性がある。

結構これも失敗しがち。聞いて聞いて状態になっちゃってすぐ話しかけちゃう。

でもそれってよくないよね。

相手も相手のペースがあるから。

自分の話をしたいならば、まずはタイミングを計らねば。

24. 定期的な連絡

人々がイノベーションを採用することを決めたとしても、その気が変わらない保証はない。人は常に自分の行った決定を補強できるような情報を求めている。常に新しい疑問を抱えている。もし答えを得られなければ、古いやり方に戻ってしまうかもしれない。

これも結構忘れてると思った。

一回チームでやろう！となったことは、常にみんな同じ水準のモチベーションだと錯覚してしまって、共有を怠ってしまっている。

これはぜひ改善したいなと思った。

25. 勉強会

勉強会における発見プロセスはすべてのタイプの学びに適しているわけではない。プログラム言語のような技術的なトピックは、学習者が問題に引っかかったときは熟練者の出席が必要かもしれない。さらにこのような探索的な手法が、すべての人に有効とは限らない。とくに、他人とのやりとりがあっても盛り上がらない人や貢献する人ではなく「スポンジ」である場合は役に立たないかもしれない。勉強会は学び方の一つにすぎない。組織における教えと学びの戦略全体の一部と考えるべきだ。

わかり味ある。

まさに例で挙げられているプログラム言語の勉強会ってよくあるけど、必ず効果的と思ったらだめだなと思った。

勉強会の参加自体にストレスを感じてる人もいるし、それはメンバーそれぞれ。

ここはやっぱり、個人的な接触で、どんな形の参加ならばストレスでないかなど、聞き出す必要がありそう。

26. テイラーメイド

人々の認識のフィルターを通り抜けるようなやり方で売り込めなければ、いかなる最高のアイデアでもインパクトを与えられない。そこでよくあるアドバイスは、「技術を売るな、仕事上の解決を売りなさい」だ。

テイラーメイドってなにと思って調べたら個別対応ってことらしい。

個人的接触で話す時に、その人達ごとに売り込み方を変えろってことかな？

ちなみにオーダーメイドと何が違うんだろうと思ったら、意味はおんなじで、オーダーメイドは和製英語らしい。

なるほど。

27. 著名人を招く

あなたのプレゼンテーションには忙しくて出られないという人でも、その分野におけるエキスパートから話を聴くためなら時間を割くかもしれない。信頼性のある講演者なら、人は講演者のいうことに感化されるものだ。

これってよくいう、何をいうかじゃなくて誰がいうかっていうことかな？

自分が言っても暖簾に腕押しな感じだけど、別の人が言うと効果テキメンっていうことってよくある。

これと一緒かな。ただ外部の人でかつ、著名人ってのが違うか。

なるほど。

28. 経営層の支持者

組織のあちこちから尊敬を受けている人物を探すこと。さもなければ、やっかいごとに巻き込まれてケチがつくことになりかねない。間違った種類の重役のサポートは、新しいアイデアが組織内で「ごり押し」されているといった印象を与える可能性がある。個人的な興味から新しいアイデアに乗ってくるような人物には注意すること。その役割が別の職務や組織に移ったら、その指導力も消えてしまうだろうから。

上層部を味方につければ勝ったも同然みたいなことを考えていた自分はこれを読んで、自分は考えが足りてなかったなと思った。

確かにここもやり方は注意しないといけない。失敗すると、確かにゴリ押しされているからやらざるを得ないみたいな印象を他の人に与えてしまう。

これは意識しよう。

29. 正式な推進担当者

新しいアイデアの成功はあなただけのものではないことをはっきり理解すること。多くの場合、成功への熱意の中にある正式な推進担当者は、他の人たちの役割を促進したり確保するよりも、自分で何でもやってしまいがちだ。みんなを巻き込む、協力を求めるを使いなさい。どれだけ他の人々の作業を促進したかで成功を図ろう。

おなじ熱量の人が近くにいれば、一緒にやろうっていうようになるけど、そうじゃない人たちの場合は、自分は一人でやっちゃっている。この辺も改善事項ってことだな。

みんなを巻き込むことをできてないってことだ。

30. アーリーマジョリティ

イノベーターとは違い、アーリーマジョリティは新しいアイデアのゲートキーパーをの役割を担うにはアイデアの採用が遅すぎる。アーリーアダプターとは違い、彼らはフォロワーであり、通常、組織のオピニオンリーダーのポジションには立ってない。だが彼らは、早期採用者と比較的後になって採用する人々とのあいだのつなぎ目となってくれる。このつなぎ目は、アーリーアダプターとアーリーマジョリティの間のギャップもしくは「キャズム」を越える橋となる。新しいアイデアを主流にするためには、キャズムを超えなければならない。

この本の前半で書いていたけど、イノベーターとアーリーアダプターの人数を足しても全体でいうと超少数派なので、全体の3分の１の数に相当するアーリーマジョリティを仲間に入れることができて、やっと定着への一歩を踏み出せるといった感じだった。

個人的にアーリーマジョリティの立ち位置ってそれこそ経営層に多そうなイメージ。

ちがうかな？

ちなみにキャズムって何？と思って調べると溝、裂け目という意味だった。

31. 達人のレビュー

通常、経営層と開発者は近くにいる達人の判断を信じる。特に彼らが長期にわたって関わりをもっている場合はなおさらである。達人は最近の流行に通じているので、専門家や頼れる知識源とみなされることがある。この信頼の認識によって、彼は経営層を含む多くの聴衆に影響を与えることができる。

達人を味方にや、著名人を招くに近いのかな？

ここもやはり、何をいうかじゃなくて誰がいうかっていう感じだと思う。

32. 体験談の共有

このパターンは体験共有のためのイベントを作り出す。多くの人は成功例に刺激を受けるので、そのようなイベントによって新しいアイデアの魅力が高まることであろう。だが間違った人を選んでしまうと、あなたの目的を損なう危険がある。たとえば、ダラダラと喋り続ける発表者のせいで、他の人が話せなくなることがある。人気があり、尊敬されている人に話してもらおう。もし不適切な人がどうしても発表したいというのなら、より感じのいい発表者の発表と組み合わせておけば、その影響を緩和することができる。

体験談の共有会って確かにやってないかも。

○○やろうぜ！よしやろう！ってなって、ルール化できても結局そのまま野放しになってしまってることがある。

こういう地道なのって大事なんだな。

次やるときはこれもやってみよう。

簡単な振り返りを共有するだけでもいいんだし。

33. みんなを巻き込む

あなたが多くのことをやりすぎることによって、失敗に向かってしまうことがあるのだ。新しいアイデアをあなた自身に関することと捉えられてしまうことがあるので、他者の考えがあなたの人格や歴史によって色付けされてしまうのである。どうすればイノベーションがもっともうまくいくか議論する人は、あなたの意見に従おうとするだろう。まるで「正しい道」を学ぶ学生のように。

なるほど。

自分は結構人見知りで、自分である程度まで頑張って、そのあと信用できる人に話を持っていく癖があるけど、ある程度っていうのがどのレベルかで、参加してくれる人たちの指針となってしまうっていうのは問題だと思った。

それが100%成功の道と誤認されてしまう危険性があるってことか。

気をつけないとだめだ。

34. ちょうど十分

新しいアイデアを紹介するためにプレゼンテーションを行う場合、より高度なコンセプトに関する追加情報を1〜2枚のスライドにまとめよう。日常会話の中で、周囲の人たちが新しいアイデアを快く扱えるような情報を提供し、まだまだ学ぶことがあると伝えよう。周囲の人がそれぞれ、新しいアイデアに興味をもって自ら調べたくなるような情報を与えよう。 管理部門の上層部を相手にプレゼンテーションをする際は、まず最初に結論を示すこと。総括的な展望を描いて見せ、質問されたら詳細について説明しよう。損失よりも収益を強調すること。誇張することなく、リスクを無視せず、新しいアイデアの導入によってよい結果が導かれることを主張するのだ。

経営層とそれ以外でプレゼン方法を切り分ける必要があるのか。

まぁ確かに、考え方が違う人達だから当然か。

35. 身近な支援者

間違ったスポンサーを巻き込んでしまうと、あなたは焦点と方向性を見失ってしまうかもしれない。新たなマネジメントを招き入れることは、同時に、あなたの考える方向性とは別の方向に押し出されてしまうリスクも伴う。あなたのアイデアを盗み、自分の実績にしてしまう独善的なマネージャーもいるかもしれない。マネージャーが熱心すぎると、新しいアイデアが強制されているような悪い印象を与えるかもしれない。あなたの真面目な思いを傷つけるのではなく、支援してくれる人望の厚いスポンサーを探そう。

マネージャーを味方にしようって話。

印象に残ったのは、上記の注意文。

明らかに危ない雰囲気の人っていうのは、わかるけど、あまり話したことない人の場合、一回ぶつけてみちゃうような気がする。

そして蓋開けると、上記のような結果になってしまうと。

そういう結果にならないよう、選別と言ったら聞こえが悪いけど、日々のコミュニケーションがとても大事だと思った。

36. 場所重要

仕事の現場ではない外部の施設を利用するには、必然的にコストがかさむ。それでも外部の施設を利用しようとするならば、きちんとやらなければならない。

1日かけてやるようなものは、職場でやらずに、別の場所で割り込みが入らないようにやろうっていうことのようだ。

よくあるプログラミング合宿とかは、まさにこのパターンに当てはまってるんだろう。

37. メンター

メンターとチームメンバーが一緒にトレーニングし、経験を共有するという効果がある。チームメンバーが新しいアイデアについて効果的にコミュニケーションが取れるようにするだけでなく、チームビルディングの練習にもなるのだ。

新卒の子について教えた経験って何回かあるけど、教ぼえてもらうという事に注力してて、自分の教えるスキルを伸ばすなんていうのは考えたこともなかった。

教える立場も一緒に成長しなければ。

せっかくそういった立場にさせてもらったのだから。

38. 謁見

チーム、個人あるいは管理者によって有意義なものとなるよう招待者を利用しよう。それにはプレゼンテーションする時間帯の前後、日中や夜間のあまりの時間や食事の時間を使うのだ。

著名人を招くパターンで外部の方を招待した際に合わせ技で使用できるパターンって感じだと思う。

この方の発言力を利用させてもらい、経営層の支持者を獲得するということのようだ。

まず最初の段階で結構ハードル高そうだけど、、、

39. 相談できる同志

コミュニティというものは、同じ目的をもった人が集い、一緒くたになって話し始めた時に動き出すものだ。このコミュニティは、落ち込んでいるときの後押しや、有用な議論や、戦略の情報源を提供してくれる。

しかし、気をつけないと、集いが泣き言をいうだけの劣化したものになってしまう。これでは、人をネガティブ思考に溺れさせるだけでなく、彼らに対して申し訳ない気持ちになってしまうだろう。誰かの不満が妥当なものであっても、人が引き起こした問題への解決策に焦点を当てよう。一度負担から開放される機会を得ると、人は前進するための大いなる知性を使えるようになるのだ。

結構バッドパターンに当てはまっちゃうことってありそう。 愚痴をいうだけの会みたいな。

もう一歩踏み込んで、それの解決策ってなんだろうね。っていうのを話し合うようにしないとな。

40. 成功の匂い

あなたの取組みがなんらかの目に見える結果を残した時、あなたと話したがる人がぞろぞろと現れるだろう。その機会を活かして教育に力を入れよう。

自分が考えているアイデアは社内全体に対しての話ではなく、あくまでエンジニア内での話だけども、それでも複数チームに分かれているような場合、片一方のチームに新シアイデアを導入して、上手く行っているような雰囲気があると、もう片方にも導入しやすくなるし、むしろもう片方が進んで導入を検討してくれると思う。

これが成功の匂いっていうやつだと思う。

結果を出さないとだけども。

41. 勢いの持続

変化への取組みをしているあいだは、自分自身を奮い立たせ続けなければならない。「静止している物体は、外部から力を加えられるまで静止状態のままである」というニュートンの第三法則は必ずしも真実ではない。新しいアイデアを使い続けなければならない。止めてしまってはいけない。一旦勢いを失ってしまうと、再び勢いを取り戻すことはとても難しい。

これはめっちゃわかる。

あれやってみようこれやってみようといろいろ提案して実際始まったけど、みんなで進めないといけないものなのに、集まりが悪かったり、そもそも仕事が忙しくて開催できなかったりというのが続いて、結局なくなってしまったイベントなども社内であったりした。

でもそれは、集まりが悪い人達が悪いわけではなく(一部悪いかもしれないが・・・)、その興奮をみんなに持たせ続けるために、自分が動かないと駄目だった。

また新たに始めるのは確かに大変だけど、形を変えて始めてみたいと思う。

42. トークン

私達の脳が記憶できる量には限りがあり、今日の情報は明日の情報ですぐに置き換えられてしまう。人には思い出させるものが必要なのだ。特定の話題に関連付けられた物体は人の記憶を刺激する。今は他のことに気持ちが移っていても、そのアイデアのことを思い起こさせる手がかりになるし、ずっと時間が立ってしまった後でも有効だ。

例としてあげられているのは、マグネットとかボタンとかだそうだ。

ステッカーとかもそうなのかな？

重要なのは暗黙的なリマインダーの役割になればいいということなので、そのトークンがなにであるかはこだわらないか。

43. 橋渡し役

最後までぐずぐずしているのろまたちはたいていの場合、同僚の殆どもしくは全員が賛同して初めて、イノベーションを受け入れるものだ。プレッシャーに負けてそうしただけだとしてもだ。だから、いずれ彼らが折れるのだとしたら、のろまたちにプレッシャーをかけようと骨を折るよりもただ待っているだけのほうが無駄がなくてよいだろう。

懐疑派との説得の橋渡し役を選ぼうという話で出た↑の文。

全員を気持ちよく説得するというのは考えなくていいということw

44. 懐疑派代表

懐疑派代表がくれる情報を活用しよう。

あなたが考えていなかったことに気づけたなら、感謝を伝える。あなたが深刻な間違いを起こす前に修正するチャンスかも知れない。しかし、懐疑派代表が提案する極端な案に乗ってはいけない。ある程度の反対なら問題ないが、あからさまに敵対している強硬な人は避けよう。

反対意見を持つ人を、反対意見をもたせたまま、こちら側に取り組むイメージかな？

すごく面白いアプローチだと思った。

45. 根回し

あなたが会話した人たちがこの先なにか見返りを求めてくる危険はある。また、ミーティング前の個別の対話は、裏取引のように捉えられることもありえる。あなたはできる限り公明正大でありたいと思っていることだろう。全くの自分勝手な理由でこのパターンを使うと、火傷するだろう。そのコミュニティにとって最良の道を考える時、このパターンはもっとも力を発揮する。

個人的な接触と違いがわからなかったんだけど、決議の前に実行するところが違うのか。

ただ、引用したところであるとおり、使い方は気をつけないと行けないパターンだと思う。

46. 恐れは無用

抵抗勢力が全くいない状況を想像すると、ぞっとする。あなた一人で常に100%の正しさを保証しなければならない。これはおそろしいことではないだろうか。完璧な人などいない。抵抗勢力にアイデアを評価してもらう必要がある。だから反対意見に対する最初のステップは、それに感謝することである。幸運なことに、このやり方はあらゆる状況で有効だ。したがって、抵抗勢力の存在を感じたときは、密かに悩むのではなく、まず表に出してみよう。

この文章を見てなんの反対意見もない状況がおそろしいと感じた。

反対意見に対して感謝することっていうのは、すごく難しいけど、自分一人がこのアイデアを考えいるわけではないという、安心できる状況を作ってくれたということに関して、確かに感謝すべきだ。

47. お試し期間

実際に目で見て、触れることによって確信してもらう方が、言葉や理論で理解してもらおうとするよりも効果的だ。アイデアが確立された手法の一部としての説得力をもつまでのしばらくの間は、「受け入れ不可」のアイデアを一時的に「受け入れ可能」にもっていくために、「試験目的」という便利なラベルを使おう。

これは確かによく使う手だ。

「とりあえず1ヶ月間ミニマムで運用してみませんか？」

みたいなことってすごく言いやすい。

本当にチームにマッチしたアイデアだったら一ヶ月間やれば、良さは伝わる。

最小構成でお試しでやるっていうのはすごくいい手だと思う。

終わりに

長かった。

この本を読むために1週間ブログ書けなかったです。。。

いろいろと参考になる物が多かったです。

実は今お仕事を頂いている会社で、自分がやりたいと言って、社内勉強会開催や社内記事を書くことなどを今のチームで導入したりしたのですが、他のメンバーから不満があがり、結局やらなくなってしまいました。

これは本人たちのやる気の問題というのもあるかもしれませんが、これを読んで、そもそも自分の導入方法・進め方に問題があった可能性があるなと思いました。

この本をもう一度読んで、再度導入できるようにしていきたいと思いました。

再導入がうまくいけば、またブログにまとめようかなと思います。

次も積本消化します。

終わり。