Rのつく財団入り口

ITエンジニア界隈で本やイベント、技術系の話などを書いています。

【雑記】エンプラ世界で楽しく「しがない」を目指すサバイバルガイド

しがないラジオのアドベントカレンダーだぞい

 クリスマスイブに祝福を! この記事は、『#しがないラジオ Advent Calendar 2019』24日目の記事です。今年も多彩な記事が並び、しがないラジオmeetup4も終わり、23日目は実在説が濃厚となったてぃーびーさんでした。→ 仕事が楽しくて仕方がなくなる方法 - Tbpgr Blog

しがないラジオは「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」の略、表記揺れがないgamiさんと時々表記揺れがあって最近髪型を変えたzuckeyさんのお2人が、様々なゲストを迎えたり様々なテーマで語り合うテック系Podcastであります。

adventar.org

 しがないリスナー勢の皆さん年の瀬にこんにちは。SIerのSEからWeb系エンジニアに転職しないけどほぼソフトウェアエンジニアでコードも書いてWeb開発を普通にやっているいわしまんです。Webエンジニアと何が違うのか、なんかもうよく分かりません!(突然の挨拶乙)

 さて2019年、振り返るといろいろありましたが、僕にとってのビッグイベントのひとつは……

しがないラジオにゲスト出演した sp.53a/bが公開!

 
でした。2019年2月公開です。転職者やWeb系やベンチャー界隈がゲストに多い中、まあ僕も転職はしていますが数少ないエンプラ界隈のゲスト出演回として、Twitterでも本当に多数の反響をいただきました。Twitterのフォロワーも増えてブログアクセスもしばらくぐんと伸びて、その後のイベントでも感想を頂いたり新たな出会いに恵まれたり、しがないラジオの影響力の大きさを感じた次第であります。
パーソナリティのgamiさんとzuckeyさん、聞いて頂いた皆さん、これから聴いてくださるかもしれない皆さん、本当にありがとうございます!

iwasiman.hatenablog.com

iwasiman.hatenablog.com

iwasiman.hatenablog.com

 sp.53ではタイトルの『sp.53a【ゲスト: iwasiman】エンプラ開発20年史と、SIer世界のエンジニアの楽しい生存戦略にある通り、その後半でエンジニアとして生きていくための生存戦略の話をして笑いを取ったりしています。
 この回で語ったことや語り足りなかったところ含め、このエントリではエンタープライズ寄りの比較的大きな企業で、技術を主軸、開発を主領域として、ITエンジニアらしく、より楽しい方向、より「しがない」な方向を目指して生き残っていくためのガイドを書いてみたいと思います。ネットでは割と見かけない題材かと思います。エンプラじゃない方にも根源的なところは同じかと思います。

 なお記事タイトルを「SIerで」にすると主語が大きくなってアクセスがさらに伸びてグッドになりそうですが、僕のとこはSI事業以外もやってる総合ITベンダーだったり、僕の歩んできたキャリアもいかにもザ・SIer道な感じでもなかったりもするので、ここでは比較的規模が大きく主にBtoBを手掛ける伝統的な従来型の会社として「エンタープライズ」「エンプラ」の表現をゆるく使っています。
 また経験に基づいた主観と生存バイアスというやつが掛かっているかと思いますので、どぞ話半分に御覧ください。

f:id:iwasiman:20191206204441j:plain:w500

自分の武器を徐々に増やし、磨いていく

 これはもう、普段からネットで情報収集したり様々な活動をしたりしている人にはお馴染みでしょう。開発言語やライブラリやフレームワークや各種技術スタック、なるべく様々なものが実務で吸収できるプロジェクトを選んだり業務外に学んで武器を増やしていくと良いのは、エンプラ世界でも同じです。
 Twitterだと時々資格不要論のイキリツイートを見たりしますが、エンプラ寄りの企業だと殆どの場合資格取得も奨励され、受験費用や報奨金が出たりします。大きい会社だと社内独自の資格や等級制度があったりするところもあります。着実に資格を取っていくのも継続的な自発的成長ができる人だと評価されますし、資格ホルダーというのも社内でのブランディング的に役立ったりします。
 またドキュメントがちゃんと書けるというのも、エンプラ世界ではより重要度が増します。英語ができると何かと役立つのはどこでも同じ。そしてWeb系だと弱めのようである、マネジメント系の力も役立ちます。
 しがないラジオの過去エピソードやキャリア系のイベントでもよく見かける、「スキルの掛け算でエンジニアとしての価値を出す」「複数の軸を持つ」#DevBoost のgamiさんの登壇資料にあった「エンジニア×◯◯」で越境の話は、エンプラ寄りの世界でも同じです。

 
 またイケイケできらびやかなネット上の情報だと軽視されがちかもしれませんが、目の前の仕事をちゃんとやっていき、実績を積み重ねていくのも武器のひとつです。こうした実績はエンプラ世界だと積み上がっていくので異動したりしても残り続けますし、人からの信頼は大きな価値です。
 単に仕事の経験を積んで問題解決能力を磨くだけでも立ち向かえることはありますし、開発の現場でエラーからなるべく短い時間で復帰する能力、バグの原因をより速く見つけて解決する力、よりよい設計の追求やより早い段階で各種問題を潰していく力は、もう泥臭い現場で地道に経験を積んでいくしかないなあと思います。エンプラ系でもいわゆる業務SEで開発から遠ざかってしまうと、この辺が弱い人はけっこういますね。

 大きめの企業になるとたくさんのプロジェクトが並行して走っており、マネジメントの上位層の人々は誰をどこに当て嵌めるか、パズルのピースを埋めていくようなことをいつもやっています。
 例えば目の前に仕事の選択肢が幾つかあって、面白そうな仕事もつまんなそうな仕事も幾つもあった場合。武器がたくさんある人、できることが幅広くある人は面白そうな仕事のアサインをゲットできる確率が上がりますし、できることの幅が狭い人は選択肢がより狭まります。
 またエンプラ系では何か大きいプロジェクトが炎上したりすると、とても上の方の偉い人の命令で各部門から人を集中的にアサインして何とか火を消せい、的な号令が下るような状況もたまにあります。
各マネージャーレベルでは、本当は早くこんな臨時の仕事は終わりにしてメンバーには別のことをさせたいんだけど落ち着くまでは仕方なく…的な感じで、みんなでよってたかって集中して現場を何とかして去っていったりします。
 こうしたケースでは炎上が鎮火し始めると、武器が多くやれることの幅広い人、新しいプロジェクトの準備や地慣らし、別のことをしたほうが価値を発揮できる人ほど、より早く現場撤退の命が下ってさっさとよそで別のことをやり始めたりします。火が消える最後の方まで残るのはやれることの幅が狭い人だったりすることもあれば、後片付けの得意な人、粘り強くやり抜く力のある人ということもあります。

 要はエンジニアとして自分を守る生存戦略的な意味でも、武器は多く持っていた方が良く、未来の選択肢がより増えるということです。

自分を知ってもらう

 キャリア系の勉強会や転職イベントでよく聞く、横文字でかっこよく言うと「セルフブランディングというやつですね。sp.53aで話していますが、読んだ本を自分の机に並べて意識高く向上心ありますアッピールする安直な方法も、技術の分からない管理職おぢさんが通りかかった時には意外と効果があります。机の上がどうなっているかというのは、けっこうその人の人となりを表すんですよね。

 周囲の人々と話をして認知してもらうことも、普通に能力を磨いて仕事で実績を出すことも役に立ちます。「あの人はXXに詳しい・詳しそうだ」「XXだったらあの人に任せておけば大丈夫だ」「そういえばあの時の彼/彼女はXX追ってるとか言ってたな」などと徐々に思われるようになれば、未来の選択肢はどんどん増えていきます。
 また大きめの大企業はとにかく人が多いので、自分を覚えてもらうのも重要です。新入社員だったり若い方であれば、なんかのイベントで役職の高い人に話しかけたりして、顔と名前を覚えてもらうのも意外と役に立ちます。酒の席だとどうせおぢさんはみんな会話の内容は大して覚えていないので、まず顔と名前だけ覚えてもらう所からやりましょう。

 また何かやりたいことがあったりするなら、不満を抱えたまま自分の中に貯めておかないできちんと伝えるのも重要です。
エンジニア転職戦線が好景気な最近、「高度AI人材に年収XXXX千マン!」関連のニュースが話題になったように、大きい会社も人材流出に危機感を抱き始めています。若手に意に反した仕事ばかりやらせたらやり直しがきくうちに辞める確率がどんどん上がるのは、流石に分かってきたでしょう。最後まで沈黙したまま一気に脱出する計画ならともかく、黙っているよりは伝えた方が何倍もましです。

 僕のとこも業績やキャリアを話し合う制度があって、Webシステムにいろいろ記入してやっています。キャリアプランの補足に「管理職に興味がありません」(キリッ)と書いている話でsp.53aで笑いを取っていますが、これは今年も書いています。将来活動したい領域的なトピックにも、最近の技術トレンドのキーワードを漏れなく書いてアッピールしています。
 古臭い組織で上に昇進していく先がマネージャーしかなくてエンジニアとしてのキャリアが閉ざされ、絶望して転職した……などという話はよく出てきますが、この手の話で記憶に新しいのはNTTコミュニケーションズさんのスペシャリスト制度の話ですね。

