  |
はてなキーワード: ペアプロとは
20年ぐらいプログラミングやってるっていう40代の人とペアプロしてるんだけど
変数はほとんどがグローバル的な扱いで独自の命名規則で宣言しるし
その命名規則も全然守られてないしスペルミスも多くて読んでてイライラしてくる
根本的な作り方が無茶苦茶でちゃんと動いてるのかバグがあるのかも分からん状態
PR出てくる度に打ち合わせして、そもそものデータ構造とか機能分割について指摘してるんだけど
この前ふと
「そういやJavaで書いたことありますか？Javaだとこんな感じですよね」
って話したらJava知らんと言われた
で、聞いてみたらオブジェクト指向言語で書いたことないし勉強したことも無いとのこと
JavaなりC++なりオブジェクト指向言語で書ける必要は無いけれど
少なくともデータの堅牢性とか再利用性とかの考え方は知っといて欲しい
低レベルなんだよ。ハッキリ言って。
どうせ枯れた技術ばっか使ってんだろ？
非常に集中力を使う厳密さが必要な作業に関して実行役と、同じ作業を俯瞰して全体を見渡したり逆に本筋以外の細部をチェックする役のペアだから、あまり家事に置き換えられない。
しいて言うなら二人とも作ったことのない新しいレシピに取り組むとき、一人が調理を担当して、もう一人がレシピ本を見ながら次の手順を示したり、料理酒とみりんを間違えていないかチェックするような役割分担だ。
うまくやればノウハウの伝授という副作用もあったりするがそれは本質ではなく、スキル差はない方が望ましい。
大体モラハラ気質のベテランプログラマーと低スキルの新人プログラマーのペアプロが成立するわけないだろ。いや新人プログラマーというよりベテラン営業マンに繁忙期だからとプログラム書かせるようなもんか。
だから学ぶしかないんだよプロジェクトマネージメントを。お互い素人なりに少しずつ学んで取り入れていくんだよ。
https://blog.tinect.jp/?p=81116
要は家庭運営は「プロジェクト」であるのだから適切なプロジェクト運営を行う必要がある、という趣旨で内容については概ね同意ではあるのだが、これを実践しようとするには大きな問題がある。
普通の人は「プロジェクトマネージメント」なんてできないのだ。
私はいろいろな会社の小さめのプロジェクトに参加して開発を請け負うエンジニアなのだが、まともなプロジェクト責任者に当たるのは20%もない。
ここでいう「まともな」というのは、
という、プロジェクトマネージメントを行うにあたっての最低限のスキルがある人である。
もちろん優秀な人が集まる大企業であれば多くの人が簡単にこなせるだろうが、私が参加するような中小企業にいるような人たちには難しいのだ。
つまり、「夫婦の人生というプロジェクト」において、プロジェクトマネージメント的な方法を用いて適切な運営を行おうとしても、なかなかに難しい話なのである。
そして更に大きな問題が1つある。
誰かが明確なプロジェクトの責任者であるなら、モチベの管理はその人の責任ですけれど、家庭運営というプロジェクトで「主従」があるべきではない
これはその通りなのだが、人生というプロジェクトにおいて最も大変と言える子育ての初期はそうもいかない。
相対的に妻が家庭運営にかけられる時間が多く、それにより知識の差もできてしまい、結果として妻側がマネージャー、夫側が指示を受ける側、という立場にならざるを得ないのだ。
そして妻側にプロジェクトマネージメントの経験がない場合に、プロジェクトが崩壊へと向かってしまう。
初産の年齢でなんらかのプロジェクトのマネージメント経験がある女性がどれだけいるかを考えれば、多くの家庭が機能不全に陥ってしまうのは想像に難くないだろう。
まずは、妻の方がマネージャーとならざるを得ない状況が大きな問題なのであるから、夫も妻と同等かそれ以上の時間を家庭運営に割けるように、育休を妻と同期間かそれ以上の期間取得すれば良いのだ。
これはとても簡単な話だ。
次に、それができたとしても若い夫婦にはそもそもプロジェクト運営は困難だ。
それを解決するにはエンジニアリングの世界からヒントを持ってこよう。
ソフトウェアエンジニアの世界には「ペアプログラミング」というものがある。
ソフトウェア開発をペアになって行うのだ。一人がコードを書き、一人がナビゲーターとしてサポートする。
一見すると一人しかコードを書いていないため作業が遅くなるように思われるが、二人がそれぞれコードを書くよりも開発が早く進む場合が多い。
これはペアで作業を行うことで、ミスを発見しやすくなる、知識を共有する時間が不要となる、チームワークが向上する、といったメリットがあるからだ。
家庭運営でも同じことをすれば良い。
まずは全ての作業を一緒にやるのだ。
分担するのは全体感の把握と個別作業の理解が十分にできてからで良い。
ネットの書き込みを見ると「夫はこの程度のこともちゃんとできない」という愚痴をよく見る。
「こんなこともわからないのか」と責めるようなマネージメントのアンチパターンではすぐに無能な夫が出来上がってしまうので、そうではなくて「一緒にやろう」と声をかけて、何度か作業を見てもらって、その後実際にやってもらって、それで何回かすれば期待する作業をやってもらえるようになるだろう。
逆に、「何か手伝うとすぐに怒る妻」には「ちゃんとやりたいからまずやり方を見せて」「今度は俺がやるから見てて」というコミュニケーションをすれば良い。
日本の多くの家庭は話し合いの場を持つということすら苦手だと思うので、この「一緒にやってみてそれから分担を考える」というプロセスは導入しやすい。
これから子供が生まれる家庭で、夫婦共にプロジェクトマネージメントのプロフェッショナルでない場合は、「育休を取る」「家事はペアプロ」この2つだけはぜひ覚えておいてほしい。
＞ 評価基準が変わり、開発効率が変わり、単価が変わっていくんだろうか。
実際にChatGPTとペアプロしてみると, 現在〜近未来において上記は間違いなく変わるだろうなという感触を得られると思う。
とくに単価については、この手のAIアプリケーションが十分こなれた世界ならば、開発作業自体が軽微な作業化するので内製するかビジネス層が自分でアプリケーション作ろうとすると思うし、単価という概念自体なくなるのかもしれない。
まあ生成したアプリケーションに関して結果責任・説明責任が残るので人間は最後まで必要になるだろうけども開発を委託する必然性は弱まると思う。
もちろん自然言語やデータモデルを使って正しく要件定義するのはとても難しい作業なので頭の悪いプロダクトマネージャーはそこでつまづくだろうけど、そうしたPMは市場から淘汰されるだろうし正しくPMな人が出てくることも予測される。
まあ要件定義自体を生成されたアプリケーションを使ってデバッグして手直しして開発工程をもういちサイクルまわすのがたいした問題じゃなくなる世界なので、このような世界では要件定義の難しさもたかがしれているとも言える。
技術的特異点なんて絵空事と思ってたけど、過渡期な文章生成言語モデルっていう技術ですらこのインパクトなのでこっからの数年、こうしたテクノロジが精錬されて我々の価値観や生活が変わるのが楽しみでならない。
「http リクエストを５０回実行するシェルスクリプトワンライナーをサンプルを表示してほしい。またリクエスト後にhttp レスポンスコードをチェックし500番台だったら実行停止してエラーメッセージを表示するようにしてください。」
ChatGPTにたいして上記の命令からはじめて、１０分くらいの作業時間で動作テストしつつ自然言語のチャットのやりとりでバグを取りつつ非同期実行などの追加仕様を加えてGo言語にリプレイスして出来上がったコードがこれです。
自分でコードはほとんど書いてませんが数行程度の手直しはしました。
注：このコードは結局500番台で全Goルーチン生成抑止/実行停止するわけではないので非同期実行化した際の仕様バグがまだ混入してますが、まあとりあえず動作はします。またGoルーチンを無作為に大量生成してしまうのでこれを抑止するような機能もあった方が良いでしょう。このレベルの仕様バグを解消するには非同期実行時の正しい動作を定義した上であらためて作業した方が手っ取り早そうですがこの文書の目的から外れる作業だし、めんどくさいので放置することにしました。コマンドライン引数周りの細かなバグについても同様です。
【所感】
ChatGPTは平気で嘘つくし、ドメインナレッジにまだ乏しいし、この例だと例えばsyncパッケージ使わない的な単純なバグも平気でしこんでくるのでまだ信用できないやつですが、嘘やバグを見抜ける程度の普通の技術者が監督するなら現時点の水準でも作業量を大幅に削減できるしオーバーテクノロジー感があります。特に小さくて雑なアプリケーションを書いて手法を実証するようなプロトタイピングフェーズなら現時点の技術水準でも大いに役立つでしょう。
我々ITエンジニアは今後１０年くらいのスパンで言うならば課題設定能力、ドメインナレッジの注入、コードレビューの力量とQAの力量、そして役立つアプリケーションが本当に役立つかを実証する能力（ビジネス的？）が問われるようになってくのでしょう。そして最終的には目的の設定と評価のフィードバックループを回し続ける現在のプロダクトマネージャーのようなスキルセットに移行する事になるのでしょう。
前職と比較すると平均技術レベルはマジで変わったように感じる。
前職だとクリーンアーキテクチャやらCI/CDやらは言葉の意味すら知らない人も多かったけど、
今の職場だとイケてるエンジニアは当然知ってるよねみたいな概念は最若手含めてほぼ全員理解してる感じ。
FargateやらKubernetesやらGraphQLやらAWSやらGCPの聞いたことないサービスやら新しい技術は常に吸収して実戦投入してて、
凡人エンジニアである俺にはついていくだけでも結構きつい、でも乗り切ったら市場価値もめっちゃ上がるんだろうなって感じもある
コードの品質についても常に議論を交わしてて、コードレビューの厳しさとか今までやってきた会社とは比にならないレベル。
命名として若干ニュアンスに違和感があるとかUT項目の境界値が1ずれてるとかでもどんどん突っ込まれるし、「よくわかんないけど動いてるから良し！」みたいなのは容赦なく潰される。
ペアプロ・モブプロはしょっちゅうみんなやってる。クラス設計に関する議題だけの会議とかも開かれたりする。
会社の規模も超大手ってわけじゃないけど俺が関わってるサービスの部分だけでも前職比較だとサポートとかデザイナーとか含めると10倍とは言わないけど近いくらいはいる。
開発手法もアジャイルの規模大きい版が実施されてて、それもなんちゃってじゃなくてちゃんとセオリーに則ってる形で管理されている。
ただ「これだけの人数いて、これだけ高い技術力があるのに作ってるサービス自体は俺が極少人数で枯れきった技術スタック使って作ってた前職のサービスと大して変わんなくね？」っていうのもまた感じた。
そら管理コストがかかる分10倍の人数がいたって開発速度が単純計算で10倍になるとは思ってないけど、前職で作ってたサービスの2倍分も価値を提供できてんのかなこのサービス？っていう感じというか……
前職は優秀な人を放任してタイムアタック的にひたすら高速リリース繰り返すみたいな感じで、(一応セキュリティ周りとか品質とか最低限はちゃんとしてたよ)管理コストが少ない分一人あたりの生産性は高かったと思う、属人化ってことだからそれが良いとは思わんけど。
動いてるものが同じなら採用技術がオンプレだろうとFargateだろうとGraphQLだろうとRubyだろうとウォーターフォールだろうとアジャイルだろうとユーザーにとっては関係ないし、
NetflixとかGoogleみたいな世界ならともかくとして、世の中の大半のシステムってそういうことじゃないじゃん？
難易度の高いイケてる技術スタックを使う＝必然的にエンジニアのお賃金が高くなるってことだから、経営者視点から見てもこういう選択って果たして正しいのかなぁって。
なんならエンジニアの賃金上げるための利権的な使われ方なんじゃっていう気もしてきた。
どう思うよ。
今ちょうど対処法に頭を悩ませてる、ここまでの人は正直人生初。
バグが多い、レビューの指摘数が多い、投げた仕事がわからない・できないで投げ帰ってくる、基本的なアーキテクチャが理解できてない、成果物が出てくるのが遅い
ざっくりとこんな感じ。
今のところこんな感じで対処してる。
正直「こんなに時間をかけて詳細に指示書いてこんな数の指摘を説明しなきゃいけないのだったらその人に振らずに俺が1から対応した方が数倍以上早いしこれは一体何を生み出している時間なんだろう」みたいなことを自問自答しながら作業してる状態。
これが新入社員とかだったら多分立ち回り方も結構変わると思う、できなくてもそれは経験不足から来るものだし、多分『教育』って形で結構時間かけて丁寧にペアプロして習熟度を上げてもらう感じかな。
2年目くらいでまだ戦力になれてない社員だったら多分3年目とか4年目くらいの誰かしら(できれば数人)と相談して教育係として俺との間に誰かを挟んでコミュニケーション上の距離を置いて負担をチーム内で分散する形にすると思う。
ただ経験年数長いで今更新人教育みたいなことをするとプライドを傷つけかねないし、ぶっちゃけこの経験年数でこれなら教育にパワーかけても効果薄そうっていうのもある。
あと単純に社内リソースが足りなくて俺がなんとかしなきゃいけない状態。
これどうすっかなぁ。プログラミングとはまた違う頭使うぞ。
