shimapapa.io

.NET,VB,C#,AzureなどMS関連中心の技術ブログ

Azure Container InstancesでJenkinsを立ち上げる

Tech

概要

Jenkinsに一度触れてみたくて、現在udemyでJenkinsの講座を受講しています。
先日Dockerの講座も受講完了したのと、今後Azureの勉強も始めたいことを踏まえ、
Azure Container Instances上にJenkinsを立ち上げて見たいと思います。

※Azureには「Azure Devops」というCI/CDサービスが存在していますが・・・

手順

Azureの操作はほぼ初めて。
今回はAzureのポータル上からCLIでリソースの操作が行えるAzure Cloud Shellで実行していきます。

1. リソースグループの作成

今回は「jenkinsResource」という名前のリソースグループを作成します。

az group create --name jenkinsResource --location eastus

成功すると以下のような結果が表示されます。

"id": "/subscriptions/d7eb1cd7-6516-4492-9006-6a138b4dfaae/resourceGroups/jenkinsResource",
  "location": "eastus",
  "managedBy": null,
  "name": "jenkinsResource",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": null
}

2. Azureファイル共有の作成

Jenkinsコンテナのデータを永続化させるため、ストレージ アカウントとファイル共有を作成します。

2-1. 環境変数STORAGE_ACCOUNT_NAMEのセット

ストレージアカウント名をRANDOMを付けて適当に設定します。

$ STORAGE_ACCOUNT_NAME=mystorageaccount$RANDOM

2-2. ストレージ アカウントを作成

az storage account create \
  --resource-group jenkinsResource \
  --name $STORAGE_ACCOUNT_NAME \
  --sku Standard_LRS \
  --location eastus

2-3. 環境変数AZURE_STORAGE_CONNECTION_STRING のセット

続いてストレージ アカウントの接続文字列をセットします。

$ export AZURE_STORAGE_CONNECTION_STRING=$(az storage account show-connection-string \
  --resource-group jenkinsResource \
  --name $STORAGE_ACCOUNT_NAME \
  --output tsv)

2-4. ファイル共有の作成

今回は「aci-jenkins」という名前でファイル共有を作成します。

az storage share create --name aci-jenkins

2-5. 環境変数STORAGE_KEY のセット

コンテナにAzure ファイル共有をマウントするために、ストレージ アカウント アクセス キーを取得し、
環境変数にセットします。

$ STORAGE_KEY=$(az storage account keys list \
  --resource-group jenkinsResource \
  --account-name $STORAGE_ACCOUNT_NAME \
  --query "[0].value" \
  --output tsv)

$STORAGE_KEYの値の確認。

$ echo $STORAGE_KEY

3. コンテナの作成と起動確認

3-1. コンテナの作成

準備ができたのでコンテナの作成をします。
今回は「aci-jenkins」という名前のコンテナとします。
（ファイル共有と同じ名前にしてしまって紛らわしい）
portsはJenkinsの設定値である8080にしておきます。
以下コマンドを実行後、しばらく待つとコンテナが起動します。

az container create \
  --resource-group jenkinsResource \
  --name aci-jenkins \
  --image jenkinsci/blueocean \
  --location eastus \
  --ports 8080 \
  --ip-address Public \
  --azure-file-volume-account-name $STORAGE_ACCOUNT_NAME \
  --azure-file-volume-account-key $STORAGE_KEY \
  --azure-file-volume-share-name aci-jenkins \
  --azure-file-volume-mount-path /var/jenkins_home/

3-2. ストレージのマウントの確認

前項でAzureファイル共有にマウントした「/var/jenkins_home/」の内容が表示されます。

$ az storage file list -s aci-jenkins -o table
Name                      Content Length    Type    Last Modified
------------------------  ----------------  ------  ---------------
.cache/                                     dir
.java/                                      dir
copy_reference_file.log   3926              file
failed-boot-attempts.txt  29                file
jobs/                                       dir
plugins/                                    dir
secret.key                64                file
secret.key.not-so-secret  0                 file
war/                                        dir

3-3. IPアドレスの確認

az container show \
--resource-group jenkinsResource \
--name aci-jenkins \
--query ipAddress.ip \
--output tsv

3-4. 起動の確認

前項で出力されたIPアドレスとポート8080をブラウザに入力すると・・・

f:id:rikupapa-shima:20190605054130p:plain

Jenkinsの画面が表示されました！

4. Jenkinsの設定

4-1. Unlock Jenkins

前項の画面の後、初期パスワードを入力する画面が表示されます。 解除するには画面に表示されている通り「var/jenkins_home/secrets/initialAdminPassword」に記載されている値を入力します。

f:id:rikupapa-shima:20190605054038p:plain

Cloud Shell セッションにファイルをダウンロードします。

az storage file download -s aci-jenkins -p secrets/initialAdminPassword

ダウンロード後、catコマンドを実行するとパスワードの値が出力されます。

$ cat initialAdminPassword