yuyarin.hatenablog.com www.security-design.jp

 僕のところでも、組織の長としての管理職でなく高度な専門職としてエンジニアのまま昇進していける制度が今年から整備されつつあり、このへん世相を反映して変わりつつあるなと感じています。

 転職戦線でのブランディングの話は、しがないラジオリスナー陣にはおなじみ、てぃーびーさん主催の「転職透明化らぼ」周りで様々な面白い話を見ることができます。

rtlabo.connpass.com tbpgr.hatenablog.com

チャンスを活かす

 これはもうどんな会社でも働き方でも同じですね。周囲の情報に耳を傾け、自分の武器を増やし、自分のやりたいことに繋がるチャンスがあったときにそこに飛び込める準備をしましょう。古いことわざで「機を見るに敏」というやつです。それは脱出に繋がる転職であったり、組織内での異動やキャリアアップの機会、新しい何かへのアサイン、色々あります。
 僕もレガシー金融開発から意気揚々と脱出転職を果たした後、とはいえ技術力がミジンコ同然だったので最初はくすぶっていました。その後インターネットの時代が花開き、クライアント-サーバーからWebアプリケーションにプラットフォームが変わり、エンプラ世界でもJavaが流行りだす黎明期にR&D案件でがっつり関われたのが大きなチャンスでした。業務系をずーっとやっていた人たちが数年遅れで「フレームワークって何?」とか言い出す頃、こちらはもう人に教えられる所まで上達していました。

 また日本の大企業は4月に年度が始まるので、年度末の3月~新年度4月、連休明け、四半期の終わる6月末、夏のお盆明け、半期が変わる9~10月、年が変わる12月~1月などの切れ目で新しいプロジェクトなりアサイン変更なり、何か変化の機会があることが多いです。
 転職をうまく決めた人の話でも、今の大きいプロジェクトがX月に終わるのでそこをリミットとして転職活動を始めてなんとかやり遂げた……なんて話もよく出てきます。

技術を主軸にするなら、業務ドメインになるべくフォーカスしない

 特定のお客さんの業務ドメインに深く関わり、業務知識に詳しい人、いわゆる業務SE。技術の方も両方バリバリできる優秀な人もいれば技術の方はまったくできない人もいます。まあ大手企業だと残念ながら技術はやってない人も多いですね。ほんとは技術をやったりコードを書きたくて転職してしまう人が一定の割合でいるのは、まあそうなるよなあと思います。
 こうした仕事はそのドメインの仕事がずっと安定して続いてお金も入ってくればいいのですが、大きいプロジェクトが終わると暇になってしまったり、まったく別の業務ドメインアサインされるとスキルチェンジに時間がかかってしまったりすることがあります。

 また、エンジニアでも読んでいる方の多いアンクル・ボブ先生の『Clean Architecture』や組織論でよく出てくる「コンウェイの法則」というのがあります。

システムを設計する組織は、組織のコミュニケーション構造をコピーした構造の設計を生み出す。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture 達人に学ぶソフトウェアの構造と設計

3チームで別れてシステムを作ったらアーキテクチャ内の構造も3チームに対応していた……的な話ですね。これと逆の話ですが、業務ドメインが組織に影響を与えることもあります。
 あるお客相手のある業務ドメインのある仕事をある部署のAさんと別の部署のBさんがやっていた。規模が大きくなったのでメンバーが追加されて組織改編でAさんもBさんもひとつの部署のそのままチームにまとめられることになった。
 またまた色々あって別のより大きい組織の配下にチームごと移動することになった。そして大きい企業グループになると会社単位の統合・合併・分社化なども起こることがあります。こうした組織改編に巻きこまれ、気付いたらAさんたちは最終的には別の会社の所属になってしまって当初とまったく別の道を行くことに……なんてことも、大企業だと起こりえます。自分の希望に沿わない場合は、周囲の動向を見定めつつそれまでに何とかしたほうがよいでしょう。

 僕は元から技術を主軸にしようと思っていたので、特に業務ドメインにはなるべく深入りしないように、その業務の経験があることはアピールせずに終わったら次の仕事に、ビジネスのアーキテクチャよりもソフトウェアのアーキテクチャの世界を追うようにしていきました。長い目で見るとこれは結果として正解だったなと思います。
 なおこれは、業務の人と技術の人が分かれがち、上流とか下流で分かれがちなエンプラ寄りの世界の話です。そういう分断がなく小さい組織でサービスを開発していくような仕事では、たぶん起こらないのかなと思います。

大きい仕事よりは小さい仕事

 ここでの「仕事」とは数時間で終わるような粒度のタスクでなく、1つのシステムを作り上げるようなプロジェクト単位を指します。小さいとは規模もスケジュールも両方含み、大きい小さいの差は感覚的なものです。小さいのはだいたい1〜数ヶ月ぐらい、大きいのは1年以上でしょうか。
大きい企業グループだと親会社が大型受注を扱ってメガSI案件になり、子会社は比較的小型の案件を扱ったりすることもあります。プライマリSIとかセカンダリSIとか区別されることもあります。

 僕は某社の子会社なので元から小~中規模の案件が多く、継続的な大型案件をやるような部署ではないところを巡って来ました。自分に選択肢がある時はなるべく小さい仕事を選ぶようにし、開発の現場を渡り歩くようなスタイルを続けられるようにしてきました。
 小さめの仕事の方が何かと小回りが利きます。一般的に新しい開発技法やツールや仕組みなども試しやすいですし、周囲の理解も得やすく、何か試して失敗しても影響も小さく済みます。スケジュールや見通しも立てやすく、プロジェクトの登場人物も少なくて済みます。金額が大きくなければ承認が必要な偉い人もあまり出てきません。技術的負債というやつも溜まりにくいですし、プロジェクトが失敗しても次はがんばろうと気持ちを切り替えて進むことができます。
 しがないラジオの皆さんの過去の経験談などで時々出てくるSESの数少ない長所として、「いろんな開発現場で経験を積める(かも)」というのがあります。エンプラ世界でも比較的小さめの案件の開発現場を渡り歩くスタイルを続けられると、だいたい同じようなことが言えます。そうして現場で経験を積み、武器を磨いて知見を貯めてきたエンジニアはたいてい強いです。

 以前に『セイチョウ・ジャーニー』のアドカレ記事にも書きましたが、この大きいことと小さいことの対比はソフトウェア開発の世界にはあちこちに出てきます。名著『カイゼン・ジャーニー』にも小さな案件のほうがカイゼンを始めやすいとありますし、UNIX哲学の名言にも「スモール・イズ・ビューティフル」があり、プログラミング原則のKISS原則、分割統治法、最近バズワード気味のマイクロサービスなどなど…

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

 では逆に、大規模なプロジェクトはダメなのか…というと勿論そんなことはなくて、上手くいっているプロジェクトでは得られることが多いでしょう。開発標準であったりきちんと記述された設計書、作業フロー、適切な責任分担や体制、入れ替わりが多いはずなのでメンバーが参加したり抜けたりする際のスムーズさ、どううまく他の機能に悪影響を与えずに自分の機能を作り上げるかの技法や逆に共通化の技法、上に立つ人ならマネジメントやリーダーシップの知見などなど…。
よく転職戦線でも大規模プロジェクトのマネジメント経験は、持っている人の少ないレアな武器として歓迎されたりしますね。
 しかしこの「上手くいってる」かがポイントで、プロジェクトマネジメントの本などを読むとよく出てきますが、大きいプロジェクトほど失敗しやすいんですね。そして炎上、疲弊するのはだいたい現場の末端のエンジニアだったり立場の弱い人という訳です。
 しがないラジオを始めネット各所に出てくるSIerの辛みの話は、だいたいこういう上手くいっていないプロジェクトの現場で苦労された方の話が多いかなあと概観しています。

運用保守よりは新規開発

 一旦リリースされて動き出したシステムの面倒を見たりするような仕事。会社さんによっては維持管理と言ったり、呼び方は色々あります。
 その後も開発が続くとStep2とか2次開発3次開発とか呼ばれたりしますが、大きいくくりでまた開発が始まったりその後も機能拡張が定期的にあったりすれば、そのアプリケーションがちゃんと作られて動いているものなら追加開発に携わるのには意義があります。リファクタリングや品質維持の知見、レガシーコードを避ける知見などが得られます。
 しかし作って動き出したら基本的にもう変化はなくていじらないようなシステムの場合、その後の仕事は比較的ルーチンワークが多くなったりします。なんでも厳密な手順書に従った操作やリリース、障害が起こったときの対応やメールや電話の問い合わせ、オンプレだったらサーバーのパッチ当てやなんかの書類作り…などなど。
 そういう仕事がメインになる部署は現状維持が第一で保守的、閉鎖的になって変化に弱くなり、新しいことが取り入れづらくなったり、メンバのモチベーションも下がっていったり、雰囲気もあまり明るくなかったりする傾向が割とあります。いわゆる配属ガチャで外れを引いてこうした部署に配属になり、若いうちに嫌気が差して脱出してしまう人もまあいるだろうなあと同情します。
 またこうした仕事にはあまり高いスキルは必要ない場合もあり、そういうケースで大企業はマネージャーが自分のマネジメントを何割かそこに割いて、実際の作業は外部から派遣契約で雇ったビジネスパートナーにやってもらうような形態を取ることもあります。そういう立場で関わる可能性のある方は注意しましょう。あまり成長のない仕事だから社員でなく外部に委託している場合もあります。

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

 僕もキャリアの中で様々な人を見てきましたが、運用保守の要素の強いところから開発案件に来るような人はパフォーマンスがあまり上がらない場合もありました。ずっと同じような繰り返しの仕事をしてきた人たちと接して「この人たちは開発の一線には立てないな…」と思ったこともあります。
