#june29jp

このサイトを https 対応しました

2017-12-10

このブログを Hugo で再構築しましたに書いた通り、これ以降 june29.jp は Hugo でソースコードを管理して成果物を GitHub Pages に載せて配信しています。見ての通りの独自ドメイン運用です。

この構成だと下記の記事にて説明されているような手順で https に対応できます。

CloudflareでブログをHTTPS化 | To Be Decided

ドメインが絡む作業なので設定が反映されるまでの待ち時間はそれなりにあるものの、お手軽に対応できちゃってお得だなぁと思いました。

結局のところ https 移行のいちばんのハードルは「これまでに蓄積してきたブックマークや Like やスターなどがゼロになっちゃう」のを受け入れにくい心理のところにありました。まあいいや、ということで思い切ることにしたので、初心に返ってがんばっていきましょう。

このエントリーをはてなブックマークに追加

書籍「サピエンス全史」の上巻を読んだ

2017-12-06

サピエンス全史(上) 文明の構造と人類の幸福 サピエンス全史 文明の構造と人類の幸福 | ユヴァル・ノア・ハラリ, 柴田裕之 | 歴史学 | Kindleストア | Amazon

先日の「アメトーーク!」の読書芸人の回で Mr.ビーンbot @kazlaser さんが紹介していて、おもしろそうだったので電子書籍版を買って読んでみました。だいぶおもしろかったのでテンション高めに感想を書きます。

社会に対する興味

ガラスの10代後半、情報工学を専攻しつつもアルバイトは接客業ばかり選んでいたし、イマイチ「情報工学と自身の人生」の接点を見つけられずにいたこと。それが20歳を過ぎて、世間が「Web 2.0」と呼ばれる潮流に沸き、ウェブが一気にソーシャル化していった時期にようやく自分がプログラミングをする意義に気付いて、のめりこんでいったこと。

ぼくはきっと「多数の人々のインタラクションから成る、社会」というものに強い関心があります。大学〜大学院時代に「複雑系」という領域に惹かれたのも、思い返してみるとすごく自然なことに感じられます。

小中学生のころのぼくにとっては、社会の授業ってのは単なる暗記科目だったんだよなあ。おもしろさに気付けていませんでした。それが今では、社会と呼ばれるものやそこで起こるアレコレを観察し、楽しむようになりました。だから、この本に向かって手が伸びたのも、なるほどなあという感じです。

常識とか伝統とか

書籍の最初の方に載っている歴史年表は「135億年前」から始まっています。紀元前の話もたくさん出てきて、数千年から数万年のスケールで物語が語られます。

そうすると、たかだか直近数十年のログに根差した「常識」だとか「伝統」だとか、あまり真面目に向き合うものでもないのかな、という気持ちになれました。ときに、自分の感覚の正当性を主張するための後ろ盾として、あるいは、自分が思考を放棄したいがために「常識」「伝統」といった便利フレーズがふりかざされるときがあって、その度にぼくはウームと唸るはめになるのでした。だけどもう大丈夫。大袈裟に気に病むことはなさそう。

仮に「常識」「伝統」といった類のものがあったとしても、時の流れとともに変化していくもの。変化を恐れずに、そのときそのときでちゃんと自分の頭を使って考えていけばよさそうです。

農業革命 (第5章〜)

ぼくはなんとなく漠然と、人類の生活レベルってのは右肩上がりにいい感じになってきたものだと思っていました。だけどそうではないらしい。

だが、一万年ほど前にすべてが一変した。それは、いくつかの動植物種の生命を操作することに、サピエンスがほぼすべての時間と労力を傾け始めたときだった。人間は日の出から日の入りまで、種を蒔き、作物に水をやり、雑草を抜き、青々とした草地にヒツジを連れていった。こうして働けば、より多くの果物や穀物、肉が手に入るだろうと考えてのことだ。これは人間の暮らし方における革命、すなわち農業革命だった。

(Kindle の位置No.1478-1481)

ほうほう。

かつて学者たちは、農業革命は人類にとって大躍進だったと宣言していた。彼らは、人類の頭脳の力を原動力とする、次のような進歩の物語を語った。進化により、しだいに知能の高い人々が生み出された。そしてとうとう、人々はとても利口になり、自然の秘密を解読できたので、ヒツジを飼い慣らし、小麦を栽培することができた。そして、そうできるようになるとたちまち、彼らは身にこたえ、危険で、簡素なことの多い狩猟採集民の生活をいそいそと捨てて腰を落ち着け、農耕民の愉快で満ち足りた暮らしを楽しんだ。

だが、この物語は夢想にすぎない。人々が時間とともに知能を高めたという証拠は皆無だ。狩猟採集民は農業革命のはるか以前に、自然の秘密を知っていた。なぜなら、自分たちが狩る動物や採集する植物についての深い知識に生存がかかっていたからだ。農業革命は、安楽に暮らせる新しい時代の到来を告げるにはほど遠く、農耕民は狩猟採集民よりも一般に困難で、満足度の低い生活を余儀なくされた。狩猟採集民は、もっと刺激的で多様な時間を送り、飢えや病気の危険が小さかった。人類は農業革命によって、手に入る食糧の総量をたしかに増やすことはできたが、食糧の増加は、より良い食生活や、より長い余暇には結びつかなかった。むしろ、人口爆発と飽食のエリート層の誕生につながった。

平均的な農耕民は、平均的な狩猟採集民よりも苦労して働いたのに、見返りに得られる食べ物は劣っていた。農業革命は、史上最大の詐欺だったのだ。

では、それは誰の責任だったのか? 王のせいでもなければ、聖職者や商人のせいでもない。犯人は、小麦、稲、ジャガイモなどの、一握りの植物種だった。ホモ・サピエンスがそれらを栽培化したのではなく、逆にホモ・サピエンスがそれらに家畜化されたのだ。

(Kindle の位置No.1507-1523)

ぼくたちは動植物に家畜化されていたんですね…!

雑にまとめると、農業革命によって「手に入る食糧の総量を増やすことに成功した」し、それから「種の個体数も増えた」けれど、各個人の生活が楽になったかというと、ぜんぜんそんなことはなかったと。しかも、こういった狩猟採集スタイルから農耕スタイルへの変化は何世代にも渡って徐々に進行していったので、渦中にいた当人たちは「生活が大変になっている」という自覚も持てなかったと。

