アル株式会社の取締役CTOになりました - UNIX的なアレ
アルのメンバー（1名はリモートのためいません） 2019年2月1日にアル株式会社の取締役CTOに就任しました。アル株式会社とはマンガファンのためのサービス「アル」を運営する会社です。現在は、Web/iOS向けに展開しています。 アル - マンガの新刊通知を発売日に ALU INC.ブック無料 最近までやっていたこと 2018年の6月頃から会社には属せずに、個人でいろいろと活動をしていました。仕事においては技術顧問やコンサル、そしてエンジェル投資など通じて様々な会社と関わることができた良い機会でした。また昨年はとにかく海外に行きまくった年で、多い時は月に２〜３回くらいのペースで海外にいって旅行しながら仕事したりといったわりと自由な生活をできた年だったなーとも思っています。（半年で10カ国くらい行った気がするのでなかなかのペースでした） 音楽活動も引き続きやっておりいままでは完全にロック畑だっ
Supershipを退職しました - UNIX的なアレ
表題の通り、2018/5/31 をもってSupership社を退職しました。現在に到るまでの経緯ですが、長く、そして若干のややこしさはあります。過去のエントリーでその辺り触れています。なお、退職の理由は割愛します。 wadap.hatenablog.com wadap.hatenablog.com wadap.hatenablog.com これから何をするのか 正直なところ「これをする！」といったものは現在はありません。現在は本当に縛られるものがないので、とりあえずはいろいろと自由にやってみようかなーというところです。そんな中で現在やっていて、今後も継続するだろう活動は以下の３点です。 音楽活動 エンジェル投資 顧問・コンサル 音楽活動 僕自身ギタリストとしてやっていきたいという思いは10代のころからありその思いは今でも変わっていません。自由に動ける今だからこそできるギタリストとしての活動
リモートでの働き方を考える - UNIX的なアレ
リモートワークの可否に関しては様々な意見がありすでに国内でも導入している企業は増えてきています。実際に働き方改革の取り組みとしても実際に上げられています。 テレワーク推進に向けた政府の取組について とはいえ、実際にリモートワークで成果を出すのは今まで通りの時間管理を前提としている業務の考え方では難しく、挙げ句の果てにはこういった管理方法すら出てきてしまうのが現状です。 japan.cnet.com 時間管理をしたほうが効率のあがる業務なのであればこのマネジメントの考え方は１つの手法としてあるのかもしれませんが、正直なところ非常にナンセンスな管理方法だと思います。 高度プロフェッショナル制 そして実際に導入が検討をされている高度プロフェッショナル制ですが、これは成果に対する評価が賃金であるということが前提となっています。しかし時間管理が染み付いているワークスタイルだとやはりどうしてもコンフリ
「ノーアジェンダ・どうしましょうか会議」の傾向と対策 - UNIX的なアレ
wadap.hatenablog.com 先日、こんなエントリーを書きました。割とエンジニアやデザイナーの方は経験したことがある会議ではないでしょうか。このワードに反応されていたので、少し掘り下げてみたいと思います。 「ノーアジェンダ・どうしましょうか会議」とは もうこの名前に全てが詰まってはいるので、経験したことがある人はすぐにわかるとおもうのですが、以下の点が揃っているとまさにその会議かと思います。 アジェンダが用意されていない とりあえず関係がありそうな人を呼ぶ 会議が始まり次第「どうしましょうか」的な空気が流れる ダラダラ長い 丸投げ感満載 というところでしょうか。会議そのものに主催者側の専門性があるものでは起きづらいのですが、自身が理解できない or 経験の無い領域の話になるとわりとこういう会議になりがちなのかなと思います。 会議の傾向 そしてこの会議が始まり「どうしましょうか」
現場に業務改善を求めてはいけないのか - UNIX的なアレ
anond.hatelabo.jp コメントも含めこれを読んで思ったことを書いてみようと思います。 業務改善を求めてはいけないのか？ まず、業務改善は上司だけの仕事ではありません。そもそも上司といってもチームによって期待されているロールが分かれているんで一概に言えないと思います。 そして業務改善は現場の協力無しでは出来ないので、何らかの協力を仰ぐことは必須です。ただ、問題はどこまでを上司が行ってどこからを現場で行うのかという点なのかなと思いました。例えば以下のような方法です。 人が辞めてしまい、業務負荷があがっている リソース不足ではあるが、あきらかに業務効率が悪い点があった ○○の問題を解決したいので、それを実現するための方法は何かないだろうか？ というような話の流れであれば、返答のパターンは以下の3つくらいだと思われます。 その方法を試したいので、○○という手法を導入したらどうか そこ
新規事業と「ざっくり力」 - UNIX的なアレ
新規事業ってあまりにも変数が多すぎて考えないといけないことだらけです。本来であれば一定以上はやってみないとわからないものだらけなのですが、どうしても細かいリスクに目が行きがちで議論が深まってしまいます。 本来であれば、とにかく意思決定は早くしプロジェクトをどんどんと前にすすめるほうが見えることも多いです。 しかしなかなかそうはいかないこともあるのが現状。そのときに使えるスキル「ざっくり力」というものに会話をしていて気づきました。 立ち上げ時のワナ まずありがちなのが、細かなリスクやこういうときにこうだったらというとにかく多くのケースの想定です。 当然、出来る限りリスクを想定しておくことは大事なのですがこのリスクを潰そうとすることをやりすぎてしまうとプロジェクトがなかなか前に進みません。とくに「予算が多い」「関わる人間が多い」となるとそうなりがちかなと思います。 確かにそれは間違ってはいない
管理画面と業務フロー - UNIX的なアレ
最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。 社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。 それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。 管理画面からオペレーションを設計する まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい 組織の最適化より管理画面の最適化のほうが合理的に行える エンジニアの合理的な思考が
株式会社nanapiの取締役及びCTOを退任いたしました - UNIX的なアレ
jp.techcrunch.com 2015年11月1日をもって株式会社nanapiを含む３社が合併し、Supership株式会社となりました。 それに伴い取締役及びCTOとしての立場を退任いたしました。株式会社nanapi（始めた当初は株式会社ロケットスタート）では、６年半ほどCTOという立場で仕事をしてきました。一人で開発していたころから現在に至るまで、本当に様々なフェーズを経てきたなぁと思います。 これからはSupership株式会社において改めてサービス開発という現場にたちもどって、サービス開発の現場で戦っていこうと思います。 立場は変われど、会社の目指す先はより大きくなっているのでより現場にちかい立場で引き続き頑張っていくつもりです。 Supership株式会社でもエンジニアは引き続き募集しておりますのでぜひよろしくお願いいたします！ 新卒採用サイト｜Supership株式会社
CTOを辞めた彼のエントリーを読んで - UNIX的なアレ
nobkz.hatenadiary.jp 昨日だが、このエントリーがバズっていて僕自身もtwitterでいくつか言及した。twitterってその場の思いを素早く伝えるのは非常に便利なんだけど、コンテキストが重要なものが説明しづらいとか、フロー的な情報という問題もあるため改めてブログに書いてみる。 率直な感想 まず、彼自身がCTOじゃなく１人のエンジニアとしてこの会社にジョインしていたのであればまぁわかるよという内容だ。エンジニアとしての美学を追求し続けたけど、それじゃビジネスが立ち行かなくなった。俺のことをわかってくれるVCが日本にはいない！ まぁここまではよくある話だと思う。誰もが失敗はするし、最初からうまくいく人なんてごく少数だと思う。問題は、この事自体を環境のせいにしているということだと思う。 技術的負債を早く返しすぎたのが失敗と書いてあるが彼がそう感じているのであればそうなんだ。た
nanapiのこれから、変わることと変わらないこと - UNIX的なアレ
すでにメディアで取り上げられているのでご存じの方もいると思いますが、本日このような発表をいたしました。 http://nanapi.co.jp/news/133 変わること 「変わることと」表現していますが、我々がもともとやろうとしている「What」の部分が変わるわけではありません。あくまで「What」を叶えるための「How」の部分が変わるだけです。 株式会社nanapiは「できることをふやす」というミッションを掲げています。そのミッションをいかにして達成するのかを考えた結果、もっとも最適な選択肢として今回の結果になりました。 http://www.syndot.jp/ 変わらないこと 連結子会社となっていますが、株式会社nanapiとしては基本的にやることは変わりません。我々が運営するnanapi.jpやアンサーに関しても今までどおり運用し続けますし、これからもよりよいサービスになるよう
fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
文章の書き方を変えるだけで社内の情報共有は加速する - UNIX的なアレ
社内の情報共有で困っている会社は多いみたいですね。でも実は、nanapiという会社ではそこまで困っていなかったりします。元々文章を扱う会社というのもありますし、ドキュメント化して共有しようという風土が染み付いているからだと思います。 そういったこともあり最近登壇するときなど、社内の情報発信などについて話す機会が増えました。弊社では社内における情報共有のツールとして、Qiita:Teamを使用しています。 生産性を向上させる情報共有ツール - キータチーム（Qiita Team） 全員がMarkdownで文章を書く 実際にnanapiではQiita:Teamを導入してから、現在ではエンジニアだけでなくアルバイトも含めた全社員がここに様々なドキュメントを投稿しています。 Qiita:TeamはMarkdownで書けるようになっています。つまり、社内のメンバーは全員がMarkdownで文章を書く
「会社は学校じゃねぇんだよ」というエントリで思ったこと - UNIX的なアレ
http://ameblo.jp/junpei-1114/entry-11889404525.html なんとなく便乗エントリー。 まぁこの内容は絶対にはてな民は嫌うだろうなーという内容ですよね。サイバーエージェントってだけで敵視するわけだし、そのうえイケメンっぽいし、若くして社長だし。はてな民が敵視するだけの要素はたくさん持っているわけです。 正直なところ、彼の文章はすごく感情的な文章だし、表現方法も拙い。やっぱり若いなぁというのが僕自身の印象です。ただ、正直このあたりの彼の主張はどうでもいいかな。うちの代表も触れていますが、彼のすごいところって視点の高さだと思うんですよね。 サイバーエージェントグループの一員として、 21世紀を代表する会社を創るため。 そして、WAVESTを日本を代表する会社にするため。 そのためだけに会社に来ています。 ここで注目したいところは、サイバーエージェント
nanapi勉強会vol2でshellについて話す会を企画した＆話した＆まとめた - UNIX的なアレ
個人的なShellTipsをまとめてみた - UNIX的なアレ 以前に話題になったネタでこんなエントリーを書きましたが、どうならもっといろいろな人の話を聞いてみたいよね、というわけでid:sotarokと話しててこの勉強会をやることになりました。 もともとのコンセプトとしてはshellのウルトラなテクニックを紹介するというよりも、なんかイマイチ使いこなせてない感がある人とか、めんどくさい作業をめんどくさいと感じずにやっている人向けな内容です。 そんなわけで、私が発表した内容は以下のスライドです。 なんか途中からemacsの話してるんですけど、emacsは概念だしレイヤーが違うので特に問題はありません。なおやさんもemacsの話してたし。 その他、当日の資料が上がっていますのでまとめてみました。 当日の資料 当日の発表内容はこんな感じです。全体的にすごく興味深い話でした。まず今日からzaw使
第21回 AWS User Group - Japan 東京勉強会で話してきました - UNIX的なアレ
最近、イベントレポート系のエントリばかりなきがします。先日こちらのイベントで話してきました。 第21回 AWS User Group - Japan 東京勉強会(一般枠) - JAWS-UG東京支部 | Doorkeeper nanapi.jpというサービス自体は今現在はオンプレミス環境で動いています。その他のアンサーや、ignitionといった新サービスがAWSで稼働しているので、そのあたりの内容です。 一緒に登壇する方々がすごい方ばかりでどんな内容発表しようかなぁと悩んだのですが、結局ふつうの発表です。まぁ５分の発表時間だったので、そこまで多くのことは話せませんね。 他社の事例をいろいろ見ることができて刺激をうけることができました。もうちょっといろいろと実験して、面白い構成にチャレンジしてみたいものです。
CTOとか役員とかに関する基本的な知識 - UNIX的なアレ
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ 先日のCTOエントリが結構反響あったので続きを書いてみます。いろいろな方のリアクションみていると、CTOとか役員とかそのあたりをもう少し理解してもらいたいなと思ったのが理由です。 役員って何？ これ結構勘違いされていますが、会社法における役員というのは取締役のことです。そのため、CTOだから会社法上の役員というわけではありません。 またそれと同様に、執行役員も会社法上の役員ではありません。取締役と執行役員を兼任しているケースは多いですが、これは社内におけるそれぞれの役割を分けているためです。 それでは取締役の役目は？ まず、重要なのは以下の点です。 取締役は単独で職務執行権限を持たず、取締役会の一員に過ぎなくなった 取締役 - Wikipedia 取締役という立場自体はそれだけで職務上の何らかの権
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ
若干釣り気味のタイトルです。CTO募集すること自体は悪くないんだけど、その内容についていろいろ思うことがあったのでちょっと書いてみます。 やたら見かけるCTO募集 wantedlyとかみるとですね、とにかくCTO募集している会社が多いわけですよ。そりゃITな会社つくるとしたらCTOはいた方がいい。 でもね、多くの社長が話すCTO像って別にCTOを求めてる訳じゃないんですよね。要するに、なんでもできるエンジニアが欲しいというだけのパターンが多い。 とくに募集要件みてもピンと来ないんですよ。別にそれってCTOである必要ないでしょ？と思ってしまう。例えば、 アーキテクチャの設計ができて スマホアプリできて サーバサイド開発もできて インフラもひと通りできて マネージメントできて イケてる提案もしてくれる あと、言うことは聞いてね みたいなことを考えてる人が多い。すごく多い。まずね、いないよそんな
技術そのものがリスペクトされる風土がこれからは大事なんだと思う - UNIX的なアレ
ITに携わる人たちの間で、エンジニアが大切でエンジニアを中心とした組織づくりをしようとしている会社がすごく増えてきました。実際にいま存在感がある会社はどこもエンジニアが活躍している会社です。 なぜ非エンジニア向けに技術を学ばせるのか nanapiでは非エンジニアむけの技術研修を毎週実施をしていて、コードのかけない人はいないようにすることを目標にしています。これはコードを書けることでそれを普段の業務に活かせるようにしようというだけではなく、技術そのものに対してリスペクトしてほしいという思いがあります。 nanapiのエンジニアはコミュニケーション能力が非常に高いので非エンジニアのレベルに合わせて技術の話をすることができますが、実際はエンジニアが遠慮せずに話してそれを非エンジニアの人が理解しようとするほうが圧倒的に仕事のレベルは上がるはずなです。やっぱり普段の仕事の会話は高いレベルに合わせたほ
個人的なShellTipsをまとめてみた - UNIX的なアレ
naoya_itoの火を噴いたシェルtips - Togetter これを読んでふと書きたくなったので。ちなみに僕はbash使っています。 CTRLを使った便利系 まず、UNIXな操作あたり。 キーバインド 意味 CTRL + s キー入力を受け付けなくする 画面出力抑える CTRL + q 上記解除 CTRL + z バックグラウンドに. fgで戻る CTRL + l 画面をクリア。clearと同等 CTRL + c 現在の処理を停止 CTRL + d exitと同等 CTRL + r historyからコマンド検索 emacsっぽいやつ どっちかというとキー操作に近い。基本はemacs。metaは僕はoptionに割り当ててる。とりあえず触りたい人はESCでOK。 キーバインド 意味 CTRL + a 行頭 CTRL + e 行末 CTRL + f → CTRL + b ← CTRL
Sensuを使ってクラウド環境の監視を効率よく行おう - UNIX的なアレ
AWSなど様々な環境でサーバを管理してくると、すべて同一の監視ツールを使うのがなかなか難しくなってきます。そんなこともあり、私も定期的にいろいろな監視ツールを試しています。 http://nanapi.co.jp/blog/2013/09/11/monitor_nanapi_servers/ nagiosとクラウドの相性が悪い！ 監視するには様々なツールがありますが、その中でも特に有名なツールはnagiosでしょう。古くから使われているツールで、プラグインも数多くあり様々な監視を行うことができます。 クライアント側にnrpeをインストールすることで、各ホストの詳細の状態まで監視することができますし、うまく活用すればかなり細かい監視までできます。 しかし、AWSのようなクラウド環境で使うには非常に使いづらいです。というのも、nagiosはサーバ側にどのホストを監視するのかという情報を持たなけ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
