ソフトウェア開発における「1人で全部作ればいいのでは？」という案、実はかなり的を射ているのかもしれない？→さまざまな意見が集まる

づだ@Flutter @Zudah228

分からなくもない主張だけど、1人に依存してるプロジェクトは、さすがにヤバい気がする トラックナンバー1 twitter.com/rui314/status/…

Rui Ueyama @rui314

ソフトウェア開発におけるチームワークとかマネジメントの大切さとかはわかるけど、単に一人で全部作ればいいだけでは？ という解決策、実はかなりスケールするし、より良いものができることが多いと思うんだよな。

2023-02-21 17:36:43

ｆｊのＹｏｇ教祖様 @fjs_kyousosama

@rui314 それは絶対に真だが、 1) スケジュール管理など、マネージメントが何もできない 2) その作業をしている人の疲労度も判らないので、仮に作り終わるところまで行った後、どれぐらい休ませればいいのか判らない。健康被害が出かねない のでトップパフォーマンスは危険。

よんいち[1141] @x_1141

わかる。 同意。 そのあと「よく動く、誰も治せないブラックボックスができあがる」こともあるけど、でも同意w twitter.com/rui314/status/…

いりじうむ @irid_v2

一人で作ったものはその人しか保守できず、その人は今後それを死ぬまで保守し続けて他の仕事ができなくなることを除けばまあ…。 twitter.com/rui314/status/…

agent_tokiyomi @ATokiyomi

完成はすると思う。ただしその人がいなくなったら保守出来なくて捨てるしかなくなる。ちょっと引き継いだだけで簡単に保守できる代物ならそれは多分作る価値がない twitter.com/rui314/status/…

mtm @__mtm

ものすごくそう思うけど、そうやってできた汚いコードが大体直す暇がなくてそのままになってしまう自分 twitter.com/rui314/status/…

Rui Ueyama @rui314

特にまだ使える状態にも至っていないプロダクトを複数人で慎重に書いて入念にコートレビューしたりたりするのはあまりいい考えとは思えない。レビューなんかいらないからコードを変更しまくって取りあえずいい感じになるまで完成させるほうが優先度高い。

2023-02-21 17:42:03

🐻‍❄️IT業界に生きる北の野性 みんくま @minkuma946

不確実性は人からかなり発生するのでこれが理想なのはわかるくま。 だけどまだ各々の専門性を簡単にはできてないので難しいくま。 twitter.com/rui314/status/…

Deep Sea Life @DeepSeaLife7

@rui314 自分の納得のいくとこまで作ってしまって、自分のスケール限界に差し掛かって初めて他人を巻き込み始めるよりも、ある程度初期から巻き込んでおいて理念と充実と成長と自負を一緒に育んでいく関係を醸成するのに投資しておいたほうが、長期的なスケール速度は圧倒的に違うと思いますね。

Naofumi Kagami - 🇵🇸 lives matter @naofumi

@rui314 @usutani これは全くその通りだと思っている。下手なチーム開発より、個人開発の方が速いし、コードの品質は高くなるし、バグも少なくできると思っている。 ただし上手なチーム開発というのもきっとあって、それを追求する価値はあると思う。 世の中はほぼ下手なんじゃないかと思っている。少なくとも日本は

boom🏊pei @curryisdrink

わかる 一方で「いい感じ」がどういった状態なのかは、複数人で開発を続けてくのが決まってるなら定義しておきたいなとも思った twitter.com/rui314/status/…

Yosuke Obata @sukechannnn

これもすごく分かるんですよね。ゼロから何か作る時とか、個人がガッと作ってチームで開発できるところまで持ってた方が速いし、スキルが高い人がやれば設計の指針にもなる。ある程度できたらそれをチームで改善してく、みたいな。 twitter.com/rui314/status/…

ぴえ🐈‍⬛ @spielatoon

1プロダクトを1人は極論すぎるけど、各ポジションに1人配置の方がいいのは共感。 フロント1人、バックエンド1人みたいな。 同じコード箇所を複数人でいじるのはコンフリクトするし、コンフリクトしないように差配するのもコストがかかる。 50%アサインを2人とかマジで愚の骨頂。 twitter.com/rui314/status/…

Masato Kawaguchi @m_kawaguchi

自分も同感で同じ結論に至り実践している。特に立ち上げのフェーズ。 一方で順調に育ち、雑務が増えたりスケーリングメリットが得られる準備が整った後は、人を増やし自分は離れ引き渡していくのが良いと今は思っている。 twitter.com/rui314/status/…

白川トヲル🌗  @Hakuto_v2022

フルコンタクト新海誠スタイル。唯一無二、一撃必殺のオンリーワンプロダクトを作るには適しているので良さげ。メジャー狙うならチーム開発が良さげ。 twitter.com/rui314/status/…

👾🌗ぺんちゃん🌗👾🌗 @qgtjagtmdjpwmdt

使える状態になってないときにコードレビューをするのはあれやけど 環境がない時点での開発とかはどうしても机上やったりするしなぁ… twitter.com/rui314/status/…

ysmrnbt @ysmrnbt

昔はこの流派だったんだけど、最近は教える側になって感じるのは、コードレビューが1番色々伝授できるタイミングなのよね。別枠でトレーニングするよりレビューの中で実例とか議論する方が理解が深まる。 twitter.com/rui314/status/…

Yoshikazu Aoyama @blauerberg

コード書くのは1人でも（それが適切な場合は）いいと思うけど、別の誰かがコードレビューをするか、同じくらいの解像度でコードを理解しておくのは最低限必要かな。 この辺が、「個人の仕事」と「組織(チーム)の仕事」の境目になると思うし。 状況にもよるのだけど。 twitter.com/rui314/status/…

とろろ@心身ズタボロ再起中 @tororo_eco

良い議論だ twitter.com/rui314/status/…

shinter @shinter__

シュッと「こんなの作ってみました〜」みたいな人は優秀だなって思う twitter.com/rui314/status/…

がみ @ca4s

スクラムの「開発者を開発に集中させろ」って目的は結局これの実現な気がする twitter.com/rui314/status/…

Yuya Kusakabe @higebu

組織パターンにも出てくる話だ 相当大規模でない限り1人が早いんだけど運用も考えるとコードを理解している人間が複数欲しくなるので難しいなと思ってる twitter.com/rui314/status/…

uharaqo @uharaqo_jp

ここ数年「ぼっち開発」をやっている。確実なデリバリー、柔軟なスケジューリング、高品質で手戻り激減、圧倒的な生産性。それが普及しないのは採用が難しいのと属人的なマネジメントが必要になるからだと思う。 twitter.com/rui314/status/…