SEの夏休み

SEの夏休みと言うと、プロジェクトの貴重なバッファ期間だったりします。プロジェクトのバッファとは、予定していた作業が予定どおり進まない場合、この期間を消費して、予定に追い付かせるためにつかう期間と言う意味になります。

では、プロジェクトの進捗が順調なことはあるでしょうか？

いいえ、まず無いでしょう。何て言ったって、我が国はメテオフォール型開発が主流ですから。(ウソ)

そんなわけで、夏休みをプロジェクトの遅延のリカバリーに使ったと言う経験を持つSEは多いのではないでしょうか。

私もそんな平民SEの一人です。夏休みと言えば進捗リカバリーです。

この期間がなぜリカバリーに最適かと言うと、普段の定例会議、進捗報告会などどは開催されません、一日中、使いたいように時間を使えるようになります。そして、この期間は神様も持ち場を離れているようでメテオやらコメットやら落ちて来ません、安心です。

ですから、安心して集中して、チームメンバと一緒にテストを消化したり、機械のログを解析したり、平日では考えられないくらいの集中力で、一気に進め、進捗を追い付かせる事ができたりします。そして、私にとって久しぶりに機械をさわったり、実機のログを自分の目で見て、解析する数少ないチャンスだったりします。

元々、機械をさわるのが好きでSEになった身分ですからね、こういう時間ってケッコウ嫌いじゃないんです。

そんなわけで今年の夏休みは

夏だ！遅延だ！リカバリーだ！

ずっと夏休みのままなら仕事しやすいのに(ｪ？)

SEってなんだろう

一口に職種SEと言うけど、よく考えるとSEは何をする仕事かわかりずらいので、SEの分類を考えてみた。

◼️成果物による分類

○プログラマー

いきなり、SEじゃないって怒られそうですが、隣り合うし境目が曖昧な部分もあると思います。成果物はプログラム、ソフトウェア、アプリケーション。ゲームの場合のみ別格の憧れの職種となっていてゲームプログラマーと言われる。

○Webデザイナー

プログラマーは直接目に見えない仕組みの作り込みをするのが仕事の中心なのに対して、Webページの実際に目にする画面を作る人。目に見えるレイアウトや色合いなどを中心にプログラムを少し書くこともある。

○アプリケーションエンジニア

アプリケーションやサービスを設定し使える状態にする人？プログラマーが作ったソフトウェアをインストールしたり、一般公開するひと。

○インフラエンジニア

主にサーバの基本的な設定やサーバで共通的に動かすアプリケーション(ミドルウェア)の設定、ディスクやストレージの設定を行う。アプリケーションが動く環境を整備する仕事。アプリケーションが動く環境は常に整えられている事が当たり前だと思われているため、アプリケーションエンジニアに虐げられている。

○データベースエンジニア

データを保存するとき、その情報を参照しやすくしたり、壊れにくくしたり、消失しないようにする必要があるため、効率的なデータの保管方法を考える必要がある。このようなデータ管理を行う仕組みをデータベースと言う。データベースもミドルウェアの一部と思うが、設計に特別な配慮が必要なため、インフラエンジニアとは一線を画し、このように呼ばれる。

○データサイエンティスト

AI関連の流行りの職種。データベースのように体系化されたデータの扱いだけでなく、様々なデータの扱い方を考えAIでの活用の仕方を考える仕事。流行りっぽくて響きがカッコいい。

○ネットワークエンジニア

ネットワーク機器の設定を行い、組み合わせてネットワークを作る人。インフラエンジニアの設計が終るとネットワークの要件がようやく決まるが、サーバやストレージの構築にはまずネットワークが完成品している必要がある。今や全ての足回りとして動いていて当たり前であり、最も虐げられている職種。

○フルスタックエンジニア

上記の全てのの知識を持つエンジニア。だいたいなんでもできる。システムが複雑化している昨今、重要性が増しているが、あくまでもSEの枠組みであるため他のエンジニアとあまり待遇が変わらない不思議。

○アーキテクト

フルスタックエンジニアでありつつ、システムの全体の構造を考える役割。担当者間に溝があったり壁を作ったり、個別最適が問題となっているため、この役割への期待は高まっているが、いざ何かをしようとすると、誰にも理解されず孤独を感じる仕事。

◼️成果物の納品先による分類

○社内SE(システムエンジニア)

成果物が自社の資産となるSE。発注側となるため、良いポジションなのかと思いきや、社内の業務部門から虐げられている。

○SE(システムエンジニア)

お客様から費用をいただいて、成果物をお客様に納品するSE。あまり、社外SEと言う言葉は聞いたことがない。ラインSEと言う人もいる。

○公共SE(システムエンジニア)

