鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

Team Geek を読み直した

先日 DevLove の勉強会「あなたが読んだ本は、きっと俺も読みたい。」に参加した*1

devlove.doorkeeper.jp

そこで紹介されていた本の中の一つに Team Geek があり、最近チームづくりに興味持っていろいろ取り組んでいるので、改めて読み直してみようと思った。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

本は発売当時に一度読んでその後は本棚に眠っていた。2013年当時は前職でやや大きめのチームを見てて、自分が技術的な詳細を知らないことをやってるサブチームも見てたので、チームづくりでいろいろ悩んでいたのだろう。そのころから現在までのいろんなことを思い返しながら読み直して、興味深い内容をたくさん見つけることができた。

読み返して印象に残った言葉たち:

  • 1.7.4 「影響を受けやすくなれば、それだけ影響を与えやすくなる。弱いところを見せれば、それだけ強い人だと思われる。」
  • 3.2.1 「伝統的なマネージャーはどうやって仕事を完了させるかを考える。リーダーは何ができるかを考える……(どうやって仕事を完了させるかはチームに考えてもらう)」
  • 3.5.2 「エンジニアが相談を持ちかけるのは、君に問題解決をしてほしいからではない。彼が問題解決をするのを手伝ってほしいからだ。そのためには、彼に質問をすればいい。」
  • 5.4.1 (許可を求めるより寛容を求める方が簡単)「勝てる見込みのある重要な争いを選択しよう。勝てない争いで資本を使い果たしても意味がない。」
  • 6.2.6 「コードを書く側の都合ではなく、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言わずにやるべきだ。」

心にしっかり留めて行動に活かしていく!

*1:Zoomでリモート参加できるようにしてくれていて、遠隔地からも参加できるのでありがたい

アウトカムを得てから深掘りするやり方

i2keyさんのブログ記事(「再発防止策はチェックリストによる目視確認」から考えるアウトカムフォーカス)を読んだ。

i2key.hateblo.jp

実利をリードタイム最短で取っていき、その後で効率化していくという話を示した図を見て、t_wadaさんのTDDの資料に出てくる黄金の回転の図

との共通点に気付いた。手段にこだわらずにとにかく動く(効果が測れる)ところまで持って行き、最適化する次のステップは価値が見えたそのあとでというあたりが。ポイントは1ステップ目をまず素早くやってしまうというところだと思うが、最適化の原則としてぎりぎりまで最適化するなということに関連して、動くものを手に入れてしっかりと対象の理解を深め、その後で最適化することでより最適な形に持っていけるという2ステップ目の成果へのメリットもあるなと思った。

実際の現場では、「動いて価値が出たんだからいいじゃん、そのままにしといて別のことやろうよ」という圧がかかってきて、2ステップ目に進めないことがありがち。1ステップ目においては動機が客観的に見てもはっきりしているのに対して、2ステップ目はそれを何故やらなければならないのか、現場の人が自信を持って説明でき、その価値を周りが認めてくれないことには切り崩されてしまうから。

自動化されたフローによる障害防止の再現性や、きれいなコードによるメンテナンスの継続性といった、もう一段上の価値を根拠として、2ステップ目をきちんと進めていける、あるいは1ステップ目を素早くやってみた結果それ以上やる価値はないからやめとこうと自律的に判断していけると良いなと思う。

まず成果を出すというゴールから始めるやり方では、こないだ会社ブログで書いた、新しい人をチームに迎え入れるときに、まずチームの一員としてアウトプットしている状態という成果を体験してもらってから、次のステップで基礎力を高めるという流れにした話とかも、類似点がありそうだ。

tech-blog.monotaro.com

OSS開発を楽しく続けてきた話を喋ってきた

DevLove関西の勉強会で、OSSへの貢献というアウトプットを継続してきた話を喋ってきました。

devlove-kansai.doorkeeper.jp

タイトルは「OSS開発を細長く続けてきた話」改め「OSS開発を楽しく続けてきた話」。

speakerdeck.com

