｢Walter｣を試していたのでまとめた

Walterは, Goで書かれた｢ビルドパイプライン｣ツールです.

JenkinsなどでCIを行う場合, 複数のジョブを連携して, 一連の処理の流れを作ることがあります. これを｢ビルドパイプライン｣と呼び, Jenkinsにはビルドパイプラインを作る為のプラグインが幾つか提供されています.

Walterは, Jenkinsに依存しない形で, ｢ビルドパイプライン｣をよりシンプルに, かつコードで指定出来るようにしたツールです(Jenkinsで｢ビルドパイプライン｣を設定する場合, 大抵ブラウザでJenkinsをポチポチする必要があります...).

詳しくは,

• walter/README.md
• Walter ファミリーの紹介 at Shibuya.go#1
• シンプルなビルドパイプラインツールwalterをリリースしました | Advanced Technology Lab

などなど参考にしながら, 実際に手を動かしながら試してみるのが良さそうです.

インストール

というわけで早速インストールしましょう. WalterはGo製のツールであり, ワンバイナリで動作します.

バイナリは, Walterのリポジトリで配布されているので, ここからダウンロードするのが手っ取り早いでしょう. Linux系の64bit OSであれば, ｢walter_x.x.x_linux_amd64.tar.gz｣でOKです.

また, Homebrewでインストールすることも可能です:

$ brew tap higanworks/homebrew-walter-binary 
$ brew install walter

問題なくインストールできれば, walterというコマンドが利用可能になります. これで準備OKです.

設定ファイル: pipeline.yml

Walterは, pipeline.ymlという設定ファイルを利用します.

pipeline:
  - name: command_stage_1
    type: command
    command: echo "hello, world"

pipeline.ymlを設置したディレクトリで, walterコマンドを実行すると, この設定に従って処理を実行してくれます(-cオプションで, 任意のYAMLファイルを利用することもできます).

$ walter
11:34:30  INFO Pipeline file path: "./pipeline.yml"
11:34:30  INFO not found "require" block
11:34:30  INFO not found "service" block
11:34:30  INFO local client was created
11:34:30  INFO not found messenger block
11:34:30  INFO not found cleanup block in the input file
11:34:30  INFO running Walter
11:34:30  INFO Starting Walter in local mode
11:34:30  INFO Preparing to run pipeline process...
11:34:30  INFO [command] exec: command_stage_1
11:34:30  INFO [command_stage_1][command] exec output: hello, world
11:34:30  INFO Finished running pipeline process...
11:34:30  INFO Preparing to run cleanup process...
11:34:30  INFO Finished running cleanup process...
11:34:30  INFO succeded to finish Walter

pipeline.ymlで指定したコマンド(単なるechoですが...)が, ここで実行されていることがわかります.

11:34:30  INFO [command] exec: command_stage_1
11:34:30  INFO [command_stage_1][command] exec output: hello, world

処理の逐次実行

次のように記述すれば, 処理を逐次(上から順番に)実行することができます.

pipeline:
  - name: command_stage_1
    type: command
    command: echo "hello, world"
  - name: command_stage_2
    type: command
    command: echo "こんにちは世界"

実行すると, 次のようになります:

11:37:53  INFO Pipeline file path: "./pipeline.yml"
11:37:53  INFO not found "require" block
11:37:53  INFO not found "service" block
11:37:53  INFO local client was created
11:37:53  INFO not found messenger block
11:37:53  INFO not found cleanup block in the input file
11:37:53  INFO running Walter
11:37:53  INFO Starting Walter in local mode
11:37:53  INFO Preparing to run pipeline process...
11:37:53  INFO [command] exec: command_stage_1
11:37:53  INFO [command_stage_1][command] exec output: hello, world
11:37:53  INFO [command] exec: command_stage_2
11:37:53  INFO [command_stage_2][command] exec output: こんにちは世界
11:37:53  INFO Finished running pipeline process...
11:37:53  INFO Preparing to run cleanup process...
11:37:53  INFO Finished running cleanup process...
11:37:53  INFO succeded to finish Walter

command_stage_1の後に, command_stage_2が実行されていることがわかります.

処理の並列実行

次のように記述すると, 幾つかの処理を並列に実行することができます.

pipeline:
  - name: parallel command
    parallel:
      - name: parallel 1
        type: command
        command: sleep 1
      - name: parallel 2
        type: command
        command: sleep 2
      - name: parallel 3
        type: command
        command: sleep 3

