vm.boxでは, OSを指定する. 今回はubuntuの有力boxであるubuntu/trusty64を利用した.
vm.networkでは, VMが使用するIP, portを指定する.
VMとホストで通信するときはこのIP, PORTを利用する.
memoryやstorage, name, hostnameなどは適宜設定して欲しい.

VM上の環境を設定する

vm.provisionを使うことで, VM上の環境設定を行うことができる.
今回は, shellscriptを使って, 環境設定を行った.

config.vm.provision :shell, :path => "general_setup.sh", privileged: true
config.vm.provision :shell, :path => "rbenv.sh", privileged: false
config.vm.provision :shell, :path => "rails_practice.sh", privileged: false

vm.provision :shellとすることで, :pathに指定したスクリプトをshellscriptとして実行してくれる.
スクリプトの実行権限はprivilegedによって変更できる.
privileged: trueは, 管理者権限を表す. defaultはtrueである.

つまり, general_setup.shは管理者権限で実行され, rbenv.shは一般ユーザで実行される.

Vagrantでやることはこれだけ.
あとは, VM上で実行するコマンドをshellscriptに逐次書いていく.

shellscriptの書き方

注意したいのは, privilegedのtrue/falseに関係なく, ルートディレクトリがsuのルートになることだ. script内部でpathを指定する場合や一般ユーザでインストールを行ったソフトの実行は絶対パスを指定する必要がある.
※ 僕はこれでめっちゃハマった

僕のVagrantfileでは, 3つのscriptに設定手順を書いている. Vagrantfileに記述した順番にscriptを実行していく.
つまり, general_setup -> rbenv -> rails_practiceの順に実行されていく.

shellscriptの内容は上記のgithubShuzoN/rails_practiceを参考にして欲しい.

vagrantの基本コマンド

www.vagrantup.com

cmd	function
vagrant up	VMの起動, VMが存在しない場合はVM作成. 初回はprovision自動実行
vagrant halt	VMの停止
vagrant destroy	VMの削除
vagrant ssh	VMにSSHで接続
vagrant status	VMの状態を表示

vagrantを使ってみて

vagrantを使うことで, railsの環境設定を自動化した.

これまで環境設定にはかなりの時間を要してきた.
vagrantfileの共有だけでその問題が解決できるのはかなり便利だ.

あとは, もう少し効率的にやる方法を知りたいな...

2016-12-03

Vagrantについて勉強した

技術日記

vagrantとは

vagrantはVMを作成する手順を自動化するためのツールである.
vagrantで環境設定の自動化を行ったので, vagrantについてまとめていく.

www.vagrantup.com

vagrantでできること / できないこと

できること

VMを作成する時, 通常であれば手動でVMのOSやメモリ, ストレージを指定してVMの構築を行う. VM作成にあたって, このような手順を行ったとこがある人は多いと思う. これを手動で複数の環境で行うのはかなり面倒である.
zakkiweb.net

vagrantを使うことでこの作業を自動化することが出来る.
VagrantfileにVMの設定をあらかじめ記述しておけば, vagrantにファイルを読み込ませることでVMを自動構築してくれる.

Vagrantのうまみ

vagrantの旨味は, Vagrantfileを共有するだけで複数の端末上で同じ環境を作ることが出来ることにある.
githubでVagrantfileを共有すれば, みんな同じ環境で開発ができる.

ここについては以下の記事が詳しい.
knowledge.sakura.ad.jp

vagrantとサーバ設定ツールとの組み合わせ

vagrantはVMの作成だけでなく, VM上の環境設定も同時に行うことが出来る.
こういった事前環境設定をprovisioningというらしい.

ChefやPuppetといったサーバ設定ツール, shellscriptと組み合わせることで, VMの作成だけでなく, VM上の環境設定も同時に行える.

できないこと

しかし, vagrantだけでVM自体は作成できない.
VM環境はvirtualboxなど仮想環境構築ソフトが別途必要である.

vagrantの機能をまとめると...

vagrantは以下の2つを行えるツールである.

vagrantの機能
- VMの構築自動化
- VM上のプロジェクト環境構築自動化

2016-10-27

dockerが使うUnionFileSystemを僕なりに解釈した

技術日記

こちらも合わせてお読みください namu-r21.hatenablog.com

dockerのイメージとコンテナについて今一度

昨日書いた記事が運良くはてブに載り, 色々な方に見ていただけた.
namu-r21.hatenablog.com

そのおかげで, 有用なコメントを頂けた.

なんでファイルシステムの話なのにメモリの話とごちゃまぜになってるんだろ。　　
コンテナを終了したらメモリ上のデータは消えるが差分ファイルシステムの writable に書かれたデータは残る。rm すると消える。

このコメントを理解するために,　dockerが利用している
UnionFileSystemとCopy on Writeについて調べた.

僕なりの解釈を書いていこうと思う.

dockerのファイルシステム

dockerでは, Union File Systemを導入している.
これは, コピーオンライトで動作するファイルシステムである.

dockerのファイルシステムそのものについては公式の解説が特ににわかりやすい.
docker-doc イメージ、コンテナ、ストレージ・ドライバの理解

今回は,

コピーオンライト
UnionFileSystem
dockerにおけるUnionFileSystem
永続的なデータの保存

について掘り下げて書いていく.

コピーオンライトについて

先日のエントリdockerのファイルシステムについて知る - 1++では, 以下のように書いた.

コピーオンライトとは

"子プロセス生成時に親プロセスのメモリー空間を複製せず，書き込み処理が発生したときにはじめて複製する仕組み"である. 

