2023/3/11(土) に「Docs for Developers: An Engineer’s Field Guide to Technical Writing」の翻訳書籍である「ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング」が日本能率協会マネジメントセンター(JMAM)社より刊行されます。 今回、JMAM社に許可をいただいて書籍のあとがきを公開できることになりました！本記事では以下に、あとがきを先行掲載します。 あとがき 「ドキュメントを書いておけば良かった」 「ドキュメントは書いてあったけど、2年前に更新が止まっている」 開発の中でこう思ったことは、何らかの形でプロダクトやシステム開発に携われている方であれば、少なくとも一度はあるのではないでしょうか。 たとえば、「設計上の意思決定の経緯が残っておらず、加えたい変更の影響範囲が分からなくて困

社内のSlackや打ち合わせで、今年に入ってから「どうやって本を読んでいるんですか？」と聞かれる回数が複数ありました。これを機にブログポストにまとめておこうと思います。これまでに色々な読書方法＋メモを試してきましたが、2022年時点で行き着いた方法という感じです。 前提 電子書籍（私の場合はKindle1）が販売されている書籍の場合は、電子書籍で購入します。電子書籍が販売されていない場合は、物理書籍を購入します。 電子書籍を優先する理由は次の2つです。 あとでまとめるときに楽なため スマートフォンがあればどこでも読めるため 特に1つ目の「あとからまとめるときの楽さ」を重視しています。（理由は後述） 読み進め方 電子書籍と物理書籍で読み方が多少異なります。そこで、電子書籍と物理書籍とで共通する部分を最初に示して差分を説明します。 電子書籍、物理書籍共通 高速で読み流し どちらのタイプの書籍で

2022年昨今のEngineering Management(EM)界隈を見ていて、1つトレンドもしくは兆しがあるなぁ、と思っていることがあります。端的に言ってしまえば、EMを専門職種として切り出して、人（や組織）のマネジメントに専念させるパターンが出てきている、ということです。 もちろん、以前からこのような形態をとられている企業もあると思います。しかし、おそらくは専門性を高めている社員がキャリアラダーの1つとして、プレイングマネージャー的にマネジメントに携わるケースが多いのではないでしょうか。 プレイングマネージャーとして人のマネジメントに関わることの問題点は、2点あると考えています。ひとつは、プレイングしている内容（開発者であれば技術的なこと、デザイナーであればデザイン的なこと）と、人（と組織）に向き合う内容とのいずれにも注力できずに、どちらも中途半端な状態になるということです。結果と

はじめに 去年によく聴いてたPodcastの記事を書いており、本記事はその2021年度版。 去年までは、基本 Tech系ポッドキャストだったけど、今年は違うジャンルも聴いてた。以下では、少なくとも5-6エピソードは聴いたなってのものについて1-2行の感想をつつけて書いていく。(2-3エピソードだけ聴いたってのもあるけど、書き始めると多くなるので省略) ポッドキャスト列挙、コメントつけて 以降は順番適当に書いていく。 agileradio アジャイル開発に関するトピックを中心に語られるポッドキャスト。Scrurm Fest Sapporo などアジャイル全般のイベントを扱っている。 ココナッツテック 最近の技術記事をトピックとして、30分程度で雑談的に話しているポッドキャスト。全然拾えてない技術記事ネタもキャッチアップできるのがありがたい。 セキュリティのアレ 昨今のセキュリティ界隈のトピッ

はじめに 話題となっていた書籍である Engineers in VOYAGE を読み終えたので、その簡単な書評を書く。 書評 結論から述べると、本書籍で多く触れられるWeb技術に関わる技術者だけでなく、普段は上流工程から技術やプロジェクトマネジメントに携わっているエンタープライズな技術者にも本書籍を読んで欲しいとおもった。なぜかと言うと、通常であれば隠蔽されていて見えないエンジニアの考えや努力が、生々しく記載されており、エンタープライズ領域でも有用である知見が多く記載されているからだ。 レガシーシステムとの戦い たとえば、Voyage Marketing社におけるECナビでの、経済産業省の述べる2025年の崖への戦いの知見が1つの例だ。1200を超えるテーブルを持つオンプレシステムに対して、いかに泥臭く改善を進めたか、書籍で説明されている。具体的な取り組みとしては、オンプレからクラウドへの

