はてなキーワード: プロマネとは
https://anond.hatelabo.jp/20221225142418
の続きです。これまでは幸運も手伝ってか合格を続けることができましたが、ついに落ちてしまいました。午前I免除、午前II88、午後I84、午後IIDでした。最初にお断りすると、事務屋が高度試験の論文分野を受験するに当たっての参考としては、topisyuさんのプロマネ合格体験記の方が本駄文よりよほどお役立ちかと思いますので、ぜひぜひお読みください。こちらは、こうすれば失敗するぞ、という反面教師にしていただければ。
1 準備
いわゆる経営学系の問題が多いのがITストラテジスト試験なので、高度試験の中ではもっともわたくしの本職が活かせる試験であるわけです。実際、午前II、午後Iは去年の過去問を眺めただけで楽勝だろうと察しがつき、午前IIはこれまででもっとも少ない4年分の過去問をプリントアウトして解き、間違えた問題のみ何度か解き直しておしまい。午後Iに至っては、過去問を解くこともしなければ、参考書を読むこともしませんでした。
準備のほとんどすべては、午後II対策に費やしました。用意したのは、翔泳社の『情報処理教科書』のITストラテジスト2022~23年版と、アイテックの『ITストラテジスト 合格論文の書き方・事例集(第5版)』の2つ。最近はDX関連が必ず出ていて、自分の本業でもそれっぽい経験(ただし、非システム側からのもの)があったことから、その経験をシステム側に寄せて論文を書きました。本番までの間、それを実際に手書きもしましたし、何度も読み返して(たまには音読もして)、準備万端だ、と思っていたわけです。
あと、この手の体験記で明示的に触れられることが少ないのですが、論文で取り上げるシステムについてのアンケートがあります。規模等についてのものですが、このぐらいのシステムならこの程度、という感覚がわたくしには一切ないので、これについてもきちんと調べて書くべき内容を整えておいたわけです。
2 本番
午前II、午後Iは順調に終わり、いよいよ午後IIとなったわけですが、開始とともに冊子をめくって愕然としました。DX関連の問題がない! 問題の選択からして、どれを選んでも書ける気がしませんでしたが、相対的に絶望度がもっとも小さそうな大問1、システム改修を選びました。昔いっちょ噛みした複数部門で使っている業務システムの改修事例(ただし、自分の所属部門ではそれを使っていなかった)を必死で思い出しながら、設問で問われている事項は形式的にはすべて対応する記述を盛り込み、字数制限も満たして何とか書き上げることができました。
しかし、書いた内容というのが、結局は(1)ユーザ部門と緊密にコミュニケートしました、(2)使用頻度の低い機能を廃止してコストを削減しました、の2つしかなかったのがD判定につながったのだろうな、と自己分析しています。こんなことを話し合いましたとか、こんな機能を廃止しました、といった具体例などをあれこれ書いて字数を稼ぎましたが、水増し以外の何物でもなかったわけですし。事前に作った論文が改修ものだったらある程度転用もできたのですが、まったくの新規プロジェクトだったのでそれも叶わず。適当な旧システムをでっちあげて改修ネタにすればよかったかな、と後からは思うものの、その場では頭が真っ白になり、そんなことを考える余裕はなかったですね。アンケートも適当に書きましたが、規模の見当もなく、論文の内容ともさぞかし齟齬があったことでしょう。
3 今後
とりあえず秋は監査を受けようと考えています。来年の春には再チャレンジを考えていますが、シラバスが変わっちゃうんですよねえ。論文の大問のひとつが組込みで固定されることになるので、それ以外の出題内容は振れ幅が大きくなってヤマをかけるリスクは大きくなってしまいますし。いっそのこと技術的な話を詰め込んで組込みで勝負する? それなら秋にエンベデッドシステムスペシャリストを受ける? もう少しゆっくり考えてみます。。。今回受かるつもりでシラバス変更をちゃんと読んでませんでした。組込みがエンベデッドスペシャリストに集約されて、ITストラテジストでは出なくなるんですね。やっぱり秋はシステム監査技術者受験で。
俺がシステム屋として見てきた限りでは、デザイン屋とシステム屋が別々で
UI/UX何それおいしいの、というシステムが量産されているように思う。
システム屋はプロジェクト初期、まだデータ構造やアプリのユースケースの詰めが甘い段階でデザイン屋に依頼する。
プロジェクトが進むと、システム屋は開発中の様々な問題に対応するために、もうデザインどころではなくなる。
デザインを修正するとしても、ビジネスロジックの深い所にも影響が出る実装を〝やらかして〟しまっており、デザイン修正に対しては激しい倦怠感・嫌悪感。
プロマネは「動くアプリが納期までに完成するか」を祈る事しかできない。トラブル続きで、UXに気を配る心の余裕などない。
昔(6年くらい前)SESに九ヶ月ほど勤めていた。
案件単価は未経験エンジニアで70万くらいだったらしい。増田の基本給は総支給で19万だった。ゴミかよ
なんでそんな会社に入ったかというと、悪質な弱小エージェントにホイホイ騙されたからである。要は若気の至り。若さゆえの過ち。
それで尚且つ入場先が不夜城と名高いメーカー系のど炎上プロジェクトで毎晩10:30までテストをしていた。帰宅はなんとプロマネがチャットで「今日はそろそろ上がってください」と全体に流すまで帰れないのだ。
ただ、この炎上プロジェクトは期間限定の入場で5ヶ月と聞いていたので我慢していた。しかし話が知らないうちに変わったようで結局9ヶ月になった。こちらには一切告知がない。ていうか増田の入場を仕切った担当営業、知らないうちに辞めてた。定期面談もなかったし、質問にも答えてくれなかった。あの人今何してんだろ。
しかもその後の入場先は片道2時間の現場だと言われた。事前面談で経歴詐称をしてくれと指示を出された。無理だ、通えない。死ぬ。満員電車に揺られて、週5で往復4時間。できるとは思えない。経歴詐称を簡単に指示を出すが、それで現場に入って辛い思いをするのは技術者だけだ。いつの間に変わっていた担当営業にそう訴えたところ、甘い、一人暮らししろ(家賃補助月15,000円)と言われた。増田は色々あり実家から出る選択肢はとれない。社宅制度(レオパ)は女性は住まわせられないとか言ってた。退職することにした。引き止められた。こんな会社本当に潰れて欲しいなと思った。
なんでこんなことを思い出したかというと、久しぶりにその会社をググったら口コミに色んな辞めた人たちが「営業がクソ」「給料がクソ」「対応に誠意がない」「経歴詐称をしろと言われた」と所狭しと書かれていた。事実とはいえ、普通の会社ってGoogleの口コミに悪口書かれるもんなのだろうか。
そして月日が経ち、増田は今の職場で技術派遣の常駐さんに指示を出すことも増えた。彼らも基本単価70〜80万くらいで来てもらっている。たまに自社用と言っても月に2回ほど外出したり、担当営業と面談(ランチ)をしたりしているようだ。大切にされている。中にはクリスマスプレゼントを自社からもらっている人もいた。
この姿を見ていると、増田がいた会社が特別クソだったのか?と思う。でもSESは滅んだ方がいい文化だと思う、マジで。若い人の労働力搾取だよ…
非常に集中力を使う厳密さが必要な作業に関して実行役と、同じ作業を俯瞰して全体を見渡したり逆に本筋以外の細部をチェックする役のペアだから、あまり家事に置き換えられない。
しいて言うなら二人とも作ったことのない新しいレシピに取り組むとき、一人が調理を担当して、もう一人がレシピ本を見ながら次の手順を示したり、料理酒とみりんを間違えていないかチェックするような役割分担だ。
うまくやればノウハウの伝授という副作用もあったりするがそれは本質ではなく、スキル差はない方が望ましい。
大体モラハラ気質のベテランプログラマーと低スキルの新人プログラマーのペアプロが成立するわけないだろ。いや新人プログラマーというよりベテラン営業マンに繁忙期だからとプログラム書かせるようなもんか。
宇宙関係の人間の本音としては、正直なところ故障解析手法や大規模プロジェクトマネージメント手法は何十年も前から宇宙開発業界が牽引してきた自負があるので、素人ごときが「失敗と認めないと前に進めない」とか言っても誰に何をほざいてるんだとしか思えないし、言われなくてもお前が想像してるよりもずっと緻密な分析と改善をやるし、それは打ち上げの中止とか成功とか関係なくどんなフェーズでも息をするように日々やってるわ、という感じ。
補足すると、故障解析やプロマネは米国を中心に宇宙業界で研究・実践され、それは国際プロジェクトで各国の宇宙開発機関で共有され、またそのノウハウは後から他業界へ広まっていったという経緯がある。
追記しました。あとイプシロン8号機はイプシロン6号機の間違いです、ご指摘感謝します。H-Ⅱ 5,8号機が連続で失敗したときのNASDAバッシングの話を書くか悩んだ関係で混同しました。
失敗と表現した人を責めないであげて欲しい。宇宙輸送機の失敗に関する慣習的な定義については色々な人がもう意見を述べているのでそれを読んで貰えれば良いと思うが、それは業界の慣習というか方言なので、村の外から来た人が『機体の異常で予定した打ち上げのタイミングで上げられなかったなら失敗なのでは?』と思うのは仕方がない部分もあると思います(それでも失敗の軽重で言えば、輸送機の失敗としてはかなり軽寄りということは分かるような記事であればうれしいですが)。
最初に共同通信が失敗と報じた際、多くの宇宙ファンが共同通信の表現を叩いていたのをみました。近年ではイプシロン8号機などの宇宙開発の明確な失敗にもあたたかいコメントが寄せられる事が多く、またJAXAやメーカに対して厳しい論調を向ける人への批判もよくみます。批判自体は表現の自由の範疇であり行き過ぎない限りはありがたいのですが、失敗と報じたことのみを以て叩くのは行きすぎだったと思います。もちろんあの事象は中断と報じるのが習慣から言って適当だと思いますが、そういった習慣を記者に押しつけ、あまつさえ工学の素養が無いと馬鹿にする態度は業界に対して閉鎖的な印象をうみ、長い目で見たときにプラスには働かないのではないかと思います。もちろん記者会見でのあの態度は一社会人として許されるものではないですが、宇宙ファンが失敗という表現を叩いたことがあの態度を誘発した部分も無いわけではないと思います。
宇宙業界はまだまだ発展の可能性を秘めた分野であり、JAXAだけではなくメーカや宇宙ベンチャーなど多くの人が宇宙を身近に感じて貰い、より多くの人に関心を持って貰おうと頑張っています。宇宙ファンはもとより、今回の打ち上げが失敗だと思った人たちもこれを機に宇宙開発に興味をもって欲しいと思っています。また次こそはH3の打ち上げが成功するように、昼夜を問わずに働いているロケット屋さん達を応援していただけるとありがたいです。
『成功』と『失敗』は結果でしかなく、問題があったのに成功することもあれば問題がなかったのに失敗することもあります(※)。よって定義として失敗に当たらないとしても今回発生した問題は関係者間で重く受け止められていると思います。また決められたスロットの中で打ち上げればよいという話も『衛星を軌道に投入する』という点だけを見れば嘘ではないのですが、射点の数が少ない日本では一つの打ち上げが延期すると連動して他の打ち上げも遅れ宇宙開発計画全体が遅延することにもなり得ます。また海外顧客の獲得という点でみれば決められた日時に上げられるというのは大きなメリットになります。更にコスト面でも打ち上げが一日延期すると莫大な費用がかかると言われています。また搭載されているALOS-3の前号機であるALOS-2は既に設計寿命を越えており、空白期間を防ぐためにも早くサービスインしたほうが良いのではないかと思います。
とは言え今回のH3は試験機かつ衛星を載せているため安全性がより重視され、L/O前に止められてよかったという結論には変わりがありません。しかし上記のような点を無視して『全く問題がない、最終的に軌道投入できれば良いんだから問題があるというやつはわかっていない』というような言い分が広まることは岡田プロマネが「ロケットの打ち上げ中止自体は非常に大きなこととして受け止めている」と回答したことや事態の収拾にあたっている人達の努力を無にしてしまい、ブコメにもあるように「JAXAは失敗を認めずに意固地になっている」と言った印象をあたえるのでは無いかと思い今回の増田を書きました。
※後者はイメージしづらいかも知れませんが、高信頼な部品を使って冗長化しても偶発的故障の影響を0にすることはできず、最終的には確率の世界になります。またソフトウェアのバグも0であることを保証することはできません。よって万全を尽くしたけれどもどうしようもなく運が悪くて失敗する、ということも理屈の上ではありえます。まあその場合でも信頼性計算のプロセスを疑われることがほとんどとは思いますが。
これは意見が分かれるところだと思います。私も以前は少し調べればわかるようなことを聞く記者に対して、ちゃんと勉強してこいと思っていました。一方で一部の科学系雑誌などを除いて記事を読む人のほとんどは宇宙に興味がない人なわけですから、そういった人たちに情報を伝える役割としてはあえてその分野については素人な記者が質問して記事を書くというのも一定の意味があるのでは無いかと最近は思っています。今回の例をとっても『失敗』と書かないと一般の人に正しく伝わらないと先入観のない記者が考えたのであれば、必ずしも公式発表と同じ表現である必要もないのではないかと思います。ただ公式発表と違う表現をあえて使うならば業界の背景について専門的な記者が補足を入れ、発言者の意図が正しく伝わるような工夫をコミュニケーションの専門家として求めたいという気持ちは少なからずあります。記者の態度については既に述べたので書きません。
https://www.youtube.com/watch?v=CZRB4MdJSuw
KYODO:中止と失敗について確認したい。意図的に止める事を中止と言います。
飛ぶはずのものが飛ばなかったように見えるのですが、正体不明の異常が起きてシステムが正常に作動して止まったかもしれないが
意図しない出来事で止まったことは一般的にいう失敗ではないですか?
こういった事象がロケットにはありますが自分たちでこれを失敗といったことはないです。我々が非常識かもしれませんが。
KYODO:これを失敗だと言われても著しく不具合はないですか。
JAXA:どのような解釈をされるのかは受け止める方になるので、そうでないですとは言い難いが、
設計の範囲の中で止まっているものは「中止」としている。ある種想定している中の話なのでそこに照らし合わせると「失敗とはいいがたい」です
色んな思いが岡田プロマネにこみ上げたからだと思うが、最初の質問のところでちょっと感極まってらっしゃいましたが、
私もその時に失敗なのかと受け止めたんですが、中継を見ている人も同じように失敗と受け止めた人もたくさんいらっしゃるように思います。
失敗ではないという事ですか?
JAXA:
(感極まったことに対して)失敗したらこんな気持ちにはならないと思いますが・・・。
えーとですね。
ミッションに待って頂いた人が近くにもいまして、人工衛星の当初から一緒にやってくれている人に残念な思いさせてしまったのが一つと
(言葉選びながら)ちょっと個人的な事になりますが、個人的じゃないかな。
ええと。天気の関係でこの2日間、延期させていただいたときに種子島宇宙センターには多くの応援していただいている人が残ってくれてまして。
(もう一度、感極まる)そういう・・あの・・、お子さんもいらっしゃいまして、「ごめんね」という気持ちですかね。これは・・。すみません。
ほいノ
高専行こうと思えば行けたんだけど、実家離れるの怖くて偏差値45の工業高校へ。
18歳までフリーター。
18歳〜21歳まで定時制に通った。
英語は個人的にそこそこ勉強したけど、数学なんかはⅠの後のAが半分も終わらなかったレベルのバカ校。
この時期は暇で、なぜかやる気に満ち溢れてたから、TOEIC700近くとか日商簿記2級とか色々資格を取った。
24歳でうつになって、30歳くらいまで日雇い・派遣↔無職を半々くらいでリピートしてた。
やってる仕事は大したことなかったけど、幸い仕事中にPCをめちゃくちゃ使うのでやりたい放題だった。
この時にプログラミングを始めた。
ここで年収どんどん上がった。
36歳でうつが再発して辞めて今に至る。
基本は、仕事で使えそうなもの・必要なものをその都度吸収していった感じ。
Webが中心ではあるけど、組み込みとかのハードが絡む分野以外は結果的に広く浅く手を出してる、つもり。
Excel VBA | 1年 |
VB.NET | 半年 |
JavaScript(Node.js) | 4年 |
HTML | 1年 |
SQL | 4年 |
GAS | 3年 |
C# | 1年半 |
TypeScript | 2年 |
Java | 半年 |
C++ | 半年 |
ラダー、FB(三菱、シーメンス) | 1年 |
実務経験があるって胸張って言えるのはこれくらい。
大体習得順。
他には、Python、Julia、R、Fortran、Rust、Go、Dart、Shell、Deno、CSSなんかは少しずつかじってる。
最近はWebに関してはほとんどJS(TS)で済む感じになったので楽。
なんでPLCが最後やねんってツッコミは置いといて、Web系寄りでラダーも触ってるって人は観測範囲ではあんまりいないので、それが俺の数少ない強み。
RDBはPostgreSQL、SQL Server、MySQL、SQLiteの順で実務経験あり。
NoSQLはFirestoreが実務経験あり、実務なしだとNeo4jとか。
PaaSはGCP(Firebase)、AWSの順で実務経験あり。AzureはADとVM周りをちょっと触った程度。
Dockerはよく使うけどKubernetesとかまでは行ってない。
後は産業用の通信プロトコル的なやつを無駄に色々触ってる。Modbus TCPとかORiNとかCC-Linkとか。PLCもそうだけど、あの辺は日本とドイツとアメリカが未だに既得権益で幅利かせててまじで闇深い。その代わりそれをブレイクスルーできればめっちゃ稼げる分野だと思う。
閑話休題。
フリーターでどんな仕事してるか知らないけど、仕事で一日の半分が無くなっちゃうじゃん?
以下、俺の場合ね。
次長クラスの人が「この製造番号でクレームがあったんだけど、作業当時どんなことあったか覚えてない?」みたいなことをわざわざ現場まで何度も聞きに来るんだよ。
作業したのなんて半年前だったりするから一々覚えてないっすよ、って言ってるのに何度も聞きに来るから、イラッとして仕事用のPCで勝手にExcelで業務日報を付けるようにして、イントラのファイルサーバーに置いて「そういう時はこれ見て下さい。次長の貴重な時間が勿体ないです」って言ったのよ。
それだけでめちゃくちゃ喜ばれる。
で、今度はその次長が「この製造番号どれくらいの時間で作業終わった?」みたいなことを現場までわざわざ何度も聞きに来るから、俺はその時またイラッとして、Excelでストップウォッチもどき作って製造番号とか工程ごとに時間計測して記録して、やっぱりファイルサーバーに置いて「これ見て下さい」って言ったのよ。
それでまた、めちゃくちゃ喜ばれる。
最初はプライベートな時間も結構使ってやってたんだけど、そういう周りに喜ばれる効率化を繰り返してると、少しずつ業務時間内で自分のスキルアップに直結する時間を作れるようになる。
自分でこれ面倒くせーな、効率よくできねえかなって思ったら、じゃあどうやって?てのを考える。
ちなみにPCがなくても、たとえばメールアドレスさえあれば今の時代カイゼンはできる。
大きな会社に勤めてるとかだと使うのが難しいんだけど、IFTTTとかが良い例かな。
これはiPaaSっていうサービスの一種で、まあ言葉の意味は覚えなくて良いんだけど、要は「イベントAが発生したら別のイベントBを起こせ」っていうのを登録して、自動化できるWebサービス。
例えば、あなたが日雇いの会社にいて、毎日違う現場に働きに行くとする。
で、出勤前、現場到着時、勤務終了の時にLINEで毎日報告しなきゃいけないとする。
で、その報告を受けた事務方は、Googleスプレッドシートにその都度入力する。つまり、それだけの為の事務員が一人いる。
面倒くさいし、お金がかかる。
そこで、「特定のグループでLINEを受信したら(イベントA)、特定のGoogleスプレッドシートに情報を記録せよ(イベントB)」っていうのをIFTTTに登録すると、少なくとも事務員の入力の手間は省けるってえ寸法だ。
IFTTTはたくさんイベントを処理させたい場合は有料になっちゃうけど、個人で試すぶんにはクレカ登録しなきゃいいだけだから試してみるといいよ。
月1000円で学べる。コスパは圧倒的。
入門コース(学習に180時間と公称してる)がしっかり理解できていれば、Webで大抵のものは作れる。
ただし、大筋は問題ないんだけど、細かい部分で最新技術をキャッチアップできてない可能性があるので、そこは注意した方が良いかも。
https://www.nnn.ed.nico/pages/programming/
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。
そしたら、職歴書の作り方次第で中小企業の社内SEにはまず転職できる。
中小企業の社内SEは、ITリテラシーの低い社員が多い中で「Excelのセルの色が変わらなくなっちゃったんだけど!」とか「複合機が紙詰まりって言ってるけどその紙が見つからない!」とかクソイージーなクエストをこなすだけでおちんぎんが貰える、人によっては天国、人によっては地獄のような職業だ。
ごめん、流石に言い過ぎた。実情は色々と面倒くさい。DXとかバズワードを聞きかじったクソ重役から突然言い渡される重めのミッションとか。
けど安定なのは間違いない。
N予備校の入門コース終わらせたら、基本情報技術者か応用情報技術者を取る。ここは社内SEと同じ。
生産技術ってのは、誤解を恐れずにすげえ簡単に言えば、カイゼンばっかりやってる人たちのことだ。
あんまり詳しくは言えないんだけど、俺が最後にやっていた仕事は言わば生産技術だった。
で、中小企業の生産技術は、Webに強い人材をかなり欲しがっている。有り体に言うとIoTとかね。
IoTは最近、セキュリティの強化がかなりクローズアップされていて、そのせいで二の足を踏んでる企業が多い。
そこに滑り込むのはアリだと思う。
よく「T型人材」って言われ方をするけど、どっちのスペシャリストの言うこともある程度分かる「橋渡し」的な人材になると途端に貴重になって需要が増すので、上昇志向があるなら「Web+何か」の組み合わせでお金稼ぐのが良いんじゃないかな。
ま、橋渡しって自然とプロマネとか任されがちで、裁量大きくて大変なんだけどね。
質問あればどうぞ。頑張って。
ほんとその通りだな、と思う
てか、うちのプロダクトマネージャーがお客様は絶対!みたいな感じで要求全部織り込むやで!みたいな姿勢なんだけど、
このプロダクトは基幹システム的な役割もあるから正直全お客様の要求そっくりそのまま織り込めるわけないのよね
本当はそんな中でプロマネに「誰を不幸にするか?」(折り合いをつけるか)を責任持って判断して欲しいのに、叩かれることを恐れてるのか「みんな幸せにするぞ!」としか言わないのよね…
まぁ、初めはそれでいいかもしれないけど、もう締切も見えてるのにまだそんなこと言ってるから要件出せないし、そんな中全部のせで見積もったらコスト高すぎと叩かれるしでもうグチャグチャ
テスラやスペースXの仕事の仕方は最低限のジョブ(プロマネか開発者かくらい)しか決まっておらず多能工化が進んでおり、各人がやる仕事は日々更新されるジャスティスボードという各開発の内容や進捗が書かれたボードを見ながら各人が決めていく
そのボードでは自動運転みたいな部品レベルからモデル3のインテグなど車両レベル、さらには車の中で絶縁テープを貼るロボットの開発といった製造レベルまでレイヤが全く違う開発項目が並ぶ
ある日は自動運転のシステム開発をして、その次の日はサイバートラックのシステムインテグをすることもある
そして、実務では開発ごとにモブという5人くらいのチームが形成される
ある日は開発者として手を汚すこともあれば、推進者としてチームを管理することもあるし、テストなど品質管理を担当することもある
もちろん車(範囲広い)のソフトウェア開発をする、くらいのジョブはあると思うが
参考
https://logmi.jp/tech/articles/327164
そもそもジョブ型雇用として細かく役割が決まっているのは非効率であり、日々変わる開発状況やプロダクトの価値に合わせてチームを組み、ちゃっちゃとアウトプットを出していくべきだってイーロンマスクは考えているんだと思う
そろそろジョブ型雇用もテスラ、スペースXみたいな化け物企業が出てきたことで"遅い雇用形態"と見做されるようになり見直しが入って行くと思う