いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。

OSC京都で登壇してきた

»

近況報告

どうも。Anubisです。一時期、なんか炎上火消しの仕事も疲れたなぁと思い、身の振り方を考えるかー、と考えてました。しかし皮肉なもので、コラムの更新を止めて開き直ったとたんに、アホみたいに色々と閃いた。閃きを形にしていって実行に移したら、身辺の問題が解消してしまった。

カッコつけて「コラムニストやめます」と啖呵をきって、「おまえ、結局戻ってきてるんじゃないか」とツッコミの嵐がきそうです。そうです。なんか書いちゃってます。何とでも言ってください。書きたいと思ったら書きます。ツッコミ歓迎だ。ただし、従来どおり相応の反撃はするので覚悟だけはしといてください。

で、閃いて形にしたものをまとめて、OSC京都で登壇してきた。「Powershellで切り開くExcelの新しい使い方」です。いつもLibreOfficeのコミュニティーでドキュメント云々の話をしていたのだが、今回は別の人が話してた。しょうがないので、別枠で申し込んで個人として登壇した。「エンジニアライフ コラムニストの会」なんて無いからね。

いつものノリだと、まぁ、十五人くらいきて「好評だったね」で御の字だ。同じノリでいたら、部屋に満杯だった。一番ビビったのは登壇者です。マジかよ。何であんなに人が来てくれたのか未だに分らない。来てくれた方々、ありがとうございます。大きな励みになりました。今後は個人でも登壇していこうと思う。(ただし、団体名は考えておこうとおもう)

登壇のテーマについて

今回のテーマはExcelとPowershellだった。結論から言うと、PowershellからExcelを制御しようとしてうまくいかなかったね。という話だ。SESの炎上対策をやっていたが、ぶちゃけうまくいかなかった。がんばったけど形にならなかった残念話でも、それなりにまとめれば良い内容になりそうだということで、今回のテーマにしてみた。

そもそも、SESというのはご存じだろうか?私がSESを意識しだしたのは、AXIAの社長さんの書いたこのブログを読んでからだ。SESとは、システムエンジニアリングサービスの略称だ。すごく簡単に説明するなら、エンジニアをドナドナする仕事だ。所属している会社名と、日報に書かれた会社名と、所属チームの会社名と、お客さんのところで名乗る会社名が違うアレです。

日本のIT業界の抱える大きな闇なので、エンジニアならこのくらい覚えとけと思う。名前もないクソみたいな慣習の呼び名がキチンと分ることは大事だと思う。そういうことで、私も登壇を通じて積極的にこの呼び方や、SESの何が問題かを訴えていきたいと思う。認知が広がることで問題意識をもってくれる人が増えてくれることを願う。

話が大きく逸れたが登壇のテーマに戻る。SESで働いていると使用できるソフトウェアが大きく制限される。そういう状況でも確実に使用できるソフトウェアがExcelとPowershellだ。このような制限された状況で、プロジェクトで扱われている情報を整理、解析、運用するかという観点からいろいろなテクニックや考え方を発表させて頂いた。

目的はプロジェクトの成功ではない

私の意見としては、AXIAの社長さんと同じでSESはさっさと絶滅して欲しい。では、なぜSESのためのテクニックなんか模索してるんだという話になると思う。ここで勘違いして欲しくないのは、私の模索しているのは、SESでプロジェクトを成功させるためのテクニックではない。あくまでデータを正確に把握するためのテクニックだ。

データを正確に把握すると、プロジェクトの抱える問題点がデータとして説明できるようになる。データを元に判断すると「ダメだこりゃ」という結論に達することもある。「仕事だから」という理由だけで確実に成功させようと思うのは考えが甘い。無理なものは無理だ。ダメだと分ったら覚悟を決めて被害を最小限に留めよう。私の模索しているテクニックはそういうものだ。

根本的なスキルが不足しているマネージャや、間違った手法を正しいと思っているマネージャを成功させる必要はない。「ただ言われた通り頑張りました」では、プロジェクトが成功しようと失敗しようと学べるものは無い。自分の関わったものが何なのか、データを元に把握しないと的確に分析できない。自分のキャリアが気になるなら、データを元に自分で考える習慣をつけよう。

SESをどんなに否定しようと、今そこで働いているならやるべき事をこなすしかない。厳しいがそれが現実だ。しかし、そこで言われたことを妄信的にこなすか、実態を知ろうとするか。これはそれぞれが責任を持って選ぶべきだ。実態を知るにも手段が必要だ。私が登壇を通じて伝えたいのは、知りたいと思う人が実態を知るための手段だ。クソプロジェクトに奇跡を起こす方法ではない。

SESに関わる人へ

SESの仕組みがクソなのは誰しもが把握していることだろう。しかし、スキルの無い人にとってはSESがユートピアだったりする。スキルの無いマネージャでもリーダー待遇で働いて家庭を持つことができるし、残業は多いが言うことを聞いて社畜に徹すれば、食いっぱぐれる心配はなくなる。待遇は厳しいが、失敗に対するいい訳は完備されている。

クソならクソなりに存在理由はある。SESは批判だけでは無くならない。既得権を握った人が現状の変化に断固抵抗する。撲滅しようにも、撲滅したい人が今、そこから抜けられない状況だったらどうするのか。誰もが利益を損なわずに短時間に、誰もが実行できる手段なんて無い。それができるならノーベル平和賞が狙えることだろう。

問題を解決する手段は浮かばないが、それぞれが一歩進むための手段くらいならなんとかなるだろう。これからも、そういう手段を考えて積極的に登壇していきたいと思う。私の考えるテクニックで、クソみたいなプロジェクトが成功することは無いと思う。ただ、実践することで考え方のバリエーションが広がることはあり得ると思う。

