技術的マイノリティプロジェクトで幸せに過ごすための5つの方法

この記事は freee Engineers Advent Calendar 2016 の 11 日目です。

こんにちは！freeeでエンジニアをしている @toshi0607です。アイコンよろしくnyanchuと呼ばれています。

僕は今、C#でWindowsのデスクトップアプリ開発を行っています。社内の大多数がRuby on Railsを使った開発を行う中でなおかつ少人数（時期によっては0.5人月、今はもっともっと）プロジェクト。この状況を「技術的マイノリティプロジェクト」と呼ぶことにします。

昨年のアドベントカレンダーにも書いた通り、エンジニアになって1年少しくらいの時点でのアサインは不安なこともありました。

• （型って何なん？）
• （レビューしてもらえるん？）
• （成長できるん？）
• （詰まったら誰に聞けばええんや？）

などなど。

そこで、この記事では技術的マイノリティプロジェクトでやってよかったなぁと思うことをシェアします。別に技術的マイノリティプロジェクトでなくても普遍的になるべきなのでは…？と感じることもあるかもしれませんが、そういうことはガンガン実行してみんなハッピーになればいいと思います( •̀ᄇ• ́)ﻭ✧

幸せに過ごすための５つの方法

1. 社外からも知見を

C＃、WPFでWindowsのデスクトップアプリを書く。色んなプラットフォームでの開発経験があるならまだしも、そもそも自分自身のソフトウェア開発の経験値が少ない中での開発。そもそもどう作ればよいかわからないことから、Widows OS固有の問題までわからないことだらけでした。たとえ社内的に聞いてわからなくても、この機能をリリースするためには乗り越えねばならない…そんなときに役立ったことを紹介します。

質問サイト活用する

わからないことは知ってる人に聞く！という王道です。

Ruby on Rails等社内的によく使われている言語と比較すると、Windowsデスクトップアプリだったこともありネットに出回っている情報が古かったり、少なかったり、そもそもないことも…。

そのような状況でも、質問を投稿すると翌日にはお返事が！ということが多々あり、何度命を救われたかわかりません…よく次の２つのサイトで助けていただきました。

漠然と書いても回答がつかないことがありますが、問題の最小単位まで考えて書けば大丈夫！

• teratail
• スタック・オーバーフロー
• 英語版の方が情報の量は豊富ですが内容が古いことも多い一方で、日本語版はオープンが最近な分？今も現役で使われてる知識が返してもらえる印象です。（今Stack Overflowで質問すればいいのか…）

識者を呼ぶ

自分で今直接書いてるわけではないけど、WPF詳しい知り合いいるよ！という同僚に紹介してもらっていろいろと知見をいただく会をセットしてもらいました。

Visual Studioのtipsから、一般的なサービス開発ではこうだがWindowsデスクトップアプリではどうすれば…？みたいな話まで様々な相談に乗っていただけました。

フルコミットでなくても、関わっていただく形は色々あるのだなぁ…と思いました。

敢えて発信する

わからないことを調べてたらある程度実装までたどり着くでしょう。でも、

• ほんとにこれって王道なのかなぁ？
• 自分の解釈正しいのかなぁ？今風の手法なのかなぁ？

みたいなときもあり、そんなときこそ敢えてQiita記事を書いてみると得るものがありました。

最低限の体裁のためにも体系的に調べますしね。

一例ですが、C#におけるasによるキャストと()によるキャストの違いという記事を書いたときには、「それは意味逆だ！」「こんなこともできるの知ってた？」というコメントをいただき知識を深めることができました。

最新情報を得るソースを確保する

社内のslackに"techmagazine"という、最新の技術情報記事がたくさんシェアされ、とても勉強になる部屋があります。駄菓子菓子、Railsやフロントエンド、AWS関連の話題が多く、その技術を使う人の数に比例している印象です。

つまり、

• 最新のC#7の機能は？
• Microsoftのイチオシ技術は？
• Windows界隈でホットな話題は？

みたいなのが追える感じではありません。

そこで、界隈で関連記事をたくさん発信してくださる方をtwitterでフォローしてリスト化し、雰囲気は何となく察することができるようになってきました。そして孤独感も和らぎます（きやすめ）。

僕が普段お世話になっている方々です！

C#とかMicrosoftとか界隈の人々

2. 困ったら困っている状況を具体的に伝える

どうしようもなく課題が山積し、優先順位付けしてもそもそもこれ一人でどうやって進めればええんや…みたいな局面がありました。

