マイルス・デイヴィスの生涯を追うドキュメンタリー。友達が良かったって言ってたので観てみた。
以前、伝記を読んだり、菊地成孔の本を読んだりして予習済みなので、一生涯に渡って何が起きるかはわかっていたけど、このドキュメンタリーはマイルスそっくりのナレーションが入っているのが良い。
自伝では、この頃、尻の調子が悪かった…という話が何度も繰り返されるけど、ドキュメンタリーでは尻へのこだわりはカットされていた。
今日の昼休みはこれを聴いていた。70年代のこういう音が好き。
マイルス・デイヴィスの生涯を追うドキュメンタリー。友達が良かったって言ってたので観てみた。
以前、伝記を読んだり、菊地成孔の本を読んだりして予習済みなので、一生涯に渡って何が起きるかはわかっていたけど、このドキュメンタリーはマイルスそっくりのナレーションが入っているのが良い。
自伝では、この頃、尻の調子が悪かった…という話が何度も繰り返されるけど、ドキュメンタリーでは尻へのこだわりはカットされていた。
今日の昼休みはこれを聴いていた。70年代のこういう音が好き。
土曜日は担々麺、日曜日は麻婆豆腐を食べた。以前より辛くてしびれるものを食べてるときだけが生きてるって感じがしている。生きてるって感じ、をもうちょっとじっくり観察すると、単に血行が良くなって便利という話かもしれない。
そういえばこないだ宇治に行ったときに寄った担々麺やが美味しかった。これだけのために宇治に出向いてもいいくらい。もし今好きな場所に引っ越せるとしたら寿司と担々麺と図書館がバランスよく点在する場所に住みたいと思う。
tabelog.com
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。
巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。
思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。
現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。
大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知られている。
庭は、どこに何があるか分かっていて、地図を見なくても安心して歩いていって活動できる場所。そういう、守備範囲というか、足場がチーム開発においてもあるとよい。
新卒だったら学生時代にやったこととか、異動してきたなら前のチームでやっていたことがあるはず。ポートフォリオとして持っている技術でなくても、最近本で読んだとか週末に調べていたことでもいい。
Dockerが得意だったらDockerイメージをより良くします、とか、プログラミングが得意だったら、一般的なプラクティスに沿ってちょっとずつコードを読みやすくするとか。
技術の発揮というのはコードを書くことだけでもなくて、現状のサーバーの構成図や、各サーバーの役割説明ドキュメントを作ってくれた人がいてありがたかった。
そうやって触ったところは庭として認識できているので、どこに何があって、次のイマイチな点はこれである、ということが頭に入る。すると、ちょっと暇があったらちょっとずつ直していけたりする。
暇になったからといって未開の地に冒険に出ていくんじゃなくて、知っているところのちょっとした改善をちょっとだけやっていく、という姿勢を身につけられると、この人はゴミを拾ってくれていてよい人だ、という形でチームに貢献していける。
たびたびエラーが発生しているバグのある箇所があるとする。あるいは、テストが全然ないけど重要なコンポーネントがあるとする。
そういう箇所をちまちま直したり、こつこつテストを書いていくと、その分野には詳しくなれるし、プロダクトとしては重要なコンポーネントが壊れにくくリファクタリングしやすくなるのでお得。
ここで気をつけるべきは、どこでもいいから手当たりしだいに手を付けるべきと言っているのではない。打ったパンチを当てるためにはよいところを狙わないといけない。
社内的には金脈というスラングがあって、今はほったらかしにされているけど、手を入れればすごく良くなる、という意味。サーバーコストを劇的に下げられる可能性がある、とか。
ほったらかしになっていた荒れ地を整えれば、開拓者としての信頼を得られる。
しばらくディレクターをやっていて数年ぶりにエンジニアに戻ったメンバーは、しばらくはインフラスキルを高める、という目標を持って、サーバーのメンテナンスだったり、DBの遅いクエリを直したり、といったissueを拾っていってもらっている。そういう目標なしに手当り次第に手を付けていくと果てしない世界になってしまうので、まずはレイヤ別に下の方から掴んでいって土地勘を得ましょう、ということになっている。
この人はここを強みしたいと動いている、というのが周りから見えてれば、このタスクはあなたの勉強になりそうなのでおすすめですよ、って回していける。
得意になりたい、ということは、まだ得意ではないことを意味している。得意ではないけど任せてもらえるためには、まずは得意技術で活躍して信頼を得ていることが必要だと思う。とはいえ、規模が大きかったり、人数に対してやることが多いチームだと、得意なことを得意な人がやらなくても、ただ目を配ってもらえるだけでありがたいという状態になったりする。
ソフトウェアがどういう構成になっているか分かってくると、ソフトウェアが動くことだけでなく、それをどうスムーズに作るかという、チーム開発が関心になっていくと思う。
今所属しているチームでは、正式なメンターメンティー、という関係もあるし、雑談したり、野良1on1をやったりして、誰が何をやってて、どこにどんな問題があるか見るようにしている。
blog.sushi.money
最近自分がやっていることだと、今はベテランが気にかけていることで担保されている機能を、人からチームに移していこうと、いくつか作業部会を立ち上げたりしている。
小学校には図書委員があって、週に何時間か貸出業務を任されたり、本にラミネート加工をする仕事があったりする。こういう仕組みがなくて本好き小学生のボランティアでやっているのでは図書室は崩壊すると思う。
同じような形で、これらの作業部会でこのあたりを見ていればプロダクトの品質低下を防げるであろう、というような整理をしている。これはチームの中でどういう人が何をやっているかが庭になっていて、役割分担を整理して冗長性を高めたような形。
庭として触って詳しくなっても、自分のものになるわけではないことに注意する必要がある。チーム開発での成果物はみんなのもので、誰がいつ触ってもよい。自分の許可なしの変更は許さない、と言い始める人はいないと思うけど、知っているからと言って権威的な振る舞いをしてはいけない。
リファクタリングという本を読むと、リファクタリングを妨げるものとして、コードの所有権が分かれていること、が挙げられていたと思う(いま手元にないので違ったら教えてください)。
社内では盆栽というスラングがある。過剰な品質を持っていて、作った本人だけが満足しているという意味。裏庭で輝いているとされている。
庭があるのはいいけど盆栽を触っているだけではだめで、あまりに小さいところにこだわってやっていると、他にやること無いのか?という印象になっていく。
自分の学生の頃はGitHubでOSSをいじくり回すのがただ楽しいという時期があって、当時触っていたリポジトリのカバレッジ100%を目指して一泊二日の合宿を企画したりしていた。
楽しかった思い出だけど、週末に友達と宿泊して風呂にも入らずテストを書き続けるのは完全に盆栽を愛でるときの行動で、それによってプロダクトの魅力が劇的に上がったかというと、その時間があったら重要なコンポーネントの重要なタスクに取り組んだほうが実があったかもしれない。
エンジニアのためのマネジメントキャリアパスを読むと、キャリアを積んでいってCTOになるまでの道が記されているので、あとはこの本を読んでください。
この本ではインターンメンターになるところから始まるけど、その前に、どこから活躍していけばいいか、ということを今日の日記では書いてみました。
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
自社の求人票で声出た pic.twitter.com/9JcO6H5O2O
— Takashi Adachi (@asanebo_) 2020年6月26日
これが残業王Tシャツです。
— Takashi Adachi (@asanebo_) 2020年6月26日
↓ PM以外もいろいろ募集してます!https://t.co/cc2rgT68LH pic.twitter.com/2Kly9WIuXT
2018年の時点で活用されていた…
残業圧っぽい空気は感じませんでした。残業したい人はしてるのかな? という感じです。全員きっちり8時間で帰るというわけでもないですが、だいたい決まった時間に帰る人が多い雰囲気です。 開発チームでは、残業はよくないということを周知する目的(?)で、毎月の残業時間トップの人には「残業王Tシャツ」が授与されます。
入社して1週間で見えた SmartHR の開発現場 - SmartHR Tech Blog
自ら王に志願される場合はここから買えます。よろしくお願いします。
夢、現代の麻薬取引のドラマを作っている。
今月の売上レポートを集計するAWS CodeBuildのプロジェクトをCDKで自動構築すると、どのIAMでリソースを作ったか分かってしまうので、そこから足がついてしまい、このあと控えている、ギャングの家に突入して皆殺しにして証拠を残さず立ち去るという完全犯罪が実現できない、プロットとして破綻している、ということで悩む。ブレイキング・バッドのIT版だと考えてほしい。
起きた瞬間に思ったのは、自動化が悪いわけではなくて、手動で作ってもどのアカウントで作ったリソースかは分かるので、悩む点がおかしい。
地元の売人と手を組んで麻薬カルテルを作るのも、クラウド事業者のAPIを呼び出してリソースを立てていくのも、目的通りに機能するシステム作りという点では同じだけど、後者は地味で、厳密で、ログが残り、犯罪への貢献度は低そう。ダークウェブ用のherokuとかはあるかもしれないけど、物語的な盛り上がりに欠けることには変わりない。
スマホがあればメロスが走る必要はなく、アプリでタクシーを呼べばあとは寝てていいので、デジタル化が進むと物語の質も変わっていくのだなと思った。
こないだのデザイン変更でタブが画面の左端のほうに寄って困っていたので、bodyを最大1280pxにするのを書いたところ快適になった。使いやすくはあるけど見た目は悪い。
@-moz-document url-prefix("https://github.com/") { body { max-width: 1280px; margin: 0 auto 0; } }
The problem with GitHub's new repository interface, and really most of their new pages (like notifications): tired eyes. pic.twitter.com/fT6nRJ85ZO
— Jahed (@JahedDEV) 2020年6月23日