IT業界で仕事をするということは、結局、どの技術でご飯食べていくの、という話

anond.hatelabo.jp

ブコメでも書いたけれど、大変なんですねー。web界隈は。それともSIerの嫉妬か、新卒が集まらなくて役員あたりから猛烈にプレッシャーを受けている人事の中の人かな。

でもSIerだってピンキリ

Web系がアレなんだったらSIerでいいじゃん派です。

とはいえ、SIerもピンキリです。自称SIerが混じっているのかどうか知らんけど。大昔に、

　SI登録・SO認定（METI/経済産業省）

こんな認定もありましたが廃止となってしまったので、名乗りたいなら誰もでSIerと言えるわけですよ。今は。まあ、元々の認定が意味があったのかどうか知りませんが。

何かを括るとき、基準のないものはゴミ箱になることを知っているのがエンジニアという生き物です。設計で「そんなデータ項目持つんかい」とか「それいるのか」的なことばかりでしょう。

IT系に夢を持ってるの

 間違ってIT業界を目指そうと思った学生がIT業界に思い描くイメージって結局何もないんだと思うんですよ。

だって、働いたことないんですよ。今はインターン制度とかありますけどね。アレ実質青青田刈りみたいなものというか、場合によっては研究室からの人材供給のパイプラインでしょう。

そういう研究室経由は昔からありますもんねえ。

それでも、インターン制度で経験したとしても実務の一部だし、実際の開発の一部分だけなわけです。つまり、エンジニア目線から見て一番ピュアなエンジニアリングのところ。美味しい部分、です。コード書きたいんだから。

インターンで知っているとしても、逆に一部分、そこだけしか知らないのよ。

他が闇かもしれないのに。

いつも言われている（と思う）けど、就職なんてイメージで決めているんじゃないですかね、IT業界を目指していたり希望を持っていたりする学生は。というか、希望を持っているのかしら、そっちの方が疑問ですわ。

Web系それともSIerで夢を見たいの

Web系とかって小さいイメージですよ。中小企業。そう考えると、オーナー、創業者の意向は絶対だし、ビジネスモデルが焼畑（案件を外から取ってきて納めての繰り返し）だと案件が途切れたり、赤字になるとすぐ人員調整だよねえ。

小さいなら自社サービスじゃないと、夢持てないよねぇ。

大きなWebサービスの会社だとそれ仕事的には大手のSIerと一緒ですよ。官僚ぽくなって。お家の家風、カンファレンスに行きやすいとかカジュアルだとかはどっちかといえば、事業会社の方が似ていますよ。やはり、サービスを作って売っているか製造して売っているかというところでの背景的なところに共通項があるのでしょう。

SIerでも中堅ならといえばユーザ系があるけれど。ユーザ系SIerとは親会社のIT部門かそれのシステム子会社。ただねぇ。売られちゃいますからねぇ。メーカ系に。そういったリスクはあるんですよねえ。

働いてみないとわからんけど

結局、働いてみないとわからないけど、コーポレートブランドで選んでもアレな会社はごまんとあるし、小さなWeb系でも事業をしている会社でちゃんとやっている渋谷系もあるし。

どの技術でご飯を食べるのか

 ただ、ずっと、30年以上も働くんですわ。今の世の中は。それこそ増田の資産家のごし子息かご令嬢でもないのなら。

まー働きます。30年以上。

そのとき、どの技術で食べていくかということなんですよ。ずっと実装するの（これはいいと思う）。ずっとSEが作った資料をまとめる仕事があると思っているの（年寄りにやらせてもらえるわけがない）。中間管理職続けるの（途中で外されますよ）。

フライパンで山ごはん シンプル・簡単なレシピ90

調達 Amazon Echo Dot (Newモデル)…Newモデル？？？

出たばかりじゃん的なかんじなのにNewモデル？？？ 

Amazon Echo Dot (Newモデル)、ブラック

Amazon Echo Dot (Newモデル)、ホワイト

プロジェクト計画をPMひとりで作る時代は終わった

とあるゆるゆるな会合で相談を持ちかけられたというか、あなただったらどうする的な感じでネタを振られたんですね。

どうやら、おかしくなっているプロジェクトがあって第三者の立場で見てレポートするのがお仕事だったらしい。