こうすると, parallel下に設定した3つの処理が, 同時に実行されます. もし, これを逐次実行した場合は6秒(1 + 2 + 3)のスリープになりますが, 並列に実行した場合は3秒で終了するはずです. というわけで, timeコマンドを使って処理時間を確認してみます.

$ time walter
11:39:04  INFO Pipeline file path: "./pipeline.yml"
11:39:04  INFO not found "require" block
11:39:04  INFO not found "service" block
11:39:04  INFO local client was created
11:39:04  INFO not found messenger block
11:39:04  INFO not found cleanup block in the input file
11:39:04  INFO running Walter
11:39:04  INFO Starting Walter in local mode
11:39:04  INFO Preparing to run pipeline process...
11:39:04  INFO [command] exec: parallel command
11:39:04  INFO [command] exec: parallel 1
11:39:04  INFO [command] exec: parallel 2
11:39:04  INFO [command] exec: parallel 3
11:39:07  INFO Finished running pipeline process...
11:39:07  INFO Preparing to run cleanup process...
11:39:07  INFO Finished running cleanup process...
11:39:07  INFO succeded to finish Walter
walter  0.01s user 0.03s system 1% cpu 3.043 total

3.043 totalということで, 確かに3秒で処理が終わっていることがわかります.

この並列処理の利用シーンですが, 例えば, carton installによるCPANモジュールのインストールと, npm installによるJavaScriptのライブラリのインストールを並列実行して, ビルドにかかる時間を節約する, といった使い方が出来ると思います.

コマンド実行時のオプション

1つの処理(Walterでは｢ステージ｣と言うそうです)の設定には, 次のようにオプションを指定することができます:

pipeline:
  - name: command_stage_1
    type: command
    only_if: test -e file.txt
    directory: dir
    command: cat file.txt

directoryは, そのステージで設定されたコマンドを実行するディレクトリを, only_ifはそのステージで設定されたコマンドを実行する条件(前提条件)を意味します.

例えばこの場合, only_if及びcommandで設定されたコマンドは, directoryで指定したdirというディレクトリをカレントディレクトリとして実行されます.

そして, only_ifでtest -e file.txtをしているので, このタスクはdirディレクトリ内にfile.txtが存在する場合のみ実行されるようになります.

まず, 失敗例から.

$ walter
11:46:49  INFO Pipeline file path: "./pipeline.yml"
11:46:49  INFO not found "require" block
11:46:49  INFO not found "service" block
11:46:49  INFO local client was created
11:46:49  INFO not found messenger block
11:46:49  INFO not found cleanup block in the input file
11:46:49  INFO running Walter
11:46:49  INFO Starting Walter in local mode
11:46:49  INFO Preparing to run pipeline process...
11:46:49  INFO [command] only_if: found "only_if" attribute in stage "command_stage_1"
11:46:49  INFO [command] only_if: command_stage_1
11:46:49  WARN [command] only_if err: exit status 1
11:46:49  WARN [command] exec: skipped this stage "command_stage_1", since only_if condition failed
11:46:49  INFO Finished running pipeline process...
11:46:49  INFO Preparing to run cleanup process...
11:46:49  INFO Finished running cleanup process...
11:46:49  INFO succeded to finish Walter

only_ifでerr: exit status 1になっており, これによってexec: skipped this stage "command_stage_1", since only_if condition failedとなっていることがわかります.

次に, ｢Hello, walter!｣という内容のファイルをdirディレクトリ内部にfile.txtとして設置して実行してみます.

$ walter
11:51:36  INFO Pipeline file path: "./pipeline.yml"
11:51:36  INFO not found "require" block
11:51:36  INFO not found "service" block
11:51:36  INFO local client was created
11:51:36  INFO not found messenger block
11:51:36  INFO not found cleanup block in the input file
11:51:36  INFO running Walter
11:51:36  INFO Starting Walter in local mode
11:51:36  INFO Preparing to run pipeline process...
11:51:36  INFO [command] only_if: found "only_if" attribute in stage "command_stage_1"
11:51:36  INFO [command] only_if: command_stage_1
11:51:36  INFO [command] exec: command_stage_1
11:51:36  INFO [command_stage_1][command] exec output: Hello, walter!
11:51:36  INFO Finished running pipeline process...
11:51:36  INFO Preparing to run cleanup process...
11:51:36  INFO Finished running cleanup process...
11:51:36  INFO succeded to finish Walter

先ほどと異なり, only_ifでエラーになっておらず, 正しくコマンド(cat file.txt)が実行され, それによってexec output: Hello, walter!になっていることがわかります.