これを2017年を生きるビジネス戦士たちの日常にあてはめてみると、売上も伸びて従業員数も増えているけれど満足度はむしろ下がっている…といった状況を思い浮かべるでしょうか。あるいは「小麦」を「ソフトウェア」に置換して読んでみても、読み取れるものがありそうです。ふーむ。

想像上のヒエラルキーと差別 (第8章〜)

人類史上のいたるところにヒエラルキーや差別は観測され、またそこに生物学的必然性はない、というお話。

あらゆる社会は想像上のヒエラルキーに基づいているが、必ずしも同じヒエラルキーに基づいているわけではない。その違いは何がもたらすのか? なぜインドの伝統的な社会はカーストによって人々を分類し、オスマン帝国の社会は宗教によって分類し、アメリカの社会は人種によって分類するのか? ほとんどの場合、ヒエラルキーは偶然の歴史的事情に端を発し、さまざまな集団の既得権がそのヒエラルキーに基づいて発達するのに足並みを揃えて、何世代もの間に洗練され、不滅のものとなる。

(Kindle の位置No.2546-2550)

けっこうウッとなる内容が多かったです…。関連しそうな話としては、以前に転校生マインドというエッセイを書いたこともありました。「高校デビュー」「大学デビュー」なんて言葉たちが市民権を得ているところを見ても、いったん定着してしまったポジションというのは「リセット」しないとなかなか覆らないということかと思います。

あとはトランプゲームの「大富豪」のことも思い出しました。富めるものは次のゲームでも勝ちやすくなっていて、しばらくは勝者と敗者が固定されますよね。しかも現実には「スペ3」のようなあえて一発逆転が起きやすくなるようなメカニズムは組み込まれていないのでした。このゲームを「大富豪」とか「大貧民」とか呼ぶ無邪気な残酷さよ〜。

2017年に日本で生活しているぼくは差別的な考えは持ちたくないとは思っていますが、生まれるのが100年前だったら、きっと無自覚に女性を低く見てしまっていたのだと想像します。奴隷が当たり前に存在する時代と場所で育っていたら、きっと考えも染まっていたと想像します。

そうやって考えていくと怖いのは、老後の自分のことですね。最近も、ぼくの2倍くらいの期間を生きている男性が、現在のぼくの感覚では「なんでそんな差別的な発言をわざわざするんだ」としか思えないことを言って、批判を受けて頭を下げていました。ぼくもインプットを絶やさずに価値観をアップデートしていかないと、30年後くらいになんの気なしに放った一言で大変なことになるかもしれません。もしそれが、2017年に言う分にはまったく問題にならない一言だったとしても、です。

最強の征服者、貨幣 (第10章〜)

ついにおでまし、史上最強の宗教との呼び声も高い「貨幣」の登場。

タカラガイの貝殻もドルも私たちが共有する想像の中でしか価値を持っていない。その価値は、貝殻や紙の化学構造や色、形には本来備わっていない。つまり、貨幣は物質的現実ではなく、心理的概念なのだ。

(Kindle の位置No.3246-3248)

ズバーンと言い切ってくれて、実に気分がいいですね〜。そう、貨幣は心理的概念。

いや本当に、2017年にこの書籍の「貨幣」のところを読んでいて、仮想通貨というか暗号通貨のことを思い出すなという方が無理でしょう。人類の社会に貨幣はどのように定着したか、という過去の話として読むのもおもしろいけれど、まさに現在進行形で「定着するのか?しないのか?」と揺れ動いているビットコインたちのことを想いながら読むと連載中の漫画の最新話を読むときのような興奮もあります。

宗教的信仰に関して同意できないキリスト教徒とイスラム教徒も、貨幣に対する信頼に関しては同意できる。なぜなら、宗教は特定のものを信じるように求めるが、貨幣は他の人々が特定のものを信じていることを信じるように求めるからだ。

(Kindle の位置No.3357-3359)

美しい文章構造だなあ。

帝国とグローバル化 (第11章〜)

上巻の終盤、帝国のお話もおもしろかったです。

  • 帝国は、ぜんぶまとめて俺が面倒を見るから!幸せにするから!というオラオラ系のノリで他を飲み込んで大きくなる
  • 飲み込むときには、人間たちを大量に殺戮したり迫害したり、文化を壊滅させたりもする
  • それでもバーンと大きくなると社会は安定する
  • 飲み込まれた民族や文明も、やがてその帝国の一部となって成長を助けることになる

ざっくりと、こんな理解であっているのでしょうか…!

こんな調子なので、現代の地球には「純正の文化」と呼べるようなものは残っていないそうです。

アメリカ合衆国という帝国では、ケニア人の血を引く大統領がイタリア料理のピザを食べながら、お気に入りの映画『アラビアのロレンス』(トルコに対するアラビア人の反乱を描いたイギリスの英雄物語)を観ることもありうる。

(Kindle の位置No.3605-3607)

わははは。

人類の文化から帝国主義を取り除こうとする思想集団や政治的運動がいくつもある。帝国主義を排せば、罪に汚されていない、無垢で純正な文明が残るというのだ。こうしたイデオロギーは、良くても幼稚で、最悪の場合には、粗野な国民主義や頑迷さを取り繕う不誠実な見せかけの役を果たす。有史時代の幕開けに現れた無数の文化のうちには、無垢で、罪に損なわれておらず、他の社会に毒されていないものがあったと主張することは妥当かもしれない。だが、その黎明期以降、そのような主張のできる文化は一つもない。現在、そのような文化が地上に存在しないのは確実だ。人類の文化はすべて、少なくとも部分的には帝国と帝国主義文明の遺産であり、どんな学術的手術あるいは政治的手術をもってしても、患者の命を奪うことなく帝国の遺産を切除することはできない。

(Kindle の位置No.3681-3688)

そうですよねぇ。もし今日から「純粋な日本文化のみに触れて暮らしていきます」と言おうとしたら、はたしてぼくの生活には何が残るのだろう?って思っちゃいますもんね。

ところで、ぼくにとっては「帝国」ってあまり身近な言葉ではなくて、アルスラーン戦記将国のアルタイルなどの物語の中に出てくる概念として捉えがちです。「身近なところに帝国ってある…?」ともうちょっとだけ立ち止まって考えてみると、ぼくが今年いちばん「帝国っぽい」と感じたのは Instagram でした。