あなただったらどうするとは、よく聞いてみると２つあって、

• 第三者の立場でレポートに何を書くか
• もし立て直すならどうするか

それが上の２つ。

トラブルプロジェクトのレポート

 必ず書かなければならないのは、依頼者が知りたいことですね。まず、大前提に第三者レポートが必要になるということは、組織の中で正確な情報がレポーティングされていない、という背景があるかもしれないということ。

正しい客観的で定量的なレポートが上がっていれば経営者はそれで判断できるものだし、それがあるべき姿です。

得てして、中間管理層だったり現場のPMが（根拠なく）まだ大丈夫だと思っていたり、そもそも（鈍感で）気づいていなかったりと原因は色々あるけれど、レポーティングされないという結果は同じですがそう言った正式なルートでは上がらずに、間接的に耳に入るとそりゃもう、疑うわけです。大丈夫か、と。

そこで何をしりたいか。

経営者であれば見通しです。あとどのくらいコストがかかるとか、いつリリースするのかとか。そのあとの運用はどうなんだとか。

もし立て直すなら

 会合の場ではこっちが主題でしたね。自分なら、あれこれとしようと思うんだけどあなたなら、と。

そのあれこれが手法、技法のことばかりで、そうなのかなーと。

例えばペアプロでとか、テスト自動化云々とか。

それはそうなんだけど。

それはプロシージャや道具の話で細かすぎると思うんですよ。あちらこちら傷を負っているのに絆創膏を持ってきてどうするんだ、と。

その対処で80％のギズが完治しそうならそれでもいいのでしょうけれど、多分、それではまた別の傷を作ってしまうのでは、と。

チームに聴く

チームに聴きますね、と。どうやってこの先、ゴールまでたどり着くのか、と。それを具体的に、詳細に聴かせてください、と。

おかしくなるプロジェクトは、目先のタスクしか考えていないことが多いです。あと、メンバが言われたことをやるチーム。

作るのはチームなのにね。

つまり、プロジェクトのプランがメンバのものになっていないんですよ。これではちょっと時間を作るとわかる、作業の手順や成果物の構成の欠落に気づかないままに進めてしまって手戻りややり直しでの不満を自分たちも一緒に作っていることになるんですよ。

もうね、プロジェクト計画はプロマネ一人で作る時代じゃない。作ってもあくまでも案です。たたき台。それを回すチームが、自分たちで回すために使えるプロジェクト計画にバージョンアップしないといけない。

もう、今はそんな時代なんです。だって、システム開発の手法やマインドセットはそっちに移り掛けているんですから。 

まとめ

実を言うとそのプロジェクト計画書はもうダメです。
突然こんなことを言ってごめんね。
でも本当です。

プロジェクトが開始すると
PMが作ったプロジェクト計画書が出てきます。
それが終わりの合図です。

チームはそのプロジェクト計画書に関心を持ったり
見たりしません。

程なく小さなトラブルが起きるので
気をつけて。

それを対処している間に、少しだけ間をおいて
デスマがきます。

働き方の哲学 360度の視点で仕事を考える

維持管理に埋められた新人SEをアジャイルに慣れさせる冴えたやり方

マインドセットやリリースまでのスピードではアジリティがないかもしれないが、それ以外は、アジャイル開発の要素が揃っているのである。

契約

 まず、契約面においてが重要である。スコープを決められない保守運用・維持管理は決められないからこそ、面倒を見る範囲を決め、ヘッドカウントでできる範囲でという準委任契約で締結することが多い。

スコープが決められないのだから見積もりができない。よって、請負契約では契約できない。していたら、政治的な理由があるか偽装請負の可能性が高い。

なお、偽装請負の場合は、その案件の上から下まで全員しょっぴかれるらしい。

一般的な保守運用・維持管理のイメージを以下に示す。保守運用と維持管理の違いはその契約を締結する組織や顧客の文化的背景で使っているのではと思うがそこはテーマではないのでここまで。以降は維持管理で統一するので。

横軸は時間で、縦が道幅である。つまりエンジニアの工数。ヘッドカウント。

このほか、維持管理に必要な技術要素が含まれる。