｢ステージ｣が失敗した場合

もし, ステージで設定されたコマンドが失敗した場合, その時点で全ての処理が中断します.

例えば, 次のpipeline.ymlでは, 最初のステージで存在しないfailed_commandというコマンドを実行しようとしています.

pipeline:
  - name: command_stage_1
    type: command
    command: failed_command
  - name: command_stage_2
    type: command
    command: echo "hi!"
  - name: command_stage_3
    type: command
    command: echo "hi! hi!"

これを実行すると,

$ walter
11:55:09  INFO Pipeline file path: "./pipeline.yml"
11:55:09  INFO not found "require" block
11:55:09  INFO not found "service" block
11:55:09  INFO local client was created
11:55:09  INFO not found messenger block
11:55:09  INFO not found cleanup block in the input file
11:55:09  INFO running Walter
11:55:09  INFO Starting Walter in local mode
11:55:09  INFO Preparing to run pipeline process...
11:55:09  INFO [command] exec: command_stage_1
11:55:09  INFO [command_stage_1][command] exec output: sh: failed_command: command not found
11:55:09  WARN [command] exec err: exit status 127
11:55:09 ERROR [command] exec: failed stage "command_stage_1"
11:55:09  WARN Execution is skipped: command_stage_2
11:55:09  WARN Execution is skipped: command_stage_3
11:55:09  INFO Finished running pipeline process...
11:55:09  INFO Preparing to run cleanup process...
11:55:09  INFO Finished running cleanup process...
11:55:09  INFO more than one failures were detected running Walter

このように, exec output: sh: failed_command: command not foundでステージの実行が失敗していて, これによってExecution is skipped: command_stage_2そしてExecution is skipped: command_stage_3になっていることがわかります.

クリーンアップ

パイプラインの一番最後(処理が最後まで終了したか, そうでないかに関わらず)に行う処理は, cleanupで指定できます.

pipeline:
  - name: command_stage_1
    type: command
    command: touch file.txt
  - name: command_stage_2
    type: command
    command: ls
  - name: command_stage_3
    type: command
    command: echo "hi!"
cleanup:
  - name: cleanup
    command: rm file.txt

このように記述すると, command_stage_1で作成したfile.txtというファイルを, 一番最後に削除してくれます.

$ walter
11:57:30  INFO Pipeline file path: "./pipeline.yml"
11:57:30  INFO not found "require" block
11:57:30  INFO not found "service" block
11:57:30  INFO local client was created
11:57:30  INFO not found messenger block
11:57:30  INFO found cleanup block
11:57:30  INFO running Walter
11:57:30  INFO Starting Walter in local mode
11:57:30  INFO Preparing to run pipeline process...
11:57:30  INFO [command] exec: command_stage_1
11:57:30  INFO [command] exec: command_stage_1
11:57:30  INFO [command_stage_1][command] exec output: file.txt
pipeline.yml
11:57:30  INFO [command] exec: command_stage_2
11:57:30  INFO [command_stage_2][command] exec output: hi!
11:57:30  INFO [command] exec: command_stage_3
11:57:30  INFO [command_stage_3][command] exec output: hi! hi!
11:57:30  INFO Finished running pipeline process...
11:57:30  INFO Preparing to run cleanup process...
11:57:30  INFO [command] exec: cleanup
11:57:30  INFO Finished running cleanup process...
11:57:30  INFO succeded to finish Walter
$ ls
pipeline.yml

command_stage_1でlsを実行したタイミングでは, file.txtが存在しますが, walterコマンドによる処理が終了した後にlsで確認すると, cleanupでfile.txtを削除しているので, pipeline.ymlしか残っていないことがわかります.

まとめ

Walter, 他にもHipChatやSlack, Githubとの連携などなど, いろいろ機能があるのでこちらも試してみたいなーと思っています.

MackerelのAmazon Linux対応に対応していて軽くやらかした話

3月28日から, MackerelはAmazon Linuxの正式サポートを開始しました: Amazon Linuxの正式サポートについて - Mackerel ブログ #mackerelio

これに伴って, Amazon Linuxにおけるmackerel-agentのインストール方法が変更されたので, 某サービスでも早速対応していたのですが, そこでちょっと軽くやらかしたというか, 凡ミスをしたのでシェアします.

結論

mackerel-agentのインストールにおいて, 別途, /etc/mackerel-agent/mackerel-agent.confにAPIキーを書き込む処理をしているのであれば, ｢sudo mackerel-agent init -apikey={{MACKEREL_APIKEY}}｣は実行しなくてもよい.

