00:01
aozora.fm第29回目。第29回目は、ゲストにAizackさんをお迎えしています。
Aizackさん、よろしくお願いします。
では、最初に軽く自己紹介をお願いします。
TwitterでAizackと名乗っております。職業は、独立系のSIerでSEをしていまして、
今年でキャリアで言うと3年目ですね。基本的に客先で常駐しながら、
ウェブサイトの構築なんかをやっているので、広い意味ではウェブエンジニアっていうような感じでお仕事しています。
よろしくお願いします。
はい、ありがとうございます。
えっと、Aizackさんと最初にお会いしたのって、あれですかね、EVERYONE ARTPUTのイベントですかね。
えっと、たぶんその辺だと思う。
あ、どうだろう。
なんか応援する会とかのイベントで。
応援会の関係…
あ、えっと、直接お会いしたのはその前に一度、
プレードさんでやられてた転職LT。
はいはいはい。
その時に、それまでお互いなんとなくタイムラインは見てたけど、
これでちゃんとお会いして、あ、あなたがっていうのはあったかなと思ったんです。
なるほど、結構あれですよね。
その後ですかね、MOVPROの話でちょっと出会ったりして。
はい。
っていうのがあって、でまぁ、その10月、11月ぐらいに出たいって話になって、
今7月になって収録をしているので、大変お待たせをしました。
いやいやいや、やっと出れました。
ありがとうございます。
こちらこそ読んでいただいてありがとうございます。
普段から聞いていただいてるけど、ちょいちょい聞いていたんで。
ありがとうございます。
割と楽しみに聞かせていただいてます。
それで、ちょっと自己紹介の話になっちゃうんですけど、
今SIRで働いている客先常駐でウェブ系の開発をやっているってことなんですけど、
主に担当されてるのはフロント、バックエンド、あとインフラ周りどのあたりなんですかね。
基本的にはバックエンドの周りをやってます。
で、今までやったのって大きく2つお仕事があって、
ウェブサイトの構築をCMS化するっていう場合にDrupalっていうCMSを使ってるんですけど、
海外ではよく使われてて、国内だとまだまだしやすくないCMSではあるんですが、
そのDrupalに既存の静的なものを置き換える。
その時にどういう風に設計しないといけないんだっけ、
管理画面どういう風にデザインしましょうか、みたいなのを僕らがやってオフショアに作ってもらう。
それを返ってきて受けてテストするっていうのが1つのパターンと、
今今やってるのが新規サイトを作る中でバックエンドで少しAPIを叩いて、
静的なページを呼び出しをかけるっていう簡単なスクリプトをバックエンド側で作っていて、
そこの設計、構築、テストまでの一連の流れを私が作業者でやっているっていう2つの大きな仕事を客席でやってます。
03:05
じゃあそのCMS周りとかだと主にバックエンドとかCMSの設定とかインストールとかをやっていて、
そうですね。インストールはインフラ側でやってる部分もあるんですけど、
そこをどう設定しなきゃいけないんだっけとかっていうのは多少僕らの方でパラメータをいじったりとかしてます。
その2つ目の方のもともと静的なサイトだったのをちょっと動的な部分を決めるみたいな感じで、
APIを叩くって部分をメインでやられてるって感じ。
それは技術的にはどんな言語とか仕組みを使ってやってる感じですか?
技術的にはPHP7を使って、いわゆるバニラPHPっていう形でフレームワークは特に使わず、
PHPで他で作ってるAPIを叩いて取りに行って、ヘッダーとフッター表示して、
あとは静的コンテンツとそれにくっつけて、みたいな形で画面表示をやる。
簡単なスクリプトとそれに紐づくAPIのパラメータとか定義を裏で持たせたいんで、
その辺を設計したり書いたりっていうのをやってるところですね。
フロントは何でそのAPI叩くんですか?
フロントはJSで叩いたと思うんですけど、
フロントは別のチームが作っているので、完全に僕らバックエンドで既に作られたものを呼び出すだけ。
フロント側のチームは別で自分たちでHTMLとCSSとJSで書いて、
いうので分業しているような形で。
じゃあ本当に既存のAPIとの間みたいなのを作るって感じなんですね。
PHP 7系でフレームワークを使わなかった理由、
多分ララベルが一番あれだと思うんですけど。
そこはですね、プロジェクトのもともとの制約が関わっているところだと思うんですけど、
もともとそこまで大きくなる話ではなかったっていう風に聞いていて、
っていうのも、私入った途中から要件定義をやってた、
ウォーターホールでいう要件定義をやっていたタイミングでは、
そもそもそんなに大きなプロジェクトではなかったので、
バニラPHPでいいだろうと。
フレームワークとかいらないよねって話で進んでたら、
どんどんどんどん話が大きくなっていって、
結果的にはそれで足りんの?みたいになったけど、
もう動いてるんでしょうがないっていうような状況ですね。
なるほど。じゃあ、一から自分でこういうAPIがあってこういうことをやらなきゃいけないよね。
じゃあ、愛宅さん一からお願いねんじゃなくて、
既に誰かがある程度レールを引いたものに途中から乗っかってやり始めたら、
燃え出したみたいな。
そうですね。関係者たくさんいる中で、
あれもこれもっていうのが増えていくのはしょうがないところであるんで、
お仕事してる中で、真っ端にいる、
06:04
僕でなんとか声を上げて変えるっていうには力を及ばずだったっていうのが、
一言で言うとそういうことですよね。
それは組織構造としては、愛宅さんが作業者としていたときに、
愛宅さんは完全に誰かから言われたことをやる感じだったのか、
あるいはステークホルダーみたいな人と会話ができる立ち位置にいたのか。
どちらかと言えば後者ではあるんですけど、
その会話をするにあたって、もう一個レイヤーがあって、
いわゆるマネージャーがもう一人自分たちのところにいて、
そのマネージャーが窓口でステークホルダーだったり、
自分が客先にいるときのお客さんと話したりっていうのをその人がやっていたので、
僕が直接全ステークホルダーに声かけとかじゃなかったんですよ。
なので一回その人通って全部やり取りが走っていたので、
把握できていないところも多かったり。
直接話せる人もいれば、大体はそのマネージャーを通してなって、
ぶっちゃけそのマネージャーはどうだったんですか?優秀だったんですか?
優秀っていうのは切り方もいくつかあると思うんですけど、
マネージメント側としては優秀な方だとは思っていて、
SEの能力の中でいうと、コミュニケーションだったり、
技術的な部分とそうじゃない部分の翻訳っていう部分、
あとはコントロール、ここに関してはすごく長けていた方で、
ただ一方で技術的な部分にはそこまで強い力だったり関心もなくて、
あとはお前がその作業をやるんだからある程度任せるよって
ドンって投げてくれるようになった。
それがちょっとうまく、僕が力発揮できず力親技の部分が重なって、
モヤっとした感じですね。
話を聞いていると、最初の要件は要件で決まっていて、
おそらくデサイヤーなんで契約形態も受け負いとか自宅のやり方であると思うんで、
最初の範囲にちゃんと収める努力をする、できなかったのが
範囲として一つあるのかなっていうのはちょっとあるんですよね。
当然後から必要なものが出てくるのはしょうがないと思うんですよ。
だって、アジャイルとかスクラウンみたいに最初に決めた範囲でやるんじゃなくて、
もっと大きな目標に向けて必要なものをどんどん明らかに一つやっていくっていうのは
不確実性との戦い方の話になると思うんですけど、
っていうのをやれば、その後から増えてきたものを優先順位に決めて
入れ替えてやっていくってことができるんですけど、
どうしてもデサイヤーの仕事の仕方って半年から半年、
その半年前の優先順位で全てが決まって、その枠組みで勝利が決まっちゃうじゃないですか。
そこからはみ出たものって、ある種冷酷な言い方というか、
この変化を非常に変化しまくっているこの時代に
09:03
そこはね、従々承知の上で切り捨てていかないといけないんですよね。
あるいは次のフェーズでやるとか。
そうですね。
っていう調整が実は、受託とか受け負いでやるエンジニア、
エンジニアに限らなくて営業とかもそうなんですけど、
すごく必要なスキルだと思っていて、
結局そこなのかなってちょっと思ったんですけど。
そうですね。そういう意味だと、
仕事が増えた原因って何も僕の上のマネージャーだけの話ではなく、
大きく言うと僕が入ったところ、お客さんがベンダーで入っていて、
そこの窓口がフロントエンドとバックエンドと分かれてたんですね。
バックエンド側が僕の上司で、フロントエンド側が別チームにいて、
フロントエンド側が動くとバックエンドに全部跳ねちゃう仕組みになっているので、
ページ1個表示するにもAPI叩くっていうのがあると、
ページごとにAPIを呼べるようにしなきゃいけないっていう仕組みとかが、
ちょっといけてない仕組みがいろいろあって、
フロント側の要件が増えます。
それがバックエンド側に全部通知されてればいいものを、
分かんないままいつの間にか増えていて、
ギリギリになってポッと増えて、
やりますかって2日前にページ追加増えます、
分かりましたやりますみたいなのが出たりとか。
っていうのも足並みちょっと大きなチームで、
会社単位だとまとまってなきゃいけない部分がまとまり取れてなくて、
フロントの人たちも夜中までお仕事しかしてたみたいなので、
そこにワーってなりました。
あれだ、お隣さんを探せってやつだ。
自分がいるのはバックエンドでAPIで絞っていくと、
そこだけ見ればいいって思いがちなんですけど、
でもそのAPIってシステムの一部だよねってなった時に、
実はそのシステム全体を見ていて、
今言ったようにフロントとバックのチームが別で、
フロントで何か動きがあるとバックにも影響があるってことは、
実はそのフロントのチームとすごく仲良くしておかなきゃいけなかったとか、
動きを読んでおかなきゃいけなかったとか、
全然関係ないですよバックエンドには。
なんだけどシステム前提で見たらそうだよねっていう、
ある種政治的なところもあったりっていうところですよね。
いやーわかる。
それはですね、こっちとしてはある程度やっていたつもりが、
割と握ってたと思ってたところ、
フロントエンド側がいつの間にか突き進んでいたっていう、
こっちからはそう見えるのが何度かあって、
毎回うーんって言いながら、
いいからやってって言われてやらざるを得なくなる。
お客さんと合意取っちゃったみたいな。
それは契約的にどうなのとかもいろいろありそうだなぁ。
そういうのをいろいろ経て、
DevOpsとか、
担当役割で違う人をまとめて一緒に仕事しなきゃダメだよねって思えば、
すごく強くなりました。
なんで近代、こういう話がいっぱい出てくるのっていうところが、
すごく腹打ちする現場ですね。
なんか、ザ日本の開発現場みたいな。
辛さしかないですね。
12:00
全部喋っちゃうとどこに飛び散るかわからないんであれですけど、
だいぶごまかしてもこれだけいろいろ出ます。
Twitter界隈とか、
強いITエンジニアの方と会話すると、
やっぱり技術専攻の方がすごく多くて、
DBとかライバラリーとかフレームワークとかにすごい詳しく言語仕様とか、
フレームワークのコード読むといいよみたいな話聞いて、
なるほど、なるほどって思うんですけど、
どうしても僕の中でそれがすごく腹落ちしないというか、
重要なのはわかるんですけど、
それ以上にもっと重要なことがあるんじゃないかっていうのが
すごく自分の中でモヤモヤしていたことがあって、
最近僕もあーって思ったのが、
その技術、フレームワークとかDBとかSQLとか、
いわゆるテック系の技術を僕が多分すごく極めていても、
僕がSIRとしてあるいはITエンジニアとして一番困っていた時期に
役立たなかったなっていうのがあるんだなっていうのがあって、
今のあいざくさんの話は全く同じなんですよ。
ほんとそうです。
どんなに綺麗なコード作法が、どんなに綺麗なインターフェースを定義しようが、
たった一言で全てがぶっ壊れるんですよ。
お客さんと合意とってきたんでってメール一本で残業が決まりますからね。
それって関係ないじゃないですか。
どんなに綺麗なSQLを書こうかDB構造を作ろうか。
だから結局ヒューマンスキルなんだよなっていうのは結局人なんですよ。
それって現場が悪いじゃんとか、転職すれば?って話もあるし、
それそれが別に正解なんですよ。
それを技術、もっと自分がやりたい新しい技術とか、
良い良い技術の活躍の場を求めて転職するのは全然アリだと思うんですけど、
でも特に内部にいるとそうなんですけど、
どうにかしたいって思うじゃないですか。
思います。ほんと思います。
一般、理由とかきっかけはあると思うんです。
人がとか、そのシステム自体が気に入ってるからとか、
最初に入ったからみたいなのがあると思うんですけど、
どんな理由があるにせよ、やっぱ上手くいかせたいじゃないですか。
そうですね、ほんと。
って思った時に、やっぱそこなんだよなって思いはあって。
すげーよくわかるっていう話聞いてて思いました。
ほんとにこう、技術で解決できると思うんですよ。
できないとは言いません。
技術を使うのが聞く人であって、
そこにたくさんの考え方から言葉から何から違う人たちが集まっちゃった以上、
そこを取り成す、上手いことまとめて落とし所を作る人が、
そのスキルを持った人がいないと、
しっちゃかめっちゃかになって、
我解するっていうのは、どのお仕事でも一緒なのかなと。
そこを整理する仕事が必要なんじゃないか、
スキルが必要なんじゃないかっていうのは、
あの案件を今も若干入ってはいるんですけど、
やってるにあたって本当に思いました。
そこが本当にSIRとかで学ぶべき仕事なんじゃないかなって。
そうなんですよね。
15:01
特にSIRだと契約形態がそういう形が多いので、
あと複数のチームが入りがちっていうことがあるんで、
そういうところはすごい重要だなというか、
足りないんだなっていうのは、
自分もそうだけど、チームとか組織っていうのはすごく感じますよね。
PMが足りないってどういうことなのかなっていうのを、
その案件やってみて、今の話してみて思ったのは、
そこを整理できる人ができるスキルと時間と単価、
全部が釣り合う人がいないっていう話なのかな。
多分いると思うんですよ、スキル単体で見れば。
ただ単価高すぎてうちだと頼めないよね。
火吹いちゃってるからもう無理ですよねみたいなのがあるから難しい。
そこが逆にできるようになると自分の単価は上がるし、
会社としてできることはいっぱいあるんじゃないかなと思っております。
本当そうなんですよね。
それを持っているとやっぱり自社サービスでやっても、
結局なんだかんだ大なり小なりあると思うんで、
企画とか営業からそういう作業とか話が降りてきたりとか、
他のチームとやり取りするってことは別にどの契約形態でもある話だと思うので、
よっぽど規模が小さくない限りは。
なのでそういうスキルって本当に大事だなって思いますよね。
本当にそうですね。
PHPいくらかけようが、そういう人が一人いるかいないかだけで、
プロジェクトの中にいるメンバーの心理的安全性、
あえてバズワードを使いますけど、
それが全然違ってくると思っていて、
いても問題が起きたら一緒なんですよ。
本当そうなんですよね。
それで僕は最初、ちょっとオープニングの話戻すと、
フォルテさんと出会った頃は正直その辺全く火吹いてなかったんで、
めっちゃアウトプットしたい、したいって言って外に出まくってたんですけど、
1月以降できなかったのはそれなの。
それがこの4ヶ月ほど続いてたせいではあったので、
もう本当足りないなと思いましたね、自分にも周りにも。
そうなんですよね。
そういう人って外からなかなかいるづらいっていうのもあったりして、
アイザクさんみたいにそれが外も知ってて、
そういう中の辛さも知ってる人だと、
そういう動きをしやすいんですけど、
中しか知らない人だと分かんないんですよね。
分かんないと。
とにかくただ辛いってだけ。
開発ってそういうもんだよねってなりがちになっちゃってて。
絶対そうじゃないですよ。
絶対そうじゃないです。
何のためスクジュール作るんですか?
何のために予算決めて話し合ってするんですか?
じゃなきゃいらないっすよって。
もう辛さしか本当になって。
そうですね。
でも外目向けるといろんなやり方やってる人がいて、
で、何だろうな、
そのデモプスでもスクラムでも何でもいいんですけど、
それをそのまま持ってこようじゃなくて、
何かそこで自分たちの現場に合わせて入れられるものが必ずあるはずで、
18:04
それが現場を良くするはずなんです。
そうなんです。
何とか自分たちに応用効かせるように消化して持っていけるように。
だから改善ジャーニーなんかはそれの典型だと思っていて、
アジャイルとかっていうプラクティスとしては知ってるけど、
直接使えないよね、
日本語の文献として綺麗に橋渡してくれてる、
いい文献かなと思って。
何度も読んでるんですけど、
まだ自分の中で落としてなくて、
ちょっとずつつまみながらやってるような中ですね。
あれって改善ジャーニーの話なんですけど、
すごくいい本だし、僕も大好きなんですけど、
改善ジャーニーに限らず、
ああいう系の本の唯一の欠点と言ってしまってもいいかもしれないですけど、
再編成がないっていうのがあって、
あの状態を作れて改善ジャーニーを読んでれば、
同じことができる可能性は高いんですけど、
改善ジャーニーだから係数は係数なんですよね。
そうですね、変数が多すぎて再現できないです。
改善ジャーニーを読んで、
あの病にやりたいってなった人のスキルとか、
その人を取り巻く変数、
状況とか上司とか、
同僚とか、
仕事内容もそうなんですけど、
っていう部分がやっぱりあるので、
結構、現実層の落差に打ちのめされるというか、
そうですね、よくできただけに、
辛いところはあるというか、
なんかこう、
こういう例えでいいのかあれですけど、
刑事モノのドラマとか見て、
太陽に吠える見て刑事になりたいっていう人よりも、
踊る大道山戦見てなりたいって思って入ったら、
もっと落差があったみたいな、
なんか自分の中で、
アジャイルサムライとかそういうのが、
いわゆる太陽に吠えるみたいな原点的なところで、
改善事案には踊る大道山戦みたいに、
ある程度翻訳して近いけど、
でもやっぱりまだ違うんだよね。
やっぱりまだ現実って壁あるよねっていうのを、
見て体感してなんか毎回誰かが、
屍がその辺に転がってるみたいな、
そんな感じなのかなって、
自分も屍の一人として思うところであります。
本当そうなんですよね。
じゃあどうすんのって話が一個あって、
個人的な意見で、
それが絶対解というか、
唯一解でもないとは思ってるんですけど、
たぶんつらいの承知で、
黙ってやるしかないんだよなっていうのが一個あって、
要は二人目を作ろうとか、
ムーブメントって言い方するんですけど、
裸で踊る男だったかなっていう話が一個あって、
これ海外の動画だったと思うんですけど、
丘みたいなところで、
日光浴みたいな、
ピクニックみたいなしてる人がいっぱいいる中で、
一人だけ裸で、
上半身裸なだけで、
リゾート地みたいな感じの、
水着着てるみたいなイメージしていただける?
21:02
みたいなとこで、
一人で超楽しそうに踊ってる人がいるんですよ。
その動画自体、
10分とか15分、
もっと短かったかもしれないですけど、
冒頭数分はもう、
人が、
ある週みんなのんびりしてるのに、
一人だけ上半身裸の人が踊ってるだけなんですね。
何やってんだって感じですよね。
でも、それが、
数分経ったときに、
一人参加するんですよ。
で、一人参加した、
二人目の男というか、
二人目なんですけど、
二人目が参加すると、
なしくずし的に、
三人目、四人目、五人目つって、
バーって人が集まってきて、
何が楽しいかわかんないんですけど、
そこで楽しそうに踊っている集団が、
これがムーブメントだっていう、
動画があって、
で、まさに、
現場での開発とか改善って、
そうだよなって思うところがあって、
何でもいいんですよ。
看板でもいいし、
振り返りでもいいし、
見積もりをうまくやろうでもいいし、
何でもいいんですけど、
何かが一人、
それをずっとやっていて、
押しつけるじゃない。
俺はこういうやり方やってるよってだけ。
しゅくしゅくとその人が、
普段ずっとやってて、
何か目についたときに、
二人目ができるかな、
みたいな流れなんですかね。
で、
あと、うるさく言わない。
これいいからやろうぜって言わない。
ただやってて、
なんかあいつ楽しそうだなとか、
あいつ毎日テイジーで帰ってんな。
大体そういう場合ってテイジーで帰らないですよ。
比較的早く帰ってんなみたいな。
のが目に見えてくると、
二人目が現れるんですよね。
何やってんのって聞かれたときに、
二人目ですよね。
こういういいやり方があってみたいな。
それいいじゃん、ちょっと俺にも教えてよってなると、
勝ちっていうのがあって。
そうですね。
誰かに勧められて、
これやれよって言われるより、
俺がこれ見つけたの方が、
やっぱ人間、モチベーション違いますもんね。
で、
誰かに言われて、
なるほど、自分もそうだわって思う話も、
例え話が一個あって、
漢字、
これも誰かから聞いた話なんですけど、
漢字、誤魔化さないことよくあるじゃないですか。
ありますね。
調べ始めたときに、
隣にいた人が、
その漢字はこういう風に書くんだよって言われたとして、
なるほどって思い出したとしても、
調べるの多分やめないんですよ。
変換して、
画面で見るまでやるので。
隣で言ってるのに。
すごく身に覚えがあります。
ですよね。
僕もそれ聞いて、
実際自分も同じことやって、
確かにって思って。
だから、
人は変わらないとか、
人は動かせないよねっての。
事実。
そうですね。
でも変わることあるじゃんっていうのは、
変えたからじゃなくて、
その人が変わっただけであって、
変えたんじゃないんですよね。
そうですね。
そうか。
怪人ジャーニーの第一章が、
まさにそれの話をしてましたよね。
僕ら、
多分読んでる人たちって、
二章三章どんどん先に行っちゃうから、
どうしても後半の明るいところに目が行きがちで、
その前に、
主人公は、
一人で粛々と、
誰にも何も言わず、
外にただ出て、
それを持ち帰って、
一人でずっとやってた時期があった。
そこの下地作ってる期間あったんだよっていうのを、
24:03
飛ばしがちだったっていうのを、
ここには、
なんていうかね、
頭から後ろからぶん殴られたみたいな。
ああ、そうだった!ってなりました。
でも本当に実際そうで、
大抵物語にすると、
つらい時期って、
一に事例があった後、
飛ばされるんですよね。
そんな感じで、
二年経ちましたみたいな。
二年は長いかもしれないですけど、
あったりして。
でも、
そこがやっぱり一番大事なんだよなって、
かつ一番つらいのが、
これって絶対じゃないんですよね。
絶対うまくいく保証がないんですよね。
つらさなんで。
人間が一番苦手な部類なんですよ。
デスマーチと炎上の違いもそうなんですけど、
デスマって死の幸運なんですけど、
歩き続ければ終わるんですよ。
そうですね。
どういう終わり稼働をするかわからないです。
どっかに何かはあるっていう。
なんだけど、炎上は終わらないんですよ。
そうですね。
ただ終わっているだけ。
基本的に誰かが年齢を増加し続けるんで。
そうですね。
なんで炎上はつらいんですよね。
終わりが見えないんだよね。
ただ帰れない。
が、ずっと続くんですよね。
だからそういうところがあるんで、
本当につらいんですけど、
そこがやっぱ大事なんだなってのはあって。
だから外部のコミュニティとかで、
なんか、
愚痴を言うてちょっとネガティブなんですけど、
他の人のベストプラクティックスを聞いたりとか、
分かってもらうみたいな。
そうですね。
本当に大事なんだなってのはあって。
自分に足りないのはやっぱそこなんだよなってのはあって。
足りないですか?
押し付けちゃってて、
うまくいかない。
でもそれって実はチームはチームの良い状態があるから、
それを変えようとするのは良くないとか。
自分が思う良い状態と、
チームが思うというか、
良い状態ってやっぱあるんで、
たとえそれがどんなに自分から見て悪い状態だったとしても、
そこからやっぱり抜け出せないんですよね。
コンフォートゾーンになっちゃうんで、チームの。
だから自発的に抜けてもらうには、
自分が常にそれをやり続けるしかない。
だからやっぱ辛さがあるんだけど、
そうなんですね。
一回動き出した時の爆発力っていうのはやっぱあるんですよね。
そうですね。
下積み期間で自分がきっちり基礎を固めてるからこそ、
2人目が入ってきた時にそのまま動ける。
逆にそれなく、もやっと始まると、
そのままぐちゃぐちゃって崩れて破壊する。
失敗事例とか聞くと、
そうですよね。
誰かが鶴の一声で持ってきて、
入れてみた。
ダメでした。
が多いなって。
そこがもうすごく繋がるところだなって思いましたね。
僕が足りないってのはやっぱそこなんだな。
その忍耐を持って、
かつチームをずっと見つつ、
自分でそれをやり続けるっていう。
僕は結構覚悟って言い方をしちゃったりするんですけど、
そういうのが足りないんだなっていうのは結構、
ここ半年、
27:01
この数ヶ月結構それを思ってますね。
そうなんだ、そう。
いやもう、まさにというか、
押しつけようとし始めてたところだったので、
危ねって思いましたね。
分かってもね、なっちゃうんですよ。
だって、外行ってやっぱりキラキラ人たち見ると、
できるんじゃないか、変えられるんじゃないかって思うんですよね。
分かる。
自分が客先でずっと動いてるからこそ、
ずっとモヤモヤしちゃうのが、
自社だったら大きな声で言っちゃえばいいんですけど、
お客さんなんで結構なお金もらって、
僕ら時間で買われてる人間なんで、
向こうのコンフォートな状態を
乱すだけになるのは違うよな。
なんで、どこまで出そうかってやってるうちに
モヤっとしてて、
その間に他の巻き込まれて、
もう嫌ってなっちゃったみたいなのが、
何回かあったんで。
分かる。
折れますよね。
分かる。
難しいなと思ってます。
なるほど。
でも辞めるのも違うなっていうのが。
そうらしい。
実際、辞めたら楽なんですよ。
多分給料も上げられますし、
開発をやりたい、技術的に高めたいは、
割と一瞬で、一瞬でっていうとあれですけど、
会社見つかれば、1年、2年で取り返しきくのかなとは思っていて、
ただ、それって、
あえてきつい言い方をすれば、
逃げになっちゃうのかなって。
自分はそういうところで何を覚えたときに、
何を学んで、何を欲してたのか、
っていうところと、ずれるじゃない?
っていうのがどうしてもあって、
今までの話の中で言った、
物事を整理する力だったり、
問題が起きないように、
自分のチームとちゃんと座組みをきちんとやって、
一緒に進めていきましょうっていうのは、
別に別の、うちの会社辞めなくたって、
辞める前ができるはずなんですよ。
そこはただの、自分のヒューマンスキルの話だけなんで、
ヒューマンスキル上げれればいけるじゃんって。
どうするのかはないんで、あれですけど、
そこは今、辞めちゃいけないなと思ったりしてるのはそのあたり。
そこの限界が来てるとか、
いや、そもそも構造がダメじゃんっていうのが理解したら、
もしかすると辞めるかもしれないですけど、
今はそれよりも先に、自分の努力が足りてないはずだと。
素晴らしい。
っていう、どこまで合ってるのか間違ってるのか分かんない、
モヤっとした感じでやってますね。
たぶん、正解はないんですよ。
認めづらいんですけど、ないくて、
だから、今辞めても、ここから何年間続けても、
たぶんどっちも正解であり、間違いであるんですよね。
ただ、僕はどっちかというと辞めちゃった方の人間なので、
その僕の観点から言うと、
今、新しいことを知っているのは事実じゃないですか。
30:01
これから先、いろいろまた新しいことを知っていくとは思うんですけど、
今までの自分とこれからの自分って
絶対違うはずなんですよ。
でも、環境は変わらないじゃないですか。
だから、今までの自分と
もう、環境は変わらないじゃないですか。
だから、自分が変わったことによって、
変わらない環境に対して何かできる可能性は、
また違う可能性が出てるはずなんですよ。
それが高いか低いか分からない。
何がどう変わったか分からないけど、何かが起きてるはずなんだ。
だから、それを試すのはすごく大事だと思っていて、
僕は、そこで自分が変わった時に、
環境を変えてしまったので、そこで試さなかったんですよね。
それは、今後悔って言うとあれなんですけど、
やっても良かったなとは思っていて、
結果的に、
5年はいかないか、3、4年?
僕がSIを辞めて3、4年経ってるんですけど、
よりひどくなってたんで、
辞めて正解だった感はちょっとあるんだけど、
自分のQOLというか、
自分のQOLというか、
技術的なところを含めて考えると、
結果的にはそうだったっていうのはあるんですけど、
でもそれって、僕がいなかったからそうなった可能性も
わかんないですよね。
思ってるとは思うんですけど、
事実としてはあると思う。
それが0.何パーか50パーかも分からないけど。
間違いないと思います。少なくとも、
自分の作業以外のところに夢を向けて、何かしら求めて、
動こうとしている、そのパワーがある人が
通常業務に入った時って、
本当その給料分しか仕事しませんって人よりは、
何か影響はプラスのマイナスは分からないですけど、
絶対あるはずで、そこが抜けちゃうとどうなるっていうのは、
1人抜けると環境って全然変わるじゃないですか。
自分の会社でも同期が辞めたり、
先輩辞めたりした中で、全然会社の形変わっちゃったんで
びっくりしたんですよ。
人と違うんだな、1人抜けるって。
業務は回っても回ってないものもいっぱいありますからね。
そうなんですよね。意外と、
あんまりこういう言い方をすると、辛くて今辞めた人を追い詰める言い方になっちゃうんで
あれなんですけど、人が辞めた時って、
会社は続くし、業務は全然回るんですけど、
意外と変わることってやっぱりあったりして、
それが良い面もあれば悪い面もあったりするので、
あれなんですけど、
辞めてどうにかするのが組織の役割なので、
ぶっちゃけそれを気にして辞められないっていうのはやっぱり
違うと思うし、辞めちゃっていいと思うんですけど、
事実として影響があるっていうのはやっぱりある。
まあありますよ。
僕の場合はですけど、辞めるにあたっては
ポジティブに辞めたい。
この会社嫌いだって辞めるのは、
一番楽ですけど、後で同じことをやりそうな。
少なくとも僕はそれが
33:01
2回繰り返さないっていう自信持てないんですよ。
割とちっちゃい人間なんで、
どうせ後で悪口言いたくなるんですよ、どの会社行っても。
であれば、今の会社は間違いない。
ここに関してはすごく学べたんだけども、
僕はこれを学びたい。こういうことをやりたいからごめんなさい。
また何かできたらよろしくお願いしますって辞め方で
行きたいなと。
その前に勘人袋の方が切れたらその時ですけど、
今のところまだ勘人袋まで来るどころか、
感謝することの方がまだ多いので、
その上で学ぶことなくなりました。次これやりたいですが、
出るまでの間にいろいろ手出してみようかな。
それで今回ここで出させてもらった部分もあるんですけど。
本当大事ですよね。
実際アメリカとかそういう社会、
それがいいか悪いか置いといて、実際そういう社会になっていて、
2年とか3年らしいんですよね。
1つの会社にいるのが。こういうことをやりたいとか、
こういうことができるからって言って、その会社に入ってやって、
終わってやれることがなければまた次の会社に行くっていう
キャリアの積み方をする社会なので、
ジョブホッパーとか転職しすぎみたいな
言い方は日本の社会だったりするし、
聞きますけどね。
実際そういう人もいるんですよ。
それはたくさんいる転職者の中で、
どっちも今出てきた2つのパターンは
どっちも属しているはずなんで、何パー数とはいるはずなんですよ。
実際僕も会ったことあるんですけど、
半年経たずに現場を転々としている人がいて、
引消しなんで僕はって言ってて、
炎上したプロジェクトに入って
費用止めてっていうすごくネガティブ、あ、ごめんなさい、
ポジティブな言い方をしてたんだけど、実際一緒に仕事をしてみたら、
ウェブエンジニアなのに
IPアドレスって何ですかっていうところから始まるような人で、
どっちかっていうと君が燃料だよねっていう、
それは恐ろしいっていう感じの人もいたりするんで、
なんでその人って結局、
その人がいい悪いっていうのを客観的に
見れてない。自分もそうだし周りも見れてない。
のが一つその人にとって辛くもあり、
幸せな点でもあるのかなっていう感じがあるんで、
客観的に物事を見るのは大事なんだよなっていうのを
思いますよね。今あいさくさんもおっしゃるように、
今の場所でもまだ学べることはあって、
もちろん嫌なこともあるけれど、
そこは両方とも見れてるっていうのは
そういうことだなと思うんで、
あとは体調とか、メンタル。
大丈夫なら全然今のところで頑張るっていうのはすごく、
そうですね。まずはそこかな、
基本生きていかなきゃいけない中なんで、
そこが耐えれなくなった時には、もちろん
学べることがあろうがなかろうがごめんなさいなんですけど、
それ、許容できる範囲内で多少上下してるんであれば、
そこは大丈夫で、あとはじゃあ何学べるの?
ここで足りるの?足りないの?っていう判断なのかな。
それがキャリアに絡むんであれば。
36:02
別に僕は給料だけもらえればいいんだ、
だったら関係ないと思いますが、
私の場合はキャリアで積み上げたいので。
ざっくり今どういう状況で、
だいぶ熱量高い話しましたけど、
楽しかったですね。
将来的なところで、今会社で学べていることと、
会社で学べないけどやってみたいとか、
学びたいことってあると思うんですけど、
そのあたり学びたいことっていうのは何かあるんですか?
そうですね。いわゆる
開発の方法論で、
ウォーターフォールをメインでやっているので、
それ以外の方法論を知らないっていうのがあって、
いわゆるアジャイルだとか、
アジャイルの派生のスクラムだとか、
そこに紐づく細かいプラクティスは、
どこかで経験したいなと思っていて、
勉強会にも出たりはしてるんですね。
近々出たので言うと、
以前だしめんさんが出られたときにお話されたと思うんですけど、
それに私も先週末行ってみて、
その前にも一度行ったことがあったので、
MOVプロ楽しいなと。
MOVプロの良さみたいなのが既にいろんな方がおっしゃっていて、
本も出てたりするのでそこはあえて言いませんけど、
良さがあったので勉強会にしたいっていうのを、
これが年末ぐらいに会社に伝えてたんですが、
ぐるっと回ってきて、
4月ぐらいにお前やりたいって言ってなかったっけ?
やれよって言うので一声かかって、
今MOVプロの勉強会を作りつつあるという状況でして、
それは会社の内部だけでやるんですか?
完全に社内の勉強会として。
それはMOVプロって、
みんなで一つのものを作るっていうところがまず一個あるので、
目的としてはどっちになるんですかね?
何か例えば会社の中で作りたいものがあって、
それをMOVプロでやるっていう形の、
ワークショップ的な勉強会にするのか?
ベストは後者だと思ってたんですけど、
自分が社外にいて、社内のプロジェクトを把握していないので、
全社に倒していて、
本当にFizzbuzzの簡単なプログラムを、
ある程度時間かけてMOVで回してみませんか?
試してみたら、
よしよしいろいろ出てくると思うんで、
そこで感じられたことがあればいいですね。
それに向けて補足で、前後にMOVプロってこうですよ、
こういうふうに使えるっていうふうに、
自分は体験してみて思ってますよ、
を伝えて、1時間から1時間半くらいで、
収めてやる感じかなっていう。
前半の話じゃないですけど、
押し付けにならないようにだけは気を付けようって、
Fizzbuzzをやろうって思ったのはどういう題材として?
ある種、できるのがわかりきっているじゃないですか。
そこをやろうって思ったのはどういう理由からですか?
39:00
まず、
自分が行った勉強会自体が、
一番最初Fizzbuzzを必ずやるんですね。
MOVプロ体験するにあたって、Fizzbuzzってみんな答え知ってるものをわざとやりましょう。
そこに難易度調整を、
4人いたら4人のうち何人知らない言語なのか、
全く知らない言語でやったりすると、
ロジックはわかっても書けないんですよ。
そこの調査からやらなきゃいけない。
それもそれで楽しくて、
っていう難易度調整が聞かせやすい問題であるっていうのがすごく多くて、
あとは問題を動かすのも楽なんですね。
環境構築みたいなのいちいちしなくても、
Webであるコーディング出せるサービス使って、
ボタン1個押したら動かせるじゃないですか。
時間かけすぎてて勉強会できませんわ。バカらしいんで。
そういう入れやすいものでちょっと時間伸ばして、
とりあえず回転させてみましょう。
Fizzbuzz選んだ。
その先にもう1個目的が作れればいいなってのはある感じ?
そうです。まず今回1回やってみて、
どっかで面白いからやってみました。
っていうのができればいいなっていう、
種まきというか、こういうのもあるよっていうのを
まずは知ってもらって試してもらうのがいいかなと。
ちなみにやる言語はPHPでやる感じですか?
今回そこはチームに決めてもらおうかなと思っていて、
一応時間は長めにとっているので、
誰も体験したことない言語を選んでもいいですよってアナウンスをして、
ちょっと誘導してみて、
問題を解くっていうのに注視してもらおうかなと。
なんかPHPでやるってなった時に、
みんなPHPできるってなるとわざわざそれを…
一瞬で終わるじゃないですか。
1人で5分で終わるものを30分でやってくだらないんで。
で、ちょっとそのMobの良さが伝わるかなみたいな、
ちょっと今思いましたね。
言語は自分で選んでくださいって言いつつ、誘導をかけようと。
ただ会社の勉強会なんで、
例えばPHPやってる会社で、
RubyやりましょうとかJerryやりましょうとか、
Cやりましょうって言いづらいんですよね。
会社の利益に直接繋がりづらくなっちゃうんで、
そこを説得するのもスキルっちゃスキルなんですけど。
難しいところですね。
一応スライド上は、
そこの言語を決めるのもMobですっていうのを書いて、
Mobのみんなで考えてくださいねって書いて、
スライドに書かないところで、
みんなが知ってる言語だと楽すぎちゃうんで、
全然違った言語、誰も触ったことないとか、
一人しか知らないみたいな言語をわざと使ってましたよっていうのを、
口頭だけで言おうと思ってます。
難しいっすね。
何かを決めるのもやっぱ難しいですよね。
そこはもう本当、
そもそも勉強会をやるっていうこととちょっと違うところも重なってはいるんで、
42:03
なかなかあれですけどね。
決まりそうもなかったらAIで決めちゃってもいいのかもしれないですけどね。
時間かかりそうだったら、
じゃあもうこれでやりますかって。
それはもうどれくらいの時期というか、
すぐやるような感じなんですか?
時期的には1ヶ月くらい先ですね。
5月末にやることは決まっていて、
会社からのアナウンスも社員には飛んでると。
参加する人っていうのがどういう任意なんですか?
共生。
基本的には共生と言いつつ、
帰ってこれる人たちはみんな来てねっていうので、
割と全社員、マネージャーも含めて来てください。
集まりそうな感じ?
今までが割と集まってるので、
3、40人くらいはマックスでそれくらいかなって。
それ一人で大変そうですよね。
一応上司もレビューしてくれてる。
上司と僕とで回すことにはなってるので、
ある程度上手くいけば。
俺やんないからやってていいよみたいな人も多分出てくると思うんで。
特にマネージャー層とか。
それをやってるのを見たいみたいな。
一緒にやってほしいんですけどね。
そういう人からドライバーやってほしいんですよね。
資料書きながら何とか見てて、
PMとかPLがドライバーやる意味あんの?ってめっちゃ言われたんですけど、
やってよってすごい思いつつ、
自分でまだやったことないんで腹落ちできなくて、
こういう時はいったほうがいいんじゃないですか?みたいな。
難しいんですよ。
もちろん動画とか見るとプロダクトオーナーの方とか、
コーディングしない人たちが側で見て、
横でナビゲーターとして指示を出してるっていうのもありますけど、
仕様わかってる人だからこそできることもあるはずなんで。
一人の人しかできないを減らすための
プラクティスなんだから、
みんなやってよって思うところではありますよね。
説得が難しいです、これ。
コード書くことに意味があるって思われちゃうと、
ちょっとコード書けない人がやる意味あるの?
っていうのはあるんですよね。
なので比率を増減させるっていうのはあると思っていて、
10-0にしない。
例えばずっとナビゲーターをやるっていうのは無しにして、
1回はやってみるとか。
最初の1回転やってもらって、
なんとなく雰囲気をつかめたら、あとはナビゲーターで。
最初に教えるためにだけリーダークラスの人が入ってもらって、
ここはこうやってくださいってルール伝え終わったら、
あとは作業者クラスの人がやってるのを
リーダーが横で指示するっていうのはあるのかなと。
自分で手を動かしてみるっていうのはすごく大事だと思っていて、
おかげで
使用を伝えるのって難しいっていうのが
まず1個あるじゃないですか。
逆に物を作るのも難しいっていうのがあると思っていて、
だいたいエサ屋的な組織形態、
45:02
あるいは受託とか
受け入れやってる形態だと、
そういう使用を伝える側って
物を作ったことがないか、
あるいは最近やってない。
後者の人が特に多い印象ですね。
若い頃やってたけど、今もう5年くらいやってねーわ。
変化が激しい業界なんで、
こういうやり方あるんだっていうのを分かってもらうっていうのは
一番大事だと思うんですよね。
その意味でいうと、
ミーティングみたいな感じで外からこうだという形だと、
結局今までと変わんないじゃんっていうのはあって、
そこで手を動かしてもらうっていうのがすごく大事。
できれば楽しんでほしいっていうのもあって。
ツールの使い方1個でいいんですよ。
別に桜井データが悪いとは言いません。
ただテキストエディターっていっぱいあるんで、
VSコードあるじゃないですかって。
勝手に入れてやってますけど。
いろんなプラグイン入れられて楽しいじゃないですかって。
そのままコーディングできるじゃないですかって。
いいじゃん使ってみようよって。
それを言えないんでモブで回せたらいいなってだけなんですけど。
そういうところですよね。
単に木を叩くのがコードを書くことじゃない。
開発することじゃないので。
そういうところを経験してもらったらまず1個ありますよね。
言葉にならないすごい楽なもの、
辛いものが一発で伝わると思うんですよ。
体験して一緒に見てる。
それのためにモブプロ使えたら、
その作業がどう辛いのかが分かってもらうだけで、
みんなちょっとずつ優しくなれると思うんですよ。
ちょっとずつ優しくなるために
一回みんなで辛いことしてみません?って言い方悪いんですけどね。
不幸の押し付けじゃないですよね。
目的は背景をお互いに知るってことが大事だと思っていて、
ナビゲーターというか使用を伝えるとか、
何かを伝えることの難しさだったりとか、
実際に手を動かすことの難しさだったりとか。
あとはぜひ勉強会の終わりに
振り返りをやってほしくて、
何でやるつもりか分かんないですけど、
僕やったことないのにお勧めしておいてあれなんですけど、
ファンダンラーンってやってほしいんですよ。
ファンダンラーンっていう振り返りの手法があって、
要はKPTとかYWTみたいなものなんですけど、
ファンダンラーンって楽しい、楽しさ、
楽しいっていうファンとラーン、やったこと、
それからラーン、学んだことの3つの軸で
振り返りをするっていう考え方なんですね。
FDLっていうの出てきましたね。
これFDLっていうのは実は公式じゃないんですよね。
そうなんですか。
KPTとかYWTがあるんでFDLって言いたくなっちゃうけど、
ファンダンラーンって言ってくれって作った人が言ってるんで。
なるほど。ファンダンラーン。知らなかったです。
48:00
僕やったことないのにあれなんですけど、
ぜひこれやってほしいなと。
楽しいってこととかを自覚してほしいんですよね。
そうですね。
そうした方がいいですね。
これ一応ググるとやり方ぜひググってほしいんですけど、
ファンダンラーンでバーって出した後、
出した人じゃない人があったりするんですよ。
これはファンだよねとか、
これはラーン寄りのファンだよねみたいなことをやるっていう。
さっき言った客観的に自分を見るじゃないですか。
自分の感情とかアウトプットを見るっていうのが
できるっていうのがあったりして、
結構それはすごく試してみたいところがあって。
他人にやらせて。
振り返りは僕も
やるにあたって悩んでいて、
どうせならやった人たちの直接のダイレクトなフィードバックが欲しいとか。
それを今今ぼんやり考えたら
Googleフォームでその場で集めたものを
後は見せて、
こんな声出ましたって。それをまとめるときに
ファンダンラーンの手法で僕がこれってこう書いてありますけど、
結構ポジティブなこと書いてありますよね。
逆に言うとこれネガティブになるとこうですよねみたいなのを
ちょっと補足してあげると
ファンダンラーンに同じにはならないかもしれないですけど、
近い落とし方はやりようがあるのかなと。
そこに合わせるように作っていけば
上手くいけそうかなと。
ファンダンラーン自体はまだよく理解できていないので、
どう合わせられるかわからないですけど、ちょっと調べてみようと思います。
たぶん今おっしゃったやり方でも全然いいと思っていて、
それ自体は別に
否定するものではないんですけど、
ファンダンラーンに限らずその場でやるというのが
すごく大事かなと思っていて。
そうですね。
というのが大事かなと思っていて。
みんなで出してみんなで見るというのがすごく大事だと思うんですよね。
それって結局回収率とか
そういう生臭い話というか
泥臭い話でもあるんですけど、
その場で振り返りをしたという実感を得るのがやっぱり大事なのかなと思っていて。
アンケートに答えるとか報告書を出すとか
というんじゃなくて振り返りをした。
お風呂をやったというのと同じで。
その経験自体が僕は大事なんじゃないかなと思っていて。
それをまとめて後でこういう結果出しちゃったら
それは全然アリだし、むしろやった方がいいと思うんですけど。
自分たちで一個物を作るみたいなのでもあると思うんですよね。
振り返りみたいなのって。
というのがすごく経験できる。
その場の空気を経験できるというのはすごい大事かなと思うんで。
可能ならそういう形がいいかなとは思いますね。
そうですね。どうしよう。
別に結論なさないで。
でも面白い指摘だなとは思う。
モブプロどうしようがかなり先行して
スタートしてやってる勉強会のやつなんで
51:01
振り返りもやるんですけど
まだはっきり決められてないっていうまま
今別のプロジェクトに入っちゃったんで
落とせないままモヤっとして走ってるんで
なんでやるのかっていう部分は
バックエンドのアプリを作るだけで
実はフロントのチームの動きで変わっちゃうって話も
同じ話だと思っていて
モブプロ経験できればいいよねで行くのか
モブプロを経験することによって
チームとか組織に対して何らかしらの
伝えたいものとか経験してもらいたいものがあるのか
ないのかっていう部分
のレイヤーの違いなのかなと思っていて
モブプロ経験できればいいのでやるんだったら
全然それはそれでいいんですけど
多分そこで終わっちゃうんですよね
チームとか組織に対して何か自分が勉強してきたもの
良かったものを伝えたいっていうのであれば
モブプロだったり振り返りだったりもっと別のことだったり
その先のことも多分見えてくるはずなんですよ
っていうところがやっぱりあると思っていて
目的とか目標の違いと
考えなければならない範囲の違いって
広げれば広げるほど大変なんですよ
人間はやっぱり狭めたくなるんですよね
だしそれは別に間違いだとは言わないですけど
締め切りとかいろんな状況があるんで
手を広げても万年あるのは分かるし事実はそうだから
必ずしも手を広げるとは言わないんですけど
そういう考え方もあるよっていう話ですよね
選択肢の中にまず入れてみて検討して
ダメだったらしょうがないっていう話ですよね
っていうのはあると思うんで
選択肢なかったんで今までいうと逆にそこ
とりあえず一本道で作って
作るまでの動きは曲折もあって
だいぶシュリンクして一旦ギュッてできた形を
どうそこから先に繋げるかって話なんで
難しいところですね
僕は外部の人間なんで言いたいこと言えるんですけど
現場でやってる人の大変さつらさってあるんで
そうは言っても
分かるんですよね
そういう無関係なところから来るフィードバックほど
正しいものはないという
これほど
忌憚のない意見って言いますけど
正しいか正しくないかはちょっと別として
意識としてごもっともなかった
大体人間と極小的
視野が狭まらないですよねそこにいると
視野が広がるものをもらえるときっかけがあると
っていうのは僕自身やっぱりある
僕もやっぱそうなっちゃう
痛いとこ疲れたと思いながら気持ちいいっていう
マッサージ受けてみる
成長してます私今
素晴らしい
54:01
楽しいですね
モブプロに関してお話してきましたけど
他なんかこういうところ勉強したいとか
そうですねモブプロがメインで話しましたが
やっぱり技術的なところも
全くやりたくないわけではないですね
コーディングも自己流でやってたに近いんで
それを高めていく
技術一人でっていうのも含めて
チームでっていうのもできないかなと
それこそソースレビューの話だとか
そもそも綺麗なコードって何っていう定義
研修に未経験で
私入ったので外部研修行った時に
綺麗なコードとか何やらこう講師の人が
言ってたり経験者の方が語ってるのを見て
未だによく分かってないんですよ綺麗なコードって何
誰も定義できてないような気がする
技術量が少なきゃいいのメモリーを食わなきゃいいの
スピードが速ければいいのそれとも
脆弱性がなければいいの
みんな違う観点で話してるんでそこは整理しませんかっていうのが
僕の中にあってそこを整理して本当にやるのが
コースレビューでしょ
一回後輩のソースをレビューしたことがあるんですけど
自分の中で論点が全然整理できないまま
いいのかどうせ分かんねえだろうな
ここ直してってやってる方が
すごい辛いんで技術として確立させなきゃってすごい思ったんですよ
本当に学ぶべきところが多いなって
分かる
自分のソースを自分でレビューするっていうのも一つじゃないですか
一回ちょっと時間を置いて見直して
こうしたらよかったみたいなそれもソースレビューの技法があれば
できるんじゃないのって技法なり自分の中の信念というか
観点があればデバッグしてる時にも
あれこの書き方ってよかったんだっけって言うと
自走してより綺麗に
綺麗にって言ったら言葉が良くないんであれですけど
より自分の中でレベルを上げていけるんじゃないかな
そうなんですよね
レビューの技法ソースレビューって結局
後手になるじゃないですか
出来上がったものに対するレビューになっちゃうんで
効率というか
より良さで考えたら最初からレビューが要らない
コードを書けた方が良いはずなんですよね
そうです一発で終わりますからね
僕は個人的にはそっちをメインにしたいかなって
レビューが要らないってことは言ってない
そもそもレビューが要らないように書けって言う
さっき話題に出たTDDとかって実はそういう
ところがあるかなと思っていて
TDDをちゃんとやっていくと
物差しになるって話があって
TDDをやっていた時に
テストが書きやすい書きにくいコードが
すごく分かってきた時に
自分のコードを書く力みたいなのを
57:00
物差しになるっていうのがあって
前提としてテストが書きやすいコードは良いコードだ
っていうのがまず1個あるんですけど
自分が成長したなってことが実感できる
最初にテストコードを書こうとして何を書けば良いか
分からないところから始まるはずですもんね
そこも含めて
何をテストしなきゃいけないんだろうみたいな
それって結局テストそのものよりも
アサートの書き方っていう構文とかそのものよりも
どういう仕様で何が重要で
何をテストしなきゃいけないのかっていう構造解析に
そういった部分を含めては確かにおっしゃる通りあると思います
自分の場合はコードレビューされる立場として
ずっともやもやしてたんで
レビューちゃんとしてくれれば問題は起きなかったじゃんとか
っていうのが根っこにあるんでレビューの話が出てきたり
コミュニケーションがうまくいかなかったことがあるから
その恨みつらみのひっくり返しじゃないですけど
モブプロへの憧れみたいなのが今出ちゃってるんですよね
これって今まで話してる中で
本当に?みたいなところが何度か疑問が出てるように
結構純粋なのかどうか分かんないんですよ
下心がめちゃくちゃあるんでこれさえあればって
後で振り返って思ってるだけなんです
そうなんだろうっていう
大事だと思いますけどね
ある種のきっかけだと思うんで
それに依存しちゃうと辛いっていうのがあって
なんとも言っててかつ逃げのように感じられる方がいたら
やっぱりケースバイケースじゃないですか
モブプロもヒューマンスキルもソフトスキルも
全部そうなんですけど
金の弾丸にはならないんですよね
全部やればいいかそうでもないし
やらなかったら意味ないからやらないよって
なんかやっぱ違ってて
結局そこの辛さは変わってないじゃんっていうのがあって
でもやっぱりやるしかないんですよね
何にどう適応できるかわかんないけど
こういう差があるんだったら試してみよう
良かった悪かった振り返ってみて
良かったんだったら続けようダメなんだったら改善しましょう
別のことやってみましょうっていうシンプルなプロセスの繰り返しになるのかなと
やっぱその辛さは僕もすごく感じていて
そこを楽しさで保管したいですね
とか変えられるとか
そもそもそれが楽しい人
技術そのものに関してもやるのが楽しいからで
別に効果とか全然考えないみたいな人がいて
そういう人はだいたいそういうところに
うまくはまったりするじゃないですかっていうのはやっぱあるんで
そういう部分はあるんだろうなって
だからどうやったら自分が楽しくなるかとか
そういう傾向みたいのを知ってると
いいよなっていうのはちょっとありますね
そうですねそこを掘り下げて
使えるか使えないかって順番ですね
いやもう得るべきものが多いですね
得るものも多いし
1:00:02
見るべきとこも多いし出てよかったです
楽しいですねこれ
いや本当今日ちょっと諸々の都合で
いい時間になったんでここまでって感じで
時間足りないのが残念ですね
もうちょっとねソフトスキルというか
チーム論とか
チーム論的な話で
こういう本の話読んでるとかっていう話もしたかったし
そうですねそこ何だったら
私大学の専攻がその辺なので
むちゃくちゃ興味ある話題であるんですけど
っていうのもあるしあと趣味系で
いろいろ声優とか
ゲームも好きですし漫画もアニメも
見たいことありますし
あれが好きなんですよね
漫才じゃなくてラフ語です
ラフ語の話も聞きたかったなっていうのは
時間がどうしても足りないんで
ごめんなさい今日は予定が
今回はここまでということで
がっつりエンジニアリングの話したんで
次回もしあればお楽しみということで
ではちょっと
このポッドキャストの告知をやっていきます
このポッドキャストアウドライフェムではゲストを募集しています
楽したい話しいことがあれば誰でもOKです
今までポッドキャストに出たいけど
ハードルが高いなとかそういう話題が全然ないよ
っていう方でも大丈夫です
今回みたいに仕事の話とかもちろん趣味の話でもOKなんで
気軽にご連絡ください
なお現在ゲストの収録給が溜まっております
今ご連絡をいただくと
3ヶ月から半年くらい先になってしまうかもしれないので
あらかじめご了承ください
ご連絡方法はツイッターのDMなど何でも大丈夫です
また青空FMではご感想や
ご意見をお待ちしております
ツイッターのハッシュタグ
シャープAOZORAFM
をつけて呟いてください
配信ページにお便りボタンがあるので
このお便りボタンを押していただくと
Googleホームでお便りを送れるので
そちらもお待ちしております
またDiscordでポッドキャスト好きが集まるコミュニティ
スパキャスというのもやっているので
ポッドキャストちょっと興味があるなとか
公開収録たまにやっているので興味がある人はぜひ参加してもらえると嬉しいです
配信ページにリンク貼ってあります
AOZORAFMからは以上ですね
ゲストのあいさくさんから何か告知があれば
2つお話したいことがありまして
1つが本として出版された
同人として出たものは去年の
年末のコミケで出てたんですけど
親方さんという方主催で
1:03:00
ワンストップ見積もり本
同人として出版されています
物理本としても時々再販
ナイトとかで出ていると思うんですけど
今はブースでPDF等で売っているはずなので
そちらを見ていただければなと
トータルで20人以上の著者の方が
いろんな見積もりに関して
お金の見積もりだったり
作業時間の見積もりだったり
いろんなパターンでプロコン
よし足いろいろ書かれて燃えた話とかも
確かあったかなとは思いますので
辛みとか悩みどうしようかなと思っている方があれば
興味の持てる本なのかなとは思っています
ぜひ興味ある方どうぞ
というのが1つ
もう1つが私ともう1人
アワナさん
私のエンジニアのアワナさんが
一度開催してまた次を拡作している
コミュニティがありまして
Everyone Outputterというコミュニティなんですけど
第1回を去年の11月にやりました
第2回なんですけど
前回アワナさん出てた時に2月3月ぐらい
っていう話してたんですけど
私の方でちょっとゴタゴタありまして
ただ2人だと若干厳しいと
2人ともまたコミュニティとしての経験も浅くて
イベントってどうしたらいいんだっけが分からない人があるんで
そういうところちょっと手伝ってみたいよとか
1回だけならやってみたいな愛であるよみたいな人がいらっしゃったら
ぜひ私かアワナさんに連絡いただければ
一緒にやりませんかと
イベント開催の実績会場をやりたいかどうかな
というのが私のお知らせになります
三つ森本は僕も参加していて
あいさつは3章
サイヤーである作業時間の三つ森みたいな話を
分か手向けのやつですね
僕は二手三つ森っていう三つ森技法の紹介をしているんで
ブースリンク貼っておくので
ぜひぜひお願いしますっていうのと
エブリオンアウトプットの方は
実際にサッフとかそういった実像がなくても
コメント相談乗るよとかっていう人がいれば
ぜひぜひDMとか
なんならシャープアウトライフェイもつけて
つぶやいてもらえればなんて思いますのでよろしくお願いします
あとあれですよねブログもあるんで
そうですね主に去年の
クリスマス頃までみんなで
なんていうんでしたっけ
アドベントカレンダー
同様に去年作ってそれで何本か書いて
今止まってはいるんですけど
またちょくちょく復活して書いていきたいなって思いもあるので
アウトプットがあるってことで紹介するの全然
ちっちゃいアウトプットが経歴が
1:06:02
一発目がジャズと落語の
要素を語る趣味全開のものだったりしますが
そういうことをやってますよっていう話です
リンク貼っておくんで
ぜひぜひ見てくださいって感じですね
よろしくお願いします
最後にエンディングトークということで
ポトキャストの収録どうでした話って毎回やってるんですけど
初めてですよね
やっぱ楽しいですね人と話すの
収録とか考えずに話してるのもいいですけど
何伝えたら伝わるのかなっていうのを
ちょっと考えながら食べると
自分の今まで考えてなかったようなのがボロって出て
話題盛り上がってっていうこの掛け合いが楽しいですね
これはもうやめられなくなるはずですよね
ポッドキャストの大好きなお兄さん方が増えるわけです
本当は始まる前も
そんなに話せるかなとか話題があって言ってたじゃないですか
やるとこうやってボロボロ出てくる
時間足んないです
ほんと楽しかったですね
今回は本当に仕事
エンジニアリングの話しかしてないじゃないですか
これが趣味の話だとまた別ベクトルの話になるので
そっちが本編だと思ってます
まだイントロ終わったという気持ちでしかやりません
なんならあとエンジニアリング1時間くらいやれなきゃ
まだまだ話つきません
トピックがトピックなので
2回目3回目全然ウェルカムなので
また機会があればぜひお願いします
2本目をまた撮るかもしれないですけど
すぐ2本目の話をさせていただきたいなと思います
楽しいって言っていただけたので私としては大満足です
ありがとうございます
第29回目は
ゲストにあいさくさんをお迎えしてお送りしました
あいさくさんどうもありがとうございました
