おおばログ

おっさんプログラマーのブログ。

キーボードとかスキャナの会社を退職しました

f:id:tworks:20180629224006p:plain

キーボードとかスキャナの会社を昨日退職しました。フリーランスの頃から勤務していて途中なんやかんやあって正社員になり、2000年から勤務していたので18年ちょっとお世話になったことになります。せっかくの節目なので、ログにまとめてみたいと思います。

何やってたの

システムインテグレーター(SI)を担当するシステムエンジニア(SE)でした。ざっくりいえば受託開発を行っていて、クライアントからオーダーメイドのシステム・アプリの開発を受注し納品するお仕事です。受注したあとは、社内リソースで開発するかリソースが足りない部分は外注(してマネジメント)するパターンが多かったです(よく聞く多段請負や外注さん丸投げはやらない主義)。

18年の中で、プログラマー → サブリーダー → リーダー(単一クライアント) → リーダー(複数クライアントかけもち)みたいな王道パターンを経験しました。

気づきのきっかけ

サブリーダーをやっていた頃、サブシステムの設計をすることが増えましたが、引き続きコードもよく書いていました。頃合い同じころに id:tmyt がグループ会社に入社してきて、グループ会社WANのIRCで相談に乗ってもらったりで助かっていました。そんなある日 id:tmyt がチャットでこんなことを書いたのです。
「おおばさんは開発者じゃないしなー」
何気ない id:tmyt の一言が俺を傷つけた?いいえ、彼はいつも忌憚のない意見をくれていたのでこのセリフも真正面から受けざるをえませんでしたし、その頃自分でも「開発者としてセンスがないな」ということに気づいていました*1。じゃぁどうしようか...コードを書くセンスを磨くか?他を目指すか?など、いろいろ考えるきっかけになりました。

どうしたか

コードセンスを磨くことをスパっと諦め*2、立ち位置を変えることにしました。id:tmyt のようなセンスの塊みたいな開発者が居たとして、彼らのパフォーマンスを最大限引き出し楽しく仕事ができるようにしようと、そこに対して自分ができることをやろうと考えを切り替えました。

具体的になにしたか

開発環境を良くする

開発環境=開発マシンを良くすることが手っ取り早いです。開発マシンの購入は人件費とくらべたら安いものですし、そもそも経費にできるので難易度が低いんですよね。その頃は自分で企画・提案書を作成してクライアントからの受注を伸ばしていたので、自分の意見が比較的通りやすい状況になっていました。そこを利用して半年に1回は新規マシンを購入し、自分のチームメンバーは3年くらいで最新スペックのマシンにローテーションできるようにしました。

開発者に丸投げしないことを肝に命じる

どんな開発者でも神様ではないので、決まっていないものに対して開発することはできません。でもこの業界、ときどき理不尽の風が吹きます。
「何もきまってないけど、スケジュールが決まっているから、開発走らせよう」
それは開発者にしわ寄せしているだけであってはならないことです。だから開発をお願いするまでに、次のことはキッチリやることにしました。

クライアントのことを透過的に伝える

このシステムを作る明確な理由・動機、機能の必然性・優先順位など、クライアントときっちり握ったあと、チームメンバーに丁寧に説明することを心がけました。誰しも開発するなら良いものを作りたいと思うのが自然で、そうであれば何が優先されるかを把握したいというのは心情ですよね。また開発側の提案や課題などをクライアントに説明し、必要な調整を行うようにしました。

設計に対するPoCと見積り

要件をもとに設計を行うわけですが「絵に描いた餅」の設計にならないように最低限の検証コードは自分で書くようにしました。自分でコードを書くことで、設計の勘所や課題が見えてきたりスケジュール感の根拠も作れるメリットがあります。センスが無いなりにでもコードが書けてよかったなと思いました。あとはインフラ設計(AWS/Azure)も出来るよう日々勉強しました。

信頼関係を築くことに手を抜かない

同じ会社のメンバーであっても社外のメンバーであっても所詮は他人同士。お互い信頼関係がなければいい仕事はできないと考えています。ですので彼らを常にリスペクトし、彼らの意見にできる限り傾聴し建設的に議論することを心がけました。

