なかなか触れるには勇気のいるエントリーですが(笑)、あえて行ってみる!
やっぱり変だよ日本のモティベーション
—
何をやるのか・何故やるのか、という動機付け(モティベーション)が明確だから、それを実行に移すためのやる気が湧いてくるわけです。逆に言えば、きちんと動機付けされていれば、やる気がなかろうが何だろうが「仕方ないなー」と思いながらでも、「やる」ことは出来るんですよ。そもそも、やる気があるからやるんじゃないんだよ。やるからやる気が出てくるの。
—
最近考えていたのが手戻りについて。
みんな手戻りを発生させたくない。なぜか。
後工程で手戻りが発生するほど対処コストが増加するから(そんなグラフ見たことありますよね)。
確かに電化製品や車などの「物」はそうなのでしょう。また、ソフトウェアも、コーディングのためにマシンを占有したり、コンパイルに何時間もかかったり(ってそういう時代を経験していませんが)、あるいは配布のためにあちこちをインストールして回らないといけなかったり(これは経験しました)という場合は、やはり成り立つでしょう。
しかし、現在はソフトウェアのその問題に対しては色々な対策が採られてきており、最初にグラフが作られた時とは状況が違うと思います。仮に似たような形になるとしても、値が違う。例えば、以前は納品後の手戻りコストが100だとしたら現在は30くらいになっているのではないか。とすると、以前は100のコスト発生を回避するために、前工程で50くらいのコストを費やしてよかったかもしれませんが、現在は前工程で50のコストをかけるよりも、手戻りしたほうがコストが低いかもしれない。
いや、30だろうが100だろうが、予定していないコストの発生は困る、と言われるでしょうが、以前も100全部ではないにしてもリスクと称してコストを計算していたのではないか、それが100のときは50だったので、30の現在は15にしてしまっているのがおかしいのであって、昔は50だったのが現在は30です、としておけばよいのではないか。
こういう抽象的な話はあまり意味がないですが、そういう観点で検証してもよいのではないかと思います。
ところが、手戻りにより発生するのは、コストの問題だけではない、すなわち「モチベーション」の問題です。
手戻りによって発生する作業を行うのは「モチベーション」が下がる。
なぜか。
・自分の最初の作業が無駄だったように感じる
・コスト増加の責任が自分にあるように思われる
・後になってさらに手戻りが発生するように思われる
・・・
で、「いやだな」「モチベーション下がるな」という感覚を持つことになります。
しかし、仕事とは約束です。ある意味義務です。最終的にそれを行うことが「正しい」のであれば、手戻りであろうがなかろうがやらなければならない。コストの分配(交渉とか)もそれはそれでしなければならない。
すなわち、「正しい」かどうかの判断と、「いやだな」の気分は別物として考えなければいけないと思うのです。
「きちんと動機付けされていれば、やる気がなかろうが何だろうが『仕方ないなー』と思いながらでも、『やる』ことは出来るんですよ」というはぶさんの言葉の通りです。いやな気持ちは酒でも趣味でもうっぷん晴らしをしながら、それでも仕事はやらなければいけないのです。
ということで、「正しいこと」の判断基準を持ちましょう。「きちんと動機付け」しましょう。自分でモチベーションを生み出しましょう。
手戻りの話に戻ると、上流工程をしっかりやって、前工程の成果をもらさないように設計を詳細化していって、と言う認識は入社以来の教育の賜物です(賜物というのはいい言葉ですが、要は植えつけられてしまったものです)。しかし本質がそうであっても、やり方は自分の経験を踏まえながら勉強すべき。勉強して基準を持つべき。
結城さんのエントリ「ソフトウェアは、私たちの想像よりもずっと複雑」
—
実際にコーディングしなければわからないことがたくさんある。それと同じように実際に本文を執筆しなければわからないことがたくさんある。コーディングしてみて得られた知見をフィードバックしなければ、ちゃんと設計できないのではないか。本文を執筆してみて得られた知見をフィードバックしなければ、構成は定まらないのではないか。
思うに、ソフトウェアも、本も、想像以上に複雑で大きなものであり、人間が誤りなく全体の設計を前もって行うというのは不可能なのではないか。設計が不要だとか、コードがすべてだという気持ちはさらさらないけれど、「コードを書かずに行う設計には何かしら本質的な限界がある」とは言えそうだ。
—
本執筆のプロ中のプロ(私の中での結城さん像)が、本文を書いてみてから構成に戻ると言う。それを受けて平鍋さんが「逆問題」「悪構造問題」と言う言葉を紹介して思考のヒントをくれている。
本を書くときにさえ、よいものを作るために「手戻り」を起こす。それに比べたらソフトウェアは、いくらでも再利用して「手戻り」を無駄にしないことができる。しかも、詳細を先に作ることも、もっともっと短時間にできるはず。そう考えると、自分の中では手戻りは不正ではなくなるので、「いやな気持ち」とも無関係(仕事上、そういうことを言わざるを得ないことはありますが)。ただ、この正しさは相対的です。今時間がかかっている部分が瞬殺できるようになれば、やり方はどんどん変わるわけです。ボトルネックをつぶしたら、別のところがボトルネックになるわけです。ということで、日々精進するわけですね。
ちなみに、イベントに行ってモチベーションが上がるのはありかなと思います。人間みんなすべてに基準を持っているわけではないので、ほかの人の活動を見て自分の基準に取り入れると言うことはあると思いますので。基準ができることで、それに向かうという動機が発生するわけですね。
手戻り
最終更新日時 : 2017年10月18日
最近の投稿
-
引っ越し先のサービスダウン
-
このサイトは引っ越しました
-
Meet Magento 2018 – Google講演
-
Code4StartUp ~ UberEatsを作ろう ~ API呼び出し
-
Code4StartUp ~ UberEatsを作ろう ~ Facebook接続
-
Code4StartUp ~ UberEatsを作ろう ~ デザインなど
-
Code4StartUp ~ UberEatsを作ろう ~ cocoapods
-
Code4StartUp ~ UberEatsを作ろう ~ Swift続行中
-
Code4StartUp ~ UberEatsを作ろう ~ iMac購入して続行
-
格納型XSS システムアーキテクト試験より
トラックバック URL
http://jqinglong.wp.xdomain.jp/2006/07/02/%e6%89%8b%e6%88%bb%e3%82%8a/trackback/