  |
はてなキーワード:ナレッジとは
第三者検証全体がこうではなく、ある巡り合わせにあったテスター一人がこんなふうに思ってたんだなというのを記録するために書きます。
この文章を読んで誰かにどうこうして欲しいとか誰かを上げ下げしようとかいう意思はないです。
## 単価と工数
私はエンジニア生活の2/3くらいを派遣契約で過ごしたため、仕事の良し悪しについてはやっぱり単価と工数で評価されることが多かったです。
残業すればするだけ会社の売上になるので、どんどん残業しましょう。残業しただけ働いたことになるから。という文化でした。
単価が上げていくことは現場責任者や営業の実力に左右され、そう簡単に変わるものでもなく、なかなか自分ではコントロールできなかったので、やっぱり容易く売上を上げていくには残業するしかありませんでした。
業務時間中に開催される研修やシンポジウム参加等は売上を下げることに繋がるので、明確なトレードオフ条件がないと参加が難しかったです。
私はそれでも構わないと思いますが、参加しようとするたびに一々上長に「売上減らしてごめんなさい」と頭を下げにいくのが変な感じがしました。
やっぱり残業時間が正義なので、中でどんな仕事しているかはあんまり重要ではなかったです。
品質向上の提案やテストの効率化を提案・実行したところで単価アップに繋がらなければ大きな成果には繋がりませんでした。
※私の場合はたまたまそういった点を評価してくれるお客様に出会ったこともあって、汲み取って営業にフィードバックみたいなこともしてくれました。給料には反映されませんでしたが、、
私は無関係な期間もありましたが、BP投入が最も評価されます。
何かにつけてプロパー/BP率を評価されて、BPを投入した分だけ利益が出るので営業頑張ろうとなるみたいです。
QAに関する提案についても第三者検証の商売として成り立つかどうかが判断基準になります。
例えば自分の会社では難しいテストレベルやテストタイプについてはその現場で必要に思えても、提案や計画には盛り込まないなどのことがあったかもしれません。
基本的に体系的なソフトウェアテストを行なっている現場に関われたらだいぶラッキーでした。
体系的なソフトウェアテストができていれば外注しなくてよかったりしますので、良くないテストマネジメントであったり、いびつなテスト設計をしています。
で、現場はお客さまの言うことを聞くことで精一杯なので、体系的な経験や知識を得るためには自分で勉強して頑張るしかありません。
10年、20年やっているようなベテランはJSTQBとかで整備された知識よりも勘と度胸と経験で頑張るみたいな場合があるので、自分で知識を取りに行かないとそういったベテランと同じ道を歩むことを頑張ろうとしてしまうんじゃないでしょうか。
本文は削除されました
私の結論は上記の通りです。やっぱりどんな現場であっても、どんなメンバーでも、どんなお客さまでも結果を出していくのがプロの第三者検証なんだと思います。
”品質のプロ"と名乗るのもいいですが、"第三者検証のプロ"と名乗る道もあるのではないかなと思います。
私は、
よさももちろんあります。思いつく限りたくさん書いていこうと思います。
様々な現場や製品に携わることができるので、一般化する実力さえあれば、様々な経験やナレッジを一般化して、ドメインに依存しない実力をつけることができると考えています。
自社QAだとどうしても社内の文化ややり方に依存した能力になっちゃうと思いますが、第三者検証テスターとしてたくさんの現場を経験していると、どんな製品でも対応できるようになるんじゃないかなと思います。
複数の現場を俯瞰して、より多くの現場をコンサル的な立場で関わることが第三者検証ではできます。
体系的な知識がある会社であれば、つよつよの人々からバックアップを受けながらコンサルをすることができます。
最近は法人を立ち上げてQAコンサル的な動きをする人が多いですが、事業が失敗するリスクとかを会社が請け負いつつ、コンサル体験を行う経験を得ることができます。
お客様から依頼を受ける形でテストするので、変な話、製品や事業がうまく行かなくても、ニーズがあればテストの業務を続けることができます。
また、現場やプロジェクトがなくなっても他の現場にいけばいいだけなので、その辺のリスクがないことが良い点だと思います。
第三者検証ということで、おそらくたくさんのテストエンジニアがいると思います。ベテランの人もいれば初心者の人もいますが、やる気さえあれば様々な人と繋がれることができます。
実際に私はいい出会いがたくさんありましたし、そういった出会いが私をQAとして成長させてくれたのではないかと思います。
2年目3年目くらいは色々悩んだ時期もありましたが、ある程度実力にも自信がついてきて、第三者検証テスターのつらさはどうでも良くなったきたというのが正直なところです。
第三者検証テスターとして一生過ごすかはわからないですが、第三者検証テスターになれてよかったと私は思いました。
まず、受注側から発注側になることで、「第三者検証」という呼び方をしなくなりました。
また、自分が成長できないこと、現実をうまくできないことを「第三者検証である」ということを言い訳にしていたと感じました。
テストベンダーの良さは、人材への投資があることだと思います。
だから、自分が投資に値する人間であれば、とてもいい選択だと思います。
「いきなり事業会社に行きたい」は、素晴らしいですが、事業会社の多くはあなたを育てようなんて思っていませんよ。
私にはテストベンダーで働くモチベーションについて、いくつかアイデアがあります。
ただ、それについて聞きたい人は私を探して私に直接聞いてください。
AI生成物ばかり学習させるとゴミになるちゃうねん。「なんでAI生成物ばかり学習させるとアカンのか」って所まで読んだ？
最近だとSNSのゴミを学習させたらボロボロになったって分かりやすいのも出てたろ。
同じ事を人間データでやってもアカンわけよ。だから大量に集めてクリーニングするの。十分な品質になるなら出自はどうでもいいの。バリエーションが足りないってんなら並び替えたり置き換えたりってのは自由にできるの。
そんでやたらとナレッジカットオフの1月にこだわってるけど、24年12月までなら汚染されてないとでも思ってる？んなわけないわな。やる事は一緒なの。
で、コロコロと学習内容を追加削除してたらデータ測れんだろ？だから25年1月ってのは「ここまでのデータで学習してます」以上の意味はないの。
AIゴミが問題ってんなら、ちゃんとした最新の教科書や報道をしっかり学習させりゃあカットオフ最新にできるぞ？25年1月までやってんのに、なんでやらないんだろうな？
システム開発で生成AIを有効に使おうとしたら、生成AIが生成するコードを鼻歌混じりで完璧に仕上げられるだけのプログラミング力と、システム全体の最適な設計ができる技術力が必須の最低ラインとなる。
プログラミング力がなければ、生成AIが仕込む地雷に気付けないからシステムを地雷原にしてしまう。
そのレベルのエンジニアでは地雷除去は100%不可能なので、ぶっ壊れたまま走る暴走列車になるだろう。
経営者の手の中に残るのは、ぶっ壊れて部品を撒き散らすサービスと、逃げ出さなきゃいけない状況なのにそれを認識できないほど低レベルの「バナナ」エンジニアの集団だ ( 大枚叩いて「世界をひっくり返す画期的なサービスを作ってる！」って思ってたらこれとか、まじウケる w )。
システム全体の最適な設計ができなければ、適切なプロンプトを捻り出せないので、整合性を保ったままサービスを成長させることは不可能だ。
現状、どこかで誰かが作ったような小さなツールなら、なんとかなりそうだと思う。
けど、成長させる前提のプロダクトに使うとか、正気の沙汰とは思えない。
小さなツールはAI のフレームの中でこなせるとしても、自社サービス、特に今までなかった類のサービスとなったら、フレームの外、現実に開いたものだからAI が扱える対象ではない。
具体的な指示を出してくれるように見えてるだろうが、過不足なく正しいかと聞かれたら、AI推しエンジニアにホルホルされたものを見た限りでは、ないわー、としか言いようがない。
AIの絵とかと似ていて、ぱっと見イケてそうで、よく見たら変。
絵のように、縦横の制限があって、各ドットの色の幅の制限もあって、多少色ずれがあっても大勢に影響がないものじゃなく、プログラムは一箇所+と-間違えただけでも致命的なものだから。
って、やたら本プログラムに迎合的なテストが生成されていたりするんだが、実装ベッタリの境界値テストとかより大事なテストが丸っと抜け落ちてたりするんだよね。
で、その重要性というか危険性を、エンジニアは理解も認識もできないままになったりする。
意味のないテストを延々と繰り返して、実環境で不具合障害が発生するたびに、場当たり的な対策をフジツボのように追加しまくってやった気になるのを運用だとか勘違いしたまま炎上地獄への坂道を転げ落ちていくんだよな。
大規模なサービスの設計は抽象度の高い部分を先に詰めないと、辻褄が合わなくなって破綻する。
初期リリースにはブーストが必要なのは確かだが、使いこなせない生成AIを使うと、書き初めで最初に筆を置く場所を適当にするのと同じくらい、取り返しのつかない事態に陥るだろう。
初期リリースこそ、全体設計と、サービスを支える基本モジュールを抽象的に、丁寧に作る必要がある。
「一旦リリースしてシェアを獲得してから作り直す」という選択肢も、一昔前ならあったけど、AI で嵩増ししたサービスの作り直しは、多分すでに合理的ではない。
再設計再実装の手間もそうだが、補助輪(AI)エンジニアに、移行作業の戦略策定設計実施ができるわけがないから。
最低限のプログラミング力とシステム設計能力があって使いこなせるエンジニアと、ないけど称賛していれば自分もすごいエンジニアと思ってもらえると思ってる意識高い系(笑)エンジニアだ。
おいら自身、たまーに使うけど、チームメンバー全員に積極的に活用しろとは死んでも指示できない。
というか言い渡した。
どのレベルのエンジニアが書いたプログラムかという情報なしに、レビューとかしてたら時間がいくらあっても足りん。
特にプログラムを書けないことを誤魔化すためにAIを駆使する奴は、発覚したら即銃殺でも構わないと思ってる。
でも、ドキュメントをAIに食わせてナレッジ共有させるのは構わないですよねって？
ゴミドキュメントを大量生成させてAIに食わせても、結果はゴミ。
"Garbage in,garbageout"くらい知らんか？ w
まずちゃんとしたドキュメントを書いて、ちゃんと整理して、ちゃんと更新しろ。
それ以上のナレッジ共有はない。
そういうことができない人間が書くドキュメントが、有用なドキュメントなわけがないだろ w
で、表題の件。
自社サービスをボロボロにした張本人たちに建て直せるわけがない。
以上 w
ほう、口の回転だけは3倍速だな。
だがな、「オフィスで成果を出せ」なんて言葉は、環境依存の無能が吠える常套句だ。
リモートだろうが出社だろうが、できない奴はできない。
若手が見て学べないだと？笑わせるな。
オフィスで背中を見て学ぶとかいうのは、教育をサボってる証拠だ。
見て盗ませるってのは、要するに言語化も構造化もできない指導力ゼロの怠慢だろ。
本物のプロは、ナレッジを共有化できる。コードも設計もプロセスも、GitにもWikiにも全部残す。それを見れば誰でも再現できる。
プロはノイズを切って最適化する。リモートはそのための手段だ。
「10年目だから偉い」とか「オフィスで働いてるから正しい」とか、そんな時代は終わった。
結果を出してから物を言え。
自分の経験だとこっちがどんだけ骨折ってもダメな人はいると思ってるけど、こいつダメだなって言えるのは本当に骨を折りまくった人だけだとも思ってる
その新人に対してはナレッジも含めて網羅してるドキュメントかレクチャーの動画を渡して数ヶ月様子見てダメだったら諦めてもいいと思う
レクチャーのなかでAIを実際に使って「この課題をこうすればこうなるから、こういう面便利だよ」とかを教えて、その様子を動画撮っていて参照できるようにしとくとかね
逆にそういうのをしてなくて口頭とかOJTでやってるんなら教える側の努力不足と思う
しっかり面倒見てあげてほしいな
あと今までどの職場でも入社してすぐシゴデキ判定もらってIQ130以上の俺でも、入社直後は異業種や異職種だと簡単な内容でも頭に入りにくかったし記憶も抜けが多かった
お疲れ様。
これだけだとなんとも言えないけど…
直近転職したアラフォー（マネージメント経験済）が平社員で入社して困ってることは…
だから上長、先輩がコイツは何ができなくて何ができるのか把握してない
放置、投げっぱに近い状況でこっちから都度質問しないといけない
質問すべきなのかの判断自体も知識不足でしにくいから自分のミスリスクが高くてストレス
とか。
あと個人的には業務背景とか例外、禁止事項は最初から都度説明したほうがいいと思う。
コイツ記憶力いいんか？理解力高いんか？とかのベンチマークにもなる。
増田の例で言うと「例外はそのときまた説明する」とかは自分が言われたら嫌だなあ。
自分が理解力とか記憶力褒められること多いからってのもあるかもしれないけど、知識は先にインプットしまくっておきたい。
ミスに寛容な組織であってもミスなんてしないほうがいいもんと思うし。
お気持ちでした
本気か？ (-_-)
いや、「ちゃんとしたドキュメント」「構造化されたドキュメント」「メンテナンスされ続けるドキュメント」であるならありだと思うが、もしそれが存在するならAIに手助けしてもらわんでも、ナレッジ化は容易だと思う。
何がどこにあるかわからん。
ってなるから、こんなことを言い始めるわけだろ？
でも、「Garbage in,garbageout」ってのが常識な訳でさ。
AIでうまくやれるから、ってんでドキュメントの質もさらに下がっていくって未来は容易に想像がつく。
なぜちゃんとドキュメントを書くのか、って言えば、「思考や仕組みをちゃんと構造化するため」な訳で、この力を養わんでなぜ仕事ができるようになるとか考えてるのか、全く理解できん。
現時点ですら、誰に、何を伝えるための文書なのか全く理解できない、「お前、これ、ただの自分専用の備忘録じゃねぇか」ってドキュメントに溢れてるってのに。
ビジネスの場で「〜を共有します」という言い回しが頻繁に使われる。だが、どうにも違和感を覚えてしまう。
「共有」という言葉には、本来「知っておくと役立つ」「知っていて損はない」といった程度の情報をみんなで持ち合う、というニュアンスがあると思う。
ところが最近では、明らかに必須の連絡事項や報告事項にまで「共有します」が使われている。
「会議の日程を共有します」「売上を共有します」と言われると、なぜか軽々しく聞こえるのだ。
必要不可欠な情報なら「ご連絡します」「ご報告します」でよいはずで、
そこに「共有」という柔らかい言葉を当てはめると、「知っておくといいよ、判断は任せるけど」と言われているように感じる。
もちろん、言葉は多数派が使えば「正しい」とされていくものだ。
だから「共有＝報告・連絡」という用法が広がっている今、違和感を持つほうが古い感覚なのだろう。
今後長期にわたって通用する「AIの実用・活用・応用スキル」を磨くには、
テクノロジーの進化に左右されにくい“原理原則”と“実務への橋渡し能力”に注力すべきです。
⸻
●ユースケース発掘・再構築力
●AIツールの横断的知識（NotionAI、ChatGPT、Runway、GitHub Copilotなど）
⸻
● 軽量なデータ分析（Excel +Python + ChatGPT）
⸻
⸻
| フェーズ | やること |
| ①習熟 | ・ChatGPTの活用法（表形式出力、要約、コード生成）を極める・各業務に1つずつAIタスクを試す |
| ②応用 | ・業務や趣味の中で「AIにやらせたタスク」をログとして蓄積・ツールを使い分ける力を磨く（例：翻訳はDeepL、校正はChatGPTなど） |
| ③発信 | ・実践例をブログやSNSで発信（反応が学びになる）・他者の活用事例をフィードバックとともに評価する |
| ④導入補助 | ・他人にAIツールの使い方を教える・PoC（概念実証）をサポートすることで思考を外化 |
⸻
先日のミーティングで「たたき台」という用語を用いられておりましたが、若手メンバーから「これは何のフェーズのアウトプットですか？」というリプライが多数寄せられており、ナレッジギャップが顕在化しております。
おそらく「たたき台」とは、アジャイルでいうMVPのプロトタイピング的なポジションの資料かとシンキングしておりますが、認識のコンセンサスが取りきれていません。
このままだとアライメントが弱く、エンゲージメントが低下するリスクがあります。現状、スプリントのバックログにもインプットされておらず、ステークホルダーのプライオリティマップにも未登載なので、リソースアロケーションの観点からもNoGoです。
セルフのアナルデベロップメントプロジェクトにアサインされた当初、私は正直、ミッションのスコープがあまりにもアンビギュアスで、コンセンサス形成に時間がかかることを危惧しておりました。しかしながら、ワークショップ形式でのブレインストーミングを複数回実施し、アサンプションの洗い出しからペインポイントの可視化までをワンストップで対応することにより、当該プロジェクトのコアバリューが徐々にクリスタライズされてきました。
ファシリテーションの観点から言えば、イニシアチブを自ら取り、レバレッジの効いたリソース配分を意識することで、タスクフォース全体のシナジーを最大化できたと自負しております。また、KPIベースでのセルフモニタリングを徹底することで、アジャイルな改善サイクルを回しながら、想定以上のインパクトをクイックウィンとしてデリバーできました。
一方で、アナル領域という極めてセンシティブなフィールドにおいては、ユーザーエクスペリエンス（UX）を損なわずにデベロップメントを加速させるには、サステナブルかつインクルーシブなアプローチが不可欠であると再認識いたしました。従来のウォーターフォールモデルでは対応しきれないフェーズに突入したため、ここでは敢えてデザインシンキングを導入し、ヒューマンセンタードなパースペクティブでのアプローチにピボットする判断をいたしました。
最終的には、全ステークホルダーがアラインし、全社的なコンセンサスのもとで、当該プロジェクトをクローズすることができました。今後はナレッジを水平展開し、ベストプラクティスとしてイントラにドキュメント化する予定です。
正確には退職を告げただから、ちょっと違うかもだけど、思っている愚痴をここに吐き出しておく。
一応、業界業種が特定されない範囲で書くように気をつけている。
半ば言い訳だ。自分が悪かったとも反省はしている、というのが前提だ。
中には30時くらいまで残業するような人もいるレベルだったが、そういったコアな部分の人員はなかなか補充されなかった。
前提知識が法律・業界・業務それぞれで必要になるため、補充される人員の要件が高くなりすぎていた。
感覚的には「飲食店を一人で立ち上げて、5年以内に複数店舗を開店させ、全店で黒字を達成している」ことを雇用の必須条件にしているような感じ。
そらいるだろうけど、おらんやろ、という難易度だった。
だからこそ今居る人材でやりくりする必要があるのだが、今いる人材も決して暇な訳ではなく、ずっと働き続けていたので、資料は議事録にもあるけど、一番はそれぞれの頭の中、になっていて、手を動かしてコトをなすためには、その人を連れてくる必要がある構造だった。
いわゆる属人化の極みである。
だからこそ、誰かが欠けるとそこのナレッジが組織として削られるのでめっちゃ困るわけだ。
だが、そういったことは幹部目線にはなく、とにかく全員が「コトを成す」コトしか考えられない状態が長く続いた。
・待遇が上がらない
新規事業というのは成功するかどうかわからない博打のようなものだ。
それ故に、ほぼ全員が失敗したときに逃げ場があるような組織構成になっていた。他の部署との兼務だったりするわけだ。（50:50の人もいれば30:70,100:0と配分は人によってまちまち。運が悪いと100:100になっていた）
そうなると何が起きるのかというと、（まだ）成功しているわけではないから、仕事はしたとしても評価ができるわけがなくなる。
業績がまだ0の状態だからだ。その点では、業績評価は0になるし、だからといってチーム内で頑張った人を評価するかというとそうではない。
ちなみに管理職以上は役職を兼務していると、兼務的でも手当が重複でもらえるので、役職者にとっては兼務するだけ給料があがる構造だった。
そういう意味では、役職者は得（なお業務量は考慮しない）だが、平社員にとっては得するところはなかった。
・頑張りは評価されなかった
先に結論から言うと、評価されなくて当然で、平社員としては優秀、という評価しかならない働き方をしていたところに非があった。
新規事業というのはリスクもあるが、社会的意義がある新規事業だとモチベーションがあがる。
自分にとっては、かなり興味も意義も感じられる事業だったので、自ら手をあげて事業にジョインした。
当時は特に人手が足りなかったので、何から何までやる必要があった。営業なのに総務も経理も企画もやる、そんな感じだ。
全部が全部、人手不足だったが為に、お人好しで手を広げていくことになった。
当然、業務量はあがり、兼務することになり、色々なことを知っている、いわゆる動くwikipediaか動くchatGPTみたいな存在になっていた。
なんでも知っている。なんでもゴールへの持っていく手順を分かっている。
お人好しが過ぎたのだ。
こうなると何が起きるかというとありとあらゆる会議に呼ばれるようになり、自分の作業時間を確保することができなくなっていった。
組織全体としては意思決定、事業推進するための必要な人材ではあったが、個人の目標達成の観点でいえば、パフォーマンスは落ちた。
あらゆることをやっていた、手を出していたので、それぞれを推進すること自体は別の人にお願いするようになっていった。
そうなると、マネジメント、リーダーシップを発揮しているわけではない、という評価になるため、昇進もしづらい状況になった。
当然である。
自分が自分の管理職(マネージャー)だったとしても同じ評価を下す。
めっちゃ意欲的に働いてくれるけど、リーダーシップは発揮していない。だからこと評価しきれない。平社員としては頑張っているよね止まりである。
補足だが、人事評価上は決して悪くなかった。半年に一回の人事評価は100点満点換算するとここ数年80点以下を取っていないし、直近1年は100点だった。
しいていうなら、そういう状況である、というのは数年単位で言い続けていたのだが、人員が補充されることはなかった。兼務が外れることはなかった。
自分の立ち回りとして、色々外していくということもできたかもしれないが、それをさせてくれる環境ではなかった。
現職場で評価されないのであれば、評価されるところに異動するのが一番だ。
会社外の話として、自分のキャリアパスを考えたときに、分岐点に立っているという自覚があったので、そういう意味でもちょうどよかった。
今は終身雇用の時代ではない。転職や副業・兼業と働き方を自分で選び築き上げていくことができる。
その反省として、仕事においてお人好しになるのはいいかもしれないが、自分が評価される範疇を超えるかどうかは検討するしてから手を出す出さないを決めるようにしたい。