運用や保守の効率化、自動化を頑張っていたりサーバー監視のプロな優秀な人たちもいる訳でもちろん一概には言えませんが、自分自身を守る戦略としては、出来上がったものでなく新しいものを作る仕事に常に行くようにしてきました。
 この開発と運用が分断されているという話は、DevOpsの文脈だとまさに従来型組織の悪しき点なんですよね。へーしゃでも最近偉い人の資料や改革の文脈でよくDevOpsのワードが出てくるようになったので、これから徐々にでも変わっていけばいいなあと思っています。

Effective DevOps ―4本柱による持続可能な組織文化の育て方

Effective DevOps ―4本柱による持続可能な組織文化の育て方

メインストリームの技術を追い、ロックオンを避ける

 世の中のトレンドとなる技術、主流となる技術を追ったりするのは普段からSNSやブログで情報を追っている皆さんは常にやっていることかと思います。エンプラ系の場合は技術が最先端より数歩後ろを行っている傾向はありますが、なるべく汎用的な技術を追った方が良いのは同じです。
 一般的に開発スパンが長い開発プロジェクトは、その間使う言語やツールが固定されるので技術がロックオンされるリスクがあります。これを避けるにはなるべく小さめの開発を巡っていったり、使う技術やツールやルールを決める側に自分が立つ手段があります。
 特定のパッケージソフトなどの開発に長く携わる場合も技術ロックオンのリスクはあります。その技術が世の中でもよく使われているものなら問題ないですが、古くないか時々確認しましょう。古すぎる場合は刷新の機会を狙ったり、将来は異動を考えた方が良い場合もあります。
 部署によっても特定の技術寄りになる場合があります。例えば主な継続的なお客さんがMicrosoft系の技術を使っていてそこへのソリューションを定期的に提供していると、Office365とかSQL ServerC#製のアプリにクラウドはMS Azureなど、だいたい部署で取り扱うのがMicrosoftファミリーの技術一般になったりすることはありえます。

速習ASP.NET Core 速習シリーズ

速習ASP.NET Core 速習シリーズ

  • 作者:山田祥寛
  • 出版社/メーカー: WINGSプロジェクト
  • 発売日: 2017/12/04
  • メディア: Kindle

 エンプラ開発でもオープンソースの資産を組み合わせて使ったり、オープンソースの組み合わせの上に何かをラップしてパッケージのようにまとめたものを開発で使ったりするケースがあります。これが政治的な理由で使わされたり使いにくかったりすると、現場のパフォーマンスが落ちますね。時々SIerの辛み、海沿いの話などで見かけるやつです。
 こうしたものを取り扱う際は、構造の中でどこからがOSSの機能なのか、中でどううまくOSSが活用されているのか、などラップした中に隠れた動きに着目して調べたり活用していくと、いろいろと学びになることがあります。新しいツールを試すような仕事も、積極的に取っていくと知見がどんどん貯まります。

 扱いにくいと思ったら自分たちなりの上手い工夫を何かしていく手もあります。僕の周囲でも、フレームワークの中にミニ・フレームワーク的な仕組みを仕込んで大規模開発に活用した事例があります。僕も、社内フレームワーク製品を使ったJava開発に慣れた人が割と簡単にシフトできるように意識して考えた、より簡単にアプリが作れる軽量PHPフレームワークを作って実案件で実績を出したりしています。

 技術のロックオンを避けるには普段からいろいろ調べたり学んだりして、他で述べたブランディングのように「あの人はなんかいろいろ詳しそうだ」と周囲から思われるようにしておく手もあります。こうするとその周囲ではあまり事例のない新しいキーワードや対応できるエンジニアがいなさそうな案件が来た時、何か新しいツールをまず調べてみよう的な案件が来た時、そういう詳しそうな人や部署によく声がかかるようになります。
 まあ僕がやってることなんですが(笑)、生存戦略としても地味に有効です。これが続くと既存技術や古い技術しか扱えない武器の幅が狭い人と、チャンスも実務経験もどんどん差が開いていきます。特にエンプラ系は技術にあまり強くない人、自発的に幅を広げようとしない人もいるので、ますます差が開きます。

 そして周囲を観察して、もう明らかに技術も人々も文化も漏れなくレガシーでどうしようもない時……は今後を考えた方がよいこともあるでしょう。下で述べますがエンプラ系ではまずこういう時、脱出の前に社内異動を模索していく戦略があります。

ルールにただ従う側でなくルールを作る側に回る

 誰が作ったのか分からないイケてないルールに従って延々と黙々と、面白くなさそうなシステムを言われた通りプログラミングしたり、伝統のExcelにスクショペタペタの刺身タンポポ的なおしごとをする…というのは、上手くいっていない空気の悪いザ・SIer案件的な現場でありそうな話ですが、まあモチベーション低くなりますよね。運用などでも、がんじがらめの定型の作業手順書をその通りコピペするだけの仕事ではスキルは上がりません。
 これも視座を高め、もう少し仕事の幅が広がるとやれることが増えていきます。ちなみに刺し身にタンポポを添えるのはあれはあれでスキルのいる仕事らしいですね。

 ルールがイケてないなら改善を提案する、いらないルールならなくす、開発の早期段階で開発標準を決めてプロジェクトがうまく行きそうな基本路線を定める、技術選定をしてよりよい解決法を考える、作業手順書などを作って後の人を楽にする、プログラマの3大美徳の怠惰・短気・傲慢に従って何かエンジニア的な作業省力化の工夫をしていく…などなど。
 こうしてルールを作る側に回ると、やれることの幅も広がり、どうやるのがいいのか考えるので思考の幅も広がり、失敗や成功から学ぶのでより自身の成長に繋がって楽しくなっていきます。本やネットをより調べるようになるので知見も貯まるでしょう。自分の好みも反映できるのでコントロールできる範囲が広がり、達成感も出てきます。
 まあ入社1年目の新人にはきっと難しいですし中堅~リーダークラスの仕事になるでしょうが、できるならこのルールを作る側に回るマインドを意識すると良いでしょう。
 僕も社内のキャリア用システムに登録してある経験プロジェクト数が一度数えたら約80、年またぎなど重複を除いてもたぶん40以上はありますが、中堅以上になってからで同じことの繰り返しだと感じたことはあまりないです。

 時々SIer時代の辛みで「やれることの範囲が狭かった、やり方が固定されていた」「同じことの繰り返しで飽きた」などの話を見かけます。恐らく規模大きめのあまり上手く行っていない従来型のプロジェクトで、末端の弱い立場、裁量のない立場で苦労されたのだろうと思います。
同時にそういうシーンでは、このルールを作る側の人間が技術力がなかったり考えが古かったり、プロジェクトに悪い影響を及ぼしていたこともあるだろうなあと思います。
 僕も何かの機会に自分はあまり関わらなかったプロジェクトのコーディング標準を見て、「こんな細かいルール絶対いらんだろ…大してプログラミングしてない奴の仕事だな……」なんて思ったことはあります。そういういらんルールがチームのモチベーションやパフォーマンスに大きく影響する訳で、ルールを作る側の仕事も大事ということですね。

 逆にこうした現場への権限移譲の考えがまったくない会社、ただルールに従う立場でしかプロジェクトに参加できないような人の斡旋専門の会社は、武器を磨いて力を貯めてから脱出含めて自分の将来を考えた方が良いケースもあるかと思います。

自分、自分のプロジェクト、自分の属する小集団の現在位置を理解する

 下で述べますが、大きい組織ほど階層構造でまたその内部に組織や小集団があって、様子がばらばらだという特徴があります。思うところがあったらまず自分の現在位置を確かめましょう。自分や今の仕事、部署は技術や文化的に遅れているのか進んでいるのか、プロジェクトはうまく回っているのかダメなのか、儲かっているのか縮小傾向なのか、会社の中でいい方なのか悪い方なのか、そして世の中の標準と比べてどうなのか。
 社内の平均と比べるなら、偉い人の発信しているメッセージに着目したり社内情報、日々社内を飛び交っている情報、社内のイベント、同期や年の近い人の知り合いを作ってよその部署やよそのプロジェクトの様子を聞いてみるなど。
 社外と比べるなら、インターネットの情報、たくさんある良書や雑誌を読む、社外に知り合いを作ったりコミュニティで活動したりイベントに行って刺激をもらってくるなどの手段があります。

