指摘スクランブル

先週は５日分の作業を３日で強行し、残りの２日を苦戦しているメンバーのフォローに当てた僕だが……。全くリカバリーできない。埒が明かない。どうしたもんやこれは。(´・ω・`)

頓挫しているのは設計書の執筆なんだけどね。まず、こんな感じ。

２．○○テーブルの更新
××テーブルを検索条件。

何を言うとるんや？(´・ω・`)

まあ、僕は設計書を読まなくても実現するべき機能は知っているから、上の箇所で本来表現したかったことも分かるんだけどね。

まず「２．○○テーブルの更新」ってのは、コピペミスだ。
別の所からコピペして、タイトルを直すのを忘れとるんや。

• ケアレスミス

次に、「××テーブルを検索条件」って、日本語おかしいやろ。何を言うとるんや？

本来だったら「××テーブルを検索する。検索条件は以下のとおり」とでも書いて、その続きで条件をツラツラと書きたかったのであろうけどな。

• 日本語としての異常

ここまではドキュメントとしての精度の問題だが、次はロジックとしての問題だ。
設計の本質的部分である検索条件が違う。

「そんな条件で検索するべきものではない」と「そもそも引数が物理的にそこに到達していない」、「別のバッチと辻褄が合っていない」と、三重で間違っている。

• 検索条件の誤り
• 単体的な観点からの誤り
• 結合的な観点からの誤り

全部違う。

更に「２」という項番が違う。
この処理はチェック処理だから処理の最初である「１」で行わなければいけないんだけど、「チェック処理を通過してから更新処理に進む」という概念が足りないから、更新処理と更新処理の間にチェック処理を挿入するような設計を書いてしまう。
記述する場所を移動させなければならない。

• フローチャート的な観点からの誤り

って感じに、設計書中の僅か５行１０行を見るだけでも指摘事項は１コ２コ３コ４コ５コ６コ……と、性質の違う誤りがスクランブルしている。
これがドキュメント全体で発生している。

どこから直していけば良いんや？(´・ω・`)

こうなってくると、本来はもう根こそぎ僕がやるべきなんだが。
どこから手を付けて良いか分からんこの設計書は全部抹消し、

(´・ω・`)「僕が一回、上から下まで全部見本を書く。それを踏襲して、次からの設計書を書きなさい」

って感じに、根っこからの軌道修正を行うべき状況。

なんだけど、それってつまり、その人が今までやってきたことは何の意味も無い、ゴミ。生産性ゼロと言ってるのと同じだから角が立つだろう。

しゃーないから、ビデオ会議で１時間も２時間も費やして説明するとか、あるいは何個も何個もチケットを起票して修正要求するとか。

そうやって、先週の木、金。そして月曜日の今日も過ごしてきたが、終わらんなぁ……。

レビューの指摘事項が多いのは構わないんだけど、この設計はレビュー対象と言うより、叩き台にすらなっていない。
ゼロからやり直すべきシロモノであり、レビュー指摘＆修正というサイクルに適合しないものなんだ。

そろそろ先週作ったバッファが枯渇してきているから、本格的に進捗を再スタートしなければイカンのだけど。

一体どないせいっちゅ～ねん。(´・ω・`)

三密論文

ちなみに、僕がセミナーに十数万円も払って、どんな勉強をしているのか、諸君らに無料でお教えしよう。(´・ω・`)

例えば、

リモートワーク開発について、私見を述べよ。

みたいな問題が出るとするじゃない？
どんな論文を書く？

パッと思いつくのはこんなところだろう。

• リモートワークはコミュニケーションの問題が発生する。
• チャットとかビデオ会議を使って遠隔コミュニケーションを促進する必要がある。
• セキュリティに注意しなければならない。

こんな論文は誰でも書けるんだよ。
これでは合格にならない。
合格論文は、もっと具体的かつ、専門性に富んだ回答をしなければならない。

例えば、僕みたいなプログラマー部門の人間だったら何を書くか？

例えば、同じリモートワークでも、１００人規模の大規模ウォーターフォール開発体制と、５人チームの小規模アジャイル開発体制では、難度が全然違うでしょ？