詳細

先ほどのブログでは, 新規インストールの手順について以下のように紹介されています.

curl -fsSL https://mackerel.io/file/script/amznlinux/setup-yum.sh | sh
sudo yum install -y mackerel-agent
sudo mackerel-agent init -apikey={{MACKEREL_APIKEY}}
sudo /sbin/service mackerel-agent start
※`{{MACKEREL_APIKEY}}`はRead/Write権限のあるAPIキーを指定する

さて, 某サービスでは, mackerel-agentを含むミドルウェアなどのインストールは, Packerを使ってAMIを作る際に行う, という仕組みになっています. これまではmackerel-agentのインストールに関する処理を, 次のように書いていました:

# 従来のインストール方法で`mackerel-agent`をインストール
curl -fsSL https://mackerel.io/assets/files/scripts/setup-yum.sh | sh
yum install -y mackerel-agent
yum install -y mackerel-agent-plugins
yum install -y mackerel-check-plugins

# 設定ファイルの生成
mkdir /etc/mackerel-agent/conf.d
cat >> /etc/mackerel-agent/mackerel-agent.conf <<'EOF';
apikey = "MACKEREL_APIKEY"
EOF

というわけで, ブログ記事に従って次のように書き換えました:

# Install Mackerel
curl -fsSL https://mackerel.io/file/script/amznlinux/setup-yum.sh | sh
yum install -y mackerel-agent
mackerel-agent init -apikey={{MACKEREL_APIKEY}}
yum install -y mackerel-agent-plugins
yum install -y mackerel-check-plugins

mkdir /etc/mackerel-agent/conf.d
cat >> /etc/mackerel-agent/mackerel-agent.conf <<'EOF';
apikey = "MACKEREL_APIKEY"
EOF

...まあ, もうオチはお分かりだと思います.

｢mackerel-agent init -apikey={{MACKEREL_APIKEY}}｣は/etc/mackerel-agent/mackerel-agent.confに指定したAPIキーを記載するコマンドなので, その後に手動でAPIキーを/etc/mackerel-agent/mackerel-agent.confに記述するようにしていると, /etc/mackerel-agent/mackerel-agent.confにAPIキーが(同一ではあるものの)2回現れることになり, mackrel-agentをうまく起動することが出来ませんでした.

...というわけで, 結論に至る次第です. ちょっとした凡ミスですが, 皆様もお気をつけ下さい.

頼りがいのある(かもしれない)Database Migration Utility, Anegoを作っています

PerlでWebAppなどを作っている際, データベースのマイグレーションをするのであれば, 例えば@sugyanさんのブログに書かれているSQL::Translator::DiffでDBスキーマに追従させる方法のような手段を使ったり, 或いはこれと同じくSQL::Translator::Diffに基づいたGitDDLやGitDDL::Migratorなどを使う手があると思います.

この辺りの方法を参考にしながら, Reactioなどでは独自のマイグレーションの仕組みを作って実践しているのですが, だいぶ安定して使えているし, そろそろ他のプロジェクトでも使いたくなってきたので, モジュールとして切り出してみることにしました.

なお名前は, Kansai.pmでAnegoのプロトタイプコードに様々なアドバイスを下さった@karupaneruraさんとそのORM｢Aniki｣に敬意を表して(?), ｢Anego(姉御)｣にしました.

使い方

AnegoはDBIx::Schema::DSLを使うようになっているので, まずはアプリケーションのスキーマをDBIx::Schema::DSLを使って記述します:

package MyApp::Schema;
use strict;
use warnings;
use utf8;

create_table 'user' => columns {
    integer 'id', primary_key, auto_increment;
    varchar 'name';
};

1;

あとは, このように操作することができます:

use strict;
use warnings;
use utf8;

use Anego;

my $anego = Anego->new(
    connect_info => [ ... ],
    schema_class => 'MyApp::Schema',
);

# スキーマのビルド
$anego->build;

# 最新のスキーマと現在のデータベースのスキーマとの差分を表示
$anego->diff;

# 最新のスキーマへのマイグレーションの実行
$anego->migrate;

次のように, Daikufileなどと組み合わせるといいと思います:

namespace db => sub {
    require Anego;

    my $anego = Anego->new(
        connect_info => [...],
        schema_class => 'MyApp::Schema',
    );

    task build => sub {
        $anego->build();
    };

    task diff => sub {
        $anego->diff($_[1]);
    };

