1 Minute Tips

投稿者: sumito.tsukada

  • Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    Alternative Directory LayoutでAnsible-playbookを作った際に考えたこと

    はじめに

    Ansibleで環境を作ろうと思えば、Ansibleのディレクトリ構成をどのような作り方もできてしまうが、Ansibleのbest practicesのAlternative Directory Layout (https://docs.ansible.com/ansible/2.5/user_guide/playbooks_best_practices.html#alternative-directory-layout )を元に構成を作ることにした

     

    なぜAlternative Directory Layoutか

    まず、Alternativeではない、正攻法(?)のDirectry Layoutは、以下のとおり

    Directry Layout

     

    これに対し、Alternative Directory Layout は Staging/Production が 明確に分かれているのが特徴だ

    Alternative Directory Layout

    双方のメリット・デメリット

    メリット

    productionとstagingがディレクトリが分かれているため 環境ごとに設定を変える事ができる。

    Directry Layoutの場合、productionとstagingがディレクトリが分かれていない。

    そのため、productionとstagingが全く同じ環境であればよいが、ランニングコストを下げるためにStagingのみ台数を減らしたり、パラメータを変更するようなことが柔軟にやりにくくなってしまう。現在のみならず、先々を考慮しこの構成を採用した

    デメリット

    ほとんどの設定ファイルがproductionとstagingで冗長してしまう

    結論

    上記デメリットがあるものの、Alternative Directory Layout を採用することによる享受できるメリットが判断し、このレイアウトを採用することにした。

  • error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    error pulling image configuration: Get https://xxxx : net/http: TLS handshake timeout

    はじめに

    docker pullした際、以下のような TLS handshake timeout が発生

    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pulling fs layer 
1607093a898c: Pulling fs layer 
9a8ea045c926: Pulling fs layer 
1290813abd9d: Waiting 
8a6b982ad6d7: Waiting 
abb029e68402: Waiting 
8cd067dc06dc: Waiting 
1b9ce2097b98: Waiting 
d6db5874b692: Waiting 
25b4aa3d52c5: Waiting 
53ec227dabf0: Waiting 
242938ace8b4: Waiting 
85bc5aaf4ec5: Waiting 
fd5b749ebe99: Waiting 
6636846685ec: Waiting 
error pulling image configuration: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha256/9a/9ae2dde61ad6947df46e2cc416be9249f314d187feb717f6e18c0dc9a46bf5bf/data?verify=1538549397-3vZspNti03KIKxRXPmQsQeUbucI%3D: net/http: TLS handshake timeout
#

    解決方法

    docker login

    # docker login
Login with your Docker ID to push and pull images from Docker Hub. If you don't have a Docker ID, head over to https://hub.docker.com to create one.
Username: 
Password: 
Login Succeeded
#
    一度ログインすると、その後取得が可能になる
    # docker pull koda/docker-knowledge
Using default tag: latest
Trying to pull repository docker.io/koda/docker-knowledge ... 
latest: Pulling from docker.io/koda/docker-knowledge
55cbf04beb70: Pull complete 
1607093a898c: Pull complete 
9a8ea045c926: Pull complete 
1290813abd9d: Pull complete 
8a6b982ad6d7: Pull complete 
abb029e68402: Pull complete 
8cd067dc06dc: Extracting 7.242 MB/122.1 MB
1b9ce2097b98: Download complete 
d6db5874b692: Download complete 
25b4aa3d52c5: Download complete 
53ec227dabf0: Download complete 
242938ace8b4: Download complete 
85bc5aaf4ec5: Download complete 
fd5b749ebe99: Download complete 
6636846685ec: Download complete 
    

    
			
    
		
    
		
	
  • 
		
		
    
			
    NINE LIES ABOUT WORK　仕事に関する９つの嘘 を読んだ
    
			
    NINE LIES ABOUT WORK　仕事に関する９つの嘘 を読んだ
    
			
    背景
    

    チームリーダーとして仕事をする上で、自分のやり方が正しいのか、ルールがおかしいのかよくわからなくなることが多々ある。
    

    その度にマネジメント系の本を頼ったりしていたが、今回同僚にこの本を勧められたので自分も買ってみた。
    

    

    ８つの質問
    

    この本では、最も業績の高いチームにとくに多くみられた従業員経験の側面があり、それを正確に表現した質問事項が以下の８つあがっている。
    

      

    • 会社の使命に貢献したいと思っているか
      • 

    • 仕事で「自分に期待されている事」とはっきり理解しているか
      • 

    • 所属チームでは「価値観が同じ人」に囲まれているか
      • 

    • 仕事で「強みを発揮する機会」が毎日あるか
      • 

    • 自分に「チームメイトがついている」と思えるか
      • 

    • 「優れた仕事」をすれば認められることをしているか
      • 

    • 「会社の未来」に自信を持っているか
      • 

    • 仕事で常に「成長」を促されているか
      • 

    

    

    目標設定について
    

    登場人物のひとりとして、よくマラソンを目指す友人という話しがでるので、自分ごとのように読んだ。
    

    目標が役立つかどうか、自発的に設定したかどうか。全体目標から落とし込まれた目標は、本当の目標ではない。
    

    最高の企業は目標を落とし込まない。最高の企業は「意味」を落とし込む。
    

    チームメンバーには外の世界で起こっていることを理解させるとともに、どの山を目指しているのかを伝える。
    

    「意味」と「目的」がわかれば人は動く。
    

    貢献するための具体的な方法はチームメンバーに任せるべきだ。
    

    

    もっと突き詰めれば「共通の目標」があってもまとまらず、チームメンバーのために本当に重要な仕事の意味と目的、使命と貢献、手法を吹き込むことと説いてある。
    

    チームリーダーの役割
    

    チームリーダーの役割は、チームとしてのアウトプットを最大化し、メンバーには手鏡を与えることである。
    

    ビジネス感覚を持った人とはどんな人か
    

    ビジネス状況を理解して決断を示す機敏な速さのことであると説いてある。
    

    ビジネス感覚を持つ人は、状況に関する重要な情報を取得、主要目標に集中し、問題解決のために取り得る妥当な対応策を認識し、適切な行動指針を選ぶこと。それができる人のことだ。
    

    人は訓練を積んでも、他人を正しく評価できるようにはならないと本書では伝えている。
    

    その状況に対してどうすればいいか。
    

    評価に使う良いデータと悪いデータを識別する方法を学ぶことからはじめる
    

    答えではなく、問いを模倣せよ
    

    本書を乱暴にたった一行でまとめるとすればこんな感じだ。
    

    本ブログでまとめたのはごく一部だが。目から鱗が落ちるところが多々あった。
    

    

    
			
    
		
    
		
	
  • 
		
		
    
			
    n日前のファイルを削除する
    
			
    n日前のファイルを削除する
    
			
    

    ファイルのローテーションをするために処理を書くことがある、find コマンドの -mtime オプションを使うが、このようなニーズでないと使わないのでメモ。
    




     find /home/hoge/backup/* -mtime +7 
    




    7日前のファイルが表示される。
    




    xargs コマンドと合わせて削除をする。
    




    find /home/hoge/backup/* -mtime +7 | xargs rm -f
    

    
			
    
		
    
		
	
  • 
		
		
    
			
    ecr get-login を使わずコンテナを ECR に push する
    
			
    ecr get-login を使わずコンテナを ECR に push する
    
			
    

    今までは
    




    aws ecr get-login --no-include-email --region ap-northeast-1
    




    のコマンドで ECR に login して container を push  することができたが、
    




    近年上記コマンドが実行できなくなってしまった。
    




    代替コマンドとして get-login-password を使うことでログインができる
    




    aws --profile stg ecr get-login-password | docker login --username AWS --password-stdin https://123456789.dkr.ecr.ap-northeast-1.amazonaws.com
    




    




    Login Successeded となれば成功だ
    

    
			
    
		
    
		
	
  • 
		
		
    
			
    標準出力と、標準エラー出力をまとめてリダイレクトする
    
			
    標準出力と、標準エラー出力をまとめてリダイレクトする
    
			
    

    たまに使うんだけど、順番を毎回ググって確認していた 2>&1 というリダイレクト処理がある
    




    いままで
    




    command >> word 2>&1
    




    という書き方で、標準出力、標準エラー出力をリダイレクトしてきたが、
    




    実は bash 4.0 から以下のような記載ができるようになったようだ。
    




    command &>> word
    




    man コマンドで bash を見ると以下のような記載がある
    




    The format for appending standard output and standard error is:
    &>>word
    This is semantically equivalent to
    >> word 2> &1
    https://www.gnu.org/software/bash/manual/html_node/Redirections.html
    




    これは便利なので活用していきたい。
    




    




    参考情報
    




    
https://qiita.com/r_plus/items/41fb31285fb64fb4be85

    

    
			
    
		
    
		
	
  • 
		
		
    
			
    ピープルウエア を読んだ
    
			
    ピープルウエア を読んだ
    
			
    

    読んだ動機
    




    業務をしていたプロジェクトリーダーを努めさせてもらった一年半の長い長いプロジェクトがようやく終わりを迎える。
    




    振り返ってみたら、不確実性との戦いだった。手探りにプロジェクトを進め、ひっくり返ることもあった。
    




    不確実性との戦いは今回担当したプロジェクト特有のものではない。おそらくきっと、人生につきまとってくるもののひとつだ。
    




    それであればこの機会に不確実性についての取り扱いについてきちんと学びたいと思うに至った。
    




    




    そこで ヒロキさんの Qiita にたどり着いた。
    




    https://qiita.com/hirokidaichi/items/95678bb1cef32629c317#%E4%B8%8D%E7%A2%BA%E5%AE%9F%E6%80%A7%E5%88%86%E6%9E%90%E3%82%AF%E3%83%AA%E3%83%86%E3%82%A3%E3%82%AB%E3%83%AB%E3%83%91%E3%82%B9
    




    




    トム・デルマコの著書はとてもいい知見に溢れているものの、自分からしたら比喩がわかりにくいこともあり、あまりすすんで読もうとはしてこなかったが、
    




    知見を得たいとの一心で久しぶりに トム・デルマコ本。 ピープルウエア を読むことにした。
    




    




    学んだこと
    




    一言で言うと、この本は不確実性を直接対処するものではなく、生産性の高いチームを育てることで不確実性にも対応できるようにするといった本だ。
    




    管理者が陥りやすい錯覚
    




    個人的にはここで挙げられている項目が現在の自分が考えていた感覚とドンピシャだった。
    




    ７つ記載があったが、その中の３つがとても良かった。
    




    • 生産性を飛躍的に向上させる方法があるはずだが、見落としてきた
      上記錯覚に対する反論として以下が挙げられていた
      基本的なものを見逃すものはない。
      新しい方法を求め努力してきた。これからやろうとしている情報のどれもが、実際に生産性を高めることはない。
      人は、何かに熱中したり、学んだり改善したりと思っているものである。

    • 他の管理者は自分より、２倍、３倍の成果を上げている
      この錯覚に対する反論は以下のとおり。
      そんなこと気にすることはない。開発やテストの部分に照準を合わせているに過ぎない。
      他にもドキュメント作ったり、顧客と折衝したりする必要がある。
      小さな視点で人と比べるのは良くない。

    • バックログが多いから生産性をあげなければならない。
      プロジェクトの完成時にコストを計算すると、当初予算を遥かに上回るのが常識。
      開発資金がなかった為に完成できなかったから、バックログになったもの。
      生産性の向上は、バックログをこなすために必要なのではない。
      バックログに溜まったタスクを潔く捨ててしまうことで得られる。
      （わかるけどこれはちょっと極端だ）
    




    生産性の高いチームを育てる
    




    人が楽しいと思える仕事に必ず「挑戦」がある。
    




    挑戦はチームのメンバーが一緒になって努力する目標が与えられるからこそ必要になる。挑戦は時にチームを一つにまとめる道具になる。最良の仕事仲間を持った時、人は愉快な気分になるものだし、力を尽くす。その時チームの相互作用がフルに働く。この瞬間、メンバーも楽しいと感じる。
    




    チームが結束し始めると、成功の確率はぐんと高まる。このフェーズに入ったチームを率いることはリーダーとしての楽しみにもなるようだ。
    




    




    結束の強いチームの特徴として、退職率の低さがある。
    




    自己防衛を取ることのリスク
    




    チーム編成を妨げ、プロジェクトを崩壊させる確実な方策与えられた仕事をこなす能力が部下にない場合、プロジェクトは失敗する。
    しかし、与えられたグループでやっていこうと一旦決めたなら、最良の戦術は部下を信頼すること。
    部下を信頼する代わりに、プロジェクトの成功を保障しようとして自己防衛の手段をとれば事態は悪化する。
    




    




    最良の上司の定義
    




    「管理」などないかのように、チームが和やかに一致団結働かせることができる人。
    




    管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人。
    




    




    健全な会社にするための戦略的要素
    




    • 品質を高める
      チームのメンバーが品質至上主義になると、市場が求めている以上の品質が備えた製品を常に生産するようになる。
    • 満足感を与える打ち上げ
      （コロナ禍なので飲み会は難しいけど、自分の担当プロジェクトが完遂しら何かしないとな。）
    




    読み飛ばしたところ
    




    この本が書かれた時と時代は変わり、リモートワークが定着したことでオフィスに全員が出社する頻度はかなり減った。本書ではオフィスの環境についても書かれてあったが、そこはざっと読んだだけで、ほとんど読み飛ばした。
    




    ここの部分はリモートワークについて語ってる Youtube大学で語っていることを取り入れることにした。
    




    


    




    まとめ
    




    時代は変わってもチームビルディングについてのポイントは変わってない。
    




    名著から学ぶことは多い。
    

    
			
    
		
    
		
	
  • 
		
		
    
			
    Model name must be alphanumeric:
    
			
    Model name must be alphanumeric:
    
			
    

    API gateway にinsert する際、エラが発生
    




    Your API was not imported due to errors in the Swagger file.
Unable to create model for 'user_id': Model name must be alphanumeric: user_id
Unable to create model for 'staff_id': Model name must be alphanumeric: staff_id

    




    これは正規表現でいうところの
    




    




    [a-zA-Z0-9]+
    




    




    のみ model name としての利用を許容しており、アンダースコア含めた名前は API gateway に許容されていないため。
    




    swagger としては アンダースコアが利用可能なので、API gateway も許容してもらいたいところだ。。
    




    




    以下のように対処する
    




    paths:
  /hoge:
    post:
    requestBody:
        content:
          application/json:
            schema:
              type: object
              properties:
                booking_deadline:
                  $ref: '#/components/schemas/hogeline'


components:
  schemas:
    Event:
      type: object
      properties:
        hoge_line:
          $ref: '#/components/schemas/hogeline'

    




    

    
			
    
		
    
		
	
  • 
		
		
    
			
    DMM.com を支えるデータ駆動戦略 を読んだ
    
			
    DMM.com を支えるデータ駆動戦略 を読んだ
    
			
    

    誰も正解を持っていない中プロダクトを開発しなければならない。不確実性との戦いである。
    




    情熱を科学で支える。データ駆動戦略とは、データを駆動させることで事業の優れた価値を見つけ、組織がデータを中心に意思決定する世界。このゴールのイメージがとても重要になる。
    




    本書ではデータ駆動する上でスクラムなどの開発手法の話にも言及があるが、その辺はすっ飛ばして、あくまでも”データ基盤” を作る上で必要な情報のみまとめる。
    




    データ駆動戦略を用いた事業の捉え方と、プロセスは以下の順番を遡ると説いている。
    




    




    1. 事業でどうやって収益を得ているか知る。
      何をインプットとするか。
      インプットに対してどのような処理が行われているか
      何をアウトプットとしているか

      時には１ユーザーの売り上げベースでミクロの視点で見る必要もあり、
      合計の売り上げで見るマクロの視点で見る必要がある。

    2. その後、事業構造を KPI で表現して予測可能性を作る。
      KPI を作るにあたり、 KGI (Key Goal Indicator) の理解や、
      CSF (Critical Success Factor) に関する知識が必要。

      KGI – CSF -KPI 

      といったツリー構造になる。
       　
       
    3. KPI から見えた課題に対して施策を実行していく。この際、費用対効果が高い KPI を選定する。

      KPI として訪問者数を目標値として老いたとする。
      キャンペーンなどの施策を行いながら、訪問者数を増やしていく。

      この時重要なのは、施策の優先順位付けに時間をかけるのではなく、
      施策の実行スピードを重要視することである。
       
    4. 仮説検証のサイクルを回す。必ず成功する施策はない。失敗を許容し多くの施策を回す。

      不確実性の高い事業の中で、全て成功するとは限らない。失敗を許容する仕組みを用意する
       
    5. KPI サイクルを高速に合理的に回す

      スピードを上げる。
    





    データ基盤を作る上では、まずはデータを集約することが第一歩にな理、データパイプラインが必要になる。
    




    データ集約は組織全体で行わないと効果が限定的になり、局所最適化になってしまう。
    




    

    
			
    
		
    
		
	
  • 
		
		
    
			
    「いちプレーヤー」から「マネージャー」に頭を切り替える思考法 リーダーの仮面 を読んだ
    
			
    「いちプレーヤー」から「マネージャー」に頭を切り替える思考法 リーダーの仮面 を読んだ
    
			
    

    さまざまなリーダーシップや組織論についての本があるが、本屋さんの中で平積みされていたので気になっていた本。
    




    「素顔」のままで疲れ果てるか、「仮面」をかぶり、生まれ変わるか。
    




    という背表紙の一文にはドキッとさせられる。
    




    本書に書かれていたことと、私自身の経験も照らし合わせながらまとめていこうと思う。
    




    




    リーダーの責務の一つに
    




    部下を成長させ、チームの成果を最大化させることがある。
    




    リーダーがチームの成果を最大化させるためにリーダが見るべきポイントはわずか５つだけである。
    




    この５つのポイントにフォーカスし、それ以外のことは任せる、見守る、スルーするようにする。選択と集中。まさにそのように感じた。
    




    




    




    組織マネジメントには数学や物理のように公式のような決められた型がある。
    




    トラブルに見舞われ、リーダーとしてどう振る舞えばいいか悩むことに出くわすが、この５個に立ち返るだけで良い。自分の所感も含めて記す。
    




    1. ルール
    




    場の空気ではなく、言語化されたルールをつくることが重要だ。
    




    ルールを作り、それを守らせるのがリーダーのすべきこと。
    




    ルールを作って、規則正しく動くのであれば精神的に疲れることもない。
    




    ルールを作る際は、主語を明確にするのがポイント。
    




    ルールが重要であり、他人に「気遣い」を期待することなどあってはならない。
    




    他人に期待してしまい、それが期待通りされなかった時は辛い。
    




    最初から「気遣い」などに期待しないと割り切ることが重要。本当に必要であればそれはルールに盛り込むことだと説いている。
    




    2. 位置
    




    対等ではなく、上下の立場でコミュニケーションする
    




    責任者がハッキリしていないと部下は働きにくい。
    




    3. 利益
    




    人間の魅力ではなく、利益の有無で人を動かす
    




    みんなで利益を目指せば迷子にならない。これはとても重要なことであり、目的が一緒であれば手段は部下に選ぶ裁量渡しても良いのではないかと個人的には思う。
    




    チーム全員を「組織の利益」に向かせるための仕組みがとても重要。
    




    「成長」という利益を追い求める限り、会社との利益相反を起こさず永遠に利益を得続けることができる。
    




    4. 結果
    




    プロセスを評価するのではなく、結果だけを見る
    




    5. 成果
    




    目の前の成果ではなく、未来の成長を選ぶ
    




    




    総括として、いかなる時も個人的な感情は決して表に出さない。
    




    ルールに基づいてチームを動かし、そして結果だけをみて冷静に評価する。
    




    本書では 1on1 などのコミュニケーションも否定しているし、合う人合わない人が明確に分かれそうだ。しかし中間管理職として疲弊する人にとっては、このような考え方もあるのかと非常に勉強になった。
    




    




    そもそもリーダーシップとは？
    




    またリーダーシップと、マネジメントについては鴨頭さんの動画が非常にわかりやすかった。
    




    リーダーシップとは
    




    


    




    マネジメントはこちら
    




    


    




    同じ動画（開始位置が違うだけ）なのでサムネが一緒になってしまっているが。
    




    自分はこの表現がとてもわかりやすかったので紹介。