今回は自分の業務を語る回です。
日系のそこそこ大きなのSIer会社のSEとして働き始めて丁度一年くらいの若輩者なのですが、説明資料作成業務が割合としてかなり多い状況ですので、その話をしたいと思います。
(ここでいう「説明資料」というのは、パートナー企業やお客さん、社内上層部等と打ち合わせするときに使う説明用のパワポのことを想定しており、設計書は一旦置いています。)
SIというものは往々にしてかなりプロジェクトの人数が多く、業務内容は多岐に渡ります。私が配属された部署・上司の結果こうなっているという話なので、私の状況はあくまで一例として聞いていただければと思います。
そもそもSIerのSEは何をしてるのか？実際どんな説明資料を作っているのか？
というような実態をお話ししたあとに個人的に問題だと思うことを挙げていきます。
一次請けのSEの役割は合意形成・調整
SIerのSEの業務は調整、ドキュメントを書くことしかしない
「システムエンジニア」と聞くとエンジニアっぽいですが(？)、SIerの場合は、大きなお客さんから仕事を受注している一次請け(＝プライムベンダー)は調整業務がほとんどになります。つまり、技術的な要素は少ないです。
お客さんや社内上層部、パートナー企業との調整やドキュメントのレビューこそ行うものの、詳細な仕様検討や開発(プログラミング)はパートナー企業に丸投げします。
彼らが週40時間(＋α)を何に使っているかというと、開発をしてもらっているパートナー企業の進捗管理やステイクホルダーとの調整の打ち合わせの割合が多く、それ以外は打ち合わせに向けたドキュメント作成ということがほとんどです。
SEの詳しい仕事内容は以下の記事にも書いています。
受注・設計・開発・テスト・リリースなどの各プロセスで何をしているか、誰とどのような調整をしているか、役割分担などについて詳しく記載しています。
日系企業ならではの合意形成プロセスがある
ある日見つけたこちらの記事は、私の会社ではないですが、日系SIerというところで似通っているところがあり、「わかる～～～」と共感しましたのでシェアさせていただきます。
共通点(1)で、プロセスが煩雑と書きました。日立はそれに加えて、それぞれのプロセスで作成するドキュメントの種類や名称、チェックリスト等のフォーマットが事細かく決まっており、それに沿ってドキュメントを作成する必要があり非常にドキュメント作成負荷が高いです。また、チーム内においても細かくマネージャーと作業者が存在することが多く、マネージャーが管理や意思決定、作業者は資料作成というように多くの関係者がいます。非常にプロセスや品質を重視している企業だと思います。残業についても、日立の方が多かった印象です。
私の会社もここまでではないかもしれませんが、プロジェクトのプロセスが重視されている印象が強いです。「多くの関係者がいる」というところで資料作成業務が多くなっていると私も感じているので、今までどういうことに関して説明資料を作ってきたかを掘り下げてみると、以下のようになりました。
これまでに作ってきた調整のための説明資料の種類
- 顧客への提案資料、状況報告資料、その他打ち合わせ資料
- 見込み利益やリスクを見積もり、プロジェクトを進めて問題無さそうかを決める社内上層部の意思決定会議向けの資料(この会議はプロジェクトを始める前に複数回存在します…。)
- プロジェクトが炎上した時に上層部の意思決定会議の決裁者やその上に状況を説明するための資料
- パートナー会社が多く、1つのプロジェクトで複数の会社と契約することが少なくないため、どういう作業を依頼したいかを各パートナー会社の管理側に説明する資料
- プロジェクトに入ってもらったパートナー会社の作業者に、依頼したい作業はどのようなものかや、納品物として何を期待しているのかを説明する打ち合わせ資料
- 社内の他部署と連携するときに、プロジェクトの概要や依頼事項をまとめた打ち合わせ資料
もちろん使いまわせるものも多いですが、それぞれかなりの品質が求められます。
これらはパートナー会社の方に任せるわけにもいかないものですし、設計や開発などの外注できる部分は外注した結果、残ったのはこのような資料作成業務、と言っても過言ではありません。
私の場合は下っ端な上にチームメンバーがかなり少なかったことから、これらの資料の草案作りが次から次へと降りかかってきました。上司に草案を出し、指摘されて修正を繰り返す日々。
個人的に課題に感じているポイント
説明資料の作成が苦痛で苦痛でたまらないというわけではないのですが、それでもこの説明資料作成という仕事の割合が多いと「パワポばっかり作ってて一体全体大丈夫なんかな…」と不安に駆られるので、自分が問題だと思っているポイントを挙げていきます。
自分が使う資料とは限らない
自分が打ち合わせで使う資料なら、分かりやすい構成はどのようなものか、何に注意しなければならないか、何を一番に伝えたいかなど考える余地があり、結果的にプレゼン能力の向上が見込めます。コミュニケーションめっちゃ苦手なので欲しい能力の一つです。
ただし、私が作っている資料の中には私が説明するものではなく、上司が社内上層部や顧客に説明するために使う資料があります。割合にして半分弱くらいでしょうか。
これだと構成や内容についてざっくりと私が考えることもありますが、最終的に上司にお伺いを立てる形になります。この場合、話すときのことを考えて自分で細部を考えることをしないので人に何かを伝える能力があまり上がらないと考えています。
上達するのはパワポの図をそれっぽく書く能力と、何かを言ってるっぽく見えるようにこれまでの資料から文章を抜き出してくる能力くらいのものです。
ITに関する知見が得られない
パワポを作る際にはあまりITの知識は問われなかったです。
設計・開発フェーズの顧客レビューなどはそもそもパワポではなくここで扱っていない設計書を使ってやりますし、各ステイクホルダーと合意形成を図るためのパワポについては、プロジェクトの概要や今の課題などふわっとしたことしか書かないことが多いためです。
細かいシステムの仕様や要件をクリアするために何をすべきか等を検討するのがSEのイメージな気がしますが、そことは関わりが薄くなってしまいました。(これは単にプロジェクト内で私がそういう仕事をあまり割り振られていないだけな気もしています。設計・開発フェーズ担当ではないですしね。)
新入りのうちに細かいシステムがどうなっているのかがあまり学べていないので、このままで大丈夫かな…という漠然とした不安があります。
市場価値が上がらない
説明資料を作るのが早くなったり上手くなったりしても、もっと言うと説明や社内調整が上手くなったとしても、市場価値って特に上がらないのですよね。
業務経歴に完璧な資料を作成したって書くわけにもいかないし。
打ち合わせを円滑に進める能力等の「ソフトスキル」的な側面はどこへ行ってもある程度は必要になるかと思いますが、他の成果やスキルがあってこそだと感じています。
(大企業の社内調整はその会社でしか通用しないものも多いので、ここも注意が必要です)
話はずれますが、最近「ソフトスキル」という言葉を知って以下の本を手に入れました。(積ん読の末尾に追加したので)もう少ししたら読んでみます。また、「ソフトスキル」の一般論についてはまた別で記事を書こうと思っています。
そもそも説明資料を作る必要があるのか？という疑問
学びがないわけではないのですが、ここまでの品質の資料を毎回作る必要があるのか…？と思っています。顧客相手や社内上層部への説明ならともかく、チーム内部での打ち合わせや他部署との連携の社内打ち合わせ資料にも結構な品質の説明資料を作っているので、工数が掛かっていて負担が大きいです。
検討してる構成のパターンの図は詳細なものではないんだからわざわざパワポに起こさなくても打ち合わせ中にホワイトボードに書けばええやん…とか、ネットでそれっぽい情報出てくるのあるよ、そのページ見せながら説明すればええやん…とか今でも正直思っています。
新人なのでまずはちゃんと資料を作って説明しろという上司の意図が多少は含まれている気がしますが、他に時間を割いた方が良いような気がしています。例えば、設計書を見て細かい仕様を理解するとか…。
まとめ
最後までお読みいただきありがとうございました。
完全に個人の状況の共有という感じですが、元々開発の技術部隊に配属されて期間限定で部署を変わったらずっとこんな感じなのでうーん、どうしよ…って感じですね。
記事の中でも書きましたが、SIerのSEの仕事内容は以下の記事で詳しく紹介しています。
また、こんな(開発はパートナー企業に丸投げ、自分たちは調整や見積もりが仕事となっている)状態のSIerに一体どういう価値があるのか、自分なりに考えたことを下の記事にまとめています。
この記事と同じように、個人的な仕事の状況を書いている回は以下の3つになります。
個人の体験に留めて、比較的主観中心で書いている文章ですが、SEの内情を知るのには良いかなと思っています。世の中に広くいるSEの勤務実態の一例としてご覧ください。
- コロナウイルスによって発注側が休んで、客先常駐のSEだけ出なくてはいけなくなった話
- 新人にはテレワークが辛い話
- ジョブローテーションに新人みんなのモチベが下がってまずい話
コメント