辛かったこと口頭で伝えるのむずいコード書けたら早いんですけどね。うまく説明できませんでした。事前に設計するなりして認識が揃っていると違うのかも。今回は事前設計なんてなかったので、説明が難しかった。初対面な人たちの集まりなわけで、お互いのことは全く知りません。その中でチーム作業をするので、結構お互いに気を使って進んでいきました。参加しているわけですし、どうしたらみんながやりやすいかな?というのが気になってしまって、コーディングに全然集中できなかった感覚が残りました。これって生産性あがってるのか?TDDで難しいことが、より大きな問題として影響してきた気がするうちのチームはTDDで進めました。TDDってテストのstepをどう刻むかって結構難しいというか感覚が大事な気がします。TDDでのstepは、自分の感覚で、自分が自信をもって進められる幅で進めていこうということだったはずなので。モブに当てはめると、モブが自信をもって進められる幅ってことなんだろうけど、他の人たちの力量もわからなかったので、なんか数倍難しい気がします。その結果、細かくしすぎて必要以上にテスト書くような形になった気がしたし、時間が無駄にかかった感覚を受けました。なんかちがうなーこれ。あと、リファクタへの意識が低かったので、ひたすらアドホックに機能を継ぎ足してコード書くような状況になってしまったのもよくなかったです。TDDはテスト先に書いたらTDDなわけじゃなくて、Red=>Green=>Refactorといサイクルを回すものなのですが、そこが意識できなかった。テスト通ったらみんなで逐一拍手してたんですが、テストじゃなくてRefactorが終わったら拍手するサイクルのほうがいいのかも。拍手したらリズム止まって、じゃあ次何テストしようかってなるので。いやいやなんか設計おかしいぞこれ。思っている人も結構いたと思うけど。メンバーの一人が、そもそも設計これ見直しましょうよって流れぶったぎって言ってくれるまで、変な方向にひたすら進んでいた気がします。なんか設計変だなー変な方向に行っちゃってるなーという感じがあったのですが、強く言い出せず。会話のなかで方針転換するにはどんな発言をすればいいんだろう。いうことをずっと考えていたので、疲れました。考えたこと解くべき問題によってはモブプロはそもそも合わない説2セッション目はちょっと挑戦であまりみんなが触ったことのない言語を選択しました。するとコンパイルがそもそも通らないよーどうやったら通るんだーという状態に。コンパイルを通すための方法って一意に決まるわけで、そのタイプの問題を解くためにはモブプロはあまり合わないのでは?と感じました。いうのも、各々が平行して調べて、各々の環境で試して、うまくいったらその人の方法を採用すれば事足りるわけです。これに対してモブで進めていくことに利点があるとは思えませんでした。使ったことないライブラリーの理解とか、そんなのもモブでやるよりは各々で試すほうが良いのではないかな?どうなんだろう。逆に、実現方法はいくらでもあって、その中からどれを選択するか?といった課題であれば向いているのかもしれません。1セッション目にチャレンジしたFizzBuzzもそういう意味ではみんな頭の中に大体実装あるでしょうし、向いていなかったのかも。ブレストとモブプロは似てるけど正反対のものなんじゃないか説ブレストは意見が出やすいように、人の意見を否定するの禁止というグランドルールで行われることが多いですよね。僕はブレストいっぱいやってきているので、そっちで育ってきたわけです。モブプロはそれでいいのだろうか?という疑問が。意見をぶつけ合うなかで良いものにしていくのが必要なのかもと感じました。ブレストみたいに、その意見もいいねーいいねーだとうまくいかないです。コードがカオスになる。そもそもブレストでは、発言しにくくならないようにという配慮で、意見の否定は禁止していたりします。モブプロでは意見の対立を認めないといけないのかも。そのうえで、対立があっても発言し続けないと、モブの人はバリューが出せません。このためには、あくまでコードの否定であり人格否定ではないんだようという、1段階成熟したメンタルモデルが各々に必要になると思いました。全員初対面でこれをやるのはちょっとつらいわ。いうか、普段会社のメンバーでじゃあそれできるの?と言われると、すぐには自信ないです。リーダー的な役割必要なのかも?意思決定が難しかったので、リーダー的な役割はあってもいいのかもと思いました。なんかお互いに遠慮しあってしまう雰囲気があり、なかなか物事決まらなかったんですよねーなんか。思います?的なやりとりが結構多くなってしまった印象でした。エディタとインタフェース各自の端末でできるようにしたほうが絶対良い。今後の展望テーマをもうちょっと考えて、普段一緒に働いているメンバーでモブやってみたいなと思いました。あと、できたらモブが成功しているチームに見学とか行きたい。現状では上手くいくイメージがなかなかできていない。NDL関西に参加した話イベントレポート地域課題解決を目的としたオープンデータの利活用を目的として、自治体が企画するコンテストであるアーバンデータチャレンジ2019への応募を目指したイベントである、アーバンデータチャレンジ京都に参加してきた。2019/11/9に1日かかりでアイディアソンを実施し、2019/12/7にハッカソンが実施されるスケジュール。アイディアソン終了後のハッカソン開催日までの1カ月間は好きに開発すすめてくださいねーという感じのイベントだった。ハッカソンでは各チームが色々と事前準備をしてきていたので、最終的なアウトプットはどのチームもすごかった。アイディアソンの様子。NDLラボうちのチームのピッチ。https://lab.ndl.go.jp/dataset/UDC2019/ideathon1_MyPlace.pdfうちのチームはWebアプリを作った。今期の個人的な目標として、なんしかモノとしてアウトプットするところまでもっていきたいというものがあり、取り組むテーマを探していたところ、たまたま見つけた。なんか一人で参加するのいややなーと思っていたので誰か誘ってみようと思った。普段から仲の良い同僚から勉強したいけど何作ったらいいかわからず手が止まってしまうという相談を受けていたこともあり、ちょうどいいかもということで誘って3人で参加した。アイディアソンまずは自治体が提供しているオープンデータの説明があった。いろんな種類があって正直すべてを覚えてはいないけど、国会図書館ということもあってかなり興味深いデータがあることがわかった。これらのデータを活用してどんな地域課題が解決できるか?をブレストしてアイディアだしし、出てきたアイディアをクラスタリングして、各クラスタに興味のある人たちがあつまってチームを形成した。チームに分かれてからはチームごとにアイディアをブラッシュアップして、ハッカソンで作るべきものの青写真を作った。ハッカソンまでの過ごし方もともと開発の勉強がしたいというモチベーションで集まった3人なので、ハッカソン当日までに集まって開発をすすめた。普段の業務では一人チームで開発しているので、チーム開発ができたことが個人的には凄く楽しかった。全体的な足回り(インフラ系とか開発環境とか)の整備とPythonでのWebAPI提供を主担当し、Angularでの画面開発なんかも行った。チーム3人で開発の勉強がしたいということで合意できていたので、成果物を追い求めるというよりは、技術的な解説や不明点の深堀など、知識習得に重きを置いて進めることができた。学びペアプロするうえでは大きいモニタが必須。airでは限界がある。説明することで学びが深まるので、良い機会だった。普段の業務でもチーム開発がしたくなった。今回は開発を学びたいという目的でチームが合意できていたが、ペアプロを進めるうえでは方向性を合意しておくことは大事かもしれない。細かいことは置いといて開発進めようぜ!ってならなくて良かった。ここの認識があっていないとチームがギスギスしたりするのかな?と思った。学びが目的であったが、それでも最後のほうはモノとして整えるために急ぐことになった。余裕をもって進められたよかったなぁと反省。これによって最後のほうは全員が全員理解して進める構造にならないケースがあった気がする。他のチームのアイディアや実装はかなりユニークなものもあり、もっともっと発想を飛ばせるといいなぁと思った。プロジェクトの進捗があまり出せていない。モチベーションが若干下がってしまっている気がする。目標達成とかそういう系統の本をまとめて3冊ほど読んでみた。テーマを固めて一気読みするのはかなり良いかもしれない。【成し遂げる力】では、行動を3つに分類している。やってしまうような行動を「衝動行動」、その他を「一般行動」が3つ。【9つの習慣】は衝動行動と一般行動を対象としたイメージで、【成し遂げる力】は3つそれぞれを対象としている。【時間術大全】は他の二冊と比べると日々の実務よりで、tips集に近い。3冊はそれぞれ根本にあるのは似たような考え方に感じる。【成し遂げる力】より【9つの習慣】の方が圧倒的に読みやすくはあるので、【9つの習慣】を読んで実践しつつ、日々の行動のサポートとして【時間術大全】を使うようなイメージが良いと思う。【成し遂げる力】の方がより広い領域を扱っている印象を持った。実例が豊富なので、実例を得たいならおすすめ。個人的にはちょっと実例が多すぎた。どちらも目標を具体的にすることの大切さを説いている。曖昧な目標ではなく具体的にすることが大事。【9つの習慣】ではあまり理由づけがなかったが、【成し遂げる力】を読むとリンクする部分が多く納得感が得られるかもしれない。目標を具体的にしておくことで、実現可能な「十分に小さい」タスクに切り分けることができる。トップダウンでタスクを小さくしておくことでロードマップが引かれるので、実施に際して簡単な状態(実施時に複雑なことを考えなくてもタスクを倒せばいい)にできるのが大きな効果。これによって成し遂げられる確率が高まる。具体的な目標に落としていく際に注意が必要なのが「人はどんなサイズの目標に対しても3〜10個のtodoしか思いつけない」ということ。目標を具体化する際には【成し遂げる力】の梯子モデルを取り入れてタスク化していくことが大事だと思った。【9つの習慣】ではif-thenプランニングが紹介されているが、これも【成し遂げる力】で「簡単な状態を保つことが成し遂げるために役立つ」という点とリンクするだろう。ルーチン化された行動は継続が簡単になるし、if-thenの形で行動をあらかじめ決めておいて自動で実行できるような仕組みが目標達成には好ましいんだと思う。意志力を使った方法はどちらの本でも否定されている。意志力を使わなくても実現できるようにしておくことが継続のためには重要。達成するためにはその対象を「魅力的」に感じていることも大切。重要なことであり価値があることだと信じることができると良い。この具体的な方法は【9つの習慣】にはないので【成し遂げる力】を参考にすると良いのかもしれない。脳の可塑性周りの話はどちらでも出てきた。固定化された知性ではなく、知性は大人になってからも変わるというマインドセットをもって、成長することを大事なことと捉えるのが大切な習慣なのかも。時間術大全ここまでで作ったタスクをその日の「ハイライト」として日々倒していく。なんの戦略もなく日々を過ごすと、せっかく作ったタスクを進める時間が取れない。これを防ぐために【時間術大全】を参考に、時間を作る。意志力に頼って集中しようとするのは難しい。物事は簡単な方が良い。気を散らすものはそもそも消してしまおうといったことで、「レーザー」の章が参考になる。体調が悪い中で意志力に頼って集中しようとしても難しい。集中できる体調を保つために「チャージ」の章も参考になる。ここで言われていることは【最高の体調】という本で言われていることとも繋がっている。人の進化の過程に生活を合わせ直そうというような趣旨。ここに興味があれば【最高の体調】を読むことをお勧めします。最後の「チューニング」の章は自身へのフィードバックについてのお話。時間術としていろんな取り組みを実験して、その結果を振り返って次の実験内容を考えるようなものになっている。このフィードバックのタイミングで【9つの習慣】で述べられていた「目標との距離をフィードバックする」を取り入れても良いのかもしれない。ある程度テーマを固めた上で何冊か読んでみる取り組みは結構色々考えるきっかけにもなるし良いかもしれないなぁ。12:34最近個人プロジェクトの進捗があまり出せていない。モチベーションが若干下がってしまっている気がする。...Tweet広告を非表示にするもっと読むコメントを書く2019-02-13自分の小さな箱から脱出する方法の読書メモ自分の小さな箱から脱出する方法を読んだ。見るビジネス書図鑑で紹介されていた書籍で、特に他人を責めがちな考え方に毒されている自分がいるなぁと思っていた問題意識に刺さりそうだな?と感じたので読んでみた。いい意味で自己啓発的な本だった。この本を読むという体験を通して「他責思考」から抜け出すためのヒントが得られるし、(詳細は後述するが)抜け出すためのきっかけの一つになる。一言で?「こうしたほうが相手のためになる」という自分の考えを裏切ったことで、それを正当化する思考が働き、世界を見る目が曇る。この状態を「箱に入った状態」と呼ぶ。相手も自分もこの状態になっていると、それぞれが自己正当化の目線で相手を見るので、人間関係がドツボにハマる。これがチーム単位になり、会社単位になってくると、チームや会社の目標達成の大きな阻害要因になる。箱から出るには、箱から出られている状態の時に、自己反省をして、相手を自分と同じく尊重すべき存在であると認識し直す。箱から出た状態を維持するためには、相手のためにするべきだと思ったことは素直に実践し、自分の考えを裏切らないように留意する。箱に入るメカニズム「相手のために〇〇してあげなくちゃ」と思った際に、それを裏切ると、それをしなかったことへの正当化が自分の中で起きる。相手の欠点を考え始めて、「だから別に〇〇してあげる必要なんてないんだ!」と考えるようになる。相手の欠点を深掘りし、「むしろこっちが被害者だわ。」と考えるようになる。自分の良いところを過剰に評価して、自分を正当化しまくる。このとき作成された箱は別の状況下でも持ち出されるようになる。箱が強化されるメカニズム相手が箱に入って自己防衛してくると、こちらも自己防衛のために箱に入るようになる。箱の中は自分が正当化される心地よい空間である。相手が自己防衛のための攻撃をしてくると、それを受けてさらに自己正当化がおこなわれ、心地よい箱の中がより心地よい空間として強固なものになる。一種の共犯関係みたいなもの。箱は原理的に強化されやすいっぽい。箱から出るためには?外に居続けるには?箱に入ってる状態ではぶっちゃけ何しても基本ダメ。どんな人でも常に箱に入っている状態ではないので、箱から出ている状況の時に、自身を見つめ直し、自己反省することが大事。それによって相手を「自分と同様に尊重されるべき個なんだ」と思えるようになると箱から出られる。ついて物語形式で進んでいく。通常の知識本とは異なり、整理されて書かれているというよりは、登場人物の学びを通して理解していくようなスタイルであり、本書の内容的にはそれがしっくりくると感じた。箱から出るための方法として「箱から出た状態にある時に自己反省をする」というものがあげられているが、本書を通じてこの体験ができるように物語形式にしていると感じた。普段の人間関係の中で、しがらみがある中で、箱から出た状態を意識的に作り、その際に自己反省をするというのは至難の技であると感じる。箱から出た状態の人間関係にいる際に、そうではない相手のことを考えたりすることはあまりないし、考えたとしても自己反省をするという発想にまずならない。箱から出た状態の人間関係にいる際に、その相手から、そうではない相手のことを考えて自己反省するように促されれば別だが、あいにくそんなことをしてくれる知り合いもいないし、正しく理解させてくれないとその相手に対しても箱に入ってしまいそうだ。その点本書はわかりやすく解説してくれているし、最悪本を閉じればその後の人間関係に影響はない。本書に対して箱の外にいることができるなら、箱の外にいる状態で自己反省をするということが果たされるわけで、とても得難い機会になると思った。余談だが、免疫マップの考え方とも近しいものを感じた。箱を強化したい・自己正当化したいという裏目的を達成するために、相手をより攻撃的にしてしまうなどはまさにそれ。本書は自己反省を経て相手を尊重すべきだという考えてこれを解消することを主張しているわけだが、これも裏目的の先入観を解消することで解決する免疫マップの考え方に近いと感じた。冬休みを活用して「なぜ人と組織は変われれないのか」を読んだ。免疫マップについて解説している本として有名(?)な本。年末年始は扁桃炎で瀕死で実家に帰れなかったので、自宅にて冬休みの3日間をかけて読みました。一言で目標達成できないことを、意志力の欠如や能力不足や努力不足などと捉えずに、対立する別の目標を達成するための合理的な手段であると主張している。このうえで目標を達成するためには、別の目標を支える固定観念を明らかにして、それを検証して必要に応じて修正していく必要がある。この作業を行うためのものが免疫マップである。これを作る作業によって目標達成のみならず、主体的に捉えていた固定観念を客体的に捉えることができるようになるので、知性の発達のきっかけが得られる。感想400ページを超える大作で読み切れるか不安だったが、読み始めたら問題提起が面白くて、一気に読み進めてしまった。目標達成できなかった時の無能感というか失敗感は誰でも味わったことがあると思うが、この本は目標達成できなかったことを合理的なこととして捉え、これを乗り越えるためにどうしたら良いか?を豊富な事例とともに説明してくれる。若干、事例がしつこい感はあった。したらいいの?どうやったらその免疫マップ作れるの?」と思いながら読み進める展開は、ヒキはあったけど、分量がかなり多いのでちょっと。チーム内で免疫マップを実践することで最大の効果が得られるような感じではあるが、自分の周りでこれを実践できるかどうかはちょっと自身がない。免疫マップを作る取り組みはかなりのレベルで自己開示が要求される。これを抵抗なく実施できる状況に自分はないなぁと感じた。チームでの実践は見おくりつつ、個人的な目標達成について考える際には免疫マップを作ってみようと思う。免疫マップが向いている目標と向いていない目標というのもあり、資格取得しようといったような目標とは親和性が低いと感じる。どちらかといえば習慣的な目標達成についてどうしてもうまくいかない場合に免疫マップを作ってみると良いかもしれない。自分の場合は筋トレを継続することがなかなかできていないので、筋トレ継続について免疫マップを作り、免疫を克服するように頑張ることでこの効果を実感できるかもしれないと思った。読書しながらマインドマップを作った。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。