人間の殺戮や迫害こそしないものの、ソフトウェア・プロダクトの影響範囲の拡げ方は、この書籍で読んだ帝国の姿に通ずるものがあると感じます。ある意味では、いまや Instagram が法であり、Instagram における影響力がパワーであり、カフェも Instagram の方角を見て営業しているわけです。鈍器や刃物や火薬を用いて領土を奪い合う戦いは減ってきたものの、テクロノジをぶつけあってシェアという領土を拡大するための戦いは、この瞬間にも進行しています。

今年に限定せずに直近10年くらいのスパンで考えてみると、Google、Amazon、Apple 等を見て「帝国じゃん」と感じることもできました。まあ、よく言われていることでしたね。ぼくの感覚がみなさんに追いつきました。

まとめ

ふとしたきっかけから、書籍「サピエンス全史」の上巻を読みました。けっこうボリューミィなので、読むのが遅いぼくはやや苦労しましたが、おもしろくて最後まで読んじゃいました。下巻はどうしようかなあ。下巻の目次を見てみると「科学革命」「資本主義」「文明は人間を幸福にしたのか」などなど目をひくフレーズが多いですね… 年末年始にでも読めるといいかな。

読んでいる途中で一度「これ、日本語で書かれた本だっけ?」と思ったときがあって、それくらい自然に読める翻訳です。めちゃくちゃ丁寧な仕事だと思います。

だいぶおもしろい書籍なので、いまさらですがぼくからもおすすめしておきます。ごちそうさまでした。

サピエンス全史(上) 文明の構造と人類の幸福 サピエンス全史 文明の構造と人類の幸福 | ユヴァル・ノア・ハラリ, 柴田裕之 | 歴史学 | Kindleストア | Amazon

このエントリーをはてなブックマークに追加

RubyWorld Conference 2017 に参加してきた

2017-11-07

RubyWorld Conference 2017

RubyWorld Conference 2017

PB010508

勤め先であるGMOペパボ株式会社が去年からスポンサーとして協力させてもらっている RubyWorld Conference というイベント。今年はスポンサーセッションでおしゃべりする担当として松江まで行ってきました。ぼくも Rubyist の端くれとしてもちろん松江には一度行ってみたいと思っていて、ようやくその願いが叶った形になります。

詳細なイベントのレポートは他に任せるとして、ここの個人サイトには参加者としての個人的なメモを書いておきます。

感想

「来年もまたきたい!」と思える、素晴らしいイベントだった。このような素敵なイベントが9年も続いているなんて、ありがたいことだなあ。2018年に開催されるはず?の次回は記念すべき第10回の開催になるとのことで、ぜひともまた参加したいところです。

松江市だけじゃなく島根県に訪れるのも初だったぼくは、ちょっとした観光も楽しめた。イベントの常連組のみなさんは非常に練度が高くて、空港から松江駅への移動方法や、松江駅周辺の地理情報、イベントの楽しみ方などなど、いろいろと教えてもらえて助かりました。

下の写真は、帰りの日に食べた割子そば。とってもおいしかった。

PB020636

交流

イベント前日夜のウェルカムパーティでは、まつもとさんに「技術顧問業、どうですか?」と質問させてもらって、いろいろと聞けてよかったです。他の人からはまず聞けないような、楽しいお話でした。

他にも直接的だったり間接的だったりでお世話になっている Rubyist のみなさんとお話する機会がたくさんあり、たっぷり2日間ほど充実した時間を過ごせました。これを書きながら思い出してみても、はーーー楽しかったという気分になれます。

宿題

みなさんの講演を見聞きしたり、お話させてもらったりする中で、いくつか宿題が見つかりました。これからの日々で自分なりの答えを探していくぞ。

あとからでも宿題を思い出せるように便利資料リンク集を置いておきます。あと、会場から撤収する間際に @koic さんと話したことがおもしろくて、しかもそのあとにバスの中で @moro さんとも似たような話になって、ぼくはあの続きをやりたいので都内でお話できたらいいなあ、と!そういうテンションになったので週明けの社内で @kenchan に雑に絡んだりしました。

感謝

RubyWorld Conference 2017 の開催に向けて尽力されたみなさん、ありがとうございました。おかげで楽しい時間を過ごすことができました。島根観光の最初のきっかけにもなりました。現地でお世話になったみなさんにも感謝したいです。楽しさがマシマシになりました。

来年も行きたいぞ〜!

このエントリーをはてなブックマークに追加

無理してがんばっている人

2017-11-06

がんばりたくてがんばっている人はそれでいいと思う。心の中で静かに「がんばってね」と応援させてもらう。たまに「がんばりたい」より「がんばらなきゃ」という雰囲気でがんばっている人や、自身の許容量をこえてがんばろうとしている人がいて、心配に感じてしまう。

ぼくが見てきた範囲では、無理してがんばっている人というのは、どこかでそのがんばりをまわりにも押し付けそうになる危うさがある。たとえそれがなんであれ、それを他者に押し付けてしまった瞬間に意味が変わってしまう。継続的にがんばるのなら、自分のコントロールできる範囲で、自分のうちに留めておけるように、無理なく自分でいられるようにがんばるのがいいと思う。

「無理してがんばっている人」を「無理して意識を高く保とうとしている人」に言い換えても同様。つまり、無理している状態がよくないんだ。みんなが無理なくがんばれる状態がいいなあ。

自分はこんなにがんばっているのに──そんなふうに心の声がこぼれてしまう瞬間がある人へ。どうか、一息ついてほしい。無理なくがんばっていきましょう。なんだったら、がんばらなくたっていい。

このエントリーをはてなブックマークに追加

書籍「初めての自動テスト」を読んだ

2017-09-24

初めての自動テスト - Webシステムのための自動テスト基礎

O’Reilly Japan - 初めての自動テスト

那須のせきさん経由でオライリー・ジャパンの高さんから送っていただきました。ありがとうございます!楽しく読んだので感想を書きます。

ざっくり、どんな内容か?

原題は The Way of the Web Tester で、内容としても「ウェブアプリケーションの自動テスト」が中心となっています。また、邦題の「初めての」に意味が込められているように、これから自動テストを導入してみたい、あるいは、導入してみたもののこれからどうやって活用していったらいいかよくわからない、といったフェーズにある人を主な対象としていることでしょう。

途中、基礎知識として HTML や CSS という要素技術や、REST という考え方の概要を説明していたり、Google Chrome の開発者ツールの使い方に紙面を割いていることからも、入門書であろうとしていることが伺えます。