このとき, 親プロセスのメモリ空間はRead onlyである.  

dockerでは, "イメージ"を親プロセス, "コンテナ"を子プロセスとして扱う. 基本的に "コンテナ単位でメモリ空間" が与えられる.

そもそもコピーオンライトとはなんなのか

コピーオンライトは, Copy on Writeと書く. 解説は, docker公式ドキュメントを引用する.
引用元 : docker-doc イメージ、コンテナ、ストレージ・ドライバの理解

コピー・オン・ライト（copy-on-write、cow）とは、共有とコピーのストラテジに似ています。

このストラテジは、システム・プロセスが自分自身でデータのコピーを持つより、同一インスタンス上にあるデータ共有を必要とします。

書き込む必要があるプロセスのみが、データのコピーにアクセスできます。
その他のプロセスは、オリジナルのデータを使い続けられます。

コピーオンライトは, 複数のプロセスが同時に動作するときに使用される, ストレージ共有の戦略である. つまり, これ自体はメモリだろうがファイルシステムだろうが関係無い.

データのコピーは非常に"重い"処理なため, その回数をできる限り減らすべく生まれたファイルシステムの最適化手法のようだ.

コピーオンライトではデータは無駄にコピーせず, 読み出しは共有領域から読み出す. 書き込みが必要な場合のみコピーして書き換える という挙動を取る.

このように, 書くとき(write)に初めてデータをコピー(copy)するから"Copy on Write"というらしい.

Union File Systemについて

UnionMountとUnion-type Filesystem(1),
まとめて束ねるUnionFSの不思議な世界を参考にした.

Unionとは, 合体という意味である.

僕の解釈ではUnion File Systemは, 複数のファイルシステムを階層的に合体させて, 1つのファイルシステムとして扱うことができるファイルシステムという理解で落ち着いた.

UnionFileSystemは, Unionマウントと呼ばれる特殊なマウント方法を取る.
その説明の前に, 通常のマウントから説明する.

その後, UnionFileSystemについて話したい.

通常のマウント

UnionFileSystemの前に, まずは通常のマウントについて考える.

f:id:namu_r21:20161027003900p:plain:w500

ここでは, /mntというディレクトリにdisc1(別名/dev/d1), disc2(別名/dev/d1)というディスクを順に1度ずつマウントする場合を考える.

2度実行した後, /mntの内容を確認すると, ユーザから見てdisc1のfileA, fileCは見当たらずdisc2のfileB, fileCのみが見える. つまり, 同時にマウントできるのは, 後にマウントした1つのディスクだけである.

Union マウント

UnionFileSystemでは, Unionマウント(以下Union)というマウントを行う.
これは, 同一のディレクトリから複数のディスクを1つのディレクトリとして透過的に扱うことができるようにするマウント方法である.

UnionMountとUnion-type Filesystem(1)を引用する.
以下のようにUnionFileSystemを表現している.

すでにディスクをマウントしているディレクトリ（マウントポイント）に別のディスクを重ねてマウントし、1つのマウントポイントから2台のディスクを同時に使用可能にするもの

f:id:namu_r21:20161027003927p:plain:w500

Unionを利用すると, 1つのディレクトリ上に3つのファイルが存在するように見える(fileCは同名なため1つとしてカウント). つまり, 実際には2つのディスクをマウントしているにもかかわらず, "見かけ上"は1つのディスクを扱っているように見える.

Unionでは, ディスクを階層的にマウントしていく. このため, 上記したように"別のディスクを重ねる"という表現になる.

実際には複数のディスクをマウントしているため, 複数のディスク上に同名のファイルがある場合問題がおきる. そのため, 常に上位レイヤのディスクを優先して読み込む.

図の場合, /dev/d2が上位, /dev/d1が下位ディレクトリである. fileCが同名ファイルであるが, この場合は, /dev/d2のfileCが読み出されることとなる.

Union File System

Union File Systemは, Unionを利用したファイルシステムである.

Unionを行う場合, 下位ディスクをRead-Only, 上位ディスクをwrite/readに設定することが一般的である. 最上位のディスクをwritable状態にして, ユーザにファイルシステムを提供する.

f:id:namu_r21:20161027003958p:plain:w500

下位ディスクのデータをReadする必要がある場合はそのまま下位ディスク上のデータが読まれる.
下位ディスクのデータに対して, 書き込みを行う必要がある場合は, Copy on Writeを行う.

Writableディスクに対象データをコピー
Writableディスク上で対象データを編集
Writableディスク上に対象データを保存

前述したように, Unionでは常に上位レイヤのディスクを優先して読み込む.
そのため, 最上位ディスクに保存することでデータを上書きしていくことができる.

dockerにおけるUnionFileSystem

冒頭でも行ったようにdockerはUnionFIleSystemを利用している.

dockerでは, イメージ用のディスクがRead-onlyなファイルシステムであり, その上にWritableなコンテナ用のディスクが重ねられる.

docker イメージとコンテナにおけるコピーオンライトの関係

図はdocker-doc イメージ、コンテナ、ストレージ・ドライバの理解より引用.

docker runでイメージからコンテナを起動した時点では, コンテナ・レイヤには何も記録されてない.

コンテナ上でファイルの"読み出し"を行う場合は, イメージ・レイヤの共通ストレージからデータ読み出しが行われる. このレイヤは, Read-onlyなため書き換えはできない.

対して, イメージ・レイヤの既存データに対して変更を加えた場合, 1度コンテナ・レイヤに対象データがコピーされそのデータを書き換えることになる.

