いろいろ足りない

不足分を補いたい

髪が長くなると良くないことが起きるのは自分だけだろうか

久々におつらい事象が起きたので、反省ついでに書いておく。
結果的には自分の知識不足に起因しているのだが、コミュニケーションをサボってしまったというのもある。
言い訳をするのであれば、チェックする人間、ゴーを出す人間がそれぞれ仕事放棄していたことを全面的に出したいところだが。
あとは未経験者のみが集められていたこともあって、そもそもの体制に問題があったと思うのだが。
そんな中で進めていて、実際今日までは平穏に進められていたのだが、お約束なのか突如爆発してしまった。
まぁ何も起きずどうしようもないタイミングで爆発するよりは良かったとポジティブに思いたいが、
社内ヒエラルキー的な格付けがなされ、信頼貯金が赤字となり、今後を思うとどんよりするな〜と思っている次第。

まぁ何より嫌なのは、ウォーターフォールで開発するのが嫌で柔軟に進めていきたいと思っていたのだが、
ほら見ろと言わんばかりに設計の重要性を突きつけられているところ。
いや、設計の重要性は否定しないのだが、一生懸命設計に時間を割いている(そしてトラブルが起きている)のを見ていると、
さっさと動くソフトウェアを作って改善した方が良いのではないかと思っていたのだ。

また、今日で一通りの実装が済んで、余裕のあるうちに終えられたなと安心しきっていたところで爆発したものだから、
メンタルへの影響が酷かった。
はぁ……。
今後を見ても、今回のような案件が発生することも少ないのだろうが、自分の駄目なところはしっかりと学んでおきたい。

工数について思うこと

工数見積がしんどい。
何故かといえば、結局あてにならないからだ。
そして不確実性溢れる工数を基にしたスケジュールで、開発が遅れているだの何だのをすることになる。
一体何を基準に遅れたなどと言っているのかと疑問に思うことがある。
どうやら最初に出した工数とやらは絶対視され、確実性の高いものだと認識されているらしい。
プロダクトの欠片も一切無く、検証の一つもされていない最も不確実性の高い時期に算出されたものであるにも関わらずだ。
さらにはその見積もりに3点見積もり等が用いられているわけでもなく、大抵各々の勘に依存している。
自分の場合、そうやって工数が多いだの少ないだのやり取りしている間にクラスの一つや二つは書けるし、バカバカしいものだと思ってしまう。
プロダクトを評価できるのは工数でも設計書でもなく、実際のプロダクトでしか無い。
よく分からんやり取りを重ねる時間があるのであれば、プロトタイプの一つでも作った方が有意義に時間を使えるし、まだ見ぬ不確実性の検証にもなる。

……とまぁ現状のストレスを発散させるために書いてみたが、上の人は上の人で要求されることが違ってくるのだろうし、
何かよく分からんけどやってみなはれでGoサインを出せるかどうかは自分がさっき否定した勘に大きく依存してるっていう。
予めざっくりとした基準を用意しておいて、そこから大きく離れていないかという指針にするのは割と現実的な落とし所なのかもしれない。

工数の善悪云々ではなく、プロダクトを作るために頑張って正確な工数を求めるのは目的ではないし手段ですらないでしょ*1ってのが一番言いたかったことかもしれん。

*1:もちろんその仕事の条件に依る、自分が置かれている条件においては確実にそう言える

抜け出してみないとわからないこともあるわけで

もう少し役に立つ内容でも書けば良いと思うのだが、構わずだらだらと駄文を垂れ流す。
例によって前職と現職の違いに言及してみたい。

個々人の優秀さでいえば前職の方が遥かに上だと言える。
しかし、組織として上手く回っているのは遥かに現職の方が上である。
その差はどこにあるのかと考えてみる。
「は?」と思うような常識外なことを強制されたり、モチベーションを下げるようなデバフ効果を毎日発してくるような論外な点は多々あり、それらを除きつつ考えるのは難しいのだが、
組織を上手く回す観点で考えたとき、そこには仕事を任せているかどうか、もっと言えば組織として弱い部分を見極め、そこにのみ介入するマネジメントの差があるように思う。

前職では上長が何であれ介入する、仕事を任せないような文化があった。
そこで厄介なのが、介入する側の専門知識や技量に大きく左右されてしまうところだ。
仕事を任せておけば良いところに限って、なまじその専門知識を持っているだけに「じゃあお前がやれよ」と思う程度に口出したり、
逆に専門外で何もわからないところまで口を出すせいで、成果物がむちゃくちゃなものになってしまったり。

