舩木俊介「かつて未来とよばれたソサエティ」

スーパーソフトウエア東京オフィス代表&キッズラインCTO

2015年は良い一年だった。

クライアントのiOS, Androidアプリ、ウェアラブルデバイスのアプリを次々と開発してリリースする一方で、毎月入社するくらいの勢いで採用した社員にSwift, Ruby on Railsなんかの研修を徹底的に教え込む「創る」と「育てる」がテーマだったと思う。

ミーティング、クライアント訪問、営業ディレクション、開発ディレクション、研修のチェックと、ほとんど1日中喋ってばかりの日々。いつもオフィスで流してるJ-waveも今年はほとんど聞いてなかった。時々、じっと黙ってデスクに座って、プログラミングしたり研修課題をつくったりという日があると微妙に嬉しい、というくらい、まさかの体力勝負な1年だった。

まあ、なによりQ3半ばで早くも今年度の予算達成が見えてきているのが素晴らしいところ。酒が美味い。積めるだけ積んで来期はいろいろサービスをリリースしていきたい。

カラーズも、キッズラインをリリースして大きな反響を頂き、社内では強力なエンジニアが育っていいチームが出来た。毎日のように状況が変わり、またプレッシャーも多いベンチャー環境で、フットワーク軽く開発を進められるエンジニアというのは世の中でもあまり多くない。そういうエンジニアが集まり、チーム文化が出来たのは何より良かった。


 
企業は人だというけど、まさにそれ。人が全て。

ただ実は、人がいれば誰でもいいわけではない。当然ながら優秀な人間が何人いるかでその組織の未来が変わる。優秀な人というのは、飛び抜けた天才的な能力を持っているというわけではなく、ある程度のビジネス能力と人格を備えているというだけだ。

個人の成長は大切。ただ、個人で戦える分野というのは思っているほど多くない。何かちょっとした仕事をしようと思えば、相手がいて周囲の仲間がいて、人の中で仕事は進んでいく。