Jenkinsに戻ってパスワードを入力すると、初期設定画面に進みます。 f:id:rikupapa-shima:20190605054848p:plain

※上記画面で「Install suggested plugins」を入力したあと、
　「No valid crumb was included in the request」というエラーが表示されましたが、
　Retryボタンを押すと次に進みました。

以上、Azure Container InstancesでJenkinsを立ち上げるでした。

参考サイト

DockerでRuby on Railsの環境構築：「W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease」のエラー

Tech

今月から以下のudemyのレッスンでDockerの勉強を始めている。

www.udemy.com

「セクション9 : 49. Docker Composeを使用したRubyon Railsの開発環境構築」
で引っかかったのでメモ。

以下、定義ファイル等の作成を終えてdocker-composeで実行するが

docker-compose run web rails new . --force --database=postgresql

以下のようなエラーが発生。

...
Step 2/8 : RUN apt-get update -qq && apt-get install -y build-essential libpg-dev nodejs
 ---> Running in f1c47b444c36
W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  
Unable to find expected entry 'main/binary-amd64/Packages' in Release file (Wrong sources.list entry or malformed file)
...

こちらの記事を参考に修正。
debian(jessie)のdocker image使ってるとapt-getでエラーが出る - Qiita

Dockerfileに追記して再度docker-composeを実行。

...
（追記）RUN echo "deb http://deb.debian.org/debian jessie main" > /etc/apt/sources.list
（追記）RUN echo "deb http://security.debian.org jessie/updates main" >> /etc/apt/sources.list
（追記）RUN curl -sL https://deb.nodesource.com/setup_8.x | bash
RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs
...

正常にコンテナが起動できた。

「THE TEAM 5つの法則」読了後の所感と読書メモ

Reading

THE TEAM 5つの法則

THE TEAM 5つの法則 (NewsPicks Book)

THE TEAM 5つの法則 (NewsPicks Book)

読了後の所感

ともすれば感情論が先出しそうなチーム・組織論やモチベーションについて、方程式を当てはめるような形での分析が記されている点が非常に参考になった。
ほぼすべての章において「Aという問題には、Bという方法で対処する」「AにはBというメリットがあるが、Cというデメリットもある」といった構成になっているので、曖昧性が殆ど無い。構成も秀逸だと思えた。
チーム論においては兎に角ロジカルに記されている一方、最終章において著者の麻野さんが実際にチームの法則を用いて、所属していたチームを変えていくストーリーと「終わりに」の読者へのメッセージは、エモーショナルで胸が熱くなる面もあったりする。

ソフトウェアエンジニア視点から非常に共感出来たというか参考になったのは、最終章内の「モチベーションクラウド」の開発ストーリー。

  • どの機能から順に開発していくかは非常に重要な意思決定だった
  • どの機能をどの順番で開発するか議論する前に、主要開発メンバー全員で以下3つの視点の選択基準を洗い出した
    • ビジネス視点：継続利用率の向上／新規顧客の開拓
    • テクノロジー視点：システムの拡張性／システムの安定性
    • デザイン視点：利用者のユーザビリティ向上／プロダクト全体の顧客体験改善
  • 選択基準に対する優先順位を定めた上で、意思決定を進めていった
  • 結果として、私（麻野さん）の持っているビジネス視点に偏りすぎた意思決定にならず、最適な意思決定を積み重ねられた

つまり、ビジネス面・技術面・デザイン面のバランスを慎重に取りながら、メンバー間で合意形成しながら要件定義をしていったと解釈した。
非常に真っ当な進め方としか言えないのだが、これが出来ずに一体どれだけのシステム開発が失敗しているのか・・・
システム開発にある意味ありがちな失敗を、「チームの法則」を用いて成功に導いた好例と言えるのではないかと感じた。

今後も「こんなときはどうする？」と迷った時に、常に手元に置いておきたい1冊となった。

読書時のメモ

第１章 Aim（目標設定）の法則

  • グループとチームの違いは、共通の目的の有無
  • 自分たちの活動は目的意識に左右される
  • 「カラーバス効果」・・・人間はある目的を意識すると、その目的に関連する情報をそれまで以上に認識するようになる
  • 目標を「適切に設定する」のが良いチーム
  • 目標のトレンド：行動目標 = 振り返り評価 → 成果目標 = MBO → 意義目標 = OKR
  • ビジネス環境の変化スピードが早く、行動目標に基づく評価だけではパフォーマンスが上がりにくくなっている
  • 現代では、各チームが意義や目的に立ち返り、成果目標の観点や水準を見直す必要がある
  • 行動目標しか設定されていないと、メンバーは「作業」の奴隷になる
  • 成果目標しか設定されていないと、メンバーは「数字」の奴隷なる
  • 意義目標を設定することによって、意思を持つことができる
  • エピソード：JR東日本テクノハートTESSEIの新幹線清掃員チームの変革
  • エピソード：2010年サッカー南アフリカワールドカップ・岡田監督率いる日本代表