文中に登場するサンプルコードは Ruby on Rails 製のウェブアプリケーションに RSpec か minitest で書いてあるものがほとんどで、第7章では Jasmine で JavaScript のテストを書いています。ただこれは筆者も「サンプルとして示しやすい言語・フレームワークを選んだだけ」と明言していて、他の言語を好んで利用している人たちを想定読者から外すものではありません。

すでにたくさんのテストコードに囲まれて暮らしているソフトウェアエンジニアなら、第1章と第8章を読んでみて、自分の中にある自動テストに対する理解や認識をあらためて整理してみるのがよさそうです。

ぼくが読みながら思い出したのは勤め先の会社でエンジニアインターンシップを実施し、そのメンターを担当したときのこと。インターン生といっしょに Rails 製のウェブアプリケーションの機能開発に取り組んだとき「テストは書いたことがないので、どうやって書いたらいいかわかりません」と相談を受けました。今月にも弊社で同様のインターンシップを実施していて、やはり学生さんは「テストを書いたことがない」という人がほとんど。インターンシップの実施報告にも部分的に書いている通り、ぼくがインターン生に相談を受けたときは以下のようなトピックについて話したと記憶しています。

  • なぜテストを書くのか?
  • どのようにテストを書くのか?
  • テストは先に書く?あとに書く?
  • REST というアーキテクチャスタイルについて
  • 継続的インテグレーションについて

この本には、ぼくがなんとなく「このへんは説明しておいた方がいいかな」と思って話していたことのほとんどが含まれています。継続的インテグレーションについては触れられていないものの、初めてテストを書こうとする人に向けたメッセージはふんだんに盛り込まれているので、次にまたインターンシップのメンターを担当するようなことがあれば、この本を手元に用意しておきたいと思いました。心強い1冊になってくれることでしょう。

ざっくり、どんな雰囲気か?

書籍アジャイルサムライのテイストが好き!という人なら楽しめること請け合い。Jonathan Rasmusson の、あの独特のなんとも言えないテイストは本作においても健在です。

読書メモ

  • 第1章
    • あらためて自動テストとはなにか、なぜか、を考えて気持ちを整理する
    • 開発を加速してくれていたはずのテストがいつの間にか足枷に… わかる、めっちゃわかる…
    • テストだって銀の弾丸じゃないよね
    • ぼくは「テスター」という役割の人とプロジェクトでごいっしょしたことないな
  • 第2章
    • いきなり Capybara で E2E テストを書いていて強い
    • サンプルコードは無駄が少なくて読みやすいですね
    • でも実際の現場ではこのサンプルコードが動くようになるまでのセットアップの方が大変そう
    • 各位、がんばっていきましょう…!
    • スモークテストという語彙を得た
  • 第4章
    • HTTP や URL の講座がはじまっておもしろい
  • 第6章
    • detestable という英単語を知った、テストしにくいってことは忌まわしい
  • 第7章
    • まるまる1章を JavaScript に使っている
    • ちゃんと MVC によって責務が明確になっているコードだからテストしやすくてよかった
    • 最後、テストコードで typo していてテストが失敗するけど、なんであの例を出したんだろ
    • 文字列リテラルの typo の話だから型付けの話ともまた違うのでは?
    • 終盤で「とにかく JavaScript 界隈は変化が激しいからがんばって」と言っている
  • 第8章
    • 逆ピラミッド、またはアイスクリームコーン
    • たまに失敗するテストは削除しちゃう、っていう割り切りはなるほど〜と思った
    • Spotify の「開発生産性向上隊」の話、めっちゃいい
  • 第9章
    • リーダブルコード的な話
    • テストコードにも治安を
  • 第11章
    • この本に「モックとスタブの違い」が書かれているのありがたい
    • 急に白髪交じりのベテランが登場してくるのおもしろい
    • 「モックの泥沼」つらそう
  • 第12章
    • テストファースト
    • 自転車の補助輪を外すようなものなんで、ある程度まで理解できたら実践しましょう
    • いくら勉強しても自転車に乗れるようにはならない、必要なのは練習だ

自動テストと私

  • まわりに「テスト大事」の人たちがいたおかげで書くようになれた
  • 2008年の札幌でかくたにさんもろさんの実演を観覧できたのが幸運すぎた
  • そこを入口にせきさんわださんの言葉を漁るようになった
    • なので今回、せきさんから連絡をもらえているのは自分にとってはすごいことなのだ
  • あとは、幸いにもテストがしっかりメンテナンスされているプロジェクトに関われてこれたので、自然に書く生活を続けられている

今でも「バグが発覚してそれを修正するとき」と「レビュアー向けに Red → Green を見せたいとき」は、ほぼ必ずテストを先に書く体になりました。自動テストに出会ってからもうすぐ10年かあ。

このスクリーンショットは、レビュアーに「ほらね」と見せるつもりでわざと CI を赤くするコミットを先にプッシュしているときの様子。

まとめ

O’Reilly Japan - 初めての自動テストをいただいたので、読んで感想を書きました。これからやる!という人に向けて手渡したい心強い1冊です。読み口も軽快で楽しく読めるところもおすすめポイントです。

このエントリーをはてなブックマークに追加

LDR終了の報を受けてフィードを整理していて思ったこと

2017-08-19

ありがとう、LDR

【重要】Live Dwango Reader/LDR Pocketサービス終了のお知らせ|LDR / LDRポケット 開発日誌

ドワンゴさんが引き取ってくれたものの、それも延命措置にしかならず、今度こそ本当に LDR とお別れすることになるっぽい。ちょっと気になって調べてみたけれど、ぼくがいつから LDR を利用しているかはわからなかった。LDR 以外のフィードリーダを常用していた時期もあってそれを突き止めるのはなかなか難しいのだけれど、このブログの2007年9月19日の記事で LDRize についてアレコレと言っているので、少なくともこのときには LDR を認知していて、身近な存在と感じていたことは間違いないだろう。2007〜2009年ごろには、フィードリーダはぼくにとって「情報収集のための必携ツール」だったのだ。

そうすると、丸10年くらいは LDR の存在する世界で過ごしてきたことになるので、あらためてこれはすごいことだなぁと思う。いつごろからか Twitter のタイムラインを熱心に見るようになり、フィードリーダからやや遠ざかっていた時期もあった。それから Twitter のある世界で何年か暮らし、でもやっぱりぼくは「日記を読むのが好きだ」「そしてそれは、流れてくるツイートを読むのとは確実に異なる体験だ」と思うに至り、主に「友だちやウェブ上で見かけるなんだか好きな人たちの日記をなるべく欠かさずに読む」ためのツールとしてフィードリーダを愛用してきた。

