ここの2人の人がいる。
プログラミングの仕事を早く終わらせることが出来るのはどちらだろう。

・Aさん
 自分のPCに向かいもくもくと作業を進行する人

・Bさん
 誰よりも仕様を聞きに行き、何度も確認しながら
 その合間に自分のPCに向うような人
 

AさんがBさんより早く終わらせるための条件は限られている。
・作るべきものが見えている場合。
・Aさんが仕様確定者である場合。
などなど。


なぜか。
だいたいの現場の状況では、
両者のスタートラインが「仕様なんてよくわかっていません」から始まるため。
答えのない状況から模索することを要求されたとき、
・ドキュメントを読み、結果を予測して作業をする
・ドキュメントを読まず、結果を聞いて作業する
の、極端に分けた作業形態だと後者のほうが確実性が高い。


プログラミングの作業内訳を以下でわけるとすると
 (1) 考える時間・理解する時間
 (2) プログラム作る時間
 (3) 動作確認する時間
 (4) 修正する時間
後者は(2)〜(4)の繰り返し
前者は(1)〜(4)の繰り返し
となる。
単純に内訳を比較すると後者のほうが早そうですよ。
ミスを前提に再考慮した場合。
ミスの影響はどこにかかるかを考えたら、やっぱり同じになるでしょう。


だって人は勘違いするんだもん。
圧倒的にタイピングが早くても、作る方向を間違えていたら
軌道修正に時間かかるやん?
その時間ってまるでムダやん?
ってこってす。

プログラミング作業における効率化のポイント

主力とマイナス要因との差は何か?
パッと思いつく内容であるところの
・手が早い
・言語の慣れ
は決定的な差とはなっていない。


プログラムを作る前に、作りながら、
あるべき姿をどれだけ明確に共有するかどうかにある。


「答え」をコードを構築する段階の早いうちに得る。
「未定」の場合は想定される対応を取れるようにコードを構築しておく。*1
「仕様変更」には当たり前に備えることはもちろん、
変更理由を把握しておき話をし、仕様設定者のおもいつきを事前に抑止することも大事。
ってことをやるのが主力。
そーゆーのをやらないで「こーすればいいんですよね?」っと自分の思い付きを押し付けようとするのがマイナス要員。


早い話が。
・答えを得る
 ↓
・その通りに作ればよい
 ↓
・作成コスト、再構築コストが低下する
 ↓
・作業時間短くなる
 ↓
・(゚д゚)ウマー
ってこった。



プログラミングにまつわる以下の作業のうち、効率化できるのはどれか?
 (1)コード作成する時間
 (2)考える時間
 (3)他人と話す時間
 (4)修正している時間


答えは全部だが、自分だけで何とかできるのは(2)と(1)。
(1)は訓練を要するが、(2)は答えの通りに作ることで圧縮することが可能なため、即効性は高い。

*1:結合度を下げておく当たり前の対処

使えないヤツその後

順調に0に近づくように調整をしながら日々がんばるぼくら。
・簡単な機能を移植させる
・不具合対応させる
・一応望み通りに動くようになる


っとここまではなんとなくよい。
が。
しかし。
主力となっている方がふっとコードレビューしてみたところ。
・ムダまみれ
・意味不明
リファクタリング実行


んでソースコードはわりと平然さを取り戻した。


振り返ればヤツの成果(?)はほぼない。
応対時間、リファクタリングの時間、リファクタリング実行に伴う調整の時間などを考慮すると
「いなくていいんじゃね?」
って結果になっている。


マイナスの要員というのはこーゆーものだなとしみじみ思う。

単なる思い付き

理解不能な人種に対しては、ブラックボックスなオブジェクトとして接すれば
日頃のぼくらの技能が行かせるじゃないか(・∀・)。
・IFを定義する
 → その人へのインプットアウトプットを決め、答えも決めて仕事を共有する
・ある程度テストする
 → カバレッジテストまでは不能だと我慢する


これなら判断しやすいじゃないか。
面倒くささは「今後その人に費やすであろう不毛な時間」と比較しながら考えたらよいっとφ(..)*1

[雑記]

よくよく振り返れば今回は、サボったポイントだったな。
事前に準備できることはする。
圧倒的な処理能力を生かして対処できることはそこでしてもいいが、
結果が伴わないようであれば準備でがんばれ!って昔の自分にも言われそうなことだな。
最近のボク錆付きそうヽ(;´ー`)ノ

*1:文字にするとなんてドライな内容なんだw

人物判断において、今まで自分の目が大きく間違ったことはない。
っていう要素に従って行動することは反省しない。
が、いや、ちょっとまて。もうちょっとなんかないか?っと探さない自分は今後の反省点とする。
今回もそうであった。
けど次回はそうでないかもしれない。

なんで「わからないからできません」って口にできるんだろう。
なんで「わからないのでちょっとがっつり教えてください」とか言えないんだろう。
わかりやすいところで保身に走られると、結局戦力外として扱う以外になくなるじゃないか。


ボクは文句を言うやつは嫌いじゃない。
同じ所目指して別の方法をとろうとか、別の手法でやってみようとか、
そういう言い合いとか主張とかはあって当たり前だと思っている。
傭兵部隊は育ちも文化も違うんだから当然やん?
そんなやつらが同じ仕事を完遂するんだから楽しいんだ。


でも「お前のせいでできません」ってな具合に頑なになられたらどーしょーもない。
じゃあどうしたら出来るようになるでしょう?
次の行動をこうしてくれたら動けますとかいう言葉は無いのか。
言ったのになかったよな?
何か言いたいけど飲み込んだ表情でもなかったよな?

「今出来ない」は仕方がない。
でも「今やろうとしない」には気持ちを汲むことすらしない。

なんか、こう、イッィィィィィィって気持ちになった。
ふぅ。
文字にしたら落ち着いた。

わからないってのは日常

わからない仕様に対した時、
間違った記述を見つけた時、
どうするだろう。

(1)こうですか?っと確認する
(2)出来ない理由にする
(3)自分の解釈で押し進む


どんな状況下であれ、「仕事を完遂する」ことを目標においているならば(1)以外の選択はありえない。
対外的に、対会社的に身を守る必要がある場合は(2)かもしれないが、たった1点ではなくまとめて資料化して武器にするのがあり方だと思っている。


先日1発目のプログラム作りで(2)の行動をとったアホがいた。
同じタイミングで増員された別の人達は(1)だった。
(3)はいなくてよかったと思っている。


経歴が煌びやかだろうと、資格をどれほど持っていようと、(2)の行動をとるやつは戦力外である。
素性を問わず(1)の行動をとる人達は戦力換算ができる。
このへんはアジャイルでもウォーターフォールでも手法は関係のない、
「人」の話。