第２章 Boading（人員選定）の法則

  • 採用はYシャツの第一ボタン。ずれていたら、どれだけ頑張っても他のボタンはきちんととめられない
  • 採用の失敗は挽回することは出来ない
  • チームは必ず４つのタイプに当てはまる
    • 環境の変化度合い：大／人材の連携度合い：大 > サッカー型
    • 環境の変化度合い：大／人材の連携度合い：小 > 柔道団体戦型
    • 環境の変化度合い：小／人材の連携度合い：大 > 野球型
    • 環境の変化度合い：小／人材の連携度合い：小 > 駅伝型
  • 必ずしも「メンバーが入れ替わらないチームが良いチーム」ではない
  • 「人材の連携度合い」が小さければ、似たタイプの能力を持ったメンバーを集めたほうが良い
  • 「人材の連携度合い」が小さければ、異なるタイプの能力を持ったメンバーを集めたほうが良い
  • 置かれた状況に合わせて、メンバーは均質的であるべきか、多様性をもたせるべきか、意識する
  • ビジネスのソフト化や短サイクル化によって、日本の多くのチームが駅伝型ではなくサッカー型の活動を求められるようになってきた
  • 「ゴッドファーザー」ではなく「オーシャンズ11」のようなチームが求められる
  • エピソード：AKB48の成功は「流動性」の結果

第３章 Communication（意思疎通）の法則

  • チームのコミュニケーションは少ないほうが良い
  • ルール設定の４つのポイント
  • What：ルールの設定粒度
    • 人材の連携度合いが小さい活動は、ルールを細かく決める必要はない。
    • 人材の連携度合いが大きい活動は、ルールを細かく決めないとコミュニケーションコストがかかりすぎる
    • 環境の変化度合いが大きい活動は、ルールを細かく決める必要はない。状況が変わってしまえば活用できなくなる。
    • 環境の変化度合いが小さい活動は、ルールを細かく決めても継続的に活動できる
  • Who：権限規定のルール
    • 人材の連携度合いが小さい活動は、メンバーが自分で決めても問題はあまり生じない
    • 人材の連携度合いが大きい活動は、リーダーやチームでメンバーの活動についてもある程度決めていかないと、不具合が生じる
    • 環境の変化度合いが大きい活動は、メンバーが自分で決めたほうが良い
    • 環境の変化度合いが小さい活動は、リーダーやチームにその都度判断を仰いだ方が適切に対処できる
  • Where：責任範囲のルール
    • 人材の連携度合いが小さい活動は、自分の担当領域の成果のみに責任をおっても問題はない
    • 人材の連携度合いが大きい活動は、メンバーにはチーム全体の成果にも責任をおってもらった方が良い
    • 環境の変化度合いが大きい活動は、ひとりひとりの責任範囲を状況の変化によって変える必要がある
    • 環境の変化度合いが小さい活動は、明確に責任範囲が決まっているのが効果的
  • How：評価対象のルール
    • 人材の連携度合いが小さい活動は、ひとりひとりが創出した成果を評価すべき
    • 人材の連携度合いが大きい活動は、ひとりひとりのプロセスやアクションを評価したほうが評価しやすい
    • 環境の変化度合いが大きい活動は、最終的に創出された成果で評価すべき
    • 環境の変化度合いが小さい活動は、成果に至るまでのプロセスを評価することも可能
  • When
    • 人材の連携度合いが小さい活動は、チーム全体の進捗の確認頻度は少なくても問題ない
    • 人材の連携度合いが大きい活動は、チーム全体で進捗をこまめに共有、確認しながら活動する必要がある
    • 環境の変化度合いが大きい活動は、チーム全体での確認頻度が多いほうが良い
    • 環境の変化度合いが小さい活動は、変化が少ない分、確認が少なくても問題ない
  • チームメンバーが動いてくれない原因は、「感情」にこそある
  • 同じことを言われたとしても「誰から」「どのような場」で言われたかによって、メンバーの感情は大きく変わる
  • チーム内のコミュニケーションは無駄があっても良い
  • 『７つの習慣』の１つ「理解してから理解される」
  • 中国の故事「士は己を知る者の為に死す」
  • 同じ内容を伝えたとしても、自分のことをわかってくれていない人が伝えるのと、わかってくれている人が伝えるのは、受け手の感情が全く違う
  • 相手に自分は理解されていると感じてもらうために、チームメンバーは他のメンバーの「経験」「感覚」「志向」「能力」を理解する必要がある
  • 相手の「経験」だけではなく「感覚」まで掘り下げることによって、「線」ではなく「面」で相手を知る必要がある
  • モチベーショングラフ・・・横軸に時間、縦軸にモチベーションを取り、変化を曲線で描く。曲線の山や谷に吹き出しで出来事を記入。
  • 相手の特徴を知らなければコミュニケーションは成立しない
  • リンクアンドモチベーションでは、人の「志向」を知るための「モチベーションタイプ」、能力を知るための「ポータブルスキル」というフレームワークを活用
    • モチベーションタイプ・・・思考や行動に対する欲求
      • 「アタックタイプ」（達成支配型欲求）
      • 「レシーブタイプ」（貢献調停型欲求）
      • 「シンキングタイプ」（論理型探求欲求）
      • 「フィーリングタイプ」（審美創造型欲求）
    • ポータブルスキル・・・業界や職種問わず必要とされる能力
      • 対自分力
        外的スキル：決断力、曖昧力、瞬発力、冒険力
        内的スキル：忍耐力、規律力、持続力、伸長力
      • 対人力
        父性的スキル：主張力、否定力、説得力、統率力
        母性的スキル：傾聴力、受容力、支援力、協調力
      • 対課題力
        右脳的スキル：思考力、変革力、機動力、発想力
        左脳的スキル：計画力、推進力、確動力、分析力
  • 自分たちはメンバーの「行動」しか見ることが出来ないが、裏側にある「志向」や「能力」を理解することで、互いのコンテキストに合わせたコミュニケーションが可能になる
  • 人間はひとりひとり異なる前提を持っているため、同じ内容を伝えても自分とは全く異なる受け取り方をしたり、全く異なる感情を抱いたりする
  • 多くのチームでは、問題やアイデアをチームとして共有するのを「場」が阻害してしまっている
  • 「どうせ、しょせん、やっぱり」
  • 場に対するネガティブな感情を排除し、積極的な発言や行動を引き出すのに重要なのが「心理的安全」
  • 心理的安全に支障をきたす原因は以下の４つ
    • 無知だと思われる（Ignorant）
      • NGワード：「こんなことも知らないのか」
      • チームが作り出すべき機会：率直質問
      • メンバーに生まれる心理：「聞いてもいいんだ」
    • 無能だと思われる（Incompetent）
      • NGワード：「こんなこともできないのか」
      • チームが作り出すべき機会：失敗共有
      • メンバーに生まれる心理：「間違ってもいいんだ」
    • 邪魔だと思われる（Intrusive）
      • NGワード：「今の言う意味あった？」
      • チームが作り出すべき機会：発言促進
      • メンバーに生まれる心理：「言ってもいいんだ」
    • 批判的だと思われる（Negative）
      • NGワード：「それは絶対違うでしょ」
      • チームが作り出すべき機会：反対意見
      • メンバーに生まれる心理：「人と違ってもいいんだ」
  • 今は以前よりも労働市場の流動性が高まり、企業組織における多様性も高まった
  • かつてよりもはるかに細やかな、相手の価値観や感情に配慮したコミュニケーションが求められている
  • 多くの企業が1on1に注目しているのは、チーム内のコミュニケーションの重要性が増していること、効果的なコミュニケーションのために心理的安全がポイントになっていることを表しているのでは
  • エピソード：ロンドンオリンピック女子バレーボール同メダル
    • チーム内の相互理解に注力し、コミュニケーションの土台を整備した後、戦略や戦術にフォーカスしたコミュニケーションにしていった
  • エピソード：ジョン・F・ケネディのキューバ危機回避
    • 「悪魔の代弁者」・・・大統領にわざと異論を唱える側近を二人与えた
  • エピソード：ピクサーのコミュニケーション

