チームボックス
エンジニアブログ

エンジニアリングマネージャーの成長と育成

こんにちは!チームボックスのヤスニシです。

この記事は、Engineering Manager vol.2 Advent Calendar 2018 の17日目の記事です。

qiita.com

「成長=スキル習得」だけではない

エンジニアリングマネージャーが最近熱く、勉強会や記事が増えてきていて個人的にはとても嬉しいです。今回は、その中でもあまり触れられていないエンジニアリングマネージャーの成長と育成について考えてみようと思います。これは私的になかなかチャレンジング。

「成長=スキル習得」というようなイメージが強いのですが、実は同じくらい大事なことがあり、そこができるかどうかが成長し続けられるかどうかの鍵を握っています。スキルややり方については、このような最近多くの本や記事も出てきてますので、ちょっと違う観点で書いてみます。

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

 

まず、EMはどういう人がやれば良いんだろう?

エンジニアはものづくりをしたくてやっているからか、エンジニアリングマネージャーをやりたがらない人が多いです。とはいえ、開発現場の課題というのはプログラミングだけで解決できるものだけではないので、肩書がついてなくてもどうしても現場でEM的な動きが必要になります。

優秀なエンジニアは知的好奇心が高く、目の前の課題が大きいと学ぶ方が多いので、解決策がプログラミングじゃなかった場合でも触手を伸ばす方がいます。そうするとEMの仕事をやってもうまくいくことがあります。そういう「何に対しても学べる方」方がEMには向いているのではないでしょうか。

逆に単にマネージャー(という役職)になりたいという方は、目的が課題解決ではなく役職になることである場合もあるので、そこは見極める必要がありそうです。

問題解決のために「人間の適応」に目を向ける

EMをやってみると、これまで見たことが無いような課題にぶち当たったり、唯一正しい答えを決められずに悩み、決定によってさらに問題が起こり悩む、ということが増えます。

f:id:tsuyok:20181217105806p:plain

課題解決方法の分類

何か問題が起こると、原因を探り対策を練り、技術的手段を探します。もちろんそれで解決することもあるわけですが、「人間の適応」が必要な場合があります。

リーダーが犯す最も大きな過ちは、適応を要する課題を解決したいときに技術的手段を用いてしまうことだ

というのは、↓の本の一節です。問題を見極め「人間が適応」に対しても対策をすることが必要です。そしてEMが対峙している問題は、人間の適応が必要な問題が多く、まず自分自身が適応しない限り、一緒のチームのメンバーも適応することができません。そのためには、私はEMがメンバーよりも自分を変え「学び続ける」ことができる、ということが大切なのではないでしょうか。 

なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践

なぜ人と組織は変われないのか――ハーバード流 自己変革の理論と実践

 

我々はどのように学び続ければよいのか

では、どのように学べば良いのか。チームボックスでのリーダー育成の考え方を元に、EMの仕事を想定して4つのポイントに整理してみました。このような構造になっています。

f:id:tsuyok:20181218084410p:plain

 

①弱みや失敗をなんでも言い、さらけ出す

失敗をしたときに、プライドが邪魔をして、失敗を認められないことはあるのではないでしょうか。そうすると「自分で認められない→学び変わる必要がない→学べない」ということになってしまいます。

そのために、まずは他人に言ってみることです。勇気がいりますが、弱みや失敗を言うことによって、自分自身もそれを受け容れることができるようになります。自分が受け入られると、何かやったときの結果や、他人からのフィードバックも受け入れられ、どんな機会からも学べるようになります。

本当の勇気は「弱さ」を認めること

本当の勇気は「弱さ」を認めること

 

②過去の学びを捨て、Unlearnする

学んできて、成功した実績があることは素晴らしいことです。でも、それがどんな場合でも役に立つわけではありません。ときには、その学びをあえて捨てて、別の学びを得る必要があります。

ただ、それにはどうしても痛みが伴います。今までの自分を一部否定するような感覚にもなるので。ただそこに向き合い、純粋な好奇心で新しいことから学ぶことができると、自分を成長させることができます。

