Lean Baseball

No Engineering, No Baseball.

創造的なエンジニアリングにはザッソウが必要だ - 先達の方々と岩田さんからの学び

「エンジニアリング」って書いちゃいましたが, クリエイティブな仕事全般に活きる話かなと.*1

このエントリーでは,

  • 創造的な活動にはザッソウは大切すぎるぐらい大切(語彙力)
  • でも, 個人の戦闘力も磨くの大事.「独学プログラマー」にいいこと書いてるので必読やぞ
  • 岩田さんをはじめ, 先達の方々もザッソウされてる

という件についてあれこれ言いたいと思います(これがそのままTL;DRです).

f:id:shinyorke:20190925200407j:plain
ザッソウは大切です, あと毛ガニも

なお,毛ガニは関係ありません.*2

おしながき

創造的なエンジニアリングにはザッソウがよく効く

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

ザッソウ 結果を出すチームの習慣 ホウレンソウに代わる「雑談+相談」

(このブログで何回も取り上げてる気がしますが)私は倉貫本の追っかけでして, と.

以前のエントリーにて所感を書いた「管理ゼロで成果はあがる」の中で上がっていた「ザッソウ」にフォーカスされた本が出たので早速読みました.

感想は一言でいうと,

創造的・クリエイティブに楽しみながらエンジニアリングしたい人は必読やぞ!

「エンジニアリング」の部分は各々の職業に読み替えて頂いてかまわないかなと(むしろ色々当てはめると良いかも).

ほんと, 素晴らしい書籍でした.

「ハマる」エンジニアリングは「ザッソウ」の出番が連続する

自分の職業・商売がエンジニアなのでこの先はエンジニアリング前提の感想ということで.

新しいアプリ・プロダクトを作ったり, 既存のアプリを保守運用したりetc...エンジニアリングをしていると,

  • よくわかんないバグに出会って「ハマる」
  • 初めて使うライブラリ・フレームワークをチュートリアル通りにやってもうまく行かず「ハマる」
  • 一生懸命, データをお掃除(クレンジング・前処理)したり集計しても数字が想定している範囲にスケールせず「ハマる」

というようなことが毎日毎時, 息を吸うように私も皆さんもお付き合いしていると思います.

ちょっと見回したら解決することもあれば, 丸一日画面とにらめっこしても解決しないときもあったりするかと思いますが,

  • 誰か(同僚なり友達なり)に「いやーハマってさ...」って話をしているうちに何か思いつく
  • 思いついたやつを「もしかして」...と思い, 試す→解決!

ていう解決パターンが個人的には多い, いやもっと言うと基本的にハマってないと雑談しないのでそういう感じなのですが,

誰かに相談していたら、なんのアドバイスももらってないのに自己解決できた、という経験はないでしょうか。

(中略)

こんな風に自分勝手に話しているうちに自己解決することを「テディベア効果」と呼びます。

※「ザッソウ」第二部より引用

(本には明記されてませんでしたが)これはペアプログラミング転じて「ベアプログラミング」と言うらしく*3,「ああ,僕がやっていたやり方(原点は知らなかった)に間違いはなかったんだなあと妙に納得・腹落ちしました.

職場でもコミュニティでも「ザッソウ」を

なるほど?ザッソウの効果は見えそうだ!でも...

  • どうやったらザッソウがうまくできるのか?
  • 雑談って仕事中しにくいんじゃない?
  • どうやったらそういうチームを作れるのか!?

...というのが出てくると思います.

これについては書籍の内容に譲るとして(≒このエントリーの趣旨的には外れるので触れません*4),

個人的には「ザッソウ」の相手は職場にもコミュニティにもいるよ!作れるよ!!

っていう提案(というか実践してること)を声高に言いたいですと.

自分のザッソウはよく,

  • Slackのtimesチャンネルでつぶやく
  • (機密性とかを排除の上)Twitterでつぶやく
  • 職場の同僚だけでなく, もくもく会やイベントでリアルに声を上げる.「お客様の中で, AWSに詳しい人はいませんかー!」的な.

というところから始まることが多くて, だいたいそれはうまく行っています.