はじめに コードコンプリートなどで有名な、スティーブ・マコネル氏のMore Effective Agile の和訳版を読んだので、その簡単な書評とメモを書く。 書評 非常に現実目線のアジャイル書籍。アジャイルの書籍は、アジャイルを当然のことながら推している人によって書かれている書籍が多いが、この書籍は完全に傾倒するのではなく、実際にソフトウェア開発に応用してみた経験から書かれている。そのため、読んでいると、「あぁ、たしかにこれあったな」「ここは悩むところだった」という点についてうなずきながら読める。 悩むところの一例をあげると、完了の定義(Definition of Done)ってどうすればいいんだろうってのがある。本書では、次のような具体例を載せているので、「このぐらいの粒度で決めていくのか」と現実に応用する場合に非常に参考になる。 - コードレビューを通過している - 静的コード解析を

はじめに 自分が fukabori.fm を配信しているのもあるけど、インプットソースとしてポッドキャストをよく聴いている。この記事では、聴いてるポッドキャストをサクサク紹介していきたいと思う。 基本はTech系ポッドキャスト。たまに、違ったのをちょいちょいぐらい。 実際に以下で書いてないポッドキャストもあるけど、少なくとも5エピソードは聴いたかな、ってものを紹介していく。 ポッドキャスト列挙、コメントつけて 以降は A-Z 順で、自分のPodcastクライアント(Podcast Addict)でSubscribeしているものを順番に。 ajito.fm suzukenさんが主宰しているポッドキャスト。VOYAGE CTOの makoga さんがよく登場する。技術的に濃いネタから、組織的なネタまで幅広い。 すごく印象に残っているepは ajitofm 29: Chiki Chiki Mon

はじめに コロナウィルス(COVID-19)でリモートワークの頻度が増加している人も多いと思う。そうなると、必然的にリモート会議の数も増える。ここで課題として上がってくるのが、リモート会議に対する姿勢、また練度だ。 リモートワークを多用して、リモート会議に慣れているチームもあれば、もともとオフサイト出社がメインでリモート会議に慣れていないチームもある。前者の慣れているチームであれば、スムースに適応できると思うが、後者の不慣れなメンバが多い部署・チームは、もっと効果的なやり方に気づいていない可能性もあると思う。(この場合、前者のメンバはストレスを溜めることにもつながる…。たとえば、一方的に音質の悪いリモート会議を想像して欲しい) そこで、この記事では自身の5-6年のリモート会議経験や、見聞きした情報から良いと思っているプラクティスを紹介していく。それによって、少しでもより効果的なリモート会議

WebRTCも誕生から5年以上経っており、Web上の記事も多く増えてきた。WebRTCには、大きくMedia ChannelとData Channelがあるが、後者のData Channelの日本語記事は非常に少ない。 日本語の記事の中では、@udonchan氏の記事が最も正確に書かれているが、2014年から時間が経ったこともあり、やや変更が加わっている部分(e.g. SCTPのPPIDは57まで定義されている点など)もある。その他の日本語記事は、やや記述が不正確なところもあるので、あまりオススメしない。 本記事では、WebRTC Data Channelについて知っておいた方が良いこと、および一次情報への参照をまとめておこうと思う。(本記事自体は、主観がそれなりに含まれるので、参考程度にしつつあとは一次情報や実機で確かめてもらえれば) W3C APIについて 仕様は以下の2つが役立つ。

本記事は、WebRTCをエンタープライズで利用したいと考えている人（例えば情シスの人）向けに、WebRTCの技術的な内容をいくつかまとめた記事。 エンタープライズ向けWebRTCの外堀が埋まってきている 社内向けなどの施策で、たとえば先進的な技術をつかったコスト削減を狙う担当者はそれなりにいると思う。WebRTCは、そこで目をつけられる技術の1つだ。（典型的なケースでは、既存のWebビデオ会議などのリプレース候補など） 新技術を導入するとなると、当然のことながら観点の1つとしてセキュリティに目がいく。すなわち、社内で「WebRTCは安全に使えるのだろうか？」と考えるということだ。たとえば、「音声・映像のトラフィックが暗号化されていたとしても、インターネットに出るのは怖い」、と偉い人が言うかもしれない。これに対する一定の回答はあるので、本記事前半で紹介する。 また、WebRTC登場初期時は、