イーロン・マスクも「才能より人格を重視する」と言うように、
知的能力ばかりを重視してしまって、その人物が周りにどのような影響を与えるか考えなかったわけです。企業への貢献において鍵となるのは、人柄であり、周囲の人たちに与えられる影響です。 ( http://logmi.jp/69117)
どれだけ実務能力が高くても、周囲に与える影響を計算できない人が多いとレベルの低い組織になる。

あと1つ付け加えるとすれば、結果に責任を持つ人かどうかがポイント。言われた仕事を真面目にするが結果に責任を持つ意識が薄いという人は、組織にいない方がいいタイプで、自覚があってもなくてもその無責任さからチームを簡単に崩壊させる。

という3点に気をつけて、何人もエンジニアを面接して採用してという2015年だった。



これからの社会はエンジニアがより必要になる、エンジニアがもっと活躍する社会になると言い続けていて、2016年はもっと大きな声で言おうと思う。それは、いま起こっている数々の社会的な問題に対して、エンジニアならもっと上手く解決できるんじゃないか、という意味がある。

機械学習、AIというのはバズワードになってしまって玉石混淆だけど、本質的には人間が気づかない洞察を得られるとか、より便利になるための道具だ。ECというベーシックな仕組みでさえも、スマホやレコメンドという道具で発展の余地はいくらでもある。ElasticsearchでMahout Tasteを噛ませてみるとか、いまだったらMicrosoft Azure MLにデータ投げてモデルを構築するとか、優れたオープンソースやサービスも数多くある。

日本が競争力や生産性を上げていくには、エンジニアが新しい価値や競争力を生み出せるかにかかっている。マーケットに素早く投入してフィードバックを得てプロダクトのサイクルを回していくべきで、企画や書類を練り回してても答えは出ない。それくらいのスピードが求められる時代なので、創れるエンジニア(エンジニアって創れる人ばかりではないので)をもっともっと増やしていきたい。

2016年は、プログラミング教育や、もっと人を笑顔にするサービスや機能のリリースをどんどんしていきたいと思います。

 
 
 
IMG_1812_2
IMG_0354_2
IMG_1765_2
IMG_0899_2
IMG_1803_2
IMG_2079_2
IMG_1739_2
IMG_1268_2
IMG_0895_2
 

今週は月曜朝イチから埼玉に移動して打ち合わせ、恵比寿に戻り面接、六本木でミーティングをして、また恵比寿で面接、そのあと開発やディレクション、プログラミングの社員教育。

火曜は面接2件して、ちょっとしたプロトタイプのアプリを開発、健康診断がヤバい結果(酒飲みすぎ)だったので社員を笑わせつつ、夜はアプリUI・デザインのディレクション。

今日は営業、システム設計のミーティングをして、このあと横浜で古くからの取引先の方々と会食。

2015年も終盤になってきて、今年もかなり数のクライアントのアプリ・システムをリリースしてきた。

最近は、新規事業開発のブレーンとしてコンサルティングから入ることが多く、ニュース系や、ソーシャルメディア系、ウェアラブル系など、ゲーム以外のスマホアプリは色々作った。IVS優勝のキッズライン、結果として2000万人くらいが利用したウェブシステムも無事リリース、SESでは自動車関連や国の情報システムも作っている。

僕が企画している何本かのアプリも早く開発したいと思ってるけど、なかなか忙しいのでエンジニアをもっと増やしたいところ。

人材会社は「エンジニアは競争率が高くてなかなか・・・」と、もうこのトークは何十回も聞いているので自分で人材営業できるくらいに覚えたんだけど、この繰り返し。エンジニアっぽい人で我慢しなさいくらいのことを丁寧に笑顔で仰る。僕も気が短いので、「エンジニアがいないんじゃない。出来るエンジニアがいないんだ。」と分けわらんこといって、ハードル上げて余計に話がややこしくなる。


現場の開発は、クライアントによって進め方はバラバラだったりするけど、アジャイル開発が多い。まあ、ウォーターフォールとかアジャイルとか開発手法はどうでもよくて、リアルに現場にいる人間としては、満足度のある完成品ができればそれでいい。

ただ、アジャイルと言いつつスプリントやレビューも合意せずに進めざるを得ないことが起こったり、混沌する場合もある。

なので、一度じっくりと開発手法を考えてみていると、ソフトウェア開発というのはQCDSの法則に縛られている。

● 品質(Quality)
● コスト(Cost)
● 期日(Delivery)
● 範囲(Scope)

というのがQCDSで、この4点が作る四角形の面積は必ず一定になる。

期日に無理をして進めると、品質とコストと範囲が必ず犠牲になる。他もまた同様。

このため、プロジェクトを円滑に進めるためには必ず日々の意思決定が必要になる。

ある機能や画面に対してユーザがどう思う可能性が最も高いのかから、何を実装するか、何を実装しないか、コストを犠牲にしてリソースを増やすのか、など。

いくらプログラミングを頑張っても、プロジェクトチーム内で意思決定をする意識が希薄であれば炎上したり、QCDSの法則に従って誰かが傷つく。それがユーザである場合は最悪のケースとなる。

ソフトウェア開発において、生産性と意思決定というのは相関関係ではなく、因果関係だといえる。

そこで、開発手法によって解決しようというのがアジャイルとかスクラムとかになるわけだけど、本質的には、アジャイル的なフォーマットを守ればいいというより、ポイントとなるマイルストーンを正しく実行するガイド役だとすると扱いやすい。

あとはTrelloGithubSlackで日常業務として落としていけば、仕組み化できる。

というのを社内Wikiにまとめようとしていて、まだ出来てない。

そういえば社内Wikiで、社員教育用の僕が書いたコードをリストアップしてると、変なものがいっぱい出てきたので、コードを見たい人はうちに入社してください。


OpenCVによる人物検知プログラム、OpenFrameworks ペリンノイズ、笑顔判定プログラム、顔移植プログラム OpenFrameworks v0.7.4、Python Naive Bayes、iOS ミュートシャッターカメラ、笑顔認識カメラ、OpenCV  顔以外の検出、漫画カメラ デジタルサイネージ openframeworks v0.8.0、iOS Swift サンプルメモ帳、iOS Swift プッシュ通知サンプル、OpenCV 二値化 大津の方法サンプル、Cinder Particle、画像自己組織化マップ、openFrameworks optical flow、vector fields - openFrameworks、openframeworks 0.8.1 ios camera app、WebSocket Chat、遺伝的アルゴリズム、Unity 3Dウォーターフォール、Matrix Cam openFrameworks、Flow Tool openFrameworks、ピクセルアート openFrameworks、iOS iBeacon デモ、Bag of Features、Bag of Features ヒストグラム、Processing パーティクル、Processing OpenGL



bsPAK86_codeing20140517


ディープラーニングの動きが手軽に試せるようになって、ソフトウェアエンジニアは遊びに困らないですね。Googleのディープドリームはものすごく気持ち悪い絵を生みだす、LSDでぶっ飛んだ世界をみるだけだったけど、名画のスタイルを学ばせて写真から絵を描く「Neural Style」はちょっと楽しい。

実際にやってみた結果はこんな感じ。何気ないネコの写真を、山口素絢、クロードモネ、Bochaton EMMANUELLE、それぞれの画風を学ばせて描かせたもの。個人的にはサイケデリックな最後の絵がかなり好き。
ns1

Neural Style


Wiredの記事「どんな写真も「巨匠の名画」風に変換するアルゴリズム」にもあるように、ゴッホやムンクのスタイルを自分の写真にあてはめることができるアルゴリズム。

論文は「A Neural Algorithm of Artistic Style - A Deep Neural Network that creates artistic images of high perceptual quality」で、実装もgithubで公開されている。

The system uses neural representations to separate and recombine content and style of arbitrary images, providing a neural algorithm for the creation of artistic images.

畳み込みニューラルネットワークによって、絵画のコンテンツとスタイルを分離することができる、というところがこのアルゴリズムのポイント。早速、EC2で動かしてみた。(gistにも手順まとめておいた

AWS EC2でNeural Styleの環境構築


EC2でGPUインスタンスを立てる。例によって、g2.2xlargeでCUDAを使う。環境構築ができているAMIを配布してくれている方がいるので、ami-ffba7b94からインスタンスを作成する。(インスタンス作成ウィザード

いつも通りubuntuにログイン
$ ssh -i yourpemkey.pem ubuntu@ec2-public-dns-name

アップデートしておく。
$ sudo apt-get update
$ sudo apt-get upgrade

そのままではcudnnがR1になっているようなので、R2にアップデートしておく。
$ cd cudnn-6.5-linux-x64-R2-rc1
$ sudo cp lib* /usr/local/cuda/lib64/
$ sudo cp cudnn.h /usr/local/cuda/include/

モジュールをインストール
$ luarocks install image
$ luarocks install loadcaffe
$ luarocks install torch

Neural-styleとモデルを準備する
$ git clone https://github.com/jcjohnson/neural-style
$ cd neural-style
$ sh models/download_models.sh

これで完了。AMIのお陰で、10分くらいで出来上がるほど超簡単。実行コマンドは、
$ th neural_style.lua -num_iterations 2000 -style_image style.jpg -content_image image.jpg -image_size 400 -backend cudnn

で、イテレーションが繰り返されて画像が出力される。

色んな絵画の画風で試してみる


どういう動きをするのか、いくつか試してみると、スタイル画像からPhotoshopでいうブラシのような感じで写真にあてはめていくイメージ。それっぽいよね、という絵になる。あくまでスタイルを分離して、新しい写真にあてはめることが整合性のとれたレベルで実現できる感じ。当然だが、新しい芸術を生みだせるわけではない。

イテレーション回数2000で、サイズを400pxくらいにしておくと、1画像当たり20分くらいで完成する。

伊藤若冲「樹花鳥獣図屏風」
out001
伊藤若冲「紫陽花双鶏図」
out002
伊藤若冲は確かにスタイル画像を使ってはいるんだけど、結局のところ、伊藤若冲の繊細綿密な表現ができるわけではないのでイマイチ。

月岡芳年「郵便報知新聞」
out003
歌川国芳「甲越勇将伝」
out004
江戸時代の絵なのに血みどろ現代風イラスト、といった意外性が大人気の芳年と国芳。これはなかなか雰囲気出てる。

クロード・モネ「散歩、日傘をさす女性」
out006
山口素絢「朝顔狗子図」
out007
元々のスタイル画像が上手く生きるタイプで、雰囲気はそのまま。

Bochaton EMMANUELLE「clin d'oeil à Picasso」
out005
ポップアート的なのもイケるとは。

↑このページのトップヘ