問題はあるけど、具体的な話をしても伝わらない、伝えられない。

そんなときにはチーム（Windowsアプリ開発がユニットでその一つ上の階層）向けに勉強会（という名の悩み相談会）をしました。内容は動作Demo（そもそも動かしたことある人あまりいなかった）、アーキテクチャ（はじめてシーケンス図的なもの書いてみた）、問い合わせ対応フローなどなど。

ドキュメントも準備して、そこで困ったことに対する助言をたくさんもらえました。

• こういう風にlogとればいいんでは？
• こういう運用に変えたら効率なのでは？
• そこは仕様なので仕方ないかも…

などなど。

具体的なコメントもらえる状況作りは要素技術というか、そもそも動作環境が異なるものを開発する上で大事なんだなぁと思いました。

3. プロジェクト・技術を一段抽象化する

C#、WPF、Windowsクライアントアプリは別のプロジェクトと違う！大変！どうしよう！となるのではなく、他のプロジェクト・プラットフォームとの共通点を探して参考にしよう！と考えることで、問題解決を進める糸口になることがたくさんありました。

###　モバイル

• クライアントアプリである
• freeeのapiサーバーと通信している
• 少人数である

みたいに共通点いっぱい！そのため、

• MVVM
• エラートラッキング
• テスト
• ビルド
• リリース
• API

だったり、界隈で流行りのXamarinってどうなんですかねぇ？みたいなところまで知見を共有し合うことでハッピーになりそうなこといっぱい！こちらからは情報提供できてないので何か役に立てたらいいなぁとか思ってます。

プロダクトマネジメント

ユーザが抱える課題を正しく把握し（正しい製品の定義）、それをいい感じに作る（正しく製品を開発する）というのはどのプロジェクトも共通！競争力の源泉！

ということで、プロダクトマネジメントチームが主催する勉強会に参加しました。

• テーマ: 『Inspired: 顧客の心を捉える製品の創り方』

• 内容: 事前に読んで感想と論点をまとめ、当日に議論

• 期間: 8/9〜11/8の毎週火曜日8:30〜9:30

• 社内他チーム（セールス、マーケ等開発でないチーム）のプロダクトへの考え方

• 自分がいかにユーザさんを知らないか

• プロダクトへのフィードバックを集める仕組み作り

• 導線まで含めてプロジェクトという意識

• 単に機能を作るだけでなく、実際にユーザさんが機能に気づき、意図通り使ってもらえる状態にするまで戦い抜く

等々それまでになかった観点を色々学んでプロダクト開発に活かすことができました。

ソフトウェア開発

プラットフォームはなんであれ、ソフトウェアを設計して、何らかのプログラミング言語で開発するのは同じでしょ！ということで、C#を使いつつも、「どんな言語で開発するにしても大切なことは何か」みたいなものを意識的に埋めていく時間を確保しました。

• 『C#プログラミング入門―「オブジェクト指向」の「プログラミング手法」を基礎から解説』
• 最初は基礎をしっかり。（これ読んだら全部わかるってわけではぜったいないけど、）オブジェクト指向ってなんだっけ…？も一緒に振り返ります。
• 『C#ショートコードプログラミング　第2版 短いコードで生産性を高める必修テクニック』
• こんな書き方便利！イディオムはこれやんな！みたいなのは実用性も高く、早いうちに一通り眺めるとよかったです。LINQとの出会いもここで、コレクションに対してここまで統一的なIF提供してくれてるのか便利。rubyとかってどんなやっけ？とか比べると面白かったです。
• 『C#逆引きレシピ』
• ファイル操作、数値と日付、文字列、コレクション操作等プログラミング言語では何やるにしても概念は変わらん…ということで、いちいち調べなくてもよく使うの覚えておけば開発は効率的になりました。
• 『増補改訂版Java言語で学ぶデザインパターン入門』
• イディオムとかよりもう少しレイヤーは上で、クラス間の関係のベストプラクティス的なのを知りたい…というタイミングがきたので勉強し始めました。C#なんとなく読めたらJavaもなんとなくわかるのでは？C#とJavaの言語機能比較したらC#もうちょい理解できるのでは？ということで、こんな連投を始めました（C#で学ぶデザインパターン入門）。まだ10個目とかですが、やっていく気持ちでやっていこうと思います。寄せられるコメントがためになり、インターフェースという概念が少ししっくりきました。
• 『C#実践開発手法 (マイクロソフト公式解説書)』
• デザインパターンと併読。一般的な概念、開発手法をVisual Studio等プラットフォーム固有の部分に統合していくためのものです。
• 『.NETのクラスライブラリ設計　開発チーム直伝の設計原則,コーディング標準,パターン』
• たくさんの人に使われ得るコード群の設計手法だけでなく、プラットフォームたるプロダクトの開発過程が書いてあってめちゃくちゃ面白いです！
• WPF4.5入門 その6 「WPFを構成するものを考えてみる」
• ことWPFにおけるXAML（Extensible Application Markup Language: 画面構築に用いるオブジェクトのインスタンス生成に特化したドメイン固有言語。XMLっぽく書く）は癖がある感じで、UIシステムはプラットフォームそれぞれで辛いなぁこれは割り切って覚えるかみたいな気持ちになりました。そんな辛みをかなり和らげてくれた記事（連載）です。