別にピンポイントでその課題の答えを求めなくても,

  • 自分の手元で起こってることを説明しなきゃ
  • 説明のために脳内で整理整頓して話し出す
  • 話してる途中に「あっ(察し」ってなる

ような事が多く, 先程の「ベアプログラミング」的な効果の恩恵を十分にうけています.

という経験から,

別に無理して職場内で「文化」「心理的安全性」を作らなくても,部分的にはコミュニティなり人繋がりで解決するんじゃね😜

と気がついてしまったので最近は,

  • 業務上の秘密・NDAに当たるものは職場内でザッソウ
  • 普遍的なノウハウ・スキル(例:Pythonの標準ライブラリの仕様, DBAのパラメーターetc...)は信頼できる友達・元同僚に
  • もうちょっとパブリックにしていいやつはいっそツイートする(ただし仕事の話は別)

という感じにしています.

本に書いてるノウハウ・思想とはちょっと異なりますが, そんなザッソウもあるんじゃないかなと思っています.

なお,「ザッソウ」だけじゃアカン! - 独学も大切

...とまあ, ザッソウは大切でとにかくやるといいよ!というのもありますが!?

エンジニアリングは言うても「創造的」かつ「職人的」な商売なので, 腕磨きも大切やで!

という本音もあります.

  • 扱ってるモノの技術・使い方知らないと適切に言語化できないし*5
  • そもそもなぜそのフレームワーク使うの?設計思想は!?的なのも抑えたほうがより言語化が洗練されるし*6

ってありますよねーって思ったら、名著「独学プログラマー」の後半(第27賞)にそんなモヤモヤに答える処方箋ありました.

  • 本質を探る努力をする.コミュニティの掲示板・チャット(Slack)等で質問・議論する, 自分で作ってみる, etc...
  • アドバイスを得る. プログラミング以外のこと, 例えば他の人のコードをたくさん読む.時間をかけて読む.

チームやコミュニティでザッソウをしながら少しずつこういうのをやっていくとより磨かれると思います(し自分もちょびっとやっています).*7

独学プログラマー Python言語の基本から仕事のやり方まで

独学プログラマー Python言語の基本から仕事のやり方まで

岩田さんのクリエイティブから学ぶ

と, 本来はこのエントリー「ザッソウ」本の感想で終わる予定でしたが, 帰省中に読んだ「岩田さん」がめちゃ良かったのと, ザッソウ文脈でも面白かったのでちょこっとポエムさせていただければと.

岩田さん 岩田聡はこんなことを話していた。

岩田さん 岩田聡はこんなことを話していた。

岩田さんと宮本さん(もしくは糸井重里さん)とのコミュニケーションが生んだ様々なクリエイティブな出来事と学びが面白くてですね,

アイディアというのは、複数の問題を一気に解決するものである

という「複数ISSUEをいい感じにまとめるのがアイディアだよ」っていうのは目からウロコでしたし,

仕様を決めるときに、ほんとうに大事なことは、

「なにを足すか」じゃなくて、

「なにを捨てるか」

「なにをやらないと決めるか」

だということをすごく実感しました。

というのはまさにISSUE駆動, Leanな考え方・動き方だったりするのですが.

これも結局の所岩田さんを中心とした「ザッソウ」で決まっていって素晴らしいゲーム・コンテンツが生み出されたのかなあ?

と思うと結構胸アツでした.

自分はもっとエンジニアとして腕を磨きたいし何よりも使う人達に価値を出していければと思っています.

たまにはこうした先達の方々からの学びを元に, 振り返るのも大切ですね!というのをこのエントリーのオチにしたいと思います.

ちなみに,ザッソウ岩田さん独学プログラマーもサクッと読めると思います, 秋の夜長にぜひ.

*1:エンジニア(駆け出しさん含む)とデータサイエンティスト(駆け出しさん含む)にご愛顧頂いてるブログなのでそんなタイトルってだけです.デザイナーでも職人でも誰でも参考になると思う.

*2:飲みながら読書はよくやるのですが,その効能となぜについてはnoteのこのエントリーを御覧ください.

*3:ぬいぐるみ(テディベア)に話しかけてる内にいい感じに脳内整理・デフラグされて解決する効果を求めてやるらしい.ぬいぐるみって偉大だ.

*4:心理的安全性がどうこうとか, ティール組織との関係は!?的なのは本そのものや倉貫さんのブログ, その他イベントなり勉強会なりで学ぶといいでしょう.

*5:「あのスーパーなエンジニアならなんでも知ってそう,ひとまず話を振るか」的に考えてやる「ザッソウ」はもはや単なる丸投げでザッソウとは呼ばない

*6:Webやるならどの言語が!?Ruby On RailsとDjangoどっちがイケてる!?みたいなのは言語・FWの思想も知らないでハナシてるのか!感ありますよね?そういうことやぞ

*7:モブ的にチームで解決したり,心理的安全性を構築しながら醸成させるのも良いですが, クリエイティブな所に行くのってなんやかんやで最後は自分の腕って大切になってくるので投資は重要です.まじで.