そして2017年7月、冒頭に置いた LDR 終了のお知らせが届いてしまった。

まずはとにかく、登録してあるフィードの情報を失うわけにはいかないのでエクスポートだ。ぼくらには OPML 形式があるので、特に困ることなくよく知ったデータ形式で登録フィードの一覧データを手にすることができた。

さて、むずかしいのはこのフィードのリストをどう扱うか、だ。ざっくり、3通りの未来があるだろうか。

  • (1) もうフィードリーディング生活をやめる
  • (2) 別の既存のフィードリーダに移行する
  • (3) あらたにフィードリーダを自作する

とりあえず (1) はナシだなあ。友人をひとり失うような、そんな喪失感を伴いそうなので (1) はナシにしよう。なので (2) or (3) で考えてみる。ここで、LDR を使いつつもフィードリーディングが疎かになるときのことを思い出した。それは「なんとなく LDR にアクセスしない時期」だ。だいたいのフィードリーダは「アクセスする」「起動する」が行動の起点となるので、これが習慣にならないと一気に疎遠になる。これと対比して、たとえば「はてなブックマーク - マイホットエントリー」のデイリーのお知らせメールは、メールボックスさえチェックしていれば目に触れることになるので、わりと自分の生活には定着していた。こういう形でのフィードリーディング生活を目指してみるのはどうだろうか。

その筋で考えたときに最初に思い浮かんだのは Slack の RSS Integration だった。常に開いている Slack Team がいくつかあるので、そこに自分のフィードリーディング用のチャンネルを用意し、新着フィードを流してやればよいのではないか。しかしこれだと、新着を検知するたびにチャンネルに通知されてしまうから気が散るかもなあ、というところが難点。

でも「Slack で通知を受け取って読む」というのは、今の自分の生活スタイルにあっていて悪くない案に思えた。というわけで。LDR からエクスポートした OPML ファイルを種に、1日1回の頻度で直近1日分の新着エントリを Slack に通知する雑なスクリプトをこしらえて、動かしはじめてみた。

新しい生活をはじめてから1週間ほどが経過した。おおむね快適に過ごせている。2017年のぼくは、フィードリーダに UI を求めていないということもよくわかった。新着エントリのリストさえ手に入ればいいのだ。Slack であれば、最短でも向こう1年くらいは使い続けるであろうから、受信装置としては充分だ。また、Slack から別の舟に乗り換えるときがきたとしても、通知先をちょいっと変えてやれば済むだけの話。当面はこの運用を続けてみよう。

結果を見ると、そんなにだいそれたものではないけれど (3) の「自作」を選択していた。

フィードを整理していたときのこと

1日に1回だけ実行される、100行にも満たない、雑なスクリプトを書いていたとき。デバッグのために500件ほどのフィードのエントリをだばだばとコンソールに出力して眺めていると、ずいぶんと懐しい気持ちにさせられた。

失効してしまったドメイン。アクセスすると404を返してくるブログ。すでにクローズしてしまったブログサービス。それらの URL は、そっと購読データから消してやった。これがなかなか寂しい作業で。LDR に登録してあるだけだと新着エントリが上がってこなくなるだけなので、対象サイトが生きているのか死んでいるのかは気にせずに過ごしていたのだあ。自前のスクリプトでは、アクセスできなかったら新着エントリの代わりにその旨を Slack に通知するようにした。もしこれからサイトの死に気付いてしまう瞬間があったら、そっと目を閉じて手を合わせるのだと思う。

何年も前に更新が止まってしまっているブログもたくさんあった。これらは、サイトとしては生きているので、フィードは問題なくパースできた。途中、新着かどうかを判定する処理をミスって、全エントリを延々と Slack に通知してしまったときがあって。2006〜2012年ごろに元気よく更新されていたブログのフィードが、まるできのう今日に更新されたかのようにばしばしと通知された。友人のブログの古いエントリから順に「2006年mm月dd日 ◯◯を作りました」「2007年mm月dd日 △△に参加しました」と通知が送られてくると、まるでタイムスリップしたかのような感覚を味わった。大学時代の自分は、フィードリーダでそのブログを熱心に読んでいたのだ。もうしばらく思い出さずにいた内容ばかりだったので、判定ミスでバグっているスクリプトから数秒間隔で送られてくる10年以上前のブログの「新着エントリ通知」を、ぼくは楽しく読んでしまった。「次のエントリ、はよこい!」と。

そうしてあらためて「やっぱりブログはいいなあ、どんなことでも書いておくといいなあ、人々の日々は尊いなあ」と心から思い、だったら自分もブログを更新しよう!という気持ちで、今日のこの気持ちを綴ってみたのであった。

このエントリーをはてなブックマークに追加

2017年下半期の成長計画づくりワークショップ

2017-07-21

ぼくの勤め先であるGMOペパボ株式会社では1月から6月が上半期、7月から12月までが下半期という区分です。2017年も明けて「今年もがんばるか〜」と思っていたのが先日のはずなのに、気がつけば下半期が始まっていました。というかすでに7月も下旬ですね…すみませんでした。

ペパボには期ごとに運用される評価制度があって、2017年下半期が始まったので「目標設定やらなきゃ〜」「今期はどうしよっかな」「面談やりましょうか」といった声があちらこちらから聞こえてきます。期初の風物詩です。評価制度についてはすでに様々な場所で語られていて、エンジニアの評価制度について - console.blog(self);の記事に他社のものとあわせてまとめられていたのでリンクしておきます。

2017年1月にペパボの本社事業部のチーフテクニカルリードになりましたで触れた通り、ぼくは今年からひとつの事業部(当時は「本社事業部」でしたが、今では名前が変わって「SH事業部」になりました)のエンジニア組織をいい感じにするミッションを授かっていて、2回目の期初となるこの時期をどのように過ごしたものか考えていました。そして、自分を含むみんなの2017年下半期が最高のものになるようにと、表題にある「成長計画づくりワークショップ」を実施するに至ったので、その顛末を紹介したいと思います。

これまでのふりかえり

ぼくは2015年5月の入社なので、これまでに5回の期末を経験してきました。期末には、その期の評価制度の締めとなる面談があります。そこで、半年間の実績について話したり、得たものや苦労したことなどを整理し、次の半年間につなげるための時間を過ごします。「評価制度」というくらいですから、評価結果も当然あります。各自が自分の目標や実績と自己評価などをまとめた「評価資料」を作成し、面談ではそれをもとに会話を重ね、最終的な評価結果を得ます。