前半では、プログラムを書けなかった中で、見よう見まねで FreeBSD ports への貢献を始めたこと、興味をもった対象について、自分に出来ることで貢献しながら学び、徐々にできることを増やしていったことを話しました。後半は仕事の中でOSS開発で学んだことをアウトプットして、業務時間でOSS開発もさせてもらえるようになった話、OSS Gateでまわりの人をOSS開発に誘っている話をしました。

緊張でろれつ回ってなかったし時間いっぱいまで使ってしまったしでさっさと降壇しようとしてたら呼び止められて、ありがたいことに質問をいくつも投げかけてもらえました。

  • コミッターになった話のあとにコード書けるようになった話があったけど、プログラミングできない状態でコミッターになれたの?
    • 本当にそうでした。Makefile書くと言っても変数の定義をいくつかするくらいなので、できちゃいました。貢献をするようになってから、ビルドエラーになったときにC言語コンパイルエラーの読み方とか学んでいったという順番でした。
    • 最初見よう見まねでできちゃって、成果をみんなに使ってもらえて嬉しい!という経験ができたのはラッキーだったと思いますが、先にアウトプットしちゃって、後追いで学んでいくというやり方もありかなと。
  • OSS Gateワークショップは何人くらい集まるの?
    • OSSの開発をしたことがない人と、経験者が同じ人数、例えば3人対3人とか5人対5人とかで参加して、ペアで作業をします。
    • 経験者と言っても、ビギナーに寄り添って一緒に考えるので、ビギナーとして参加した人が次はサポーターとして参加したり。
  • OSS開発をしていて一番嬉しかったことは?
    • うーん何だろう。
    • Emacsというエディタを気に入ってずっと使っていますが、それを開発したリチャード・ストールマンにパッチを受け入れてもらったときはめっちゃ嬉しかった。ほんの小さなパッチですが。
  • どれくらいの時間をOSS開発に使ってる?
    • 学生のころは、研究そっちのけでやっていたこともあった。学業が本職なので本当はよくない。
    • 仕事でやるようになって本業としてやるようになって本当に良かった。遊んでるわけじゃないのでお給料もらえるし。
    • その場では仕事の中での割合を答えるのを忘れていたけど、特に区別して時間をとってないので、必要に応じてというのが答え。製品開発や障害調査のクリティカルパスに乗っているならずっとOSSデバッグをしてる日もあるし、全くやってない時期もある。
    • 仕事では回避して過ごしたけど面白いなと思うOSSの不具合については、おすそ分けしてもらう感じでプライベートで解決しちゃうことも時々あります。趣味なので仕事の持ち帰りではない(気が向かなくなったらやらなくてもいい)という気持ちでやってます。

後藤さんのお話

後藤さんからは、コミュニティイベントの開催や登壇というアウトプットのお話がありました。

継続的に同じイベントに参加して周りと喋ることで、次までに自分がアップデートされていかないとコミュニケーションのネタがなくなるという形で、自分を駆り立てているという話があり、参考にして自分もやってみようと思いました。ネタ作りを意識することで日々のインプット、アウトプットが促進される。「来月どう変わっていられたら素敵か?」という問いかけもよいなと思いました!

ダイアログ

4人くらいのチームに分かれて、私のまわりでは勉強会についての話をしました。テーマをかっちり決めずに集まって、付箋にそれぞれの話したいことを書きそれぞれが書いたことを出してそれについてみんなで議論する形式は、やってみたことないので今度やってみようかな。

別のチームでは、Qiitaやブログの下書きが溜まってる話が出てたという話があったようです。自分向けメモ書きとして自分に役立てばいいやと公開してしまうようには心がけているものの、それでも供養しないといけないものがちょっとずつ溜まってしまってる…。もっと気軽に書いていこう。

越境しようとしている者達の話

devlove-kansai.doorkeeper.jp

これは聞かねばという話が並んでいたので申し込んでいたら、中村さんから「御社で会場提供できませんか」と声をかけていただき、弊社オフィスで開催。周りの人も連れて行って一緒に刺激受けてこようと、数人誘って参加しました。

