プロセスとアウトプット
華々しい成果というのはその煌めきの10倍、100倍泥臭い仕事が多い。
予め技術的に可能だとわかっていても、実際にやらなきゃいけないことは泥臭いやつが、10倍くらいある。
この相場観が欠落したまま低コストでやれなんて言っていたら新しい物が生まれない。
— hiroki kishi (@nogahighland) 2015, 10月 14システムは人ができないくらいのことをものすごいやってくれて凄いんだけど、思いやりとか全然無ぇから、毎度毎度書いて教えなきゃいけねぇのがたまに馬鹿らしくなる
— hiroki kishi (@nogahighland) 2015, 7月 30システムという仮想世界と、大工といった実世界の違いはその複雑性が目に見えるか見えないかの違いなのだが、ユーザーからはもちろん、管理者にも見えないために「作っちゃいなよ」とか平気で言われたりする。さらに、夏目漱石が
世の中に片付くなんてものは殆どありゃしない。一遍起った事は何時までも続くのさ。
と言っていたりもするように、作りっぱなしのものなんて殆ど無い。思いついたように「機能追加してみようぜ」なんてことはざらにある。
それ自体は何の問題もない。創造性が溢れてきて具現化したくなることは、人間冥利に尽きる。ただ、作るにあたっては受け手にその責任を全うしなければいけないと思っていて、そのためには「作る」作業が効率化されているべきだと思っている。
何もコーディングだけではなくて、知識共有の習慣化だったりソースコードの標準化だったり、自動化だったりする。
- 個同士は編隊されて合議したルールに基いて行動することで相乗効果を発揮する
→チームメンバーがお互いのナレッジを共有しあうと、効率的だ - そのためにリーダーやマネージャが組織を作る
→リーダーはそういうチームづくりを促進すべきだ - その先にアウトプットがある
→そうすると早く作れるだ - チーム同士も個と同じ
→チーム同士も共有するといいだ
「運用改善好きそうだよね」と言われたことがあるけど、価値創出に集中したいから余計なことに手間取らないようにしたいのであって、本当は攻めの方が好きです。汚ぇモン作ってんじゃねぇという怒りのモチベーションが好きそうに見えるらしいです。
— hiroki kishi (@nogahighland) 2015, 6月 23アウトプットが全て、というアドバイスはコーチングでいうところの正論だけどアドバイスが具体的でない、という悪例だと思う。
ゴミをアートにする人はいるが、普通は質の良い素材や考え方が良い物を作るのだから、同じように技術力やプロセスも大事なはず。それを軽視したらアドバイスとは言えない。
— hiroki kishi (@nogahighland) 2015, 6月 5あんまりにも状況が酷いとこんなふうになってしまうのだが、実はしれっと効率化して白鳥のように優雅に良い物を作りたいですよねって話です。