第４章 Decsion（意思決定）の法則

  • チームにおける意思決定は個人におけるそれよりもはるかに難しい
  • 社会心理学では、複数人が集まると不適切な意思決定をしてしまうという説すらある
  • チームの意思決定には３つの方法がある
    • 独裁
      • チームの中の誰か一人が独断で意思決定する
      • 納得感：低
      • 時間（意思決定のスピード）：短
    • 多数決
      • いくつかの選択肢を提示した上でチーム全員の意思を問い、多数の賛同を得た選択肢に決定する
      • 納得感：中
      • 時間（意思決定のスピード）：中
    • 合議
      • チーム全員で話し合って結論を導く
      • 納得感：高
      • 時間（意思決定のスピード）：長
  • チームで意思決定をする際には、議論や検討を始める前にどの意思決定方法を用いるか決める
  • チームによる「合議」をスピーディに、再現性を持って進めるためには、選択肢同士ではなく、まず選択基準と優先順位を決めるべき
  • 「正しい独裁」はチームを幸せにする
  • 意思決定者が必要な情報を十分に集め、様々な角度からの意見を聞いた上で決めることは、意思決定の制度を高めるためには非常に重要
  • 極論を言うと、チームとしての意思決定を迫られるのは、メリットが51%、デメリットが49%あるようなことに対してだけ
  • ファーストチェス理論：「５秒で考えた手」と「30分かけて考えた手」は86%が同じ手。5秒以内に打ったほうが良い。
  • 意思決定者は孤独を恐れず、チームのために迅速に力強く意思決定しなければなりません
  • 意思決定は意思決定そのものよりも、意思決定後に選んだ選択肢をどれくらい着実に実行し、正解に出来るかが重要
  • 独裁者が持つべき影響力の源泉
    • 専門性：メンバーにすごいと思われる技術や知識を持っていること
    • 返報性：メンバーにありがたいと思われる支援や関与をしていること
    • 魅了性：メンバーにすてきと思われる外見的・内面的魅力を持っていること
    • 厳格性：メンバーにこわいと思われる規律や威厳を持っていること
    • 一貫性：メンバーにぶれないと思われる方針や態度を持っていること
  • エピソード：NASA アポロ11号 月面着陸
  • エピソード：シンガポールの経済成長

