サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
daiksy.hatenablog.jp
発端 今年の頭に、講演依頼をもらった。 専門学校で、学生さん相手に業界動向やこれからのために何を学ぶべきか、といった話をしてほしいとのこと。 当然、快諾したのだが、持ち時間を尋ねたところ「90分」だという。 人前で話す経験、というのは、おそらく豊富な方だと思う。5分間のプレゼンであるライトニングトークをはじめとして、カンファレンスで40分ほどの枠をもらって喋ったこともあるし、パネルディスカッション形式の登壇も3回ほど経験がある。 だいたい年に5, 6回は、なにがしかのIT系のイベントで登壇していると思う。 が、それでも90分という持ち時間を聞いてぞっとした。ライトニングトーク18回分。カンファレンス約2回分の時間をしゃべり続けなければならないのである。 90分という持ち時間を聞いて、専門学校で開催される講演会であるから、学校の授業1コマ分の時間に相当するのだろうと気づいた。これまでだらだら
"Agile Japan 2017 京都サテライト", "KANJAVA PARTY 2017" で、『リモートチームの道具箱』というタイトルのセッションでお話をさせていただきました。 connpass.com kanjava.connpass.com リモートワークに取り組んでいるチームで仕事をして3年目になりますが、リモートワークは難しいなーというのを常々思っています。 世の中はどちらかというと、リモートワークという素晴らしい取り組みをどんどん推進しようという流れに向いています。リモートワークの推進には僕も賛同するのですが、一方で、「難しさ」の部分があまりクローズアップされません。このまま、導入だけが先行してしまうと、結局「やっぱりリモートワークなんて止めたほうがいいのでは」となってしまう恐れがあって、それを懸念しています。 リモートワークは上手に使いこなせば、柔軟な働き方が促進される
今年は、はてなインターンの実行委員長という仕事をしている。 hatenacorp.jp 8月15日から9月9日までのインターンを終え、今年の教科書も公開ができた。 developer.hatenastaff.com まだもう少し委員長としての仕事が残っているが、ここで一度今年の振り返りをしようということで、実施した。 振り返り手法としてのKPTとYWT ぼくは普段、Mackerel というプロダクトの開発にかかわっている。Mackerelでは開発手法にスクラムを採用していて、2週間のスプリントごとに毎回振り返りを行っている。ここで使っているのはKPTという手法だ。 KPTはKeep, Problem, Tryの略で、2週間を振り返って、その期間でKeepしておくべき良かったこと、Problemとして議論すべき問題となること、そしてそれらを受けて次のスプリントですべきTryを決める。 K,
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
パスワードつきzipの添付メールと鍵配送問題 ボブのもとに届けられたアリスからのメール。このメールにはzipファイルが添付されていて解凍にパスワードが必要だ。このパスワードは、添付ファイルの後、アリスから別のメールに記載されて送られてくる。この手順により、最初のメールをイブが盗聴したとしても、イブはパスワードを知らないので添付ファイルを解凍することはできない。 一見すると安全に情報をやりとりしているようにみえるこの形式は、実はまったく安全ではない。ファイルが添付されている最初のメールが盗聴できるのであれば、当然イブは次に送られるパスワードが記載されたメールも盗聴できるからだ。 zipに施されるパスワードの強度はとりあえず気にしないこととして、この情報のやりとりは暗号におけるとても重要な問題をないがしろにしている。それは鍵配送問題と呼ばれる。 暗号の中には、かなり早い段階で「絶対に解読不可能
Nexus, Scrum@Scale, LeSS, SAFeなど、スクラムチームをスケーリングする手法はたくさん存在する。 しかし、アジャイルコーチなどに、「スクラムをスケールするにはどうすればいいですか?」と聞くと「そもそもスケールをするな」と言われることもある。ぼくも基本的にはこれに同意する。 コンパクトな職能横断型のチームで、短いサイクルで高速に、安定したペースで開発をする。これをずっと続けることができるのならばそれが一番良い。 なのになぜ、人々はスクラムチームをスケールしたくなるのか。なぜこんなにたくさんのスケーリング手法が存在するのだろうか? そういうことを考えてみた。 最初から人がたくさん必要な場合 そもそも最初からスケールされたチームでやりたいパターンがある。大規模な開発などはそうだろう。 小さくローンチして、インクリメンタルにユーザーフィードバックを受けながら開発できれば理
「駅すぱあと」を支える開発 〜9262の可能性を繋げ!〜(DevLOVE関西Ver) というイベントが開催された。 ぼくも会場係としてスタッフ参加。 「駅すぱあと」の歴史から技術、開発のマネジメント手法に至るまで、幅広い話が聞ける良いイベントだった。 いろいろな話が聞けたのだけれど、僕は特に佐藤さんの「『駅すぱあと』新しい開発基盤の研究」がおもしろかった。 まだ開発途中で、実際の駅すぱあとには組み込まれていないそうなのだけれど、佐藤さんは「駅すぱあと」の運賃計算のDSLを研究・開発しているという。 曰く、鉄道の運賃計算は泥沼である。単純に距離や、目的地までの駅数などで運賃が算出できればよいが、鉄道の運賃計算には無数の特例がある。 下記リンク先に、JRの運賃の特例計算が列挙されているので、ちょっと見ていただきたい。 ……お分かりいただけただろうか。現在の「駅すぱあと」では、これらの特例がすべ
これは Chatwork Advent Calendar 2日目のエントリです。 また、このエントリの公開日翌日に開催される"だいくしーのスクラムBar #1" で取り扱うテーマについての詳細な解説記事も兼ねています。 chatwork.connpass.com スクラムマスターって何をする人なの? 本項ではこれについて少し考えてみたいと思います。また、ぼく自身が普段どういうことを考えながらスクラムイベントや、その他の仕事をしているか、なども書いてみようと思います。 スクラムマスターは、ソフトウェア開発に関する他の職種と比べても、具体的な職務内容がわかりづらい役割なのかな、と思います。少し乱暴な言い方をしてしまうと、デザイナーがいなければデザインはできないし、プログラマーがいなければアプリケーションコードを書くのはとても困難です。しかし、スクラムマスターがいなくても別に開発はできます。 そ
新しい会社に入社して1ヶ月半経った。 今回はエンジニアリングマネージャとしてのポジションでの採用で、過去4回の転職はすべてアプリケーションエンジニアとしての採用だったので、その差分に若干戸惑っている。時勢的にフルリモートワークというのも大きい...。 "成果"が見えにくい仕事に対する実感をどのように得るか まずひとつは、"成果"に対する手応えが異なること。エンジニア採用であれば、「入社最速RTA!!」などと言いながら、とりあえず小さなタスクを拾って入社後1週間以内くらいに自分の出した最初のプルリクエストがマージされれば、「最初のステップは超えた」という実感を得ることができた。 マネージメント職では、そのようなわかりやすい成果が見えづらい。そもそも、自分の打ち手が効果を発揮するのが翌月、みたいなリードタイムも珍しくないので、自分はちゃんと給料分働けているのだろうか、とまぁまぁ不安になる。そこ
DevLOVEアドベントカレンダー 越境 12日目の記事です。 今年のテーマは越境。ということで、ソフトウェアエンジニアの現場における「越境」について考えてみようかと思います。 いまいち納得のいかない片方向な越境 「エンジニアも営業的な目線を持ってセールスに貢献すべきだ!」 「エンジニアも自ら企画を立案し、サービスの売上げアップに貢献すべきだ!」 多くのエンジニアが、このような物言いを苦々しい気分で聞いた経験があるのではないでしょうか。 営業職の偉い人は、エンジニアもセールスを学び、営業の視点を持て、と言う。 企画職の偉い人は、エンジニアも企画を学び、サービスを立案しろ、と言う。 ところがエンジニアリングを学ぶ営業や企画の人は少ないし、エンジニアリングを学ばない営業職や企画職が、それを理由に咎められている様子など一度も目にしたことはありません。 なぜエンジニアばかりが開発以外のスキルまで求
少し古い本だが、「そういえばみずほ銀行の開発プロジェクトってどうなってるんだろう」と思いながら2chの某スレを読んでいて、この本の話題が出てきたのでKindle版を読んでみた。 システム障害はなぜ二度起きたか みずほ、12年の教訓 作者: 日経コンピュータ出版社/メーカー: 日経BP社発売日: 2011/07/28メディア: 単行本購入: 2人 クリック: 466回この商品を含むブログ (15件) を見る 本書の構成は大きく、 2011年3月の東日本大震災の義援金処理で発生したシステム障害の解説。 2002年の合併直後の新システム稼働時の大規模障害の解説。 東証や東京消防庁などの他の大規模システム障害事例の概観 システム障害を発生させないための提言 の4つにわけられる。 本書の主張は一貫して、ITはいまや企業の根幹を担う中枢であるので、IT部門に丸投げするのではなく経営陣が積極的にITにか
photo by E R I mollifier.hatenablog.com ITコミュニティ界隈で定期的に話題になるこの問題。 定期的に出る、ということは、無断欠席は永遠になくならないと思ってよさそうだ。 そもそも他人の行動を制御するのは不可能なので、制御可能な自分たちの運営を工夫して解決し、関係者全員が幸せになれる方法を考えよう。 有料とかブラックリストとかほんとに有効? この話題でいつも意見として出るのが、前金制キャンセル不可の有料制にしてはどうか、とか、無断欠席者のリストを共有する、とかいった話。 ただ、ブラックリスト作ってもリストに載ってない無断キャンセルなんて無限に存在し続ける。 有料制も、会場によっては営利目的とみなされて使用料がそれによって跳ね上がったりする。 そもそも、無断キャンセルによって補欠登録になってしまっていた人の参加の機会が奪われるのを何とかしたい、というのが
昨日、以下のツイートをしたところそこそこ反響があった。 自分は今、コード書かずにマネジメントしかしてなくて、そんなポジションの人にそれほど価値ないでしょ、とか思ってしまうけど、こういうポジションの人がいないチームの話とか聞くと、やっぱりいたほうがいいんじゃないか、と思うし、ほとぼりが冷めるとまた自分は無価値のように思えてしまう。— だいくしー (@daiksy) February 18, 2019 エンジニアマネージャってなんか実績を示しづらいので、世の中の数多のマネージャ職に埋もれて、自分にスポットが当たりづらい、結果、キャリアに不安が拭えない、みたいなとこないです?— だいくしー (@daiksy) February 18, 2019 そこで、もう少し悩みを掘り下げてみる。 通勤電車内でiPhoneのメモに雑に書き並べただけなので、まとまりはない。 モダンなデベロッパー文化をチーム内で
2024年5月1日から、株式会社はてなで組織・基盤開発本部のエンジニアリングマネージャとして働き始めました。 2014年から、2021年まで社員だった時代があるため、いわゆる出戻りという形になります。 一度退職した会社に再び入社する、というのは、通常の転職活動と違った悩みなどもあり、自分も今回の転職に際して「アルムナイ採用」などのキーワードでいくつか参考にした記事がありました。 最近は身近な事例も耳にするとはいえ、まだまだ通常の転職と比べてアルムナイ採用は例が少ない気がするので、せっかくなので体験記を書いておこうと思います。 基本的には自分の個別の事例ですので、世間一般のアルムナイ採用の実態とは異なる箇所もあることをご承知おきください。 戻ろうと思ったきっかけ もともと最初にはてなを辞めた理由が、自分の新しいキャリアを志したチャレンジという側面が強かったため、辞めた直後からなんとなく「機会
仕事ではじめる機械学習 作者:有賀 康顕,中山 心太,西林 孝発売日: 2018/01/16メディア: 単行本(ソフトカバー) ちょうど仕事で機械学習を用いた機能開発のプロジェクトの進行管理をしていて、目次をみたところ良さそうに思ったので読んでみました。 オライリーのEbookでPDF版を買ったのですが、まもなく紙版も出るようです。 まえがきには、CourseraのMachine Learningコースを受講するか、『ゼロからつくるディープラーニング』を読んでおくと良い、とありました。ぼくは直前に『ゼロからつくるディープラーニング』を読んだあとでしたが、いきなり1冊目に読んでも問題ないのではと思います。難しい数式などはあまり出てきません。とはいえ、ある程度の機械学習についての知識を持っているのが前提になっているので、少なくとも機械学習を取り扱う際によく出てくる用語の意味などはある程度知って
およそ一月前くらいに、同僚の id:hitode909 さんとモブプログラミングをやってみようということになった。 hitode909さんとはチームは別なのだけれど、最近週一で別チームに行ってペアプロなどをしつつ、知見の横展開や課題の発見などをやろうという試みをされていて、ではせっかくなので、と自分たちのチームに招いて軽くお試しでモブプロをやってみた。 blog.sushi.money モブプログラミングとは、ペアプログラミングをチーム全員にまで拡大したようなもので、1つのプログラムをプロダクトオーナーも交えたチーム全員で取り組む形式である。 セミナールームにエンジニア8人ほどで集まって、大画面ディスプレイにソースコードを共有しつつ、「コードを書く人(ドライバ)」と「それ以外の人(ナビゲータ)」とで1つの課題に取り組んでいく。 実装をチーム全員で取り組むため、知見が共有できたり、設計上の課
今期の目標設定を決めましょう、というときに、よく「〇〇の機能を期日どおりにリリースする」と書きたくなりがち。ぼくも以前はよく書いていた。 マネージャの仕事をそれなりの期間やっていくうちに、この考え方はまったく意味がないな、と思うようになった。 リリース日を遵守する、というのは、プロダクトのビジネス価値を生み出す要素の一つにすぎない。期初にたてた予算が、この日にリリースされることを前提に計画されている、とか、競合製品よりはやく価値を出すためにはどうしてもこの時期にリリースしたい、といった感じだろう。 なのでリリース日を目標にするのはなんの問題もない。当然そのように振る舞うべきだ。ただ、これが評価に結びつくととたんに破滅する。 リリース日遵守を基準点。遅延すると減点、前倒しで加点。こんなふうにしてしまうと最悪。 開発を進めるうちに、どうしてもリリース日に間に合いそうにない。スコープを絞って間に
11月1日付で、株式会社はてなに入社しました。 はてなに入社するということで、なるべく自社サービスを利用していこうと思い、これを機にブログもはてなブログに移行しようと思います。引き続きよろしくお願いします。 はてなでは、Mackerelの開発に携わる事になりました。前職に引き続きScalaが使われているプロダクトで、これまでの経験を活かしていきたいと思っています。 今日は入社初日でめちゃくちゃ緊張しましたが、チームメンバーの何人かとは入社前からお酒を飲んだり、勉強会などでご一緒させてもらったりしていたので、おかげで比較的スムーズにジョインできたかな、と思います。 はてなは会社としても、新しい社長の元でおもしろいフェーズにあると思っているので、良い化学反応を起こせるように頑張ろうと思います。
以前、アジャイルラジオというpodcast番組に出演させていただいた(バックナンバーはこちら)。この番組のパーソナリティの土屋さんのご紹介で、大阪情報コンピュータ専門学校というところで学生向けの講演をさせてもらう機会を得た。 1コマ90分。講演自体は約60分ということで、ここまで長丁場の登壇は初めてのこと。準備段階ではいろいろと苦労もあったがとても良い経験をすることができた。 IT業界の楽しさを伝えたかった インターネットを見ると、IT業界については否定的な意見がとても目についてしまう。長時間勤務、納期に追われる、デスマーチなどなど。こういったマイナスの意見というのは、共感も得やすいし、そもそも自虐ネタというのはネタとしてもおもしろい、ということもあって、悲しいことにこういった言説の方がインターネットでは拡散しやすい。 ただ、ネガティブな意見の方が目立ってしまう、というだけで、業界をポジテ
リモートワークは難しい。 在宅を基本とするリモートワークは働き方の多様性という意味で非常に有効だ。 すべての勤務が在宅でなくても、家族の介護や、自身の都合などで任意の日に在宅で仕事ができるだけでも、大きなメリットがある。 働きたいと思っている人が、オフィスに縛られること無く、家庭や個人の事情と両立しながら働くことができるし、チームとしてもメンバーが働けなくなることで生じるリスクを少なからず軽減することができる。 とはいえ、リモートワークは難しいのである。 リモートワークに取り組んでいたいくつかの企業が、その取り組みを断念した、というニュースもちらほら耳にするようになった。 なにがそんなに難しいのか。その要因の大きな部分に、コミュニケーションの難しさがあると思われる。 リモートワークだと、チャットやメールなどのテキストでのコミュニケーションが主流となる。ここに大きな難しさがある。 「毛づくろ
仕事のひとつとして、技術組織におけるタレントマネジメントに取り組んでおり、勉強したことを簡単にまとめておく。 タレントマネジメントと一口に言っても、その類型にはいろいろとあり、マッキンゼーの"War for Talent"が書籍も出版されていてよく知られている。これは、簡単に説明すると、社員を成果の発揮度でA, B, Cに位置づけ、組織をAの人材で充足し、Cはなるべく数を減らす、という戦略をとる。選別の要素の強いマネジメント手法であり、あまり日本型の人事管理には馴染まない。そもそも、組織のすべてをA人材で満たす必要はあるのか、A人材のみで充足するためのコストに見合うのか、といった議論もある。 マッキンゼーの"War for Talent"は選別的なアプローチであり、逆に人材すべてをタレントとみなすマネジメントは、包摂アプローチと分類される。 他にもタレントマネジメントの類型はいろいろとある
※ベストセラーになった書籍『嫌われる勇気』からタイトルをもじっただけで、その書籍とこのエントリの内容に関連はありません このエントリは、はてなディレクターアドベントカレンダー16日目の記事です。 advent.hatenablog.com サブディレクターという仕事 ぼくはMackerel というプロダクトの開発チームに所属しています。これまで、2年弱アプリケーションエンジニアとして仕事をしてきましたが、今年からチームのサブディレクターに就任しました。 サブディレクターということで、厳密にはディレクターではありません。チームのメインディレクションは、ディレクターのid:Songmuに権限があります。 Mackerelチームは、はてなの中でもかなりの大所帯で、エンジニア、デザイナ、セールス、マーケティングと多用な職種の人が在籍しています。ロケーションも東京と京都、愛知(自宅からのリモート勤務
入社して1週間経ったまとめ。 入社エントリがホッテントリに入った 株式会社はてなに入社しましたというエントリを入社翌日にアップしたところ、ホッテントリ入りしてました。 身内に向けたご挨拶、というノリで書いたエントリにもかかわらず何やら注目を集めてしまい、申し訳無い気持ちになりつつも、いろんな意味で注目を集める会社に入ったのだな、と気が引き締まる感じでした。 入社後のオリエンテーションが丁寧 入社して最初は新しい会社の文化やルールなど、覚えることがたくさんありますが、それらの案内がすごく丁寧でした。 また、各種情報ははてなグループでドキュメントとして共有されているので、わからないことがあれば検索するとだいたい見つかるようになっています。 後述しますが、実際の開発作業に関してもスムーズにチームに入れるようにとても丁寧に配慮されていて、入社してすぐに混乱もなくプロダクト開発に着手させてもらってい
自分がまさに中間管理職ど真ん中なので、中間管理職の仕事を可能な限り自分なりに言語化してみようと思い、ざっくばらんに思ったことを書いていく。 今回は、情報伝達について。 組織がコンパクトであれば、中間管理職など必要はない。トップの意思がダイレクトに末端までスムーズに伝わるからだ。 組織が大きくなるにつれ、情報の伝達はスムーズにいかなくなる。 帝人の元会長である安居祥策氏が、日本経済新聞に寄稿した記事で記した「√の法則」というものがある。 100人の社員に物事を理解してもらおうと思えば、√100=10 として10回同じ説明をする必要がある。 10,000人の社員が相手になれば、100回になる。 多くの人に自分の考えを理解してもらうためには、このくらい同じ説明を何度も繰り返す必要があるということだ。全社員が集まる集会で、1回説明すれば明日からすべての社員がそのように動く、ということはない。 これ
scala.connpass.com Scala福岡で登壇機会をいただき、お話してきました。 ぼくたちが運用・開発しているMackerel というプロダクトで、2度実施したPlay Frameworkのバージョンアップで得た知見を元に、アプリケーションフレームワークの更新をどうすれば安全にやれるだろうか、という観点でのお話でした。 あえて技術的な側面にはあまりフォーカスせずに、プロジェクトマネジメントの視座からお話することで、ScalaやPlayにかぎらず参考になるような発表になればいいな、ということを意識しました。他の言語の世界をあまり詳しく知らないので、意図通りの発表になったかどうかはわかりませんが…。 Twitterを見たところ、おおむね好評なようでよかったです。 サービスに機能追加しながら運用しつつ、フレームワークやライブラリのバージョンアップについて行くのまじで大変なので、このセ
いよいよ RSGT2022が迫ってきましたね! これはRSGT2022を待ちわびるアドベントカレンダーの記事です。 qiita.com RSGT 2022では、1月5日の14時からRoomCにて「Scrum@Scaleの理論と実装 - 組織をリファクタリングしながらスケールする」というお話をさせていただきます。 Scrum@Scaleを採用して運用しているチームに今年になって参画し、そこでの取り組みや「Scrum@Scaleってどういうものなの?」といったお話をさせてもらう予定です。 スクラムマスターとしての7ヶ月 さて、ぼくは2021年5月に今の会社にエンジニアリングマネージャーとして入社しました。現在のミッションは、Scrum@Scaleで運用されている部門全体を統括して、その開発プロセスを整えていくのが仕事です。他にも、社内にスクラムを横展開したり、採用・育成などエンジニアリングマネ
はてなにエンジニアリングマネージャとして入社して2ヶ月と少し経ちました。 マネージャとしての「最初の100日」もいよいよ終盤です。 note.com 入社して最初の取り組みとして、およそ100人のエンジニア全員との1on1を実施しました。 なぜ全員とやろうと思ったか イギリスの人類学者であるロビン・ダンバーによって提唱された「ダンバー数」というものがあります。 これは、人間が安定的な社会関係を維持することができる人数の認知的な上限について提案された数字です。大雑把に説明すると、人間が相互に認識しあって社会関係を築ける人数はおよそ150人程度、というものです。 要するに1つの組織でお互いに顔見知りの状態で活動ができる集団の人数上限が150人前後であるということです。 このエントリを書いている時点で、はてなのエンジニアはおよそ100人ほどいます。つまり、はてなのエンジニア組織は、まだダンバー数
今の会社に入社してから10営業日目を迎えました。 前回の転職のときにも書きましたが、マネージャーとしての転職は、他の職種とは違った難しさがあるのを実感する日々です。 マネージャーの仕事は、社内の人々からさまざまな期待をされる役割ですが、リモートワークということもあっていまいち何をしているのかみんなには伝わりづらい仕事です。そこで、毎日日報を書いたり、社内チャットの分報チャンネルにこまめに雑談も含めて吐き出したり、グループウェアに文章を書いたりしています。 このような入社直後のマネージャーの様子を、社内向けにグループウェアに投稿した文章をアレンジして書いておこうと思います。世の中の新任マネージャーの参考に少しでもなりますように。 どういう役割として入社したか はてなでは、組織・基盤開発本部エンジニアリングマネージャーという役割をもって入社しました。 はてなは、はてなブログやMackerelな
ぼくたちの開発チームは、現在1スプリント2週間のスクラムチームとして活動している。スプリントの最後には振り返りを実施しているが、そこではおなじみのKPTを採用している。 参考: 情報マネジメント用語辞典:KPT(けいぴーてぃー) - ITmedia エンタープライズ チームは複数拠点にメンバーが分散しているリモートチームで、振り返り会はテレビ会議を使って行われるので、KPTのやり方にもそれなりの工夫が必要となる。 Googleスプレッドシートを使ったKPT 通常のKPTでは、大きな模造紙やホワイトボードに、Keep、Problem、Tryの領域を定め、そこにそれぞれの内容について書かれた付箋紙を貼っていく。他の人が書いた付箋の内容が呼び水となって、他の人が別の課題を思いついたりもするので、全員が揃って付箋を次々に貼っていく、というスタイルが良いとされている。 メンバーが複数拠点にまたがって
次のページ
このページを最初にブックマークしてみませんか?
『だいくしー(@daiksy)のはてなブログ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く