    task migrate => sub {
        $anego->migrate($_[1]);
    };
};

buildをすると, .dbディレクトリにスキーマの情報が保存されていきます. diffやmigrateをする際にバージョンとして指定することで, 現在のデータベースのスキーマと, 過去の任意のスキーマについて, 差分を表示したりマイグレーション(ロールバック)したりすることもできます.

$ ls .db
1458563116.sql
1458710980.sql

# 現在のデータベースのスキーマと, 1458563116.sqlにおけるスキーマの差分を表示する
$ daiku 'diff[1458563116]'

さっくり作った段階ですので, ご意見ご要望ご指摘などお待ちしております. よろしくお願い致します.

久々のKansai.pmでライブコーディングをしてきました

久々のKansai.pmである, Kansai Perl Mongers 第16回ミーティングが開催されたので参加してきました. 前回の開催が約3年前, 確かJPAの講師派遣制度で@yusukebeで来られた時だったと思うので, だいぶ久々だなあ, と思います.

当初は, ｢PerlのWebApp開発におけるの新たなスタンダード〜Aniki+Amon2〜｣というタイトルで, 最近気に入っているORM｢Aniki｣を使ったWebApp開発の話をしようと思っていて, 直前に開催されたキッカソンでデモアプリを作ろうとしていたのですが, WebAppのデータベースの準備をするあたりで｢これまで書いてきたマイグレーション周りのコード, ライブラリ化してまとめたいな...｣という気持ちが高ぶって来て, 最終的にはそのへんをライブコーディングで作っていくか, という所に落ち着きました.

今回の資料... というかライブコーディングの前説はこちら.

ちなみに, ライブコーディングしながら開発していたライブラリは, 当初は｢Aniki::Migrator｣という名前にしていましたが, Aniki専用という訳でもないので, ｢頼りになるMigrator"Anego"｣として作っていくことにしました.

...LTで, いいところを全部持って行った@karupaneruraさんにアドバイスいただいた所もちゃんと含まれています.

今回, 久々に関西地方にお住まいのPerl Mongerの方々とお会いできて楽しかったですし, 最後には｢次のKansai.pmは8月までに!｣という声も挙がったので, 次も是非参加したいですね!

他のチームに｢技術的支援｣をする時に気をつけていること

自分が働いているGaiaxのように, 社内に複数の事業があり, それぞれにエンジニアが所属して働いている場合, ｢ねえ, ○○のチームの××って仕組み, どうやってるの? うちのチームでもやってみたい!｣といったコミュニケーションから, 他のチームに対して｢技術的支援｣をする機会が生まれる事が多々あります.

最近の例だと, 社内の新規事業の立ち上げや, オンプレからクラウドへの移管のタイミングで, Infrastructure as Codeやデプロイ施策, ChatOpsなど整えたいので, 相談に乗って欲しい! という声を何度か頂いた事がありますし, よくよく考えると今やっているPhotosynthへの留学も, 見方を変えれば｢Photosynthへの技術支援｣と言えるかもしれません.

そういった｢技術的支援｣をする時に気をつけている事についてFacebookにつぶやいた所, 思ったより反響があった(ような気がした!?)ので, 備忘録として, そして自戒としてブログにも綴っておこうと思います.

｢自分のこだわりや考えを, 一方的に押し付けない｣

何かしらの｢技術的支援｣をするということは, そこに｢支援する人｣と｢支援される人(チーム)｣という関係が生まれます(なお, 以後"支援する人"を"支援者", "支援される人(チーム)"を"支援先"と呼ぶことにします). そして, 支援をする｢何らかの技術領域｣において, 支援者は支援先よりも深く取り組んでいて, 一日の長があるはずです(だからこそ, その知見を活かすべく支援先は支援者に技術的支援をお願いするからです).

そういう時に, 気をつけないとやってしまいがちなのは, 支援者が過去の経験から導いた解決策(支援先に存在する課題を解決するための手段)を, 一方的に支援先に押し付ける, というやり方です.

このような技術的支援がうまく成果に繋がるパターンも多々あると思います. しかし, 場合によっては支援先の課題を解決するはずの技術的支援が, 支援先に新しい課題を生み出しているパターンがあると思います.

1つは, 支援者が提案した解決策が, 支援先が使っている言語, フレームワーク, ミドルウェア, インフラ, ツールなどの文化や慣習に則っていないパターンです. この場合, 支援先が支援者の解決策をそのまま鵜呑みにして実施していったところ, 支援先で既に利用している何かしらの技術的要素の文化や習慣に則っていないが故に, 新しい別の問題が生じてしまう, という結論に行き着きがちです.