Engagement（共同創造）の法則

  • どんなプロフェッショナルも、その活動はモチベーションに左右される
  • 全てのチームがモチベーションに左右される
  • エンゲージメントを高めるための4P
    • Philosophy（理念・方針）
    • Profession（活動・成長）
    • People（人材・風土）
    • Privilege（待遇・特権）
  • エンゲージメントを高めるためには時間やお金などの投資が必要になる
  • エンゲージメントという観点から投資対効果を高めるためには、4Pのうちどれをチームの一番の魅力にするか定め、そのPをエンゲージメントの源泉とするメンバーを集め、そのPに絞って魅力を高めることが重要
  • もしもチームが「何に共感して、メンバーたちはチームで活動しているのか？」が不明確なのであれば、エンゲージメントを高める軸を明確にすべき
  • エンゲージメントの方程式：エンゲージメント=報酬・目標の魅力（やりたい）× 達成可能性（やれる）× 危機感（やるべき）
  • 報酬・目標の魅力（やりたい） = WILL
  • 達成可能性（やれる） = CAN
  • 危機感（やるべき） = MUST
  • ディズニーのようなPhilosophy型のエンゲージメントの場合
    • 「ハピネスを日本中の人々に提供する」というゴールを定めたら（報酬・目標の魅力）
    • 途中の目標を「1000万人、2000万人、3000万人の来客を集める」などのプロセスに分ける（ 達成可能性）
    • ゴールやプロセスへの貢献が少なければ組織に所属できなくなるなどのペナルティを課す（危機感）
  • メンバーのエンゲージメントを高める方程式をチームに埋め込むことが大切
  • これからの時代のチームは、金銭報酬や地位報酬だけでなく、感情報酬を重視しなければならない

特別収録：チームの落とし穴

  • 社会的手抜き
    • リンゲルマン効果：集団が大きくなるほど、1人あたりのパフォーマンスが低下する
    • この落とし穴にはまらないためには、メンバーの「当事者意識」を高めること
    • 当事者意識を高めるためにコントローすべきポイント
      • 人数：少なけれ少ないほど当事者意識は高まる
      • 責任：ひとりひとりの責任の所在が曖昧であれば、当然当事者意識も低下する
      • 参画感：意思決定が自分とは関係ないところで進んでいると、チーム全体のことが段々と他人事のようになっていく
  • 「あの人が言っているから」
    • 肩書や経験のあるメンバーに他のメンバーがやみくもに従ってしまい、個人であれば決してしないような間違った意思決定をしてしまうこと
    • この落とし穴にはまらないために、チームの中に「議論」というプロセスを埋め込むことが重要
  • 「みんなが言っているから」という落とし穴（同調バイアス）
    • 自己の経済利益を最大化させることを唯一の行動基準とする人間のことをホモ・エコノミクスと呼ぶ
    • 現実にはホモ・エコノミクスは存在しない。なぜなら、人間は感情で動く生き物で、時に非合理な行動を選択してしまうから
    • 人間の非合理な行動につていから、行動経済学が生まれた
    • 行動経済学では「同調バイアス」というバイアスが提唱されている（ハーディング効果）
    • この落とし穴にはまらないためには、チームの「雰囲気」を意識的にマネジメントすることが重要
    • 一度ネガティブな人がマジョリティ（過半数）を握ってしまうと、みんなが同調バイアスを発揮し、ネガティブな態度に追随してしまうので、チームの「雰囲気」を変えることが非常に難しくなる
    • 一方でチームにポジティブな態度の人ばかりでもチームは良くない方向に進むことがある。周囲の顔色を見ながら何でもかんでも賛成するようばチームは、時に状況判断や意思決定を間違えるから。
    • チームの雰囲気はポジティブすぎてもネガティブすぎてもいけない
    • 「雰囲気」をマネジメントするためには、「スポットライト」と「インフルエンサー」の観点が重要
    • スポットライト・・・チーム内である態度のメンバーに光を当てることで、実態よりも全体的にポジティブな人が多い、ネガティブな人が多いと感じさせてチームの雰囲気をコントロールするアプローチ
    • インフルエンサー・・・チーム内で特に他のメンバーに影響力の強いメンバーに個別に働きかけ、転換させることでチームの雰囲気をコントロールするアプローチ
  • 「あの人よりやっているから」という落とし穴（参照点バイアス）
    • 本来は100のパフォーマンスを出せる人が、隣のチームメンバーが60しかパフォーマンスを出していないので、自分も60くらいでいいか、と意識的・無意識的に考えてしまう
    • 特にリーダーはメンバーの参照点になりやすい
    • この落とし穴にはまらないためには、チームの中で「基準」を明確に示すことが重要
    • チームの中で誰が「基準」を満たしているのか、満たしていないのかを共有することで、自分に都合の良いメンバーの成果や行動を参照点にさせるのではなく、チームとして「基準」にすべきメンバーの成果や行動を参照点にする必要がある