mirai.doda.jp

③自分と向き合い、自分を知る

自分は今どういう状態なのか、何を学ばなければならないのか、何をUnlearnしなければならないのか、というのは、自分自身を知らないわかりません。わからないと、その後のアクションにつなげることができず、学ぶのが難しくなります。

その根源の多くは感情からやってくるのですが、感情は自分で認識するのは難しく、何もしないと目の前を通過していきます。つまり、努力をしないとできません。普段の仕事の中で自分へのセンサーを働かせ、自分の感情や無意識を知るようにします。

自分の感情を知るためには、気がついた時にノートにメモし、言語化すると良いです。毎日続けていくと、だんだん自分が何を感じているかが理解でき、次にどんな行動を変えるべきかが見えてきます。

④行動を変え、ふりかえる

何を変えるべきかわかったら、行動を変えます。行動を変えると、結果が出ます。結果をそのままにしておくと、学ぶことができません。しっかりとふりかえりを行い、何が良くて何が悪かったのか、次何を変えるべきかの結論を出すことで、学びが習慣化します。

エンジニアチームは、スクラムなどを導入することにより、チームでふりかえりをすることは多いと思いますが、自分自身のことについてふりかえる人は少ないと思います。チームと同様、個人で振り返ることで、改善プロセスが回るようになっていきます。

corp.netprotections.com

EMの育成ではこの4つのポイントもフォローする

EMを育成する場合に、チームビルディングやプロジェクトマネジメント、スクラムなどの知識やスキルを習得すること(主に技術的手段)と同時に、これらの適応に関してもフォローをしていくことが大切です。

そのために1on1やEMでのミーティングなどで、①〜④の学びについても一緒に考え、何か新しいアクションを行い、自分自身の成長に向き合い続ける環境を作り続けると、個人だけでなくEMを中心として全体で学び続ける組織を作ることができると思います。

やるのは難しいけど、学びには喜びがある

私自身、適応問題で悩み続けました。何か課題があるときに、自分自身が変われず、なかなか前に進めないという苦しいことが多くありました。ただ、このような考え方に出会った時に、少しずつ自分自身が成長するということの意味がわかってきました。

特にマネージャーの仕事は明確な答えが見えないことが多く、どの選択肢を意思決定してもどうなるかわからない、というようなことが多くなります。そうなると、わからないという事実や失敗に向き合わなければならなくなります。

そういう意味で、EMは人間の適応という意味での「学び」を意識する必要が多くなると考えています。ただこれが結構難しい。でも、やれたとしたら問題解決とともに自分が成長できるので、喜びが多くあります。

是非チャレンジしましょう!私もがんばります。

論文紹介: Enabling Factorized Piano Music Modeling and Generation with the MAESTRO Dataset

こんにちは、チームボックスCTOのhiromuです。

この記事は、以下のAdvent Calendarの8日目の投稿です。

qiita.com

今回取り上げる論文はこちら: Enabling Factorized Piano Music Modeling and Generation with the MAESTRO Dataset | OpenReview

Google Brain のプロジェクトの1つである、深層学習によって音楽を扱う Magenta のチームからの論文で、公式ブログでも詳細が紹介されています。

magenta.tensorflow.org

12/8 時点でのレビュースコアも 8, 8, 8 と、かなり高い評価を受けています*1

概要

本論文の貢献を一言で表すと、音楽情報処理のためのピアノ演奏とその録音の新たなデータセット MAESTRO を構築したという点にあります。このデータセットは、International Piano-e-Competition というピアノコンクールの9年分のデータで、クラシックを中心に430曲・172時間の演奏が含まれています。また、Disklavier を用いて収集されているので、打鍵の強さやペダルの情報も MIDIデータとしてに含まれているというのが魅力的なポイントです。