大規模で社会影響の大きい公共(政府)系が顧客の案件をこなすSEを敬意を表して公共SEと言う。

○金融SE(システムエンジニア)

大規模で社会影響の大きい金融系が顧客の案件をこなすSEを敬意を表して金融SEと言う。

◼️工程による分類

○上流SE(システムエンジニア)

プロジェクトの前半の要件定義や、基本設計を主に担当する。上流は階級の話ではない。会議ばっかりして、決定事項を○○書と言うドキュメントにまとめるのが主な仕事内容。プロジェクトの後半に入るとまとめ役的な仕事が増える。

○下流SE(システムエンジニア)

響きがよくないのであまり、下流SEと言われることはなくシンプルにSEとだけ言われることが多い。ウォーターフォールモデルで川の流れに例えると、川の河口で川幅が広がった部分を担当する。別に3流と言う意味ではない。上流工程でドキュメントにまとめられた内容を参照してシステムに反映させ、実際に動くものとして形にする仕事。机上の空論と言う言葉があるように、実装の際にはいろいろな問題が発生するのは当たり前だが、問題が発生するとなぜか立場が悪くなるため、日々過重労働により問題の沈静化に努めている。

○プレSE(システムエンジニア)

上流SEのさらに前に提案活動をのみ行うSE。だいたい受注のために魅力的すぎるが実現性が不透明な案件を提案する。受注後にプロジェクトを推進するSEから誰がこんな無理難題を約束したんだよって、嫌われる。

○QAシステムエンジニア(品質保証)

最近ある会社がよく使ってるよう担った言葉。一般的には作ったシステムが思った通りに動いているかテストする作業は下流SEのタスクに含まれるが、検査の客観性やシステムの複雑化によって検査そのものが難しくなっていることから、システムの検査に特化した知識をもって体制をつくるときに現れる役割。たぶん下流SEの突かれたくない部分をつつく仕事なので、下流SEからは嫌われる。

○維持SE・運用SE(システムエンジニア)

稼働中のシステムのメンテナンスを行うエンジニア。作業ミスがシステム停止に直結するため、難しいリスクのある作業はしない。誰よりも最新構成の管理の、大切さを知っている。

◼️技術的知識の活用度合い

○SE(システムエンジニア)

仕事のうちの大半は自身の扱う製品に対する技術的知識を中心に活用する。プロジェクト管理の知識も必要だが、自身タスクをしっかり管理する程度の割合。

○PL(プロジェクトリーダー)

プロジェクトの中で一つのチームをまとめる。インフラチーム、アプリケーションチームなどのグループができるイメージ。担当する対象についての技術的知識に主軸をおきながらも、チームをまとめる為のプロジェクト管理の知識が要求される。

○PM(プロジェクトマネージャー)

プロジェクト全体をまとめる仕事。技術的な知識と、プロジェクト管理の知識が50：50で必要と言われている。プロジェクトの成否の全責任を追うため非常にプレッシャーがかかる。

○PMO(プロジェクトマネージメントオフィサー)

特定の製品に特化した仕事はせず、プロジェクト管理の専門家としてPMを支援する仕事。プロジェクトマネージャーをとりまとめる上位組織と思いきや、実態としてはプロジェクトマネージャーの事務局的な仕事だったりする。

SEと言っても職務内容はその現場によっていろいろ。また、人によってカバー範囲や解釈も違うかも共通点と言えばなんかブラックと言うイメージがつきまとうことくらいでしょうか。。

メテオフォール型開発と2025年の崖

メテオフォール型開発(※1)とは、2018年に日本で提唱されたシステムは開発手法。

当時、日本でもPIMBOK6版が出版され、従来のウォーターフォール型開発に加えアジャイル型開発が体系に追加された。これにより、システム開発の現場では実務の状況に合わせたシステムの開発手法の選択が推奨されるようになりました。

そんな中、当時の日本で最も広く活用されていたとシステム手法の特徴を叙情的に体系化したものがメテオフォール型開発です。

メテオフォール型開発はトップダウン的にリリース内容とリリース日のみを黙示録と言う形で決定し、あとは現場のエンジニアが死ぬ気でなんとかすると言う開発手法です。

現在の日本のレガシーシステムは、メテオフォール型開発によって開発され維持されているものが少なからず存在するとか、しないとか考えられるが、最近の労働環境の変化の影響を受けてメテオフォール型開発の継続が困難になってきている。これが2025年の崖の問題のひとつの要因(リスク)と考えられる。

