タグ

workとdevelopmentに関するmoqadaのブックマーク (63)

  • 30日間、開発をお休みします

    カタツムリのように働くEnglish version is here こんにちは、TAKUYAです。 数日前にInkdropの新しいモバイル版をリリースしました。今のところとても好評で嬉しい限りです。幸いなことに、Inkdropはここ一年ずっと成長し続けていて、以下のように決済回数が安定して増えています: そして先月の売上は26万円でした。やっと前職の給料を上回りました(笑) 東京で生活するには充分の利益です。このまま伸ばすことができれば、フリーランスも安心して辞められますね。 現在のロードマップも残すところあと一つとなりました。最後の項目は、タスクのプログレス表示機能です。モバイルアプリの再開発に比べたら簡単そうですね。新モバイル版に取り組んでいる間にデスクトップ版の機能要望が大量に溜まっています。次のロードマップにむけてそれらを整理して議論する必要があります。また、デスクトップ版も同じ

    30日間、開発をお休みします
  • 子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには - エンジニアHub|若手Webエンジニアのキャリアを考える!

    子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには お父さんは出産を除くすべての子育てタスクを担当できるとして、エンジニア的なアプローチで育児に取り組む白山文彦(@fushiroyama)氏が、キャリア構築や技術的成長との両立について語ります。 こんにちは、白山(@fushiroyama)と申します。主にモバイルアプリ開発を生業としています。 4年前に第一子をリリースして地道な改善施策を重ねつつ、半年前にめでたく第二子もカットオーバーしました。以来、外ではソフトウェアエンジニアとして外貨を稼ぎつつ、家庭ではフルスタックお父さんとして、事に風呂に寝かしつけに夜泣き対応にと奮闘しております。 その過程で「エンジニアでよかったなぁ!」と感じた点や「こういう考え方やアプローチはエンジニアならではかもしれない」と感じたことが少なからずあったので、ぜひ紹介したいと思

    子育てを支える技術 ─ フルスタックお父さんとエンジニアとしての成長を両立させるには - エンジニアHub|若手Webエンジニアのキャリアを考える!
  • 計画する技術 - kakakakakku blog

    今日は社内勉強会で「計画する技術」というタイトルで発表をした. 前から少し「計画」のところに課題感があって,そのあたりの知識を組織に広めて欲しいというオーダーもあったため,僕が日々考えていることを言語化して,発表することにした.僕は今までに様々な「計画」の経験があり,実際に今の組織でも難易度の高いプロジェクトを何度も計画し,遂行してきたため,「計画」に対する信頼残高は増えているのではないかと思う. 発表資料 意識したこと 今回,発表資料を作るときに意識したことが2個あった.他にも話したいことはたくさんあったけど,組織マネジメントの話はまた別でしようと思って,あくまで「計画」に特化した話にした. 明日からすぐに使える話をする 開発プロセスに依存しない話をする 1. 明日からすぐに使える話をする 原理原則すぎる話や,難しい法則の話は控えるようにした.そういう話をしてしまうと,その場では「おー,

    計画する技術 - kakakakakku blog
  • エンジニアチーム全員がフルリモートで働く際に役立つ便利ツールと組織のルール | 働き方・カルチャー

    こんにちは、株式会社キャスターでCTOを担当しています、福田です。 株式会社キャスターはオンライン秘書サービスを主な事業として展開しており、100名以上の従業員全員がフルリモートで働いています。 エンジニアチームもその例外ではなく、当然全員がリモートワーカーで、各自が自分の好きな場所に住み、集中できる環境でコーディングに勤しみ、必要に応じてオンラインで活発に議論しながらモノづくりをしています。 このブログで伝えたいことそんな我々エンジニアチームは、自分たちにとって働きやすい環境は何かを追求するため、日々新しい取り組みを実験として試しながら、リモートエンジニアリングに最適なツールやルール作りに取り組んでいます。 今回のこのブログでは、そんな我々が、日々愛用しているツールや、リモートワークをする上で気をつけていることや組織のルールの一部をここで紹介させていただこうと思っています。 この記事を読

    エンジニアチーム全員がフルリモートで働く際に役立つ便利ツールと組織のルール | 働き方・カルチャー
  • テックリードという役割

    なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術エンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ

    テックリードという役割
  • 一日8時間、60日間ペアプロしてみて思った日常ペアプロのコツ. 一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミン… | by Naohiro Oogatta | Medium

    一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 (ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program

  • ドイツの受託開発会社を退職しました - WETな備忘録

    2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い

    ドイツの受託開発会社を退職しました - WETな備忘録
  • メンバーが増えるので、開発方針をまとめました。 - CureApp開発者ブログ

    2016 - 03 - 31 メンバーが増えるので、開発方針をまとめました。 4月から、新たに3名のエンジニアがCureAppに加わります! 今まで、チームとしてどうあるべきか、というのもあまり考えずに走ってきました。 ということで、ここで一度振り返って、どういうチームでありたいか、ということをまとめてみました。 長くて暑苦しくなってしまうものですね。 これを、初版としてどんどん改良していきます。 CureApp開発チームの目指すもの、それは それぞれが別な得意領域を持ちながら広くシステムを理解し、開発に参加できるチーム 社員は、どのプロジェクトにアサインされても戦力になるようにする。 そのために、 マルチプラットフォーム な言語を選択する (まずは JavaScript ) 皆が思う「良いコード」が同じになるように、 設計思想 を統一。 同期/非同期 コミュニケーション により情報を共有

    メンバーが増えるので、開発方針をまとめました。 - CureApp開発者ブログ
  • エンジニア立ち居振舞い: 気持ちよりも行動を評価する - ✘╹◡╹✘

    エンジニア立ち居振舞い」 というお題に対しての投稿。 立ち居振る舞いというか、姿勢、それも比喩的な意味での姿勢の話なのだけど、所謂やっていく気持ちよりも、行動した事実に価値を見出すように努めている。エンジニアと言うとその職業柄、仕事の所作みたいな話が多くなりがちだけれど、何も仕事に限った話ではなくて、例えばブログ記事を書くときなどもそうであると思う。こういうものを頑張ってつくっている最中であるとか、こういうところで困っていて大変といった気持ちを吐露したくなることがある訳だけど、そこは矜持としてグッと我慢して、早くいいものを完成させてみんなを驚かせたいとか、苦しい気持ちはひた隠しにして反骨精神を高めるとか、そういう気持ちに変換して、より大きな成果を上げられるようにしたいと思っている。 自分に限らず他人の行動についてもそうで、何かやりたいと言っている人や、あるいは筋の良さ悪さについて考えあぐ

    エンジニア立ち居振舞い: 気持ちよりも行動を評価する - ✘╹◡╹✘
  • 技術採択のときにやるべきこと - まるまるこふこふ

    初めに 新規プロジェクト/既存プロジェクトで、新しく使う ライブラリだったり、フレームワークだったり、ミドルウェアを選定してきた経験を通して、 採択する段階でこれはしておいた方がいいなという知見が溜まったので、 メモ書き程度に記述します。 前提として、技術採択についてある程度メンバーに裁量が任せられている風土があり、 かつミッションクリティカルでないシステムに導入する、また自社で事業を行っており、 顧客=ユーザーであるというのがあります。 (この辺の前提条件が違う場合、採択に当たってまた別の観点が必要になってくると思います) システム要件を満たしているかどうか なんだかフワっとした言い方になりましたが、例えば Web システムに JavaScript のライブラリを 導入する場合に、Web システムが IE8 に対応するという要件ならば、 そのライブラリが、IE8 でも動くか調査するという

    技術採択のときにやるべきこと - まるまるこふこふ
  • Kaizen Platform, Inc. エンジニア行動指針

    Engineering Teamの Akira MAEDA です。 今回はKaizen Platform, Inc.社内にあるエンジニア行動指針を紹介したいと思います。 このエンジニア行動指針は創業間もない頃に技術顧問のNaoya Itoが中心になって作成し、今から2年半ほど前にオフィスに遊びに行った私に、CTOのToshimasa Ishibashi、Naoya Itoの二人がKaizen Platformの実現しようとしている未来とともに熱心に説明してくれ、私のKaizen Platformへの転職のきっかけになったことを今でも思い出します。 以下内容 — - Kaizen Platform, Inc. エンジニア行動指針Message from CEO (Kenji Sudo)・ 我々はクラウドソーシングで新しい働き方を作り出していく集団なんだから、我々自身も新しい組織のあり方に挑戦

    Kaizen Platform, Inc. エンジニア行動指針
  • 2年半のリモートワークを振り返ってみる - じまろぐ

    フルリモートワークな会社に勤めて2年半が経った。簡単に振り返ってみる。 前職と現職 前職はごく普通の勤務体系(10:00 ~ 19:00)で働いていた。 今いる会社は全社員がフルリモートワークで、出社義務も一切なく、勤務時間も各自の裁量で決められる。業務はフロントエンドの受託開発をメインとしていて、CodeGridという自社の技術系メディアの運営もしてる。担当業務としては案件のフロント部分全般と、記事執筆がある。 コアタイムとかそういった規則が一切ないので、いつどこで働くかを自分でコントロールできる。そんな会社に入って2年半が経過したので振り返ってみる。 適応しようともがく期 いきなりフルリモートに適応できる人は稀だと思う。業務のことも同僚のこともわからないので、最初はとにかく環境に適応するために邁進。心理的な余裕が少なく、ゲームやっててもあんまり楽しめてなかった気がする。 リモートワーク

    2年半のリモートワークを振り返ってみる - じまろぐ
  • 初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG

    こんにちは、fluct SSP開発部の@saxsirです。 今年の4月に入社した新人ですが、職場ではgolangとかAWSとかを使って社内向けのプロダクトをゴリゴリと開発しています。 さて、VOYAGE GROUPでは人事評価制度の一つとして技術力評価会という相互評価の仕組みがあります。 これは年に2回ほど開催されており、直近半年くらいの仕事から何かテーマをピックアップし、別チームのエンジニア2名(評価者)に「私はこんなすごいことをやったんだよ、どやっ」とお話しながら自分の技術力を評価してもらうという場になります。 もちろん、新卒も例外なく技術力評価会を行います。 今回は初めての技術力評価会を終えて私が学んだこと、を社外の方向けに書こうと思います。(言うまでもなく、私は被評価者です) ※以下、「技術力評価会」を「評価会」と略して表記する場合があります TL;DR 「なぜやったのか」を説明

    初めての技術力評価会を終えたので感想を書いた - CARTA TECH BLOG
  • いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;

    先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう

    いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
  • NTTからピクシブ株式会社に転職しました - 大企業からベンチャーへ移ったエンジニアの話 - ふろしき Blog

    ピクシブ株式会社に入社しました!…といっても、入社したのは2015年8月1日と約1年前です。 「転職エントリーは、転職した直後に書くよりも1年後の方がいいのでは?転職の興奮が覚め、会社のこともある程度わかってから書いたほうが、身になる話ができるんじゃないか?」 なんてことを入社直前に思いつき、あえて今頃になって、転職エントリーを書いています。 このエントリーでは、大企業からベンチャーへ、エンタープライズ系からネット系へ、受託メインの会社から事業メインの会社へ転職した私が、1年経った今感じていることをお話しします。それで、後ろに続こうとしている人に、何かしらのヒントを残せたなら、私としても嬉しいです。 最初に言っておきますが、「こんな会社辞めてやる!」的な、そういうコンテンツはないので、期待しないでください!!! 転職で変わったこと 私の転職は、テクノロジーというキーワードを除くと、なにもか

    NTTからピクシブ株式会社に転職しました - 大企業からベンチャーへ移ったエンジニアの話 - ふろしき Blog
  • 「プログラマとして食べていく」という話を福井県の学生さん達にしてきました - その後のその後

    一昨日、福井県の「ふくい産業支援センター」さんが主催されたセミナーで、標題の講演をさせていただきました。資料はこちら。 参加者約70名のうち、75%は18歳以上の大学生・専門学校生、15%が高校生・高専生、10%が小中学校。これまでエンジニアの中で話をする機会は多々ありましたが、学生さんばかりの中で話すのは初めてでした。 内容 内容としては、「プログラミングでこんな感じでメシをってる人がいる」という一つの参考例として自分の働き方を紹介しつつ、プログラマとしてとりあえずやっていけるようになるまでの話と、フリーになってからおもしろい仕事を得るためにどんなことを考えながら働いているか、の3部構成でした。 50分と長尺の講演だったので、最後にFAQをくっつけて時間調整できるようにしておいたのですが、6つぐらい用意しておいたうち2つぐらいしかしゃべれず。話したうちのひとつは「お金の話」だったのです

    「プログラマとして食べていく」という話を福井県の学生さん達にしてきました - その後のその後
  • リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話

    1年くらいリモートワークを続けてみた感想 まず当然ながら「リモートワークは生産性が高い!これこそ未来のワークスタイル!」のような感想はありません。 生産性やコミュニケーションに関連するメリット、デメリットをうまく相殺しきれれば、生活の自由度だけ向上してハッピー、と考えています。 今は自宅かレンタルオフィスのいずれかを作業場として開発などを行いつつ、社がある渋谷には1泊2日の出張を月2回するようなペースで仕事をしています。基Slack でテキストチャットによるコミュニケーションをメインとしつつ、必要があれば MTG に Hangout でビデオチャットで参加します。 生産性は大して上がらない 期待していた生産性は、それほど向上することはありませんでした。 東京にさえいなければ気軽に MTG に呼び出されることもありませんし、開発に充てることが可能な時間は若干増えています。通勤時間が長

    リモートワークの勘所と限界について1年くらいの感想、組織にとっての選択肢作りの話
  • 英語できないエンジニアだけど外資系に転職してしばらく経ちました - タオルケット体操

    僕の英語力について こういう記事って、「英語できない」を過少申告してること多いですよね。「TOEIC820点しかとれてなくて全然ダメなんです>_<」みたいな。アレはなんなんですかね? ちなみに僕はそもそもTOEICを受けたことがないです。 そんな僕のスペックをまとめると 学生時代に特に苦手意識を持ったことはない(苦手意識を持つほど勉強しなかったとも言える) TOEICを受けたことがない StackOverflowを読むくらいならなんとか 英語で会話したことは(ほぼ)ない 去年初めてヨーロッパに行った際、「tea or coffee?」にcoffeeと答えたらteaが出てきた DMM英会話の無料体験をしてみたら死んだ つまり公式には学校教育でしか英語を学んでいないということになりますね。平均的な日人って感じだと思います。そして学校の英語教育は役立たずで有名(実際に役立たずっぷりを実感)なん

  • 個人的な老害エンジニア行動指針を策定した - tehepero note(・ω<)

    2016 - 07 - 01 個人的な老害エンジニア行動指針を策定した エンジニア 自分は今33歳なので、Webの世界においては完全に 老害 と言われてもおかしくない世代にさしかかっています。自分は 老害 には決してならないと強い意思を持っていたとしても、どうやら 脳科学 的には避けられないものだと聞いたことがあります。 というわけで、意思よりも明文化すべきだろうということで個人的にではありますが、 老害 エンジニアとしての行動指針 を策定致しました。 若くないことを肯定し、世代の違いを認識する 親の世代に比べると例えば今の30代は過去の30代よりも若いし、40代は過去の40代よりも若い人が多くなったというイメージがあります。自分が子供の頃の30overって完全にオッサンオバハンのイメージでしたが、少なくとも見た目の面では変わってきている潮流にあるのでしょう。老化のスピードは緩まっているの

    個人的な老害エンジニア行動指針を策定した - tehepero note(・ω<)
  • トレタ増井氏×桂対談 - エンジニアが年収700万円台の壁を越えるためには何が必要?(前編)|転職ドラフトReport

    トレタ増井氏×桂対談 - エンジニア年収700万円台の壁を越えるためには何が必要?(前編)2016-06-27 18:00 ※写真左から株式会社リブセンス 取締役 桂大介、株式会社トレタ CTO 増井雄一郎 第2回転職ドラフトに株式会社トレタさんが参加します!飲店向けの予約/顧客台帳サービスを作っているトレタさんと言えば、@masuidriveこと増井雄一郎さんがCTOを務めている会社。エンジニア年収やそれを上げる方法などざっくばらんにお話を伺います! エンジニアリングだけでは年収700万円台が壁 桂: こんにちは。今日はいろいろお伺いさせてください。 増井: よろしくお願いします! 桂: 転職ドラフトでは、企業がユーザーを年収付きでドラフト指名します。そこでまずお伺いしたいのですが、増井さんは、高い評価を受けるITエンジニアってどんな人だと思いますか? 増井: 自分でいろいろ作った

    トレタ増井氏×桂対談 - エンジニアが年収700万円台の壁を越えるためには何が必要?(前編)|転職ドラフトReport