モノの作り方について

Question

今回の質問は、開発の仕方に関する質問です。

仕組みを100%理解できていれば、バグが発生するような実装をすることはない

といった考え方を前提とした上で、

ある時間的制約の中で、システムを作らなければならないが、現時点でスキルが不足している

状況だとします。

この場合、100%理解（したという自覚）がなければ、実装にバグが埋め込まれる可能性があることになりますが、
時間的制約のため、100%を目指すことが厳しい、といったジレンマに悩んでおります。

このような場合、どのように開発していくのがベターでしょうか。

Comments

[m.ts10806]

追記が多すぎて結局どの回答も全てに対応しきれません。回答者を振り回すだけになるので問題・課題を絞ってください。愚痴ならやめてください。

[退会済みユーザー]

teratailってこんな質問ばかりなのかよ。しょーもな。

[m.ts10806]

だからといって一気に全て消すのは状況を悪化させるだけですよ。「意図的に内容が抹消された質問」という指摘もあります。編集から履歴を見ることもできます。余計に回答者を振り回しているだけです。

Answer 1

100%理解できていれば、バグが発生するようなことなんてないはずなのです。

んなことないよー

思った通りに動かないのがバグ。
プログラムは思った通りには動きません。作った通りに動きます。
理解していることと、その理解に忠実なコードが書けることとは別だし、
その"思った"がお客様の欲するものと一致してる保証もない。

Answer 2

正直に申し上げて、元々の質問の設定がかなり乱暴に思います。質問者の意図が回答者に伝わりづらいので精度の高い回答は得られないのではないかとおもいます。

＞ある期間（時間的制約の中）で、趣味で何かを作ろうと思ったが、現時点ではスキルが足りていない。
という時点で理解が難しいんですが、趣味での物作りで時間的制約のある状況がイメージしづらいです。
さらにそれを業務であった場合どうであるか聞かれても、飛躍しすぎです。
業務であれば時間的制約内に達成するのは当然のことです。自分にその能力が無ければ正直に申告して対応を上司なり顧客なりに、できるだけ早く伝えるのは社会人なら当たり前のことでしょう？

Answer 3

趣味に限らず、理解せずに進むと後戻りが必ずあります。
それをどの程度許容できるかは、趣味と業務では天と地程差があります。
趣味でデスマーチを経験するはずもなく。

どんな進め方にするかについては、過去に色々な方法が検討されています。
ソフトウェア開発方法論

あなたの言われる、完璧な状態でなくても先に進むというのはアジャイルと勘違いされているかもしれません。
学習しながら進むということならリーン開発かもしれません。
トヨタに学ぶ！リーンソフトウェア開発の7つの原則

Answer 4

たぶん「理解」というのが、「誰にとっての」が抜けているように思います。

使っているアルゴリムを9割しか知らないのと、例えば「動的計画法」の9割も理解できているのとでは天地の差です。

今時間的制約があるということは、「わからない人にとって、9割理解できた気がする」、ということなので、これは個人に強く依存する前提になってしまいます。

調べることにもよりますが、とりあえずGoogle検索の上位を全部だいたい理解できた気がしても、たぶん7割も理解したことにならない、そんな感覚です。
のちに180度理解が誤っていたと気づくことも珍しくありません。

ただ言えることは、プログラミング言語は一切の忖度がありませんので、なんとなく書いたものがうまく動くことはありません。
なので、とりあえず10割を目指して理解したと思ってからでないとお話になりません。

---

それで業務においてですが。

そもそも最初から未知のことについて解を持てることはありません。
解があるようなことに対して車輪の再開発をするのは愚かなことです。
ゆえに、現実的な問題に対しては、とりあえず、ものを作りどんな問題が起き得るのか、知見を積むことから始まります。。

その後既存のものを修正して正すこともあれば、全面的に設計を見直すこともあるかと思います。
個人的な経験では作り直した方がはやいです。

おそらく今の流行りはCI/CDのようなもので、いわゆるfail fastを実現することを目指します。
早めに失敗して修正するのです。

個別の問題に対して良き解を持つことは難しいが、方向修正をしやすい仕組みを作ることは比較的汎用的なやり方があります。

---

ただモダンな開発のベストプラクティスが意味あるものであることを実感するためにはある程度の経験を積む必要があります。

今質問者がどの段階にあるのかはわかりかねますが、自分がある程度苦労したと思っているのであれば、体系的な手法を学んでみると良いかも知れません。
逆に困ったと考えたことがなければ、とりあえず手を動かすことが大切かと思います。

Answer 5

業務の場合ですが、まず見積もり段階で要求を達成可能か、納期内に完了可能かといった
判断を行います。
納期内に可能であれば、見積もりも提示できるでしょうしまた、見積もりを提示する以上
受注確定であれば完遂が必須条件となってしまいます。
現状、社内で技術や知識面で不確定要素が多いのであれば、納期に対してデスマーチ発生率が高くなり
収益も悪くなります。
瑕疵期間も少なからずありますし、もろもろ込みで判断したうえで会社として請け負うわけです。
個人がどれだけ意欲的であってもリスクや収益性を考慮した結果、見送りなんてざらだと思います。
見積もりの内訳についてもヒアリングされることもありますしね。

