テックリードという役割
なぜこの文章を書くか?自身が数ヶ月テックリードの役割で経験した内容を基に、テックリードがどういう役割で、毎日の仕事の中でどのような仕事をするのかについて書いていく。 テックリードはサンフランシスコのWeb系企業では一般的なようだが、日本ではまだそれほど広まっているとはいいづらいと思う。 テックリードに求められるのは一言で言えば”技術でエンジニアチームをリードすること”である。Webエンジニアのキャリアパスでたびたび二元論的に語られる、”技術一本で生きていく”職人的なトラックとも”人やプロジェクトのマネジメントをする”マネジメント系のトラックともニュアンスが異なる。 自身の技術力、そしてリーダーシップをもってエンジニアチームのアウトプットを最大化させていくのがテックリードの役割である。 多くの人にその役割を知ってもらい、エンジニアとしてのキャリア形成の助けになればと思っている。 なお、このポ
日報共有アプリケーションをOSSとして開発している話
日報一覧画面最近、プライベートな時間をつかってRepostというオープンソースの日報共有アプリケーションを開発しています。 投稿した日報に対して、コメントや絵文字でリアクションすることでチームでのコミュニケーションを活性化させることを目的としています。日報版Slackのようなイメージです。 まだ開発着手から1ヶ月ということもあり、バージョン0.0.1でまともに稼働できる段階ではないですが、開発のモチベーションを高めるためにも記事を書いてみました。 技術スタック チャンネル作成画面RepostはフロントエンドにReduxを採用し、SPAとして構築しています。APIサーバとしてのバックエンドはRuby on Railsで開発しています。また、エディタ部分はDraft.jsを用いてMarkdownエディタを実装しているところです。 Draft.jsについては、過去にとあるプロダクトに採用した経験
Swift の if case / guard case によるパターンマッチングの使いどころ
今日したこんなツイートの補足ツイートをしようとしつつ、やや長くなりそうなので、プチ記事にしました( ´･‿･｀) aa上の例は、「caseを使わずとも guard payload.aps.category == .dog else { return } と書けば良いのに」と思われそうで、確かにそう書ける時はそれがベターかなと思っています。 改めて書くと、次のような感じです。 enum Animal { case 🐶, 🐱 } let animal = Animal.🐶 if animal == .🐶 { print("イッヌ🐶") }では、次のように associated valueをもつ列挙型の時はどうでしょうか？ enum Animal2 { case 🐶(name: String), 🐱 }let animal2 = Animal2.🐶(name: "mono") i
API Diffs的にApple Developer Documentationサイトを見られるChromeエクステンション
確かiOS 10.1からだったと思うのですが、Appleから新しいAPI Diffsが提供されなくなりました。その代わり、リファレンスページであるApple Developer DocumentationでSDKのバージョン間の差分をハイライト表示できるようになったので、これが実質的なAPI Diffsの代替になっているのだと思います。 ですが、開発者としては、旧API Diffsのように差分だけをまとめて見たい場合もあります。また、Developer Documentationでは、3階層目にまで降りていかないと変更されたクラス等のリストが見られないため、一覧性に関しても不満を感じていました。 エクステンションが有効になっている状態でDeveloper Documentationにアクセスすると、ブラウザ右上のポップアップから次の操作ができるようになります。 変更されていないAPIを非表
Incrementsを退職します – r7kamura – Medium
IT エンジニアが退職するときに添えられることが多い東亜飯店の画像今月いっぱいで Increments 株式会社を退職します。今日が最終出社日で、残りは有給消化です。 Increments では何をやってたの？Increments と言えば Qiita を運営している会社というイメージですが、Qiita の開発に直接携わる機会はほとんどなくて、技術基盤や Qiita:Team の開発に携わったりしていました。 分かりやすい例を幾つか挙げると、Qiita API v2、トップページのフィード、通知購読、絵文字リアクション、タスクリスト、qiita-elasticsearch、qiita-markdown、アクセス権限付きグループ、サポートサイト、チーム統合機能の開発や、UI 刷新、絵文字画像セット移行、ログインセッション永続化、Docker 移行、VPC 移行、Terraform 導入、We
私が松江にUターンした理由
おことわりもともと[松江移住ITエンジニア Advent Calendar 2016](http://www.adventar.org/calendars/2018)の記事をQiitaで公開していましたが、「プログラミングとは関係ない」という理由で公開停止となりました。まあ、執筆当時知らなかったとは言え、基準は明確ですし、そのことに不満はありません。しかし、せっかく書いた文章が公開されなくなるのはもったいないので、こんどはMediumに書いてみることにしました。 今度はどうかな？ はじめにこれは[松江移住ITエンジニア Advent Calendar 2016](http://www.adventar.org/calendars/2018)の25日目です。 私が松江に引っ越してからおおよそ２０年になります。松江移住ITエンジニアの中でも古参と言っても良いでしょう。Ruby関連となれば確実に
普段はiOSエンジニアの方が英語の話をするとすごかった
年度末の金曜日を英語で締めくくろう！ # 今年こそ...今年こそ英語レベルアップしたい... もう一人で挫折したくない、仲間が欲しい、月一くらいでモチベーション維持のためにアウトプットの場がほしい...。 そんな気持ちで、今年こそ英語が… 主催のkayocoがTwitterで呼びかけてとりあえず始まってみたこの勉強会も第３回です。毎回満員御礼。LT枠は倍率約2倍です。枠の都合でなかなか来れない皆様には申し訳ありませんが、毎回内容はかなり濃密だと自負しています。 3回目にして、なぜここで記事を上げるのかというと、今回僕が登壇してほしいとお願いした吉川さんはじめ、内容が濃すぎて僕自身振り返りの時間を取らないと内容が吸収しきれなかったからなんですね。LT枠で登壇されたみなさまには大変申し訳無いんですけど、この記事では吉川さんが話されていた内容にフォーカスさせてください。(LT枠を含めたまとめは後
いいアイデアなんか思いつくはずがない
インタビューや観察の結果を整理する方法として「親和図法（affinity diagram）」がよく用いられます。また、そこからチームでアイデアを出す方法として「ブレインストーミング（brainstorming）」が用いられます（そこから再び親和図法に戻ることもありますね）。いずれも有名な手法なので詳細は省きますが、付箋紙をホワイトボードにペタペタ貼りながら、みんなでワイワイやるようなイメージです。 https://www.flickr.com/photos/jakecaptive/49915119よく用いられるからには、きっとそれなりの理由があるのでしょう。ですが、私はいずれに対しても（めちゃくちゃ）懐疑的です。使っていないわけではないのですが、使ってもいまいち感が残るというか、まるでうまくできる感じがしないのです。こんなのでいいアイデアなんか思いつくはずがない。それこそ「机上の空論」みた
合宿
いまアルバイトしている会社で合宿があった。 アルバイトも一緒にどうぞと誘われたので行ってきた。実はあちこちで働いてきたのに、合宿というのは初めての経験だったのでけっこう楽しかった。私は全社的な飲み会とか、社員旅行・研修とか、そういうのは嫌いだ。特に業務後や休日にそういうのをやろうとする会社は今の時代おかしいとすら思う。なるべくそういうのには関わりたくないし、強制でない限りこれまでは無視してきたし、今後も無視していくと思う。 但し、業務内に業務として全社的な企画があるのを否定するわけではない。前述したのは業務なのかそうじゃないのかを曖昧にして、経営者または管理者が意図的に画策しているなにかを誤魔化そうしているのが気に食わないだけだ。他人を巻き込むのにその当事者がそういった覚悟なしに行動していることそのものに疑念をもっている、つまりはそういうことだ。 さて、今回参加した合宿は、平日に朝から夜ま
ブログを書くこと
はてなダイアリーから Medium に引っ越したのでなんか書こうと思って書く。Medium の使い勝手や雰囲気に慣れるというか、まぁ書くことそのものが目的なので内容にはあまり意味がない。 かれこれ10年ぐらい、私はブログを書くのを続けてきたと思う。 非公開の個人の日記みたいなものから始まって、ブログが流行って、はてなダイアリーを書くようになって、働いた会社の開発者ブログも書いたりしてきた。話すのが嫌いなわけじゃないけれど、いろいろな理由から好きでもない。 たくさん話すとどっと疲れる言葉だと自分の頭にあるイメージの何分の1しか表現できない文章を書くと自分自身の思考の整理にも役立つもっともらしい理屈を並べてみたものの、単純に話すよりも書く方が好きだと、ただそれだけの理由かもしれない。 そんなことを考えていてふと思い出した。 プログラマというのは、一種の物書きに近い。 プログラマは35歳が限界ど
良いプログラマーを採用するには
ここで言う「良い」とは、優秀なとか、プログラミングスキルに長けたという意味。プログラマーと一口に言ってもいろんなタイプがいると思うし、お仕事だったら実務をチームでこなせることが第一条件になる。私なら以下の条件を全て満たせば良いプログラマーだと思う。採用やってるわけじゃないから本当にそうかどうかは知らない。 リーダブルコードが書ける継続的な学習習慣が身についている客観的に理解できるドキュメントが書ける英語の読み書きができるプログラミングが好き先日、管理部が上長に新卒採用で未経験であっても、どうやったらプログラマー適性のある新人を採用できるかといった話をしていた。中途採用を待っていても採れないから新卒採用に注力するらしい。そんな中で性格に多少の問題があってもプログラミングスキルの高い人を採用すれば、あとは開発側で何とかするといったことを話したところ、管理部もそれ自体は理解しているが、会社の方針
コミュニケーションは枯渇する
昔、働いていた職場で新たに昇格したばかりの社長がいきなりこんなようなことを言い始めた。 社内のコミュニケーションを活発にすれば業績が上がります。うまくいっていないのはコミュニケーションの問題です。 当時の私はなんか違和感を感じながら聞いていた。それから社員旅行や全社飲み会が企画され、半強制参加が義務付けられ、欠席者はその理由を社長宛にメールするという制度となった。そして、社内に組織横断的にいくつものタスクチームが設置された。個々のタスクそのものは業務とはあまり関係なく、目的はコミュニケーションを活性化させることにあった。 私が入ったタスクチームの課題は、全社員だったか全開発者だったかに「デュアルディスプレイ環境を導入する」といったタスクだった。当時、その会社ではモニターを持ち込みしてデュアルディスプレイ環境を整えている社員が数人いた。そういった環境を会社が全員へ支給してはどうか？ということ
失敗の活かし方
愚者は経験に学び、賢者は歴史に学ぶ。 有名な言葉なので聞いたことがある人は多いと思う。きっと頭の良い人は書を読んでたくさん学んで失敗を未然に防ぐのだと想像する。昔は私もそうあろうと、というかそうありたいと憧れていたけれど、最近はもう諦めてしまった。 そのため、本稿は経験から学ぶことを受け入れた人が書いたものだ。 失敗の仕方人間なので必ず失敗をする。 失敗そのものは防ぎようがないけれど、失敗の仕方は予防線を張れるかもしれない。やや抽象的な表現だけど、昔働いていた職場で上司から聞いた言葉が私の失敗に対する心構えの原点になっている。 自転車で車道と歩道の間を走行しているとき、どう転んでも車道側に倒れないこと。それが失敗の仕方。 私の場合、未知のことに取り組むとき、基本は楽観的になんとなくうまくいけばいいなと話しつつ、あまり言わないが最悪の場合も頭の中では考えていたりする。 例えば、勤めている会社
納期を守ることの意義
業務で納期を全く守らない組織で働いていていろいろ思うことがあった。 なんかもやもやしたので自分の考えを整理してみる。ここで言う納期を守らないというのは、具体的にいうと、例えばその担当者が2-3ヶ月程度で見積もった作業が結果的に3–6ヶ月程遅れるのが常態化している状況だ。そして遅れることが当たり前過ぎて何ら進捗管理をしない組織の話だ。私の感覚だと、見積もりの倍ぐらいの工数が実作業にかかるというのはビジネスの感覚としてはありえないもので、そのギャップに悩んだ時期もあった。 納期が遅れることによる弊害を洗い出してみる。 予定したスケジュールでその機能を含むサービスを提供できない予定した経費でその機能を開発できないここで時間 ≒ 経費とほぼ考えて良いと思うが、もう少し踏み込むと機会損失という考え方もある。先行者利益が大きい業界だと、時間が遅れることによる売上の減少というのは無視できない金額になる。
エンジニアとして歳をとっていく
普段はプログラマーとしてお仕事をしている。過去に SIer でプロジェクトマネジメントにも携わっていた経験があるため、状況によって顧客との折衝を行ったり、開発のマネジメントも行ったりはする。 エンジニアの中には、自分は技術のみでキャリアを築き、マネジメントは一切しないと固く決めている人もいるが、私はそういうタイプではない。技術は好きだが、業務で必要に迫られたり状況次第で臨機応変にマネジメントもしていくといった考え方で働いている。 最近マネジメントに関して話す機会があった。私がマネージャーとしてお仕事をするとしても唯一諦めている人たちがいる。 スキルもやる気もない年配の方はマネジメントできない。 こんな話をして聞いている人はだいたい苦笑いをしているし、説得力のある反論をこれまで聞いたこともない。もちろんこんな年配の方は滅多にいない。もし私がマネージャーだったらそういった人は絶対に自分のチーム
なぜ優秀なエンジニアを低待遇で採用してはいけないか
この記事は技術そのものやエンジニア採用のことがよく分からない経営者へ向けて書いています。エンジニアが読めば当たり前のことが書いてあります。また優秀なエンジニアならこう考えるのではないかというところは、私見によるものなので本当にそうかどうかは分かりません。 募集要項を書く募集要項で最も重要なのは待遇に関するところだと私は思います。具体的に言えば、だいたいの年収です。もちろん業務内容や組織の雰囲気なども重要ですが、業務内容や組織の雰囲気が良ければ年収が低くても働こうと思ってくれるのではないかと考えるのは経営者の奢りであって、そんなエンジニアはほとんどいません。優秀なエンジニアにとってはそのどちらも満たす求人が他にたくさんあるために候補にすらなりません。 逆に業務内容に魅力がなくても年収さえ高ければ良いという優秀なエンジニアも一定数いるはずです。待遇を具体的に書くことはそういった層に響くのではな
イケイケなベンチャー企業が「リモートワーク」導入失敗する３つの理由
私はもともと富士通っていう会社で働いてたんですが、そこには中国にいても北海道にいても違和感なく会議ができる仕組みがありました。（少なくとも私が所属していた部署の現場には） 会議スペースが絶対的に足りないという理由からMicrosoft Lyncが導入されて、それ以来は社員同士が（たとえ向かい合って座っているとしても）Lyncでスクリーンシェアしながら電話会議をするというのが習慣化していたのです。 ところが、2015年にとあるベンチャー企業に転職して、それが当たり前じゃないことに気づきます。 「リモートワークやろう」と意識高く言う人はイケイケベンチャーだとたくさんいます。しかし、ちゃんとやることもやらないまま「うまくいかない・・・」と結論付けられるさまを何度か目の当たりにしました。 この記事では、「ちゃんとやることやってからじゃない？」と違和感を覚えたところをなんとなく書きのこしておきます。
Medium Japan より大切なお知らせ
2016年は Medium にとって忘れられない1年となりました。Medium の Japan コミュニティは驚くほどに成長し、毎月数百のストーリーが日本語で投稿されるまでになりました。 年初に各種メディアでアナウンスさせていただいた記事を既に読まれた方もいらっしゃると思いますが、Medium はこれまで以上に利便性の高いプラットフォームの実現に向けていくつか戦略上の変更を施すこととなりました。 Japan 含めて10カ国以上で Medium の運営を続けてきましたが、本年よりすべてのオペレーションを本社であるサンフランシスコに集中させることにしました。そのため、これまで2年に渡って運営、キュレーションしてきた Medium Japan の各公式パブリケーションや公式 Twitter、公式 Facebook の運用を本日を持って止めることを決定しました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテンツ化することのなにか
経験のある人を身近におくこと