  |
はてなキーワード: 命名規則とは
2021年5月5日、MicrosoftのC# のコーディング規則 (C# プログラミング ガイド)に今まで明言されていなかったprivateなメンバ変数(field変数)への命名規則が記載された。
ちなみに同じMircrosoftが出してるStylecopやFxCopといった静的コード分析ツールの現在の仕様は「アンダーバーは付けるな」で、
おそらく.Netだけがアンダーバーを付けていたが、今後はそういったツールも.Netに合わせる流れになっていくと思われる。
private または internal フィールドに名前を付ける場合は、Camel 形式 ("camelCasing") を使用する必要があり、_ プレフィックスを付ける必要があります。
マニュアル人間のように、マニュアル、ドキュメント化、文章化を悪とする風潮が日本にはあるように思う
これが良くないのではないだろうか
いや、Zガンダムでもいい
ガンダムのマニュアルがなかったらアムロはガンダムを大地に立たせることができなかったのではないだろうか
もちろん、武器をマニュアルから見つける時間はなく、偶然押したボタンで頭部のバルカンが出た
しかし、マニュアルがなかったら心細かったであろうし、諦めてしまっていたかもしれない
形だけであれ、まずマニュアル、ドキュメントが存在するというのは心強いのである
ドキュメントがない、issuesに知見が溜まっていない、Stackoverflowで話題にさえならない
そんなソフトウェアはどんなに優れていても使っていて行き詰まってしまったら投げ出しやすくなるだろう
ソースコードが公開されていても、ドキュメントがないのでトラブルのたびにコードを読む、これはとても苦痛だ
命名規則が無茶苦茶なソースコードがあったらプロでさえ投げ出したくなるだろう
コメントから自動生成だけでなく、チュートリアル、Getting Started、Installation、バカでも一通り学べる文章が必要だ
そうでなければそのソフトウェアは流行する可能性はまったくないだろう
インハウスツールであったとしても投げられてしまい、ちゃんとドキュメントや管理できる別の社員が作り変えるかもしれない
つまり、恋愛も同じであり、マニュアル、ドキュメントが寧ろ必要なのではないだろうか
そこには概要やインストールから始まるように、まず最初の一歩はどうすればいいのか、がちゃんと書かれている
そして、恋愛の一通りの機能を学べるようにチュートリアルが用意されている
Zガンダムのカミーユだって父親のコンピュータから操作方法のマニュアル、ドキュメントを盗んでいたと劇中で述べている
ブライト・ノアは才能だと言っているが、自分はそれは少し違うと思うのだ
カミーユに至っては母親も材料物性のスペシャリストである、つまり金属などの分野である
ドキュメントを書く、文章を書くというのは技術をまとめる、開発したものの操作方法をユーザーに伝える、大切なものである
それが将棋や囲碁であれ、あやとりであれ、必ずその分野のプロがいるのである
しかし、恋愛のプロが書いた本があったとしても、碌なものがない印象がある、なぜだろうか？
まず、恋愛のプロである筆者が自己を正しく分析できていないことがある
つまり、なんだかよく分からないがモテる、みたいな人は自分が自分でどう優れているのかさえ理解できていない、いわゆる天才肌とも言えるものである
一般的に、天才というのは他人に自分がなぜできているのか説明するのが非常に下手なことが多いように思われる
例えば水泳について考えるとして、水泳の天才は子供の頃からなんとなくできてしまうパターンが多いように思われる
しかし、天才的な水泳選手が他人に教える、子供に教える、となると非常に下手になってしまう
その理由は私なりに考えるに、天才は自分がなぜそれができるのか、できるようになったのか理解できていないのである、天才だからである
しかし、天才には敵わなかったが、努力の天才とでも言うか、努力で実力を積み上げた選手は他人に教えるのが上手いのである
なぜか？
それは彼らが、自分はなぜできないのか？天才はなぜできるのか？それをひたすら考え、天才のフォームを観察し、仮説や実験、検証を繰り返したからである
苦労をしてきたからこそ、できないプレイヤーの欠点、伸ばせる長所などが分かるのである
詐欺的なもの、単なる自己啓発的なもの、ポジティブシンキングになれば引き寄せの法則が、みたいなものは尚更無意味である
恋愛のマニュアルもまた、恋愛を上達させるために努力を積み上げてきた努力の天才、恋愛の天才に努力で太刀打ちしようともがいた人が書くべきである
以上、まず恋愛にもマニュアルが必要だということを述べ、そこにはステップアップ方式で学べるチュートリアルも必要であり、
それらを正しく書くためには恋愛の天才ではなく、恋愛の天才を目指した努力の天才が書くべきだということを述べた
まず、マニュアルがないのが悪い、マニュアル人間は悪くない、という発想の転換、逆に考えてみることが大切なのではないだろうか
自動車だってマニュアルがない教習所もない教官もいないでは事故って死ねというようなものである
とりあえず動くソースコードでそれなりの規模のが欲しければGitHubからcloneしてくればいいんだよなあ。
と言っても、元増田が「gitって何？」のレベルだとそこで話が折れてしまい、
gitとは？バージョン管理とは？ハッシュ値とは？みたいになってしまうので説明する側も辛い。
自分が説明される側でも説明する側でも辛いのは、それだけ専門性が高い分野ではあるのだろうけど。
自分だって自分の専門外のことをそれ専門の人にまくし立てられて説明されるの辛いｗ
ソフトウェアの命名規則が天邪鬼でなければ、スタート地点はmain.cppみたいに類推もできるはず。
デバッガでメインルーチンからブレークポイント打つなりしてポチポチ動作させたり変数の中身の変化を確認していく。
色々なクラスとかソースコードを眺めて全体像を把握し、そこからコアとなる機能、自分が知りたい箇所を目指す。
ソースコードがある、デバッグ情報があるなら、当たり前だが変数名や関数名があるので類推しやすい。
（Javaとかで難読化してると、逆コンパイルできても変数名や関数名は分からなくされていて読み辛かったりする。
いや、だから難読化なんだけどｗでも、.classファイルしかなくてもそれで中の肝心のアルゴリズムは読めてしまったりする）
自分には大した技術はないと自分でも思ってるけど、普段やってることをまったく知らない人に説明するのは難しいだろうね。
というか、できる人やプロだって新しいビルド方法なんて分からない。
C++ならcmakeやpremakeは分かるけど、ninjaってなんじゃ？みたいなｗ
そこで新しい道具に手を出して躓くことも多々あるし、
他人は他人で自分の知らない道具、好きでない道具を使ってたりもするわけで、ビルドするために嫌々最低限即席で学んだりする。
適当に感想を述べる。ただの主観なので履修に悩んでいる人はシラバスと逆評定を読め。L系列については書かない。
「¬A ∧ (A ∨ B) ⇒ B」みたいな命題の証明を、ある規則に従って行ったりする。理科生的には数学の根源を掘っているみたいで楽しい。
全13回の授業で毎回違う教員がいろいろ話をしてくれる。各回ごとにレポート課題が出るが、最終的に提出するのは1つだった。単位に関係あるのは実質1回だけなので、結構気楽に聞くことができて癒しになる。普通の講義は毎回理解を求められるが、この授業は理解できなければその回のレポート課題を選ばなければよいだけなので。
人間の認知機能と脳機能の関係をやる。説明の都合なのか話題の9割が視覚（特に錯視）についてだった。脱線が激しすぎて全体的に何を言いたいのかいまいちわからない。ノートとスライドと教科書を見比べまくってなんとかしたが面倒すぎた。良い勉強方法が最後までわからない。
学際の香りがする。主に扱うのは二酸化炭素とオゾンホールとプラスチックとダイオキシン。「地球に温室効果がなかったら気温は-15℃」というのはよく聞くと思うが、その根拠をエネルギー収支の計算から示したりする。意外と覚えることは多い（フロン番号の命名規則とか）。
印象がない。新しいことを学んだ気がしない。とにかく簡単だった。
天下り的にいろんな化学が降ってくるが、具体的な理論づけは全くやらないので結局暗記ゲーと化した。基礎化学で扱う内容は、後々その他の化学系の科目で詳しく扱うので正直取る意味がなかったと思う。
熱力学の更なる応用みたいな感じ。ルシャトリエの原理とかの証明をしたり、酵素の阻害剤がどう働くのかをやる。学ぶところが多くて楽しいが結構難易度は高い。
なにもわからん。
Pythonやってれば楽勝。Pythonの実用みたいな感じ。アルゴリズム力よりコーディング力が付く。
アルゴリズム入門よりアルゴリズム寄り。ダイクストラ法とかやる。毎回課題が出るので面倒さは結構ある。アルゴリズム好きな人は楽しいと思う。
謎の証跡用画面キャプチャPDFを大量に残さないといけなくて、それらを共有フォルダに決められた命名規則で保存
主にメールで業務するのにDaaSのPC上だとメールがインデクスされてないので検索にめちゃくちゃ時間がかかる
最近グループ全体で使うコミュニケーションツールが導入されたけどスマホからは写真添付出来ないクソ仕様
で、根本的な原因は社員のITリテラシ、というかそもそも具体的な能力が低すぎて話にならないからなんだよね
普通のOutlookはメールの検索が１秒以下で終わることを知らないし
SlackクローンのMattermostがあるとかも知らない
当然プログラミングはできないし、そういったことは「誰かに頼んでやってもらう」のが標準だと思っている
で、自分たちはリスクマネジメントだのAIストラテジーだのデジタルトランスフォーメーションだのを勉強してる（笑）
だからいつまで経っても良くならないし良くしようとしてもよくわからない障害に遭う
昇格試験でも「そもそも基礎力上げないと話になりませんよ」と言っても共感されないしピンときていない
「そんなことよりマネジメントは」「AI戦略どうするのか」みたいな話ばかりで
「いやだから、基礎力ないとそんな話できませんよ」
まぁ結果として部内評価で昇格はしたけど面接の成績はボロボロで
同じような問題意識持ってても落とされた人はいっぱいいるんだろうなぁ、とは思う
大企業がそれなりのITリテラシ持てばそれなりに新しいことができるとは思ってるんだが
そろそろ潮時なんだろうかとも思い始めている
はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ
441あとで/2227users 未経験でも1カ月で即戦力クラスの知識が身に付く『webデザインドリル』公開 | knowledge / baigie
319あとで/2886users 賃貸住宅の退去費用として13万円請求された時の対応方法をまとめます｜犬笛｜note
305あとで/1662users 非デザイナーの僕がデザインぽいことをする時に使う便利なツール18選｜かずたか@プログラミング独学して起業した人｜note
260あとで/2214users 【朗報】Youtuber中田敦彦、うっかりまともな資産運用を数十万人に広めてしまう・・・これには金融マンも真っ青 | ライフハックちゃんねる弐式
228あとで/1529users 研修資料まとめ.md · GitHub
214あとで/1017users 技術ブログをバズらせたくて必死で身につけた情報収集術 - omuriceman's blog
191あとで/1517users 社会人の不幸の8割は合意のない期待から｜田中邦裕｜note
185あとで/1788users この法律が日本を｢生産性が低すぎる国｣にした | 国内経済 | 東洋経済オンライン | 経済ニュースの新基準
182あとで/1222users 科学的で現代的な「人を動かす」──『事実はなぜ人の意見を変えられないのか-説得力と影響力の科学』 - 基本読書
180あとで/970users 3年かけてたどり着いた英語記事を読むための方法 - Qiita
172あとで/796users 文系大学生が機械学習を０から始めて９か月でKaggle銀メダルを獲得するまで - Qiita
170あとで/669users いま知っておきたいLinux─WebアプリがOSのプロセスとしてどのように見えるか？ を運用に生かす - エンジニアHub｜若手Webエンジニアのキャリアを考える！
170あとで/1344users 機械の立体図をフリーハンドでとんでもなく上手に描く人が製図のテクニックを解説「恐ろしいレベル」「弊社に欲しい」 - Togetter
169あとで/2472users 食べログ3.8問題を検証 - クイックノート
168あとで/1146users 質問が出ないのは話し手の責任が8割。だから「質問が出る」ようにルールを決めたら、大成功した話。 | Books&Apps
166あとで/898users 貧困を減らす実験アプローチ｜安田 洋祐｜note
165あとで/679users 社内勉強会で作ったDocker/Kubernetes入門の資料を公開しました - inductor's blog
164あとで/695users データサイエンス・機械学習をやるためのエンジニアな本まとめ - 2019年版 - Lean Baseball
157あとで/1090users 20年の営業マン生活でわかってきた「仕事の本質」を全部話す。 - Everything you've ever Dreamed
154あとで/953users 【インスタ、エアビー、Slack等】人気サービスの初期ユーザー獲得方法
153あとで/1292users 【四川料理のスゴい人】家庭のキッチンの火力で「プロ並みのチャーハン」をつくる方法 - メシ通 | ホットペッパーグルメ
151あとで/1150users ０から100万円貯める、節約サバイバルガイド
149あとで/1972users 巨乳の炎上に見る進化と文化のミスマッチ - 本しゃぶり
148あとで/637users WebサービスのA/Bテストや機械学習でよく使う「確率分布」18種を解説 - paiza開発日誌
147あとで/1149users フライドポテト、チェーン店別徹底比較 :: デイリーポータルZ
143あとで/598users プログラミングの命名規則ガイドラインを規定するオープンソースプロジェクト「NamingC - エンジニア・プログラマのソーシャルITメディア
143あとで/661users ワークフロービルダーが新登場 : Slack で簡単にタスクを合理化 | The Official Slack Blog
142あとで/564users 「単体テスト」再入門！ 開発の現場でバグを確実に洗い出す最適な手法と、テストケースの作り方 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
140あとで/1334users 13歳から43年間野宿していた「洞窟オジさん」はかつての住処でナニを食べていたのか？【極限メシ】 - メシ通 | ホットペッパーグルメ
138あとで/963users 自称IT企業があまりにITを使わずに嫌になって野に下った俺が紹介するWindowsの自動化の方法 - Qiita
私が前に勤めていた会社の話。
会社は、Web制作会社でした。クライアント企業からサイト制作を承る、どこにでもあるちっぽけな受託の会社です。
そこに、中途採用でデザイナーが入ってきました。まだ若いけれども、前職でもWebデザインをしていたという女の子です。
Aさんは、即戦力として期待されていましたが、まだ若いということもあり、会社のローカルルールなどにも慣れてもらうため、
教育係がつくことになりました。それが、当時デザイナーチームの中でもトップクラスの実力を持つ、年配の（多分40代）女性です。
そのベテラン教育係の人を、Bさんとしますね。職人肌で、黙々と自分の仕事に取り組み、いつも良いデザインを仕上げてくれるプロフェッショナルです。
さて、Aさんは入社１週間も過ぎ、順調に仕事をこなしていました。実はこの会社は過去に未経験者を多く取りすぎてしまい、
ろくに教育も出来ないのに仕事を押し付け、うまく仕事が回らなかったという反省がありました。
（あまりの無茶振りに、９割ぐらいの採用者は退職してしまったのです）
そんなこともあり、経験者のAさんには期待も集まり、周囲は「久しぶりにようやくまともな人が入ってくれた…」
ただ、Aさんはちょっと独特な感じの人でした。
良く言えば「ふわふわしている」、悪く言えば「不思議ちゃん」な感じです。
もちろん仕事はおろそかにしていなかったですし、業務遂行上のコミュニケーション能力は、何ら問題ありませんでした。
さて、教育係のBさんです。彼女は長く勤めていましたが、家庭があるので、パート勤務でした。
どちらかといえば職人肌で、後輩の面倒をまめに見るというよりかは、自分の仕事はさっさと終わらせて帰りたいタイプのようで。
（そりゃ家のことがあるし、さっさと帰りたいがためのパート勤務でしょう…）
それでも、Aさんは最初からテキパキ仕事をしていたし、社内のローカルルール、例えば素材はサーバーのどこにある、だとか、
ファイル名の命名規則やフォルダ構成はどうするかとか、そういう最低限だけ教えて、後は放置だったようです。
当時はかなり仕事が立て込んでおり、Bさんに仕事が集中していた、ということもありました。
パートなのに、夜の８時を過ぎても帰れない、なんてこともざらにあったようです。
そんな時、事件が起こりました。不思議ちゃんなAさんが、突如大声をあげたのです。
「あ～～～ ２時間かけてやったイラレの作業間違えて消しちゃった～～！！！」
長時間コツコツやってきた作業が、一瞬で電脳の藻屑に消えた時の、無限にも等しい喪失感を。
周囲からは「Aちゃん、ご愁傷さま～」「保存してなかったの～？」という言葉がありましたが…
隣に座っていたBさんは完全無視。そう、この時も確か夜の8時頃でした。
BさんはBさんで、怒涛の仕事量を押し付けられ、この日も帰れずにいたのです…
Aさんの、ふわふわっとした、あま～い感じの声で「イラレの作業消しちゃった～！！！」に
いちいち反応している状況ではなかったのでしょう。
「タイムマシン、ないんですか～？」
とBさんに質問したのです。
そこで初めてBさんが
「はぁっ？」
と切り替えしました。
Bさん「はぁ？」
Aさん「だからぁ～、データが飛んじゃったんですよ。タイムマシンがあれば復活できるじゃないですかぁ～」
Bさん「はぁ？ あんたねぇ、そんな状況で子どもみたいな冗談言ってんじゃないわよっ！ こっちだって忙しいんだから！」
Bさん、ついにキレました。忙しいってのもあったのでしょうけど、Aさんの不思議ちゃんっぷりにも、前からイライラしていたのかもしれません…
いずれにしてもBさんがキレるような光景は社内全員始めてだったので、みんな、ぽかーんとしてことの成り行きを見守っていました。
そして、Aさんもここに来てキレてしまったようです。
Aさん「はぁ？ なんでこっちがキレられなきゃなんないのよ！ タイムマシンのない会社なんか信じれられないわ！」
Bさん「だぁかぁらぁっ！ 冗談言ってんじゃないわよっ！ ここは会社よ！ タイムマシンなんてないんだから、こまめに保存してなかったアンタが悪いんでしょっ！」
Aさん「あぁ？ 話の通じねえおばさんだなぁ！ 会社だからこそタイムマシン用意しとけってんだよ！」
あのふわふわしたAさんとは思えない言葉遣い… いよいよ二人が掴み合ってキャットファイトに発展するか！ ぐらい盛り上がったところでしたが、先にリングを降りたのはAさんでした。
Aさん「あー、もういい。こんな会社、辞めてやるわ！ こんな時間まで作業してタイムマシンもないとか、ありえないし！」
といって、カバンを持って帰ってしまいました。当然、2時間の苦労がパーになったイラレの作業はほったらかしで。
Bさんは、Aさんが会社の部屋から出ていくのを見送ってから、何事もなかったように自分の作業にもどりました。さすが職人です。
さて、ここまでお読みいただいた方のうち、Macユーザーの方ならお分かりいただけましたね？
そう、Timemachineとは、Macに搭載されている自動バックアップシステムです。
通常、1時間に1回自動的にバックアップが取られるので、間違って消したとしても、1時間前に保存されていれば、そこから取り出すことができるのです。
そして、残念ながら、この会社は全員Windowsでした。さらに、個人でMacを使っている人も数えるほどしかおらず、ほとんどの人はTimemachineがMacのバックアップシステムだと知りませんでした。
（ちなみに私がその数少ないMacユーザーで、上記やりとりを見ながら、吹き出しそうになるのをずーっと堪えてましたｗ）
BさんはずーっとWindowsで仕事してきた人のようで、Aさんの言う「タイムマシン」が、不思議ちゃんぶっているAさんの、タチの悪い冗談に思えたそうです。
適当にいなしても食い下がってくるAさんに、ついカっとなって怒鳴ってしまったとのこと。もちろんタイムマシンがそういうものだと知っていたら、そこまで怒らなかった、と後に彼女は語っています。
さて、次の日。
私が出勤すると、入れ違いにAさんが会社の部屋から出てきてすれ違いました。早く会社に来て、昨日のことを話していたのでしょう。
その日の朝礼で、マネージャーから「えー、突然ですが、Aさんは本日付けで退職となりました」と発表があり、どうやら早朝に話をつけてしまったようです。
・データのバックアップを取る仕組みを会社が用意していないのはおかしい
・以前の会社では、Timemachineが用意されていたMacで業務をしていた
・Windowsを使うことに抵抗はないが、そういう仕組みがない会社では働けない
・TimemachineはMacユーザーには常識。Macのことも知らずにこの業界で仕事をしている人たちがいるなんて信じられない
・というか、Macでの動作検証とかどうしてるんですか？（←一部の人が個人の端末でチェックしてるだけ。してない案件も多い）
・なので辞めます
という話があったそうで。一応就業規則的には退職は1ヶ月前に申し出る、ということになっていましたが、
彼女は頑としてそれを受け入れず、社長がしぶしぶ当日で辞めて良いということを認めたそうです。
まあ、私も彼女は気の毒だと思いましたが「そんなことで会社辞めんでもｗ」とは思いました。
彼女はまだ若いので、こんなしょぼい会社辞めたところで、身の振り先はいくらでもあるのでしょう…
ここもちろぐ
生産性志向のSEが、IT業界での奮闘記や仕事や生活で学んだことをはきだします。
2018-05-15
gizeh-2272008_640
こんにちは。もちです。本日は、みずほ銀行のプロジェクトで2か月限定支援に行った時のことを話したいと思います。
あの頃は、ちょうどポケモンGOがリリースされた時期でした。 プロジェクトのお昼休みに、わくわくしながらアプリを立ち上げて、メンバーの方と遊んだものです。
そんな次期システムが、いよいよ、2018年6月9日から徐々に移行開始されるそうです。
みずほ銀、9日からシステム移行 「世界最大級のプロジェクト」 ATMやネットバンクに臨時休止日 (1/2)
みずほ銀行とみずほ信託銀行は、入出金や口座管理などを担う勘定系システムを統合した次期システムへの移行作業を9日から始める。4000億円超の資金を投じて進めてきた世界最大級のプロジェクトが、最後のヤマ場を迎える。
www.itmedia.co.jp www.itmedia.co.jp
移行が発表されてから、「あの頃が懐かしい」と感じたため、せっかく浮かんだいろいろな想いを残そうと思って記事にしました。
ここもちろぐ
ここもちろぐ
みずほ銀行のプロジェクトで2か月限定支援に行った時の話、まなび編です。 ▼前記事の問題編はコチラ www.cocoamocchi.com 古参メンバーの仕事を奪う デキる古参メンバーはとにかく忙しいです！！ 新規参入者でもやり方さえ一度知れば、できそうな仕事もありそうだということで、積極的に仕事を奪いにいきました。 たとえば…
2018-05-17 22:53
www.cocoamocchi.com
毎朝エレベータに長蛇の列
人気アトラクションかな？と思わせるほどの大行列でタイミングが悪いと10分以上待たされました。
テストフェーズがちょうど一個上の段階に進んだためか、チーム内のスマホは鍵付きロッカーでしっかりと管理されるようになりました。
インターネットが使えない
security-265130_640 これが一番厄介でした！！！
新入社員であれば、まずはググり力を鍛えろ！と先輩に教わるも方もいるのではないでしょうか。
わたしみたいなIT業界で働く方々は特にインターネットで調べまくる生き物です！
なのに使えないので厄介でした。
・・・とはいっても、わたしの場合は、こっそり休憩スペースにスマホを持ち出して調べてました。
他には、書籍にもお世話になりました。
ここで 「ネットが当たり前だと思うな、腕を磨こう」という教訓を得ました。
印刷用紙が真っ赤で読みづらすぎ
持ち出し抑止のために、プリンタ用紙が赤くなっておりました。
(特に持ち物チェックがあるわけではないので、悪意のある人なら持ち出せたかと思います。)
印刷してみるとまあ～わかりづらい。 気持ち的にもなんか落ち着かない。
でも一定の効果はきっとあったのだろう。。
ただでさえ生産性の低い環境なのに、働き方もやっぱり残業ばかりされている方だらけでした。
特に既存メンバーの古参者は大量に仕事を抱えているので、いつもヘトヘトです。
他の人へのレビューも、当然荒い。
また最終退館者名簿を見ると、お客さまサイドも負けずと毎日23時台まで残っているようでした。
※ちなみに
ごめんなさい、わたしは最長でも21時には帰りました！寝不足すぎると生産性がダダ下がり逆効果なので苦笑。
単体開発 バグ改修
私の場合、残念ながら新規開発部分は残ってなく、仕様取り込みやバグ改修をちょこっとやったくらいです。
開発ではなく、ほとんど仕様整理やJP1いじっている時間が多かったです。
命名規則がつらい
短い単語をアルファベット1文字で表現する文化があったため、それらをつなげて作成されるDBのテーブル名やカラム名が新規参入者にとってはしぬほど分かり辛かったです。
1箇所の修正で5個もケースはないし、誰も見ないのではないかなというくらい、ゆるふわなテスト結果が置いてあったりと、とてもじゃないけどもお金を扱うシステムだとは思いませんでした。
これ、結合テスト以降、バグ爆発するのでは？という印象だった。
the-1865639_640
階層がとにかく深く、無秩序に置かれた何千のフォルダ群はまさにジャングル。
既存の古参メンバーであったとしても、過去の単体テスト仕様書の在り処を探すだけで10分以上かかっていました。
IDEなど開発に使用するツールも、各チーム持っている情報が異なっていて、結局、既存メンバーの持っているものを丸ごとコピーして使ってました。
個々の期限がタイトにも関わらず、申請日時を厳守しなければならないのはつらかったです。
この申請は、数チームで1つのエクセルファイルにまとめて申請します。
プログラムファイル１つ１つのパスを記載していくのですが、 誰かが1ファイル既述を誤るだけで、
どこぞやのチームのせいで2連続申請ミスされたこともあり、こちらとしてはたまったものではありませんでした。
もしかしたら、誰かが休みたいがために、わざとミスしてるのではと疑いたくなるくらい大変でした。
まあ、とはいっても緊急リリースみたいな１～2日でできる裏技も時に使うことができたため、そこまでではなかったのかもしれません。
プロジェクトマネジメント
child-waving-goodbye-595429_640
うちの会社だけかもしれないけど、メンバーの離脱が、作業指示を出しているチームリーダーまでなかなか届かない印象でした。
「来週からこの作業お願いするね」と言っていた矢先に、彼らがいなくなることを知らされる。
これは、どこの炎上プロジェクトもですが、各タスクの期限だけ決まっていて、工数は考慮されていない事案です。
この事案は仕方ない場面もありますので、メンバー側がリーダーやプロマネに少々寄り添って、自分で仕事を考えていればOKです。
親切なプロジェクトじゃないのは分かっていることなので、他責にせず、ざっくりと工数を伝え、助けていきましょう。
新規参入者の実力が怪しい
少し言語知っている程度(for、if文はできるけど・・)で意思疎通の難しいプログラマーが国籍問わず、たくさんおりました。
猫の手も借りたいくらい忙しいプロジェクトだったので、自分で主体的に仕事を考え、動き、古参メンバーを助ける必要があります。
しかし、
進捗が良くないことをごまかす
など、この中のどれか1つ該当ではなく、複数持ちのプロジェクトキラーが何人かいました。
他の人も急に想定外の残業フォローをしなければならなくなるし、本人は無駄に悩み続ける時間増えるし、誰も幸せにならない感じでした。
まとめ
特に銀行のプロジェクトは、生産性の低い現場やずたぼろな構成管理など、環境的問題も多いことがわかりました。
同時に他責にせず、主体的に行動すれば、新規参入者でもそれなりに活躍できることもわかりました。
しかし、わたしの場合、２か月限定が配属前から決まっていたこともあり、
心までしんどくならずになんとか戦えたことが大きいかもしれません。
もし炎上案件に出会っても、 心や身体をやられるようなことがあれば即刻辞退をおすすめします。
残業による残業という負のスパイラルが、もし嫌なら、早く抜け出すほうがこれからの人生豊かです！
断言できます！！
