さて、今日も freee advent calendar やってまいりました。

freeeの CEO の佐々木です。今でこそ CEO 業にフォーカスしている訳ですが、会計ソフトfreee をリリースして世に送り出すまでは完全に微力ながら僕も第一線でコーディングしていました。僕の職歴は、ほぼほぼマーケティングとファイナンス（あと、ちょっとだけデータ分析）なのでエンジニア経験がある訳ではないのですが、起業したいという人に「どうやって勉強したんですか？」とよく相談を受けたりもするので、思うところを共有してみます。

#まず、こんな人が向いてるんじゃないかと思う
とりあえずシンプルでよいので目的に沿って動くプロトタイプ的なソフトウエアをつくるということは、次のような条件にひとつでもあてはまる人であればひとまず素養はあるのではないかなと思う。（大規模に展開する商用のソフトウエアの開発やメンテナンスの場合はまた別の話で、それは専門家にお任せ）

台本や脚本のようなものを書くのが好き（特に非常に似てると思う）
ゲームやってたらいつの間にか朝になっていたことがある
高校で数学Aは比較的得意だった
掃除が得意（ちなみに僕は苦手だが、もし得意だったらもっといいものつくれたんじゃないかと思う）
契約書をつくるのが得意である
スポーツ競技などでセットプレーの作戦を立てるのが得意である（将棋やチェスなども同じか）
イベントの進行表をつくるのが得意
Google 検索と仲良しである
英語の読み書きが得意（英語で検索すると簡単に答えがみつかることが多い）

他にもいろいろあると思うので、何かピンと来る人はぜひぜひ挑戦されたし。

「何をつくりたいか」に尽きる

キャリアとしてのエンジニアを志す訳ではない人が、コーディングを覚えようとしてもすぐ挫折する一番の原因は、「とりあえず勉強してみようとする」ことにあるのではないかと思う。僕も何を隠そう、今までの人生の中では何度か漠然とプログラミングの本を買って、勉強しようとしてみたことがある。そして、そのことごとくは失敗に終わった。

一方で、「この問題を解決したい」、「こういうものをつくりたい」という意志が明確にあるときに、プログラミングを勉強しようとするのではなくて、手段を問わないのでとにかく実現するというスタンスで臨むと、自然といろいろと理解できたり覚えたりできるものである。

いくつか僕の人生に訪れた、「こういうものつくりたい衝動」の例を紹介しよう。

膨大な調査データの集計作業

僕は学生のころ、マーケティング調査のスタートアップでインターンをしていた。当時は、まだ駅前で調査員の人たちが、「アンケート調査協力お願いします」というようなことがされていた頃で、それをインターネットに置き換えてしまおうというビジネスであった。
オペレーションも黎明期であったその会社では、回答してもらったアンケートデータのデータ整理や集計可能なデータへの変換をエクセルを使ってやっていたのだが、これが非常にタフな仕事であった。何度かその仕事を経験して、「もう二度とやりたくない」と思った僕は、エクセルのマクロとやらを使えばこの業務は自動化できるのではないかと思い、当時の社長に、「この仕事はもうやりたくないので、かわりに自動化するツールを開発する時間をくれないか」という提案をした。言ってしまったので、やらなきゃいけない。とりあえず、エクセルマクロ（VBA）の本を買ってみたのだった。

レコメンドエンジンの開発

僕はキャリアの中で、レコメンドエンジンの会社でCFOをやっていたことがある。資金調達をする傍ら、今後の事業戦略を考えていると、汎用性が高く、スケーラブルなプロダクトの必要性を強く感じ、そのような方向に沿ったプロダクトの構想を練ってみた。しかし、当時、実はB2B向けのレコメンドエンジン事業以外も抱えており、社内のリソースをこちらのスケーラブルなレコメンドエンジンの開発に差し向けられない事情があったのだ。僕はしびれを切らして、少なくともデモに使えそうなプロトタイプを週末などにつくってしまおうと思った。これは目的がはっきりしていたため、意外とすんなりできた。「PHP+MySQLでECサイトの開発する」的な本を買ってきて、書いてあることにしたがってそのままつくった商品詳細ページに少しコードを足して「これを見た人はこれも見ています」というリストを写真つきで表示させるだけのシンプルなでもだったが、見た目的には未来を感じさせるようなものができて、社内も「これならいけそう」というイメージを持つことができ、大きく事業転換を実行するきっかけにもなった。

全自動のクラウド会計ソフト freee の開発

freee のようなプロダクトをつくれないか、と思い始めたのは、まだ僕が Google にいる頃だった。中小企業向けに広告プロダクトのマーケティングを担当していた僕は、日本の中小企業向けにオンライン広告を広めていくだけでなく、よりビジネスのベースとなる部分でテクノロジー活用を進めていく取り組みの必要性を痛感していた。日本では中小企業の web サイト保有率は低く、他の先進国と違って Fax がメインのコミュニケーションチャネルとなっているような状態である。そこでふと、スタートアップでCFOをやっていた頃に、経理の業務が大変で、より新しいタイプの会計ソフトをクラウドでつくれば、もっと経理の業務を効率化できると考えたことを思い出した。そこで、Googleで調べてみると、会計ソフト業界にはその時点でもまだイノベーションがまったく起こっていないことがわかった。
さらに考えてみると、単に「会計ソフト」というと小さな話に聞こえるが、「あらゆるビジネスに経理は必要」という視点でみれば、会計ソフトにイノベーションを起こすことで中小企業のテクノロジー活用度を一気に塗り替えることができるかもしれないし、中小企業をネットワーク化し、B2Bの取引のあり方自体に変革を起こしたり、また、いつか人工知能がCFOサービスを提供するなんてこともできるのではないかと考えると、これはとてつもなく大きなことだと思うようになった。もちろんそこで再び「すぐ、これをつくりたい」という情熱が湧き、まず Rails の本を買って一通りのサンプルをつくりあげたあと、早速具体的にプロトタイプをつくりはじめた。