"越境”の正体とはなにか? / 中村さん

  • 越境とは
  • 前提、制約を気にせず、あらゆる活動をすること
  • 目的に忠誠を誓う

私が見つけた境界線 / 橋詰さん

  • ここが境界線かも、「この先に何かありそう」と感じた
    • 既視感
    • ちょっと難しい
    • 経験者少ない
    • ちょっと面白い
  • それまでは、「技」(正しい技術、正しい開発)、「体」(正しい業務)
    • 境界線の向こうに「心」(定着化、現場へのケア)
    • あまりやっている人居ない
    • けど、既に境界の向こうにも何人か居る
      • 何か共通点がある人
      • 壁打ちさせてもらう
  • 人を相手にすることの難しさ
    • 15人くらいのチームでも難しい
    • そのあと何千人に広げないと
  • 進むには
    • 自分が折れない
    • 正しいことをする
    • 周りの意見を聞く
    • あわてない
      • 刺激と反応の間にスペースを取る
    • 前に進んでいることを確認しながら進む

私の「越境」航海図 / 神ノ倉さん

  • 若い頃、技術力が全て、組織ワーク?何それ?だった
  • 障害が起きている顧客の顧客のところに飛び込む
    • 駆けつけて全力で取り組めた
    • 会社の枠を越えた一体感が得られた
    • その後よい関係を築けた
    • 飛び込んだことについては一切怒られなかった
  • チームの話
    • どうありたいのか(to-be)をあげる、共有する
    • 日々の業務から学習できる仕組みを作る
    • タスクボード
      • 自分のDoingがたくさん
      • タスクの関係見えない
      • 人依存でタスク握ってる
    • タスクボードの改善
      • 案件ごとのレーン
      • Doingの数を制限
      • イデア試して改善の繰り返し
  • カイゼンジャーニー社内読書会
    • Zoomで複数拠点繋いで実施
    • やったあとそれぞれの気づきを共有
      • 学びの活け〆
    • 今日の発表した事も、社内の宣伝に使う→広げる
  • Trust, but Verify
    • 信頼する
    • フォローちゃんとしますよと表明

怖くない越境 - 小心者でも越境マンになれた理由 - (改) / 福本さん

  • エンジニアは修正理由全部覚えなきゃいけないと思ってた。
  • 別チームのお手伝いで GitHub, Git, アジャイルと出会う
    • 修正理由覚えなくていいんだ!
    • メインのチームにも導入したい
  • 「現状を疑う」は大切
  • 狭い範囲から、少しずつ広める
  • 新人研修やっていたら、突然の総務。
    • 2年くらい居た
    • 無邪気に五歳児の空気で問いかけ
    • 「なんでそうしてるんですか?」
  • つらいのを何とかしたい + きっかけをくれる人の存在
    • きっかけをひろう
  • やらない理由
    • 失敗したら…
    • 思考の停止
    • やってもやらなくても給料変わらないし
      • 会社の中だけ見てること自体リスク
  • 現状維持バイアス、損失回避性
    • そういうものだから、しょうがない
    • そういうこともあるよね
    • 状況がそうさせてるだけ
  • 人生は短い
  • おもむろに Evernote に価値観を書き出す
    • 自分に問いを投げる
    • 人に聞いてもらうのもおすすめ
  • 誰にでもできる、今からできる
    • きっかけを拾う
    • 時には見切りをつける

ダイアログ

みんなが出したいろんな境界からいくつかピックアップして、それを乗り越えるにはどうしたらいいかをみんなで考えました。

感想

私は話を聞くのに夢中になりすぎて会場係のことすっかり忘れてしまっていたので、他の人連れて行って正解でした。刺激たくさんもらいました!

OSS Gateでサポーターをやりながら悩んだこと

やりたいと思っていたOSS Gate社内版の2回目を楽しく開催することができました。やったー!そちらの開催レポートは他の参加者の方が書いてくれそうなので、社内外のOSS Gateで何度かサポーターをやってみて感じたこと、やる中で悩んだことについて書きます。

