30歳過ぎから工学 vol.2

http://d.hatena.ne.jp/j130s/ から移行しました.オープンソースロボットソフトウェア技術者兼主夫. 高校・大学学部文系-->何となくソフトウェア開発業-->退職・渡米,テキサス州でシステムズ工学修士取得,しかし実装の方が楽しいと気付き縁があったロボティクス業界で再就職.現在 Texas 州内の産業用オートメーションのスタートアップに Georgia 州から遠隔勤務.

ソフトウェアエンジニアリング基礎 (CSE3310 Fundamentals of Software Engineering)

期末試験週間に入りました. ここ3週間は学期末へ向けて宿題が立て込む一方, 大学院応募〆切も新たに2校あったりして, 寝不足な毎日をなんとか強壮飲料(レッドブル)と気合とで凌いでいます.
忙しかったもう一つの理由は標題の授業. 講義は金融系システム構築をしていた先生が, ソフトウェアエンジニアリングの学界の大家, 英国の Dr.Sommerville の教科書や資料を元に経験談を交え話しをします. 1個づつのトピックに私も言いたいことや考えさせられることがあって良い講義だった*1. しかし忙しい理由は講義ではなく, 学期通して行われたチームプロジェクト〆切があったため. 要件が決まっているウェブシステムの要件定義書とシステム構築を4人チームで3ヶ月かけて行い, 最後は担当教員と授業参加者全員の前でプレゼンするというもの. 授業評価の50%を占めるのでいやでも頑張らねばならないものでした.
内容だけからすると経験者の私がわざわざ時間と金をかけて履修すべきものではないのですが, 最終評点が比較的甘いということで知られていたので平均評定を上げたい私には都合良かったのと, (システム規模の小ささ, 品質の低さはさておき)英語でのチームワークの経験を増やすには良いな, 失敗しても自分の授業評点が傷付くだけだし, と考えて履修しました. 私以外のチームメンバー3人は, 2人が30歳過ぎフルタイムワーカー, 残り一人も夜勤あり. そしてシステム構築に欠かせないモチベーション, 新たな知識を身に付けてやろう, や, 良いもの作ってやろう, は最初から低く, 私はといえば WEB三層システム自体はちょっと今更なモノだったので興味が持てず, 結局時間もモチベーションも限られたチームでした. 時間を有効に進めるため, 設計ドキュメントやタスクリスト等を利用し, 会って意識を共有できない分を埋める試みをしたり, 作業分担は全員が全範囲を一通り経験するのではなく得意そうなところだけを担当するといった, 時間が足らない中で何とか質を上げる提案をしましたが, 機能しなかった. とにかく2人(フルタイム女史と夜勤男子)が待っても待ってもコードを書いてこない. 女史とは特にうまくいかなかったようで, 提案はことごとく反対/無視され, 一方 Google Docs を使ったドキュメント共有を見せたら妙に気に入ったのか, それ以降〆切間近だっていうのにコードをろくに書かずドキュメントばかり量産され, 誤った刺激を与えてしまったかのよう. 結局ラスト2週間で, やっと皆が一日中一箇所に集まって作業することで2人も何とか使えるコードを書き始め, 最低限の状態でプレゼンを乗り切る形に.
正直その2人への不満はたくさんあって, 途中何度もストレスを感じてこの授業を履修したことを後悔したけれども, うまくチームを軌道に乗せられなかった自分の反省をします. 具体的な行動としてはごく基本的なことですが 1)リーダーを決めること, 2)一緒に作業(打合せじゃなく作業)する時間を持つこと, でしょうか. 1点目は学生チームならではという感じもしますが, チームリーダーはもとより, 各人を何かしらのサブリーダーにする. すると責任感を持つ. 責任感を無理矢理でも一人ひとりが持たんと, 何も仕上げない人が出てくる*2. 2点目は, 前述の2人は手取り足取り口頭で伝えないと作業を始められない様子だった (e.g. "FTP ってなに?どういうツール使えば FTP できるの?" "PHP ってどう書けば良いの?") ので, 隣の席で作業して分からないことがあったらすぐ聞いてあげられるようにしたら, なんとか手を動かし始めた. (ここから愚痴)プロ/アマ問わずシステム構築界の常識として, サンプルプログラムを見て学ぶのは当たり前です. 私も入社してすぐ, "ソフトウェアエンジニアは自分で調べろ. その結果分からなければ人に聞け" と指導されました. ネット上のコミュニティを見てもその意識は徹底されてると思う. そもそもどんな分野だろうが, 少しでもやる気が高い人なら自然と自分である程度は調べるはず, まして私らが必要としていた程度の情報ならすべて Google で探せる時代です..(愚痴おわり).
しかしながら終わってみて思うのは, 少なくとも彼らの作業態度に対して直接1対1で話し合うことをすべきだったなと. 私は教師でも上司でもないのでそういうごく基本的な意識改革を促すわけにはいかなかったし, 女史は指摘に対し逆にキレてくる感があるので正直話しにならんと思い, 作業しない2人に対して何もしなかった. 結果的に, 作業しない人がいる->作業できる人がその分を補う->負担が増える->終わったら喧嘩別れ, では疲れるし質は下がるしやり終えた後の連帯感もないし, で良いことが少ない. 私はこう考えるのだがどう思うか?と指摘したうえで喧嘩になるのなら諦めるしかないと割り切れただろうし, 彼女らの作業を妨げていた原因がわかったかも知れない. 実際, 締切3日前に一緒に作業していた時に, その女史は以前から私からのコードの書き方の指導を待っていたことが明らかになりました(というか, "j130s が教えてくれないから私がコード書き始められなかった" という, やってないことに対する言い訳だった). 私はついカッとなって "私はあなたを指導する責任はないし1ヶ月前からサンプルコードは共有してたでしょ?" とキツ目に言ってしまったが, 私もそのサンプルコードをメールで共有して終わるのでなく, その見方が分かるか等フォローをすべきだったんです. 今後参加するチームでは, ここまでレベルが低いことはもう無いだろうけれど, 普通にあり得る状況ではあるだけに, 勉強になりました. これまで経験してきたチームでは私じゃない誰かリーダー格がやっていたことなんだな.
もう一つだけ, 同種の授業を履修する機会がもしあるならば, モチベーションに問題がなさそうな人と組むべきですね. 学科の先達日本人に以前そう助言もらってましたが, 今回はこの授業に費やす時間を抑えたいのと, 個人的に慣れている WEB三層システム なら他の生徒の成果が少なくてもどうにかなるだろうと考えたのと, そしてランダムに選ばれたチーム編成の方が自分の一番の目的である英語でのチームワーク的に勉強になるだろうという三つの目的で, 敢えてランダムチームに. その点から言えば, 当初の目的は果たしたと言えそうです. また, 授業開始後に知り, 追加することになった "プレゼンを原稿を見ずに行う" という目的も達成しました. 実は恥ずかしながらプレゼン経験が少なく, むしろ国際学会の口頭発表の方が日本語プレゼンより多いのですが, 口頭発表はとにかく質は気にせず "(業務が忙しい中, 論文が採択されたのに欠席すると学会で角が立つので)行って発表してくれること自体が君の目的だから" と毎回上司に言われていたこともあり, いつも原稿を見ながら行っていました. 今回3時間かけて原稿を作り, 1時間ほどリハーサルを自分で繰り返したら, なんとか原稿に目をやらずに十分間のプレゼンを終了した遅咲き34歳.
いつにもまして低レベルな話で恐縮でした. さー勉強に戻らんと.

日本人友人に鰻丼をご馳走して頂く. 冷凍鰻(中国産)を短時間酒蒸しすると, ふかふかになるようです.
P.S.1. 上述の怠惰な2人, すべて終わった今頃になって "このシステム作ったこと, 履歴書に載せられるよ! 今後も作り続けようよ!" とかメイルで言い出す始末...肝になる部分作ったのは君達じゃないけど, 邪魔も助言も何もしないし著作権だなんてこと言い出さないから, どこまで自分達でできるのか見せて欲しいものです.

*1:内容は日本のソフトウェア開発技術者試験を, プロジェクトのライフサイクルにおける実装以外の各箇所を掘り下げ感じです. 日本でソフトウェア工学の授業を履修したことは勿論無いけど, 網羅的に知識体系が出来上がってるのを見せられると, 欧米の工学の長所を見せられている気がする.

*2:Maslow の三角形で言う所の, 一番てっぺんの "自己実現欲求" を満たすものにあたるんでしょうが, このプロジェクトではそんな高尚なこと言ってる場合では無い.