connpass.com

 何となくでもいいからよそと比べてどうなのか分かれば、それも行動指針になるかと思います。例えば「ウチはこれからもC●B◎L一筋でやっていこう!(爽)」とか「クラウドは信用できない、オンプレが一番だ」とか「プログラミングは誰でもできる単純作業だ。そういうのは外注にやらせてウチは管理だけやっていく」とかいう方針が全社を通して共通していれば、そんな会社は早く脱出を考えた方がいいかもしれません。
 でも大抵はそんなことはなくて、たまたま今のプロジェクトがうまくいっていなくてそれはマネジメントに問題がある場合もあるし、たまたま今の部署が保守的で隣に行ったらまったく違うこともあるし、たまたま大して実力のない嫌な先輩に当たっただけでよそに行ったらロールモデルになり得る優秀な人たちがいた……なんてこともあるかもしれません。

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

異動や社内転職の選択肢を吟味する

 華々しい退職エントリに比べるとあまり目立ちませんが、社内転職に近い形で異動したらそれだけ問題が解決した……というようなブログ記事も時折見かけます。
 上のように自分の現在位置を理解したら、次に一度は吟味したほうが良いと思うのがこちらの選択肢。大きめのエンプラ企業にはまともな所ならそれはそれでメリットがあります。ネームバリュー、長期的な安定性、企業体力、資産、給与、福利厚生、設備、人的リソースの厚さなどなど…。
得てしてこのへんは長期的な視野で見ると効いてくるものが多いです。入社して会社の中の様子が右も左も分からないうちに問題プロジェクトに放り込まれたりして疲弊してしまうような若手には、正直このへんのメリットは実感が湧かずよく分からないことも多いでしょう。隣の芝が青く見えて転職を考えたりするのも当然だろうなあとは思います。
 いわゆる「配属ガチャ」で運不運があるのは大きい企業の辛い所ですが、外れを引いたら異動して自分の望む方向に近づいていく戦略もあります。事業部など大きい組織をまたいでの大幅異動を望むのでなく、目の前のタスクとは別の仕事をしたい、あの先輩とどうしても合わない……などの直近の小さな問題、特に人間関係は、管理職が話を聞いて理解してくれると意外とあっさり解決したりすることもあります。

 またエンプラだけでなく事業会社やWeb系企業にもありますが、所属集団を超えて応募できる社内公募のような制度がある会社もあります。ある程度腕に覚えのある人向けですが、こういう手段を活用して異動していく手もあります。
 僕の弊社も今は制度が変わっちゃいましたが前はこういう公募がありました。僕も過去2回ほど、応募してうちに来ないかと別部署から誘われた事があります。

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

自分と属性が近い人を探す

 キャリア構築や成長や転職活動の話でよく見聞きするのが、人は環境に左右され、環境を変えると自分も大きく変わるという話。人間は社会的な生き物なので回りの人々に影響される訳ですね。エンジニアとしての成長にも大きく関わってきます。
 探してみると社内にも自分と同じような悩みを抱えていたり、同じ方向を目指していたり、目標になるような実力のある人がいたり、実は社内勉強会のような活動をしている人もいるかもしれません。社内に見つからなかったら社外から探す手もあります。各地の勉強会イベントはテーマが決まっているので探しやすいですね。

 僕も、うちは法令順守の意識が高いから仕事以外でブログとかで活動してる人あんまいなくて寂しいな~とずっと思っていました。すると社内サイトで何かを見ていて知ったのですが、実はOpenStackとかKubernetesとかOSSコミッターをしているような凄エンジニアも広い社内にはいるんですね。グループ全社のクラウド有識者がたむろっているSlackチャンネルを見つけてジョインしたらめっちゃフランクに会話していて、なんだ探すとこういう人たちもいるのか……!と思ったこともあります。
 なぜ知らなかったかというと会社がでかすぎて社内サイトもでかすぎて情報にたどり着けなかったという、大企業あるあるなやつなんですが、まあこういうこともあります。

情熱プログラマー ソフトウェア開発者の幸せな生き方

情熱プログラマー ソフトウェア開発者の幸せな生き方

  • 作者:Chad Fowler
  • 出版社/メーカー: オーム社
  • 発売日: 2010/02/26
  • メディア: 単行本(ソフトカバー)

上位の人々が発しているメッセージに着目する

 よくメディアでの情報発信が活発な若い企業だと、自社ブログなどで技術情報や社内の様子、今後の方向性や採用の話などを発信したりしているかと思います。
 エンプラ系の企業はあまり外部向けにはやらないんですが、社内ではいろいろサイトに記事が載ったり、節目のイベントで上位層の人々が情報を発信したりすることがあるかと思います。これらのメッセージが未来にどれだけ適合しているかを自分なりに考えてましょう。

 エンプラ界隈を席巻している最近のパワーワードに、ニュースなどでよく出てくる『2025年の崖』があります。長く続いた基幹システムやインフラの老朽化、パッケージソフトのサポート終了、古いシステムを扱える高齢IT技術者の引退、いろいろ重なってこのままだと日本のITは危ない!という話ですね。

www.sbbit.jp

 僕のとこの組織の偉い人もこのへんの話は前からしていて、従来型の人を出すだけのSI案件はもう減っていくのでシフトしていこう、自分たちの商材やサービスで新しいビジネスを作り出していこう、若手も尊重して変化に適合していこう……的な前向きな姿勢を取っています。全社的にもこの2019年、リモートワークが本格的に始まったり制度改革が始まったり、変化や挑戦をキーワードに打ち出してきたり、あーやはり2020年代への生き残りをかけて本格的に活動を始めたなというのは概観していて感じます。
 あまり技術に詳しくない偉い人の作った資料にも従来のSoR(Service of Record)やレガシーと対になるこれからの時代を表すキーワードに、SoE(Service of Engagement)、共創、アジャイルスクラム開発、DevOps、CI/CD、クラウドネイティブ、マイクロサービス、シングルページアプリケーション、そして中身があるようでないようなエンプラ界必殺のバズワード「DX」(デジタル・トランスフォーメーション)などのキーワードがよく登場するようになりました。

monstar-lab.com

 自分の会社の今後に思うところがあったら、これら未来との適合ぐあいを一度考えてみると良いかと思います。大企業批判やSIer批判の文脈だとよくオワコンと言われるところですが、まともな会社なら今後のことをそれなりに考えてそろそろ対策を始めているはずです。
逆に何もしていなくて、毎年同じようなことばかり言っていたり人の派遣しかしていないような会社は、もう脱出対象なのかもしれません。

社内の情報に注意する

 大きい会社だと事業部がなくなったり生まれたり、くっついたり離れたり、それどころか会社単位で分社化したり合併したり、偉い人が変わって方針が変わったり、いろいろ起こります。
武器を技術に置いたエンジニアだとしても、ある程度は社内を行き交う情報を知っておいた方が生存の助けになるかと思います。たとえばやばそうな案件の話も、何も知らずただ火の中に突っ込んで死亡するよりも、知らないよりは知っていて進んだ方が周囲に助けを求めたり警戒を発していち早く撤退したり、何か手が取れます。
 コミュニケーションツールが普及した会社ならSlackやTeamsの雑談チャンネルかもしれないし、メールかもしれないし、通りかかった人の雑談やミーティングエリアから聞こえてきた話、飲み会で聴いた小話かもしれません。

周りの人々の仕事を知り、自分にないスキルを持つ人と協力する

 これはエンプラ系企業に限らずの話だと思いますが、エンジニアだけで成り立つ会社は少ないと思います。プロジェクトのマネジメントも、組織のマネジメントも、人と話したり仕事をとってくるのが得意な営業の仕事も、諸々社内調整する仕事も、地味な事務的な仕事も、オフィスを綺麗に保つ仕事も、人を育てる仕事も、人を支える仕事も、それぞれ価値があって会社が成り立っているわけです。互いに敬意を払うべきでしょう。
 僕も技術が主軸なので時々内面の悪の心が「どうせこの人自分で手を動かして開発なんてできないんでしょ?」なんて思ってしまうようなシーンもあるのですが(笑)、『Team Geek』のHRTの三原則(謙虚、尊敬、信頼)を思い出すようにしています。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

 また、新人研修なんかで多くの人が遭遇するのがチーム開発の難しさ。チームワークが重要なのもどの会社でも同じでしょう。自分にない能力を持つ人とはうまく協力して仕事に立ち向かいましょう。
 エンジニア界隈でもある程度力を付けた人の過去の失敗談でよく出てくるのに「全部ひとりで何とかしようとして結局失敗した」というのがあります。技術同人誌『挫折論への招待』にも同じような話が出てきます。
 僕もこれは、過去何度か手痛い失敗をしてきました。その後はマネジメントが得意な人となるべく一緒にうまくやっていくことを意識するようになりました。

booth.pm

