PFIインターンへ行ってきた（後編）〜その心〜
本エントリはPFIインターンへ行ってきた（前編）〜結合テストの自動化環境を整えてきた - obfuscatismの後編。インターンでやったことは前編を参照してもらうとして、後編ではインターンのきっかけ、参加する上での私の心境だとか、非技術的だけどチーム開発で必要かもしれない行動方針・環境適応のためのライフハック的なこと、インターンで知ったデザインドキュメントについて紹介する。締めのまとめは、ほとんど書かない方針で！
勝手気ままに書いていくので、エッセイみたいな感じで、役に立つかとか読む人を選ぶ文章かもしれないので、最初に断っておこう。構成としては以下のような感じ。
- 2011年3月インターンのきっかけ（PFIインターンは2009、2010年の夏に開催していた）
- インターンに対する私の思惑
- インターンでの私の目標
- 短期間で開発効率を高めるために意識したこと
- インターンで知ったデザインドキュメントとは何か
まあ、私の思考をトレースしていくと、こんな人間ができあがるというか、インターンのきっかけから、インターンが終わるまでの思考などを混ぜてみた内容となっている。インターンの面接とか、チーム開発のプロセス云々については書いていない*1。
インターンのきっかけ
結論から入ると、twitterで約1〜2年間程度、何度かリプライする程度の関係で、お互いの利益なるかもしれない状況だったので直接お会いした結果、2011年3月にPFI春インターンを開催して頂けることになった。その時期2010年11月頃、私の心境はいろいろと変化があったわけだ。
きっかけは2010年11月頃、twitterで@nobu_kさんとのやりとりから。PFIがQAエンジニア、テストに関連した技術者を欲しているというのはPFIウェブサイトに掲載されている採用情報なり、関係者のtwitterを見ることで判断できた。ちなみに、本エントリ執筆時点でも「シニアQAエンジニア」の採用情報はまだ掲載されているようだ。その11月頃、QAエンジニアを欲しそうにしているので、私は「大学の卒論終わったら2011年春頃にアルバイトさせてもらえないかな？」程度の気持ちでtwitter上でメッセージをやりとりし、PFIオフィスへ単身乗り込み、3月のインターン開催を検討してもらうことになった。本来なら夏インターンに参加すべきところだが、去年は私の都合（大学院の入試対策のお勉強）で参加を諦めていた。ついでに、筑波大学は7、8月が夏季休業のため他大学とインターンに参加する期間が一致しづらいというのが参加しにくい理由でもある（といっても、普通に応募して期間を交渉すればよい話。でも、11月時点で2011年夏までは1年近い期間があるため、私が落ち着ける時期が3月だったわけだ）。
インターンに対する思惑
2010年秋頃の私は、そろそろ大学院卒業後（2013年卒業予定）の就職を考えたときに企業を調査しないとヤバイだとか、2011年春以降のアルバイトをどうするかだとか考えていた。研究についていけずドロップアウトしたらどうしよう、などというのも含めてね。純粋にPFIへの興味もあったし、インターンを通して成果物（公開可能なアウトプット）を得ることができないか、といった思惑もあった。エネルギーをかけて行動を起こすのなら、1度で得られる利益を最大化したいと思うよね。
理論的には前述の通りで、感情的には私が卒業研究に対する気持ちとか、研究続けていけるのかといった悩みがかなり影響していた。脳内の思考がまとまらないときは、新しい環境へ飛び込んで心機一転してみたくなるわけである。
将来の就職先探し
自分の保身を考えていて（笑）、「ソフトウェアエンジニアとしてまともに生きていける」であろう企業をなるべく多く知っておこうという気持ちが強かった。何をもって「まとも」と定義するかは議論しないけど、ジョエルテストでは測れない、非技術的な部分も重要になる。開発で目指していることや、人間関係で合うか合わないかは一緒に開発をしてみないと分からない。私は大学入って4年間、いくつかの会社でアルバイトさせてもらった経験ががある。多少痛い目を見たこともあるし、マネージャ不足っぽい状況を数回見たりもしてきた（といってもアルバイトという狭い視点であるが）。他には、大学で仲の良い友達だからといって、共同でソフトウェア開発をしてもその人が書いたコードに信頼を置けるか、開発がうまくいくかは一緒にやってみないと分からない。虎穴に入らずんば、というわけでインターンやアルバイトは情報収集に良い機会だと思っている。あと、「組織としての方針」とかあったりするけど、それは誰かが決めたことであって、組織における意志決定とか思想的なことはどうなっているのか、とか、そのあたりも抑えておきたいと考えていた。
PFIへの興味
PFIについては、WEB+DB PRESSの#19 プリファードインフラストラクチャー 太田 一樹，岡野原 大輔，田中 英行：小飼弾のアルファギークに逢いたい♥｜gihyo.jp … 技術評論社を見ていて非常に興味深い会社であることは感じていたが、開発体制とか、研究開発で何をやっているか謎な印象だった。これについては、インターンに参加してそこそこに解決した気がする（気になる人は、PFIのインターンに参加して自分で確かめよう！）。
また、今回のインターンは製品開発チームでインターンをさせてもらうということで、新規開発よりも保守に近い経験ができそうと感じていた。学生のうちにソフトウェア開発をしていても、保守を経験する機会は少ないと思う（私の観測だけど）。私自身も、保守を中心とする開発経験はなく、自分がどれくらい保守を楽しめるか試してみたかった。結論としては、前編で書いたようにテストツールの開発、テスト自動化のためのプロトタイピングが中心で保守を意識した開発の比率は小さかったが、それでも多少保守についてはヒヤヒヤしながらgit pushする経験ができた。
インターン参加する上での目標
目標には、成果を出すこと、そして自分の考え（人生の悩みなり）を方向付けしたいと考えていた。
目標その1 - 成果その1：
インターンをさせてもらうからには、何かしらの成果を出さなければならない。成果といっても、PFIの利益に繋がることがまず第一に考えた。インターン開催にあたって、インターンを主宰するPFI側は準備、期間中は通常業務の時間を割いて、エネルギー（時間、お金、労力）を使うわけだ。なので、私はインターンで参加して、成果（テスト自動化を達成）を出しつつ「即戦力な」お得感を演出させることを目指していた、、ような気がする。
PFIに対して、新しい価値、もしくは新しくないけどPFIという組織に存在していない「価値」を提供することを目指せたら良いと思っていた。「結合テスト自動化」を「新しい価値」と言うには、しょぼく感じるかもしれないけれど、例え小さくても次に繋がっていくわけで、最低限の目標は達成できた。PFIの結合テスト自動化もまだ始まったばかりだ（次回作にご期待くだださい...？）。テスト自動化という重要な部分に貢献できて私は嬉しく思っている。
私が大学4年間では、「即戦力」程度の技術力を得ることと、「（技術にしろ何にしろ）たくさん引き出しを作ること」を目指してきた*2。「引き出しをたくさん作る」とは、私が大学へ入学する前にid:connect24hさんから言ってもらった言葉。この春大学に入学したばかりの1年生がこの文章を読んでいたとしたら、覚えておいて欲しい言葉でもある。「広く物ごとを捉えて、自分で物にして活用できる引き出しをいっぱい作って、行動範囲や可能性を広げて欲しい」というような意味だったと思うけど、完全には覚えていない。技術が面白くて仕方がなかった高校時代と比べて、私も少しはバランスが取れてきたかなという気がしている。
目標その1 - 成果その2：
他に目標とした成果としては、PFI内部の評価、私がPFI外部へアピールできる成果（オープンソースでソフトウェアを公開したり、ブログを書いたり）などがあった。前者についてはインターン参加者を文書化・数値化して見える化する評価シート的なものが無い（？）ようだ（あっても少し怖い気がするけど）。後者については前編でdtestを紹介したり、ブログを執筆できたのでソコソコに満足と言える。前者については「技術的にかなりキレるヤツ」とまではいかないかもしれないけど、22歳でこれくらいやれる人間がいると知ってもらえただろうから、「私を知っている人を増やすキャンペーン」としては、良いのではないかしら。
それにインターンと言っても、短期間に正社員全員とペアプロしたり、一緒に開発をするわけでもないので、技術的・非技術的なスキルすべてを全員へアピール＆評価するのも不可能でしょう。特に、デスマーチだとか緊急時にどれだけ対応できるかといった部分は、それこそそんな状況下で一緒に開発を体験してみないと分からないでしょう。全員とペアプロは、頭おかしいけど、やってみても面白い気もする。でもインターンの目的と確実にズレてるだろうけど…*3。
インターン中、開発効率を高めるために気を付けたこと
新しい環境で素早く適応したいがために気を付けたことと、開発効率アップのために毎日数時間ごとにA4ノートへ進捗・タスクなどを記録していた。両方ともライフハック的な要素というか、非技術的だけどチーム開発＆短期のインターンだからこそ意識していた点である。
コンテキスト（社内の空気）の把握
インターンは1ヶ月間と短い期間であるため、その期間内に環境に適応して成果を出す、私自身の目標を達成することが自身に求められる。インターン期間の最初のうちは、日常的に使う社内用語・コンテキストを意識して覚えるようにしていた。また、マニュアル・Wiki等で定義されたキーワードがあれば、暗記するようにしていた。しかし、文書になって明文化されたものもあれば、どんどん変化していく流行語、雰囲気のようなものもある。そこは適宜、楽しみながら混ざっていく感じだったろうか。「コンテキスト」については、人に説けるほど読んだわけじゃないけど、ブログ「発声練習」の以下のエントリに書かれた「ハイコンテクスト文化」が印象に残っていたので意識していた。
妄想：会社がコミュニケーション能力を求める理由 - 発声練習
技術者、日本人同士でしかも日本語を使って会話をしていても、話しがかみ合わなくなることはある。それは、この「ハイコンテクスト文化」とも関連していると思う。無意識のうちにコンテキストに依存した会話をしてしまい、双方が気づかずうちに会話がどんどんズレていってしまう現象がある。日常生活の会話でも、話しの流れを省略し過ぎて誤解が生じることと、基本的には同じだと思う。コンテキストを理解してもらえることを前提に会話する利点もあるが、ソフトウェア開発においては前提の確認を怠ったコミュニケーションを日常的に繰り返すことで生じる誤解が開発に支障をきたすこともある。そういう友達がいたので...。
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (131件) を見る
一度書いたあとに気づいたが、『エリック・エヴァンスのドメイン駆動設計』の2章「コミュニケーションと言語の使い方」で説明されていることと内容がほぼ一緒かもしれない。とにかく、会話する上で齟齬となる専門用語・オレオレ用語を潰していったり、定義を正確にして曖昧さを減らすように気を遣った。特に環境（地理的、人のクラスタ）が変わったときは、認識のズレは多いだろうから、それが積み重ってオーバーヘッドが生じないよう注意した方がよい。コンテキストに依存した誤解ではなく、純粋に私の無知からくる認識不足は何度かあったかもしれない。
ハイコンテキストについては、大企業などでは専門用語が通じるので仲間意識が生じて社外の人間にソーシャルハックされてしまうだとか云々…とかいうのも考えられるけど、本エントリとは関係無いのでセキュリティとかソーシャルハックについて興味があるなら『欺術 - 史上最強のハッカーが明かす禁断の技法』でも読むといいよ。
- 作者: ケビン・ミトニック,ウィリアム・サイモン,岩谷宏
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2003/06/21
- メディア: 単行本
- 購入: 9人 クリック: 98回
- この商品を含むブログ (100件) を見る
インターンで知った「デザインドキュメント」という概念
「デザインドキュメント」という概念を初めて知った。何を作るか、アプローチなどを記述するテンプレートが用意してあり、実装する前にデザインドキュメントを記述する。PFIの開発チームにあわせて、テンプレート・習慣を作っているのだろうと開発プロセス的な部分で一番感心したのがココ。
デザインドキュメントはどこに起源があるのか知らないけれど、以下のブログで鵜飼文敏さんの講演が紹介されているので見てみると良いかもしれない。
デザインドキュメント - 計算機と戯れる日々
software design documentでぐぐってヒットしたページを読むべし！
Software design description - Wikipedia
Brad Appleton | CMCrossroads
まとめなど無い
書きたいことだけ書いた文章になった。インターンに参加しての心境変化については、文書化しづらい部分があり、うまく説明できそうにないので今回は書けず！
- なぜ検索エンジンを開発するのか、ソフトウェアで何を達成するのか、http://preferred.jp/co_mind.htmlのようなことも聴けたりして良かった
- 大学院へ行く・行かないだとかもお話し（というより人生相談）ができて非常に良かったなぁという次第。年齢があまり離れていないので、こう勢いに任せた話しもやりやすいですね！
- 大学院の研究なり、大学出た後の進路なり、最終的には「自分が何をやりたいか」になるわけでして、「そういう風に考える機会になったのは良かったね」と友達に言われてその通りだと思った。人生どうするか、絶賛悩み中。
