GitHub経由で海外から仕事が来た話 - その後のその後
はじめて海外から（フリーランスとして）仕事をいただく、という貴重な経験ができたので、その経緯などを書いてみたいと思います。 きっかけ 7月末のある日、知らないメールアドレスから英語のメールが来ました。内容を一部だけ抜粋すると、 We are looking for someone to develop a very simple apple watch app and a companion apple phone app. というわけで、Apple Watch アプリをつくって欲しい、とのこと。内容を読むと加速度センサとジャイロを使いたいそうで、必然的に watchOS 2 案件になりそうです。 メールには明記されてませんでしたが、GitHub で公開している watchOS-2-Sampler を見て連絡くれたのかなと。（※もちろん面識はなく、共通の知り合いもいないので、これ以外にわざ
開発組織のマネジメント
フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発
かばんを持たない技術 : akiyan.com
かばんを持たない技術 2014-12-11 「かばんの中身を紹介するブログリレー」という催しをnanapiメンバーで始めました。僕は普段はかばんを持ち歩かないのですが、それについて一度書いてみたかったので、9人目として参加します。前回はCTOのwadapでした。エントリーまとめは主催のyunicoのまとめエントリでどうぞ。 目次 かばんは持たないのでポケットの中身を出します 通勤時にかばんは持たないので、ポケットの中身を出します。 iPhone 6 とキーケースだけです。キーケースはカード類も入るやつで、紙幣と小銭も入れているので、実質的な財布です。 キーケースの中身はこんな感じ。基本的に持ち物はこれだけです。このアシストオンのキーケースはけんすうがレビューしていたのを見て、5000円程度と安かったので最近買いました。ただちょっとデザイン的に好みじゃないので、キャサリン・ハムネットのキーケ
リモートワークの地味な知見 - ✘╹◡╹✘
華やかなところはまあググれば出てくるんで、地味なところに触れる。 日報にまとめておく リモートワーク中は、毎朝10:10 - 10:20の間、Google+ ハングアウトのビデオ通話を利用して進捗・問題共有しているんだけど、慣れてないと共有過多で時間が長くなりがち。8人居て、1人5分とかになると重い。いま取り組んでいる実装の話とかを始めてしまったり、あと会議参加者に対して「これどうですかね？」と質問する内容が含まれていたりすると、特に時間が長くなりがち。この辺は、事前にQiita:Teamの日報に前日やったことや翌日やることをまとめておいて、詳しくは日報に書いたんで見てくれという風に改善されたりした。日報、リモートワークで特に役に立つ。では日報を書いておけばミーティングは不要になるのではないかという話になるかもしれないが、この先は君の目で確かめてくれ。 情報の倍率を変えられるようにしておく
毎日コードを書くこと - snowlongの日記
ワザノバで紹介されていたKhan AcademyのJohn Resigが投稿した Write Code Every Dayの翻訳です。 訳がおかしいなどの指摘をいただけると大変助かります。 去年の秋、自分のプロジェクトのコーディングを始めたんだけど、あまり進捗がよくなくてKhan Academyの仕事の効率を犠牲にすることなしに作業をすすめる方法を見つけらずにいた。 自分のプロジェクトへの取り組み方にはいくつかの問題を抱えていた。 私は週末にプロジェクトに取り組むことを優先し、平日の夜は時々といった具合だった。 自分にとってはその戦略は効果的ではなかったことが今ではわかっている。 週末の間も仕事と同じくらいの高いクオリティでプロジェクトに取り掛かり完成させるという作業は信じられないほどのストレスだった。（そして、うまく行かなかったら失敗したような気分だった。） 週末にいつも予定が空いている
先に相手の予算聞けよ
見積もり初心者の増田君にマジレスな。 先に相手に予算聞いて「う～ん、２００万ぐらいかな～」って言ってきたら、それに合わせて見積もり作れ。 簡単な要求でも２００万円分の機能をつけてやればいいし、難しい要求なら２００万円以内でできる仕様にすればいい。 これができれば見当違いだったり桁違いの見積もり出して大失敗することはないし、確度はかなり高い。 ある程度精度のある見積もりを作った方がいい。 要求仕様だけ見せてきて予算を言ってこない場合は「降り」 これは発注先が決まっていて、社内でちゃんと相みつ取った証拠に使われるだけで完全に無駄な労力になる。 出すならバカ高い金額で適当に作った見積書出しておけ。 マジなコンペも「降り」 零細企業は5分の1とかのコンペに付き合ってる暇はない。 金額は限界まで下げないと取れないし、仮に取れても要求仕様も期間も厳しくなってデスマーチ確定。 無理しすぎたせいで納期内に
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
リモートワーク（在宅勤務）を導入するためのポイントと残された課題 | Social Change!
私たちソニックガーデンでは、リモートワーク（在宅勤務）が出来る働きかたを実現しています。むしろ、これからはリモートワークを推奨しようと考えて、経営施策を進めているところです。先日は、ソニックガーデンでリモートワークをしているメンバーへのインタビューも行いました。 お昼寝もアリ！？成果がすべての楽しくシビアなリモートワーク さて、私の書くこの記事では、私たちソニックガーデンの働きかたを参考に、会社やチームにおいてリモートワークを導入していくためのポイントや課題について、実践を通じた経営からの視点もあわせて書いてみました。 いつ働いても、どこで働いてもよい働きかた 私たちの会社ではソフトウェア開発を仕事にしていますが、ソフトウェア開発とは非常にクリエイティブな仕事です。決められたものを、ただ黙々と手を動かせば出来るような仕事ではありません。特に、私たちはソフトウェアの企画をするところから、プロ
ssig33.com - ダンピングをするな
これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip
ScaleOut | Supership
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
入社二ヶ月経ちました - 銀の人のメモ帳
前職を数ヶ月で辞めて転職活動して、意外にすんなりと転職活動を終えてた。普通に転職活動をしてみて、一社内定頂いたけど辞退した。 今働いてるところは、前回の転職活動で意識高いエントリを書いたらメールくれたベンチャー。 前回の転職活動では、力が欲し〜とか自分より凄い人が居るところで働きたい〜とか言ってたけど、今回は、如何に自分が楽しく働けるか、もしくは自分が楽しいように変えられるかを重視してた。 今の会社、社員数は20人に満たないから、わがままじゃなくて妥当性を持って変えようとすれば変わりそうな感じで、そこらへんについてはストレスが少ない。 本当は入社一ヶ月くらい経ったあたりで社名を明かしてそれなりにひと目に付くような文章書こうと思ってたけど、炎上の火消しにぶっっっこまれてマジで糞な感じになってるから、こんな感じで、なんか適当に書いてる。 僕より前に入社したエンジニアは、わりとギークっぽい感じで
ドワンゴに入社した
そう。タイトル通りだ。筆者、江添亮はドワンゴに雇用された。一体、どのような経緯でドワンゴに入社するに至ったのか。また、どんな仕事をしているのか。それを説明するには、時系列を追って書いたほうがいいだろう。 2013年8月21日 ふとみると、以下のようなサブジェクトのメールが届いていた。 【ご相談】ドワンゴ主催の C++11, 14 に関する勉強会にスピーカーとしてご参加頂けないでしょうか C++11？ C++14？ なんと、日本にC++14などという単語を知っている企業があったのか。しかし・・・ドワンゴ？ SPAMだろうか。いや、こんなにピンポイントなSPAMがあるわけがない。 それにしても解せないメールだ。ドワンゴといえば、もちろん、あの有名なニコニコ動画の企業だ。ニコニコ動画と言えばWebサイトだ。ニコニコ動画やその関連サービスの開発にC++を使っているのだろうか。いやまて、たしか子会社
リモートワークには東京がよいのではないかと思った - ワザノバ | wazanova
http://www.amazon.com/Remote-Office-Required-Jason-Fried/dp/0804137501 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 「リモートワーカーになってみて感じてること」で紹介した37 Singnals のDHHの最新作「Remote: Office Not Required」の日本語版がでて、ちょっと話題にのぼってるようですが、東京のスタートアップがリモートワークを成功させるのに向いているのではないかとふと思いました。 リモートで仕事をする際に、オフィシャルな情報の共有はそれほど問題にはならないですが、カルチャーの浸透や日常の何気ない会話のような非オフィシャルの情報共有が、会社を一つにまとめるには重要と言われてます。そこで、 GitHu
仕事で失敗して薪を切りたい時にオススメするチェーンソー 5選 - 自省log
ビジネス成功の真髄は 「失敗を受け入れて、いかに自身の血肉としていくか。」 らしいのですが、そうは言っても失敗した直後ってやっぱり落ち込んじゃうもんですよね。私はハートがオブラートでできている貧弱を地で行くタイプなので失敗してはよく凹んでおりまして、そんなときに薪を切ってみたら気持ちが落ち着いたので本日は切りやすそうなチェーンソーを紹介します。 諸注意ですが、薪とか木を切るだけに留めてくださいね。このチェーンソーを振り回すとかはもう本当シャレにならないのでやめてください。薪を切るだけですよ切るだけ、間違っても変なマスクつけて金曜日に外出しないでくださいね。 仕事で失敗して薪を切りたい時にオススメするチェーンソー 5選 ナカトミ(NAKATOMI) 電気チェーンソー(305mm) EC-305N ナカトミ(Nakatomi)Amazon電気工具界の新進気鋭ナカトミさんのチェンソー。3,980
『強いチームはオフィスを捨てる』：満員電車と決別するための一冊 - 脱社畜ブログ
Ruby on RailsやBasecampの開発元であり、このブログでは度々紹介している『小さなチーム、大きな仕事』（原題：Rework）で有名な37シグナルズがまた働き方についての本を出した。原著が出たという話は知っていたのだけど（ちなみに原題は『Remote』）、こんなに早く翻訳が出るとはすばらしいことだ。 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 作者: ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン,高橋璃子 出版社/メーカー: 早川書房 発売日: 2014/01/24 メディア: 単行本 この商品を含むブログを見る 今回のテーマは「リモートワーク」（≒在宅勤務）である。毎日通勤電車に乗って、規則正しくオフィスに通って仕事をするのではなく、各人のライフスタイルに合わせて家やカフェなどで、場所を選ばずに柔軟に仕事をするようなワークスタイルの
受託開発とサービス開発を同じメンバーが担うことへの挑戦
パソナテック Find Your Ability 講演資料 「ディレクターにとってのWeb業界って？ 」naoki ando
エンジニアとして「頑張る」ということ - 銀の人のメモ帳
プロジェクトにアサインされた段階で、これはデスマになりそうだな、と感じることがある。 そういう時、僕は、プロジェクトを管理している人に「デスマは絶対にしない」ということと「残業もしない」という旨を伝えている。 これは、決して「頑張らない」という事ではなくて、スケジュールや予算の調整は、エンジニアより上のレイヤーの人間が「頑張る」べきことだと考えているから、そう言っている。 エンジニアとして僕が「頑張る」べきことは、例えば自分を含めたプロジェクトメンバーのスキルアップであったり、開発効率向上等によって工数を短縮出来ないかを考え、実行することであったり、プロジェクトで得たノウハウを次に活かせるような形で保存・共有することだと思っている。 実際は、様々な状況でデスマや残業をせざるを得ない事が多々ある。会社として頑張らなければならなかったり、金銭的なものであったり、色々な事情がある。 そうなったら
2013年を振り返る - ギークに憧れて
2013-12-31 2013年を振り返る 今年も残す所あと僅かとなったので､振り返りを実施する運びとなります｡ 1月 仕事 昨年から続いていた炎上案件の火消しをする｡精神がやられ気味になる｡ ブログ･作った物 ツイートするIntelliJプラグインを作ったよ - ギークに憧れて SKIPのGoodJobを通知してくれるChrome拡張作った - ギークに憧れて 2月 仕事 炎上案件から解放されて常駐先に戻る｡ ブログ･作った物 Node.jsとかTitaniumとか触ってた記憶があるけどあんまりよく覚えていない｡ eXcaleでcronしてみる - ギークに憧れて 3月 仕事 社内フレームワークでコード書いてた記憶がある｡ ブログ･作った物 勉強会で初めて発表側に回る｡JavaScript初心者を克服したかったのでjs系の勉強会に参加する｡ JsCafeに参加して読書会してきた - ギー
レビューフレンドリーな開発のしかた - tomykaira makes love with codes
2013-09-02 レビューフレンドリーな開発のしかた git dev 最近は多くのチームでレビューの習慣が定着してきました。おもにレビュアーとしての仕事を依頼されることもあります。 コミット・ブランチの作りかた一つでこのレビューのしやすさが格段に違ってきます。 自分が普段の開発でこころがけていることをまとめてみます。 前提 レビュイーとレビュアーの間に上下関係があるわけではないですが、レビュイーは多少手数が増えても、レビュアーのことを最大限配慮すべきです。 なぜなら、レビュイーはその機能の開発に集中して取り組んでいますが、レビュアーはすこし見るだけです。 なにかするとしたら、レビュイーがやったほうが時間も手間も少なくなります。 レビュアーはレビュイーよりも、変更について詳しくありません。 レビュイーは開発にいろんな部分を見てまわり、他のモジュールとの関連性や実装のこまかな意図を把握して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【Omoroki 9 Hacks】 組織のあり方を考えている人へ