元々、メテオフォール型開発を成功させていたのは、スーパーSEと呼ばれる人達の貢献によるものが大きい。スーパーSEはシステムの稼働を全てに優先させることを美徳とし、生活の全てを仕事に捧げる人たちです。また飽くなきテクノロジーへの探求心により幅広い知識を得ていて、さらにその知識をより拡張性し続ける人たちです。一説によると週90時間程度を目安に働いていたとか。業界では神に近い存在で、目に見えないデータの流れが見えたり、複雑怪奇なシステムの全体像を把握していたり、言ってみたら預言者です。これらの人達は日本の大規模ITシステムの黎明期から第一線で走り続けている人が多く、常にIT業界を第一人者として走り続けてきた人達と言えます。

しかし、これらの世代が加齢により、徐々に第一線を退く年代となってきました。それに加え、近年の労働時間管理の厳格化、ライフワークバランスを重視する価値観への変化、転職市場の活性化によるスーパーSE候補のコンサル化(※2)が進んでいます。これにより新たなスーパーSEは生まれにくい環境となってしまいました。結果としてシステム開発の現場にいたスーパーSE達が急激減っていくことでしょう。

このような背景から2025年の崖の問題を考察すると、メテオフォール型開発が破綻するリスクが、スーパーSEの消失により顕在化する可能性ある時期が来た問題と捉えることができます。

そこで、2025年の崖を乗り切るための対策案を考えてみました。

1.ズバ抜けた報酬の募集によるスーパーSE候補者の獲得(コンサル化の防止)により、無理やりメテオフォール型開発を推し進める。

2.雇用延長による現在のスーパーSEの延命により、無理やりメテオフォール型開発を推し進める。

3.スーパーSEに依存しない開発手法の実現のため、メテオフォール型開発を取り止め、アジャイル型開発の応用した、無理の無いショートゴール設定と、進捗阻害発生時の目標(ショートゴール)の見直しを可能とする。

レガシーシステムに悩みを抱える日本企業は、まずは自らのシステム開発手法の現状を調査し、必要に応じてこれらの対策案を検討するべきだと言うのはきっと過言でしょう。

残念ながら、多分この話はフィクションです。

(※1)参考url

https://eiki.hatenablog.jp/entry/meteo_fall

(※2)スーパーSE候補のコンサル化の問題は、コンサルがシステムの稼働の責任を追わない職種であること。多くのコンサルはシステム開発の上流工程のみを担当する。一方、スーパーSEは下流工程まで責任を持ってやりとげるため、メテオフォール型開発の実行力がある。

奴隷SEを育てる魔法の言葉

とある日経の記事にて、SIerの奴隷根性を何とかせよとアブラギッシュな顔で語られている。あまり好きじゃないつもりであったが、いつもついつい目に止まり、読んでしまう。結局のところファンになってしまっているのかもしれない。

さて、その方の好きな単語である奴隷根性について思うところがある。

それはIT産業の格子にSEの奴隷化を求める仕組みが作り込まれているのではないかと言うこと。ここでは分かりやすく、ユーザー、SIer、メーカー(ベンダー)の３階層で整理する。IT業界の場合メーカーはほとんどアメリカ企業と考えて良い。メーカーは圧倒的な開発力と、コンセプト力でIT市場の動向をコントロールし、自社の製品を導入しないと、時代遅れのITシステムのになると言う不安をあおる。日本のユーザーやSIerにはことコンセプトを覆すだけの青写真を描く力はないため、この流れにただ身を預けるしかない。確かに新しい製品をコンセプト通りに使い、今まで新しい使い方へと変化することによって、効率や価値が産み出せると言うことはあるだろう。しかし、日本の多くのユーザーは業界に遅れないように新しい製品を導入したい。にもかかわらず、今までの使い方はなるべく変えたくない。そんな流れから、自身の現行システムを分析し、期待するメーカーの製品を示唆する形でRFPを作り、複数のSIerからの提案をもらう。提案と言っても、RFPにはざっくり言うと現行踏襲と書かれているだけなので、おなじ使い勝手で最も安いSIerを採用することになる。さて、SIerは過酷の入札を勝ち抜くために限界までダイエットした見積で契約が成立する。契約した時点ですでに赤字と隣り合わせのギリギリの見積となる。そうなるとあとは生き残る術はやる内容をいかに最小限におさえるか。つまり書いていないこと、言われていないことにいかに手をつけないかが生き残る術となる。当然ながら、SE工数の赤字はSIerにとって死を意味する。こうして無事にひとつの奴隷根性のSIerができあが上がった。

他にも

「見積の妥当性を確認するために工数の明細を出せ」→当然ながら、言われた作業だけすれば良いと言う意識付けの効果がある。

「製品不良な相性問に対して当初の計画から変更を許さない」→次からリスクのある目新しいことに消極的になる。かなり具体的に要件をまとめないと着手しないようになる。