サポーターについて

OSS GateワークショップはOSSの開発にまだ参加したことがない人が、おすすめのやり方に沿ってやってみることでOSSへのフィードバックを実際に体験し、OSSの開発に参加したことがある状態になっちゃおうという趣旨のイベントです。

  • 主役はあくまでもOSS開発に参加したいと思ってるビギナー
  • ビギナーの側でサポートして、体験の質を高めるのがサポーター

という建て付けで開催されるので、サポーターはすごい人じゃないと出来ないと思われがちです。特に弊社内でやったワークショップの二回目の会や、最近何度かの大阪のワークショップでは、サポーターは既に過去にこのワークショップを経験したことがある人だったので、サポーター向けの説明を端折り気味になっていた気がしますが、実はサポーターに向けてもおすすめのやり方がワークショップの資料に具体的に書かれていて、実は初参加の方でもサポーターをやれるようになっているんです!

  • ビギナーと一緒に悩んであげよう
    • →これでいいのかな、と最初不安なビギナーの側で、大丈夫だよと言う
  • 自分が開発者ならこう読めると開発者視点を伝える
    • →別の人から見ると、こういう誤解をするかも、という気付きを伝えてみる
  • 自分が開発者ならこの報告をもらったらうれしい、と開発者視点を伝える
    • →受け取る側のつもりになってみて、感じたことを正直に言ってみる

例えば普段はビギナー的な立ち位置だったとしても、普段と違うロールを演じてみることで一歩先の景色を見る体験ができるよう、まわりにサポートメンターやモデレーターを配置してさらなるサポート体制が組まれているのがこのワークショップの特徴です。(さらに言えばモデレーターについても、過去の動画があるのでそれを見て具体的なやり方を知り、あとはサポーターやサポートメンターに助けてもらいながら進めることができるようになっています)

サポーターをやってて悩んだこと

端的にいうと、どこまで言うべきか、どこまで言うのを我慢するかというので毎回とても悩みます。ビギナーの体験の質を高めることのポイントとして、

  • とにかくやってみよう
  • 自分でできたという実感を持とう

ということがあります。その場でOSSの開発に参加出来たとしても、今日はサポーターが居たからできた、明日からはサポーターが居ないから出来ないだと、このワークショップの期待値を十分に満たせてないことになります。なので、

  • 転ぶ前に手を差し伸べるのでなく、行けるところまでは自由にさせてみる
  • サポーターが答えだと思うことを教えるのではなく、ビギナーが自分で考えて自分で気付くよう仕向ける

といったことを意識するのですが、時間が限られていることの焦りから、ついつい手を出しすぎてしまっていることが多いなと反省してます。

直近の社内ワークショップで実際にあったこととしては、ビギナーが選んだドキュメントへのフィードバック内容を聞いて、

  • 読み方の問題で、今の書き方で問題ないんじゃないのかなぁ
  • でも、フィードバックを体験するなら、そのまま進めるべきなのかなぁ

の葛藤の末、ビギナーが「OSSを動かす」のフェーズで体験したことを

  • 手順の通り進めてみる
  • ひっかかってエラーメッセージを読む
  • 手順の注釈とエラーメッセージを見比べて解決方法がわかる

の流れで再現してもらって、既に一度やってることとはいえそれほど困らずに解決できたのを見れたので、「そこまで困らなかったんじゃないですか?ドキュメントの記述がよいから困らなかったのでは?」という問いかけをして、別のフィードバックポイントがあるなら違う方で進めるのがいいかもと結局言っちゃいました。

幸いもう一つ見つけていたフィードバックポイントは客観的に見てドキュメントに不親切な点があると思えたのでそちらで進めて、結局時間内にフィードバック送信までは行けなかったのですが、ワークショップの直後にビギナーが自身でIssueを投稿されてた(自分の力でフィードバックできた!)ので、時間切れになったのも含めて素晴らしい結果に繋がりました!

