Author Archives: Masa-ta

開発ディレクター

表題の通り。
あれ、昨日アクセスなかった…?と思ったらしれっと復活したりします。
セグメントを着ると少数について嘘風になったり、アナリティクスもいろいろ慣れが要りますね

———————————-
きん
 アナリティクスの機能の数字が0になっていたので調査中 09:56

きん
 1日1回しか集計されないかもしれないので、明日見てダメそうなら問い合わせます 10:57

きん
 普通に表示されるようになっていた 17:23

-
きん iOS担当

appleが”SSL対応ですよ”と告知していてなんとかしないといけない件。
やらないとねーという対応相談

———————————-
かじ
 webviewもありましたっけ?

きん
 あらゆるhttpアクセスが使えなくなると考えてくれればいいです。APIもWebViewも使えなくなります。

かじ
 10月中とかですかね?
 あ、もう使えるようなので、使えるか確認してみよう
 …APIの呼び出しで単純にhttpsにしただけだと404になってしまいました。
 サーバ側対応必要すね

しま
 たぶんそれは数時間で対応できるかと
 ただ全部やるとサーバーが負荷がカツカツだった場合は負荷問題で時間をとらなければならないかもしれないです。
 HTTPSは多少負荷あがります

まさ
 負荷耐えられるか塩梅見る、みたいな意味で先にやっておいた方が良ければそういう段取りにした方がいいですかねー

きん
 とりあえずすぐできるとこやっとこう


かじ アプリ全般
きん iOS
しま web
まさ 調整係

1970年からの秒数をlong型で持つと2038年でまでしか数えられないってこと…?
といった雑談になりました

———————————-

きむ
SQLのdatetimeとtimestampってどう違うんでしたっけ…?

しま
MySQLのDATETIME型とTIMESTAMP型の違いを検証してみた

きむ
知らないことがありました。ありがとうございます!

しま
自分も知らないことだらけでしたw

きむ
2038年問題が発生するかもしれませんね

しま
スケジューリングしておきますw


しま webエンジニア
きむ webエンジニア

チーム開発を一つの生産機関だとすると、
企画→仕様化→実装→テスト→リリース→改善
みたいなサイクルになります。これを最大化するにはどうすればいいか?

結論から言うと
「何かしらの尖った開発スタイルを持つ」
だと思ってます。
最大化、なんていう発想でいると、全方位なんとなく改善、みたいになります。
戦ってる市場に合わせて、「何の領域を高めるのが一番勝てるのか?」を考えてスタイルを構築するのが重要。

先日、あるエンジニアが、本人がターゲットユーザのど真ん中だったこともありますが、土日でささっと機能追加をしてきました。で、このクオリティが非常に高い。

以前から、
(ユーザ側担当者が)仕様を決めて→(エンジニアが)実装して→(ユーザ側が)テストして→(エンジニアが)直して
これがもうほんとーーーに遅い。遅すぎる。
とキレてました(実際は全然怒ってないですがw)。
そんな日常の悩みを吹き飛ばしてくれるクオリティでした。
え、こんなのが速攻で作れんの…?と思いました。

エンジニアとユーザ側の間にいるディレクターとしてはなかなか悔しい話でもあるんですが、一つの「高い開発力」はこういうことだと思います。
すなわち、「ユーザ側」と「エンジニア」が「同じ人」であること。
生産性と儲ける力で圧倒的存在になってる前職開発の教えの一つが、「なるべく一人の把握範囲を増やす」でしたが、それを思い出しました。
それだよ…!と8回ぐらい言ってしまった。

スマホアプリのUXで勝負するような開発は、作ってもすぐ真似しあってて、レッドオーシャンです。
できれば、一度制覇したらしばらく勝ち続けられるアプローチにしたいところですよね。

時々起きる奇跡のような生産性を何とか常態化し、一定の開発ノウハウ、開発スタイルを確立していきたいところです。
そうすれば「意外と結構勝てるはず」なんて思っています。

弊社の採用募集枠タイトルの一つに
月曜日が楽しみになる仕事、しませんか?
というものがあります。

とあるメンバーが考えたコピーで、弊社の長所をよく表現している物だと思いますが、
これは、自分がちょくちょく零している
「平日が終わってしまった…早く月曜にならないかな…」
等のつぶやきを元にした物とのことでした。

自分は以前、ガチガチの「効率と結果を追求」する組織にいました。
それはそれで、刺激や成長や興味や面白い人が多く、非常に濃い時間だったのですが、
約束を守り責任を果たしきれるかといった不安、競争から逃げたい気持ち、等から、
日曜や月曜朝はかなり憂鬱でした。
休み明けが辛い、というのは多くの方が経験している感覚だと思います。

では、現職になって仕事量がそんなに変わったのか?
というと、そうでも無いです。
共働きに変わり育児の時間が増えた分、もしかすると減っているかもしれませんが、
通勤の間や家にいる時間も、「完全に前向きな気持ちで」
かなりの時間、仕事のことを考えていたり、実際に手を動かしていたりします。
こんな考え方もできる。いろんなことを試したい。。等。
そして、実際に仲間と一緒に働ける金曜が終わってしまうのは本当に寂しいし、
月曜がくるのは待ち遠しいです。

ベンチャーならではの柔軟な働き方が前提にある、心構えですね。
(この辺りは、社長のブログにもイメージが書いてありますね)

ところで、技術者として
「どんな時に夢中で動いていられるか」
というのは、とても大事な要素だと思います。
早く実物にしたい、改善のプロセスが好き、議論が好き、
快適な場所でずっとコードを書いていたい…等々。

僕は、この要素が、技術者としての強みを決定づけていると考えています。
トラブル解決こそ真骨頂な人、
コードの美しさの為なら早出残業など厭わない人、
プロトタイプを出す速さがとんでもない人、
何でもできて話が早く遊び心溢れる人、
絶対の安定性で計画を全く落とさない人、、
こういう傾向は、「仕事で何をしている時が一番楽しいですか?」という質問をした時の答えと、
無意識だと思いますが、面白いぐらい繋がっています。
言語や技術領域ではなく、役立ちの種類が人それぞれの仕事のタイプと感じます。

そして、こういった「夢中からくる強み」が、「仕事の中心」になっているか。
これが、「日々の仕事が楽しいか」を決めていると考えています。
夢中でやれることなら、オンオフなんて関係なくなりますよね?
で、実際に成果、出ますよね。

マネージャーとして、成果が出る上にメンバーが夢中で働ける、
という形は理想です。
常にこれを目指して、課題設定、目標設定、開発ディレクション、日々の議論、
日々の雑談(?)、、をやっているつもりです。
新卒エンジニアへ ということは、既にどこかに就職している皆様かと思いますが(笑)、
「本当にこれが生産的なのか?」等自分の働き方に不安を感じたら。
ぜひ一度弊社エンジニアの顔色でも見にきてみてください(ドヤ顔)

最後に
「こんなCTOがいる職場で働きたい」っていう観点、いいですよね。
就職先選びの決め手は、
職種や業種や業務内容や条件ではなく、絶対、
「どんな人と働けるか」
ですよね。
wantedlyは「とりあえず会ってみる」ができる素晴らしい仕組みだと思います。
(企業側は結構大変ですが(笑))

(※この記事はwantedlyのブログ用に作成したものです)