前の会社にいた頃、尊敬する先輩がいた。SESでいろんな会社に常駐して多分20年ぐらいの経験がある人。その人から学ぶことはかなり多かった。僕はこの先輩に出会えただけでも前職を選んで良かったと思っている。技術的なことではなく仕事への向き合い方といった意味で。
目次
めんどくさいエンジニアの典型だった僕
僕がその会社にいた当時は、Web系に来て1年目で、開発の経験自体が足りていなかった。富士通で8年プロパーとしてやっていたので、広く浅くの経験は持っていたが、所詮は人にやらせている間に片手間でつけた素人開発力。当時のスキルは低かった。僕が作った異常にネストの深いSassに恐らく残ったメンバーは苦しめられていることだろう。(すみません。。。)
で、富士通上がりといういい意味でも悪い意味でも温室育ちだった僕は、開発のプロセスについては特に厳密であった。具体的に言うと要件定義が曖昧なまま開発を進めることに異常に嫌悪感を示していた。また、設計書がなかったり、客の要求が2転3転したりするのも許せなかった。期限は変わらないのに仕様変わるんすか！？ とブチギレてばかりだった気がする。
そんな感じなので、ざっくりとしたまま進めようとするクライアントや上流と時折衝突していた。恐らく衝突された側はこいつめんどくせーなと思っていたことと思う。
ベテランの先輩に自分の業務を引き継ぐことに
そんな折、客先常駐をやっていた件の先輩が帰社し、自社プロジェクトの開発を行うことになった。
で、僕が担当していた、とあるプロジェクトを先輩が引き継ぐこととなった。このプロジェクト、結構きつく、なにせ古すぎて要求資料すら残っていない。規模は大したことないが、正確にプロジェクトを把握するのが非常に難しい案件だった。
気の利いた資料は一切ないので、ひとまず簡単な引き継ぎ資料を作成し、先輩に軽く説明をする。
「古いプロジェクトだもんで、あまり資料がないんですが。。。」と恐縮して言いつつ…
否。
内心、「こんな酷い状態で僕も引き継いだんですよ？ 先輩もきっと苦しむと思います」と思っていた。共感して欲しかったのだと思う。
で、僕の説明を受けて先輩。資料を見ながらほうほうと頷き、想像とは違った一言を放った。
「大丈夫。中身見れば分かる」
何もない状態で詳細を理解した先輩
いくら何でもそれは無茶。と思った。そもそも何をやろうとしているのか、ぱっと見は分からない。現に僕も実際に動いている画面と断片的なコードから、きっとこう言う要求の元に作られたのだろうと推測して、おっかなびっくりここまでやってきた。普通、呪詛の一言ぐらい出てくるものである。しかし先輩は「大丈夫」と当然のような顔で言った。
その後、2~3日ほど先輩は一日中コードを見ていた。時折エディタを開いてメモを残していたように思う。一言も喋らず、僕に質問もせずに黙々とコードを読んでいた。
先輩が来て1週間ぐらい経っただろうか。営業さんから先輩に引き継いだプロジェクトについての質問が飛んで来た。狭い会社なので、会話は丸聞こえである。営業さんは僕と先輩の方を見ながら質問して来た。あんまりよく分からない部分だった。「ちょっと調査して回答します」と言おうとした時だった。
「そこは〇〇っすねー」
と先輩が軽い感じで答えたのである。
マジかこの人。と思った。
その後のやり取りを見ても、完全に理解している口ぶりだった。顧客への注意点も的確だった。外部APIの知識もいつの間にか豊富。
技術的な話もしておくと、このプロジェクトはfuelPHPを使っていた。先輩と雑談していたところ、どうやら先輩はPHPのMVCフレームワークに触るのが初めてらしかった。それどころかPHPもあんま触ったことない的な。
「それでこの理解の速さっすか！？」と驚くと、先輩、「だってだいたい同じでしょ。読めば分かる」とだけ言い放った。完全に脱帽だった。
ほとんどの開発現場はないものだらけである
スキルはイマイチだが無駄にIT業界の経験だけが長くなって来た僕から言わせると、ほとんどの現場はキチンとしていない現場だ。みんなしっかりしろよとブチギレたいわけではなく、そのぐらいキッチリとプロジェクトを回すのは難しいのである。
下記のような職場を思い浮かべてみる。
営業が確固とした戦略で動いており。
顧客の要求が明確であり。
メンテナンスされている仕様書があり。
適切なスケジュール管理がされていて。
エンジニアの開発力とコミュニケーション力が高く。
ユニットテストやE2Eテストがキチンと書かれており。
CIがキチンと回されていて。
みんなの給料が高く。
顧客の評価も高い。
断言するが、そんな職場は、ない。断じて、ない。
どの職場も現場も、何かしらの問題を抱えている。
それによく考えてみよう。僕が文句ばかり垂れていた職場はGoogleかMicrosoftか何かか？ 僕の力量に見合った、僕レベルの職場である。そもそも、自分で選んだ会社であり職場だ。高尚なイケイケ理論が自分の中にあり、それを実践できるだけの力を持っているのであれば、なぜGAFAに入らなかったのか。また、なぜ自分の職場を変えようとしないのか。
Joel on SoftwareでJoelがエクセル初期の時代にMicrosoftのプログラムマネージャーだった時の話が出てくるが、「仕様書をきちんとメンテナンスし続ける方法」が語られている。裏を返せばこのような方法論をMicrosoftの人が書くぐらい「仕様書をメンテナンスし続ける」というのは難しい。仕様書に限らない。イキリエンジニアが、当然それぐらいはやって然るべきと位置付けているものは困難なものばかりだ。
つまり、多分に語弊があるが、僕の前の会社やあなたの会社が、それをできていると期待すること自体がナンセンスだ。Microsoftのイケイケの方が工夫をしてようやく到達できる段階に、なぜ我々が到達していると思うのか。
そして、仮に僕やあなたがイケイケ理論の元、職場改善をしようとした時、プログラムを書くことより何倍もそれが難しいことに気づく。（実際、僕は前職で仕様書作りに奔走したが本当に上手くいかなかった）
意識高い系のQiitaやSlideshareにある、職場の問題点を改善した系の話。
Twitter上で、とんでもなく劣悪な開発環境をディスるトレンドツイート。
大手SIer企業を退職した話、SIerの開発がいかに闇を抱えているか。そこから脱出したイケイケの私。
それらに書かれている改善の武勇伝、いかにひどいプロジェクトかみたいな不幸自慢を見て、さも自分は違う、自分ならば改善可能だと感じる錯覚。
そう、錯覚だ。
文句を垂れて悦に浸り、ただし行動はしない系のマインドのやつに、改善活動は不可能だ。
ない環境で最善を尽くすのがプロ
件の先輩の話で言えば、先輩は、要求も仕様書も設計書もない状態でも自分のできる100%を出すことに注力した。ソースコードを読み、検証環境であらゆる操作を試し、要求を推測しそれを自分のメモとして残してプロジェクトの全容を把握した。
おそらく、経験が僕の2倍ぐらいある先輩。何もかも揃っているプロジェクトというものが存在しないことを知っていた(ましてや、単価の安い札幌の小さなWeb系企業に完璧を求めるのはナンセンス過ぎである)。なので、教科書的にはひどい状況の引き継ぎであっても特に文句も言わず、最善を尽くしたのである。
ブラックジャックによろしくの第一話で、研修医の主人公が1人で当直をしていた時。自分にはとても手に負えないようなボロボロの交通事故患者が運ばれてきた。主人公は「こんなの無理だ」と逃げ出し、患者はオペ室に放置された。結局、助けに来た院長が手術を行い、事なきを得た。その次のシーン。
院長が病院の隅っこで縮こまっている主人公に向かって「なぜオペをしなかった。どうせ死ぬなら腹を開けろ」と言ったのである。
極端な話だが、医者として現場に立った時点で患者にとって、主人公の都合、ひいては病院側の都合などは関係ない。プロとして現場に立つ以上、主人公なりの最善を尽くさねばならなかったのである。それは「独力で手術を行い、結果患者を死なせてしまう」、と言う最善だったかもしれないし、「手に負えないとわかった時点で最初から自分で手術することを諦め、院長に電話をかけ続ける」、が最善だったかもしれない。どれが最善かは問題ではなく、プロとしてその時に考え得る最善を尽くさねばならないのである。
話はソフトウェア開発に戻る。件の構図はブラックジャックによろしくの第一話によく似ている。クライアントから見たら、開発者の技量の都合、古過ぎて引き継ぎ資料が全く残っていないと言う会社の都合は一切関係ないのである。
ここで、
仕様書をよこせ、
要求は残ってないのか、
テストコードもない、
PHP5.3じゃねえか、
最悪なプロジェクトだこれは炎上必至だ、
とかグダグダグダグダグダグダグダグダグダグダずっと文句を垂れ続け、主体的に行動しないのであれば、それはもうプロとは言えない。少なくともソースコードや動く現物があるのであればやれることはゴマンとある。とにかく自分の専門性を総動員してベストを尽くしてから、より開発をうまく進めるための改善を提案すべきではなかろうか？
無論この場合、過去の会社側に明らかに問題はあるが、その問題と自分が最善を尽くさないことに全く関係はない。従って、過去のメンバーの負債によって、困難な開発にぶち当たったとしても、まずは動いて自分の最善を尽くさなければならない。その結果失敗したとしたらようやく組織の責任になる。
まとめ
まとめると下記である。
- ほとんどの現場では、要求定義や仕様書がしょぼい、設計書がない、ソースコードがクソなどの何かしらの問題を抱えている
- その問題に対して、不平不満をたらして開発に対して受け身になるのだとしたら、それはプロのエンジニアではない
- 経験のあるエンジニアは現場が完璧でないこと知っている。その上で専門性を総動員して最善を尽くすべき
- それが嫌だったらGAFAに行け。（このレベルの人には到底無理だろうが）
本日は以上！
