メリークリスマスイブ！ 皆様クリスマスイブはいかがお過ごしですか。
データサイエンス部所属のエンジニア 笹島 
id:sisijumi です。
年末ということもあり、今日は一休という会社のエンジニア組織の変遷を振り返るとともに、現状に関してもお話させていただきます。 （現状はデータサイエンス部ですが、今年の10月までは宿泊事業部のエンジニアのマネージャーをやっておりました。）
一休における収益の変遷
宿泊事業に関してですが、過去発表した資料を元に説明させていただきます。 （近年非上場になった為、直近の収益に関しては資料はありません。）
創業期、成長期を経て、一時停滞したものの、きちんと再度成長していることがわかりますね。
事業のステージに合わせて変化してきました
創業期、成長期を支えてきた組織構造
各部署内に宿泊・レストランチームが存在しています
各部署が都度エンジニアのマネージャーとコミュニケーションと会話して開発を進める、というスタイルになっています。
この頃、中心となるマネージャーがボトルネックになってしまうと開発の全体のスピードが遅れるという課題がありました。 また、宿泊予約やレストラン予約等それぞれのサービスがより成長し、上記の開発スタイルがそのスピード感にマッチしなくなってきました。
再成長を支えた事業部の設立
それぞれのサービスをより成長させることへコミットできるように、一休という会社としても事業部制への移行を実施しました。 それとともに事業部毎にエンジニアを配置する形に変更になっています。
事業責任者とエンジニアのマネージャーでプロダクト開発優先順位を意思決定し、開発メンバーを調整するという流れでした。 以前の形と異なる点は、エンジニアのリソースをどう活用すれば事業の成長に最も寄与できるかをきちんと意思決定しながら開発を進めている点です。 （以前の形では依頼ベースで開発を進めてしまうところがあり、事業の成長に最も寄与するためのエンジニアのリソースの配置をどうするか、という視点が欠けていたと思っています。）
目的型組織への移行
ミッション毎にプロダクト開発チームの枠組みを作りました
事業を成長させるためのミッションを作成し、ミッション毎にチームを配置しました。この形にすることで、それぞれのチームごとにミッションに集中できる構造になっています。
以前の形ですとビジネスオーナーとエンジニアの間にエンジニアのマネージャーが間に挟まってしまい、不要なコミュニケーションが発生してしまっていました。ビジネスオーナーとエンジニアの距離をより近づけることで、開発時のコラボレーションがより活発になることを目指しました。
事業部長が作成したミッションごとのチームそれぞれで、プロダクト開発が進む体制になっています。 この構造においては、マネージャーはエンジニアを後方支援する形になっています。また事業部長とのコミュニケーションも何をやるかではなく、事業の成長に各ミッションへのエンジニアのリソースは最適化できているか、という視点が主になっています。
最後に
エンジニアの枠組みとしてこうあるべき、というビジョンも必要ですが、それに囚われずチーム構造を柔軟に変化させる必要があります。
自分がマネージャーだと、現状のチーム構成から変化させることに心理的負荷はやはりあります。（チームでやってもらっているメンバーにきちんと説明し、合意をした上できちんと進めないといけないということが頭をよぎり、反射的に反対することもある）
しかし、今の立場に縛られず現状の事業をどうやって伸ばすか、成果を最大化させるためにエンジニアチームでやるべきことはなんなのか、など事業にきちんと貢献できているかを客観的に継続的に判断する必要があります。事業的な成長をプロダクト開発において牽引していきたいと思います。
明日は 
id:ninjinkun の iOSとAndroidの段階的リリース機能を比較する です