さらに、このデータセットを使って、録音データからの採譜、MIDIデータでの作曲、MIDIデータからの演奏再現の3つのタスクを行った結果も載せています。特に、採譜については state-of-the-art を達成したと述べています。

データセットの詳細は元論文を見ていただくとして、ここではこの3つのタスクの結果について紹介したいと思います。

録音データからの採譜

採譜は、同じく Magenta チームが出した Onsets and Frames (Hawthorne et al., 2018) を適用しています。軽く紹介すると、双方向LSTM を用いて録音データから採譜を行うのですが、新たな音の入り(Onset)の検知のみを行うネットワークと、各フレームごとに鳴っている音を推定するネットワークを分けることで、MAPS という既存のデータセットでのF値の state-of-the-art を 23.1 から 50.2 へと飛躍的に向上させています。

今回は Onsets and Frames に音の消えるタイミング(Offset)を検知するネットワークを追加した上で、MAESTRO でトレーニングを行った結果、MAPS での F値が 67.4 まで向上したと述べています。また、MAESTRO のバリデーションデータでは、F値が 80.5 にもなったとも述べています。

MIDIデータでの作曲

作曲については、Google Brain が出した Music Transformer (Huang et al., 2018) を適用しています。これは、自然言語処理において Self-Attention の導入により圧倒的な性能を見せた Transformer (Vaswani et al., 2017)*2MIDIデータに適用したものになります。

定量的な評価が難しいからか、具体的な結果があまり述べられていませんが、こちら から Music Transformer のほうで公開されているサンプルを聞くことができます。特に、Piano-e-Competition Primed Samples として公開されているものは、黒鍵のエチュードをスタート地点として、全く異なるもそれっぽいような曲になっていて、聞いてみると面白いかと思います。

MIDIデータからの演奏再現

最後に、WaveNet (van den Oord et al., 2016) を用いて、MIDIデータからそれを演奏したような音声データを生成するということを行っています。簡単に言うと、WaveNet を用いたシンセサイザということになります。ここでは、MIDIデータから得られるピアノロールのような形式の行列を入力として、Conditional WaveNet で音声データを生成しています。

これも、公開されているサンプルを こちら から聞くことができます。論文中にも書かれているように、ホールの反響や奏者の息のようなものまで再現されているのが面白いです。また、コンクールの年によって録音環境が異なるために、音声データの途中で急に音色が変わるという現象があったらしく、入力の条件付け変数として開催年を追加することで回避できるようになったというのも味があります*3

まとめ・感想

大きなテクニカルコントリビューションがあるというよりは、データセットの公開がメイントピックとなっていますが、この規模の質の高いデータセットができたというのは、音楽情報処理分野にとっても大きな意義があるかと思います(特に、Google だからできたという部分もあるように感じます。)*4

また、Online Supplement の Alteration Samples にいくつか例がありますが、録音データからの採譜と演奏再現を組み合わせることでできる表現というのも面白そうです。ここでは、MIDIデータに採譜した上でピッチやテンポを変えて音声データに戻したものと、信号処理的に変換したものを聞き比べられるようになっていますが、データセットさえあれば、MIDIデータから楽器や音色を変えるということも可能になるんじゃないかと思います。

すでに Magenta チームは、Autoencoder で低次元の潜在表現を得ることで、8つのボタンのみでそれっぽくピアノが引けるという Piano Genie を公開していますが、機械学習によってどんな音楽体験が生まれていくのか、非常に楽しみです。

www.youtube.com

参考文献

宣伝

株式会社チームボックスでは「人の成長を可視化し、再現性を持たせる」というミッションに取り組んでおり、「芸術」や「学び」といった人の抽象的な領域に機械学習をもってアプローチする仲間を募っております。

www.wantedly.com

*1:参考: Open Review Explorer

*2:日本語の解説としてはこちらがおすすめです: 論文解説 Attention Is All You Need (Transformer) - ディープラーニングブログ

*3:Online Supplement の末尾で開催年の変数による生成結果の違いを確認できます。