その変更はイメージからの変更差分のみを記録する.
これがUnion File Systemの特徴である.

コンテナ内の状態変化はコンテナ・レイヤで閉じていて, 他のコンテナや大元のイメージには影響しない .

同じイメージから複数のコンテナを作った場合, コンテナごとにコンテナ・レイヤが用意される.
このため, コンテナ同士が互いに干渉せず, 複数の同環境で多様なオペレーションを行える.

僕のなかでdockerのイメージはこう解釈した.

dockerにおける"イメージ"は, 
"ベースイメージ(ファイルシステムの初期状態)に対する
ファイルの変更差分を階層的に記録した「ファイルシステムそのもの」"

コンテナは以下のような感じ.

イメージがもつファイルシステムを引き継いだ
変更部分のみを保持する固有のストレージを持つ1つの実行環境.

dockerコンテナのライフサイクル

先日のエントリdockerのファイルシステムについて知る - 1++では, 以下のように書いた.

  dockerでは, イメージを元に"コンテナを作ったり消したりする"できることが特徴であり, 
「コンテナは使い捨て」という感覚で使われることが多い. 

コンテナはこのように"生き死に"を繰り返すので, 
「コンテナのライフサイクル」と呼ばれる.  

そして, "コンテナ上のメモリ空間はコンテナの終了とともに消える". 
つまり, コンテナ上でのファイル追加, 変更は"永続的に残らない"のである.

この部分についてもコメントでご指摘をいただいたので加筆. mapk0yさんのコメントを引用させていただきます.

コンテナを終了したらメモリ上のデータは消えるが差分ファイルシステムの writable に書かれたデータは残る。rm すると消える。

どうやら, docker rmでコンテナを削除するまでは, コンテナのwritable上にファイルが残るようだ. つまり, コンテナを削除しなければ, コンテナ上にデータは残る.

では, 永続的にデータをどうやって残すか.

コンテナのライフサイクルに関わらず永続的に残したいデータがある場合は, 以下の方法を取る.

データボリュームを利用する.
現在のコンテナをイメージとしてcommitする(非推奨)
データコンテナを利用する(推奨)

データ・ボリュームの利用

これは, ホストOS側にデータを記録する方法である. これをデータ・ボリュームと呼ぶ.
データ・ボリューム docker docs 公式和訳が詳しい. コンテナの起動時にホストOSのディレクトリ(データボリューム)をコンテナ起動時にマウントする. これによって, ファイルシステムの一部としてデータボリュームを利用できる.
.

現在のコンテナの状態をイメージとしてcommitする(非推奨)

dockerでは, コンテナのスナップショットをイメージとして吐き出すdocker commitというコマンドがある.

つまり, これまでコンテナ・レイヤだったストレージをイメージに含んでしまうのである.

これは元のイメージをある1つの環境に依存して汚してしまうため, お勧めできない方法である.

docker データ・コンテナ

最もお勧めできる方法は, データコンテナであるようだ. この方法では, 以下の手順をふむ.

データボリュームをマウントしたデータ保存用のコンテナ(データコンテナ)を1つ作る.
他のコンテナにデータコンテナをマウントする

データコンテナのメリットは以下のようなものだ

データボリュームをrmするまでは, 永続的にデータが残る.
複数のコンテナから同一のデータを参照できる.
1つでも参照されているボリュームがあると, rmによるコンテナ削除ができない.

つまり, 1つのコンテナと存在するものの,
データコンテナとして参照され続けている間は
削除の対象にならない.

dockerを通してUnionFileSystemを勉強してみた所感

ファイルシステムがある種, "一方向のバージョン管理"のような仕組みを取られていて衝撃的であった.
きっちり記憶領域が分かれているから, "コンテナ間が依存しない"ということがわかった.

加えて, "データボリューム"周りの話についても, 以前より理解が深くなった.

dockerの永続的なデータ保持方法を知りたくて, 調べ物を始めたけれど
気づいたらファイルシステムの話をしていた.

まだまだ仮想環境やOSの話はわからないので学ぶことが多い.
今はvagrantの勉強をしているので, 次はそちらについて書く.

2016-10-25

dockerのファイルシステムについて知る

技術日記

こちらも合わせてお読みください

namu-r21.hatenablog.com
namu-r21.hatenablog.com

dockerのイメージとコンテナについて今一度

先日書いたdockerを触ってみる - 1++で，イメージとコンテナについて以下のように述べた.

イメージとコンテナについて

* イメージ : 仮想環境の雛形
* コンテナ : イメージから作られた実際の仮想環境

今一度調べていくとこの表現はあまり正しくない.

dockerイメージは, 雛形ではなかった .

dockerイメージは, ファイルシステム全体の状態を保持したスナップショットと表現した方が正しい. OS(ファイルシステム), アプリケーション, 内部のデータまでを写真で切り取ったかのように全て記録した状態がイメージである.

dockerコンテナとは, そのdockerイメージを動作させたものを指す.

つまり, dockerを利用すると, 任意の環境を別の環境で完全再現できる .

dockerで作ったローカル環境イメージをサーバ上に持って行き, そのイメージをdocker runするとコンテナとしてそのまま動作する.

dockerのファイルシステム

dockerでは, Union File Systemを導入している.

これは, コピーオンライトで動作する. コピーオンライトとは子プロセス生成時に親プロセスのメモリー空間を複製せず，書き込み処理が発生したときにはじめて複製する仕組みである. このとき, 親プロセスのメモリ空間はRead onlyである.

dockerでは, イメージを親プロセス, コンテナを子プロセスとして扱う.