14年目のエンジニア・1年目からのふりかえり

diary

明日から4月。
明日で社会人・エンジニアになり13年経過したことになる。
ここに来て改めて13年をふりかえってみたくなったので、まとめてみた。

1年〜3年目（2006年〜2008年）

とあるきっかけで、自分はある業界向けのパッケージソフトを自社で開発・販売している会社に新卒入社した。 かっこよく言えば「ベンチャー」「スタートアップ」とも言えるが、小さな小さなソフト会社だった。

使用していた言語は、入社当初はVB6.0。その後製品のリプレースに伴いVB.NETに触れていく。

プログラムを書く事自体は楽しめていたし、対象となる業界にも興味が持てていた。 しかし、業務時間以外に独学で勉強するといったモチベーションはなかった。 プライベートな時間は趣味や友人達と遊ぶことに費やしていた。 恥ずかしい話だが、社会人やエンジニアとしてのキャリアプランなんて全く頭になかったというのが正直なところ。

だが、今回のふりかえりで思い出したことがあった。

当時会社ではテストチームが発見したバグを、Excelで入力したレポートを印刷して開発者に共有していた。 レポートに修正があれば再度印刷したり、手書きで直したりと、こんなフローを自分はとても無駄に感じていた。 そのような状況の中、調べた結果、世の中には「バグレポートシステム」というのが存在していることを知る。
調査した中から自分はMantis Bug Trackerというツールを発見し、 空いているPCにインストールさせてもらい、社内に展開。Mantisはたしか2年ぐらいは運用されていたと思う。 その後、バグ報告以外にもタスク管理が出来るツールとして「Backlog」を発見。 これも自分で発見して社長に提案した。Backlogはその後10年以上社内で使用され続けることになった。

また、ソースコードは当時ファイルサーバーで他のプログラマの方と共有していた。（！） 起こって当たり前の状況なのだが、上書きミスして1日分の作業を捨てる事故を起こす。 対策案を調べる中、世の中には「ソースコード管理ツール」というのが存在していることを発見。 IDEがVisual Studioだったこともあり、MSのTeam Founadion Serverを提案。
こちらも自分でインストールして社内で運用を始めた。

ここまでふりかえると、当時ソフトウェア開発についてはそこまでモチベーションが高いわけではなかったが、

  • 業務フローにおいて無駄と思える部分を発見する
  • 解決策を探す
  • 解決策を提案・実施する

といったことがこの時点で行えていたんだな、と今回のふりかえりで思い出せた。

4年〜6年目（2009年〜2011年）

2009年頃はiPhoneの普及とともにiOSアプリ開発が盛り上がる。 2010年にはiPadが登場。 社内でもiPadを使った製品の企画が立ち上がり、iOS開発に携われることになった。 スクールにも通わせてもらえることになり、Objective-Cのスキルを身につけることができた。

さらに2010年頃からどういう風の吹き回しか、ビジネス系の書籍を読み始める。 会社のしくみ、マーケティング、経済や世界情勢の本など。 池上彰の本とか、「カンブリア宮殿」の書籍版とかを読んでいた。

この辺り、社員の動かし方とか商品の売り方とかに興味が持てたのは、 自分は自社開発で、なおかつ小さい会社だったので、営業とか販売とかバックオフィスなどが、 自分がよく見れる範囲に存在していたからだったのではないかと思う。

そして、読書の範囲はソフトウェア開発方面まで広がる。
ふりかえると当時ターニングポイントになったのは 「オブジェクト指向でなぜつくるのか」だったと思える。
この書籍をきっかけに
・Java言語で学ぶデザインパターン入門
・リファクタリング
といった名著も読み漁り、テスト駆動開発/XP/アジャイルという概念を知ることになる。
当時はその他に、
レガシーコード改善ガイドや、 アジャイルソフトウェア開発の奥義など、ディープな書籍にも手を出したりしたが、 ほとんどきちんと理解できていなかったと思う・・・

このようなきっかけからか、この頃にはTeam Foundation Serverを使った自動ビルドや、 自動テストの実装にも着手を始めていた時期だった。

7年目〜9年目（2012年〜2014年）

iOSアプリ開発をきっかけに、デザインやユーザーインターフェースにも興味がわき、
当時はUI関連の書籍をよく購入していた。

辺りがとても面白かった。 アジャイル・サムライも2012年ごろに購入していて、
SCRUM BOOT CAMP THE BOOKも2013年頃。
仕事では実践する機会はなかったが、アジャイルへの「憧れ」は募るばかり。

また、この頃に業務でAWSを使用する機会があった。
クラウドコンピューティングにこのタイミングで触れることが出来たのは良いきっかけだった。

