2012年7月4日水曜日

職場に感謝を

開発に移って早9ヶ月が経とうとしています。毎日の仕事では、巨大な C++ のコードベースと向かい合い、舞い込んでくるバグタスクやリファクタリングタスクをひとつひとつ処理していきます。レガシーコードも存在しているので、製品のデザインの歴史を知るエンジニアに助けを求めることも多々あります。自分が関わっている範囲は MATLAB の
  • インタプリタ 
  • インデックス
  • デバッガ
  • プロファイラ
  • 関数ディスパッチ
  • 関数ハンドル
  • ワークスペース
  • サーチパス
といった部分です。MATLAB ユーザの方であればこれらのうちいくつか触れたことがあるかもしれません。

毎日とにかく楽しく、現状に対する満足度はチームに入る前に僕が抱いていた期待値を上回っています。Great place to work たらしめている要因は複数あり(自分の思い込みも含む)、どれもありがたいものです。

すべてはつながっている
プ ログラミング言語論、計算論、アルゴリズム、ソフトウェア工学といった分野で、書籍で読んだり、大学の講義で聞いたものが現場で駆使されている。学校にいたころは学びの姿勢がなっていなかったため、何の脈絡もなしにただ書籍を斜め読みしたり講義を聞いていたりしただけで、あんまり内容が頭に入ってこなかった。これは何の役に立つのかなとポリポリ頭を掻きながら困惑していた時期もあった。しかし今の現場では、そういったベストプラクティスが実際の製品に組み込まれているところを目の当たりにできる。コンピュータサイエンスやソフトウェア工学で重要だと謳われている知識やスキルを身につけることが、己に大きなアドバンテージを与えるということをはっきりと実感させてくれる職場なのである。

いざというときに救いの手を差し伸べてくれる
直面している問題の全体像を把握することが一人では困難なため、特定の分野を熟知しているエンジニアに助けを借りることがよくある。僕がつまづいている箇所をひとたび説明すれば、彼ら/彼女らは次にどうすべきかそのステップを楽しそうに説明してくれる。エンジニアだからだろうか、みな質問が飛んでくるのが好き、説明するのが好きというのが見てとれる。だからこそ僕も気兼ねなく声をかけることができる。しかしそれは、僕の側で必要なリサーチをすべて終えた後でという条件つきだ。手ぶらで「分かりません」では解決にむけて何も前進していない。分からない部分にも領域があり、分かる部分との境界線を引くことが重要なのだ。今の現場は、みな直面している問題が簡単ではないことをよく分かっており、この「線引き」さえも立派な努力として認めてもらえる。線を引いたはいいがこれからどうしていいか分からないという「いざ」という局面で、同僚は喜んで力を貸してくれる。

発信者によらず意見を尊重する
同僚はみな僕よりも年配で長年の開発経験がある。なかには20年以上の経験を持つ人もいる。そんな人からしてみたら「学校出たてで開発経験も十分にない君の意見など無用だ、ただ黙って言われたとおりにしていればいい、質問も一切受け付けない。」と思っても不思議はない。しかしそんな態度をとられたことはただの一度もない。逆に「このタスクに関連しているコードを一番見ているのは君だ、気づいた点、不明な点、改善すべき点があればどんどん教えてほしい。」と僕のインプットを歓迎してくれる。例えば、僕がすぐにコードの挙動をつかめないような部分を指摘すると、それはもしかしたら初見の者にとって分かりにくい複雑なデザインになっているのかもしれないという、悪いニオイのフラグをあげてくれる。発信者が誰であれ、そこにある意見を真剣に聞いてくれるため、いつも前向きな気持ちで仕事に取り組むことができる。

過ちそのものより個人の成長を重視する
去年の12月に、コードをコミットする際に走らせたテストの結果で分かりにくい記述があり、その部分を明らかにしないまま自分の変更をサブミットして、コードベースを壊したことがあった。そういうときも「前に進むときに間違いを犯すことは一向に構わない。同じ間違いはしてはならないが、新しい間違いはどんどんすべきだ。過ちを恐れて前に進めなくなることが一番問題だ。」と、原因を追究し把握した上でそれを学習の機会とさせてくれる。また、初めてやることは比較的時間がかかるが、それは二度目以降はより短い時間でこなしてくれるだろうという期待を込めて任せているんだ、とよく話をしてくれる。過ちやつまづきはすべてその人の長期的な成長にとって必要な糧なのだ。

和気あいあいとした現場
自分のチームは多国籍で比較的陽気な人が集まっている。前述の僕がコードベースを壊したときも「Yahoo, Yuki's just broken our codebase! 」みたいなノリだった。そんなお気楽で大丈夫なのかと思ったりもしたが、どうやら大丈夫らしい。またチームメンバーのオフィスも一箇所にまとまっているのでお互い気軽に話しをすることができる。とにかくストレスフリーな現場である。

必要最低限のミーティング
進捗のミーティングはほぼスタンドアップミーティング。合計時間にして1週間に30分強。普段から気軽に話しをすることもあって、椅子にどっしり腰を下ろして時間をかけてミーティングをすることは少ない。なので、日々中断が入ることなく自分の作業をすすめることができる。


というような感じの職場です。当面の目標は社内向けに「Ruby ソースコード完全解説」をリスペクトして「MATLAB 実行エンジンソースコード完全解説」を書くこと!
とはいうものの、どれくらいかかるのか・・・実行エンジンと限定したのは、他の製品、デプロイとかグラフィックスとか Simulink を含めようものならもう対象がデカ過ぎて死ねるからだ。実行エンジンだけでもデカ過ぎてやばいのだが・・・