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 documentから拝借した. この図ではDebian, emacs, 最後にApacheサーバのイメージを順次適応している.
そして, それらを順番に実行していったものがコンテナであり, コンテナはその階層の一番上にメモリ空間(writable)を持つ. コンテナが利用できる記憶領域はこの部分である.
dockerコンテナのライフサイクル
dockerでは, イメージを元にコンテナを作ったり消したりするできることが特徴であり, 「コンテナは使い捨て」という感覚で使われることが多い. コンテナはこのように"生き死に"を繰り返すので, 「 コンテナのライフサイクル 」と呼ばれる.
そして, コンテナ上のメモリ空間はコンテナの終了とともに消える.
つまり, コンテナ上でのファイル追加, 変更は永続的に残らない のである.
docker データ・ボリューム
では, 永続的に残したいデータはどうやって記録するのか. dockerでは, ホストOS側に記録することでこの問題を解決している. これをデータ・ボリュームと呼ぶ.
データ・ボリューム docker docs 公式和訳が詳しい. ホストOSのディレクトリをコンテナ起動時にマウントする. これによって, ファイルシステムの一部としてデータボリュームを利用できる.
dockerを勉強してみた所感
dockerは, ファイルシステムごと環境をスナップショットするという点でかなり便利だ.
docker imageさえあれば, 環境設定なしでクローン環境を作ることができる.
また, ブログで触れてはいないが, Dockerfileを書くことで環境設定を自動化することもできる.
これには, 手順を明文化できるというメリットもある.
ただ, サークルで利用するというところを考えた時に, ちょっと抵抗がある.
dockerの仕組みは通常のファイルシステムと少し違う部分があるので, 感覚を掴んでもらうまで少し時間がかかりそう.
vagrantの導入を考えてみる.
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プロセスに見立てて実行するツール
という風にとらえている.
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だな….
技大祭を終えて4 統括
1年前の自身と比較して
1年前の自分はどうだっただろう.
あまり記憶にないが, 覚えている限りでは次のような感じだったと覚えている.
自身でもきっと変化のある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年間ありがとうございました.
技大祭を終えて3 執行部の1員として
執行部としての活動期間
執行部として活動したのは正味5ヶ月もなかったかもしれない.
10月に発足し, 11~3月中旬までは参加していない.
そして, 7月頭からは自身のことでほぼ参加していない.
つまり, 僕が執行部として活動したのは2015/11, 2016/3, 4, 5, 6月だけである.
執行部としての立ち位置
技大祭では「局長」位にいる人間は自動的に全体の意思決定を行う「執行部」に所属することになる.
と書いた.
執行部では, 技大祭にまつわるほぼ全ての決定を行う.
学祭のテーマに始まり, おおよそ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年, ありがとうございました. 本当にいっぱい失敗させていただきました.
技大祭を終えて2 情報局長として
情報局長としての始まり
局長になったきっかけは昨年の技大祭2日目. 前部門長と発足のきっかけとなったドクター先輩と3人で話をして, 僕が局長に選ばれた. 同期に非常に優秀で人柄が良い人間がいたので, そちらになるだろうとタカをくくっていたのでかなり驚いた記憶がある.
不安はかなり大きかったが, やってみたいと思えたし, 勉強になると思ったので引き受けた.
個人としての挑戦
僕はこの1年で結構な数の挑戦をしていると思う. 自分で言うのもなんだけど. そして, 1年前は途方もなく無知だった.
僕個人として挑戦を書いてみよう.
- ほぼ初めてのWebアプリ作成
- 初めてのチーム開発
- 開発リーダ 兼 プログラマ
- 初めてのHP作成
- ネットワーク素人
- 意思決定組織への初参加
- 就活との並列
つまり局長になった時は, 情報局長に求められることの9割について僕は何の知識もなかった
高専の情報科出身で情報専攻の修士1年のくせにIPアドレスがなにか正確に説明はできなかったし, 市販のルータもまともに設定できない人間だった.
Webアプリの前に, ホームページと何が違うの? サーバクライアントってなに？ データベースてつまるとこなに？チーム開発とかどうやんの？ってレベルであった.
こう文字に起こすと強く思うが, ドクターの先輩や前部門長がなぜ僕を選んだのかわからない笑
今は, それなりに人に教えてそれなりに求められたものを作っていられるので, 1年で幾分かの成長はしたのだろう.
とりあえず, 1年前の9月はそんな感じのスタートであった(苦笑)
就活との兼ね合い
僕はM2なので局長期間中に就活があった. 大体11月末~4月末が僕の就活時期だった. 幸い僕が希望するWeb業界は3~4月がシューカツのピーク期だったためかなり早く内定がもらえ, 選定の時間も多く取れた. つまり, 一般的な人(6月start)よりは早く日常にシフトできた.
9,10月はアプリの仕様会議をして一旦活動を休止. 大体11月末あたりから就活を始めて, 初めての内定は3/1だった. そこで一度安堵したあと, 3月半ばあたりから情報局の仕事を本格的に始めたと記憶している.
内定先を決めた4月末までは就活をしながらプログラムを書いていた記憶がある. 面接の前に先輩に質問したり, 新宿のカプセルホテル, 渋谷のカフェでコード書いた日々が懐かしい. たった半年前とは思えない.
この頃は楽しくコード書いてた記憶があるので, いい現実逃避のツールだったのかもしれない笑
とはいえ, 作るべき機能があったり, 面接で話す材料としてのネタとして必死にやってたと思う(うる覚え).
情報局長としての挑戦
個人としての話は上記の通りだが, 情報局長としての挑戦も書いておこう.
余談だが立場が変われば, 挑戦の範囲も変わると知れたのも学びの1つだった.
- 局として初のチーム開発
- 参加団体アプリとホームページの同時運営
箇条書きだと2つしかないのか. 意外と少ない.
個人的にはこの2つがとても大変だった.
局として初のチーム開発 と リーダとしての失敗
あくまでも僕の主観でしかないので, 僕から見たチーム開発について書いてみようと思う.
これまでの情報部門は参加団体アプリ, HPともに1人が1つのプロダクトを担当, 管理していた. つまりモノはあっても, ノウハウが完全に個人に蓄積している状態だった.
そのため, 僕自身としても局としてもチーム開発のノウハウが全くない状態からのスタートであった.
<プログラマ ≠ チームリーダ>
はじめはチームとして動くどころか, 既存アプリの主旨すらよくわからなかった.
とりあえず, 創設開発者であるドクターの先輩からアプリの主旨を教えてもらいながらひたすら「総務局」に求められたコード書き続けた記憶がある. 3~4月のこと.
正直この頃が一番きつかったが, 目に見えてモノができる楽しさにのめり込んでいった記憶がある. ひたすらプログラミングが楽しかった.
この頃に読んでいた本を書いておこう
こう見るとWebの本ほぼ読んでないな(汗)
アプリで使用しているRailsに関しては, とりあえず基礎を抑えてから アプリのコードを見てひたすらリファレンスを引いて読んだ記憶がある.
でもこれは, 「1人のプログラマ」としての役割でしかない.
「チームリーダ」として動くためには「アプリ全体の理解, タスクの分解, タスクの難易度設定, タスクの優先度設定, タスクの分散, チームメンバの理解度/能力把握/教育」とやることがいっぱいある.
小難しいので言い換えると「コードを書く」のがプログラマであり, そうではなく「他人がコードを書くために何が大事でそれを誰にどう頼むか考える」のがチームリーダの役目である.
つまりチームリーダは, 「1人のプログラマ」として動けることは大前提として, 「ふさわしい人間を選ぶ」ことも必要だし, 不足する能力があるのであれば適宜教育も必要だということである.
こうやって書くと仕事だよね, これw
というわけで, 4~6月は第1,2回参加団体説明会までに作らないといけない機能の実装とともに, githubの使い方とかチケット駆動開発のやり方, 局内でのRails勉強会に時間を割いた記憶がある.
7,8,9月は研究と内定先のタスクで色々カオスで記憶が薄い笑
とはいえ, 勉強はしていた. 勉強になった本を書いておこう.
- チームギーク
- Webを支える技術
僕の代は優秀な人間が3人いたので, かなり甘えていた部分がある. 僕があやふやな仕様書いて, 僕が求める形で機能が実装されて返ってきていたのだから, もう感謝しかない.
<チームビルディングの心がけと失敗>
やってみないとわからないもので, チーム開発は以下の4点を守れば僕の場合うまくいっていた.
- 総務局が求める仕様をかなり詳細に聞く. 言い漏らし, 確認し忘れは事故の元. わからないことは速攻で確認する.
- 詳細な仕様を書く. 言葉に揺らぎを持たせない. できるだけ視覚化する. 目的と背景を伝える.
- 仲間を信じる. 感謝と尊敬を忘れない. 出来で判断せず, やったかやってないかだけを評価する. 仲間ができないときは自分も考える. タスクごとに責任者を決める.
- 情報局の全ての仕事は自分のタスクだと思う. そして, 人にタスクを譲るのではなく, 自分のタスクを「時間をもらってやってもらっている」と考える. 常に仲間に感謝を忘れない.
詳しくはチームギークに譲る. 超良書なのでエンジニアは特に読むことをお勧めする.
心がけてはいたが, 完璧ではないと思うこともいっぱいある.
なんでレビュー書いてくれないんだ!, とか, もっとレスポンスくれ！って思ったことは何度もあった. 逆に, 「この子にはまだ早いかな…」とか「自分でやったほうが早い!」と自分で実装しちゃったりもした.
1, 2 はとにかく誠実に相手が欲しい機能を聞くことが大事である. 相手が欲しいものは非常にあやふやなので, ひたすら具体化, 視覚化を繰り返して一旦の着地をさせる.
作ってみたら意外とうまく作れていたり, 全然意図した方向じゃなかったりと様々ある.
失敗するときは大体, 仕様策定時点でうまく意図が共有できていない時だった. しつこいくらい担当者に聞くことが大事.
3,4の仲間を信じるっていうのは, 「信頼の置ける仲間に仕事を任せる」ということではない. それは単純に彼らに「期待」しているだけで, 「信頼」しているわけではない.
仲間を信じるというのは「仲間の失敗も許容して仕事を投げ続けること」である.
失敗しても最後はできる, と信じ続けることが「仲間を信じる」ということだと学んだ.
だから, できないからといって仕事を取るのは冒涜になる(case by caseだけど).
技大祭が終わるまで僕の仕事は「局員の仕事を選ぶこと」だと思っていたけど, 本当の仕事は「できるかできないかは別として, 局員に仕事を振り続けること」であると気付いた.
できるかできないかなんて, 所詮「サークル」なので2の次で良い. 問題はやってくれたかどうかである.
何かの価値を感じてサークルに来てくれている, わざわざ自分の時間を割いて僕の元で動いてくれる仲間にそれ以上何を求めるものはなかった.
逆に彼らに価値を提供することがずっと課題だった.
「仕事を振る」というのは「チャンスを与える」のと同じ意味だと思う. 仕事を振らないのは彼らに対する冒涜だった. 本当に反省している.
僕の使命は, 「自分が実装すること」ではなく, 「彼らが実装できなかった部分だけをひろうこと」であったと今更になって気付いた.
参加団体アプリとホームページの同時運営 と 面白い違い
僕自身, ホームページ作成が初めてだったので初めはちょっと放置気味だった(白目)
あと, 上記したがアプリとHPが同時に動いた過去はないので, どっちも動かすことは初めての経験であったようだ.
どちらも, どのようなタイムスケジュールで動くのか知らなかったので結構その場しのぎでやっていた記憶がある.
放置とはいえ, HPを実際に触ってみるとword pressが優秀(笑)でマウスで大体の操作ができて, やりたいことはpluginで大体なんとかなる, という感じだったので1日で基本動作は理解できた.
本音をいうと僕自身は, アプリ開発, チーム運営に注力したかった.
なので, 執行部経験者の後輩を責任者として1人, 実装担当として新入生1人いれて, ほぼ丸投げしていた.
僕はHPの仕様とイメージを決めて, 特に指導もせず「こんな感じでつくって〜」とチャットを飛ばすだけであった.
逆に, アプリの方の後輩は勉強会を開き自分なりに丁寧に教えて, とはいえ仕事を後輩に任せずにいる自分を自分で嫌っていたりした.
どちらが最終的に伸びたかというと, HP担当の後輩であった.
チームギークにもあるが, 「最も効率良く仲間のやる気を無くさせる方法は, 彼らを子供扱いすることだ」ということを身にしみて体感した.
繰り返すが, 僕は彼らを信じきることができず, 彼らのやりたかったことを潰してしまっていた. 本当に申し訳なく思っている.
局長としての最大の失敗は, 「後輩を信じきらなかったこと」で間違いない.
3に続く
技大祭を終えて 1
技大祭を終えて
9/17, 9/18に行われた技大祭.
僕は1年間技大祭を運営する立場として過ごした.
結構面白かったし, 得たものも多かったように思う.
これを機にこの1年間のまとめでも書いてみよう.
結構長くなりそう.
技大祭とは
そもそも技大祭とは, 僕の大学の大学祭である.
僕は学祭を運営する技大祭実行委員会に所属している.
以下この委員会を技大祭と呼ぶことにする.
人数はだいたい50~70人くらいだったはずである.
名簿に書いてある人間は多分そのくらい(人数に興味がないのでここは適当).
技大祭における僕の立ち位置
僕は, 技大祭の中で「情報局」という局の長をこの1年担当していた.
この局はかなりざっくり言うと「コンピュータ」的なことを担当する局である. ここについては後述する.
そして, 技大祭では「局長」位にいる人間は自動的に全体の意思決定を行う「執行部」に所属することになる.
なので, 僕はここ1年「局長」, 「意思決定組織の1員」として2つの顔を持って活動していた.
情報局の立ち位置
局レベルで担当していたことは主に3つ.
- 学祭に参加してくれる団体の情報を集めるWebサイトの実装
- 技大祭のHP管理
- 部室の電子機器, ネットワーク管理
学祭に参加してくれる団体の情報を集めるWebサイトの実装
大学祭に参加してくれる団体は出店や展示, 演舞をやってくれる団体のことを指している.
その大体はサークルか研究室であるが, 地域の方が出てくれたりもする.
この団体を管理しているのは「総務局」という他の部門が担当している.
では情報局が何をしているかというと, 参加団体の情報を入力しイイカンジに管理できるWebサイトを作ることである.
情報局ができる前にドクターの先輩が一人で作ったアプリを今年から「局」としてチームで管理することになった. 僕が主に力を入れてやっていたのはこれだった.
技大祭のHP管理
もうこれはそのまま. 技大祭の情報を掲載するホームページの管理をしている.
一昨年の情報部門長が作ったHPにコテ入れしてリニューアルした, という感じだった.
昨年度は, HPやSNSの更新が甘く学内でさえも十分に情報が公開されていなかったようだ.
僕の大好きな福山雅治も言っていたが, 「告知をしなければいくらファンでも来てくれない」.
これは真理だと思う. いつ何をやるかわからないイベントに来る/来れる人はいないだろう.
ということで, 今年度は出来る限り決定事項や企画, パンフについて情報を掲載していた.
基本的には後輩に丸投げで指図をする立場だった.
部室の電子機器, ネットワーク管理
部室の電子機器やネットワークの調子がおかしいときに直す役割, あと当日のネットワークを移動させる役割を担っている.
ネットワークの勉強が楽しいと気づけたきっかけの1つだった.
執行部としての立ち位置
技大祭は7局から構成されている. つまり7人局長がいる. そして, それらは「外部団体交渉」, 「広告, 企業協賛」, 「会場, 団体管理」, 「財務」, 「装飾作成」, 「企画構成」, 「情報管理」のように役割ごとに分割されている.
この中で情報局の比重は非常に軽い. 36年続く技大祭の中で, 新設4年目(実質3年)ということもあるが任せられている仕事がかなり少ない. そして, その重要性も他局に比べ低い.
昨年は情報部門だったが, 今年から局位を頂いて1局として活動させていただいていた.
なので, 僕がついた当初は立場的にはかなり弱い立場にあった.
つまり, 局長である僕の立場もそれなりに低いはずだった.
2に続く
tmux & vim で <C-h>にキーバインドする
iTerm2 v3 & vimで<C-h>にマッピングできない時 - 1++の続き.
上記でやった方法では,
- tmuxでは
<C-h>がキーマップできず, - vimでは
<C-h>がキーマップできる.
という問題が起きた.
僕はtmuxとvimをシームレスに行き来するプラグイン(vim-tmux-navigator)を使っているため,
どちらでもキーマップできることが必須になる.
そこで, tmux側で<C-h>をエスケープすることでtmuxとvimを共存させた.
一般的には以下の設定を行うとtmuxでエスケープできる.
参考サイト
// .tmux.conf bind-key -n C-h send-keys Escape "[104;5u"
これを応用して, キーマップを行った.
is_vim='echo "#{pane_current_command}" | grep -iqE "(^|\/)g?(view|n?vim?)(diff)?$"'
bind -n C-h if-shell "$is_vim" "send-keys Escape '[104;5u'" "select-pane -L"
