チーム運営について調べてみたいこと
先日、2年ほどいてくれたメンバーがチームから離れた。
今のチームは、比較的人の入れ替わりが激しく、自分も含めて3年以上チームにいる人がいない。
前職で初めて参加したチームはかれこれ8年ほど同じチームに在籍し、ほかのメンバーも同程度の期間いた。阿吽の呼吸のようなもので成り立つ部分も多かった。
特段悩んでいるわけでもないのだけど、メンバーが頻繁に入れ替わる前提でのチーム運営のコツみたいなものが気になり、ふと「高校サッカーの監督は、3年というサイクル前提で考えているからノウハウがあるのでは？」と思い簡単に記しておく。
少しずつ時間作って高校サッカーの監督の本を読んでみようかな。
青森山田高校
静岡学園
中央学院高校
国見高校
他にも調べたらたくさん出てきそう。
これらの中で「3年」というサイクルを意識して運営しているようなものがどのくらいあるかかなぁ。
いかにチームの文化・色を残しつつ、新しく入ってくる色を消さずに溶け込ませるか？という視点で気になっている。
Djangoはじめました（2020年6月）
はじめに
前々からいつかやってみたいなと思っていたDjangoに触れる機会ができたので、やってみた感想を書いてみる。この記事の目的や対象読者が誰なんだというのはあるのだけど、無理やり書いてみると
・Djangoに興味はあるけど、なんとなく触ってない人
が
・触ってみるキッカケになる
くらいかと。
思ってたより簡単に形になるな、という面と、調べ始めると色々と複雑なものがでてきそうだな、というのが今時点の感想。
※以下、「この業界に何年いるんだよ」みたいな年齢なのに、プログラム初めて触ってみましたみたいな感想文になってしまった・・・
自分のバックグラウンド
どの程度の基礎知識のうえでやったんねん、というのがあるかと思い書いてみる。
- 数年、業務で開発に携わることはないくらいに開発からは遠ざかっている
- Pythonはちょっとしたツールを作るくらいには理解している
- Djangoは知識ゼロ
- JavaでのWebアプリ開発の経験があるので、Webアプリの基礎知識はある
- HTML/CSS/Javascriptは苦手だけど拒否反応を示すほどではない
- Bootstrapは初めて
- SQLは書ける（が、Djangoだと今のところ書いてない）
何をやったか
- ジェネリックビューを使ったCRUD
- 関数ベースビューを使ったCRUD
- Azureに構築していたDBからmodels.pyの生成
- paginatorを使ったページング
- 一覧の検索ボックス
- ついでにBootstrapでの装飾
どのように進めたか
Djangoを始めるキッカケは、社内のインフラの人がSlackで「Pythonの勉強会でもやってみるかな・・・」とつぶやいたのにリアクションしたこと。Pythonかと思ったけど、せっかくならDjangoでWebアプリ作ってみようか、となりスタートした。
- 週に一度1時間～2時間程度教えてもらいながらコードを書く。みたいなことが、3回
- 自分で作りたいものがあったので、隙間時間で真似しながらコード書く
- Djangoのドキュメントで関連しそうなところを読む
- Djangoのソースをチラ見する
- やりたいことベースで検索してWebの記事を読む
注意した点
やりたいことベースで真似して書くともっと早く動くものができあがるのだけど、「自走プログラマー」で窘められてのもあり、ちゃんと公式ドキュメントやソースを見るようにも心がけた。
今時点でできあがったもの
世に出すには程遠いが、自分や身内で使う分にはまぁ、いいんじゃないのくらいのUIのWebアプリができあがった。
機能としては、
- インシデントの一覧を表示する
- 一覧上で特定の検索項目で検索することができる
- 20ページごとにページング
- 一覧からIDを選択すると詳細画面を表示する
- 詳細画面から特定項目の更新画面に遷移できる
- 更新画面で特定項目を更新して一覧画面に戻ってくる
くらい。
入力チェックは未実装。戻る機能（ボタン置くだけだけど）も未実装。更新時の確認画面（もしくはダイアログ）も未実装。
と、まだまだWebアプリとしては未熟。上のは更新画面だけだけど、勉強会用には登録・削除機能も作ってみた。
やってみた感想
上のようなものを作って、勉強時間も含めて、正味24時間程度しか使ってないのではないかと思う。Django触ったことない状態から。
教わりながらだったからスムーズにいった側面はあると思うけど、思った以上に簡単に動くアプリケーションが作れて感動した。（Railsもやってみたら同じような感動ありそう）
1日8時間換算で3人日でゼロからここまで作れるなら、相当コスパいいんじゃないかと思う。
わかりにくいなと思った点
MTVという概念が、どうも気に入らない。viewになんでも書く思想が気持ち悪い。「"ビュー"なのにな・・・」とか思ってしまう。
公式ドキュメントが微妙に・・・
その他
誰かに教わりながらできれば本当に楽にできるけど、そうじゃなければ無難にDjango Girls のチュートリアルからやればいいんではないかなと思う。ちょこちょこ読んでみてるけど、わかりやすいと思うし、勉強会も似たような進め方でやってくれていたなと感じた。
おわりに
どのような人がここまで読んでくれたのかはわからないのだけど、今後も月単位での感想や進捗を（思い出したら）備忘がてら書いてみようかなと。
仕事で必要と感じることでインプットする情報はやはり変わる
はじめに
先日記事に書いていた、「なぜ / 何の情報をインプットするのか？」という内容に関連するような実体験があったので、日常の記録的に記してみる。
いきさつ
以前に「現場で役立つシステム設計の原則」を読んだときに、もう少し自分が若手のころに出会っていたかったな、と感じていた。
「リーダブルコード」「現場で役立つシステム設計の原則」「ドメイン駆動設計入門」はプログラムを書く人の必読入門書だと思う。もっと早くに出会っておくべきだった。
— ちゃぱ (@as_chapa) 2020年3月15日
後輩にも是非読んでほしいなと、当時ゴリ押ししておいたのだけど、読んでいる気配はなかった。自分も後輩も業務においてコードをガリガリ書いたり読んだりする立場ではないので、まぁ、仕方ないかと思っていた。
このときは、その後輩にとっては、「仕事で不要 かつ 興味がない」だったのだろう。
その後、時が経ち（といっても3か月）、その後輩が業務でがっつりとソースコードレビューをすることになった。その中でふと「そういえば以前にゴリ押しされた本があったぞ？」と思ったようで、「あのときオススメしてくれてた本ってなんでしたっけ？」と聞かれた（やっぱり読んでなかった！！！）。
興味がある分野なのかは不明だけど、「仕事で必要」と感じ始めて優先順位が上がったのだな、と思い、自分の自己満マトリックスを思い出してニヤニヤしていた（リモートでの1on1だからバレない）。
（自己満マトリックスの再掲）
インデックスを貼っておけたという意味で多少なりとも貢献できていたのかなと、その点でも良かった。
悪い癖
が、ここで悪い癖が出てしまうのが、余計なお世話好きの先輩の性。
ということで、「あの本はね、システム開発全般でDB周りとかのことも書いてるけど、序盤の話とかは、ドメイン駆動設計という考えの話も盛り込まれててね、ドメイン駆動設計というのはね、エリック・エヴァンスさんという方がね・・・」とクドクドと話してしまい、きっと嫌がられたはず（だけど、いつか彼の中で「必要」と感じるタイミングを待つ）。
ご丁寧に「ドメイン駆動設計 モデリング / 実践ガイド」と「WEB DB PRESS vol.113」のリンクをSlackで送り付けておいた。
本当は「リーダーブルコード」も薦めようと思ったけど、何とか踏みとどまった。
おわりに
なんだか本当にただの日常の記録になってしまった。けど、きっと数年後の自分が酒でも飲みながら「あぁ、彼は元気かな？」なんて思うのだろうと信じて、インターネットに公開する。
（週一更新のために書いたわけではない！）
書籍「テスト駆動開発」を読んで感じたこと
はじめに
「テスト駆動開発」「TDD」、もちろんキーワードとしてはずっと知っていたけど、自身のキャリアの中で真剣に学ぶタイミングを逸していた。最近勉強している「ドメイン駆動設計」の中でも「テスト駆動開発」の話は出るし、ajito.fmの古い回をちょうどよく聞いたこともあり興味が再燃。きちんと理解しようと和田さんの「テスト駆動開発」を手に取った。そこで感じたことを記しておく。
書籍の読み方
この本を読むにあたって大事なことは2つあるかなと思っている。
ひとつめは、「写経」すること。ふたつめは、「付録C：訳者解説」から読むこと。
１：「写経」すること
写経することについては、書籍のP.305にも書かれている。実際に自分が思ったことはこのページに書かれてしまっているのだけど、以下のようなことを思った。
・写経をすることで優れたプログラマーが何を考えながらコードを書いているかを追体験できる
この書籍は、試行錯誤の過程もそのまま書いているので特にオススメ。
・別の言語で写経をするとさらに学びが多い（自分はPythonで写経した）
書籍でレッドになるところがグリーンのまま進むこともあり、なぜだろうと考えると言語仕様によるものだった、ということも多々あり、言語の特徴が見えてくる。
２：「付録C：訳者解説」から読むこと
自分は残念ながら最初から読み進めてしまったけれど、これは絶対にしたほうが良い。内容が古びているわけではないのだけど、やはり初版の出版から20年近く経過していることもあり、変化がたくさんある。付録Cでは、その全体像を丁寧に解説してくれている。全体のマップができた中で、この本を読むことで、位置づけがクリアになっていくと思う。
写経の中での気づき
第Ⅰ部はJavaで書かれているけれど、これをPythonで書き直した。お恥ずかしながらソースを公開してみる。
写経をしながらメモを残していたのだけど、以下のようなことを思っていたらしい（早くも記憶が遠のいていく・・・）
・「同一性」の判定で悩んだ
Pythonだとインスタンス化した際に、別のメモリ空間に保存されるのでassertEqualsが正しく動かないことがあった。結局「__eq__」を実装して対応した。
・Pythonって動的型付けなんだなぁ
いや、まぁ、そんなのは知ってたんだけど、いざ静的型付け言語である Java から書き直してみると、違いを感じるところが多かった。意識的にやろうと型ヒント書きまくったらソースがごちゃごちゃして見にくくなったり。
テスト駆動開発の勉強という目的もだけど、Pythonの勉強にもなった。この辺の話はもうちょっと違う軸も入れて、整理して書きたいなと思う。
他に感じたこと
読み始めるきっかけのひとつになったajito.fmの回を、読み終えた後に聞きなおしてみた。結構同じようなことが話されていて、「わかるわぁ～」と思いながら聞けた。和田さんのこの本に込めた想いとか狙いも話されているので、より深く理解する手助けになるかと思う。オススメ。
「いま」ドメイン駆動設計について書く（～勉強中の身～編）
はじめに
ドメイン駆動設計を勉強している。まだまだまだまだ勉強中の身ではあるものの、だからこそ「こう勉強してきたら、少しずつ理解できた」というものを書けるのではと思い「いま」書いてみる。若干ポエムっぽいのはご理解を。
ちなみに「エリック・エヴァンスのドメイン駆動設計」は恐れて買ってすらいない。「実践ドメイン駆動設計」は買ったけど読んでない。というレベルです。よし、対象読者が絞られた。強い人はこれから下は読まない。
興味のきっかけの振り返り
「ドメイン駆動設計」ってなんだろう？と思い始めたのが昨年の11月。きっかけはWEB+DB PRESS Vol.113の特集。
こんなことを思っていたらしい。
ドメイン駆動設計の特集がわかりやすくて感動。悪いコードをリファクタリングしながら指し示してくれると、納得感がとても強い。
— ちゃぱ (@as_chapa) 2019年11月21日
定期刊行物一覧：WEB+DB PRESS #gihyojp https://t.co/PPxGcxXJAV
この当時でいうと、「ドメイン駆動設計入門」も「ドメイン駆動設計 モデリング/実装ガイド」も刊行されておらず、どう勉強していいのかわからないなーと手探りな感じだった。Twitterを見返すと、どうやら「現場で役立つシステム設計の原則」から読み始めたらしい。（Twitterって便利だなぁ）
「現場で役立つシステム設計の原則」はとても素晴らしい本なのだけど、いま「ドメイン駆動設計」を勉強するなら違う本を選ぶ。
いま自分が思うドメイン駆動設計
「ドメイン駆動設計」ってスコープが広すぎて「感覚的にわかる」ところと、そうではないところが人によって大きく異なるのではないかな？と思う。
例えば普段の業務が実装に近い場合は、「値オブジェクト」とかのほうが理解しやすい。普段の業務がお客さんと要求を詰めてくような人の場合は、「ドメインエキスパートと～」とか「境界づけられたコンテキストが～」とかのほうがしっくりくる。
ドメイン駆動設計が、ソフトウェア開発の全般を取り扱っているので、上記のような疑問を持ったのかな、と思う。自分のキャリアでいうと、プログラマとしてコードを書いていた時期よりも、お客さんと会話しながら要件を詰めていた時期のほうが長いので「ドメイン駆動設計で書かれてることって、要件定義で普通にやってることじゃない？」という感覚を持った。実装面から興味持って勉強し始めたのに、「あれ？」と思ったりはした。
いま学ぼうとする人にどう薦めるか？
ドメイン駆動設計が気になる。という人にはまず以下の書籍をお薦めする。
全体像がとてもわかりやすく書いてある。きっと「エヴァンス本」に書いてあることをいい感じに端折ってくれていると思うのだけど、前述した通り「エヴァンス本」を買っていないので確認できない。けどきっとそうだ。
これを読んだ上で、モデリングのほうに興味を持つか、実装のほうに興味を持つかで次のステップが変わるのだろうなと思う。
もうちょっと「エヴァンス本」から漏らしたものを把握しておきたいのであれば、無料のこちらにサッと目を通すのも良いかと。
https://www.infoq.com/jp/minibooks/domain-driven-design-quickly/
モデリングに興味を持った人
えっと、、、わかりません。（自分が実装のほうに興味を持ったので）
実装に興味を持った人
とにもかくにもこれかなぁ、と思う。
これを読みながら、以下のPodcastを聞くと趣深い。
35. クリーンアーキテクチャと DDD（nrslib） | PHPの現場
実践して得られる気づきは大きいと思うので、その先は実際に自分でコード書いてみるのがいいのではないかな、と思う。
わたしの読書履歴
ドメイン駆動設計に絡んできそうな本として、以下の順序で読み進めて今に至っている。「あぁ、この辺は読んだうえで書いてるのね」くらいに思ってもらえれば。
2019年12月
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法：書籍案内｜技術評論社
2020年1月
わかる！ドメイン駆動設計 ～もちこちゃんの大冒険～【C91新刊】 - TechBooster - BOOTH
https://www.infoq.com/jp/minibooks/domain-driven-design-quickly/
2020年4月
ドメイン駆動設計 モデリング/実装ガイド - little-hands - BOOTH
【PDF版】わかるかも！？ ドメイン駆動設計 はじめの一歩 - シン・オブジェクト倶楽部 - BOOTH
その他の参考情報（見てないものも含む）
本だけではなくこれらのインプットからも理解を進めた。一部、まだ見てないものも含む。
little_hand_s DDD Channel - YouTube
- 松岡さんの解説動画
匿名で聞けちゃう！松岡@DDDブログ書いてますさんの質問箱です | Peing -質問箱-
- 具体的なQAが多い。なんなら質問できちゃう
https://www.youtube.com/watch?v=5oJeSrwztPg
- 成瀬さんのクリーンアーキテクチャの解説動画（DDDではないけど）
35. クリーンアーキテクチャと DDD（nrslib） | PHPの現場
- クリーンアーキテクチャの話が多かったりするけど、DDDのことも
ドメイン駆動設計に15年取り組んでわかったこと 「ビジネスルール・値オブジェクト・型」が3つのキーワード - ログミーTech
- 増田さんの講演文字起こし
おわりに
軽い気持ちで書き始めたら2,000文字以上になってしまった。入門系の本ばかりを読んでおり、いい加減「エヴァンス本」読もうかな、と思っている今日この頃。「エヴァンス本」を読んでしまうと、初学者寄りの発想ができなくなるのでは？という謎の恐怖から、いまの断面で書いてみた。いつか「～ドメイン駆動設計極めたり～編」を書けるようにがんばろう。
なぜ / 何の情報をインプットするのか？
はじめに
少し前に情報収集し過ぎて、でも自分の知識不足を感じて疲れていた（知れば知るほど自分の無知を知る、というループ）。「どうやって効率的に情報をインプットしているのだろうか？」ということを身の回りの人に聞いたりして、自分のやり方と比較した。それはそれで面白かったしタメになったのだけど、その結果、情報をインプットするチャネルが増えただけになった。おぉ、失敗。
そのときは「WHY」「WHAT」「HOW」の「HOW」だけ考えていた。
そもそもなぜそんなに情報をインプットするのか？何をインプットするのか？というところを考えていなかった。きっと失敗の原因はそれもひとつあるのだろう。よし、ちょっと真面目に考えよう。という記事。
なぜ情報をインプットするのか？
先に自分なりの答えを書くと、「なぜ」かは「仕事で成果を上げるため」とする。例えば、「妻との共通の話題のために、妻と同じスマホゲームをする」とか、「娘との共通の話題のために、同じアニメを観る」とかは整理の枠から外します。（家庭内を円満にすることで、ストレスを減らし、仕事に集中できるようになり、仕事の成果が上がる、といった風が吹けば桶屋が儲かる的なことは、一旦忘れます）
何をインプットするのか？
仕事での成果に繋げるということを軸に据えつつ、優先度の付け方として以下のマトリックスを考えてみた（最近気になっているPdMの方が四象限のマトリックスをよく使うのでパクリ）。
仕事で必要 かつ 興味がある
熱意のあるうちにガンガン情報をインプットする対象とすべき。こういうものは、「好きでやっている」ことだったりするので、苦ではないケースが多い
仕事で必要 だが 興味がない
仕事で必要であれば、成果を上げるために一定量のインプットは必要。概要レベルは押さえて、仕事でマイナスにならないようにするところまではがんばる
仕事で不要 だが 興味がある
これは捨ててはいけないと思っている。仕事なんていつどんな風に変わるかわからないので、広く情報をインプットしておくことは大切だと感じるので。ただ、仕事の成果を上げる目的からは短期的には遠いので、暇なときに調べていざ仕事と絡められそうなときに気づくようにインデックスを貼っておく感覚
仕事で不要 かつ 興味がない
ゴミの日に燃えるゴミと一緒に捨てましょう
（まぁ、上の話と絡めると、いつかきっとどこかで役に立つ、みたいな発想もできるのだけど、そうするとキリがない）
まとめ
「WHY」「WHAT」という軸も加えて情報のインプットについて再考してみた。インプット沼にハマって抜け出せない自分のような方の手助けになれば幸い。まずは自分が沼から抜け出して、この効果を証明しないといけないんだけど。
