IDEA Note

  • 現在のアプローチの先に「自分が求める結果」が無い事を知った

    現在のアプローチの先に「自分が求める結果」が無い事を知った

    はじめに

    マネジメントの仕事をさせて頂くようになってから、考えるべきこと、主にマネジメントに伴う悩みが自分の悩みの大半を締めるようになった。

    上司や親しい人には悩みは打ち明けていたものの、第三者のコーチングというものを受けた事がなかった。そもそもコーチングがよく分かってなかった。

    そんな中、職場の先輩から安西さんのコーチングを紹介してもらった。

    前途したように、自分はコーチングを受けた事がない。

    そのため、どこまでが世の中で言う「コーチング」で、どこからが安西さんにしていただいた「コーチング」なのかわからない。

    今回していただいた事をまとめたいと思う。

    安西さんのコーチングを受ける前にしたこと

    安西さんのコーチングは、カフェでしていただくこともできれば、オンラインでコーチングをすることも可能とのこと。

    自分はオンラインを選んだ。

    メールでアンケートを送ってもらい、そのアンケートを埋める。事前にアンケートに回答する形で、コーチングに必要な”人となり”の理解に繋げているようだ。

    • 今回お話しすることで期待すること。
    • 気になっていること
    • 自分自身、どうありたいのか。
    • 自分の特性(性格など)

    これを書いているうちに一つの大きなことに気づいた。

    初対面の人に悩みを打ち明けるのは初めてのことなので、

    限られた時間の中で初対面の方に対し自分の経歴を伝え、現在の役割、そして本題の悩みを共有させていただくことになるが、せっかく無料で1時間も取っていただくため、無駄がないようにするには、自分自身整理する必要があった。

    そこで気が付いたのが、現在の悩みに到るまで、なぜそう思ったのか、どのような経緯でこの悩みに至ったのか一気通貫で言語化した事がない。

    自分の悩みを口頭で上司や親しい人に悩みを伝える事はあっても、自分の経歴などバックグラウンドは共有されているので、必要なところだけを伝えているが、どうしても省いてしまうところが、初対面の人相手では省略をすることなどできない。
    今回は事前準備として与えられたアンケートへの記入を通してまとめる事ができた。
    コーチングの初期段階として、その過程が非常に良く、自分自身の悩みを言語化する事ができた。

    コーチングを進めていて得られた気づき

    お話しを進めている中で、安西さんは所々「問い」をくれる。

    「どうなっているのが理想ですか?」

    「それを実現する為に、どのような事をしていますか?」

    一つ一つ答えていく。そしてたどり着いた。

     

    「”自分が求めていた結果”を達成するには、”自分が行っているアプローチ”の先に無い。」

     

    自分には”こうなって欲しい”という理想があって、その上で試行錯誤しながら様々なトライ&エラーを繰り返してきた。しかし、アプローチが違ったことに気付けた。

    これは自分ではなかなか気付けなかった点だった。いかに自分の話を聞いてくれて、時折、第三者的な「問い」を投げかけてくれる事がいかに大切かを学んだ。

    そして、別のアプローチを一緒に考え、具体的なアクションプランまでセッションの中で一緒に考えてくれた。

    そこでも「来週からできそうですか?」など精度を高める質問をしてくれ、アクションプランの質を高める事ができた。

    紹介していただいた事

    優れたリーダーはどのように行動を促すのかという点で、ゴールデンサークル理論というものがあるというものを教えてもらった。

    • Why なぜ
    • How どうやって
    • What 何を

    の順番で話したらどうだろうと提案していただいた。

    コーチングの後に調べたが、以下の記事は非常にわかりやすかった。

    https://swingroot.com/golden-circle-theory/

    それに伴い、Whyを突き詰めて書かれている本も紹介。

    • カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
    • スクラム 仕事が4倍速くなる“世界標準”のチーム戦術

    この本は土日の課題図書として読もうと思う。

    これからどうするか

    コーチングは1時間を予定していたが、結果1時間半もかけてもらった。
    無料でここまでしていただいて本当にありがたい。ありがたいし申し訳ない気持ちもある。

    安西さんはコミュニティを作りたいという想いが源泉でこのような活動をされているそうだ。

    今回コーチングをしていただいて、自分では見えてないところが見えるようになった。愚直に受け止め、真摯に改善していき、「自分が求める結果」の実現により近づけたらと思っている。

    そしてこれからも挑戦し、いつか安西さんへ嬉しい報告ができればと思っている。

    本当に得難い経験だった。安西さん、ありがとうございました!

  • パフォーマンス・マネジメント -問題解決のための行動分析学- を読んだ

    パフォーマンス・マネジメント -問題解決のための行動分析学- を読んだ

    はじめに

    自分以外の人のモチベーションを維持・向上させ、マネジメントをしていく上で必要な本を探していた、先輩から紹介されたので即購入した。

    多くの物事は複雑に絡み合っている事が多いが、パフォーマンス・マネジメントを読んだ後は比較的シンプルに切り分ける癖がついた。

    今回はパフォーマンス・マネジメントについてまとめる。

    現状の確認

    仕事や人間関係がうまくいかない時には、他人や自分を責めるのではなく、問題を解決する方法を考える。

    仕事や人間関係がうまくいかない時、その原因を他人や自分の性格や能力、やる気や適性のせいにしてアクションを取らないことを、個人攻撃の罠と捉えている。

    個人攻撃に入った人は近づきづらく、負のスパイラルに陥る。

    個人攻撃に陥らない為には、一切の感情が入らないらないよう、チェックリストを予め作成し、それに基づいて「できているところ」、「できないところ」を整理する。

    強化の原理

    個人やチームが強くなる原理

    行動する事で、何か良い事が起こったり、悪い事がなくなったりすると、その行動は繰り返される。

    強化の原理が働くときは、

    〜〜の時〜〜したら〜〜になった

    という関係が成立している、

    〜〜の時  Antecedent:先行刺激
    〜〜したら … Behavior:行動
    〜〜になった … Consequence:結果

    と捉え、このことを行動随伴性(こうどうずいはんせい)と呼び、その頭文字からABC分析などと呼ばれる。

    これはちゃんとした医療用語で、心理カウンセラーがメンタルヘルスの一環で使う言葉のようだ。参考情報 http://www.counselorweb.jp/article/441261060.html

     

    改善点はその3つに分ける事ができる。

    Antecedent:先行刺激の改善

    例えば、他の人へ与えたタスクが、期待しているものと違っていた場合、

    その人が動く上での前提条件、Antecedent:先行刺激が足りない可能性がある。

    この際、「では自分が悪かったのか」と個人攻撃の罠にハマる危険もある。おそらくそれがひどければ鬱を誘発する。

    そのため、悪いところを探すのではなく、何か役に立つところを積極的に見つける。

     

    Behavior:行動

    作業者の「引き出し」が少なく、問題解決する上での数ある選択肢の中で、不適切な選択をするのであれば、この項目を改善するように考える。

    この点を改善するには、「引き出し」を増やすようトレーニングをする必要がある。

    Consequence:結果

    やる気の無さが直結する事が多い。

     

    行動を強化する、”何か良い事”を「好子(こうし)」と呼ぶ。これを一種のご褒美として使い、チームの強化などに使う。

    弱化の原理

    行動する事で、何か悪い事が起こったり、よくない事がなくなったりすると、その行動は繰り返されなくなる。.

    一方でチームが”悪くなる要素”を「嫌子(けんし)」と呼ぶ。これは望ましい行動を伸ばすという点からは欠点が多い。人間関係にも悪影響を与える可能性もある。

     

     

  • dockerをECSで動かした時のdebug方法について

    dockerをECSで動かした時のdebug方法について

    はじめに

    dockerコンテナを動かしていると、何らかの原因で起動シェルが止まってしまうことがある。今回はその調査方法の一つ、ECS用にAWSからオフィシャルのログ収集ツール ECSログコレクター が提供されているので、今回はそれを紹介。

    インストール方法

    AWS公式サイトにある通り、ツールを取得する

    $ curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh

    その後、sudoをつけてシェルを実行する

    $ sudo bash ./ecs-logs-collector.sh

    しばらくすると、諸々ログが取れる

    $ sudo bash ./ecs-logs-collector.sh
    Trying to check if the script is running as root ... ok
    Trying to resolve instance-id ... ok
    Trying to collect system information ... ok
    Trying to check disk space usage ... ok
    Trying to collect common operating system logs ... ok
    Trying to collect kernel logs ... ok
    Trying to get mount points and volume information ... ok
    Trying to check SELinux status ... ok
    Trying to get iptables list ... ok
    Trying to detect installed packages ... ok
    Trying to detect active system services list ... ok
    Trying to gather Docker daemon information ... ok
    Trying to inspect all Docker containers ... ok
    Trying to collect Docker daemon logs ... ok
    Trying to collect Amazon ECS Container Agent logs ... ok
    Trying to collect Amazon ECS Container Agent state and config ... ok
    Trying to collect Amazon ECS Container Agent engine data ... ok
    Trying to archive gathered log information ... ok

    無事完了すると、correctというディレクトリが作られ、ログが集約される。

    $ ls -ltr
    合計 236
    -rw-rw-r-- 1 ec2-user ec2-user  14181  7月 19 14:25 ecs-logs-collector.sh
    drwxr-xr-x 3 root     root       4096  7月 19 14:25 collect
    -rw-r--r-- 1 root     root     219653  7月 19 14:26 collect-i-0051ca9951de8e82a.tgz

    dockerの状態を確認するには、correct、インスタンスid、配下のdockerディレクトリにログとして出力される。

    /collect/i-xxxxxxxxx/docker

    ざっと見てみると、

    [
        {
            "Id": "xxxxxxx",
            "Created": "2019-07-19T12:36:48.665852002Z",
            "Path": "sh",
            "Args": [
                "/root/bin/execute.sh"
            ],
            "State": {
                "Status": "exited",
                "Running": false,
                "Paused": false,
                "Restarting": false,
                "OOMKilled": true,
                "Dead": false,
                "Pid": 0,
                "ExitCode": 137,
                "Error": "",
                "StartedAt": "2019-07-19T12:36:49.47823385Z",
                "FinishedAt": "2019-07-19T13:12:07.097787961Z"
            },

    終了したときの状態がわかる。

    OOMKilledがtrueになっており、このコンテナはメモリを使い果たし、OOMKillerが発動、コンテナがkillされたのではと推測が立つ。

    linuxのimageをbaseに使っていると、当然メモリーを使い切った際にはOOM killerなどは発生する。その際の原因調査をする上では、サーバレスのfargateよりは、まだホストにログインできるECSの方が原因調査はやりやすい。

    それ以外にも非常に細かい状態を確認することができる。

                "DnsOptions": null,
                "DnsSearch": null,
                "ExtraHosts": null,
                "GroupAdd": null,
                "IpcMode": "shareable",
                "Cgroup": "",
                "Links": null,
                "OomScoreAdj": 0,
                "PidMode": "",
                "Privileged": false,
                "PublishAllPorts": false,
                "ReadonlyRootfs": false,
                "SecurityOpt": null,
                "UTSMode": "",
                "UsernsMode": "",
                "ShmSize": 67108864,
                "Runtime": "runc",
                "ConsoleSize": [
                    0,
                    0
                ],
                "Isolation": "",
                "CpuShares": 2,
                "Memory": 2147483648,
                "NanoCpus": 0,
                "CgroupParent": "/ecs/ad627055-dc5b-4903-96ed-be9e0f25cf33",
                "BlkioWeight": 0,
                "BlkioWeightDevice": null,
                "BlkioDeviceReadBps": null,
                "BlkioDeviceWriteBps": null,
                "BlkioDeviceReadIOps": null,
                "BlkioDeviceWriteIOps": null,
                "CpuPeriod": 0,
                "CpuQuota": 0,
                "CpuRealtimePeriod": 0,
                "CpuRealtimeRuntime": 0,
                "CpusetCpus": "",
                "CpusetMems": "",
                "Devices": null,
                "DeviceCgroupRules": null,
                "DiskQuota": 0,
                "KernelMemory": 0,
                "MemoryReservation": 1073741824,
                "MemorySwap": 4294967296,
                "MemorySwappiness": null,
                "OomKillDisable": false,
                "PidsLimit": 0,
                "Ulimits": [
                    {
                        "Name": "cpu",
                        "Hard": 0,
                        "Soft": 0
                    },
                    {
                        "Name": "nofile",
                        "Hard": 4096,
                        "Soft": 1024
                    }
                ],
                "CpuCount": 0,
                "CpuPercent": 0,
                "IOMaximumIOps": 0,
                "IOMaximumBandwidth": 0,
                "MaskedPaths": [
                    "/proc/acpi",
                    "/proc/kcore",
                    "/proc/keys",
                    "/proc/latency_stats",
                    "/proc/timer_list",
                    "/proc/timer_stats",
                    "/proc/sched_debug",
                    "/proc/scsi",
                    "/sys/firmware"
                ],

    詳細はこちら。

    https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-logs-collector.html

    では、今日はこの辺で。

     

     

  • 作業ブランチを別リポジトリのブランチへ引っ越し

    作業ブランチを別リポジトリのブランチへ引っ越し

    はじめに

    アプリケーションを作っていると、当初作ろうとしていたものと、今作っているものが徐々にズレてくることがある。

    その時に考えることの一つが、「リポジトリどうしよう」ってやつだ。

    新しいリポジトリとはいえ、いきなりmasterにpushするのもなんだか忍びない。

    今回はリポジトリのブランチを別のリポジトリのブランチとしてコピーする方法を紹介。

    やりたいこと

    いたって簡単。

    これだ。これをやりたいのだ。

    コマンド

    # 新しいリポジトリをclone
    git clone git@git.sumito.com:hoge/AFTER-REPO.git
    cd AFTER-REPO
    git checkout -b AFTER-BRANCH
    
    # remote登録
    git remote add tmpbranch git@git.sumito.com:hoge/BEFORE-REPO.git
    git pull tmpbranch AFTER-BRANCH --allow-unrelated-histories
    
    # 新BRANCHへpush
    git add .
    git commit -m 'copy'
    git remote rm tmpbranch
    git push origin AFTER-BRANCH

    あとはpushした先で期待通りになっているか確認するだけでよい。

     

  • Error getting valid credentials (AKID ): NoCredentialProviders: no valid providers in chain. Deprecated.

    Error getting valid credentials (AKID ): NoCredentialProviders: no valid providers in chain. Deprecated.

    はじめに

    ECSでコンテナを動かそうとすると、作成されるEC2でdocker logsに

    2019-07-08T12:17:52Z [INFO] Event stream ContainerChange start listening...
    2019-07-08T12:17:52Z [WARN] Error getting valid credentials (AKID ): NoCredentialProviders: no valid providers in chain. Deprecated.
    	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
    2019-07-08T12:17:52Z [INFO] Registering Instance with ECS
    2019-07-08T12:17:52Z [INFO] Remaining mem: 3885
    2019-07-08T12:17:52Z [ERROR] Unable to register as a container instance with ECS: NoCredentialProviders: no valid providers in chain. Deprecated.
    	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
    2019-07-08T12:17:52Z [ERROR] Error registering: NoCredentialProviders: no valid providers in chain. Deprecated.
    	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

    というエラーが記述された。その原因と対策を明記する。

    原因

    ecsを実行するEC2インスタンスのroleに適切な権限がない。

    roleに以下の通り権限を付与する

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "ecs:CreateCluster",
                    "ecs:DeregisterContainerInstance",
                    "ecs:DiscoverPollEndpoint",
                    "ecs:Poll",
                    "ecs:RegisterContainerInstance",
                    "ecs:StartTelemetrySession",
                    "ecs:UpdateContainerInstancesState",
                    "ecs:Submit*",
                    "ecr:GetAuthorizationToken",
                    "ecr:BatchCheckLayerAvailability",
                    "ecr:GetDownloadUrlForLayer",
                    "ecr:BatchGetImage",
                    "logs:CreateLogStream",
                    "logs:PutLogEvents"
                ],
                "Resource": "*"
            }
        ]
    }

     

    もしEC2へattachするroleを変更したい場合は、ECSの画面からではなく、CloudFormationの画面から変更を行う。

    これは、ECSのサービス作成時、裏でCloudFormationが実行されるため。

    具体的な手順はクラメソさんのBlogが非常にわかりやすい。

    https://dev.classmethod.jp/cloud/aws/ecs-change-instance-type/

    変更点は以下の箇所

     

    有効化するには現在起動しているEC2インスタンスをterminateすること。

    オートスケールの設定がされているので、自動で新しい設定のインスタンスが立ち上がる。

     

     

     

     

     

     

  • go言語で自分のlocalIPを取得する

    go言語で自分のlocalIPを取得する

    はじめに

    dockerコンテナでgoのプログラムを動かしていると、コンテナのIPをどのように取得すればよいか困ったのでその対処を紹介。

    コード

    package main
    
    import (
    	"fmt"
    	"net"
    )
    
    func main() {
    
    	netInterfaceAddresses, _ := net.InterfaceAddrs()
    
    	for _, netInterfaceAddress := range netInterfaceAddresses {
    
    		networkIp, ok := netInterfaceAddress.(*net.IPNet)
    
    		if ok && !networkIp.IP.IsLoopback() && networkIp.IP.To4() != nil {
    
    			ip := networkIp.IP.String()
    
    			fmt.Println("Resolved Host IP: " + ip)
    
    		}
    	}
    }

    解説

    至ってシンプル。 “` net.InterfaceAddrs() “` でIPを取得することが可能だ。

    127.0.0.1 で表現できない時など、テストコードなどで活躍しそう。

  • You must specify a region. You can also configure your region by running “aws configure”.

    You must specify a region. You can also configure your region by running “aws configure”.

    はじめに

    ECSでタスクロールを指定しているのに、ECSで動かしたコンテナ内でawsコマンドを使うと、aws configureをしてくれとエラーが出る際の対処。

    You must specify a region. 
    You can also configure your region by running "aws configure".

    原因

    エラーメッセージの通りregionが指定されていないから。

    コンテナに以下の設定を入れるよう、Dockerfileを修正する。

    [default]
    region=ap-northeast-1
    output=json

     

     

     

  • 【Docker】ストレージ容量不足時の対処法【解決済み】

    【Docker】ストレージ容量不足時の対処法【解決済み】

    はじめに

    Dockerのビルドサーバーでストレージ不足が発生しました。
    不要なファイルを削除する必要があるため、安全に容量を確保する方法を紹介します。
    dockerで/var/lib/docker/overlay2 が肥大化した時の対処になります。

    まず対応すべきこと

    現状把握

    Dockerがディスク容量を圧迫している原因を確認するため、以下のコマンドを使用します。

    docker system df このコマンドで、Dockerに関連するディスク使用状況を確認できます。

    TYPE TOTAL ACTIVE SIZE RECLAIMABLE
    Images 9 1 2.014GB 1.962GB (97%)
    Containers 2 0 0B 0B
    Local Volumes 4 2 824.6MB 781.2MB (94%)
    Build Cache 0 0 0B 0B
    対処

    使用されていないコンテナ、ボリューム、ネットワーク、イメージを削除するには、以下のコマンドを使用します。

    docker system prune

    ただし、使用されていないボリュームとイメージを削除するには、以下のオプションが必要です。
    docker system prune --volumes --all

    volumesの削除

    上記コマンドで、不要なvolumesを削除しました。この操作で、355.4MBの容量を確保できます。ただし、storageの削除には、–volumesオプションを追加する必要があります。

    53d15cd6b78ad0f21788a22e9ce16a7295c4bab97609973
    deleted: sha256:7ae9338aed73a0f33568db53740431038d3a1f779c4dae40d27433984e1cd97c
    deleted: sha256:b1be54c8cadff1e50b87b93559320a1ae57b8d0dd326507148f7ca81d707beed
    deleted: sha256:86d78f10b9718618eaae056f5dfa1edae518949aee4578e4147268e9db2e75f0

    Total reclaimed space: 355.4MB
    ただし、storageの削除には、 --volumes オプションを追加する必要があります。

    imagesの削除

    docker system prune --all

    作業後

    上記の操作を完了した後、Dockerのディスク使用状況を再度確認すると、すべてのカテゴリーで容量が0になります。

  • ワンライナーでサイトのレスポンス速度を計測する

    ワンライナーでサイトのレスポンス速度を計測する

    はじめに

    しっかりした監視ツールを導入せずに、さくっとレスポンス速度を可視化したいときがある。

    手軽に描写できるワンライナーを紹介。

    どんなことができるか

    ワンライナー

    while true; do sleep 1; curl -kL 'http://接続先URL' -o /dev/null -w "%{time_total}" 2> /dev/null | perl -anle 'print "▇"x($F[0]*100)." $F[0]"' ;done
    

    [ec2-user@ip-10-1-8-134 ~]$ while true; do sleep 1; curl -kL 'https://tsukada.sumito.jp' -o /dev/null -w "%{time_total}" 2> /dev/null | perl -anle 'print "▇"x($F[0]*100)." $F[0]"' ;done
    ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 0.361941
    ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 0.370393
    ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 0.904969

    状況に応じて

    “` *100 “` の部分を適宜変更する。

     

  • standard_init_linux.go:190: exec user process caused “exec format error”

    standard_init_linux.go:190: exec user process caused “exec format error”

    概要

    dockerで起動シェルを渡した際、 “` standard_init_linux.go:190: exec user process caused “exec format error” “` というエラーが発生した際の対処

    原因

    起動シェルの中でshebangが抜けていたことが原因

    dockerの起動スクリプトでは必ず指定しなければならない

    対処

    起動シェルの1行目に

    #!/bin/bash

    を追加してあげるのみ(環境によって適宜変える)

    そもそもshebangとは

    “`  #! “` で始まる行。

    実行プログラムのインタプリタが定義される。

    ほとんどのプログラムは shebang が自動補完されるため無くても動く。しかし、dockerでは省略が不可能。shebangが必要なようだ。