ふとした気づきをつらつら。
エンジニアの取り組み(=技術記事)を発信できない慣例……
大手SIerのウォーターフォール案件でおこなわれている取り組みは、インターネットの記事を検索しても、抽象的な話しか出てこないのですよね。
現場レベルの情報は多重業務委託の結果、かつての私のような名もない協力企業の人が手を動かしているので、「秘密保持」の対象とみなされます。
したがって、どうしても「このプロジェクトでは、こういう考えで/こういう過去の出来事があって、こんなことをしています」というエンジニア目線の情報は発信されづらい。
→→→ お客さん目線で考えれば、国や金融機関のシステムともなれば、自由な情報公開=リスクであるので、情報公開に踏み切るのは難しいところ。そもそも、いただいている工数は発信活動のためのものではない、ということも気になる。
エンジニア目線では技術情報発信に厳しい現場だなあと思います。
私はそうではなかったですが、大手SIerのウォーターフォール案件で働きながら、社内発信を中心に強くなっていく方もいらっしゃいます。100%業務とは関係ない個人活動を発信する方もいらっしゃいました。いずれも「体力」「バイタリティ」に自信がある方に向いている活動方針だと感じられました。
私は体力に自信がなかったので(現場にいた頃の認識では、 世の平均値<私<<<<<体力すごい人 だと思っていた。)、業務内容に基づく技術発信ができる職場に転職しなければ、発信する経験は積めそうにないなあ、と思っていました。
(これを書いている現在は既に転職しており、業務の一環として技術発信が推奨されているベンチャーに入社したことで、執筆の機会が増えました。)
IPAのWebサイトで閲覧できる情報 → 現場エンジニアが普段考えていることとはちょっと違う
◆IPAのアーカイブ>書籍・刊行物 リスト
・https://www.ipa.go.jp/archive/publish/index.html
PDFが公開されています。
だいぶ抽象的で、研究発表のような内容です。
現場レベルの話ではなくコンサル向きの情報ですね。
◆2011/07/22「ソフトウェア開発の標準プロセス」(財団法人計算科学振興財団 ソフトウェア・エンジニアリングセミナー)
・https://www.ipa.go.jp/archive/files/000004771.pdf
この登壇資料はわかりやすかったです。