１００人全員が一斉にリモートワークに移行したら滅茶苦茶やがや！！
でも、元から５人くらいの小規模チームで、かつメンバーも相応にスキルが伴っていれば、別にリモートワークに移行するのも難しくないよね？

また、そこにコロナ対策という背景も加わったらどうか？

１００人規模のデスマ開発なんて三密そのもの、タコ部屋、典型的なクラスター発生源やろが。
５人規模の開発体制であれば、そりゃ家族が同じ所にいるのと変わらん。

リモート開発という意味でも、コロナ対策という意味でも、開発規模は小規模チームに区切ることが合理的なんや。

こういうのは僕みたいな現場を知っているエンジニアでなければ出てこない。VPNで繋いでセキュリティを担保、とかそんなのは仕事している人間はみんな知っとる。知ってても、それを書くべきタイミングが今だ、と気付くかどうか、ということや。
システム開発部門の人間だからこそ知っている具体的な着眼点を論文では表現する必要があるんや。

セミナーで勉強しているのはそういうことや。

「文章の上から下まで筋が通っている」というだけの国語力の問題では済まんのや。
「専門性とは何たるか？」を言語化して踏み込まねばならんのや。

上記みたいな話は経験のあるエンジニアならみんな知っているけど、いざ問題として論文を書けと迫られた時に、「ああ、この問題はそういうことを聞いているのか」と理解出来るかどうかは別の話だ。

セミナーではこういうことを教えて貰っている。「こういう問題ではこういう事を書くべきなんですよ」という趣旨だな。それを勉強している。

どや。こんなブログを読むだけでも勉強になったやろ？

諸君らも真面目に勉強しなければアカンで。m9(´・ω・`)

セミナー終わり

今日は技術士のセミナーを受けてきた。ふう。(´・ω・`)

次のセミナーは来年だから、しばらくはゆっくりできるか。しかし宿題が出ているからコツコツと頑張っていかないと。

しんどいなぁ。(´・ω・`)

時間の合間を縫って勉強していくべきスケジュールだから、例えば仕事終わって晩御飯で酒飲んでいる時も「ああ、酒なんか飲んでないで少しでも勉強した方が良いのかな？」みたいな気がして、１秒足りとも忘れてリラックスすることが出来ない。

今までの試験との違いは、経年疲労。
もうウンザリなんや。

今までの試験は「今年落ちても来年また再チャレンジすればいいな」と気軽な気持ちで無理なく勉強を続けてきたけど、１５年もやってると、流石にもう嫌なんや。(´・ω・`)

それに、ここまで来ると人生の境遇も負担になってくる。

僕は別にＮＴＴ研究所とか、そういう所の技術者ではないんやで？
基本情報も持っとらんような連中に混ざって若手の面倒を見るとか、そんな泥臭い現場型のエンジニアや。

そんな中でＰＭやら技術士やら、ってのは異色の存在。こんなことやってるの僕しかおらん。知り合いで技術士持っている人が１人いるけど、その人は会社の経営者や。
何かおかしいんや。僕は普通ではないんや。

従って、話題にも出せん。そりゃそうやろ？
僕が資格の話を始めたら、

(´・ω・`)「僕はＰＭも取って今は技術士の勉強をしているのに、諸君等は基本情報すら持っとらんのかね？　ん？」

って感じに相手は受け取るに決まっとる。

従って、僕自身が資格の話を持ち出すことは出来ない。同格の人間がおらんってことは、話題が合わんってことだ。これが鬱に繋がる。

あと、年齢や社会的立場。
僕はもう３８歳。今まで十分積み重ねてきたという自負はあるし、そろそろ成果を出して収入もそれなりのものにしなきゃいけないというプレッシャーも感じている。
そんな時に「試験に落ちました」では面目が立たんやろ。人生はどうなるんや？
１年目に基本情報に落ちて、２年目にチャレンジするような若手とは背負ってるものが違うんや。

ちなみに、僕は去年にＰＭに合格したが、それまで４年間、ＰＭに落ち続けたからな。
同じ試験に４年連続で落ちる不毛。常人では耐えられんぞ。僕だから根性で七転八起が出来るが、普通の人間だったら２年目くらいで放り出しとる。

とにかく、何もかもが負担と鬱とプレッシャー。

本当に終わりにしたい。

一縷の望みは、来年の試験で一発合格すること。それで僕のこれまでの苦労に見合った正当な評価が得られることになる。

辛いお。(´；ω；`)