契約の観点では、維持管理の作業（メンテナンス、拡張等）のサービスを行う作業の定義や定量的な作業上の制限を設け、それを超える場合は事前に協議、などの制約を設けることもある。

作業

現場での作業は、基本的な作業計画を立てて行う。ベースとなるのが不具合対応で優先されるものである。システム運行上のハウスキーピング的な作業やシステム拡張がある。この他、セキュリティの脆弱性対応なども計画的に行うものと緊急対応するものがある。

これらをどこまでやるかは契約時に決めるが、そうした範囲の作業を年間で計画し、一定のサイクル、月次や四半期などのサイクルで維持管理業務を制度化する。制度化するのはプロセスづくりと本番適用の計画を立てるということである。

これをやらないと人的リソース管理が破綻し、維持管理で契約のキャップがある場合は赤字になってしまうのと人のやりくりができなくなる。

 上図の期間の繰り返しを見て何か気づきはないだろうか。

期間ごとにリリースするということはスプリントを回しているのである。

要員

アジャイルな開発では要員を固定化することで様々な恩恵を受けることを進めている（意訳）。

開発スピードをあげようと思ったら、コミュニケーションのハードルは低い方がいいし、成熟度も上がった方が良いに決まっている。まあ、それはウォーターフォールでも同じだけど。

維持管理は比較的というかシステムをサンセットするなどがない限り同じ要員で走り続けることが多い。それはシステム運行に必要な業務ドメイン的な知識の蓄積が暗黙で求められているからだ。

結果的に要員が固定化するので新人SEが維持管理に配属させられると蝉になるわけだが、それはさておき、アジャイルな開発の必要要件の一つを満たしている。

導入言ってはいけないこと

もしこれを読んでアジャイルな進め方が合っていそうだと思っても、間違っても契約上はもちろん、顧客にアジャイルで維持管理をやります、とは言わないこと。

あくまでも維持管理チームの中での運用的な位置付けにとどめておくこと。アジャイルなら人は少なくて済むのだろうとか、逆に文書は作らないのだろうというような、誤解から変な方向に行かせないためである。

それにやってもないこと（ここでは今までの維持管理のやり方からアジャイルなプラクティスを取り入れた維持管理）をできますなんて言えないのだから。

ただ、受け身な仕事の仕方を少しずつ変えていきたいとか、蝉になってしまいがちなSEに技術的な養分を与えたいなどの狙いがある場合は、運用の改善として進めるのが良い。

冴えない彼女の育てかた Memorial (ファンタジア文庫)

失敗の％に意味はない。失敗するのがプロジェクトである

日々、飽きずにプロジェクトマネジメント やそれに関連したエンジニアの育成について書き溜めているが、専門がプロジェクトマネジメント だからとか、マネージャだからとかドメイン的に書けるからという安直な理由はあるけれど、経験したことを自分の中で大事に温め続けていてもいいことは何もないから、だったら、使ってくれる誰か（エンジニアしかいないかもしれなけれど）よかったら活かしてくれればいいな、くらいの気持ちと単なる習慣なんですけれどね。

失敗は半数、7割、どっち

何がは、プロジェクトが、です。

どこでもプロジェクトは成功することを前提にしている。成功すると思っているから、半数が失敗だ、という物言いになるのでしょう。

tech.nikkeibp.co.jp

10年ちょっとくらい前のPMIの配布物では、7割くらいのプロジェクトが失敗していると記事を読んだ気がする。10年も前のことだし、英語だったしで、曖昧だが多分そうだろうと思う。

失敗の％は作っている

数年前の日経コンピュータか日経システムズでプロジェクトの成功は7割くらいまで上がったと見た記憶があって、そりゃすごい、ほんとかね、と思った記憶がやはりあって、で、３月１日号の表紙をパラパラと見てふーんと思ったんですよ。

まあ、アンケートを誰（ユーザかSIerか）から取るか、成功の指標値を何にするかとか、アンケートを作る側が作る際にどのように記事を持っていきたいかで自由に設定できるから、％を見てどうの、こうのを語るのは意味がないんすよ。

定量的に取れる数字と顧客満足度などの定性的評価にならざるを得なくて回答者の胸つき三寸で回答している項目があるのですからあまり数字に意味はないんですよ。

失敗することが大前提

 どうして、なぜ、プロジェクトマネジメント が存在するのかを考えてみてください。