10年目〜12年目（2015年〜2017年）

10年目ということになり、引き続きメイン製品の保守開発でコーディングは行いつつ、リーダー的なポジションでマルチに動いていた。 要件定義、ビジネスパートナーさんとの調整・成果物確認、 リリース計画の管理と開発に関わることはすべて携わっていた。 採用面接などにも参加し、自分が採用に関わった人が期待通りに成果を上げてくれるのはとても嬉しい体験だった。
一方、辞められてしまうのもとても辛い体験だったが・・・ 。

開発チーム内の人数も増え、ソフトウェア開発はチームをうまく回していく事が非常に重要で難しいことであると理解し始める。 また、いわゆる企画・営業のビジネスサイドと、開発のエンジニアサイド間の協調にも悩んだ時期だった。
この辺りの軋轢がなぜ起こるかは、のちに「エンジニアリング組織論への招待」によって明確になったのだが・・・。 上記の問題を少しでも改善したく、Backlog上での要望・要求と要件とタスクの優先順位を明確にするルール作りなどを積極的に行っていた。

トム・デマルコのピープルウェアなど、
チーム・組織についての書籍に特に興味が惹かれる時期だった。

そして人の出入りも多い時期で、様々な経験を積んだ開発者の方たちと出会い別れていく中、 自分は1つの会社、1つの分野、1つの製品しか知らないまま、このまま時間が過ぎてしまっていってよいのか？ という思いが募り始める。

13年目〜現在（2018年〜現在）

前述の思いは消えず、35歳を迎え結婚・子の誕生・自宅の購入とライフイベントが続く中、 転職を決意。 2018年10月に新しい職場で働き始め、現在に至る。

ふりかえりのふりかえり

転職については後悔はないが、ここにきて今後のキャリアに迷いが出てきてしまった。

チャレンジしてみたい事はまだまだ沢山ある。 プロジェクトマネジメント・ピープルマネジメントのスキルを伸ばしていきたいのは一番だが、 プロダクトの企画も行ってみたいし、スクラムも実践する機会を得たい。

だが、このような願望が「自分はテック面のスキルが乏しいので、年齢ともにマネジメントに逃げているだけでは？」 という不安の表れではないかという思いにも囚われてしまっている。

さらに、1番の優先順位は家族との時間なので、仕事と家庭のバランスもどのように取っていくか。 何かを得るためには何かを捨てなければならない。 改めて自分の目的・目標を見直して行動をしていかなければ。

「Fukabori.fm エピソード13 ゲスト：twadaさん」を聴いて（主にテストに関する話）

Tech

最近通勤中はエンジニア向けのPodcastをよく聞いているのだが、

上記Fukabori.fmのtwadaさんゲスト回が学びが多すぎて、メモ的に記録しておきたくなった。

こんな貴重なお話がフリーで聴けるなんて、本当にありがたいことだ。

 

※自分の言葉と分けるためにPodcast上の話は引用で記載しているが、

  まんまPodcast内で話された言葉ではない。要約している。

 

『見られているだけでコードの質は高まる』

コードレビューがある=他人に見られているという意識ができるだけでコードの質は高まる。

なので、コードレビューのインフラに投資する。

RedmineでもGitHubでも、プルリクエストなどでコードレビューを行える環境を構築する。費用対効果は得られる。

ペアプログラミングの話から、コードレビューでも同様の効果はあるという話になって。

コードレビューは、導入してない状態からするとなった場合、費用対効果とかの話になっていきがちだなと感じていたが、コードレビューによって生まれる「意識」というのは盲点だった。

確かに後輩とか新人の方に、恥ずかしい・ダサいコードは見せられないなという気持ちはある・・・

『テストを書く場合、自PCにインストールできるものは本物を使い、できないものはモック／スタブを作る』

これもすごくスッキリした。

具体例でいうと、コード内でAWSのサービス、例えばS3などを使うというケースの場合、モック/スタブ化するのが良いというところなのかな。

自前のWebAPI等と絡むコードの場合、それは環境を用意できるので実物を使う、とか。

『プライベート関数はテストしない』

プライベート関数は、パブリック関数からテストできる。

プライベート関数は現状追認のテストになりがち。

リファクタリングを支えるテストにはならない。

プライベート関数、思いっきりテストしていた・・・

テストコードからはリフレクションで関数名を取得するので、

これはどうなんだろうと思いながらも・・・

ただ、言い訳としては関わっていたシステムがWindows Formのレガシーシステムで、パブリックからテストが困難なクラスが多く、

それでも機能追加を行っていかなければならないという状況で、

新規追加したプライベート関数はせめてテストしたい、という思いがあった。

が、今回「プライベート関数のテストは脆いテストになりやすい」というのを認識できた。

『UIのテストコードは書くけど、書きすぎない』

UI=Viewは変更が大きい部分。テストが失敗しやすい。

テストが失敗するからViewを変更したくないとう本末転倒な状態が生まれてしまう。