勉強しんどい

 技術士の勉強、キツい……。鬱になってくるわ。(´・ω・`)

でも何とか受かっちまえば今後の展望も開けてくるんだが……。

今後ってのは、僕が６０歳とか７０歳とかになった時の話ね。真面目に考えていかないと。

同じＩＴ業界、システムエンジニアに該当する人間の中でも色々な種類がいるんだけど、僕はプログラマー、典型的な技官なんだよね。
３８歳の今はパワーを持って働けるけど、流石に６０歳で同じ働き方は厳しいと思われる。だから今のうちに資格を取って、例えば論文の執筆とか、スクールの講師とか、そういう現場の最前線から離れた所に行かざるを得なくなった時でも活躍の道を残す為の方策。

それが技術士受験だ。

技術士に受かり次第、ちょくちょくどこぞに論文を投稿とか始めていきたいと思っているが、それは先の話だ。

とにかく今は合格が先決だ。

ちなみに、僕とは違うタイプならばどうか？　例えば、マネージメント系の人。マネージメントは経験豊富であることが有効な面が多いから、比較的技官の僕よりも高齢化に強いのかな？

と思ってたんだけど、意外にそうじゃないんだよなぁ。

僕の知っているＮＴＴの人とか、ＮＴＴなんて典型的な大企業で、ＮＴＴ自身は管理を行い、実装は下請けに発注する構図でしょ？
そういう所の社員はどうなっているかと言うと、５５歳で役職定年とか言われて年収ダウンして仕事も無くなっちゃってるのよ。

可哀想に。(´；ω；`)

だからマネージメント路線の人は、同じ職種の人間同士で競争に勝たないと６０歳７０歳の道は存在しない。マネージメントに行きたがる人は多いけど、あれは狭き門なんだ。

だから、マネージメント型の人の方が安泰とは安直には言えないってのが僕の考えだな。
どこもキツい……。

とにかく、僕の場合は、同じ働き方を永続することが不可能であることは明らかで、いつかどこかで変化する必要が絶対発生する。
その変化に対応する為に、今のうちに資格を沢山持っておくだの、あっちこっちに論文を投稿して名声を広めておくだの、柔軟な発想と入念な準備の両方が必要なのよ。

ただ頑張って毎年同じように農作物を育てていれば良いような業界じゃないの。

生きてるだけで辛い業界じゃ。しんどいしんどい。(´・ω・`)

前倒し

やれやれ、突貫工事で実装してきたが、今週５日分の目標を３日で達成できた。(´・ω・`)

ここからは少し落ち着いて見直ししつつ、要件が動いちゃってる部分へ改修とか、微調整フェーズだな。

早めに終わらせて終盤に余裕を持つのが仕事のコツや。(´・ω・`)

もたつきマン

 こういうパワフルなプロジェクトになってくると、やっぱり人生は押し進めていくことが最も重要であることが再確認できるな。(; ･`д･´)

仕事やってても、とりあえずは仕事を割り振って、数時間待って様子を見てみると……。
何か、モタついてて……。

( ；´Д｀)「う～ん」
( ；´Д｀)「あ……」
( ；´Д｀)「え……」

何をやっとるんや？
何が分からんのか自分でも分からんのだろうが、要するに全体的に自分の仕事のイメージが膨らんでいないから、何をどういう風に進めたら良い分からず、立ち往生しとるんや。

分からんのなら、分からんなりにとりあえずバーッと手を動かしてしまって、少し経ってから、