プロジェクトが成功しないから経営にインパクトを及ぼします。ひどい場合には会社の存続が危ぶまれることになる。

だから、厄介なプロジェクトをマネジメントしようとするわけです。

つまり、プロジェクトは失敗するんです。

それが大前提。

話はそこから。

失敗して会社がなくなるのは社会的責任やウンタラカンタラで困るから、そうならないようにしようよ、と。それがプロジェクトマネジメント をする理由です。

だったら、失敗しないと「思われる」ことを続ける他ないのです。会社を潰したくないので。

でも、プロジェクトは失敗すると最悪の事態を想定しつつも、楽観的に進めるしかないのです。

ガルパンでも観て勉強しましょう。

ガールズ&パンツァー 最終章 第1話 (特装限定版) [Blu-ray]

システム開発は複雑化、高難易度化しているっていうけど残された道はデスマしかないの

とある勉強会でパッケージベンダの講演を聞いていたのだけれど、ああなるほどねという感想とそれはどうなの的な感想があったのでそのメモ。

プロジェクトは複雑化高難易度化しているか

 ここ数年、ソリューションでも方法論でも、記事の出だしでもプロジェクトは複雑化しており、難易度も高くなっているという論調で始まっているのだが、本当だろうかと疑いを持って聞くことにしている。

実際、そうなのかもしれないが、そういった論調で始めないとソリューションなり方法論が売り込めないからなんだろう、とマーケティングの常套句的に煽っているのだろうという見方をしている。

環境の変化

 疑いつつも実際にはオンプレやASP的な業務システムやそれを支えるインフラ、ネットワーク環境が、クラウドサービスの流入により組み合わせが単純ではなくなった。ベンダの囲い込みによるロックインからサービスを手早く取り入れ早期に利用することを狙っての採用が増えている。

これにより、既存のオンプレとクラウドサービスの組み合わせでシステム全体として利用環境が複雑化した、というのは以前と比較すればそうだな、と思う。

難易度についてもエンジニアはITSSにあるように専門化が進んでおり、技術的に複雑化すればプロジェクトとしての必要とするスキル、スキルレベルが多様化するため、難易度が高まるという観点も理解できる。

実はそれほど変わらない

オンプレで半ばクローズドな従来のシステムでは環境は変わらないからそれは除くとして、クラウドサービスが流入しているようなシステムの開発ではどうすれば良いのかということである。

モデル的な考えで見れば、ベンダロックインされたシステム環境と実はそれほど変わる点はないのである。

ポイントは、手をつける前にどれだけわかっているか、である。

 成果物、成果物を構成する技術要素、成果物を作成する手順、成果物の要求品質が把握できていれば複雑化、高難易度化したプロジェクトであろうと従来のクローズドなシステム開発でも同じである。

逆に言えば、従来のクローズドなシステム開発でも 成果物、成果物を構成する技術要素、成果物を作成する手順、成果物の要求品質が把握が必要であっって、それができていないから失敗するのである。

クローズドなシステム開発であっても新技術の導入はあるし、それをするならフィージビリティスタディを行いプロジェクトリスクを下げることするのだから、同じように複雑化、高難易度化したシステム開発であればこそ、それをしなければならない。

結局やることをやっているかどうかなだけだ。

今必要なことは

 それはどうなの的なことといえば、それ、つまり複雑化、高難易度化したシステム開発で先端的なトレンドになるかどうかかもしれないが、当たり前のことを当たり前にするには、プロジェクトマネージャ1人ではプロジェクト計画書すら作れる質、量ではない、ということに対するアプローチだ。

 冒頭の講習でもそうだが、プロジェクト計画をプロマネが1人で考えるのではなく、（たたき台というかプロマネはこう考えているけれどという案を持ち込み）チームでそれを仕上げるための支援ツールや（最近アジャイル開発系のカンファレンスで見かけたが）ワークショップとしての導入論をコストを掛け、採用する必要があるのではないか。

ここである。

複雑化、高難易度化しているというならそれの対処をしなければならない。環境が変わっているのだから。

ゆるキャン△ 1 [Blu-ray]

間抜けなマネージャは自分のやり方を押し付け事細かく聞きたがる