さて、このときにアンハッピーな事態が起こり得ます。被評価者の自己評価と評価者が出す評価にズレが生じることがあるのです。面談等の場で会話を通じて認識のズレを解消できればまだよいですが、場合によっては完全には納得できないまま評価を下されることになるでしょう。これは、被評価者にとっても評価者にとってもうれしくない事態です。

では、なぜこういった事態が発生するのでしょうか?ぼくが見聞きしたケースには、以下のような要因があったように思えます。

  • 目指すべき方向が共有できておらず、あらぬ方向に突き進んでしまった
    • 評価者が「そっちじゃないんだよなあ」と思ってしまう
  • 目指すべき方向はあっていたが、どこまで進めば充分かを共有できていなかった
    • 評価者が「もっと進んでほしかったなあ」と思ってしまう

「西に10km以上進んでほしい!」という期待に対して「北に10km」だったり「西に5km」という実績になっている、という状態です。認識のズレが原因で評価が高くならないようだと、被評価者は「せっかくがんばったのに…!」とモチベーションを下げてしまうかもしれませんよね。そんな事態は可能な限り避けたいものです。

なにを隠そう、ぼくは2015年下半期の面談に「自己評価はSです」と臨んで「じゅんくん、そういうことじゃないんだよ」と見事に散りました(?)からね…!ぼくの場合は別にモチベーションを下げることはなくて、フィードバックを受け止めて「たしかにそうだよな〜」と思えたので、よかったといえばよかったですけれども。にしても、期末じゃなくて期初に気付いていれば、もっと有意義な半年間を過ごせただろうとは思います。今にしてみれば。

じゃあ、どうすれば認識のズレによるアンハッピーな事態を回避できるのか?を考えてみましょう。ところで、認識のズレによって失敗する先述のようなケースを見たとき、ぼくは「なんかこの失敗、経験したことある気がする…」と思いました。プロダクト開発に携わっている人なら、もうピンときたかもしれません。

  • 顧客が必要としていない機能を開発してしまった
  • 顧客が望む機能ではあったが、品質が充分ではない状態でリリースしてしまった

こんな状況に、とっても似ていると感じました。耳も胸も痛いですね…!人はなぜ、よろこばれないお仕事に多大な時間を費やしてしまうのか… ウッッ!っと傷つくのはあとでゆっくりやることにして、ここは歯を食いしばって先に進みます。もしこれがプロダクト開発における問題と同種ならば、よく知られたプラクティスによって問題を回避できる可能性があるのではないか、と仮説を立ててみます。

プロダクト開発の心強いプラクティス

今回ぼくが取り入れることにしたプラクティスは、以下の2つです。

(1)によって、目指すべき方向があっているかを事前に確認できます。(2)によって「こうやるともっと先に進めるかも」という発想が促されることを期待します。どちらも、最近のプロダクト開発、ソフトウェア開発の現場ではふつうに実践されているような内容かと思います。むしろ、どうして今まで評価制度の運用には取り入れてこなかったんだろう、と思うくらいで。

成長計画づくりワークショップ

やってみました、ワークショップ。

まず、最高にハイな状態で2017年下半期の終わりを向かえた自分のことを想像し、すべての項目でS評価の自己評価を記入した評価資料を作成します。社内で2回に渡ってこのワークショップをやってみたところ、参加者のみなさんは15〜20分くらいで書けていて、素晴らしいな〜と思いました。イメージをつかんでもらうためのサンプルとして、ぼくの2017年下半期の評価資料をつくって持っていったのですが、ぼくは書き上がるまでに40分くらいかかりました。ぼくだけズルしてごめんね。サンプルとしてわかりやすいものにしたかったので、みなさんよりじっくり取り組ませてもらいました。

みんなの分が出揃ってきたら、それを参加者のみんなでいっしょに見てレビューをします。ワークショップの中では、このレビューのことを「MOD」と呼ぶことにして、みなさんには「じゃあMODをお願いします!」のように呼び掛けました。MODはもちろん、ペパボの企業理念であるもっとおもしろくできるの略です。すんばらしい未来の姿を描くためのワークショップなので、ネガティブなフィードバックよりもポジティブなフィードバックがたくさん出るようにと願いを込めて「みんなでMODしましょう〜」と声をかけていました。

誰かが「こんな成果が出すことができた!」と下半期の実績を語れば「しかも、それをテックブログに書いていてめっちゃよかったよね」と誰かがMODします。「PHP 7.2 へのアップグレードが完了しました」「あれは対応が早かったね、リリースされてから1週間以内でキャッチアップできていてすごかった」や「◯◯をプロダクションに導入できました」「それを見て入社してきた人もいましたよね〜」なんてやりとりもありました。まあ素敵!

ワークショップをやってみて

なんにせよ初の試みなので不安もありましたが、参加者のみんながしっかり乗っかってきてくれて、とっても楽しい時間になりました。「半年後の最高の俺たち」の姿を見ることができたので、なんだか誇らしい気持ちにもなれます。各自、自分の口から「こうなっていました」をみんなの前で表明したことで、もうやるしかないぞ〜という気持ちになってくれたんじゃないかなぁと思います。

「2017年下半期の評価資料」という中間成果物にはけっこうなエネルギーがあって、うちの事業部のエンジニアたちがつくってくれた資料は、他の事業部のエンジニアたちの目にも留まって「え!なにこれ!めっちゃいいことが書いてある」という反応につながりました。そうして、けんちゃんくんさんが CTL を務めるお隣の事業部でも同様のワークショップを開催させてもらうことができました。

2回ともおおいに盛り上がったので、まだまだ改善の余地はあるでしょうが、悪くないワークショップができたと感じています。今日もうちの事業部では、みんなで見た未来を現実のものにしてくれそうな勢いある行動を見かけましたよ。やったね!

まとめ

  • 2017年下半期が始まったので、最高の半年間にするためにワークショップを開催してみました
  • このワークショップは、もともとあった評価制度をさらによいものにすべくプロダクト開発のプラクティスを取り入れた内容になっています
  • 参加者みんなで盛り上がって楽しい未来を見てから現在に戻ってくるので、みんなが元気になるのもうれしいです
  • これまでの目標設定は「各個人のもの」か「当人と上長のもの」に留まりがちでしたが、これがチームで共有されてフィードバックしあえるようになるよさもあります