というわけで

私はサポーターの立場でOSS Gateワークショップに何度か参加していますが、自信に満ち溢れた状態でやっているわけではなく、常に悩みながら参加して、悩みの中からいろんな学びを得ています。いい経験になっているので、これまでサポーターとして参加したことない人もやってみるといいと思います。オススメですよ!

個人のタスクマネジメントについて見直してみた

個人のタスク管理について、自分のやり方よりももっといいやり方がないか、DevLove関西の勉強会に参加して考え直す機会を作りました。

devlove-kansai.doorkeeper.jp

これまで

これまでに使ってきたツールで覚えているのは

  • Remember The Milk
  • PCに付箋
    • 前職でやってた自分用タスクボード
    • 会社の机の上のPC本体(ケース)の側面を利用
    • ふせんにタスク書いて貼る、やったら剥がす
    • いっぱいになってきたら棚卸し。
      • やらなくていいものを選んで剥がす
      • 自分でやらなくていいものはまわりの誰かに振る
      • 他の人に振ったものは剥がす(チームのタスク管理ツールでは管理されてる)
  • Any.do
    • 仕事のこともプライベートのこともごちゃまぜで放り込んでた
    • Androidスマホでアプリも使っていた気がする。
    • やること書き出して、やったら消すというのがさくさくできてよかった
    • ふりかえりをうまく組み込めなくてやめた
  • Evernote
    • 日毎にノートを作って仕事のその日やることを列挙してた
    • プライベートのことは発生したときに別のノートに書いていた
    • 「○○の対応3件おわらせる」とか、ざっくり書いてるものもあった
    • 何をやったかふりかえりができるようにこのやり方始めたけど、ふりかえりがどれくらい出来てたかは不明
    • 個々のタスクをやれたかどうかは記録してなかった
    • Trelloがいいという話を聞いて乗り換えてやめた△
  • Trello
    • 仕事のことを書くボード、プライベートの勉強のことと家のことなどを書くボードの二枚
    • やりたいことのレーンがどんどん増えていくけど動かないのが辛かった記憶が少しある
      • 大きめのものを分割する機会を持ててなかったのが敗因?
    • 流行りに乗って始めたが、うまく使いこなせないままやめちゃった気がするがあまり憶えてない△
  • 無印のA6ノート ← いまここ
    • タスクリストに書いてるのは仕事のこと
    • 一日で見開きの2ページを使って、左にタスクリスト、右にメモ書き
    • 朝の電車でその日やることと見積もり時間(分)を書き出す
    • 一個のタスクは長くても1時間以内で終わるくらいのサイズで
    • 業務時間の6-7割くらいを目安に、超えてたらやりきれないので削る
    • 帰りの電車で、出来たことにチェック、仕掛り中のことに△、手付かずに×
    • 金曜の終わりに週報書く時に一週間でやったことふりかえるのに見てる
    • 同じノートに社外勉強会行ったときのメモなんかも書いてる

今のやり方のふりかえり

うまくいってる

  • 通勤に合わせて一日の計画、一日のふりかえりが習慣化できてる
  • 週報をトリガに週の終わりにやったことのふりかえりができてる
  • 日単位で無理がないように作業計画できてる
  • タスク管理の粒度を決めるのに、チームのタスク管理方法の影響を受けない
  • チームのタスク管理ツールを補完できればいいやくらいの感じでゆるく継続できてる
  • 計画したのに仕掛中だったり手付かずだったことが見える

課題

  • 一日より大きい単位での個人タスクの計画ができていない
    • チームのタスクとしては週次で計画してる
    • ちょっと先にやることは個別でGoogle Calendarカレンダーに入れてるものもある
      • 日が決まってないものは見直すくらいの日に
  • そのうちやりたいことのメモがあちこちに散らばっている
    • Inbox のリマインダー、Evernote
    • 棚卸しできてない
  • ブログやQiitaの下書きが放置されて賞味期限切れになりがち
  • 仕事以外のタスクのふりかえりができていない