基本的に コンテナ単位でメモリ空間 が与えられ, その変更はイメージからの差分のみを記録する. コンテナ内での状態変化はコンテナで閉じていて 大元のイメージには影響しない .

dockerのファイルシステムに関しては,
今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。,
Dockerライフサイクルの基礎地雷を踏み抜けろ!
が視覚的かつ丁寧に説明している. こちらを参照してほしい.

dockerでは, 1つのイメージが複数のイメージによって階層的に構成されている. dockerでは, それぞれのイメージが逐次実行されていく.

docker Union File System from docker document

図はdocker documentから拝借した. この図ではDebian, emacs, 最後にApacheサーバのイメージを順次適応している.

そして, それらを順番に実行していったものがコンテナであり, コンテナはその階層の一番上にメモリ空間(writable)を持つ. コンテナが利用できる記憶領域はこの部分である.

dockerコンテナのライフサイクル

dockerでは, イメージを元にコンテナを作ったり消したりするできることが特徴であり, 「コンテナは使い捨て」という感覚で使われることが多い. コンテナはこのように"生き死に"を繰り返すので, 「 コンテナのライフサイクル 」と呼ばれる.

そして, コンテナ上のメモリ空間はコンテナの終了とともに消える.

つまり, コンテナ上でのファイル追加, 変更は永続的に残らない のである.

docker データ・ボリューム

では, 永続的に残したいデータはどうやって記録するのか. dockerでは, ホストOS側に記録することでこの問題を解決している. これをデータ・ボリュームと呼ぶ.
データ・ボリューム docker docs 公式和訳が詳しい. ホストOSのディレクトリをコンテナ起動時にマウントする. これによって, ファイルシステムの一部としてデータボリュームを利用できる.

dockerを勉強してみた所感

dockerは, ファイルシステムごと環境をスナップショットするという点でかなり便利だ.
docker imageさえあれば, 環境設定なしでクローン環境を作ることができる.

また, ブログで触れてはいないが, Dockerfileを書くことで環境設定を自動化することもできる. これには, 手順を明文化できるというメリットもある.

ただ, サークルで利用するというところを考えた時に, ちょっと抵抗がある.
dockerの仕組みは通常のファイルシステムと少し違う部分があるので, 感覚を掴んでもらうまで少し時間がかかりそう.
vagrantの導入を考えてみる.

2016-10-15

dockerを触ってみる

技術日記

こちらも合わせてお読みください

namu-r21.hatenablog.com namu-r21.hatenablog.com

動機

サークルで環境設定が面倒くさいと言われたので, dockerで提供することにした. infrastructure as codeをやってみたくて勉強中.

dockerとは

色々なサイトで説明されているので, 詳細はそちらに譲る.
Dockerイメージの理解とコンテナのライフサイクル
 docker what is docker? (公式)
Docker入門
 2016年版、Dockerのすべてが5分でわかるまとめ!(コマンド一覧付き)

仮想環境界隈におけるdockerの立ち位置についてはDocker入門がかなりわかりやすかった.
dockerの用語解説は2016年版、Dockerのすべてが5分でわかるまとめ!(コマンド一覧付き) が分かりやすい.

僕自身の理解では dockerは,

ホストOSのカーネルを利用して, 仮想環境をホストOS上の1プロセスに見立てて実行するツール

という風にとらえている.

f:id:namu_r21:20161015123905j:plain
2016年版、Dockerのすべてが5分でわかるまとめ!(コマンド一覧付き) より引用させてもらう.

Dockerは内部的にサーバクライアントで動作している. 仮想環境はDockerサーバ上で動作する. そのため, 仮想環境を立ち上げたり, シャットダウンしたり, 仮想環境内に入ったりするためにはDockerサーバに命令を送らなければならない. これらはDockerコマンドで操作することができる.

イメージとコンテナの違い

「dockerはイメージを基にコンテナを生成し, 仮想環境を提供する. このためコンテナ型仮想環境と呼ばれる. 」とどこのサイトにも書いてあったが初めは意味がわからなかった…

僕のなかでの理解では, 以下のように整理した

イメージ : 仮想環境の雛形
コンテナ : イメージから作られた実際の仮想環境

プログラムソース(イメージ)があって実行するとプロセス(コンテナ)が立ち上がる, という風に言い換えるとわかりやすいかもしれない.

そして, イメージは異なる環境上に持っていっても, dockerさえあれば動くようになっている.
つまり, 作成したイメージを異なる環境に渡すことで「環境を移植, 共有」することができる.

イメージとコンテナに関してはDockerイメージの理解とコンテナのライフサイクルが視覚的に説明してくれている(3Dの図すごい).

imageのイメージが湧かない点について

dockerのイメージは「仮想環境の雛形」といった.

docker hubと呼ばれるdockerイメージのホスティングリポジトリにはruby, rails, mysql, nginx, ubuntu, centosなど多くのimageが存在する.

が, とりあえず何らかのosが存在しないと動作のしようがない.

ruby, railsなどのイメージは, 何らかのOS上に名前に対応するパッケージをインストールしたイメージを生成し, 共有してくれているようだ.