敵を作らずに味方を増やす

 わざわざ仕事で喧嘩をする人はあまりいないと思いますが(……ですよね?)、エンタープライズな世界でも敵は作らない方が良いです。異動や組織改編、プロジェクト諸々の変遷を経て、かつて縁のあった人とひょっこりまた一緒に仕事をする機会が来たりすることもあるからです。
 また自分の仕事の実績や周りからの信頼も、積み重なると価値になってきます。『7つの習慣』などに出てくる信頼貯金(信頼残高?)というやつです。こういう貯金も、いつか組織での異動やプロジェクト間での異動の時に助けになることもあります。
 自分が世話になった恩は直接返せなくても、ブログの記事や活動で、未来の誰かに対して送る……という「インターネット恩送り」という言葉もあります。SNS上での言動もやがてはその人のイメージを形作ります。自分が為したことはいつか自分に返ってくるのです。

完訳 7つの習慣 人格主義の回復

完訳 7つの習慣 人格主義の回復

 最近聴いたしがないラジオで思ったのはsp.71の戸本さんのお話ですね。社内で尖って色々あったけどその陰でちゃんと見ていて評価してくれた人もいた……という話、ああこういうのあるよなあと思いました。

shiganai.org

自分に距離が近い人々と仕事をする

 エンプラ系大企業は母体組織が大きすぎて、自分たちから距離が遠すぎて何をやってるのかお互いによく分からないような組織もあります。こうした遠い組織同士で大きな案件を取り扱う際、仕事の取り合いになったり責任を追及しあったり、内部抗争のように同じ会社内でいがみあったりする事態もたまに発生しえます。
 こうしたケースでの自衛の戦術はすぐに距離の近い管理職にアラートを上げて相談、権力のある偉い人に偉い人の力で解決してもらうことです。相手組織の顔が見えず様子がよく分からなくてうまくやっていけそうにない時には、その案件はもう手放してウチは撤退!なんて組織的戦略をとることもあります。
 まあエンジニアとしては関わりたくない話ですね。こういうとこは大企業特有であり、優秀なエンジニアからなる小さな精鋭組織には敵わないよなぁと思います。

 それゆえ自分を守る戦略として、互いに信頼して守りあい一緒に仕事をすべきなのは、まずは距離が近い人々からとなります。例を上げると自分→自分の所属部署→部門→同じ事業部→前に一緒に仕事をやったことのある人たち→同じ会社グループ内...のように同心円状に広がる感じです。そして不慮の事態に備えて管理職とも相談できるようにしておきましょう。
 結局人間はお互い知っている人同士で仕事をした方が上手くいくし、パフォーマンスも上がるし、心理的安全性も確立されるわけです。僕も過去上手くいった仕事は、たいてい自分と距離が近い人と一緒にやった仕事でした。

 こうしたことを考慮に入れれば、SES企業などあちこちからかき集めてきたお互いをよく知らない要員で客先常駐プロジェクトをいきなり始めても、上手くいかなさそうなのは分かりそうなものですが、人間はなぜ過ちを繰り返してしまうのか……

プロジェクトや社内を観察する

 名著『カイゼン・ジャーニー』にあるように視座を高めて、今のプロジェクトや社内を観察したり、会社の外からの学びや観察と対比してみましょう。
 机に座ってディスプレイとにらめっこしてるだけでは分からないこともあります。一見何をしているのか分からない偉いおじさんも、権力をうまく使って社内調整をしてくれていたり、客の前に立つと巧みな話術で話をまとめる力を持っているかもしれません。何をしているのか一見分からないマネージャーも、来月来るであろうチームの危機を救ってくれそうなスーパーエンジニアを確保すべく社内で要員調整に奔走しているのかもしれません。意外と自分のことを見て評価してくれていて、何かの時に有益なことをしてくれるような偉い人もいます。
 もちろん逆のこともあって、相手が年下と見るとマウンティングしてくるけど実際大したことのない人、口だけ立派なことを言うけど本人は大して実力のないような人もいるし、様々です。
 一般的にエンプラ系大企業は平均年齢が高めなので、まあ若いWeb系企業などよりはおぢさんが多くなります。頭の固い保守的な人が障害になることもあるでしょう。
 しかし年寄り=悪かというとそうでもなくて、長年の経験から来る知見だとか人間的な懐の広さだとか、いろいろ持ってる人もいるわけです。このへんは社会に出たばかりの人なんかにはすぐには分からないし僕も駆け出しの頃はそうでしたので、人や物事を見る力を養っていくしかないかなあと思います。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

大きい組織内集団特有の現象を理解する

 大きめの会社にはその中に事業部とか部とかグループとかより小さな単位の階層構造の集団がありますが、特徴があります。文化や雰囲気、未来への適合ぐあい、方向性、様々な特性が、集団ごとによってばらばらだということです。だいたい以下が影響するかと思います。

  • 集団のトップが誰か、またどこから来た人か
  • 集団で力を持つ主要な人々がどんな人たちか
  • その集団の生い立ちがどこか
  • 集団の予算や儲かり具合(マシンスペックの例の人権話に影響する)
  • 全国に支部があるような大きい会社なら、その集団の中央との距離
  • 集団の主な仕事相手
  • 集団の主な仕事内容
  • 集団の主な取り扱う技術
  • 集団内の年齢構成...

 例えば僕のとこでは来たる来年のオリンピックに向けてリモートワークを推進していますが、アンケート的なものを見ると全社でまぁバラバラです。僕のいる事業部のように割と積極推進できてるところもあれば、様々な理由でまったく活用できていない集団もあります。
「全社一丸となってXXしよう!」的な話はよくどこでもシャチョーがいいそうなセリフですが、大きい企業でそれができるんだったらとっくにやってる訳です。事業部が変わるとまるで別会社みたいだとか、同じ企業グループ傘下のはずなのにまったく文化が違う…とかこの手の話は各方面の退職エントリでもよく見聞きするので、大企業だとどこでも同じようなものかなあと思います。

 僕も前にGoogleFacebookAppleなど世界を変えたビッグプレイヤーの歴史の本を読んできました。それぞれ面白いのですが、共通するのは、最初は少数の天才が率いる小さな集団だと物凄いことを実現していくが、集団が大きくなってくると必ず人間関係で何か起こって障害になるということです。
 人間の歴史を紐解いてみても、これまで世界中の様々な王や英雄が世界統一を夢見てきましたが完全な世界制覇はほとんど果たされていない訳で、これはもう人間社会の宿命みたいなもんかなと思います。

 というわけでエンプラ世界で「しがない」を目指すには、このへんを考慮に入れ、大きな組織の中で自分の行きたい方向にうまいこと泳いで近づいていく必要があります。大企業特有の目に見えない引力に引き寄せられてパワポ戦士やExcelエンジニア、中身のないSEになってしまう世界線は、武器を揃えて力を蓄え、未来の選択肢を増やして回避しましょう!

組織内集団や仕事の特性を理解する

 エンプラ系でも会社によって様々であり、もちろんこれ以外にもハードウェア系とか色々あるのですが、思いつく範囲で並べてみました。組織の話と仕事の話が一緒になっていますがご容赦ください。エンプラ系じゃない仕事も混じっています。

研究、あるいは研究組織と一緒に開発をするしごと

 アカデミックな目的のための研究や論文、業界標準の技術を追求したり調べたりする仕事。研究所やR&D的な組織です。また研究者的な人々は開発に携わっているわけではないので、より現実的な開発が得意な組織が一緒になって何かを作ったりもします。
 こうした組織は理系の大学の研究室の延長のようなアカデミックな、フランクな雰囲気があったり、紹介記事に載ってるGoogleとかの先進的なオフィスの写真みたいな感じになっていたりします。
トレンドになるかもしれないまだ実験的な技術や先進的なツールやプロセスも進んで取り入れたり、使い物になるか調べたり試作したりするので、新しい技術に触れる機会は多いです。一般的なSIerやエンプラ開発のイメージとかなり異なる仕事です。触れることができればエンジニアとしても絶好の機会でしょう。
 過去のゲスト回ではsp.42のくろたろうさんの過去のキャリアに出てきたりします。またsp.67のiwashiさん回でもNTTコミュニケーションズさんには研究所とまた別に事業部側にも研究組織がある……なんて話が出てきて、あーこのへんは同じなんだなと思いました。

shiganai.org

 こうした仕事の特徴は納期通りものを作ることに追われるよりも、使う技術自体がハイレベルで形にすることが難しかったり、難しさの種類が違うことです。中にはできるところまでで終わったりする、調べることが主な目的の案件もあります。契約で言うと請負開発でも派遣でもなく準委任契約のおしごとになったりします。
 弱点は……これもくろたろうさん回の回想に出てきますが予算でしょう。今はお金にならないけど将来お金を生み出す元になるかもしれないナニカに先行投資する形が多いので、予算がなくなるとそこで突然プロジェクトが終了になったりします。
またハイレベルな少数精鋭メンバでこじんまりと行うことが多いので、人をたくさん投入してなんとかするメガSI案件とはだいぶ様子が違い、あまり外部にイメージが伝わりにくい仕事でもあります。
2017年のしがないラジオAdvent Calendarのgamiさんによる記事で大手SIerでも研究開発部門ならスキルアップできたり楽しくなったりするかも……という話がありましたが、だいたいそうです。