はじめに WebRTCの通信形態は大きく分けて、暗号化を解く/メディアを解釈するサーバを介するもの と 介さないもの、の2種類がある。 暗号化を解く or メディアを解釈する サーバを介さないもの P2P TURN経由 暗号化を解く or メディアを解釈する サーバを介するもの MCU経由★ SFU経由★ (VoIP-WebRTC Gatewayなどもあるが、ここでは取り上げない) どれが必要になるかは、WebRTCを利用するアプリケーションのユースケースに依存するので、一概に何が1番良いというものはない。 本記事では、上記のうち、★をつけているメディアサーバ(SFU/MCU)の現状(2016年)について記載する。WebRTCを使う上で、特にMCUやSFUに興味がある方には参考になれば幸いだ。 もし、記載で誤っている点などがあれば @iwashi86 までメンション/DMをいただきたい。

はじめに WebRTCは様々なブラウザでサポートが進んでいる。これらの対応状況について世の中に多くの情報があるが、アップデートされていない情報も多いため、最新の情報を追うのはなかなか骨が折れる。そこで、本記事では2016年3末時点での対応状況をまとめていく。 本記事を読むと得られるもの・得られないもの 得られるもの 2016年3末時点での各ブラウザにおけるWebRTCの対応状況 得られないもの ソースコードレベルの実装詳細 対象読者 WebRTCに関わっているエンジニア、WebRTCの動向に興味がある人 WebRTCを多少なりとも知っている人 では本題に進む。 Google Chrome WebRTCの提唱をはじめたGoogleだけあって、WebRTCの黎明期から様々な機能を提供している。現在も活発に開発が進んでおり、Chrome/FirefoxにおけるWebRTCのマイルストーンの記事に

はじめに 以前の記事にて、SlackにおけるWebRTCの利用についての解析結果を掲載した。 前回の記事は、Slackが1:1の通話において、どのようにしてWebRTCを利用しているかという点にフォーカスしており、 SlackはTURNを強制的に利用し、Janus経由でエンドツーエンドの音声接続を提供していることを明らかにした。 本記事の概要 本記事では、引き続きSlackの音声通話機能についての解析を述べる。 本記事の主なスコープは、Slack音声通話機能の多人数会議(マルチパーティコール)の解析である。 本記事を全て読むと、Slackにおける多人数会議のアーキテクチャ、およびWebRTCの利用技術を理解できる。 対象読者 なお、前回同様にWebRTCの基礎知識を持った人を想定して記事を書くので、基礎的な知識の解説は実施しない。必要な場合は、前回同様にHTML5 Expert.jpの解説

はじめに 2016/3/3より、Slackに音声通話機能が搭載された。 試しに使ってみたSlackユーザもそれなりにいると思う。 Slack音声通話機能の対応クライアントは、現時点では限定的だ。Slackの設定画面の一文を引用すると Currently on Mac and Windows desktop apps and in Chrome; coming soon to mobile! の通りで、Chromeまたはデスクトップのネイティブアプリとなる。 音声機能が実装されていてこの種類の対応状況なら、もちろん利用技術はWebRTCと考えるのが素直だ。(しかもWebRTCベースのスタートアップであるScreenHeroを買収していることもあり) ここで、最も気になるのは内部でWebRTCをどのように利用しているか、という点だ。 すでに、WebRTCエンジニア御用達のWebRTCHacks

1. はじめに WebRTCの動向を追いかけている人であれば、ORTCについて耳にしたことがあると思う。 だが、ORTCの登場背景等について、記載した日本語記事があまりなかったので、 私の知る範囲で、以下にまとめておこうと思う。 (ORTCを当初から追いかけているわけではないので、間違っていたら@iwashi86までご指摘ください。非常に歓迎です！) 1.1. 本記事の対象者 WebRTCについてある程度知識がある人向け SDP何それ？な人は、HTML5Rocksあたりを読んでから、以降を読むと分かりやすいと思う 2. なぜORTCが登場したのか？ 2.1. WebRTC 1.0の世界 既存のWebRTC(まだ、仕様として固まっていないが、以降では分かりやすくWebRTC1.0と呼ぶ)において、 シグナリングプロトコルは規定されていない。これは次のJSEPのドラフトからも確認できる。