なので、よくやる方法としては、詳細なテストは書かない。ユーザーのシナリオレベルのテストを自動化＝CIで回していくようにする。

画面の構造が変わっても影響が少ない部分をテストする。

CIなどでスクショの変更前・変更後の差異を抽出して、それを人間が見て変わっている・変わっていないと判断するのも効果的。

画像の差分を取る技術は進化してきている。

 ちょうど今の現場のASP.Netのシステムで、Selenium導入してUIテスト自動化できればなと考えていたところだったので、非常に参考になった。

画像の差分を取る話については、以前Google内のテストの本でも見たことある。

『カバレッジは絶対値ではなく傾きで見る』

カバレッジは進捗など何らかの管理道具にすると、うまく回らない。

カバレッジは絶対値ではなくCIなどで「傾き」をみて、チームの健全性を図る指標にするのがよい。

カバレッジが高い状態から低い状態に推移ししている場合、テストコードが書かれなくなってしまっているのかもしれない。

低い状態から高い状態に推移ししてるなら、新しいコードにもテストが書かれていると取れると解釈できる。

この話も今後ぜひ参考にしていきたいなと感じた。

昨年在籍した現場ではカバレッジ100%が達成基準だったけど、

単発的な納品なシステムだったのでまあそういう選択肢もあり得るのかな。

ある製品を継続して保守していく、となった場合はこの考え方が良いと思う。 

 

 

初めてDockerに触れてみた

コンテナ技術を実際に手を動かして試してみたく、

以下のDocker入門　第一回〜六回に従ってチャレンジしてみた。

 

knowledge.sakura.ad.jp

 

自PCがMacなのでDocker For Macをインストールして試してみたが、

終わったあとにimagesとかのファイルを片付けるのが面倒なので、

Amazon EC2のインスタンス立ち上げてそこで実行していけば良かったなと、終わってみたらから思った。

 

ソフトウェアエンジニアは進化型（ティール）組織の夢を見るのか

Reading

「ティール組織」を読み終えた。 

ティール組織――マネジメントの常識を覆す次世代型組織の出現

ティール組織――マネジメントの常識を覆す次世代型組織の出現

 

概要

・人類は、意識が新たな段階に移動するたびに、新しい組織モデルを生み出してきた

・人類のパラダイムと組織の在り方は以下のように進化してきた
　・受動的（無色）

　・神秘的（マゼンタ）

　・衝動型（レッド）

　・順応型（アンバー）

　・達成型（オレンジ）

　・多元型（グリーン）

・そして、最も先進的な組織が進化型（ティール）

・ティール組織は以下のような特徴をいずれかあるいは全て備えている

　・自主経営（セルフマネジメント）：階層やコンセンサスに頼ることなく、同僚との関係性の中で動くシステム。

　・全体性（ホールネス）：だれもが本来の自分で職場に来ることができ、同僚・組織・社会との一体感をもてるような風土や慣行がある

　・存在目的：組織自体がなんのために存在し、将来どの方向に向かうのかを常に追求し続ける姿勢を持つ

 

ソフトウェアエンジニアに本書はためになるのか？

　本書では、著者が調査した実際のティール組織における活動や具体例も、数多く紹介されている。

（調査対象には日本のインターネット企業「オズビジョン」も挙げられている）

 

また、完璧な予測はせず、すぐに実行可能な解決策を狙い、新しい情報が入ればすぐに改善が図られるといったティール組織の意思決定プロセスは、リーン生産方式やアジャイル開発が核心にある、といった記述もある。

本書で紹介されているオランダの訪問看護組織ビュートゾルフの創業者は、スクラムの生みの親、野中郁次郎のファンであるという話も興味深い。

ソフトウェアエンジニアにとっては、従来型の組織構造から進化した組織の一つの形として、アジャイルな状態の組織がイメージしやすいのではないかと思う。

 

紹介されているティール組織のプラクティスの中でも、

　・チームミーティングのファシリテーション

　・階層を持たない代わりに存在する「コーチ」の役割

　・社員間の紛争の解決手続き

　・チームの価値観を共有するための組織慣行

　　（この中でオズビションの「Good Or New」というプラクティスに惹かれたが、今は終了してしまったらしい・・・参考：組織は変化し成長する。『ティール組織』に登場したオズビジョンの当時と今(やつづかえり) - 個人 - Yahoo!ニュース）

　といった内容は従来型組織におけるチームビルディングやマネジメントにも十分適用できるのではないかと思われるし、また著者は本書の後半で以下のようにも述べてくれている。　

 

　本書は、理論的なモデルや理想的なアイデアではなく、真似され、普及されることを待っている現実を取り扱っている。ここに示した事例を読んで、読者であるあなたや多くの人々が刺激を受け、「自分もやってみよう！」という気になってくれれば本望である。　

 

　今自分が所属している組織を、いきなりティール組織に変化させていくことが出来なくても、ティール組織のプラクティスを参考にして組織とそこに所属する人々のパラダイムを刺激することは十分可能なのではないか。