jumpei-ikegami.hatenablog.com

 僕も汎用機の世界を脱出転職して2000年代、エンプラ世界でもクライアント-サーバーの時代が終わりWebアプリケーションとオープンソースJava/.NET全盛期が始まる頃、先んじてこうした先進的な仕事に関われたのはキャリア構築の中でも非常に役立ちました。

専門的な技術を使うしごと

 世の中には工場や医療や教育など様々なビジネスの現場があり、主に大口の顧客向けにソリューションを提供する技術を取り扱う仕事もあります。画像認識や音声認識指紋認証や顔認証やAIやIoTなどなど。
あまり外部にイメージが伝わりにくい仕事ですが、エンプラ系でもこういうことをやっているところもあります。このへんに来るとスタートアップ界隈でよく聞くX-Tech(クロステック、エックステック)系と似てきますね。

社内システムを作るしごと

 大きい会社になると配下のグループ会社も沢山あって、そうした会社がユーザーになるシステムの構築や拡張も仕事で出てきます。同じ会社の中で仕事とお金を出し合ってぐるぐる回る感じですね。
 こうした仕事も段取りがまずいと炎上したりもしますが、スケジュールや見積、体制作り、技術選定などがうまくいっていれば、割とすんなりとうまく進んだりします。良い意味でも悪い意味でも同じ会社なのでなあなあになったりすることもあれば、同じグループのよしみでしょうがあんめえと、細かい仕様追加のお願いも聞いてあげたり、いろいろあります。
 こうした仕事も経験を積んで力を蓄えることができます。グループ内のあちこちから依頼が来るこうした開発案件を手掛ける部隊を、組織として用意している場合もあります。
 注意すべきはERPとか基幹系システムなどで、社外では通用しなさそうな難しいパッケージソフトや自分の将来像に沿わないソフトウェアが出てきたりした時ですね。避けられるなら深入りしないなどの戦略を取った方がいい場合もあります。ERP系で有名なSAPも2025年で保守期限が切れます。

 たいていこうしたアプリケーションの価値の本質はブラウザの奥のサーバーサイドにあり、精密なロジックや正規化がきちんと行われたデータベース、適切に使われたライブラリや整然としてメンテナンスしやすいコード、他のシステムとの連携などにあります。そのためアプリケーションの見た目の話は重要度が低かったり、レガシーブラウザがターゲットに含まれていたりします。具体的には、フロントエンドの皆さんが速やかな死を望んでいるであろうIEとかIEとかIEとかIEです。イケてる最新のフロント技術を極めたい人には物足りないかもしれません。
 といっても主に2000年代のオープン系技術や古いパッケージなどで動いている老朽化したシステムも最近は「オープンレガシー」と呼ばれ、置き換えの時期に来たりしています。そのリプレースの機会に最新技術が投入できるかもしれませんね。

tech.nikkeibp.co.jp

パッケージソフトを作るしごと

 汎用的なソフトウェアを作ってパッケージとして販売する仕事もあります。数を売って利益を得たり、顧客ごとにカスタマイズして利益を得たりします。こうしたところは開発を外任せにしたりはせず、キーマンとして社員でも技術力のある人材を揃えていることが多いです。開発に関われればスキルアップにもなるし、うまい機能拡張やカスタマイズの仕方を学ぶのもコード設計の知見が貯まるでしょう。
長い間売られているソフトウェアの場合は内部構造や使っている言語やツールが古くて、技術ロックインになるリスクはあります。逆に刷新の機会に恵まれるかもしれません。
 SaaSでなく顧客環境に直接インストールするオンプレ方式のソフトウェアの場合は、現地の環境構築やあちこちに売って回る営業に近い役割になると、開発から離れて繰り返しに近い仕事になることもあります。こうした部署では定期的な人材ローテーションをしたりして仕事の固定化を防いだりします。また、これからはクラウド前提のパッケージソフトもより増えることでしょう。

動いているシステムの面倒をみるしごと

 運用保守とか維持管理とか呼ばれる仕事。『運用保守よりは新規開発』の戦略の話で触れました。
 もちろん一概には言えないんですが、従来型の大企業だと一般的に文化が保守的だったり、停滞気味の空気が満ちている傾向があります。集団の中がまた開発と運用に分かれていて、両グループで分断があったりすることもあります。改造案件に積極的に関わって実装技術を伸ばしたりインフラ系のスキルを貯めたりしながら、DevOps時代の変化を見ましょう。
 場合によっては大きい単位の改造案件なども社内の開発が得意な別な部隊に任せていたり、コスト削減などの理由で実作業は雇ったパートナーさんに任せていたりすることもあります。じゃあ社員は何やってるんじゃいという感じですが、中身のないシステムエンジニアにならないように注意してサバイブしていく必要があります。

 自分より上の年齢層の人に聞いてみるといいかもしれません。「ウチのアレ、確かに古いし中のロジックもボロボロなんだけどなんとか毎月動いてるし、俺もプログラミングなんてほとんどやってないから今更新しい技術なんてついてけないし、現状維持で今のまま行くしかないんだよね~」的な残念な反応が返ってきたら、若いうちに異動や脱出を考えた方がいいかもしれません。
 でも意外と「その問題は前から認識していて、来期にアーキテクチャからすべて作り直しを考えている。キミの力を貸してくれないか」的な胸熱展開が始まるかもしれません。

システムを作り直すしごと

 エンプラ世界でもプロジェクトが上手く行かないことは割とよくあり、ある程度出来上がったけど問題のあるシステムというのはあります。別部隊が引き取って苦労しながら開発を続けたり、ゼロに戻って作り直したりすることもあります。
僕の観測範囲だと、調査の結果方針が決まったら、体制も作り直してプロマネも設計整理も実装も力のある要員を集めてメンバも一新、仕様も整理し直してスケジュールも引き直して最初から仕切り直しだ!と作り直すことの方が多かったです。一旦は赤字になるけどあとあと考えると作り直したほうが黒字になるわけですね。
 こうした仕事も前回の問題点を調べて参考にしたり、どうやって今回はうまく作っていくのか考えながら進んだり、メンテナビリティを考えて実装したり、得られる知見はあります。
 Java以外の言語で僕が覚えている所でいうと、PHPの今となってはマイナーなFWのCodeIgniterで誰かが作ったらしいけどうまくいかなかったやつをみんなで最初から作り直し…なんて経験があります。

 この手のシステムが形にはなっているけど後から入って苦労したという話は、オンラインでも東京だとオフラインでも時々耳にしますね。
 ベンチャー創業期にスピード最優先でRailsで作ったけど後の成長期になって苦労した、Rubyを拡張可能なメタプログラミングでいわゆる黒魔術を駆使し過ぎて裏で何かやってるのが追えなくて苦労した、PHPでなんかすごく古い謎のフレームワークで作られていてメンテで困った…などなど。こうした技術的負債の話は、エンプラ系Web系ベンチャー系問わずICT業界あるあるかと思います。

業務ドメインの大きなSI案件を扱うしごと

 お客が作りたいと思っているシステムを代わりにシステム・インテグレーションする、一般的なSIerのイメージの大部分を占めると思われる仕事。しがないラジオのエピソードで出てくる闇のSIer話や、ネット各所の退職エントリの過去話は、こうしたいかにもザ・SIer的な案件、そしてその中で立場の弱い若手や下請けなどの立場で苦労された方の話、あるいはSIer関係なく会社自体がブラックだったり問題があった場合も多いかと思います。
 主なドメインとしては金融、官公庁、自治体、医療、製造、流通、通信などなどでしょうか。僕もレガシー金融開発の世界線を脱出してきましたが、金融系は使用技術や文化が古いことが多く危険だという話はIT業界で昔からされていますね。もっとも最近はソニー銀行みずほ銀行などAWSの活用も出てきたり、変わりつつあります。

 レガシー銀行システム開発の話というと、界隈の方々と知り合うきっかけでもあったはっせーさん回が思い浮かびます。同じく元PL/Iヤーとして、僕が転職したのは1997年なのに2010年代半ばの話でなぜこんなに変わっていないんだ!と驚愕しました。 shiganai.org

 最近の回だとsp.73のきゅ〜ぶさんの物語でも過去のSES時代のエピソードで、ネットで時折語られる海沿いの危険な案件で今も紙レビューをしている金融系案件の話が出てきます。

