きのこカンファレンス2025と前夜祭に参加しまして。
(最近、ずっと『三体』を読んでます。)
内容ではなく、参加して、何を考えたか。みたいなメモ
参加の動機
ある程度の関係を培ってきて「この人にはこれ頼むと安心」みたいな感じだったり、
自分も自分で｢こうしておけばいいよね｣と仕事をこなす感じで、負荷も成長実感も少なく。
けど、このまま同じ状況が続くわけでもなく、今40代ですけれども、50、60になったらどうなるのか。
昔は「これやってる人少ないから、やっとけば差別化できる！」みたいな感じでうまくいってた気がするけど、
今は世の中的にもなんだか整っている感じもして、そういうのもわかりづらいというか。
同年代の人たちはどう思ってるんだろう？って興味があって参加してみた。
｢次ってなんだ?｣
年齢を重ねてきて、自分には今も何の価値が出せいて、何の価値が弱くなった?無くなった?のかを考えたりする。
そして「これからは何を学んで、何に挑戦すればいいのか？」
- QAエンジニア?
エンジニアリングを経験している方がまだ少なそうだから?そういう経験があるならもっと改善できるんじゃないか?
- トレーニング、教育
組織的に、ただ業務に打ち込んじゃっていそうな方がいる。それはよいが、組織の観点として次の準備が整えられない?
- チーム、チームビルド、コミュニケーション(パス)
適当に集まって朝会やってればいいものじゃない。マネジメントを体系的に学び、活動できる環境づくりを?
- チームの目的、目標、ビジョン
チームビルドに関連して必要なことだけれど、苦手な方が多い印象。自分も得意なつもりはないけれど。状況によりけりでの価値は知っているつもり
- マインド、思考、戦略
↑と似た感じ
- キャリアカウンセリング?
自分は自分で考えるけれど、一緒に考えることはできる。こう考えてみたら?とか、話すことで気づく視点とか。これって体系的な情報ってあるんですかね?
- 評価?自分の強みを最適に表現する能力
評価って大変。という話もあるので、改めて学んでみる?
- 効果的、効率の手法?
人それぞれ、好みの部分もあるけれども、技術力というよりは業務遂行力よりのパタンとか
- 今は名前の無い仕事?
理想があって課題があって、それを解決する道を見つける、考える
こういう活動はしてみよう
若い方に話を聞きに行く活動をしたいと思ったり。新しい方法や考えを探す旅。
どんな状況で、どういう働き方してますか?
どういうマネジメントしてますか?
どういう課題や、理想をもっていますか?
同じ世代の方に聞いても、つい自分の中で解釈、消化しちゃいそう。な感じもあり。
若い方から求められて話をする場合は、自分が応えるだけで終わっちゃいそう。
求められてること、要望に多く触れるには、自分の知りたいことを頻度よく進めるのが良いかな?って。
懇親会
↑のようなことを考えていたところ、懇親会で実際に話を伺える機会あって良かった。
こういう状況だけれど、こういうチャレンジをしてみたい。という経験と動機の学び。
｢複雑｣に対処していく話になるのかな?
先週は土日含め、いろいろとめちゃんこ忙しかった。ので、読めず。
｢バーティカルスライス｣出てきた。
その前段で｢複雑さ｣に触れて、人間の脳みそは、多くのモノを覚えられないし、よく惑わされる話が出てきている。
さっさと始めることが最良の選択であること"も"あります。
"も"あります。
｢動くソフトウェアから始める｣
｢最小のバーティカルスライス｣
タイトルだけでも想像してしまうのは、先入観がありすぎてフラットに読めないのは良くないよな。とは思うけれども…。
- TDD
- BDD
- DDD
↑こちらはわかるけれど
↓こちらは初耳
- タイプ駆動開発
- プロパティ駆動開発
次の時に、読み返してみよう。
1つの機能を実装しようともしないうちに、自家製のデータアクセスフレームワークを完璧にするために何ヶ月もかけているプログラマーに何度か会ったことがあります。
どんな馬鹿でもコンピューターが理解できるコードを書ける。良いプログラマーは人間が理解できるコードを書く。
コードは資産じゃなく負債。
書くコストもあるけれど読むコストもだいぶある。極力書かないで充たせるとよいですよね。
そんな簡単なこと、そんな小さなことがいろいろな結果をもたらす!
スキルを上げることなく、アウトカムを改善するのです!!
また出てきた、好き。
けど、やらない人まだまだ全然いるのよね。
チェックリストは｢読んで実施する｣ものと｢実施してから確認する｣ものがある。
こういう言語化されるの気持ち良き。
git
git init
チェックリスト
- Gitを使え
- ビルドを自動化せよ
- エラーメッセージをすべて有効にせよ
この本を読ませたい。が読ませても建前理解している風で実践しないんだろうなぁ。
耳からねじ込みたいっ。
つぶやき
- ｢ボーイスカウトルール｣って、わかりやすくって理解されやすそうな言葉だなぁっていつも思うけれど普段使わないな。今度使ってみようかな。
- ボールとバットの計算は、なんかいつも焦ります…。
- ソフトウェア開発の難しさ。の話ですけれども、自分は何事も脳みそに収まらんと辛い…すぐウッてなる。作業は分解したがり、スケジュールも分解したがり、依存も極力少なくしたい。みたいな。
コードの価値の話がすぐ出てきた
処理を共通化したい。けど、実は似てるだけでちょっとずつ違ってて複雑になっていって、結局作りきれない。みたいな話もあったなぁ。
コードの価値は、売上?だけじゃないけれども、価値を出せないコードが生まれる機会は存在しますね。注意しませんと。
新しいメタファー｢脳｣
内発的動機づけは、コンピューターに無いよね。というのはクスりとくる。
コードを書く回数より、読む回数が多い。っていうのは｢確かに、そうかも｣感ある。
小さな変更でも、処理の最初から最後まで把握しないと正しいのかどうか確証持ちきれないよね。
複雑なタスク?を自動化の仕組みで改善させようとして作業時間がなくってずっと問題が残ったままになる方、チームってある
また『脳に収まるコードの書き方』を読んでる。
チェックリストがあれば、スキルの向上なしに結果を改善できます!
｢いる｣というか自分の周りでよくいる、見かける。
そして、問題が残ったままで周りがいろいろ被る。ずっと。
少しでも改善できたら自動化する作業時間も作れるんだからさ、そういうところからやろうよ。
プログラミングの設計と実装?って分けがちだけれど、実装中に設計を更に詰めたり、変更もしたりするから、設計って進行中のもので建築のメタファーへのズレみたいなのはとってもあったので言語化されているようで気持ち良い。
建築のメタファーがこき下ろされていて?興味深くはあるけれど、ちょっと気の毒というか。
ガーデニングや会計士なども。メタファーであるから一長一短?というか。有害とまでいうからそれだけ気持ちがあるんだろうな。
UI/UX中心に作業進めていたプロジェクトの時に｢DBの構造違うからこのソフトウェア駄目。｣みたいなこと言われたことあるけれど、DBあってもUIなかったら触れないんだが。みたいな気持ちで最後まで分かりあえなかったなぁ。
この本のテーマは｢経験則のガイドツアー｣なのですね。
目次みたら眺められるのでしょうけれど、見ずにこのまま頭から読んでいこう、何が現れるのか楽しみ。
『脳に収まるコードの書き方』を読み始めた
1章もまだほんの1,2ページ
｢ソフトウェア開発は家を建てるようなものじゃない。そんなものだと考えると失敗するぞ。｣
というのが、もう掴みはOK。
プロジェクトと考えるのも、状況によるけれど、そうじゃないんじゃない?と。
パフォーマンスが良いチームは、思い立ったらすぐにリリース出来る。というのは、自分に置き換えると好みのタイミングでリリース出来る。ということかな?と。
建築フェーズがコンパイル。固めるとき、であって自由。他すべての作業が設計フェーズ。
『曖昧なところなく詳細に書く行為が、プログラミング』よき。
興味深まる導入。
マネージャーの業務は、｢お使い｣じゃないんと思うのです
相談?をもらいまして!
｢マネージャーが『その作業が終わってもらわないと困る。』とチーム内の特定の方を朝会中ずっと責めていている｣
それはどうなんだ?と。
深堀って聞いてみると、
- 朝会の状況もっと詳しく?
- 時間は30分
- 他のメンバーもそっちのけで、マネージャーと特定の方とのお話し合いに終始している
- 特定の方が事前に連絡しておくことも必要なのでは?
- 今まではちょっと遅れてもなんでもなかった、最近はスケジュールがあるのか厳しく言い始めた(?)
- 作業自体かかっても2,3日作業なので、｢事前｣というのも最初に伝えなければ、いつ伝えても｢直前｣みたいになってしまう
- 特定の方の普段の状況は?
- 他のチームからもMTGや相談、不具合対応なども複数の方面から依頼がきている
- それじゃ小さなことも作業時間がとれずに予定通り終わらないよね
- 他のチームからもMTGや相談、不具合対応なども複数の方面から依頼がきている
- マネージャーの方はそういう環境を改善してくれないの?
- 相談してくれ。とは言ったものの、そのまま話は終わり
みたいな
こんなん朝からやられたらその日のチーム内メンバーのモチベーションなんて湧かないよね…。と同情してしまう。
メンバーの作業、集中時間確保もしてない。 周りからの依頼も状況判断せずに直接メンバーに下ろしちゃう。 実質、その特定の方という方が、マネジメントもして開発作業もしているプレイングマネージャー化しているように思ってしまう。
そうなると、そのマネージャーの方とやらは何を仕事としているのだろうか??
｢マネージャーの役割、業務とは!?｣みたいなのは苦手だけれども ｢マネージャーとして自分はチームにどうやって貢献するのか?｣を考えたときに、メンバーが気持ちよく働けてパフォーマンスを発揮してもらう。 みたいなこと考えたりしないものなのか?
と思ったりするので、
チーム内での改善も難しそうだし、この相談内容だけでは一方的なお話ではあるので、 飛び越えて申し訳ないけれど、マネージャーの更に上の方や横のマネージャーの方と相談するのがいいと思いますよ。
というフィクションです。
マネージャーの業務は、｢お使い｣じゃないんと思うのです
相談?をもらいまして!
｢マネージャーが『その作業が終わってもらわないと困る。』とチーム内の特定の方を朝会中ずっと責めていている｣
それはどうなんだ?と。
深堀って聞いてみると、
- 朝会の状況もっと詳しく?
- 時間は30分
- 他のメンバーもそっちのけで、マネージャーと特定の方とのお話し合いに終始している
- 特定の方が事前に連絡しておくことも必要なのでは?
- 今まではちょっと遅れてもなんでもなかった、最近はスケジュールがあるのか厳しく言い始めた(?)
- 作業自体かかっても2,3日作業なので、｢事前｣というのも最初に伝えなければ、いつ伝えても｢直前｣みたいになってしまう
- 特定の方の普段の状況は?
- 他のチームからもMTGや相談、不具合対応なども複数の方面から依頼がきている
- それじゃ小さなことも作業時間がとれずに予定通り終わらないよね
- 他のチームからもMTGや相談、不具合対応なども複数の方面から依頼がきている
- マネージャーの方はそういう環境を改善してくれないの?
- 相談してくれ。とは言ったものの、そのまま話は終わり
みたいな
こんなん朝からやられたらその日のチーム内メンバーのモチベーションなんて湧かないよね…。と同情してしまう。
特定の方の作業、集中時間確保もしてない。 周りからの依頼も状況判断せずに直接メンバーに下ろしちゃう。 実質、その特定の方という方が、マネジメントもして開発作業もしているプレイングマネージャー化しているように思ってしまう。
そうなると、そのマネージャーの方とやらは何を仕事としているのだろうか??
｢マネージャーの役割、業務とは!?｣みたいなのは苦手だけれども ｢マネージャーとして自分はチームにどうやって貢献するのか?｣を考えたときに、メンバーが気持ちよく働けてパフォーマンスを発揮してもらう。 みたいなこと考えたりしないものなのか?
と思ったりするので、
チーム内での改善も難しそうだし、この相談内容だけでは一方的なお話ではあるので、 飛び越えて申し訳ないけれど、マネージャーの更に上の方や横のマネージャーの方と相談するのがいいと思いますよ。
というお話。