そのほか

外部設計をきっちりやる、詳細設計も開発者と相談して必要であればやる、スケジュールが想定とずれてきたらクライアントと調整する...当たり前のことを守ることを頑張りました。

結果どうなったか

某社のエースと仕事をして、そのプロジェクトが終わったとき
「これまでで一番仕事がしやすかったです」
という一言をもらうことができました。
f:id:tworks:20180630001858p:plain
自分のアプローチが少なくとも間違ってなさそうだな、と本当に嬉しい一言でした。

あれ?じゃぁなんで辞めちゃうの

受託開発が窮屈になってきたからです。次の「デメリット」の方を強く感じるようになったからですね。

受託開発のメリット

  • 自社プロダクト開発のように、特定テクノロジーにロックインされることが少ない
    • クライアントの数だけ新しいテクノロジーに触れるチャンスがあり、そこに挑戦することで、開発側の経験や知識を増やしていくことはできると思います(できました)。
  • 面白案件に関わるチャンスがある
    • 自分の場合、World WideなNDA案件に多数関わることができました。某DRMを使ったシステム開発で国内最初の人になれたりとか。

受託開発のデメリット

  • クライアントの望む以上のことができない
    • 予算にしてもスケジュールにしてもクライアントの都合が最優先されます。これは時にBestよりBetterな(もしくはそれ未満の)戦略を取ることがあるということです*3。開発側からみた場合、妥協したプロダクトが出来上がってしまうことが時にあるということです。
  • チームメンバーが固定しにくい
    • 案件によって規模や期間が異なるため、その都度メンバーを組み替えることが多かったです。これはアジャイルなどを用いたチーム成長をやりにくくする状態になります。

経験とともにキャリアプランが変化した

そうして経験を積んでいくうち
「固定されたチームを持ち、そのチームを成長させつつ、そしていいプロダクトを出し続けたい」
そんな気持ちが強くなったわけです。それは今の会社では実現できないため辞めることを決意しました。キャリアプランのミスマッチが出てきたわけですね。それが敵うであろう次の会社はすでに決まっていまして、来週からJOIN予定です。お約束の「試用期間」がしばらくありますので、そこが終わったあたりで状況をお伝えできればなと思っています。

謝辞

この場を借りて、転機のきっかけとなった id:tmyt と某社のエースさんに、御礼申し上げます。

おまけ - 上司や仲間に退職を伝えた時の反応

快く送りだして頂けた上司に感謝。

  • 上司A「そうか...新天地でも活躍期待してるからな!」
  • 上司B「今回は本気やな?」
  • 同僚A「お!ついにですか!」
  • 同僚B「えーーーーーっ!!!独立するんじゃなかったんですか...」
  • クライアントC「うちじゃないんですかイヤーーーーーーッ!」

*1:id:tmyt と比較すると "並の開発者はすべてセンスなしレベル" になるという話もある。

*2:いまもコードは書き続けていますが、チームビルディングなどの別の役割に時間を割くようにしました。

*3:ほとんどが政治的理由なもの。どうみても使いにくいUIに対し「これ絶対使いにくいのでこうこう変えた方がいいです」と提案しても、クライアント上層部が「OKこれで!」ってなると、クライアント企業のパワーバランスによりそのまま行くことが往々にあります。ここは何とかしたかった悔いの残るところです。

角から生えるやつ Windows版ができた

★ TL;DR

  • 角から生えるやつ Windows版ができた
  • 角から生えるやつ とは...
  • プログラムを公開するから、あとはみんなでがんばれ

★ 角から生えるやつ Windows版ができた

★ 角から生えるやつ とは...

こんなやつです。


先にmacOS版を作っていて、詳細は以下に書いています。
tworks.hatenablog.jp

★ プログラムを公開するから、あとはみんなでがんばれ

  • コードはgithubで公開しています。MITライセンスです。

github.com

  • 諸事情でコマ画像は公開していません。察してください。

角から生えるアイツ

この記事はラブライブ! Advent Calendar 2016 - Adventarの21日目の記事として公開されました。