shiganai.org

 大きいメガSI案件だとプロジェクトが中止になって失注すると会社の売上も大損害になり、それだけリスクに神経質になります。そのため失敗を避けようとし、変化を恐れる、ルールががんじがらめで厳しい、できることが少ない、文化が古い、大量の人海戦術……などなど、従来型のSIerぽいイメージが並びます。これを避けてサバイブするには、安直ですが『大きい仕事よりは小さい仕事』で述べたように小さめのプロジェクトをやっていく戦略もあります。

 伝統的な枯れた技術を使うので古い、なんか使いにくいパッケージとかが出てきた、開発ツールを変えられない……などのお馴染みの話も、『ルールにただ従う側でなくルールを作る側に回る』で述べたように、自分が決める側に回れると、比較的裁量が大きくなります。苦しんでいる現場を助けて改善したり、モダンな技法を取り入れたりすることもできるでしょう。実際エンプラ開発では、開発早期に開発標準を定めたり、これから開発メンバーが進む道を先んじて整備しておく仕事は重要です。
 他、こういうたぐいの比較的大きく危なそうなプロジェクトに外から開発者として加わる際、注意すべきところをサバイバルの観点から書いてみます。

  • マネジメントはできているか?:エンプラ系やSI企業の強みはここですから、これすらできていないとじゃあ何ができるんじゃいとなります。
  • マネジメントは適正か?:立場が弱い人を恫喝するのがマネジメントと勘違いしているような人もいるかもしれません。重要なプロジェクトではふつうプロマネの資格を持ってたり経験のある人を配置するはずですが……
  • 顧客との調整はできているか?:お客様は神様ではありません。矛盾している要求をうまくまとめたり、契約や仕様書を盾に戦ってチームを守るのも、プロジェクトを運営する側の仕事です。対応難易度を考えずお客の言うことをほいほい聞いてしまうような無知な人がフロントに立っていると炎上の原因になります。
  • 技術的なキーマンはいるか?:マネジメントする人が技術に弱いなら強い人を配置したり、関連部門に協力を取り付けたり、フォロー体制を敷いているはずです。このへんも何もしていないと後で炎上の原因になります。
  • 開発標準はあるか、そして適切か?:テストはカバレッジ100%必須とか非現実的で意味不明なルールがあったりすると、開発の現場が分かっていない人が作った可能性があります。こういうのも炎上の原因になります。
  • プロジェクトの登場人物が多すぎないか?:いわゆるステークスホルダーとか、何社も関わっているとそれだけ調整に時間がかかったり足並みが揃わなかったりします。
  • 品質維持はできているか?:急にあちこちから人をかき集めてきたような炎上プロジェクトに多いですが、一部のプログラマーのスキルがあまりに低くて周囲の足を引っ張ぱるような事態もよく起こります。
  • コードレビューをしていたら、指摘は適切か?:コードの本質でなくコメントの書式がどうのという本質から外れたつまらない指摘ばかりしてくる人がいたら要注意です。肝心のレビュアー側に技術力がない恐れがあります。大企業には、開発はできなくてドキュメントしか書けない人というのが一定の割合でいます。
  • 相談できる人は周囲にいるか?:自社メンバーなど自分に距離の近い人と共に動き、孤立無援の状況を作らないようにしましょう。
  • 指示を伝えるだけの仕事をしていないか?:「開発の実作業は全部外注さんに振って社員の君はとりまとめをしてくれ」なんて指示に要注意です。それでマネジメントやリーダーシップのスキルが貯まるなら良いですが、右から左へ指示を伝えるだけの毎日だと、大企業特有の中身のないSEが爆誕してしまいます。プロジェクトからの離脱や所属部署異動や脱出も考えましょう。
  • 指示をしてくる側の人はまともか?:逆に指示を受ける側で作業するなら、してくる側の指示が正しいかも重要です。経験が浅く開発経験のない人が指示する側に立っていたりすると全員が不幸になります。受動的にただ従うだけでなく、より上位の人に相談したり対策をとりましょう。
  • 偉そうなだけの中身のない人はいないか?:グループ各社が配下にいるようなエンプラ系大企業だと、本体に近い位置ほど、訳もなく自分は偉いと勘違いしているけど価値を出していない人がたまにいます。偉い人の力で追い払ってもらうか、2025年の崖と共に沈んでもらいましょう。
  • 実装者を見下すような風潮はないか?:まともな人のいるまともなプロジェクトなら普通マネジメントや仕様面と技術、うまくバランスを取ってやっていくはずなんですが……世の中にはまだまだありそうですね。
    大企業のSEが言いそうな「オレは上流工程の人間だから」なんて台詞はプログラミングができない言い訳に使われることがよくあります。このへんも今後2020年代には変わっていくと思います。従来型の古い思考にしがみつく人と会社は、2025年の崖に沈んでもらいましょう。

 普段から注意して、危なそうな案件には元から関わらないようにする基本的な戦略もあります。
しがないラジオのリスナーの学生の皆さんでエンプラ系企業を目指す方はあまりいなさそうですが(笑)、就職の観点でいうと本社でなく子会社に入社すると、手に余る大きすぎる案件に出くわす率が下がったりします。また従来型の日系SI企業では、ぶっちゃけ本体よりも子会社のほうが技術力があったりすることが多いです。

 しがないラジオ勢にお馴染みのてぃーびーさんやVTRyoさんたちの技術同人誌『挫折論への招待』に、炎上プロジェクトの原因はほぼ運用や体制やマネジメントにあり、エンジニア個人に原因があるわけではないケースがほとんどである……という一節があります。僕も経験からこれには完全同意です。

booth.pm

事務系のしごと

 ビジネスとして利益を得る直接作業に対して、直接は利益を生まない作業を間接作業と呼ぶことがエンプラ系ではあります。事務系とかスタッフ系とか呼ばれたりバックオフィス系に近いこともあります。社内手続きの謎めいた承認フローを回して申請を承認したり却下したり、伝票を入れたり、エンジニアからするとめんどくさそうに見えるかもしれない事務仕事をしっかりやってくれるところです。
 急な出張の手続きをパパパッとしてくれたり、マシンの調達とかオフィスの整備など、情シス的に社内の何でも屋として色々助けてくれる方はどこでも助かります。

 しかしエンプラ系の大企業では、間接部門がひとつにまとめられて大きい組織になったりすることがあります。こうした組織の定型作業をITの力で効率化してあげたりするのは良いですが、こうした組織に近い特性を持つところに所属するのは、ITエンジニアの生存戦略上はなるべく避けましょう。
同じような仕事の繰り返しの占める割合が多く、言い方はとても悪いですが誰でもできるような仕事が多いです。企業の方針が変わったり傾いたときに、アレな話ですが真っ先に配置転換やリストラのターゲットにされやすくなります。
 近年ではこうした仕事の業務改革が盛んになり、RPAの力でだいぶ効率化されたりします。それだけ、日本の伝統的大企業には無駄な仕事が多いということですね。

仕事ごっこ ~その“あたりまえ"、いまどき必要ですか?

仕事ごっこ ~その“あたりまえ"、いまどき必要ですか?

 2018年末に某*TTさん関連の一連の退職エントリが話題になりましたが、その中でも福利厚生や組合の話と並んで間接作業部門の話がよく出てきて、なるほどこのへんはどこのエンプラ系大企業でも同じなのだなあと思いました。

セキュリティのしごと

 日々新しい脅威が生まれるインターネットの最新状況を調べたり、脆弱性に対応するルールを社内に展開したり警告したり、セキュリティ関連のツールの使い方を社内に教えたりする仕事。そういう専門部署があったりします。セキュリティエンジニアという呼び方もありますがICT業界全体ではあまり占める割合は高くなさそうです。
 こうした仕事も有識者が多く、社内の講習会に行ったりすると講師はかなりハイレベルな人が出てきたりします。人の割合が小さいのであまり外部にイメージが伝わりにくい仕事でもあります。

品質管理のしごと

 規模の大きいエンプラ系になるとたくさんの開発案件で生まれるコードやアプリケーションの品質を維持するため、標準を作ったり展開したりすることを仕事にしている集団もあります。Web系企業のQA(Quality Assurance)と呼ばれる仕事に近いです。現場のプロジェクトや事業部に品質管理担当がいることもあります。各種言語でのコードの静的チェックなどは、各社の現場の皆さんもいろいろ試したりしているでしょう。
 こうした仕事もいろんなツールが触れたり勉強になることもあります。一方下手をすると、なんかExcelを弄って数字の帳尻合わせするだけになってしまうような仕事もあります。
 また、大企業の中央に近いところにこういう組織があると、一向にプロジェクトの現場には降りてこなくてなんか上からいろいろ指摘するだけになり、現場からは煙たがられたりすることもあります。このプロジェクトになんかすごい自動ツールとか全面導入しましょう!と外野から勧めるけど自分たちは実際のプロジェクトでは特に何もしない、みたいなよく分からない人もたまに出没します。

 品質管理に限らずですが、こうした人の仕事に文句をつけるのが仕事として存在してしまうのも大企業特有の現象です。口だけで実行しない人がいるのは今後の変化への妨げだ……などと批判されたりしています。おぢさんは偉そうなことを言っていい気分になって仕事をした気になるけど、受ける側の若手からするとなんの価値にもならず邪魔なだけだった、という訳です。

プロセス、ツールなどを調べたり展開するしごと

 よくエンプラ系やSIerの大規模開発は採用技術が古いなどと言われますが、その原因に技術を調べるのに時間がかかり、承認などに時間がかかり、そして図体がでかいと会社じゅうに展開するのにまた時間がかかり……というのがあります。
 sp.53で話していますが、僕のところでは2000年代のJava/.NETの時代に標準化の重要性に気付き、開発方法論やツールなども含めて全社標準が決められ、また社内展開に時間がかかり……というのがあって、2000年代終わり〜2010年代がメインの次のスパンの変化への対応が遅れたなあというのを感じています。
 こうしたツールやプロセス類、世の中のトレンドを調べたり社内用のツールを作って展開していくような仕事もあります。またこういう集団と一緒になって、新しい考え方やフレームワークなりを調べたりする仕事も、最新技術への対応力が上がって有益です。

