CTOって何なんだ
こう思った理由
僕が考えるCTO
私なりの解釈ですが、CTOは経営層に近い仕事なんですよね。実際に私はCo-Founderであり、取締役です。 その立場を活かして、テクノロジーをどう経営に活用するか、それによっていかに会社の価値を上げることができるかという点だと思います。
技術を活かして会社、組織の価値を上げていくということが必要なんだと思います。これ、心底そう思います。マジです。やばいです。
根底にあるのは信頼関係だと思います。組織を導く役割が求められている以上、「あの人があそこまで言ってくれるなら。。。」と思わせる必要があります。
そう思うには、今まで積み上げてきた実績、なによりそれに基づいたその人に対する絶対的な信頼感が必要だとおもいます。誰よりも手を動かす人であるべきだとも思います。
そもそもなんでこんな話をしてるか
- CTOとして組織を導ける強いエンジニアになりたいから
- フルスタックなエンジニアになりたいから
- すごい人に会うことが多くて、最近エキサイティングすぎるから
- 現場が少しずつ変わってきているから
- 休み前にGWにしっかり考えてきてほしいと言われたから
システム開発のトレードオフに関して
システム開発においてよく言われている
「トレードオフ」
について考えることがありました。
開発において大事にすべき要素(僕が大事にしていること)は
- スピード
- クオリティ(+セキュリティ)
- フレキシビリティ
です。
よく「何かを取れば何かを捨てないといけない、そこはトレードオフだよ」 と言われます。(何を隠そう、僕も言っています。)
この言葉を聞いてたまに思うのが、
「本当にそうしなければいけないのか」
という疑問です。
何かを得るために何かを捨てなければいけない
なんて誰が決めたのでしょうか。
それは本当にベストなやり方なのか(他にもやり方があるのでは?)、
自分の傲慢ではないのか、
他の人だともっと良いやり方がるのではないか、
あの人に任せてるからこんなに時間がかかっているのではないか、
などなどモヤモヤを上げればきりがありません。
何が言いたいのかというと、
トレードオフなんてくそみたいな前提条件は捨てる
常に今の自分を否定し続ける
ってやっていかないと良いエンジニアにはたぶんなれない
nodebrewが素晴らしすぎる
nodeは頻繁にバージョン上がるし、毎回インストールまじで面倒だし、 新しく出るバージョン11試したいし とか思ってたらすげー素敵なやつ見つけた
nodebrewというNode.jsバージョン管理ツール
https://github.com/hokaccha/nodebrew
導入手順は下記が参考になります。
node.jsのversionを管理するためにnodebrewを利用する - Qiita
注意点としては、インストール前に一度Node.jsを削除する事です。
pkgファイルでインストールしたnode.jsをアンインストールした時ハマったこと(Mac OS X) - Qiita
とにかくおすすめ。Node.jsやる人は絶対にいれたほうが良いと思います。
仮説と事実を混同してほしくない
それぞれの定義(Wikipediaから引用)
- 思いつき
- 急にひらめいたこと、ふと心に浮かんだこと
- 仮説
- 真偽はともかくとして、何らかの現象や法則性を説明するのに役立つ命題
- 事実
- 現象として観測された事柄
思いつきで物事を説明する人は最低だと思います。 (自分たまにそういう時あるけどね、、、反省してます。)
でも、思いつきでしゃべっている人はまだかわいいもんです。 だって、今思いつきなんだけどとか言ってくれるから。
僕が困る人
僕が困る(嫌い)なのは、仮説を事実と混同して話す人たちです。
Aがあって、Bがあって、Cがあって、、、 ということはDになるはずだ! と結論が導かれているようです。
「裏を取ったんですか?」と聞くと、 「AとBとCを確認することが裏を取ったというふうにも考えられるよね。」という答えが。 (裏取ってねwwwwww)
仮説はどこまでいっても仮説です。 事実にするには実際の現象を確認する必要があります。
いくら状況証拠を集めても、それは仮説である ということをわかってほしいです。
じゃないと話が噛み合わないし、もうこの人と議論しようと思わなくなる。
以上でした。
Gunosy(グノシー)の新しいiOSのアプリがイマイチだったからGunosyLiteにしました
所感
正直イケてない
イマイチな理由
- アプリアイコンのデザインがダサい
- Gunosyらしさが全くない(Smar○Newsと変わりない)
ということで元のUIに戻すことにしました。 でも前のバージョンに戻すとか出来ないしな。。。
と思っていたら、GunosyLiteなるものを発見!
これだ!と思って設定しようとすると何度かむきー!となったので書いときます。
手順① アカウント紐付け削除 GunosyLiteに既存のアカウントを紐付けようとすると、 「そのアカウントは利用されています。」
となるので、まずは解除(1むきー!)
Gunosyの設定画面からアカウント設定を選択
WEBじゃないと解除できないと書いているので、WEBページに仕方なく遷移
遷移時にAppStoreに移動しますか?と聞かれる(2むきー!)
遷移すると無限ループみたいになってしまうので、ここはキャンセル
実際のアカウント画面から解除しようとすると、twitter,facebook同時に解除は無理(3むきー!)
最終的には一度アカウントを削除するしかありませんでした。。。 退会すると今までの履歴が全部削除されるのか。。。また一から貯めていかないといけない。しんどいな
いや、いいんだけどさ。。。何か理由があるだろうから。
でも、僕は好きになれませんでした。
まとめ
アプリって一度見放されるとその後絶対使わないから、本当に慎重にやったほうがいいと思います。(明日は我が身だなー)
某お天気アプリも大幅なUI変更であっという間にユーザーは離れました。
本当の意味でユーザーを向くって難しいですね。 とことんユーザーを向けるエンジニアになりたいです。
(追伸) 退会せずに、ログアウトすれば良かったのね。。。データだけは戻して欲しい。。。 ただいま問い合わせ中です(´Д` )
デブサミ2014 iOSアプリケーションの継続的デリバリー ~エンタープライズ品質のiOSアプリケーションを目指して~ #devsumi
iOSアプリケーションの継続的デリバリー ~エンタープライズ品質のiOSアプリケーションを目指して~(梅原直樹(株式会社リコー))
どうも。@sisijumiです。
今年はスマホアプリ開発Yearにしようと思っているので、何か参考になるのではと思い参加したセッションで衝撃。2日間のデブサミでベストセッションに輝きました。。。
バックグラウンド
株式会社リコーで働かれている方です。
新規事業を生み出すために、クラウド関連とiOS関連で日々開発を進めているそうです。
概要
社内でiOSアプリの開発が開始(とりあえず何か作ろうというよくある話。うちもそうでした(笑))
「自分がやります!」と手を上げてみたものの
- 開発経験ない
- チームがいない
- 仕様もない
- 納期だけはある(笑)
という状況
ここからどういったサービスを展開し、またそのサービスを展開するに際しどういった開発スタイルで進めたかというお話でした。
開発したサービス
UCS 少人数向け、ポータブルなテレビ会議システム
(すみません。使ったことないです。。。)
開発スタイル
- 価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなければならない!
- ソフトウェアは価値があるかぎり、開発し続けなければならない!
というミッションを支えるために
- 開発体制
- MMF
- とことん自動化
なんかで仕組みや工夫したこと、試行錯誤したことを余すことなく教えてくれました。
(いやー、ここ本当に良かった)
そもそも何故継続的にユーザにサービスを届ける必要があるのか
非常にシンプルなお話だったのですが、
ビジネスで主導権を得るために継続的にリリースする
ためです。
間違いなく、そのとおりだと思います。競合サービスに負けないために、1日でも早くユーザにサービスを届けることは僕らの仕事だと思います。
開発体制に関して
- 価値を生み出せるチーム自体が価値
本当にそのとおりだと思いました。ソフトウェアを開発するのは人であり、チームです。素晴らしいチームが存在すること自体が、組織として、また会社として価値になります。
- DeveloperとTestEngineer
それぞれの役割を分けているそうです。
TestEngineer:製品の品質について責任をもつ
Developer:コードの品質について責任をもつ
開発するサービスを決めた後、それぞのチームが走ります(仕様と実装とテストが平行!!)。コードを書くDeveloperとテストを書くTestEnginner、それぞれの役割を終え合流した際に、一つの機能開発が終わった時にリリース可能な状態になっているそうです。
いやー、非常に理にかなっています。現実として、1~2名で開発する場合は難しいと思いますが、こういった体制ができれば個々の強みを活かしたチーム作りが出来るはずです。実際に、リコーさんではコストも下がり、リリース速度も上がっているそうです。(素敵すぎる。。。)
MMF(Minimal Marketable Feature)
価値の優先度が高いものから小さく作るということです。ユーザの反応を見て、反応が小さければ×、良さそうであればバージョンアップ、つまり小さく設計して小さく実装することで手戻りを少なくして大きく育てる。いまやるべきなのか、後でやるべきなのかを常に問いかけながら進めているそうです。
提供する価値の優先度 > 実装の優先度
とことん自動化
実機でのテストにこだわり、それを自動化するための試行錯誤については感動を覚えました。何が何でもやってやろうという意気込みが必要ですね。
まとめ
以下のミッションが僕のミッションにもなりました。(ゆくゆくは会社のミッションにしていきたいと思います。)
- 価値のあるソフトウェアを早く継続的にデリバリーしお客様を満足させなければならない!
- ソフトウェアは価値があるかぎり、開発し続けなければならない!
実現するために、もっとできることがいろいろあるなと感じました。
今は会社でもそのための仕組み作りを進めているので、そこに全力で頑張りたいなと思っています。
セッションが終わった後で、「感動しました!」と伝えさせて頂いたところ、
というつぶやきが(笑)
この方、本当に熱くて面白くていい人だなーと感じました。
また、実現するにはやっぱり自分で手を動かしてやるのが一番だと言われました。指示するだけではだめですね。。。自分で示していかないと。どれぐらい本気でやろうとしているのかが、チームにも会社にも伝わりません。
来年のデブサミでも登壇いただくと思いますが、そのときには良い報告ができるように頑張ります。
テスト駆動開発入門に行ってきました(ずーっと前の話)
ずーっと前に参加したテスト駆動開発入門
和田さん(@t-wada)の話した内容を、反省(チームに全く導入できていない)含めて残しておきます。
TDDの目的
動作する綺麗なコード!!
TDDのサイクル
1 次の目標を考える
2 目標を示すテストを書く
3 テストを実行して失敗させる
4 目的のコードを書く
5 3で書いたテストを成功させる
6 テストが通るまでリファクタリングを行う
7 1~6を繰り返す
一つ一つ片付けていく
TDDのこころ
・1つずつ少しづつ段を小さく
・素早くまわす(フィードバックサイクル)
・自分が最初のユーザ
自分が作ったメソッドを自分が利用せず提供するケースが存在する
そのままでは自分のメソッドの改善点に気づかない
・不安をテストに
手が止まるときは何が問題なのかを考える
・命綱を編む
TDDのメリット
最大の理由は心理的なもの
応用
テストの無いコードが既にたくさんある
#レガシーコード改善ガイド
既にデータの入ったデータベースがある
#データベースリファクタリング
FragileTests
SlowTests
#xUnitTestPatterns
#実践駆動開発
一つ覚えて帰った