nDiki : トレードオフ

YAPC::Asia Tokyo 2014 1日目

昨日の前夜祭から一夜明けての YAPC::Asia Tokyo 2014 1日目。昨年に引き続き慶應義塾大学 日吉キャンパス開催なのでなんとなく勝手がわかってちょっと気楽。去年はなんか多目的教室に入りそびれたので、今回は早めに移動とかしてそちらも回ってみた。

電源の取れる藤原洋記念ホールがなんだかんだいって居心地が良かったりはするんだけれどね。

今日は Go 使ってみようかなと思ったのが収穫。会場でとりあえず golang Debian パッケージをインストールして hello.go ぐらいはしてみた。goroutine 以外は思っていたより普通の言語……なのかな?

お昼は @syamata 氏と @bornite 氏と日吉天神でラーメン。去年と同じ店だった。と思ったら去年は同じ場所で「らーめん 元山亭」という店だった。日吉天神は去年10月7日オープンらしい。 @syamata 氏が最近 Facebook で Yelp のフィード流しているのでモチベーションとか聞いてみたら「アーリーアダプターとして、まだデータにないお店やレビューを登録していくのが楽しい」とのこと。あーわかる。

「インフラエンジニア(狭義)は死んだ」 Satoshi Suzuki @studio3104 氏 (多目的教室2)

インフラエンジニアのメンタル的な面に視点を当てたトーク。

• 物理的なハードウェアにかかわる事は減ってきている。
• そのかわりコードを書ける必要が高まっている。ただしコードを書けばバグも発生するのでコードを書かない選択肢も常に考える。
• あとリーダブルコード的な話とか。

「Go For Perl Mongers」 Daisuke Maki @lestrrat 氏 (多目的教室2)

Go にいりては Go に従え。

• いわゆる例外処理無い。
• いわゆるオブジェクト指向的でもない。
• fmt は ふむと? / ふんと?。
• ハードタブ。

Go 使ってみたくなった。

「お待たせしました。Perl で BDD を簡単に実践する最高にクールなフレームワークができました」 Tokuhiro Matsuno @tokuhirom 氏 (多目的教室2)

Perl のテストフレームワーク回りの話し。

• 2 の開発中止あるある。

テストフレームワーク関連はできるだけ枯れて安定したものがいいなと思う(テストフレームワークの不具合とか仕様変更まで追いかけ続けなくていいように)。便利さとのトレードオフ。

「Perl::Lint - Yet Another Perl Source Code Linter」Taiki Kawakami @moznion 氏 (多目的教室2)

わりに泥臭い世界なのではと思ったら、やはり泥臭い感じだった(実装的に)。

C スタイル for だって goto だって適材適所なので使った方が良い場面だってあるので、そういうのはきちんと説明できるといいんじゃないかと思う(lint がそこまで判別できたら凄いけど)。

「One layer down below.」 Kang-min Liu @gugod 氏 (藤原洋記念ホール)

フルフルの汎用モジュール使わないで、軽くて速い機能を削った専用モジュールを作って使うのもいいよという話。

• Hijk:: ElasticSearch など用に特化した軽量 HTTP クライアント Perl モジュール。

「いろんな言語を適材適所で使おう」 Kentaro Kuribayashi @kentaro 氏 (藤原洋記念ホール)

経営的な視点まで入った技術選択の考え方の概論トーク。

• 継続性を見越した技術選択
• microservices

「WHERE 狙いのキー、ORDER BY 狙いのキー」 @yoku0825 氏 (藤原洋記念ホール)

MySQL のインデックスを Perl データ構造で擬似的に説明。

フォントかわいいけどコード部分とかちょっと見辛かった。

「Mojolicious を使った web アプリケーション開発 実践編」 Yoshimitsu Torii @torii704 氏 (藤原洋記念ホール)

ビギナー向け。

「Java For Perl Mongers」 Kazuhiro Osawa @Yappo 氏 (藤原洋記念ホール)

Java = Perl。

Lightning Talks Day 1 (藤原洋記念ホール) スタート!

ハッシュタグ #yapcramen

(画像は http://yapcasia.org/2014/ より)

インターンシップ制度を受け入れたチームメンバが個人として期待するといいんじゃないかと思うこと

インターンの方が配属されるとチームが賑やかになるとともに、チームメンバの皆さんも忙しくなりますよね。就業体験型のインターンシップでは、ほとんどの場合ふだんの業務を抱えながらインターンの方をフォローすることなるので大変かと思います。

新しい人が配属された直後はチーム/個人の生産性が落ちるという話はトム・デマルコ氏の本を読むまでもありません。フォローをしている間は自身の担当業務ができなくなるので個人的な生産性は落ちることがほとんどでしょう。ここはトレードオフとしてチーム全体で受け入れるべきだと思います。

さて会社・人事・部署それぞれに期待するところがあってのインターン制度ですが、個人では何を期待していけば良いのでしょうか。

インターンシップ制度に個人として期待するといいんじゃないかと思うこと

インターンの方に良い就業体験を提供できるようにしていく一方で積極的に自身でも学んでいきたいと私は思っています。目新しいところはありませんが、個人レベルでは以下のような点を期待するといいのではないかなと考えています。

人に教える事による自分自身の学び

人に教えようとすると「あれっ?」となることは仕事に限らずあると思います。私は説明するタイミングであらためて用語の定義を確認しなおしたり、手順をドキュメント化したりしてみています。

インターンの方の得意な分野からの学び

インターンの方の研究テーマや人生経験などから、学べることはいろいろあると思っています。ですので「この人面白いことやってそう! チームとしても学びがありそう!」という方に来ていただけるようにできるだけしています。

インターンシップ期間中はチーム内 LT をしてもらったり、ランチで話をきかせてもらったり、あるいは自分の知らないような工夫点を業務時間中に教えてもらうようにしています。

また、私が社会に出て働き始めた頃に担当したインターンの方はその後しばらく一緒に仕事をすることになりました。別々の会社になった今でもばったり再会して情報交換させてもらって学ばせていただいています。そういうのもいいものだなと思います。

間接的な学び

今は直接インターンの方についたりはしていないのですが、どのような就業体験を提供できるのかを考えたりこういった記事をまとめてみたりと、どの立場でも取り組んで学べることはあるなと思っています。

インターンの方にとっても自身にとっても、短期的な利得よりは長期的にみて良い成長の糧となればいいのではないでしょうか。

---

[ opinion ]

品質と時間のトレードオフを判断できたの自画自賛

ワークショップで「品質より時間を優先」の判断をとっさにしてゴール達成できたの、品質・時間・スコープ・予算のトレードオフを意識して意思決定するアジャイルソフトウェア開発経験の賜物だなーと思ったり。

(なお、スクラムだと期日固定で、品質可変よりもスコープ可変の方が多くの場合望ましい。今回はスコープ変更ができない課題だったので品質を下げるという選択をした。)

one-on-one ビデオ会議の相手が隣の会議室から出てきた

one-on-one のビデオ会議を終えて会議室を出たら、相手が隣の会議室から出てきた。

これ自体は笑い話。

個人個人でオフィスワークの日とリモートワークの日を好きに選べるようになったことで、ミーティングについては面倒なことも地味に増えている。ビデオ会議はなんだかんだセットアップが手間だ(人数に合わせてマイク + モニタのスピーカーかヘッドセットかを接続して事前テストしたり、カメラを設定したり)。

毎回今日はどうやって参加しますかと確認するのもなあとミーティング参加者がどこにいるのか事前確認していないので、予想が外れると直前でビデオ会議準備の変更を強いられることもある。

自由な働き方の提供とトレードオフで発生するコスト。