みなさんの現場で成長の加速のために工夫していることなどあれば、ぜひぜひ教えてほしいです。ぼくたちももっともっと成長していきたいので、よさそうなものはどんどん取り入れて自分たちを変えていきたいです。

もしこのエントリを最後まで読んでくれたペパボの人がいたら、ぜひ社内でも共有してください。「自分も成長したいとは思っているけれど、下半期をどんなふうに過ごしたら成長につながるかはまだわかっていない…」そんな人がいたら、そう思えた今が好機です。いつでも話しかけてきてください。もちろん、エンジニアに限らず。きっと力になれると思います。

それでは、2017年の後半戦も楽しんでいきましょう〜!

このエントリーをはてなブックマークに追加

これからチーム開発に立ち向かう花ざかりの君たちへ

2017-06-29

2017年度新卒研修がはじまりました! - ペパボテックブログ

上記エントリにあるように、今年の4月に入社してくれたフレッシュ・フレッシュ・フレーッシュな若者たち、社内では「新卒7期生」と呼ばれているみんなの研修の日々が続いています。毎日、彼ら彼女らががんばる姿を見ることができて、刺激的で楽しい最近を過ごしてきました。どうも @june29 です。

今は職種別の研修期間に突入していまして、エンジニア研修の座学もはじまりました。この座学は、ペパボの仲間たちがかわるがわる教壇に立ち、7期生に知っておいてほしい内容をおおいに語る時間になっています。下記は、座学講師を募集するインターネット掲示板の様子です。

ぼくも、ペパボに入社した2015年、その翌年の2016年と、こうした新卒生たちと交流する機会には積極的に関わってきました。自分とは違う世代の人たちと話していると気付くことが多いですからね。少しでもお近付きになりたいといつも思っています。

今年も「俺がやるぜ〜!」という気持ちはありつつ、うちの事業部にいる「自分がおもしろ人間であることをあまりアッピールせずにいるズルい人たち(?)」にこそどんどん前に出てほしいという想いがあったりして、座学の枠が少しずつ埋まっていく様子を一歩引いた位置から眺めていました。そんな、ある日。

今年のエンジニア研修の船頭役を務めている @asuforce@shimoju_ から「6月29日の枠が空いていまして」とお声がけいただき、この枠にふさわしいハンドルネームを持つ者は @june29 をおいて他にないだろうということで、ありがたくお引き受けしました。ふたりが与えてくれたテーマは「チーム開発」です。この瞬間から、ぼくがこれまでの10年間ほどの経験を思い出し、チーム開発について自身の考えをまとめあげていく時間がはじまったのでした。

3章から成る構成にしたものの、今日伝えたかったことは「チームについて」がほとんどでした。このあとに続くたくさんの座学の中で、ソフトウェア開発については、他の講師のみなさんが素晴らしい教えを示してくれるでしょうから、ぼくはそちらに任せることにしました。

花ざかりの君たちへ。これから過ごす日々に、楽しいチームと楽しいソフトウェア開発がありますように。応援しています!ソフトウェアエンジニアの定年退職まで残り1年となったぼくからは以上になります。

このエントリーをはてなブックマークに追加

「自分の側にあって、相手の側にないもの」を正しく伝えること

2017-04-24

自分が日々のコミュニケーションの中で「これを重要視しているな〜」と気付いたものがあったので、整理のために書きます。ここでは「情報をやりとりする」タイプのコミュニケーションを扱います。

そもそもコミュニケーションとは、異質な2つのものをつなぐためのものです。もし、あなたとぼくが完全に等しい存在であったとしたら、そこにコミュニケーションは必要ありません。我が家はなかよし夫婦だとは思いますが、奥さんとぼくは異なる存在であり、性格も価値観も所属も経験してきたことも違うので、その差分を楽しむために日々コミュニケーションを取っています。はい。

「相手と自分は違うものである」という前提が、とっても大事。そう考えると、誰かとコミュニケーションを取るときには「自分の側にあって、相手の側にないもの」を正しく伝えることが重要であるということがわかってきます。

お仕事でのやりとりを想像してみても、そうですよね。ぼくはソフトウェアエンジニアなので、他の職種の人とやりとりするときには「ソフトウェアエンジニアリング」の観点から他のみなさんに情報提供することを心がけています。

また、スケジュールの相談についても同様です。ときに、恐らく相手を思いやる気持ちによって、作業をお願いする側が「そんなに急がないので、今やっている作業が終わってからでよいです」と言ったりします。それに対して引き受ける側が「すぐ終わるんで、今からシュッとやっちゃいますね」と返したとしましょう。

  • 「そんなに急がないので」はけっこう曖昧なので、より詳細な情報を伝えられるとよさそう
    • たとえば「今日中に終われば最高、今日で終わらなそうな場合はいつ終わるか知りたい、今月中に終わらないようなら相談したい」くらいの情報があると判断に役立つ
  • 「今やっている作業が終わってからでよい」は、自分より相手の側の事情に立ち入っているので、確度の高い言及はむつかしそう
    • このやりとりでは結局、引き受ける側が「すぐにやっちゃった方がいい」と判断している

お願いする側がどれだけがんばったとしても、引き受ける側の都合を100%理解して引き受ける側の代わりに判断することはできませんからね、そこに力を注ぐよりは、自身が持っている情報を適切に示して引き受ける側が判断しやすい状況に近付けるのが得策でしょう。ポイントは「相手を思いやること」と「自分が持っている情報を正しく伝えること」は両立できるということです。前者だけを考慮しようとして「なんだか忙しそうに見えるし、今日中はむつかしそうだから、今週中でお願いしてみようかな…」と想像することはできますが、どこまでいっても想像することしかできません。それならば、しっかり後者をこなしていくのが、誠実なコミュニケーションだとぼくは思います。

こういったやりとりは実際にちょくちょく見かけるので、それぞれの現場でコミュニケーションを改善できないか?を考えてみるのもよいのではないでしょうか。

(関連) 「わたしメッセージ」へ、そして「わたしたちメッセージ」へ。

以前に「わたしメッセージ」という考え方について書いたことがありました。これもコミュニケーションにまつわる話で、簡単にいうと「主語を “わたし” にしましょう」というものです。実は、主語を “わたし” にしてやりとりしていると、自然と自分側の情報を相手に伝えていくことになるので、あわせて紹介しておきました。