勉強したての頃は「なぜOS無しでrubyやnginxが動くんだ!?」と思っていたけど, 当然の結果であった;(

もちろんubuntuやcentosも使えるようだが, dockerではalpineという非常に小さいlinux osを使うことが多いように見受けられた.

おわりに

とりあえず, dockerの概要については理解できた. 次はDockerfileだな….

2016-09-22

技大祭を終えて4 統括

日記

1年前の自身と比較して

1年前の自分はどうだっただろう.
あまり記憶にないが, 覚えている限りでは次のような感じだったと覚えている.

Webやりたいけどどこから手を出せば良いか不明
8月のインターンで初めてRailsのアプリを作成するも実装大失敗
研究室のネットワーク管理を任せられたものの意味不明

自身でもきっと変化のある1年だったと思う.
試しに書いてみよう.

技術的には以下のようなことについて学んだ.

小規模なネットワーク構築の技術
ネットワークの基礎的な知識の習熟(OSI L2~L4)
Ruby on RailsによるWebアプリの構築
DBの初歩的理解と設計スキル
ホームページ作成の初歩的なスキル
githubによるコードの管理とチーム開発手法
Herokuによるサービスのインターネット公開
- test, production環境を分けて安全に保守
先方との仕様策定と実装仕様の判断

リーダとしては以下を意識的にやっていた

局で頻繁に飲み会をやる
教育(勉強会を主催)
メンバーの能力の把握
タスク分散
タスクの管理

執行部としては以下のことを意識的にやっていた

他局長と仲良くなること
分散した議題を視覚化して一旦の整理をつける役目
議題の目的, 目標を明確化する役目

1個人として

希望だったWebベンチャー起業に内定(5月)
圧倒的断髪(7月 : 大失敗)

全体を通してみると, 結構いろんな変化があるなぁ.
決定的に, 1年前より圧倒的に「自信」を持って行動しているような気がする.

叶えば叶う, 望めばもらえる, やればできる, できるできるできる

そう思い続けてきた1年だった.
そして, 「チャンス」を失うのはいつも「自分」がきっかけだと気付いた.

短期間でこれだけの変化ができる,
1年で変われると知ることができた1年だった.

1年の学び

< 技術面 >

1 テスト

テスト書いてないとか@t_wadaさんの前で言えない…
(内定先のテスト界隈の著名人)

チーム開発, 特にWebアプリのようにIOや操作が多いのものは
特にテストが欲しいなぁと感じた1年だった.

結局勉強も実装もできてないので,
後輩に負の遺産を残すことになったm( )m

2 Webの基礎知識

8月に内定先のインターンに参加し愕然とした.
インターンはGoを使ってWebアプリを作るという内容であった.

そして僕は全然ついていくことができなかった.
Railsの知識だけでは全くWebアプリは作れないのである.
(RailsはWebアプリを作るために設計された便利機能群と思えばいい)

Railsでは, RESTが何か, Cookie, Sessionが何か, 美しいURI設計とは何かを知らなくても簡単にWebアプリが作れる. それは全てrailsのコマンドがやってくれるからである.

これは一見便利であるし, そして怖さでもある.

ツールに任せず, ちゃんと基礎を理解していくことが大切だと知れた.

とはいえ, それを気づかせてくれたのは,
技大祭内でのRailsの経験があったからに他ならない.

Webアプリを触るのであれば,
少なくとも「Webを支える技術」は読むべき本だと思う.

3 先方との仕様策定と実装仕様の判断

情報局は基本的に総務局の要望を聞いて, 必要な機能を実装する. 僕は要望を聞き, 仕様を決める役目を1年間担わせていただいた.

おかげさまで, 人のイメージ, やりたいことを聞く能力はかなり高まったと思う. 反面, 個人的な遊びや誕生日祝い決めるときにもガチでしつこく聞いてしまうようになったので, 諸刃の剣であった(汗)

< チーム面 >

1 結果的に飲み会が少なかった

情報局のほとんどのタスクは, slackというチャットツールとgithubで仕事が完結する. githubに仕様が書いてあり, 詳細な質問はslackで担う.

今時のリモート開発ってやつだ(ドヤ).

とはいえ, 顔を合わせていない人と仕事を円滑に進めるのは難しい.
相当仲が良くない限りはチャットで冗談をいったりしない.

だから, 僕は4~6月かなり飲み会を重視していた.

情報局員との飲み会は, 技大祭の活動中で屈指の楽しみだった. いつも「作る飲み会」にすることを密かにテーマにして楽しんでいた. ハンバーグを1から作ったり, 団子を作ったり, 時々ラーメンに行ったり.

後悔が残るのはやはり7月以降でスケジュール的にあまり飲み会を開けなかったことである. 学部3年, 4年の僕が好きだった「技大祭」は頻繁に飲み会が開催される場であった.

その僕が, 自局の新入生たちに「技大祭」らしい楽しみを提供できなかったことをとても悔やんでいる.

2 教育

これはもう既に技大祭を終えて2 情報局長としてに書いた.

大きな学びは, 「わからなくても仕事を投げた方が結果として伸びる」ということ. 逐一全て教える時間はない. だから, その人の能力を理解して「ちょっとだけ無理をする」程度のタスクを投げ続けること. それがもっとも早く伸びる方法だと知れた.

そして, 教育者として最も大事なことは「自分は相手がわからない時に助けられる人間として存在し続ける」こと. 自分が教える彼らよりも3倍は早く先に行かなければならない. そう学べた.

後輩に教えるために資料をいっぱい作ったこと, いろんな方法で教えたことは活動の中でもかなり楽しかった. 自分が知っている知識, やり方をどうやって彼らに伝えるか, 目で見てわかるようにするか, ここを考え続けるのは楽しい作業だった.

3 タスク管理

タスクの管理について, 正直ガバガバだった. そして, それが原因で大失敗した.

総務局は団体管理を行うために大量の資料を作成する. そしてそれらは毎年50, 60団体分を生成する必要がある.

そこで, 第2, 3回参加団体説明会向けに「書類出力機能」の実装依頼を受けた. そして, それらの機能は実装され提供された.

が, それらは実際使われることなく今年度が終わった.

なぜ使われなかったかというと, 「要求する機能が期日に間に合わなかった」のである. ソフトウェアを開発していると, 「一見動いているようで動いていないバグ」が結構頻繁に起こる. このバグ修正が期日に間に合わなかったのだ.

私の局では, 僕と実装担当者が目視確認によるチェックを行い，ステージ環境にデプロイすることにしていた(テストを書けという話). そして, ステージ環境にデプロイ後, 総務局にチェックを受けるという形であった.

大体は期日前にバグが見つかり, 修正によって上がるのは2日後. その時点では遅いということがあった.

これは, 技大祭を終えて2 情報局長としてにも書いたように,

情報局の全ての仕事は自分のタスクだと思う. そして, 自分のタスクを「時間をもらってやってもらっている」と考える. 常に仲間に感謝を忘れない. という心がけに反している.

せっかく作ってもらった機能が日の目を見ないことはすごく淋しいことである.
もう少し早く期日を設定し, しっかりとバグ修正期間を取れば実稼働に耐えうる出来のものばかりであった.
この部分に関しては, 僕の管理不足, 読みの甘さとしか言いようがない.

局員には本当に, 本当に申し訳ないことをしたと思っている.

サービスは「タイミング」によって全く使ってもらえないということが身にしみてわかった.

< 執行部 >

多すぎて書けないかもしれない.
かいつまんで書いていこう.

自ら辞めることは成長機会を捨てていることと同義
自分ではなく, 組織, 1つのチームとして何を生むかを考える
組織として価値を出すとき, 「仲のよさ」が重要
価値を出す領域の違いを理解することの大切さ

上2つに関しては技大祭を終えて3 執行部の1員としてにもう書いたのでいいだろう.

1 組織として価値を出すとき, 「仲のよさ」が重要

ここは情報局, 当日を過ごして肌で感じたものである.

なぜ「仲のよさ」が大事かというと, 「質問の生まれやすさ」が変わるのである.
仲がいい人であれば気軽に聞けるし, あまり知らなければ聞きに来ない.

情報局では, slackを使ったコミュニケーションをとっていた.
仲のいい後輩は質問をしてきたが, あまりFace to Faceで話していない後輩は仕事を頼んでもほとんど質問が来なかった.

つまり, 便利なツールの導入だけでは解決できないのである.

また, 技大祭当日は運営本部が設営され当日運営の中枢を担う.
このとき, 問題発生や, ちょっとした質問をしにくる人間は普段から部室に顔を出しているメンツであった.

運営において「意見がくる, 質問がくる」というのはとても大切な要素である.
自分に情報を伝えてくれる人間がいるということは, 自分自身が存在しない空間の情報を取得できるということである.
これは自分をスケールアップ, 分身させていることを意味する.

いかにスムーズに情報をとり, 目的達成をするかにおいて「仲のよさ」はかなり重要な要素だと気づけた.

だから, 普段の飲み会は本当にバカにできないしこまめに連絡を取ることの大切さを知った.

2 価値を出す領域の違いを理解することの大切さ

そんなの当たり前ですよね. でも, 意識するのは難しいと気付いた.

7局の局長は「局」レベルでそれぞれ違う役目を持って構成されている.
それだけでなく, 組織運営していく上で「キャラクター」というのはとても大切なんだと知れたのは技大祭にいたからだろう.

今年度は,

委員長が全体統括のマスコット
副委員長が事務管理とバランサー
総務局長, 広報局長, 財務局長/副局長が論点把握
渉外局長が理論的に飛んだ部分の穴埋め

以下略
を担当していたように思う.

それだけでなく, 「雰囲気作り」という点でかなり個性的な人間が委員長, 副委員長, 局長/副局長に就いていたためバラエティに富んでいてよかった.

それぞれ担うべき分野, 得意な分野, 苦手な分野が違う.
だからこそ, 網羅的に, 多面的に物事が進む.

自分にしか提供できない価値もあるし,
他人にしか提供できない価値もある.

自分だけではほんの少しの価値しか出せないということに気づけた.

そして, それぞれがそれぞれの価値を出していることは組織として動く中で強く意識しなければならないと学んだ.

執行部の彼らと過ごす時間は基本的にはすごく楽しい時間であったし,
だからこそ後悔の多いものとなった.

技大祭を終えた気持ち

技大祭は片付け日である9/19(月)で一旦の区切りであった.
執行部としては, 次期執行部の選出を行うまで継続となるし, 情報局の引き継ぎもまだあるが気持ちとしては不思議な喪失感がある.

1年間(実質半年)日常として存在していた技大祭が終わったのか, そうか, と確認するようにこの数日(執筆は9/22(木))を過ごしていた.

立ち返ってみると, 6月末に執行部から自ら身を引いた時点で, 技大祭とは一定の距離を置くような立場として過ごしてきたように思う.

執行部としての立場の反面, 自身のタスクがある中でも情報局長としてチーム先導やHPの管理はやっていたつもりであるし, そこにはかなり強い面白みを感じてやっていた.

7, 8月にもっとコミットしていればもっと広い視野, もっとたくさんの思い出ができたのかもしれない, もっと大きな価値を提供できたのかもれない, と, 後悔が多々ある.

とはいえ, 自分のやってみたかったことは大体できたし, 想像していた領域を超えて色々挑戦ができた.

この1年, 研究はあまり進んでいないけど(汗)，決して無駄な時間とは思わない.
むしろ, 情報局長として過ごすことができてよかったと感じている.

最後に

僕を局長に選んでいただいた山仲さん, 芦田さんには頭が上がりません. お2人のおかげで多くの経験をさせていただきました. ありがとうございます.

執行部の皆様には大変ご迷惑をおかけしました. そしてありがとうございました.
総務局長, 副委員長, 渉外局長, 広報局長/副局長と一緒にいた時間は特に楽しかったです. ありがとう.

そして, 最後に情報局として働いていただいた皆さん, 総務局長, 阿部, 林, 木村本当にありがとうございました. 1年楽しく, そして, 成長できる環境を与えていただけたことに感謝しています.

1年間ありがとうございました.

2016-09-22

技大祭を終えて3 執行部の1員として

日記

執行部としての活動期間

執行部として活動したのは正味5ヶ月もなかったかもしれない.
10月に発足し, 11~3月中旬までは参加していない.
そして, 7月頭からは自身のことでほぼ参加していない.
つまり, 僕が執行部として活動したのは2015/11, 2016/3, 4, 5, 6月だけである.

執行部としての立ち位置

技大祭を終えて1に

技大祭では「局長」位にいる人間は自動的に全体の意思決定を行う「執行部」に所属することになる.

と書いた.

執行部では, 技大祭にまつわるほぼ全ての決定を行う.
学祭のテーマに始まり, おおよそ300万ほど(だっけな?)の予算分配, 企画運営, 会場管理, 団体管理, 外部団体誘致, 企業協賛, 装飾を執行部で決定する.

僕が所属する情報局の主な任務は「団体管理のツール作成」と「外部への情報公開」だけなので, 他局に比べかなり比重が軽い.
その上, 執行部は学部3~4年生で構成されているので, 修士2年の僕は少し年上になる.

そのため, 初めは「僕は意思決定に参加しない」という条件で執行部に参加していた.

退屈な会議

執行部に入った僕を待っていたのは,
11時間も続く会議, いまいち目的がわからない議案,
何も決っていないのにフェードアウトしていく議案,
終わらないドッグファイト(ただの言い争い).

ずっと同じ密室空間に束縛されて結論が出ないことを考え続けること, しかも何も発言できない状態は非常に苦痛だった.

多少, 学生団体に参加していたため
会議のやり方を少しだけかじっていたのも相まっていたのかもしれない.

自分も相手も執行部未経験なので人のことは言えないはずし, 初陣が最初に踏むべき必要な段階だと今思えばわかる.
当時の自分は -いや, 多分今の自分でもキツイと思うだろうが- 我慢ならないものであった.

口を出し始めた時期

就職が落ち着き, 段々と執行部に顔を出すことが多くなった.
修士2年の同期で, 技大祭に精通している同期がいたため, 「虎の威を借りる狐」のごとく, 大きい顔をして会議で口を出し始めた.

4,5月は自分の力でなんとか会議をよくしよう, 本気でいい学祭を作ろう, そう思い自分自身のタスク(研究とか授業)をないがしろにしながらコミットしていた記憶がある.

反面, 見ればなんとなく結論が見える(決まらない結末も含め)議案に対して, 議案に至るまで何時間もかかる会議にうんざりしていた.
自分自身の意見を求められると釣られたように意見が通ってしまう雰囲気にとてもうんざりしていた.

今思えば, 当時の自分の態度は奢りでしかないし, 「自分がどう思うか」ではなく「全体として何をするか」を優先すべき場面が多くあったと思う.

なおかつ, 議案を自分が提出しているわけでもない.
会議において「議案」はとても重要で, これがしっかりしていれば決まるし, これがあいまいだと「議案」の定義に終始して終わらない会議が始まる.
つまり, 当時の僕は自分では何もやっていないのに「頑張っている人間を責める」立場にたっていた. 議案を決めていた2人は会議の数日前に必ず夜中まで残っていた. ここは, とても申し訳ない.

「邪魔者」だと認識した時期

そして, 6月頃には司会の立場を担っているはずの副委員長よりも先に議論を止め, 好き放題ものを言っていたと記憶している. 6月頃は, 踏み込み過ぎたアクセルのように空転を繰り返していた.
本気でやろうとすればするほど, 孤立し空回りしていた.

段々, 「今思えば」が枕詞になってきた気がする.
今思えば, 僕が司会をやってしまっているのだから, 後輩は司会がうまくなるはずがない.
加えて, 僕がいることで発言に恐怖がつきまとうし, 「ディスカッション」を邪魔している. あと, 2,3つ上の先輩に強く意見できるはずもなく, 正しくない意見も通ってしまっていた.

例えば, 僕が言いだしたgmail移行, google driveの採用は結構簡単に会議を通過したように記憶している.

当時は本気で必要だと思い導入した(好奇心がないとは言い切れない)が, それらは結果的に執行部の仕事を増やしていた.

「執行部」としての立場を捨てたきっかけ

元々, 「技術」について興味があり局長になったという部分は前の記事でご理解いただけていると思う.

執行部として過ごしている中で,
段々と「害」になっている自分,
「全体運営」に対する興味が薄れている自分,
「局の仕事, 執行部, 研究, 内定先のタスク」と自分自身のタスクが多すぎて処理できずにいる自分
に気づき, ストレスフルな日々が続いた.
そして, 段々と「当日」が自分のなかで現実的なものとなり, 「情報局長」としての立場でできることの少なさに気づいた時期もこの頃であった.

要約すると「本心から興味がない部分に長時間を消費されること」に心底嫌になっていた.

そして6月末に, 自分の価値観の中で一番優先度の低い「執行部」を切り捨てることに決めた.

今思えば, 好きなことだけをしようとあまり好きでないものを切り捨てただけのように感じている.

執行部を離れた7, 8月

7月は, 8月頭にある中間発表に向けた研究と内定者に与えられたWebアプリの開発に明け暮れていた.
とはいえ, 執行部に行っていない罪悪感はもちろんあり, 反面, 好きなことをして過ごしている開放感の間にいた.

8月は, 中間発表を終えてから, 内定先に行き3週間のインターンの手伝いをしていた. そこで学ぶことは多かった. 専門的に今の自分に何が足りていないか, どういうものを目指して勉強すればいいのかを知れた. 内定者, インターン生, 社員との交流の中で, 来年就きたい部署のイメージが湧いた.

7, 8月は多くの経験, 思想を学んだし, 多くの遊びを経験したし修士2年として過ごし方そのものは決して間違っていなかったと思っている.

その犠牲として, 6月末からはほぼ執行部に参加していない.

浦島太郎として帰宅した9月

インターン手伝いを終え, 9月に帰ってきた自分は当たり前であるが「執行部」として全く機能しない人間となっていた.
そして, 自身も技大祭について知らないことが多すぎるため, 執行部としてのモチベーションも全くなかった. そのくせ, 最後の最後に参加したミーティングでは昨年度の経験を振りかざし「6月の自分」の立場で物事を発していた.
当然, 他の局長からの信頼は完全になくなっており, 全くの「役立たず」として当日を迎えた.

圧倒的な能力差を感じた準備日, 当日1日目

準備日, 当日1日目を過ごした僕は「圧倒的な能力差」を感じた.

この2ヶ月間,
僕は「僕のために」時間を使い,
彼らは「技大祭を良くするために」時間を使ってきたのだから当然であった.

彼らは「技大祭として提供できること」を考えて行動していた.
僕は, 「自身 / 情報局として提供できること」という狭いスケールの中でしか物を判断できていなかった.

当日1日目にOBが言っていた言葉で印象的な言葉がある.

「技大祭実行委員会は, 参加団体, 来てくれるお客さんが居て初めて存在している. 参加団体がお店を出し, 演舞をしてくれるから初めて魅力的な学祭が生まれる. それを忘れて, 参加団体に対して上からの目線で指図するのはお門違いも甚だしい. 俺らは参加団体, お客さん全てに気持ち良く学祭を過ごしてもらう. そこに全力でやることが仕事や. それを理解せずに, 適当にやってそれなりのことやってればいい, ってやつは辞めてしまえ. 本当に好きならそんなことできないはずや. 」

適当にやってそれなりのことやってればいい

まさに, これが9月, 準備日, 当日1日目の僕だった.

準備日は総務の仕事をこなしてから4時に就寝.
当日1日目は, 何もできない自分に打ちひしがれて執行部最速で帰宅した.

当日2日目と片付け日

当日1日目で挙がった点として,

晴天雨天の切り替えや企画中止を掲載する緊急掲示板が存在しない.
突発的な資料作成がかなり多く必要である.

というものがあった.

情報局としては,

HPに事前に用意していた緊急連絡ページに掲載する
緊急連絡をTwitterに投稿する
突発的な資料作成の全般を情報局員で担う

という対処を行なった.

これで十分に役目を果たせたとは全く思っていないが, 来年に向けた局員への意識付けはうまくできたと判断している.

片付け日は無心で撤収作業をしていた.

執行部として参加していて感じたことと失敗

執行部の皆さんにはとても感謝している.

僕に裁量を与えてもらい

slackというチャットツールの導入
gmailへの移行
google driveの採用

と50人を超える組織に対する新しいチャレンジをさせていただけたこと.
決して成功だったとは言えないが, 貴重な失敗をさせていただけたのは執行部の方々がいたからだと本心で思っている.

そして, こんなにも勝手で好きなことしかしていない僕に, 打ち上げで感謝の言葉をくれた子もいた.

執行部として1年を過ごし, 当日を経験して強く思ったことは,
1個人であっても「技大祭という組織として提供できること」を
考え続けることが必要だったということ.

僕は局長期間中ずっと, 「技術で提供できること」,「自身の能力で提供できること」を追求し続けていた.
そして, 知らない間に「いい技大祭」を提供するためではなく,
「良いWebアプリを作ること」, 「ツールでより便利な環境を作ること」といった
「手段」が目的になってしまっていた.

そして, 最終的には何のために活動してるのか分からなくなってしまっていた.

この2ヶ月は非常にもったいないことをしたとおもっている.
執行部として, 技大祭として提供できることを考え続けていれば
もっと多くのものを執行部のみんなと共有し,
もっと良い「技大祭」を提供できたのだろう.

結局は僕のおごり, 僕自身の判断で機会を断ち切ってしまった.

自分自身で「チャンス」を断ち切ってしまったことが執行部として活動していて一番の失敗であった.

そして, 最後に,
この記事では自身の本心, 反省, 後悔を書いているので良い事があまり書かれていない.
が, 彼らと過ごした約半年間の活動は本当にとても楽しかったと思っている.
彼らとラーメンに行ったり, 部室でくだらないことを話したり, ひたすら真剣に会議したり.
彼らと活動できて良かったと思っているが, 途中で自ら身を引いた自分が言う立場ではないだろうな.

執行部の皆さん1年, ありがとうございました. 本当にいっぱい失敗させていただきました.