タイトルが長くなるので端折っているが、文字数を気にしないならこうタイトルをつけたい。

本当はこう付けたかったタイトル

「間抜けなマネージャはマネージャが考えたやり方を部下がその通りやっているか詳細にトレースし、できるマネージャは確認だけする」

そして、今日書きたいことはこれで全部である。以上。

とするとツイッターで収まってしまう文字数なのでなぜかを少しだけ説明する。

もし、自分に間抜けなマネージャの要素の1つでもあったら、月曜日からは気にして、変えていこう。

間抜けなマネージャは間抜けである

間抜けなマネージャがなぜ間抜けなのか。間が抜けているという意味では使っていない。マネージャの役割を負っているのにマネージャの仕事をしていないから間抜けなマネージャなのだ。

マネージャの仕事

マネージャの仕事は、たったこれだけだ。

「部下の特徴を見つけ、その特徴を活かす」

何に活かすか。わかりきっていることである。属する組織の目標を達成するためにリソースである部下の特徴を知り、その特徴を最大限に活用できるように活用するのだ。

間抜けなマネージャは部下を知らない

 間抜けなマネージャは部下を知らない。なぜかは後述する。ただ、できるマネージャは部下が何が得意か、どんな仕事をすると楽しいかを知っている。

マネージャの傘下に属する部下は配属された時点でリソースが１である。１であるから貢献は１以上でなければならない。

なぜ１以上なければならないかがわからないエンジニアは効率性について語る資格はない。外部にだけ効率性を求め、自分には効率性を求めないエンジニアの話を聞く価値なてないのだから。

話を戻して、１以上の貢献をしてもらわなければならないが、その貢献をしてもらうに当たっては、最小限のコストや負荷で貢献してほしい。たとえ0.6の成果しか出なくても２倍働くことを前提とすれば1.2が得られるから組織への貢献としては一見、良さそうだ。

それが良くないのはコストが２倍になっていることと、負荷が２倍になっていることですぐに故障してしまうというリスクを含んでいるからだ。

コストは計画値以内であればよい。一円でも少なければ十分である。差が０であれば合格ラインである。

ところが、１の貢献をして欲しい、計画のコストで実現して欲しいと思っていてもその貢献に使用するスキルが部下が持っているスキルと一致するとは限らない。多くは一致しない。なぜなら、部下自身がどのスキルが一番効果的に活用できているかを知らないからだ。

省力で最小限のコストで最大限の貢献をしているかどうかで物事を見て判断していない。先に感情が立ちふさがる。好き嫌いである。

これを排除して部下がどのような長けた特性を持っているかを知らなければならない。その上で、好き嫌いを知っておく。好きより嫌いを知っておく。嫌いな仕事に当てると効率性が下がり、不良というトラップを仕込むからだ。

間抜けなマネージャは部下を知らないし、知ろうとしない。なぜなら、頭数でしか部下を認識できないからだ。目の前に降りてきた仕事を目の前で手が空いている部下にもじどり振るだけの仕事をしているだけなのだ。

仕事の成果の伸び代を上げたければ、成熟による効率性と道具を変えることによる生産性の向上だとする発想が必要だ。それを考慮せず、目の前に回ってくるさらにタンポポを置くように部下を配置していればタンポポ以上の仕事はしてくれない。

間抜けなマネージャは押し付ける

間抜けなマネージャは間抜けなマネージャが振った仕事のやり方まで押し付ける。マネージャならこうやる、というプロシージャの通りにやらないと不機嫌になる。

だから、事細かく口を出してくるし、細かい進捗の確認をする。

別に細かい進捗の確認が悪いわけではない。なぜ細かく確認しているか、その目的が自分が考えるやり方でやっているかどうかで聞いているからダメなのだ。

他人に箸の上げ下げまで監視され、文句を言われたら楽しいわけがない。そういうことだ。

できるマネージャ

できるマネージャは、仕事を始める前に期待を伝える。部下の得意を知り、考慮した役割に着かせる。部下が最大限の貢献をできるように環境を作ることで部下が考えて仕事するように仕向ける。あとは、部下が期待に応えるために考えたことを部下の報告で確認し、部下がそれをやったと報告を受けたら結果を確認するだけだ。

はぴはぴ くるねこ 1 (enterbrain)