実際、自分の方が経験もあり上手くできる、という場面は多くあるのだろうし、場合によってはそうした方が良い場面もあるとは思う。
ただ、組織として考えた場合に、このやり方は短期的には上手くいっても長期的に上手くいかない。
上は上でレベル感としてはただの作業だし、下は下でその経験をする機会がなくなる。
そこに人の成長はなく、組織の成長もないからだ。
誰にも経験値が入らない状態に陥る。
組織が止まる。


そんな状態が数年続けば、何も回っていないように思えるのも当然だったのか、と環境の変わった今ふと思ったのであった。

原点

新天地で働きだして、およそ一ヶ月が経った。
それが良かったのか悪かったのかはまだわからないが、前職にいたままでは手に入れられなかったものを手に入れられた。
妙な縁、あるいは呪いというべきか、それが10年近く続いていたので、それが解かれるまで、まだまだ時間がかかりそう。
楽しいことはなく、同時に辛いこともないようなそんな平坦な場所で、それが逆につらくはあるのかもしれないが。
そんな時こそ、ここに来た原点を思い出したい。
自分の人生を取り戻すんだって。

組織の停滞

もう書くことはない、次に気持ちを切り替えようと思っていたのだが、まだまだ書きたいことは出てくるようだ。
人の適応力は凄まじく、地獄を忘れてしまいそうになるので、記録として残しておこう。

続きを読む

組織の終焉

長年、自分が知りたいテーマだった。
組織の始まりがあれば終わりもある。
その終わりとはどのようにして終わるのか。
会社の末期には何が起きるのか。
自分の目で見ておきたかった。
その終わりのはじまりはどこから始まったのだろうか。

組織としてはうまく行っていた時期もあった。
到底潰れないだけの資金が準備され、優秀な技術者が雇われ、人が増えた。
比較的順調にプロダクトの開発も進んだ。
そしておかしなことも起きた。
長年開発し続けてきたプロダクトが、セールス部員の努力もあってようやく世間に認められ芽が出てきた正にそのときに事業転換がなされたり。
組織力に課題があったため組織編成に注力し、来月から始動する正にそのときに部のトップの交代が命じられたり。
挙げ句、何の専門性も持たない人がそのポジションに就いたり。
他にもおかしなことは多々挙げられるが、その結果に共通しているのは人が辞めるということだ。

終わりのはじまりとは、人が辞めるような要因を作り出すことだと自分は思う。
特に自分が見てきたのは、人の気持ちを無視した理不尽さに加えて、経済活動や利益追求の論理も満たさないまさに「おかしなこと」ばかりであった。
人が辞めること自体がさらに人が辞める要因にもなり、負の連鎖に繋がることもある。
教育コストをかけ、業務知識を持った人が次々に消えていく。
人を雇えばいいと経営者は考えるのだろうが、人が増えても組織の戦闘力が低下したまま。
必要とするキャッシュは増え、その状態でさらなる効率を求められる悪循環に陥る。
それはもう組織の終焉なのだと思う。

ここからは蛇足だ。*1
果たして今後その組織がどうなるのかは知らないが、さらなる崩壊に進む要素にならまだ興味はある。
これまでは全体的に若さがあった。その勢いで乗り切ってきた面がある。
時間は戻らない。
過去と同じバイタリティで難局を乗り切るのもいずれ限界が来る。
人は老いには勝てないのだから。
また、彼らは結婚した。子を授かった。彼らは家庭を守る必要がある。
一方は家庭を守るため、一方は雇用維持のために賃金を上げていく必要が出てくるが、そこにも限界がある。
そしてそのキャッシュのために新しく雇う人数を制限する。実際は0であろう。
組織の新陳代謝が行われなくなる。
変化なく、革新なく、組織としても老いる。それで望む成長ができるのか疑問である。

これらを避けるための唯一無二の方法は人材を大事にすること、ただそれだけ。*2

*1:そこから逃げ出し次に向かう自分自身のモチベーションでもある

*2:人数が多ければまた別なのかもしれないが、それは終わるまでのスピードが遅くなるだけだと思う

出会う順番って大事だよね

要はちゃんとしたアーキテクトに出会ったことが無いこと、そしてアーキテクチャが必要となるほど大きな開発に携わっていない*1ことが要因。アーキテクチャやアーキテクトの必要性を否定的には思わない。
という前提の下、ぐだぐだと書く。

*1:いや、本来はどんなものであれ必要だと思うよ

続きを読む