職人気質総悲観論
「ソフトウェア職人気質」（ビート・マクブリーン著、村上雅章訳：ピアソン・エデュケーション：2300円＋税）なる本を先程読了致しました。
副題が「人を育て、システム開発を成功へと導くための重要キーワード」となっておりまして。プロジェクトの進め方から人材の育て方、開発環境の構築方法からテスト・保守も含めた開発の視点、と範囲盛りだくさんの内容でかなり充実していた、のですが。
なんかねぇ、悲しくなっちゃいましたよ私。
いや、この本が悪いって言ってるんじゃないのよ。念のため。つーかこの本いいよ。機会あったら読んでみ。比較的薄い本だから抵抗無く読み進められます（なんらかの形で開発に関わった事がある人じゃないとさすがにつらいかもしれんけど）。がっくりきてんのは本の出来とかそうゆうんじゃないの。
いやね。読めば読むほど期待感が焦燥感、そして絶望感に変わってくのがわかるのよ。読了して、んじゃ自分の環境どうやって変えていけばいい方向に向かっていけるのか考えたら。結論。
全部変えないとダメじゃん。
うっがーーー！開発手法はもちろんのこと人材育成からプロジェクト形態から何から何まで全部ブっ潰さない限りこんなこと夢の夢のまた夢じゃー！！やってられっかクソボケー！破壊じゃ破壊！殴れ！刺れ！犯れ！殺れ！壊っちまえーーーーー！！！デストロイーーーーー！！！
はっ、今何が俺に憑依した！？
とまぁ型どおりのボケはおいておきまして。ちなみにこれ何が元ネタなのかなぁと検索かけてみたら、少年ジャンプに連載されてた「無頼男（ブレーメン）」からの引用なのね。ちゆ１２歳でもネタにされてます。とりあえずこのセリフ、インパクトだけは無駄に満ち溢れてますな。だからおいとけっての。
話戻す。でも正直な話、これマジに実践しようと思ったら、オフィスに手榴弾２発か３発投げ込んで上も下も関係なしに殺戮した後にゼロから作った方が早いんじゃねぇか？とか真剣に検討してしまいました。無論そんなことしたら理想の環境作る前に刑務所で自分の生涯終わってしまう可能性の方が格段に高いのは目に見えてますのでやりませんが。当たり前だ。
ま、ダメだダメだ言ってるばかりでも話は全然前に進みませんから、例の如くかなり端折りつつ「職人気質」の中で示されてるプロジェクト形態と現実を比較してみましょーかね。
これによると、推奨されるプロジェクトの人員構成は、まず一人、または少人数の熟練職人を中心として構成されます。そしてこの職人が集める形で、職人一人当たりに数人の弟子（アプレンティス）、これとは別に職人一人当たりに数人の一般職人（ジャーニーマン）を加え、ひとつのプロジェクトチームとして機能させます、と。
こう書くとどこぞの工事現場みたく聞こえますが、誤解してはならないのは職人、または弟子なんて肩書きは、ここでは純粋に各個人のスキルを表す程度の意味しか持ってない、ということですな。単純に教え教わるの方向関係のみを示してると。
またこれら３つの役割がピラミッドでもなければフラットでもない、というのも大きな特徴といえるでしょう。中間管理職のよに一般職人が入るのではなく、あくまで熟練職人→弟子、一般職人→弟子、そして熟練職人→一般職人という２者の関係の中でスキルの熟練を図りましょうと。
で、案件をそのプロジェクトが実施する場合、設計からコーディング、テスト、リリース、そして保守まで、このすべてをプロジェクトの内部で完結させていくという大前提を存在させています。コーディング＝下級、要件定義＝上級なんて区分は存在しないんですな。熟練職人であってもコーディングやテストは行うし、弟子であっても要件定義に参加する、幅広い分野をまんべくなく押さえ実現できることの方が重視される形になるぞと。たとえプロジェクト内部で人材変動が起こったとしても、一般職人が熟練職人となる、または弟子が一般職人と進化する形でプロジェクトの中で引き継いでいき、ソフトウェアがいつまでもそのプロジェクトの中で管理維持できるようにしましょうと。 まぁ大体こんな感じになる訳です。改めて言っておく。この説明むっちゃ端折ってるからな。間違って要約してる危険性だってある（笑）。詳しく知りたきゃ本を読め。
さてと、じゃあこれを現状の（一般的な？）会社形態のモデルに当てはめ・・・。
・・・・・・。
熟練職人ってどこにいるんですか？
のっけから前提条件成立してないんですけど。しくしくしく。
いや、確かに探せばいるだろうさ。世の中すっげー人はいっぱいいる。でも、そうゆう優れてる人はとっとと管理職一本槍にひきぬかれてしまうという悲しい現実がある訳で。開発現場に留まることを許されないんですわーな。「留まってもいいけど、そこにいる限り給料は上がらないよ」なんて現実が思いっきりまかり通ってると。よって優秀な人程どんどん現場現場から引き剥がされてしまう・・・というのが現状でしょ？
実際、今までにおしごとしてた中で、そうゆう人何人も見てる。腕は確かなのよ。聞いてもほぼ理想的なロジック・開発技法がすらすらと出てくる。よっぽどその人が組んだ方が短い期間で精度の高いモノを作り出せるんですよね。でもその人がやらされてるのは朝から晩まで会議会議ドキュメント会議進捗会議。しかも他人に振り回される仕事の方が圧倒的に多いから、自分の仕事は休出手当ても出ないのに土日に出てきてしこしこと。こんなんじゃ現場に目を向ける余裕なんかとっくの昔にひねり潰されちゃいますわ。企業としての規模が大きいところにいる人程、首を縦に振っちゃうんじゃないです？
そうゆう人を再び開発現場に戻す勇気がお偉いさん方にあるのか？今見てる限りでは「無い」としか断言できねーんだよな。あぁ悲観論。
また、問題は熟練職人の確保だけに限った話じゃないです。仮に偶然の産物でひとりの熟練職人さんを確保できたとしましょうよ。こうゆう仮定を打ち出さなければならないこと自体が悲劇そのものなんだけど。
そこにぶらさがる一般職人、もしくは弟子を少人数に絞り込んでプロジェクト形成することなんてホントにできると思うかえ？人海戦術のクセ抜けずにひっつけられるだけの弟子ひっつけて職人さん過労死させるか、もしくは口開けてエサ放り込まれるの待つだけの弟子がわなわな増産されるのが現状では関の山。数週間も待たずに旧態依然としたPM-SE-PGピラミッドに戻っちゃうのが目に見えてますよ。テスターや保守は相変わらず丸投げで組織の蚊帳の外。今の開発手法って総じてテスト保守軽く扱いすぎだし。
結局「人を育てつつ」「プロジェクトをリリースさせる」の両立に目が向かなくなるんですねぇ。始め順調かもしれないけど、追い込まれれば追い込まれるほど視野狭くなっちゃって、気が付けば優先されるのはリリース期日のみ。挙句の果てには「ダメとわかってても突っ込め」「できなくてもやれ」でにわか特攻部隊のできあがり。みずほ銀行みたく望む望まざるも問わぬまま鉄火場に有り金突っ込んでるプロジェクトなんざ世の中掃いて捨てる程ありますって。みずほが特別だなんて思ったら大間違いだぞ。
プロジェクト内でのみ完結させるってのも現状かなりきっついですしね。大きいところは大きいところで自分ところで技術者抱え込む余力もないからどうしても協力会社とかいいつつ外に丸投げしちゃう。小さいところは小さいところでお金欲しいからそうゆう案件をもらっちゃう。でプロジェクト終わって解散しちゃうと残るのはかろうじて動くアプリと訳のわからんコードだけ。こんなんでは自分ところに知識残らないのはわかっちゃいる。いるけど余裕がないからやめられない。この悪循環の繰り返し。
これは私とかの派遣で貰う（送られる）方にしてもいっしょなんですわーね。月日重ねてそれなりの知識とか体験とか重ねて、その派遣された先では重宝する存在になったとしても、契約終了とかでそのプロジェクトおさらばになった瞬間、派遣元の知識は大半が役に立たなくなり、派遣先は必要な知識を失う、という悲劇があちらこちらで発生してるんですな。
一旦この悪循環切れさえすれば「体験知識の空洞化」にも歯止めかけられそうなんですけど、これをやるには現場だけじゃなくて、経営TOPとしての決断が必要。でそれを踏み切ってもらうようにするには・・・望みがなさ過ぎる・・・。
あーなんか書いてたらもうイヤんなっちゃったなぁ。首吊っていいすか？
とはいえ「じゃあもういいや」の思考停止ではそれこそ蟻地獄の如くずぶずぶと沈んでいくのは目に見えてるんで、なんらかしらの手を（他人どうのこうの関係なしに）打たなきゃいけないんですけどね。どこから手をつけていいものやら。手っ取り早く環境変えるなら・・・やっぱ転職かなぁ。でもこのご時世、かつ現在の企業倫理じゃ、結局はどこも似たりよったり・・・。となるとやっぱ起業？ムチャ言うなーあんなめんどくせーことやってられっかー。
をい。
つー訳で結局なんかダラダラと書いてしまいましたが。つい最近「文章短くしよう」とか言ってたくせに嘘ばっかりだな私。まぁいいや。
別に今回取り合げた「職人気質」をムリヤリに全面採用せぇなんて思うわけではなく、いやちょっとは、いや実のところかなりあったりもしますが、まぁできるところからちびちびとやってくしかないんでしょうねぇ。「このままじゃあかんだろ」という危機感は常に持ちつつ。気合入れすぎて死なないよーに気をつけましょー。をー。
なんか投げやりなシメだな。オチ考えられる希望もねぇよしくしくしく。
その思考、なんか違う。