f:id:tworks:20161220110726p:plain

★ TL;DR

  • ちょっとだけプログラミングの話
  • 愛おしいラブライブのキャラクターを身近に
  • プログラムを公開するから、あとはみんなでがんばれ

★ 私とラブライブ

ラブライブといえば、キャラ(アニメ・誌面)/音楽/声優さんの三位一体が成した素晴らしい作品です。私の場合は声優さんがキッカケで「南條さんが声優しているの!?」というところから入り、気づけば絵里推しとして大ハマリしていたのでした。じょるの尊い...。えりちふつくしい...。ちなみにAqoursは梨子が好きになりました。直前のスクフェスのイベント(梨子イベ)は60位に喰い込みました。愛の力ですね。f:id:tworks:20161220013938p:plain

★ 愛おしいキャラクターを身近に

さて、ラブライブを語るときに魅力的なキャラクターの話はつきものだと思います。そして私もそうですが「魅力的なキャラをもっと身近に!」という気持ちの方は、多かれ少なかれおられると思います。その手軽な方法の1つに、PCやスマホの壁紙設定があり、私は劇場版の特典色紙をスキャンしてPC壁紙にしていました。
f:id:tworks:20161219204145p:plain
えりちふつくs

★ 動かしたい?

こうして、PC壁紙のえりちを見るたびに癒されるわけですが、ある日思ったのです。
「これ、動かせないかな...?」
次の瞬間、隣でこんなことを言われた気がしました。
「やりたいからやってみる。本当にやりたい事って、そんな感じではじまるんやない?」
これはもうやるしかない。やるったらやる!

★ 作り方(レシピ)

材料
  • アニメーションのコマ画像を数点
    • 画像を綺麗に切り出すための熱いハートがあれば(最重要)
  • 透明なウィンドウ
実装
  • マウスカーソルの追従
  • 透明なウィンドウを表示(って見えないけど)
  • コマ画像をパラパラアニメの要領で透明なウィンドウに描画

★ 出来上がっていく様子

ここからはTwitterのPostで、カタチになっていく様子をご覧ください。

1.劇場版BDのエンディングシーンから素材を丁寧に切り出し、コマ画像を作っていきます。

2.試しに透明なウィンドウの上に、1コマ描画しました。この時点ではまだ動いていません。

3.アニメーション処理を入れてみました。それっぽく動いています。

4.マウスカーソルが左下に来たら、ピョコっと生えるようにしました。いい感じです。

5.アニメーション終了時にフェードアウト処理を入れつつ、アニメーション速度を調整しました。

作業時間はコマ画像切り抜き11時間/プログラミング1時間。そんな感じで出来上がっていくのでした。このアプリを常駐させておき、ふと疲れたときにマウスを左下にもっていくと...癒されるわけです(・8・)自分で作っておきながらですが、動くものを目の当たりにするとハァアァァルゥゥアァアショォォーーー!ホッコリしますね。

★ 下から生える

一度仕組みができてしまえば、アニメのコマの差し替え+アニメーション調整でバリエーションが増やせそうです。ということで早速...ヨーソロー!


★ そして駆け抜ける!

勘のよい方は気づかれたかもしれません。
「あなた絵里推しなのに、ここまで絵里要素ないじゃん!」
と。
「私だって、好きなことだけやって、それだけで何とかなるんだったらそうしたいわよ!!」
「ちょっと待って、別にやりたいなんて。大体、私がアプリになるなんておかしいでしょう?」
と言いたい衝動を抑えつつ、作成に入ります。


2期1話冒頭のシーンですね。こちらは透明なウィンドウを画面全体に表示し描画しています。ああ...えりちふつk

★ まとめ(主に開発者の方へ)

  • 「プログラムを公開してほしい」という声を各所からいただいてましたので、これを期に公開(OSS化)します。MITライセンスです。