(´・ω・`)「こんな雰囲気にやっていけば良いでしょうか？」

って聞けば、中身がどれほどボロボロでも、結果的に全部やり直しになったとしても、それが叩き台となって再スタートが切れる。
全然分からないからこそ、とりあえず手を動かしてみる精神が必要なんだ。

が、もたついているヤツは、

( ；´Д｀)「う～ん」
( ；´Д｀)「う～ん」
( ；´Д｀)「う～ん」

こんなことやってるだけで丸１日経過するからな。成果物が虚無だから、支援する側も何をベースに話をして良いか分からん。

人生も同じで、止まってるヤツは３年経っても５年経っても止まってるからな。凸凹しつつも、とりあえず推し進めていかないと軌道修正もやり直しも出来ないって感覚が無いんだ。

緩いプロジェクトだとそんなに気にならないんだけど、このプロジェクトみたいに条件が厳しい「いざ！！」ってタイミングになると、その人物が進めていくタイプなのか、何ともならんもたつき野郎なのか、その辺が顕著に浮かび上がってくる。

とにかく、まだプロジェクトは大変だが、強い気持ちで活気を持って進めていかねばならんな。(´・ω・`)

圧倒的生産性

ちょっとプロジェクトがマジに大忙しで心がブログ書く状況ではないのだが。(; ･`д･´)

11/24(火)から新プロジェクトがスタートしたけど、要件に対して納期がとんでもないな。
12月で開発完了、1月がテストフェーズだぁ？
期間が３倍足らんわ！！

まあ、そういう無理を通すのがエンジニアの腕の見せ所なんだけどね。(´・ω・`)

ともかく、やるだけのことは頑張ろうと今週は突貫工事で頑張っている。頑張っても無理な可能性もあるんだけど、姿勢を見せておく事も重要だからね。
世の中は合理性ばかりではなく、そういう他者へのアピールも計算する必要があるってのが大人の世界ってもんや。

しかし気になるのが、設計書を書いてるヤツ。若手なんだが、まだまだ感覚が鈍いな。

と言うのも、要件はこうなんだ。

ファイルを読み込んで、ファイルの内容に応じて処理して欲しい。

これだけ見れば簡単に見えるだろう。
しかし「ファイルの内容に応じて」って一体何やねん？

これね、経験豊富なベテランじゃないと分からないんだけど、IT業界のシステム開発って、IN/OUTの総量が工数の総量なのよ。

「凄く難しい複雑なロジックを作る」みたいなクールな話は基本無い。

データベースの決まった所から取ってきて、0を1に編集して、また同じ所に戻す。処理なんて殆ど全部こんなもんよ。
問題は「決まった所」ってどこなのか、ということだ。

このプロジェクトの場合、

• 新規契約の場合
• 更新の場合
• 解約の場合
• 追加の場合
• 再送の場合
• 新規契約２の場合
• 更新２の場合
• 解約２の場合
• 追加２の場合
• 再送２の場合

それぞれ取り扱うテーブルのカラムが違うねん。

そりゃ、読み込むファイルは１コしか無いかもしれないよ？
だからバッチ本数は１本だ。
しかし、アウトプット先が１０種類あったら、処理の総量はバッチ１０本と同じである。

今、設計を書いているヤツは、バッチの起動トリガーが物理的に１つであることしか理解してねぇんだ。
しかし、本質的にはバッチ１０本だ。

コイツ、設計書は省略して書いているから気付かないんだろうけど、設計者は同時にテスト担当者でもあるから、テストケースを書く時になったら否応無く気付くだろう。
自分の認識の１０倍の処理が存在している、と。

ともかく、実装担当の僕としては、頑張ってソースを大量生産するしか無いな。(; ･`д･´)

設計者の認識の１０倍の仕事量が目の前に存在している。荒っぽくとも、とにかくこれを力任せに片付けて、細かい問題はテストフェーズでバグという扱いで修正して最終的に納期を間に合わせるしか無い、というのが僕の方針である。(; ･`д･´)

生産量がモノを言うプロジェクトだ。

要件未確定な部分もいくつか混ざっているか、そういうのは横に置いておいて、とにかく前に進めていかないと。

大変なプロジェクトや。(´・ω・`)