「障害発生時に再発防止策を共用する」→言われたルール・対策のみ守れば良いと言う思考になる。

こんな環境で、こんな言葉を浴びなが仕事の経験を積み重ねることで一人前の奴隷SEが成長することになる。

これは死を意味する赤字を回避する為の生存本能とも言える。

結局は相手の見え方と言うのは写し鏡。奴隷のようなSEに不満がもしあるのならば、それは奴隷であることを求めているからなのではないかと感じたと言う話。

プロジェクトマネージメントに真面目に取り組むと組織が疲弊する件

プロジェクト推進の費用の公平性と透明性を確保するためには入札が必要だ。

入札のためにはどよのうなシステムがほしいか明確にし、RFPとして要求事項をまとめあげる必用がある。RFPに対しての回答は、対応項目に×のある提案は論外。やる気なし。RFP記載のとおりに提案したベンダーの中で最も安いベンダーを採用するべきだ。

さて、RFPを参照して入札するベンダーの立場では、お得意様のRFPには必ず回答しなければならない。記載の内容は漏れなくすべて○にしなければならない。費用は最大限切り詰めなけらばならない。さもなければ、やる気の無いベンダーとされ、今後の引き合いの声がかからなくなってしまうかもしれない。そして、見積の不確定要素のリスクを低減するため、できる限りの手弁当である程度の設計を進める方が良い。

そんな努力のかいがあって、ユーザ企業は特注のシステムを割安で手に入れることができるベンダーを決定できた。

そうして、システムの完成に向けてユーザ企業とベンダーでタッグ組んで走り出す準備ができた。しかし、システム開発の契約ができた途端にユーザ企業とベンダーの敵対的関係が始まる。

ユーザ企業は、契約した金額の中で設計が具体化するにつれて明確になってきた新たな具体的な課題の取り込みを要求する。追加要件として、コスト増やスケジュール遅延を認めるわけにはいかない。

一方、ベンダーは契約時に確定した限られたリソースで利益を確保しなければならない。そのため、実施内容は極力最小限にする必要がある。RFPに記載の項目のみにスコープを絞って、プロジェクトの損益悪化を防止しなければ会社がつぶれてしまう。

こんなそれぞれの思いからプロジェクトの完了までユーザ企業とベンダーの言った言わないの敵対関係が続くことになる。

真面目な取り組めば取り組むほど対立は明確になる。

結果として出来上がるのは何でも押し込もうとするユーザとユーザが予め言ったことしかやらない奴隷のようなベンダーの関係性だ。

真面目に仕事に取り組んでいるのに不幸なものだと思う。

そして、奴隷のようなベンダーが作り上げたシステムは必要最小限にしぼった気の効かないシステムとなる。

ユーザ企業は、気の効かないベンダーに動いてもらうのと、気の効かないシステムを扱うのに疲れ果てヘトヘトだ。

ベンダーは、わがままなユーザ企業の要求を実現するための、手弁当の入札対応の設計と、ほとんどの利益の出せない特注品のシステム開発でヘトヘトだ。

結局、ユーザ企業もベンダーも余力はほとんどなく、疲弊する日々を毎日ただ過ごすのみとなる。

では、疲弊しないためにはどうするか。

ユーザ企業は入札結果×の部分を認め、自身で○とする為の体制の確保してまで対応が必用な項目なのか考える。そして値段のみではく、担当者自身が一緒にシステムを作っていきたいと思えるベンダーを採用するべきだ。こうすることで、担当者自身のシステムに対する思いが強くなり、自発的にシステムの改善を検討できるようになると思う。

一方、ベンダーはRFPのやりたくない項目を×のまま回答する勇気をもつこと。自身のソリューションパッケージやSaaSの長所を全面的に押し出した提案とし、×となる項目への対応は顧客自身で考えてもらう。REP通りの特注品の開発をやめることで、ユーザ企業と体力の削りあいをやめるべきだ。特注品は一見売り上げは大きいように見えるかもしれないが、案件を通して組織内部に残る価値はあまりなく、ただ主担当のメンバーが疲弊するだけだ。特注品作るリソースで、しっかり得意なものを強化し、実績を増やすことに注力するべきだ。そうすることで自身のサービスをしっかり成長させられると思う。自身のサービスの強化と思えば、少しは気の効いたシステムを作る気になるのではないかと思う。

では、自身のサービスには強みがなく、特注品を作るしか無い場合はどうするか。それは、RFPの回答(請け負いの案件)ではなく、単に技術者の派遣の提案にすれば良いのではないかと思う。ただベンダ側のメリットは少ないのでは無いかとも思う。名ばかり請け負いが行き着く先は結局は双方の疲弊だと思う。