4.プロジェクト固有の話でなく、みんなの身近な問題であると考えらえる環境を整える

エンジニアはMacで開発する人が大多数で、その他のチームも比較的Mac使いが多く、Windowsアプリをヘルプページでしか見たことがない、という状況がありました。そうなると、

• 問い合わせ対応し辛い
• 機能が追加されても実感がない
• 社内的なフィードバックが得られない
• 開発者のみの目線から広がっていかない
• 開発上の課題、特にUIや使い勝手関連が共有し辛い

となってしまい、ほんとにいいことがありませんでした。

そこで

• 社内的にみんなが触れる（リモートアクセスできる）環境を準備する（触ったらフィードバックをもらえるフォームがある）
• サポートチーム朝会に動作Demoやよくある問い合わせのプレゼンをしにいく
• 社内の全体集会やエンジニアの集会で開発過程や成果を共有する・してもらう

というのをやりました。これはまだまだ取り組んでいる途中ですが、「社内の人 = 自分が開発するサービスをよく知っている」という状態には勝手にならないことを実感しました。

5. 課題に正しく向き合う

リソースが限られているからこそ（限られてなくても）、

• どんな課題を解決しないといけないのか？
• 何を達成したら成功と言えるのか？

を突き詰めて考えることはより重要になります。

• UXを高めたい
• 登録ユーザを増やしたい
• 競合サービスよりこの部分で勝ってると言いたい

などです。

そのために追い求める数字を議論し、可視化し、毎日追い、その上で打ち手を考えるというプロセスを愚直に進めることはとても効果的でした。

たとえば**「UXを改善する。そのために、問い合わせ内容を分析して多いものから施策を打ち、カテゴリ別に問い合わせ数をトラッキングする」**みたいな進め方です。

施策の効果の有無は可視化されているので（サポートチームのみなさんに協力してもらいました）
、施策の様子を見守ればいいのか、別の打ち手を考えなければならないのか判断が早くなるし、特定の条件下で問い合わせが減ればユーザの利便性は向上しているとみなせるし、問い合わせが減ること自体もハッピーです。

KPIは大事な指標ですが、結局KPIでしかないなので最終的に解決したい課題が解決できているのか確認するのを忘れずに…

何となくいい感じがする、技術的に楽しいけど、問題解決に何一つ寄与しないサービスなんて僕は作りたくないです。仕事では…

まとめ

• 技術的マイノリティと言えども、技術はオープンになってる、オープンにしようと努力する人々がたくさんいるので界隈みんなで高め合っていけたらいいですね！
• 技術的マイノリティと言えども、違いばかりに囚われず共通点を探すといいことがありそうですね！
• どんな技術を使うか以前に、問題を正しく把握し、解決できているかどうかに集中したいですね！

というお話でした。

このプロジェクトを経て、まとめの3つ目をより強く意識するようになりました。

どんな技術を使っているかではなくて、ちゃんとユーザに価値が届いているか。

技術の種類はもちろん、技術の高低もユーザにとっての価値とは比例するとは限りません。

ただ、高い技術を使った技術がより大きな価値を届けられるならそれは身につけられるよう努力したいし、高くない技術であるほど模倣される（ユーザにとっての価値が低くなりやすい）ので絶えず磨き続けていく所存です。

おさそい

というわけで、freeeでは一緒にちゃんとユーザに価値を届けていく仲間を募集しています！

freeeの採用ページもぜひぜひご覧ください。オフィス見学やゆるっとお話も大歓迎です！

さいごに

明日は入社前にして既に様々な技術を使いこなしユーザへ価値を届けているfreeeのホープ、 @taiyo です！おたのしみに(｀･ω･´)ゞ