まとめると

要は、プロのエンジニアではない状態でプログラミング自体を勉強しようと思っても、片手間でやっているとよほどの人でないと失敗する。より重要なのは、「具体的につくりたいものを持つ」ことであって、それがあれば、勉強も圧倒的にカンタンになるし、最短距離でそれを実現することができる。もしくは、職業エンジニアの門を叩くべし。
（ちなみに、本気で商用化するときはプロと一緒にやるべし）

エクセルVBAではじめるカンタンプログラミング体験

とはいえ、「いつか何かに情熱を持ったときのためにプログラミングを勉強しておきたいんだ」というあなたに、おすすめなのはやはりエクセル VBA でマクロを書くことだと思うので、きっかけがてら簡単に紹介。（エンジニアの人は読み飛ばしましょう）

なぜエクセルVBAか

あなたのPCにエクセルがインストールされていれば、開発環境のセットアップは不要。
解きたい課題がみつかりやすい。大学でも職場でも使う機会は多いはず。「よくやるこの作業をもうちょっと自動化するアイデア」はデスクワークを主にしている人手あれば結構たくさん出てきやすいのではないか。
マクロ記録すごい。マクロ記録により、コードで表現したい動きをどのように書いたらいいのか簡単にわかるので学習コストが低い。

ではさっそくやってみよう

マクロ記録してみる。

セルD6のフォーマットを％にして、赤字で100%と入力する。

Visual Basic Editor を開いてみると、こんなコードがすでにかかれている。これが、あなたの今やった動作を VBA で書くとこうなるというもの。

Sub Macro4()
'
' Macro4 Macro
'
    Range("D6").Select
    Selection.Style = "Percent"
    ActiveCell.FormulaR1C1 = "100%"
    Range("D6").Select
    Selection.Font.ColorIndex = 3
    Selection.Font.Bold = True
End Sub

なので、上記のコードを実行すれば、セルD6に赤字で100%と入力することができる訳。

それがわかれば、指定されたセルにどんどん赤字で100%と入力するようなプログラムをどんどん書いていける。

Sub Macro4()
    Dim i As Integer
    i = 2
    Sheet1.Activate
   
    Do While Cells(i, 1).Value <> ""

        Cells(Cells(i, 1).Value, Cells(i, 2).Value).Select
        ' 2行目から、1列目・2列目に書いてある数字を行列とするセルを選択して
        ' マクロ記録の結果をつかって、100%を太字の赤文字で記入する
        Selection.Style = "Percent"     'マクロ記録そのまま
        ActiveCell.FormulaR1C1 = "100%" 'マクロ記録そのまま 
        Selection.Font.ColorIndex = 3   'マクロ記録そのまま
        Selection.Font.Bold = True      'マクロ記録そのまま
        
        i = i + 1
    Loop

End Sub

僕が最初につくったアンケートデータ集計プログラムはこんな要領で、マクロ記録を組み合わせながら

集計仕様セルを参照して、集計すべき列を集計シートにコピペする
集計シートでピボットテーブルをつくって集計する
集計結果を結果シートにコピペする
1.に戻って最後までいったら終わり

という感じで、主要な処理は全部エクセルの機能をそのままつかって目的を実現することができる。（もちろん、とっても遅いのですが、なんとかこれでも大きな効率化につながった）

自分もコーディングしてみてよかったこと・悪かったこと

よく聞かれるので、最後に起業家として、自らコードを書いたことでよかったこと悪かったことなどまとめてみる。

よかったこと

「もし自分で開発していなかったら、リリースまでの9ヶ月間何をやっていたのだろう」と考えると、あんまり有効な時間を過ごせなかった気がする。最短でプロダクトをリリースするために効率的な手段であったと思う。
その後のチームの一体感。リリースまでの間にどっぷり開発につかることで、今でもおおよそ、開発チームの話がそのままの言葉でも理解できるし、どんな課題を抱えていて、それがどう大変かなどがイメージできる。これは、会社全体の一体感やビジネス推進の上でとても重要だと思う。そして何よりその方が楽しい。
Hard Things に書いてあるように、一度どっぷり自分でエンジニアをやってみることはその後、採用などにも取り組んでいく上でとてもよかったと思う。
エンジニアの打ち上げに行ける

悪かったこと

リリース後、コード書くのやめた時に、「コード書いてた方が楽しい」と思ってしまったことがある。また、いつかどっぷり浸かりたいと思う。
まだチームが小さかった頃は、エンジニアの話がわかるが故に開発チームに対して細かすぎる時期があったかなと思う。
もしかすると、プロダクトのリリース直前などで、もっとベータテスター増やすとかそういうアプローチにもっと投資ができたかもしれない。（ただ、実際にはリリース後にソーシャルメディア等でいただいた改善要望を忠実にこなしていくことに支えられてここまでくることができたので、たられば論ではある）

まとめ

ということで、なんだかんだ言って、いいことの方が大きいんじゃないかなと思う。人生に彷徨えるアナタ、まずはエクセルと向き合いなさい。

ということで明日は

FinTech Challengeで優勝を果たし、これまで freee 史上最も多くの職種をこなして来たバーコード男こと＠fuji-tipが、世界の車窓をご案内します。

お願い - 僕のコードを書き換えてください

githubによると、まだまだ僕の追加した行数は freee のエンジニアの中でも上位15%に入るようです（要はいらないものを書いたり消したりしてたのだと思いますが）。「ドシロウトの創業者のコードを徹底的に書き換えたい！」、そんなアツい想いを持った方、ぜひこちらまで。