リモートでの働き方を考える - UNIX的なアレ
リモートワークの可否に関しては様々な意見がありすでに国内でも導入している企業は増えてきています。実際に働き方改革の取り組みとしても実際に上げられています。 テレワーク推進に向けた政府の取組について とはいえ、実際にリモートワークで成果を出すのは今まで通りの時間管理を前提としている業務の考え方では難しく、挙げ句の果てにはこういった管理方法すら出てきてしまうのが現状です。 japan.cnet.com 時間管理をしたほうが効率のあがる業務なのであればこのマネジメントの考え方は１つの手法としてあるのかもしれませんが、正直なところ非常にナンセンスな管理方法だと思います。 高度プロフェッショナル制 そして実際に導入が検討をされている高度プロフェッショナル制ですが、これは成果に対する評価が賃金であるということが前提となっています。しかし時間管理が染み付いているワークスタイルだとやはりどうしてもコンフリ
落とす面接と通す面接 - UNIX的なアレ
ottiee.hatenablog.com 同僚のデザイナーが良いことかいてました。最近は採用活動には携わっていないのですが、以前に似たようなことを採用において感じたことがあったので書いてみようと思います。 不慣れな人ほど落とす 私自身も面接官トレーニングというものをちゃんと受けたことがあるわけではないので、いわゆる「正しい面接」というものをできているかどうかはわかりません。 ただ、過去にやっていた採用活動においてまずよく起こるのが面接に不慣れな人ほど簡単に人を落としてしまうということでした。 なぜそうなってしまうのか。理由としてはシンプルで、通すことよりも落とすほうが簡単だからです。相手の嫌な部分やダメな部分なんて自分が思い込んでしまえば簡単に作ることができるので、落とす面接は簡単に仕上がってしまいます。場合によっては単純な好き嫌いだけで合否を決めてしまうこともある。1の良いところをみつ
リズムをつくる開発サイクルと会議のペース - UNIX的なアレ
gihyo.jp 先日発売されたこちらで取材された内容なのですが、せっかくなのでもう少し詳しく書いてみようと思います。スクラムの実践方法というよりも、円滑に回すために会議や意思決定のタイミングを工夫した内容です。 前提条件 以下が実施した条件です。 iOS/Androidのアプリ開発 アプリはリリース済みで、機能追加やアップデート対応 iOS2名、Android2名、サーバサイド2名、デザイナー2名 会議のリスト イテレーションは２週間で切っていて、その中で以下の会議を実施しています。 開発者全員が参加するもの 朝会 スプリント計画 振り返り プロダクトチェック会 仕様レビュー会 プロダクトオーナーが参加するもの プロジェクト運営MTG プロダクトバックログMTG 会議の実施内容とタイミング Daily - 朝会 これは毎朝実施されます。デイリースクラムも呼び、その日のやることや問題となっ
管理画面と業務フロー - UNIX的なアレ
最近また管理画面に近いものをつくったりしていて感じたのですが、事業会社において管理画面がどのタイミングで実装されているかというのがすごく重要だなと感じたのでちょっと書いてみようと思います。 社内向けの管理画面の実装って割と後に回りがちで、最後に仕方なくなんとか実装するようなケースが多いと思うんですよね。そして、ある程度発生してきたオペレーションの実態に合わせて実装するみたいな流れになるのではないかなと。 それはそれで一つの実装の手法だと思うのですが個人的には逆のほうが良いのではないかなと思っています。 管理画面からオペレーションを設計する まず、以下の理由から管理画面ありきでオペレーションを設計したほうが良いと思っています。 既存のオペレーションありきで管理画面の要件を出すため、イノベーションがうまれづらい 組織の最適化より管理画面の最適化のほうが合理的に行える エンジニアの合理的な思考が
StartupBaseのメンターをやってきた - UNIX的なアレ
つい先日、StartupBaseというイベントのメンターをやってきました。ビジコン的なイベントではあるのですが、ポイントは高校生以下ということ。今回参加している中で最年少は中学１年生の子もいました。 startupbase-u18.com どういうことをするのか？ １チーム４名くらいで、４チームつくり２日間かけて事業を考えてプレゼンをします。実際に調査という名目で、街中に出ていろいろなアンケートをとったりヒアリングをしたりして事業の実現性やニーズなどを固めていくといった流れになります。その中でちょっとアイデアが出てきたかなーというあたりでメンターとしていろいろとアドバイスをするという感じでした。 実際にやってみて 彼ら・彼女らにとって、事業を自分らで考えて説明をするなんて当然人生で初めてだと思うんです。別に一生そんなことしなくても生きていけるし、人生の必修科目ではない。 でもやっぱりこの年
2016年で学んだこと、僕の行動指針 - UNIX的なアレ
これは、行動指針 Advent Calendar ９日目のエントリーです。 僕なりの行動指針を書くわけですが、割と今年は仕事・プライベートともにいろいろあったのでそこから得たことなどを含めて新たな行動指針にしていきたいと思いエントリーしました。 価値観を疑え 目の前だけの選択をするだけで人生って進んでいくものですが、その選択をする価値観を見直す機会ってなかなかないなぁとおもいます。なぜその選択をしたのか、ということを定期的に振り返る必要はあるなぁと思いました。 絶対な価値観って存在しないし、それでも自分自身は信じ切っているので価値観の原点となるものを定期的に思い出すだけでも意味はあるかもですね。 メンタルとフィジカルを高い水準で保つ これは起業してからの７年間ずっと考えていることです。メンタルとフィジカルは密接に結びついているので、高い水準で保つように日々努力しています。 3日間全力で走れ
想いは時間に喰われるか - UNIX的なアレ
ベンチャーを立ち上げて、とにかく突き進んでいる時って人は最強になれる。こういうときって最初の「想い」だけで動いていて、どれだけ働いても戦い続けられる無敵状態になっている。 自分の想いをそのまま実現しているからこそ疲れないし、どこまでも走り続けることができる。この無敵状態ってプライベートにも反映されるもので、仕事が無敵状態の場合はプライベートも無敵でいられる事も多いと思う。 とはいえ実際に会社のビジョンやミッションって最初から決まっているような会社ってあまりなく、事業をつくっていく中で徐々に固まっていくことが多い。 そのビジョンが固まっていくなかで経営者の「想い」が成長することは本当に素晴らしいこと。いままで描いていた想いが抽象化されたり具体化されたりで、企業として成長をできるビジョンになっていく。そうできる会社や経営者は健全な思いで会社を経営できているはず。 これはあくまで従業員目線ではな
母校での講義で、僕が伝えたかったこと - UNIX的なアレ
元nanapi CTOの和田修一さんを迎えて中央大学での学生起業授業「ビジプロ2」だん。 熱と想いのこもった講演とその後の質疑応答も盛り上がり、学生たちによるビジネスプランのプレゼンには可能性を感じた。 まだ荒削りだが、昨年に続き今年は複数社がここから起業してくれる事を期待。 pic.twitter.com/kYaW5QEQO1— 高橋亮平 (@ryohey7654) 2016年11月10日 僕の出身大学で講義をしてきました。ベンチャーの立ち上げだったりを推進している授業のゲストとして呼ばれて、過去の経験やなぜCTOとして起業するに至ったのかみたいお話をさせて頂きました。 「人生でやりたい100のこと」というリストを管理しているのですが、その中に「母校で講義をする」というのがありました。そのため呼ばれたときは本当に嬉しかったです。紹介をしてくれたSkylandVenturesの木下さん、中
新規事業と「ざっくり力」 - UNIX的なアレ
新規事業ってあまりにも変数が多すぎて考えないといけないことだらけです。本来であれば一定以上はやってみないとわからないものだらけなのですが、どうしても細かいリスクに目が行きがちで議論が深まってしまいます。 本来であれば、とにかく意思決定は早くしプロジェクトをどんどんと前にすすめるほうが見えることも多いです。 しかしなかなかそうはいかないこともあるのが現状。そのときに使えるスキル「ざっくり力」というものに会話をしていて気づきました。 立ち上げ時のワナ まずありがちなのが、細かなリスクやこういうときにこうだったらというとにかく多くのケースの想定です。 当然、出来る限りリスクを想定しておくことは大事なのですがこのリスクを潰そうとすることをやりすぎてしまうとプロジェクトがなかなか前に進みません。とくに「予算が多い」「関わる人間が多い」となるとそうなりがちかなと思います。 確かにそれは間違ってはいない
チャレンジするなら若い方がいいし、失敗の数だけ強くなる - UNIX的なアレ
http://www.ishidanohanashi.com/entry/2016/09/15/193000www.ishidanohanashi.com なんか思ったより厳しい大人が多いなぁと思うのですが、僕は個人的にすごく応援したいと思っています。世の中にはいろいろな18歳がいると思うんですけど、少なくとも自分はごく普通の18歳だったのでこんな選択肢は出てこなかったんですよね。 僕自身は、普通に大学を卒業して普通にそこそこ大きい会社で新卒として4年くらい働いて、共同創業者として起業したという経歴です。なので起業に関しては1回しか経験をしていないわけですが、これがなんどか経験していたらもっとうまくやれたんだろうなぁなんて反省は沢山ありました。 確かに彼の行動って若さ故の過ちのように見えます。でもこういったチャレンジをしていくのって早いほうが良いと思うんです。たぶん、本当に大変なことだらけ
エンジニアが合コンで使える、口説き文句 - UNIX的なアレ
いつも合コンで「仕事なにやってるの？」と聞かれると、「えっと・・・インターネット関係」といってお茶を濁していませんか？ サーバーエンジニアたるもの、いつでも熱いマインドを忘れてはいけません。 いくつかのくどき文句を用意いたしました。 今日は待ちに待った合コン！ さぁそれでは今日は待ちに待った合コンです。 エンジニアとしての知識をギラギラに使い倒していきましょう。 君にnmap！ まずはnmapで開きポートを探しましょう。セグメント単位でも調べることもできるので豪快に。 特に指輪の位置や種類には注意。 ぼくはもうスワップアウトしそうだよ！ 何よりも自分の気持ちを伝えるのにはこの言葉がささるでしょう。ただし、swapアウトしてしまうとパフォーマンスが劇的に落ちるので注意。 あの子をnslookup 電話番号を聞くときはこの言葉で。しっかりと相手のIPアドレスを調べましょう。 ただし、/etc/
スタートアップにおける点の正義と線の合理性 - UNIX的なアレ
テストを書くかどうかみたいな話がよく議論に上がりますが、毎回賛否両論なわけです。CTO向け1on1を続けていく中でも近い話がよく議題としてあがりました。 wadap.hatenablog.com 当然な話でどっち側の意見も間違っているわけではなく、話している背景が違うのが根本的な原因なんだと思っています。そこを自分なりに考えをまとめてみました。 点で語る正義 これはまず一方からだけみた正しい回答のことを指します。まずこの点でみたらテストの議論に関して言えば当然「書いたほうが良い」という結論になります。会社の経営的な話で言えば「赤字よりも黒字のほうがいい」ですし、人事観点だけで言えば「人はやめないほうが良い」という事になります。 点で語ることは非常に大事なことですし、世間に様々な先人の知恵があります。点だけでみると変数は少なく、判断しやすいと思います。一方で圧倒的な正義になりやすく、これを振
小規模スタートアップの技術的な方々の壁打ち相手的なことをやります - UNIX的なアレ
ひとことで言うと CTOや技術の統括をしている小規模ベンチャーの人に対して、1on1をします どういうこと？ CTO的な方だったりとか、技術的なマネージャーをやっている方って様々な悩みがあると思います。当然、それを僕が解決してあげるなんて偉そうなことはできるわけでは無いのですが、コーチング的な感じで話を聞き出すことはもしかしたらできるんじゃないかななんて思いました。 今も紹介ベースで相談とかを受けているのですが、今回はそれを公に募集してみようと思います。 ターゲットとなる方々 小規模スタートアップのCTO エンジニアのメンバーを抱えてるけどうまく回せていない 技術者のマネージャーがいない あたりでしょうか。 なぜやるの？ 自分自身、壁打ち相手がいなくて困ったことがあった 頼みづらく、こういうのがあるといいかなというのをやってみた 自分自身もっと成長したいので、上の立場からというわけではなく
なりたい自分になるための名言 - UNIX的なアレ
このエントリーは名言 Advent Calendar 2015で書いています。 名言 Advent Calendar 2015 - Adventar （まちがって2日エントリーしてしまったのですが、せっかくなので書きます） なりたい自分になるための名言 （とある著名なギタリストをさして）は日々の練習時間を質問されたら「10時間」と答えました。 彼らがいまだに同じ時間練習し続けているのであれば、同じ1日24時間の中での練習時間をいかに合理的に練習するかを考えないと、永遠に彼らのようなレベルの演奏はできないと思いました。 とあるプロギタリスト教則本に書いてあった言葉です。この言葉には非常に影響をうけていて、特に新卒でエンジニアとして配属されたときに強く意識していました。 同じ時間、同じような仕事を周囲の先輩たちとしていたらいつまでも追いつけないだろうと思い、とりあえず長く働くことは前提でどうす
具体的な事実から抽象化する能力と、抽象的な要件から具体化する能力 - UNIX的なアレ
それぞれの能力について 最近、事業を推進する上で必要な能力について考え際、特にプロダクトを開発する時点では2つの能力をもった人間が配置されていることが成功の秘訣なのではないかと思いました。それがタイトルの通り、2つの能力です。 具体的な事実から抽象化する能力 抽象的な要件から具体化する能力 具体的な事実から抽象化する能力 まずこちらの能力ですが、新規事業の立案〜実行する時点までに必要とされる能力です。具体的なイシューをかき集め、それを実現することができる抽象化されたアイデアをアウトプットできる能力でしょうか。 比較的、プロデューサーと呼ばれる職種の人がこのような仕事を得意としているイメージがあります。ポイントは先程も書きましたが具体的な事実から抽象化した提案ができるという点です。ただ思いつきだけで話す人も違います。 抽象的な要件から具体化する能力 これは立ち上げ時のエグゼキューションにおい
株式会社nanapiの取締役及びCTOを退任いたしました - UNIX的なアレ
jp.techcrunch.com 2015年11月1日をもって株式会社nanapiを含む３社が合併し、Supership株式会社となりました。 それに伴い取締役及びCTOとしての立場を退任いたしました。株式会社nanapi（始めた当初は株式会社ロケットスタート）では、６年半ほどCTOという立場で仕事をしてきました。一人で開発していたころから現在に至るまで、本当に様々なフェーズを経てきたなぁと思います。 これからはSupership株式会社において改めてサービス開発という現場にたちもどって、サービス開発の現場で戦っていこうと思います。 立場は変われど、会社の目指す先はより大きくなっているのでより現場にちかい立場で引き続き頑張っていくつもりです。 Supership株式会社でもエンジニアは引き続き募集しておりますのでぜひよろしくお願いいたします！ 新卒採用サイト｜Supership株式会社
nanapiのこれから、変わることと変わらないこと - UNIX的なアレ
すでにメディアで取り上げられているのでご存じの方もいると思いますが、本日このような発表をいたしました。 http://nanapi.co.jp/news/133 変わること 「変わることと」表現していますが、我々がもともとやろうとしている「What」の部分が変わるわけではありません。あくまで「What」を叶えるための「How」の部分が変わるだけです。 株式会社nanapiは「できることをふやす」というミッションを掲げています。そのミッションをいかにして達成するのかを考えた結果、もっとも最適な選択肢として今回の結果になりました。 http://www.syndot.jp/ 変わらないこと 連結子会社となっていますが、株式会社nanapiとしては基本的にやることは変わりません。我々が運営するnanapi.jpやアンサーに関しても今までどおり運用し続けますし、これからもよりよいサービスになるよう
sshでリモートサーバーをマウント、便利にsshfs - Unix的なアレ
開発の作業をしているときは、複数のホストのサーバーを行き来していろいろとオペレーションをするようなことがあると思います。 そんなときに1つのサーバーから作業できるよう、ssh経由でリモートのサーバーをマウントし、Localのファイルシステムのように見せることができるsshfsを紹介したいと思います。 sshfsのインストール Debian/Ubuntuならaptで簡単インストールできます。なお、fuseグループに入っている必要があるので、その設定まで実施します。なお、ユーザー名はwadapで実施します。 $ sudo apt-get install sshfs $ sudo adduser fuse wadap $ newgrp fuse以上、簡単ですね。 早速リモートホストをマウント リモートホストをマウントするのは簡単です。マウントポイントをつくって、sshfsコマンドを実行するだけ。
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で文章を書く
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