やってみる

  • 仕事のタスクについてはまぁまぁうまくいってるので今のやり方で継続
  • 仕事以外のタスク、仕事になる前の構想段階のタスクについて、別のツールを試してみる
    • 一箇所にまとめて、棚卸しとふりかえりをしたい
    • Trello をもう一度試してみようかなと思ってる
      • 前も流行りに乗ったけど結局やめちゃったので、やり方少し考えてから

勉強会での気付き

前は個人タスクの管理だからと人に聞いたりせずに一人で考えてたけど、今回の勉強会に出て、他の人もいろいろ試行錯誤してるんだな、他の人に聞いてみたら解決できることもありそうと感じたので、困ったらまわりの人に相談してようと思った。

タスク管理するときに、

  1. やらなくていいのでは?
  2. 自分でやらなくていいのでは?
  3. もっと楽にできるのでは?

の順で考えるがよいと中村さんが言ってたのは、これまでも意識はしてるつもりだったけど改めて意識しようと思った。下に行くほどやる前に考えないといけないことが増えるので、タスクを整理しようというタスクで押しつぶされないように。

Python のコマンドライン引数

要約

  • python module.py arg1 arg2 ...
  • python -m module arg1 arg2 ...
  • python -c script_str arg1 arg2 ...

のいずれの方法で実行した場合にも sys.argv[1:] には [arg1, arg2, ...] が格納される

シェル芸勉強会の課題

techplay.jp

シェル芸勉強会が開催されていたのですが参加できなかったので、Twitter に流れてきた問題を解いてみました。

seq は 1 から指定した数までインクリメントしながら一行ずつ出力します

$ seq 10
1
2
3
4
5
6
7
8
9
10

この出力を xargs に食わせると

$ seq 10|xargs echo
1 2 3 4 5 6 7 8 9 10

のようにコマンドライン引数にできるので、

$ seq 10|xargs python -c "import sys;print(sys.argv)"
['-c', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']

のようにすれば Python にリストを受け渡せることがわかります。あとは argv[1:] を int にして足せばいいので

で解くことができました。

理解不足

解けはしたものの、一晩明けて何か引っかかる気がしたので見直してみると、'-c' が先頭の引数になってるけどその後に与えたスクリプト文字列 "import sys;print(sys.argv)" はどこへいったのか、全然理解できてないじゃないかということに気付きました。

試しに他のやり方で同じ内容の処理を実行するとどうなるか見てみると

~/argv-test$ cat sum.py
import sys
print(sys.argv)
~/argv-test$ seq 10|xargs python sum.py
['sum.py', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']
~/argv-test$ seq 10|xargs python -m sum
['/Users/yoichi/argv-test/sum.py', '1', '2', '3', '4', '5', '6', '7', '8', '9', '10']

いずれのやり方でも、xargs 経由で与えた引数は2要素目以降に入っています。

公式ドキュメント https://docs.python.jp/3/library/sys.html#sys.argv を参照すると、

Pythonスクリプトに渡されたコマンドライン引数のリスト。 argv[0] はスクリプトの名前となりますが、
フルパス名かどうかは、OSによって異なります。コマンドライン引数に -c を付けて Pythonを起動した
場合、 argv[0] は文字列 '-c' となります。スクリプト名なしでPythonを起動した場合、 argv[0] は
空文字列になります。

とその仕様について書かれていました。スクリプトの実行方法に依らずに argv[1:] でコマンドライン引数が取れるよう、この仕様になっているのだと思います。

実装確認

"-c", "-m" を指定した場合の動作を CPython の実装で確認しました。

  • Modules/main.c の Py_Main() で "-c" あるいは "-m" を argv[0] として PySys_SetArgv() に渡しており、Python/sysmodule.c では一旦そのまま sys.argv に格納している。
  • "-m" が指定されていたときには続いて Modules/main.c の RunModule() が呼ばれ、 runpy.py の _run_module_as_main() を実行し、そこで sys.argv[0] が上書きされる。