もう1つは, 理想と現実の壁が出来上がるパターンです. 支援者が一方的に解決策を押し付ける場合, その解決策は支援先の現在の状況(支援先が利用している技術的要素に加え, 開発しているプロダクトの特徴であったり, そのチームの文化, 状況, 習慣であったり...)が考慮されていないパターンが多いはずです. そうなってしまうと場合, 支援先は支援者が提示する解決策(理想)と, 今の支援先の現状(現実)のギャップが大きすぎて, 解決策を実現する為に大きなコストを捻出しなければならなくなるはずです.

...また, 日本人は｢変化を嫌う｣とよく言われます. ｢変化を嫌う｣事に対する是非はともかくとして, このような大きなギャップを乗り越えに行こうとすると, チームの中でも賛否が別れる可能性は容易に想像出来るのではないでしょうか.

ここで支援者が解決策の実現を強行すると(例えば, 支援者が実際に手を動かして実装を始める, など), 言うまでもなく支援先の理解や納得のないまま作業が進んでいきます. 大抵, このパターンは中途半端な結末に終わる事が多いです.

例えば, 解決策の実現が中途半端に終わってしまうパターンもあるでしょうし, 無事完成まで至ったとしても, それが支援先に引き継がれない(使われない, 有効に利用されない)という事もあるでしょう.

｢支援者｣が気をつけるべきこと

ここまで, 技術的支援をするときに, 支援者が｢自分のこだわりや考えを, 一方的に押し付け｣た時に, 支援先に与えてしまう可能性のある悪影響について述べてきました.

ここでは, 逆にこれを防ぐ為に支援者はどのような取り組みができるのか? というところについて, 現時点の気付きを述べたいと思います.

...といっても, それは難しい事ではなく, ｢自分のこだわりや考えを, 一方的に押し付ける｣の反対のことをすればいいだけだと思っています. すなわち, ｢自分のこだわりや考えを活かしつつ, 支援先と解決策を一緒に考える｣ではないでしょうか.

支援者が成し遂げるべきは, ｢支援者の理想を支援先に実現させる｣ではなく, ｢支援者の支援によって, 支援先の業務が最大効率で回るようにすること｣です(但し, この2つがイコールになる場合もあると思います).

そのためには, 解決策を示す前に, 支援先の現状と課題をしっかり調査し, 理解に努めなければなりません. そして, そこから単純に解決策を提示するだけでなく, 一旦提示した解決策に対する反応を受けて, 更に解決策をブラッシュアップしていく必要もあるでしょう.

更に, 解決策はなるべく複数のフェイズに分離して, 少しずつ進められるように構築する方が良いでしょう. 言い換えれば, 支援先の課題を細かく分離して, 1つずつ解決していくように道筋を作るべきです. こうすることで, 支援先はその解決策によってどのような問題が解決され, どのようなメリットを得られるかが理解しやすくなります. 加えて, 一度に大きな変化を実現する場合と比べると, 細かい変化を繰り返す方が, その変化にかかるコストの見積もりもやりやすくなるでしょう.

まとめ

ここまでの話をざっくりまとめると, 技術的支援をするにあたって大切なのは, 支援する技術に対する知見だけではない, ということです. 何かしらの技術的支援をするエンジニアには, 支援先に対してより良い解決策を示せるようにするための工夫が求められます. その1つが｢支援者と支援先の相互理解｣であり, そのためにしっかりコミュニケーションを取り, 信頼関係を育んでいく事が大切, ...だと, 個人的には思っています.

いずれどこかのタイミングで詳しくお話しようと思いますが, GaiaxのRNDに新しく｢Delivery Support Team(仮)｣というチームが出来ることになりました. このチームは, ｢エンジニアが開発したサービスと, そこからの生まれる価値を顧客に"届ける"｣, という行為を｢Delivery｣と称して, そのために必要な全ての技術的要素(例えばCI環境の整備, デプロイフローの構築, ChatOps, Infrastructure as Code, IaaS/PaaS移行支援, ミドルウェアの導入/移行支援, チューニング, などなど...)を支援するチームです.

4月からは, この｢Delivery Support Team｣としての活動, すなわち他のチームへの技術的支援が業務の主になってくるので, ｢自分のこだわりや考えを活かしつつ, 支援先と解決策を一緒に考える｣を胸に刻んで取り組んでいきたいと思っています.