*4:レビュアーも全員が同様に述べており、The engineering is carefully done, well-motivated, and clearly described. というコメントもあります。

ヒトの学びにテクノロジーを!

はじめまして、チームボックスのヤスニシです。エンジニア兼コーチをしていまして、プロダクトを作りながら色々な会社さんの組織づくり、マネージャー育成のお手伝いをしております。

さて、我々チームボックスでは、リーダー育成プログラムサービス「Teambox LEAGUE」を提供しています。

育成プログラムというのは基本的に人だけで行うサービスがほとんどですが、我々はテクノロジーも積極的に活用しています。講師(サービスでは監督と読んでいます)やコーチもいるのですが、テクノロジーも使って、様々な方面からリーダーの「学び」を後押ししているんです。

f:id:tsuyok:20171220133418j:plain
レーニング風景

そんな中で、ここ数年で開発してきたものに知見や学びが溜まってまいりまして、その辺皆様にお知らせできると嬉しいなぁと思い、エンジニアブログを開設してみました。今後月数回、チームボックスでの技術的取り組みや、エンジニアリングマネージャー向けのマネジメントのコンテンツなど、色々な視点で記事を書いてまいります!

今回は初ブログということで、チームボックスがどんな技術をどんな考え方で開発しているかをご紹介しますね。

チームボックスの技術的チャレンジ

f:id:tsuyok:20181206115302p:plain:w500
チームボックスの技術的チャレンジ

1.ドメイン駆動設計

「変更容易性」

チームボックスはまだ小さなベンチャーですが、今後の拡大や開発メンバーの増加を見据え、スピードとソフトウェア設計を両立していくことにチャレンジしています。そのために、ドメイン駆動設計を取り入れ、オニオン / レイヤードアーキテクチャでレイヤー構造を作りつつ、常にドメインモデリングリファクタリングを行いモデルを育てています。

スピードとソフトウェア設計を両立するのは時間的に厳しい部分はありますが、だからこそそこに「学び」があると思い、努力を続けています。

2.機械学習

「リーダーの分析」

リーダーの育成プログラムは、講師やコーチがこれまでの経験やスキルから、参加者がどのような状態か、今後どのようなアプローチをしていくと良いかを考えて提供します。属人化している部分が多いですし、人によってもスタイルが違い、なかなか再現性がある状態にできません。

そこで、チームボックスでは、機械学習の様々なアルゴリズムを使ってリーダーの状態分析にチャレンジをしています。テクノロジーの力を使って、定量的に分析し、講師やコーチのようにリーダーへより良い学びを提供できるよう努力を続けています。

アーキテクチャの考え方

アーキテクチャとしては、インフラやサーバ管理のコストを下げるためにもGoogle App Engineを採用し、マイクロサービス化しながら開発しています。

その中で、堅牢さが求められるユーザー基盤はKotlin、常に新機能開発を求められる部分はPythonで開発するといった使い分けをしています。フレームワークはPyramid, Vue.js, Spring Bootを使用し、どんな言語、フレームワークでもドメイン駆動設計を取り入れています。

【開発環境】

チームボックスのメンバー

f:id:tsuyok:20181206133704p:plain:w400
チームボックスメンバー(上記他10人ほどおります)

複業 / フリーランスの方など、様々な得意分野の優秀なエンジニア十数人関わっていただいております。社員は私とCTOの矢倉、CDO(デザイナー)のTehuですが、我々も複数の会社で働かせていただいていますので、フリーランスの方と同じような働き方になっています。

いつでも仲間を募集中です

いかがでしたでしょうか。何か面白そうだな、と感じていただいた内容はありましたでしょうか。

弊社自由な働き方を推奨しており、勤務時間も自由、働く場所自由、休暇自由、複業自由、となっておりまして、複業で一部の時間、フリーランス週1日など、どんな関わり方も可能です。

そのために契約方法も含めて、気軽に関わっていただけるような仕組みをご用意しています。是非お気軽にご連絡くださいませ!

www.wantedly.com