このエントリーをはてなブックマークに追加

「第2回エンジニアリングマネージャー勉強会」でトークしてきた

2017-02-21

ペパボの本社事業部のチーフテクニカルリードになりましたに書いた通り、2017年1月から社の事業部のひとつのチーフテクニカルリード(通称: CTL)を任せてもらっていて、今年はエンジニアリングマネージメントについての考えも深めていきたいと思っています。なにかを学ぶときに発表の機会を持つのは常套手段ですから、今回のイベントが GMO Yours で開催されると知った瞬間に「トークしたいです」と手を挙げました。

第2回 エンジニアリングマネージャー勉強会 - connpass

以下、トークで使った資料です。

資料だけ見てもよくわからないでしょうから、このエントリでいくらか補っておきます。

大切にしてほしい3つのこと

弊社には大切にしてほしい3つのことというものがあります。社内のみなさんは当然知っているでしょうし、噂によると採用面接のときにも「これ知っている?」と話題に挙がることが多いそうなので、これから弊社を受けようと思っている人もチェックしておくとよいでしょう。

  • みんなと仲良くすること
  • ファンを増やすこと
  • アウトプットすること

さて、この3つを試しに読み上げてみると、どんな感想を抱くでしょうか?ぼくは「けっこうふつうだな」と、入社直前にはそんなふうに思っていました。どれも「あなたは大切にしていますか?」と聞かれたら「ええっと… はい、大切にしていると思います」と答えてしまいそうな内容に思いました。

これ実は、社のエンジニアにとっては半年ごとの「評価」にも大きく関わっている話で、この3つが評価の軸にもなるんですね。この3つそれぞれについて「あなたはこの半年間、どれくらいできていましたか?」と問われることになるので、自身の評価資料を作成するにあたって、多かれ少なかれ向き合うことになる3ヶ条です。

今でもはっきりと覚えている、ぼくが入社してから初となる期末の評価面談のこと。ぼくは「みんなと仲良くすること」の自己評価を、最高評価の「S」として面談に臨んだのでした。面談相手を担当してくれたのは @hsbt さんと @kenchan くんさんです。

さて、ここでぼくの面談の数日後のチーフエンジニアの日報の一部を見てみましょう。

面談、みんなと仲良くする、アウトプットするという部分について同じことを色んな人にひたすら繰り返し説明しているので書いておこうと思う。

みんなと仲良くするという項目で違うチームとコミュニケーションをとって開発したので評価A,Sですという人が多々いるけど、専門職であるエンジニアにとって、それは業務を遂行する上では当たり前であり「仕事をしていました」と同義なので、それらが優れた実績である、とは評価することはできない。

ではどういうことが優れているのか、というのは等級にも影響するものの、大別すればコミュニケーションをとる範囲が等級で求められているものに比べて事業部、会社を超えているなど範囲が広いであったり、コミュニケーションの創発が自らの活動によって引き起こされたものであったりする、というような場合に優れている、と評価可能と考えている。

つまり、「自らが何をした、何を実現した」ということが引き金となって、コミュニケーションを取れるようになった、コミュニケーションが高いレベルで取れるようになった、という事実を主張した上で、この何をした、ということが優れた実績なのだ、という主張が初めて可能となる。

ウエーイ、視座が低かったワイのことが書いてあるぞ〜〜〜。まさにこれと同じような話を面談のときに言ってもらえて、たしかにそうだよなぁ、ワイはちょっと捉え方が狭かったよなぁ、と痛感し、面談の直後に自己評価を下げたのでした。

この体験を経てぼくは、大切にしてほしい3つのことと出会い直すことになりました。なんとなく日々を過ごして、期の終わりにただ受動的に評価を受けとるのではなく、もっとかっこいい自分になるためには日々をどっちの方向に変えていったらいいかを、この3ヶ条とにらめっこしながら真剣に考えるようになりました。そうして、件の面談があった次の期から自身の活動範囲を拡げて「本社事業部エンジニアの会」というものを発足し、それからいくらか経って本社事業部のチーフテクニカルリードになり…。あの面談を経て考え方をスイッチできたことが、今のぼくの日々につながっていたのですねぇ。

というわけで、弊社においては「大切にしてほしい3つのこと」を各自が解釈して自分の日々に還元していくことは、とっても大事です。ただ、ぼくは自分ひとりではその道を見つけられず、より視座の高い人たちとの会話によってようやく気付くことができました。

こういった指針が明文化されているのは、とても心強いことです。この指針に従って行動していけば、社内で多くの人に喜ばれる可能性が高いわけですからね。漠然と「いいエンジニアになれ!」と言われる場合に比べて、考えるためのヒントが散りばめられているのはありがたいことだと思います。加えて、それを各自が自分の文脈に落とし込んで解釈することも大事です。指針があって、解釈がある。そうして初めて、各自が自身の行動を変え始めることができると思います。

ぼくは本社事業部のチーフテクニカルリードなので、本社事業部のエンジニアのみなさんが、各自が思い描く「もっとかっこいい明日の自分」になるために、これらの指針をヒントにしながらどんなことに取り組んでいったらいいか、いっしょに考えていきたいです。もちろん CTO やチーフエンジニアが日々の中で発しているメッセージの中にエッセンスはふんだんに含まれているわけですが、本社事業部に属している分、よりみなさんに近い立場で、隣でいっしょに考えられるような存在でありたいと思います。

最近、社の Slack に上の画像のような3つの Emoji を追加しておきました。社内の誰かが「これは、高いレベルでみんなと仲良くしているなあ!」と思ったら「み」の Emoji Reaction をつけますし、他2つについても同様です。こうして「なるほど、こういう行動・活動がかっこいいのだな!」という具体例が広く可視化されれば、エンジニア各位、ひいては社内の全員が、もっとかっこいい自分になるための道を見つけやすくなるだろうと思います。きっと、そうなるであろうことを願って、今日もぽちぽちと Emoji Reaction をつけていきます。

これは Rebuild: 174: One Thousand Custom Emojis (sotarok) でメルカリさんの Slack 文化の話を聴いて速でパクりました。

あまり明示的に「マネジメント!」という言葉を持ちながら今のポジションでお仕事しているわけではないのですが、広義にはこういったこともエンジニアリングマネージメントの範疇なのかな〜と思い、こんなお話をさせてもらいました。

このエントリーをはてなブックマークに追加

もっと古いエントリへ