次回の登壇は、多分、秋に開かれるOSC東京になると思う。これからも積極的にアウトプットしていきたいところだ。今とり組んでいるのは、対SES炎上対策Powerrshell、通称「力技(ちからわざ)」だ。難しいことは置いておいて、何かしら具体的な形にできればと頑張っている次第でございます。気が向いたらちょくちょくコラムを書くかもしれません。

Comment(11)

コメント

仲澤@失業者

自分もフリーランスのUI系プログラマですが、契約形態はまぁ似たようなもんです。
仕事にする言語を限定させてもらっていてC++とAndroid用Javaだけ受けてます(Objectiv-C、Swiftも可)。
ところで、今までできの悪いリーダーというのをあまり見た事がありませんし、クソなプロジェクトに参加したこともありません。個人的にはリアリティがないんです。
データベース系の仕事にはそういったことがあるとは聞いてますが、もしそうならその仕事の性質上、そうなりやすい理由などがあるんでしょうか。
どうなんでしょう。

Anubis

> 仲澤 さん


クソなプロジェクトに参加したことがないのがなんでだかは分かりません。ただ、幸福な人であることは間違い無いです。SESは労働形態として問題があり、腐敗が進みやすいです。だからと言って、全てが腐っている訳ではないです。


金融系の案件では、何故か無駄な手数が多く頭の固いマネージャとよく当たります。分野によって何かあるのかもしれませんね。

過去から続いている因習によって、現在、何らかの不条理に悩まされているとする。
取り得る態度は、次の3つですね。


■松コース:
不条理の根本的な解決を図る

 
■竹コース:
自分にできること、できないことを見定めて、根本的な解決よりも、漸進的な改善を図る

 
■梅コース:
誰か他人に愚痴る、またはネットで一方的に愚痴を書き殴る

 
梅コースは、当人のストレス解消に多少は役立つので、一概に否定はできませんが、聞かされる(読まされる)ほうにとっては、つまらないですよね。
やっぱ竹だよ竹!
竹竹!

Anubis

> ぬ
じゃ二度と来るな。

私のコメントが不愉快だったようですね。
その理由を理解した上で、お詫びが必要であればお詫びしたいです。
 
私は、元記事の
>問題を解決する手段は浮かばないが、それぞれが一歩進むための手段くらいならなんとかなるだろう。
 
という内容を読んで、
「自分にできること、できないことを見定めて、根本的な解決よりも、漸進的な改善を図る」
 
という意味だと解しました。
先のコメントの意図は、その思想への同意を示したかった、というものです。
 
しかし、当のコメントを読み返すと、逆に、揶揄しているように受け取られても仕方ないなぁ、と感じました。
あるいは、「揶揄」とまでは行かなくとも、「重んじるべきものを、不当に軽く扱っている」ようにも読めます。
 
とりあえず思いつく理由は上記のとおりです。
仮に、それが不愉快の理由であったとするならば、確かに私がお詫びすべきものです。
申し訳ありませんでした。

Anubis

> ぬ さん
改めて頂いたコメントを見て、本当に伝えたかった意味が理解できました。


私がコラム中でSESをクソだと書いているので、「梅コース」と受け取っていました。「竹コース」だったんですね。だとするなら、私の付けたコメントが不適切でした。お詫びします。


誤解を解くために誠実なコメントを頂き、ありがとうございました。

BM

「SES炎上」というのが良く分からないです。
「プロジェクト炎上」というのはいくらでも経験したのですが、
その中にはSESもプロパーも存在しています。
「SES炎上」というものを説明して頂ければうれしいです。
(コラムになるかな?)


P.S.
SESというシステムがクソというのは同意です。

Anubis

> BMさん
「対SES炎上対策Powerrshell」ですかね?


SESだと構造上、炎上しやすいというのはご存じかと思います。ただ、炎上の仕方にパターンがある。ずばり、データのまとめ方が雑すぎるので炎上しやすい。SESで与えられる標準的な環境(Windows に Excel と Word しか入っていない) でも雑なデータに対応できるように考えたPosershellの使い方が「対SES炎上対策Powerrshell」です。


いずれコラムでも書いてみようかと思いますが、別途、GithubやらQittaなどに具体的な手段は書こうかと考えてます。次のOSCで、この話題で登壇する予定です。

BM

Anubisさん。ご返答ありがとうございます。


>SESだと構造上、炎上しやすいというのはご存じかと思います。
すみません。SESだから炎上しやすいというのは経験した事が無いです。
過去炎上したのは「上流工程の致命的ミス」や「スケジュールを考えてない無茶な仕様や変更要求」
が経験したものです。
SESが社員よりコキ使われるのはままありますが、
それはSESだけでなく下請けの会社社員も同様です。


>SESで与えられる標準的な環境(Windows に Excel と Word しか入っていない)
上記に書かれたツールしか使わせてもらえないからいう事でしょうか?


具体的な手段はOSC待ちとして「SES炎上」の概念をコラムで掘り下げてご説明頂けたら幸いです。


ファンより。

Anubis

> BM さん


SESについては、私がコラムを書くよりもわかりやすく書いてくれているブログがあります。
今、疑問に思っていることの大半はここを読めば「なるほど」となります。


-- 残業ゼロのIT企業アクシア社長ブログ --
https://axia.co.jp/blog


こちらのブログとは別視点で、SESに関するコラムはいずれ書いてみようと思います。

BM

Anubisさん。ご返答ありがとうございます。

提示頂いたURLを読ませて頂きます。

コラムを楽しみに待っています。

コメントを投稿する