「スタートアップがまともなわけ無いから入るな」【後編】SUGAR・杉谷保幸CTOインタビュー
高速・高品質の両立を目指そう スタートアップであろうが、大企業であろうが、開発は最初から高速で高品質でやっていこうと考えるべきなのです。低品質だと不具合は増えていき機能追加はしづらくなっていき人も減り採用もできず会社が死んでしまいます。低速だとプロダクトか会社自体が存続できません。高速と高品質の両立が重要です。 高速と高品質を両立するためには道具や手法に拘らなければなりません。 たとえばSUGARに導入しているのはドメイン駆動設計(DDD)という手法です。詳細は専門書などを参照していただきたいですが、ものすごくざっくり言うと、「人間の言語能力というのはとても優れているので、言葉と実装を一致させる部分をつくりましょう」という考え方です。ドメインというのは「業務知識」という意味です。業務のひとつひとつを言葉として厳密に定義して、それと実装を一致させるという考え方が基本になります。 例えば、「本
初転職4年間のまとめ、あるいはCTOを辞めたお話 - 考えた。
4年間務めた株式会社セプテーニ・オリジナル、およびコミックスマート株式会社を退職しました。役職はどちらもCTOでした。どなたかの役に立つことを願い、4年間の活動とその結果をまとめます。2014年。開発組織を作るためにやってみた事 と 2015〜2016年で開発組織を作るためにやってみたこと を最新結果と共にまとめた物になります。 前提：自分は何をやりたかったのか "高速で高品質な開発ができる組織を作りたかった"が一つ。これは前のエントリ技術的負債について考えたで詳しく述べています。 もう一つは "有名プロダクトも知名度もない会社で腐った開発をしてたら、採用ができないよの解決"です。採用は会社の生存には欠かせない重要な要素ですが、エンジニアにはセプテーニの知名度はほぼありませんし、GANMA!等を除けば基本的に社内向けのツール開発になります。その上で開発文化も残念な状態になってしまってはエン
CTOとしてデビューすることになりました - joker1007’s diary
近況報告、というかタイトル通りなのですが、CTOとしてデビューすることになりました。 7月から、最近お世話になってたReproという所のCTOという肩書を得ました。 自営業の個人事業主からいきなりCTOですよw まあ、CTOといっても、そこのフェーズ次第でやることってのは色々と変わってくると思います。 私の当面のミッションは、中長期的なアーキテクチャの方針決定とそれを実際に形にすること。 そしてリクルーティング、つまり転職斡旋おじさん業です。 なので、責任とコミットする割合が増えるだけで、そんなに今までとやってることは変わらないと思う……多分。 まさか自分がCTOになるとは全然思ってなかったんですが、30歳も越えたし肩書きと共に仕事するのも新しい挑戦としては良いかと思いました。 後は、収入ラインとかIT健保の任意継続が切れた後の社会保障の確保ですかね……。まあ、金は大事ですよね。 他にも色
チーフ・テクノロジ・オフィサ（CTO）ってチーフ・エンジニアと違うの？（石橋秀仁）
良いCTOは金の草鞋を履いてでも探せ (ZEROBASE BLOG)へ頂いたコメントを紹介します。それをきっかけとして、CTOの職務とは何かについて考えてみたいと思います。「天才エンジニア」と同様に「CTO」という言葉も曖昧に使われがちです。 →素敵な要約をして頂きました：CTOと「技術経営」 - Zopeジャンキー日記 今回のポイント CTOの職務は何か？ それに必要な能力は何か？ 前提 「CTOの職務」を論じる上での大前提ですが、「人に仕事をつける」という考え方ではなく、「職務に人をつける」という考え方を前提として読んでください。つまり、「ある天才エンジニアを連れてきてCTOという肩書きを与える」のではありません。さきにCTOという職務と、その職務記述書(job description)があって、そこに「CTOの職務記述書に相応しい人物を連れてくる」という考え方です。 誤解の無いように
リリース力 - Masatomo Nakano Blog
って、大事だなーと思っていてエンジニアの力の差が大きく出るところだと思っている。 新規サービス 新規アプリ ちょっとした社内ツール プロジェクトの進め方の改善 大き目のリファクタリング とかなんでも、とりあえず始めることは簡単だ。ただ、それを形にしてリリースしたり継続するのは難しい。 データベースのマイグレーションが必要だったり、最後の細かいUI調整もなかなか時間がかかる。色々な環境でのテストも必要だ。 技術的以外な部分でも、関係者との調整や、ユーザーへのお知らせ、面倒なことが多い。 開発者なら誰でも実感値あると思うけど「だいたいできた」から「リリース」までの距離はだいぶ遠い。自分の感覚としては「だいたいできた」で良くて半分くらい。楽しいのも最初の半分、後半は楽しくないことが多い。飽きも来る。 (これらの面倒なことを減らすのが、Quipper CTOである自分の役目だとも思っている、がそれ
コードの綺麗さの先にあるもの - Fashionable Life
2012-11-30 コードの綺麗さの先にあるもの 久々の更新になりますね。せっかくなのではてなブログに移りました。 昨日弊社代表の 「コードが汚くてもいい」っていう社長のインタビュー記事に対して 「コードが汚いのは悪だろ」って脊髄反射してるブクマコメントとかツイートが たくさんあるのでCTOとしての自分なりの意見を書いてみようと思う。 実際の現場 最初に記事を目にしたプログラマー達はまぁ「コードは汚くてもいい」にしか目にいかないだろう。そんな会社で働きたくないって思うかもしれない。この会社には汚いコードが溢れてるんだろうなと。 脊髄反射的にブコメしたり、ツイートされているものは全て拝見させていただいた。 では実際の現場はどうなのか。 盛大に勘違いされてそうだが、そもそもの大前提としてうちのコードは別に汚くない。 綺麗、汚いとかの定義は人それぞれだが、仮にその評価軸をリーダブルコード(可読
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いま注目のエンジニア100 話題のベンチャー・スタートアップで活躍するCTOインタビューサイト