github.com

  • 諸事情でコマ画像は公開していません。察してください。\ダレカタスケテー!/
  • 実装は動けばヨシの心でアニメーション処理はベタ書きです。気になる方はcloneするなりforkするなりして、カッチョよく実装してあげてください。pull reqを送っていただけると作者が泣いて喜びます。
  • 私の都合でいまのところmacOS版しかないです。Windows版は一度作りかけたのですが頓挫しています。以降の開発は https://twitter.com/od_10z に引き継ぎますので、リクエストは@od_10zへ出していただけるとスピリチュアルやね。

 →(12/22 Updated / Windows版もできたかも...githubからリポジトリ公開したら本Blogからもご連絡したいと思います)
  →できました。
tworks.hatenablog.jp


  • 「プログラムを公開されても俺には開発環境ないし...」という方は、開発できる身近な方を探してみてください(すみません)
  • 知人から「テクノロジーは変態によってこうなるのだ!」という名言を頂きました。み、ミトメラレナイワァ...

★ 最後に

本プログラムが少しでも皆様の癒しになれば幸いです。\ハラショー!/

課金コンテンツをAppleに預ける - How to implement "Hosting Content with Apple"

iOSアプリ内課金についての記事です。

前置き

iOSのアプリ内課金を実装するとき、プロダクト(課金アイテム)をどのように提供するか、検討が必要になります。そうはいっても採択できる方法は次の2つになるのですが。

  1. プロダクトをアプリに内包し課金後それが使用できる実装にする
  2. プロダクトをアプリ外(公開サーバ等)に配置し課金後にダウンロードし使用できるようにする

前者は、軽量なコンテンツを提供する場合や、課金アイテムの実体が要らない場合で採用されることが多いです。

対して後者は、比較的大きなコンテンツを提供するときに使われます。たとえばコンテンツがゲームの追加ステージの場合、ステージの画像データ、BGMなどが含まれるでしょう。それらをアプリに内包してしまうと、アプリのサイズが肥大化、アプリダウンロードに問題が生じる可能性があります(モバイル回線でダウンロード可能なiOSアプリのサイズは100MBまでです)。

例として、iOSアプリの「太鼓の達人」は、アプリ内課金で楽曲を追加購入することができ、購入後に楽曲データを公開サーバからダウンロードしています。
f:id:tworks:20140103181245j:plain

コンテンツ管理サーバを用意する?

さて、プロダクトをアプリ外に配置し課金後にダウンロードできるようにするためには、プロダクトの配置先となる公開サーバが必要になります。またプロダクトを単純に配置してしまうと、購入していないユーザもダウンロードできてしまいますので、正規購入者だけがダウンロードできるようなセキュリティーの実装(Webアプリケーションの実装など)が必要になります。
f:id:tworks:20140103182226p:plain
しかし公開サーバの運用は、多くの場合でコストがかかります。私もそうですが、個人の開発者にとってこれが足かせになることが多くあるように思います。そしてこれがボトルネックとなり、プロダクトの提供が思うようにできないことがあるかもしれません。

コンテンツ管理サーバが不要な "Hosting Content with Apple"

このボトルネックについてAppleが解決策を提供しています。ダウンロードさせるプロダクトをAppleのサーバに預ける(Hostingする)ことができる "Hosting Content with Apple" です。"Hosting Content with Apple" を利用することで、開発者は公開サーバの運用やセキュリティーの実装を省略でき、iOSアプリの開発だけに集中することができます。
f:id:tworks:20140103182948p:plain

続きを読む

現在サンドボックスでInApp購入を行う権限がありません。

f:id:tworks:20140103005324p:plain
iOS実機でアプリ内課金のテストを行っていた最中、
「現在サンドボックスでInApp購入を行う権限がありません。」
というエラーが表示され、テストができなくなってしまいました。

iTunesConnectの[Manage Users] - [Test User]を確認したところ、次の状態であることがわかりました。

  • テストで使っていたApple IDは以前は[Test User]アカウントとして登録されていた
  • ただし現在は[Test User]から削除されている
  • [Manage Users] - [Test User]からApple IDを削除しても、Apple IDそのものは削除されず、サインインすることは可能な状態になる
  • この状態でアプリ内課金をテストを行うと、前述のエラーが発生する

ここまでわかったので、[Test User]から新しいテストアカウントを作成し、無事テストを続けることができました。