不足している知識、技術がリスクとして低くなるのであれば、受注に向けて周囲や上司を説得しやすくなりますし。
あるとすれば、想定よりも技術的困難度が高い、知識習得が進まないといったケースでしょうか
まずは納期に対してどれだけ遅れが発生しうるかなど別事案になりそうな気もします。
本トピックでは、各技術者個人の技術、知識に関する指標となるものもないので
ざっくりとなりますが、受注して仕事するうえで、納期が守れそうかが重要ではないかと考えます。

趣味である場合
その人がどれだけ意欲を維持し目標到達にむけて時間を割き行えるかになるかと思います。

Answer 6

まずは成果を求められる環境に身を置くべきですね。
嫌でも分かると思いますよ。

Answer 7

私はソフトハウス（SIerとか孫請けとか言われるところ）で育ったので、
趣味でも仕事でも、変わらず１でした。
そう言う乱暴な環境で育ちました。
プロジェクト毎に、環境が違う、言語が違う、作法が違うのが当たり前で、
そのために学ぶ時間なんて与えられたことなど殆どないからです。
（プロジェクトそのものが研究だった場合を除く）
お陰で、必要になるまで学ばないと言う悪いクセも身についてしまいましたが。

ただ、次のような畑違いの環境では、学ばずに対応することはほぼ不可能だと思います。
事務処理のプログラムしか書いたことがない人に、３Ｄゲームを作らせるなど。

つまるところ、「仕組みの理解＝処理をイメージできること」であるなら、学ばずに作ることは不可能ですし、
「仕組みの理解＝環境や言語仕様の理解」であるなら、作りながら学ぶことはじゅうぶん可能だと思います。

Answer 8

こんにちは。

1. 作りながら仕組みを学び（理解できていない部分があっても気にしない）、とにかく完成させる
2. まず仕組みを9割理解する。その後、ささっと作る

私の場合は趣味ならほぼ１です。私は技術側に偏っているので、できることが解っているものを作るのはあまり楽しいと感じないからですね。でもコンテンツを作るのが楽しい人はそうでもないかも。

仕事の場合は、その仕事のビジネス・モデル次第です。

• 自社企画の研究開発要素を多く含む開発の場合は1.が主になる場合も少なくないです。
• 請負の場合は、まずは見積もりを出します。見積もれないものは受注できないので2.です。100%できることが見積もり完了時までに判っている（＝100%理解している）場合が大半です。（それでもたまに見落としがあるので痛いです。）
• 委託の場合は、クライアントさん次第です。仕組みが解っていないものについてはその旨きちんと説明し、それでもトライして欲しいという依頼であれば遂行します。誠実に遂行する必要があるので結構きついです。

ところで、請負と委託は結構厳密に異なります。３０秒で分かる！「請負」と「委託」の違いが分かりやすいです。

Answer 9

時間が不足する中で、どれくらいの理解度でモノを作るか

100%理解してないのに完成するわけがないので、時間が不足とか関係なく100％理解できるまで手を出してはいけません。

teratailの「質問するときのヒント」にもあるんですが「今置かれている状況を整理し、わかっている範囲とわからない範囲を明確にしましょう」
明確にすることで「わかってない」ことがわかるので、その部分の理解度を埋める活動することが最優先です。
100％理解できるまで手を出してはいけません。マネージャーやリーダーの立場であれば、少しでも理解が不足しているメンバーがいれば100％理解できるまで手を出させてはいけません。
100％理解すること、理解させることもモノづくりの一連の活動の一環です。

Comments

[m.ts10806]

「○割程度理解」というのも同じ案件であっても定量化できるわけではないので、押し並べて100％理解以外考えるべきではないかと。

Answer 10

趣味の場合、

1. 作りながら仕組みを学び（理解できていない部分があっても気にしない）、とにかく完成させる

お仕事の場合、条件次第です。
とにかく動いて欲しいお客さん案件の場合と、お役所みたいに、後始末が面倒な場合、後からの責任追及が予想される場合、同じ対応はできません。
その他の場合もあるので、一概には。また、管理者として対応する場合もまた、異なります。
あ、あら探しをモットーとするお客さん案件も要注意ですね。

Answer 11

趣味の範疇なら、

3．そもそも時間的制約など設けない。興味があるなら時間がかかろうとも仕組みを理解しようとする(作りながら)。

ですね。趣味に時間的制約を設けるケースが思いつきません。

業務では、できるかできないかを明確にさせないとまずい場合が多いです。頑張ればできそうなら頑張る分も含めて見積もることはできますが、どれだけ頑張れば良いか判らないほど難しいことであれば「できない」と言うしかありません。当然、依頼主(上司だったりクライアントだったり)との相談・交渉が必要になる場合もあるでしょう。

100%理解できていれば、バグが発生するようなことなんてないはずなのです。

そんなことはありません。車のドライバーは運転方法を100%理解していますが、事故は起こります。それと同じです。

（ヒューマンエラーは理解とは関係がないためここでは考えないこととします）

バグのほとんどはヒューマンエラーです。それを考えないとするのはナンセンスです。

Answer 12

質問の意図が分からないな。
前提として仕組みが分からないものは作れないというのがある。
仕組みを分からずして作ることなどできるのか。（いや、できない。）

Comments

[退会済みユーザー]

制約がすっかり抜けておりましたので、本文を修正致しました。