Webサイトを作るしごと

 大きい企業になると社内サイトも大きくて社内システムもたくさんあって、統一されていないとかはよくあります。
作り方は様々です。HTMLに詳しくないので自動で作ってくれるツールなんかを使ってそのまま公開されている時も、きちんとWebコンテンツを作り込んでいくこともあります。こうしたWebデザイン寄り、Webディレクションマーケティングの仕事もあります。このへんになると普通の制作会社やWeb系企業のWebデザイナーとあまり変わらないかと思います。
 しがないラジオの最近のエピソードでいうと、PodcastソムリエのKANEさんがエンジニア→Webディレクターへの転職をしていますね。

shiganai.org

アジャイル社内ベンチャーのような組織内組織

 個人的には神回だったしがないラジオのsp.67のiwashiさんの回に、大企業を変革していくならまず小さく自律的に動ける独立したアジャイル組織を作り、その中で上手くいったらコピーして別の組織にも適用していこう……というような話があります。NTTコミュニケーションズさんのLean Agile Baseというオフィスですね。

developer.ntt.com

 この話は良いなあと思いました。変化に対応していこうとしている企業なら、何かこういう属性を持った小集団や組織を作ろうとしている所もあるかもしれません。もしも動きがあったら要注目ですね。きっと志を同じくした素晴らしいエンジニアがいることでしょう。

shiganai.org

#jtf2019の資料。これも熱いです。

 似たような話として、新人研修で一定期間、複数のチームで疑似プロジェクトや本物のプロジェクトをやって学ぶような疑似組織があります。こうした形態も新しい技法やツールや考え方が導入しやすく、新しい試みの実験台にしやすいです。意欲の高い新人が集まるのでみなよく成長し、活気のあるエモい空間が形成されます。
僕も昔1年間講師をやったことがあるのですが、キャリアの上でも大きな学びでした。

新しい形の仕事を探すしごと

 自社のパッケージソフトや各種ツールや技術を組み合わせて客の課題の解決をソリューションとして売ったり、営業部隊と一緒になってこれからの仕事の種を考えたり、これからの商売のネタになりそうないろんな技術を先んじて調べる仕事なんてのもあります。偉い人も一緒になって従来型のSI開発の先を目指そうと色々考えたりしています。ちなみに僕が今いるのはこういう組織です。

情シスなしごと

 情スシ、じゃなかった情シスはおかしんさん回を聴きましょう!

shiganai.org

インフラ・ネットワークのしごと

 このへんの仕事は僕は関わってこなかったので、どぞ有識者から聞きませう。僕の会社でもサーバー管理系などの仕事をやってる集団もいろいろありますが、クラウド時代にはより変わっていくと思います。
 しがないラジオにはインフラエンジニア属性の方も多数ゲスト出演されていますね。

スマホ開発のしごと

 またKotlinが生まれる前ですが、JavaAndroid開発をやってる部隊と一緒の試作案件でサーバーサイドをやったことはあります。スマホ系開発といえば(スマホ以外もやられてますが) aozora.fmでお馴染みFORTEさんが思い浮かびます。

shiganai.org

ゲーム系のしごと

 お堅めのエンプラ系開発はゲーム開発とはあんまり縁がないですね。sp.53aで話していますがかつては悪の帝国テイストがあった旧Microsoftがコンピュータとインターネットの世界を全面支配しようとしていた頃は、エンプラ世界でもMSをdisるのがエンジニアの嗜みみたいな風潮になっていたこともありました。
 そんなM$帝国の武器の一つであったお堅いC#が、時代は変わって今はUnity界隈でゲーム開発で人気を博しているのは面白い流れだなあと思います。
 しがないラジオではgremitoさんともんりぃ先生さん、ものラジ勢が詳しいです。

shiganai.org

組み込み系開発のしごと

 ワタクシかつてC言語はポインタが分からなくて挫折したよわエンジニアなので、組み込み系は門外漢です。組み込み系とか通信系ソフトなど、いわゆる低レイヤーの世界はまだC言語をがっつり使ったりしている所もあるかと思います。
 昔から使われている枯れた技術をずっと扱っているこうした組織は変化が昔のまま止まっていることが多く、バージョン管理や開発標準、マシンスペックや組織の文化、考え方が古すぎて我慢できず脱出した……などの話は退職エントリで時々見かけます。

人材リソースとしての派遣や、客先常駐が主なしごと

 まともな会社さんも多々あると思います。またこうした方々含め人材を提供してくれる会社の協力のおかげで、エンプラ系企業の大きい開発プロジェクトが成り立っているというのも残念ながら真実です。ご立派な大企業の看板を掲げていても実質外部からの要員に頼っている現場がまだまだ多いことは、僕もいつも心苦しく思っています。2020年代には少しづつでも変わっていってほしいと願っています。
 成長できそうなスキルが得られる案件を選ぶ、待遇や収入など、注意しながら進んでいきましょう。
特に、法的なところや経歴詐称などでおかしいと思ったら 脱 出 し ま し ょ う
 
 

自分の道を、楽しさドリブンで行く

 結局は自分次第だ……というのは何事にも言えるでしょう。会社の発信している情報が正しい時も、世の中の標準と照らして間違っている時もあります。周囲の人間が言っていることが合っていることもあれば間違っていることもあります。インターネット上の情報も有益なことも、バイアスが掛かっていることもあります。
 広大なエンプラ世界の中を歩み生き残ってきた中で、僕も多くの人を見てきました。沢山の人に世話になったりその逆もあり、駆け出しの頃に迷惑をかけたりその逆もあり、多数の失敗と成功から学んできました。
学ぶところの多い人もいましたし、今になって考えると何の手本にもならなかった人もいます。エンプラ世界を旅していると時々遭遇する、技術やプログラミングを軽視する風潮も無視して受け流し、自分の足で進んできた先に、今の自分がいます。

会社を盲信するのではなく、かといって全否定するわけでもなく、適度に離れた位置に自分自身の砦を築きましょう。
新鮮なインターネットや沢山ある良書、技術同人誌から情報を得て公平な視点を養いましょう。
志を同じくする人たちを見つけ、想いを分かち合っていきましょう。
ネットやオフラインのイベントから、刺激や熱量を受けていきましょう。
自分でもアウトプットを始めて、フィードバックの連鎖が力になっていくのを楽しみましょう。
共有や多様性、お互いの尊重を良しとするITエンジニアの文化を伝えましょう。
自分が楽しいと思える仕事をなるべく増やし、楽しくない仕事を減らすように動きましょう。
様々な人の辿ってきた旅路の話を聞いて、自分のジャーニーの助けにしましょう。
そんな、いろんな旅人たちの話が聴けるオススメのPodcastのひとつと言えば……
 
 

しがないラジオはいいぞ。(約束)

 
 
で締めたいと思います。(ドヤァ...
 

f:id:iwasiman:20191206204441j:plain:w500

まとめ:それぞれの「しがない」を求めて

 というわけで、予定があって忙しい(であろう)華の独身男女諸氏には投稿しにくい微妙な日だけど家庭のある人には問題ない、12/24のアドベントカレンダー記事でした。
 これからITの世界に踏み出そうとしている方も、キャリアについて考え始めた方も、現職に思う所あり脱出を決意した方も、転職活動を頑張っている方も、転職先で頑張っている方も、ナカーマが少ないですが(笑)僕のように変化が始まろうとしているエンプラ側で上手くやっていこうとしている方も、「しがない(=楽しくて仕方がない)」の形はそれぞれ。

 皆さんの「しがない」が少しでも実現できますように。しがないのパワーを既に発信している方々が祝福されますように。そしてしがないラジオを通じて繋がった輪が助けになり、聖夜のジャーニーの行く手を照らしますように。
 この記事が少しでもしがないクエストの助けになれば幸いです。クリスマスにインターネットと無限の雲海のご加護のありますように。

 それではみなさんよいお年を。そして12/25最後のアドカレ記事は満を持して、髪型を変えてパーマでイメチェンしたzuckeyさんが4回目の登場です。meetup4では2Fのロビーで判別できずホンマすんませんでした!(突然の土下座)
 

おまけだぞい

 しがないラジオを最近聴き始めた方は、たくさんの面白いゲスト回のついでに、遡ってsp.53a/bも聞いて頂けますと喜んで悶死して漏れなくTwitterで反応します。😇 shiganai.org shiganai.org

 その中でも語っている、時を遡って20世紀末の1997年に紙駆動転職した時のエモい話は2018年のアドベントカレンダーにあります。 iwasiman.hatenablog.com

去年のAdvent Calendarはこんなことを書いていました。 iwasiman.hatenablog.com

iwasiman.hatenablog.com

キャリア関係の話は他にも以下のエントリで書いていました。 iwasiman.hatenablog.com

iwasiman.hatenablog.com