技大祭を終えて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に続く
