TechBlog運用の難しさとHERPでの考えについて（TechHub公開に寄せて）
HERPの技術発信の場として、HERP TechHubをリリースしました。会社のドメイン上ではなく、個人のブログのHubとしてのページを作成する形をとっています。 それに至った背景について書いてみたいと思います。 TechBlogのあり方を考えてみるTechBlogの目的と内包している問題について、エウレカでTechBlogの開設・運用をリードした経験から得られた課題も踏まえて考えてみる。 TechBlogの目的 従来のTechBlogの開設・運用の目的は以下の3つにまとめられると思う。 ブランディングを通じた採用力の向上エンジニアの個人ブランディングエンジニア全体・技術貢献ブランディングを通じた採用力の向上 エンジニア採用においては情報発信は欠かせない。もちろん一番大事なのは良いUXを提供できるプロダクトを作り、その品質を上げていくことだが、それだけでは社外の人間からして技術への考え方や
プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
モブプログラミングとコードレビュー
特集1では，2人1組になってコードを書くペアプログラミング（ペアプロ）と，チーム一丸となってコードを書くモブプログラミング（モブプロ）について解説します。… この中で、モブプロは モブプログラミングの「モブ」とは群衆のことです。モブプログラミングでは、ペア（2人）ではなく、モブ（チーム全体）でプログラミングを行います。モブの人数は3人から5人くらいを想定しています。ペアプログラミングと同様に、コードを書くだけでなく、すべてをモブで行います。 と説明されています。 私がモブプログラミングという言葉を初めて聞いたのは、現マイクロソフト牛尾氏の以下のブログ投稿だったように思います。
新卒を3ヶ月で捨ててフリーランスになって変わったこと、得たもの、そして失ったもの
新卒入社したピクシブ株式会社を退職し、フリーランスになって半年以上経った。本格的に仕事をし始めたのは8月からなので、まぁ丁度半年と言っても問題ないだろう。 自分は高卒で入社しておいて3ヶ月半でやめるという信じられないような行為をした上でフリーランスとして生きているわけだけれど、今の生き方はすごく満足している。自分にとって新卒というカードはあまり重要ではなかったので使ったことに特に後悔はないし、ストレートでフリーランスになるより数ヶ月だけでも新卒をできたのは良いことだと思っている。 とはいえ状況としては今のほうが性に合っていることは間違いない気がするし、良いことを書きたいんだけど、それはそれとして、明確に失ったものもあるのでどちらもどこかにまとまったテキストとして書き残して、これからまた自分が大きな人生の選択をする時に考えるためのものとして活用できたら良いなということを思い、書いてみることと
エンジニア採用に必要な4つの軸 – Yoshiyuki Kakihara – Medium
エンジニア採用に必要な4つの軸ソフトウェアの会社やっているとつくづく思いますが、エンジニア採用って難しいですよね。会社にとってのタイミング、相性、スキルなど、考えなくてはいけないことがとても多い。僕自身も常に悩みながら取り組んでいるのですが、最近、社外の経営者の集まりなどで採用のやり方について聞かれることが増えてきたので、一度考えを整理してみたいと思います。 どんな人が欲しいのかをまず決める採用活動はマーケティングであり、実務の内容は営業活動に似ています。ターゲットを決めないマーケティングが成功することはほとんどないですね。ダイレクトリクルーティングがいい、このメディアがいい、などなど、ついノウハウから入ってしまいがちですが、そこはぐっとこらえる。ゴールから目をそらしてしまったらPDCAを回すことは不可能です。ターゲットを決めましょう。 この「どんな人を採用するべきか？」という問いに対して
信頼できて行動力を持った仲間 - erukiti - Medium
行動力を持っていて、僕に取って信頼できる人であるところのおやかた@技術書典4(当選) (@oyakata2438)さんがこんな発言をしていた。 最近、口に出したことがいろいろ実現したり、具体化に向け相談中、なんてことが続いている。 信頼できる人たちには、やりたいこと、あったらいいな、をとりあえず伝えておくと、絶対損しないw飲み会とかでもいいのでｗ — おやかた@技術書典4(当選) (@oyakata2438) February 13, 2018 これ、ちょっと条件があって、人として信頼できる人達でも行動力の無い人たちなら実現しないし、行動力があっても人として信頼できない人たちだったら困った事になりがち。僕はそういう意味では、技術書典をきっかけに、親方さんを含めた信頼できて行動力がある人達と去年出会えたのがとても大きい。 年末に書いた通り、一昨年から去年にかけてかなり重度の人間不信に陥る事態
イギリスで働く
日本からイギリスのオフィスへ出向になり早一年が経った。 日本人エンジニアが海外で働くことも珍しくなくなってきた今日、海外生活について綴ったブログ記事をよく見かけるが、だいたいほとんどがUS、それもシリコンバレーの話。せっかくイギリスにいるんだしイギリスの話も書いてみるか、と思いキーを叩いている。 なぜ移住したかというと、御託はいくらでも並べられるが、一言で言うと退屈だった。20代後半が退屈だったら、あと3–40年何をするんだと。とりあえず、一旦無力になれば見えるものもあるかもしれない。コンフォートゾーンとかミドルライフクライシスがどうとか、さしずめそういう話だと思う。 自分はBristolという南西部の都市に住んでいる。人口で言うと、イギリスで10番以内には入るかな、というくらい。これがLondonやManchesterのような大都市だと話は変わってくると思うので、「こういうのもあるよ」く
タベリー | とある仕様書 – Yamotty – Medium
グループ共有機能仕様書の公開に踏み切ったのは、10Xのプロダクトがどうやって作られているか、について部分的に触れてもらえると思ったから。 10Xでは「細かな実装・デザインの白兵戦」・「認知と理解を獲得していく空中戦」を一緒に戦えるプロダクト・マネージャーを育てていきたいと思っているので、この仕様書を読んで「10Xで力を試してみたい！」という方はぜひ以下のフォームから応募してほしい。ユーザーの感情を科学できる人が10XのPMにはフィットすると思う。 仕様書の前提となる考え仕様書は「チームのワーキングスタイル」によってその役割をかえるものだ。今の10Xは「ユーザーの前に積まれた膨大な課題の山に優先度を付け、とにかく早くプロダクトをプッシュしていくこと」が最優先のチーム。 そのため、「膝を突き合わせて瞬発力の高いコミュニケーション」を重視している。リモートはしない。 この環境では議論のすべてが口
個人で運用している Web サービスをどう管理しているか 2018年版 - r7kamura - Medium
個人で運用している幾つかの Web サービスについて、自分がどう管理しているかを振り返る。 実験には Heroku を利用習作につくったアプリやβ版段階のアプリは、Heroku で動かしている。Heroku を使う場合のより具体的な条件としては、データベースが明らかに無料枠に収まりそうで、24時間動いていなくてもまあ誰にも怒られそうないような場合。Slack 用の Bot や、nippo という日報専用サービスのクローズドβ版などを主に置いている。 メリットに感じている部分は、無料で使えること。デメリットに感じている部分は、サーバが US に配置されることと、データベース系の Add-On が高くつくこと。例えば日本語圏向けのサービスだと、通信時間がそこそこ長くなり、結果的にサービスの体験が悪くなる（昨今の平均的な Web サイトの速度はまだまだ遅いので、それと比較すると悪くなるというほど
DroidKaigi 2018 アプリをGitHubで公開しました
DroidKaigiのカンファレンスアプリは毎年多数のコントリビューターが参加しており、たくさんのAndroidエンジニアの技術や知見がつまったアプリに毎年なっているのではと感じています。 この記事を書いている時に、もうすでに去年の62人を大きくこえる82人のコントリビューターがアプリに貢献していただけていることに大変感謝しています。 今回はまだ参加していない方も簡単に参加できるように、簡単なガイドを作成しました！ Androidエンジニアのみなさんがオープンソース開発に参加してみる最初のいい機会になるのではと考えています。 まずはDeployGateから開発中のDroidKaigiアプリをインストールしてどんなアプリか確かめてみましょう 簡単なコントリビューションガイド1. DroidKaigiアプリはGitHubのIssueを利用しています。このIssueの中で、自分ができそうであった
日本マイクロソフトを退職します
日本マイクロソフトを退職します新卒で入社した日本マイクロソフトを 1 月 17 日に退職します。 学部生の頃、就職できるはずのない雲の上の企業でした。 就職活動していた際にも視野に入れていませんでした。 なぜそんな大企業に就職したのに退職するの？ こんな記事も書いてもらったのに退職するの？ という質問をよくされるので、いわゆる退職エントリを残しておきます。 なぜ退職するのか最初に、日本マイクロソフトは素晴らしい会社です。 私自身、技術力以外にコミュニケーション能力や電話応対能力、メール文章作成能力が格段に成長しました。 しかし、技術職であるにも関わらずコードを書いてチームで開発をする機会は全くない部署でした。 そこでふと、「このまま今のカスタマー サポートを続けていて自分は何年後かに後悔しないだろうか。」と思いました。 そして、試しに転職活動をしてみると同じ外資系のカスタマー サポート職の
エンジニア向けの社内情報共有ツールの紹介
FiNCのエンジニアの人数も50人を超え、チームを横断した情報共有の機運が高まっています。 もともと社内には情報共有ツールとしてConfluenceやGitHub Wikiなどがありましたが、前者はMarkdownなどのエンジニアがドキュメントを書きやすい機能が不足しており、後者は情報の検索性に難がありました。 エンジニアのコミュニケーションを活性化させるため、カジュアルに記事を投稿できて誰でも見ることができる、新しい情報共有ツールを導入をすることにしました。 今回は候補として検討した際に、以下の要件を満たしていた情報共有ツールを紹介します。 Markdownを使ってプレーンテキストで記述できる記事の更新履歴のdiffを見ることができるフィードで記事の一覧を見ることができるわかりやすい検索機能コメント欄でのやりとりができるWebhook(チャットツール連携)UML記法やスライドの埋め込みの
Swift コンパイラの警告を無視できないようにする
これは Optional(2018) 年対策のひとつとしてアリですね。 @koher さんが昨日 Qiita で記述されたとおり、デフォルトではコンパイル時の警告（⚠️）を無視できます。
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
エントロピーの先に生命が見る夢と、世界と時間の美しさと、挑戦
元旦にこういうツイートをしたらたくさんリツイートしていただいたので、せっかくならそう思った背景と決意を書き残そうと思い、初めてブログの筆を取りました。 すべては宇宙の大原則から始まるこんなにも世界は進化しているのに、何故また次々新たな問題が出てくるのだろうと、疑問に思うことがあります。 たとえば、インターネットによって確実に世界は便利で安全になっているのに、より孤独を感じます。ＷＨＯは、世界で鬱病に苦しむ人が急増し、推計約3億人強にも上ったと発表しています。飢餓問題が減っても、肥満患者は世界に約10億人いて、今度は過食で死ぬ人が増えています。 たとえば会社経営においても、組織としては確実に成長しているのに、課題を解決したと思ったらまたどんどん新しい課題が出てきます。以前、オリックスの宮内さんが、会社小さいうちはいろんな問題があると思って頑張って会社を大きくしたけど、結果的には、会社が大きく
株式会社YOUTRUSTを作りました
この文章は、いつか仲間になってくれる人と軸がブレそうになったときの自身に向けて書いています。このエントリが今後何年か、拠り所になるといいなと思います。 2017年12月28日、株式会社YOUTRUSTを作りました（厳密には登記申請をしただけでこれを書いている30日現在、無事に設立できるかはわかっていませんが…）。 なんで会社をつくったのか、そもそもなんで会社をやめたのか、何をしようとしているのか、自分にとっても人生の節目である2017年のうちに記憶に残しておこうと思います。 何をしようとしているのか雑にいうと「転職市場の気持ち悪いあれこれをなんとかしたい」です。 私自身が採用を4年やってきて市場に感じた採用側としての違和感と、自分が初めて転職をしようとした際の求職者としての違和感、この両方が揃ったときに「なんとか解決したい」と思うようになりました。その思考が止められず、気がつくと会社を辞め
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PWAs are coming to iOS 11.3: Cupertino, we have a problem
研究者からエンジニアに転生して1年経ちました
Androidアプリ(β版)のリリース報告と開発当日レポート
年収とシリコンバレーとソフトウェアエンジニア
