00:08
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、いろんな技術についての情報を、雑談形式で発信していきたいと思います。
僕も元数学者なので、3月14日というと、円周率の日ですね。
なんですけど、3月14日の朝1時51分ですよね。全然起きてないです。爆睡してました。
世界的に、円周率の日で、円周率のコミュニティとか海外にたくさんあって、そこでお祭りとかお祝いしてる気はしますけど、ちょっと後でそれはググろうと思います。
今日ですけども、引き続き徳丸本を読んでます。
SKLインジェクションのお話を、ちょっとチャッと読むところがあって、2週目なのに全然覚えてないなっていうので、やばいやばいと思いながら試験勉強してるんですけど。
インジェクションの話をしようと思ったんですが、あまりにも浅いのでやめといて、今日はブラックボックスと利便性の話を、最近思うところがあって話しようかなと思ってます。
といっても、今からしゃべりながらいろいろまとめるので、これみたいな意見があるわけではないですけど。
で、さておきなんだっけ。
セキュリティの勉強をしてるからっていうのもありますけど、いろんなものがSaaSとして便利になってきてます。
お金さえ払っていけば、専門家ではないですけど、知識なかったとしても、それを導入することで、この分野、この方面に関する対策とか体制は作れるようになってますというのはあるんですが、
それに頼るのはいいんですけど、頼れば頼るほど、中身を知らないとか仕組みがどうたらっていうのを分かってないまま使うことも本当に多いと思って。
便利とブラックボックスが増すということは、その分リスクも上がるし、何かが起こったり、そこから出てきた出力されたログを見て、これが何っていうのを理解できなかったりすると、
それはそれで本末転倒だなっていうところがあって、とても難しい話ではあります。
利便性というか、むしろ再現性の方が良くて、再現性が高いということは、他の人でも対応できたり、
自分でない専門の人じゃないとしても、少なくとも進めることはできるというようなことが再現性にはあると思いますが、
中身が分からない再現性っていうのは果たしてどうなんだろうっていうのが感じていて、
でもじゃあ全部を理解して物事を進めるってそれは現実的ではないですし、何々センサーと思ってて、
それこそ依存度が高い仕事の進め方にはなるので、
どこまで便利にしてインターフェースだけを提供してその中身を知らなくてよいのかっていうのは、
プログラマーとしてはよくあるお話だよなと思ってます。
特にオブジェクト思考をやってると、本当にその辺は出てくるかなと思ってて。
最近は僕はフロントエンドの開発者なので、タイプスクリプトができていろんなものがしっかり型定義されたおかげで、
分からなくても関数ジャンプとか型定義にジャンプしてしまえば見ることができるんで、
03:01
これでだいぶ透明性が上がったから、書いてなくても開発者としてはツールが解決してくれたっていうのはもちろんありますけど、
とはいえブラックボックスを増すということはこういうリスクが上がるよなっていうのはつくづく感じていたりはします。
自分が専門分野じゃないけどやらなきゃいけないものであればあるほど余計にこれは加速するんだろうなっていうのもあって、
そもそも触れないっていう可能性ももちろんありますけど。
お金に余裕があるんだったらそういう自分が専門じゃないところとか知識がないところを利便性を上げるんじゃなくて、
もう外部委託をしてしまう。いわゆるお金で解決ですね。
これは一つの選択肢としてもちろんありますし、それでうまく回ればいいのかもしれないですけど、
スケールするとかパフォーマンスを上げるっていう観点になった時、自社の人じゃないところに委託をしているので、
対会社間のスピード感になるので、絶対下がるよねスピードは。ベロシティーそんな出ないでしょ。
そこの辺も難しいなと思ったりしてます。
セキュリティとテスターをやってたからブラックボックスというキーワードは結構僕は反応しやすいんですけど、
ブラックボックステストもあるし、ホワイトリストテストもあったりはしますけど、
ブラックボックスのままテストをするってやっぱ一度開発者側にもなってしまったせいというかおかげというか、
持った視点があるので、ブラックボックスのまま進めるっていうことに対する気持ち悪さは絶対的にあるんですよね。
昔は分からなくても良いし、例えば僕よく例に出すのはテレビですね。
テレビって僕ら中の回路構造とかどうなってるとかボタンを押した時の内部処理とか全然知らないですけど、
押せばとりあえずテレビがつくし、電源が入って、ネットワークとかちゃんと繋いでるんであればそこで、
あとはチャンネルさえリモコンでポチポチ押して変えれば、チャンネル変えて見たいものができたり音量調整もできたりとか、
僕らはそういうのを知ってはいます。
そこまでインターフェースだけを提供してあって、中身のブラックボックスはそのままでいいでしょうっていう話はあるし、
テレビのテストをしろって言われたら割りかしやりやすいと思うんですよね。
異常のテストってどこまでやるかっていうのは難しいと思って、
中身ある程度知ってる人ではないと表層だけのテストしかできないので、そこのバランス感は難しいなと思ったりはしますね。
実際に中身の方は別知らなくてよくて、とにかく使えること。
エラーが起きた時に何かしらの画面に映ったりとか何かしらの反応があって、
いっぱいユーザーの人たちはここに問い合わせをすればいいとか、こういう手順を踏めば復活するかもしれないみたいなのが、
マニュアルにもしかしたら書いてあるかもしれないですけど、
いうのがわかればいいんですけど、そうじゃない場合はブラックボックステストっていうのはかなりリスクしかないよなっていうのをすごく感じておりますね。
テストの観点でいくと、狙った通り動かないテストはあるのに正常通り動かしていったはずが予想もしない結果になるってよくある話ではあるんで、
06:03
テストケースをどこまでやるかってまた難しい話もありますが、
とにかくブラックボックスで物事を進めることのリスクと、
バランスですよね、ビジネス的な観点でのバランスをどうとるかっていうのが、
割と僕はまだまだ関心が強くて、
今も新しいプロジェクトに入ってるんですけど、
情報量が多すぎてブラックボックスではないはずなんですけど、
全部が透明で情報量が多すぎると人間の脳が死に始めて、
なんだかんだブラックボックスを生み出しているなっていう感があります。
厳密にはブラックボックスではないんですけど、
単なる情報のオーバーフローだけなんですけど、
整理されてないと結局人間として把握してません、
もしくは知りませんと同じ状況を生み出しているってことを試みすると、
全てが透明で全てをテキストにガッと書き起こしてあることって、
それはそれでまた違うなっていうのはすごく今感じてます。
で、前の配信ではしゃべりましたと思うんですけど、
ドキュメントの陳腐化というか、鮮度ってあると思ってて、
だいぶ前に作ったドキュメント、もしくは議事録とかテンプレートみたいなものが、
今もそれが使えるとか鮮度高く生きているかっていうと、
そういう話はぶっちゃけないと思ってます。聞いたこともそんなにないですね。
定期的にちゃんとドキュメントそのもののメンテナーも必要ですし、
そういうことをしていかないと、
新しく入った人がオンボーディングすごく大変だよなっていうのは、
今まさに僕がオンボーディング受けてる身であるので、
大変だなと思う感じではいますので。
そういう状況だと、ブラックボックスではないけど、
ドキュメントブラックボックス感があるので、
例えば1回ドキュメントブラックボックスと呼びますけど、
その場合は利便性を上げるためには、
ドキュメントのインデックスをしっかり張るとか、
ポータル的なページをちゃんと作っておく。
そこのメンテナースをちゃんとしておくとかですね。
リンクたどって3度たどれますねとか目的のページ行きますねとか、
検索性をしっかり上げておくとこも大事ですよねみたいなところです。
やっておくのはすごく大事で、
やっぱりドキュメントエンジニア、
エンジニアじゃなくてもいいですけど、
エンジニアだったら割とちゃんと構造化をしてくれたり、
便利な構成を考えたりとか、
便利なアクセスの仕方を考えてくれたりする可能性があるので、
エンジニアが本職として
ドキュメンテーションのメンテナンスとか構造を考えてくれるっていうのは、
僕ちゃんと職としてありだと思ってるんですよね。
今はノーション使ってる会社さんがだいぶ増えていますし、
ノーションAIを使えば、
AIに聞いてしまえば出てくるっていう可能性もあるので、
そんなに構成をしなくて、むしろ情報量を出しておくことの方が
よっぽろ大事っていうのはもちろんありますけど、
ただAIは結局ある情報を送って、
そこから考えて、僕らの欲しいもの多分これだろってやってくれるので、
情報が多すぎると雑音も増えるので、検索性結局は下がるので、
なんだかんだ最後は人間がドキュメントをちゃんと整備することって
どっかしら重要だよなっていうのは僕は思ったりします。
09:00
人間は楽をしようとする生き物なので、
便利なツールとか技術があればそれに依存はするんですけど、
便利すぎるものに依存して人間が脳死でわちゃわちゃやると、
基本的にはカオスを生み出してしまう。
ここはよろしくないよなっていうのを感じはしますね。
とにかくブラックボックスは意識をしようと思ったら
なかなか意識できないんですよね。
気づいたらそうなってましたの話が多いんで。
気づけてるっていうことはすごく重要で、
じゃあ気づいたからどうしますっていうのを議論することは大事で、
そこまま気づかないままずっと言ってて、
不細が山になったときに初めて目で隠すことすらできなくなるみたいな話がよくあると思う。
今まで僕も何案件かやってきましたけど、
ノーションがすごく便利すぎて、
ノーションにとりあえずメモを残すと。
とにかくメモマーな人が、
ユメミはちょっと多かったかな。
そりゃいい話であって。
メモしていただくのはいいんですけど、
情報型だったり、
重複する情報がたくさんその辺に散りばめられていて、
この人とこの人同じことを実は言ってたし、
同じことを考えてたけど、
それも一緒にいわゆるペアプロしながら考えたほうが話は早かったよねっていうんですけど、
二方向で考えていてその時間がちょっともったいなかったなって話もあったりするんで。
いかにブラックボックスを下げるかっていうのはすごく大事だと思ってます。
これはプログラミングの話もそうし、
今ドキュメンテーションの話もそうし、
システムの設計構成の話もそうだと思いますけど。
アクセスのしやすさとか透明性はもちろん求めますが、
透明すぎると情報型っていうのはやっぱあるので、
バランスは考えつつ、
ちゃんとインデックスをしっかり整備するっていうのが
とりあえず落としどころなんじゃないかなって気はします。
特番の試験が3月16日受験なので、
もうマジで今ギリギリでやばいんですけど、
まあしっかり頑張って読み切って試験受けていこうかなと思ってます。
まあ落ちたら落ちたで自分の実力がないってことを自覚して
改めてやり直そうかなと思ってますし、
自腹で再度受け直そうかなと思ってますけど、
まあ引き続きセキュリティの勉強はし続けていきたいかなと思ってます。
まあ発信はしながら、
だいたいセキュリティクラフターの人たちは
つよつよの人が多いので、
間違ったことを言うとボロっかすに言われるんですけど、
それは僕の勉強になるので、
まあメンタル強く間違ったら発信をして、
で間違ってたらちゃんと記事内を訂正して、
もしくは全部書き直しをしてアップロードすると思いますけどね。
こういうのはチャレンジしないと絶対身につかないと思いますのでね。
今後も頑張っていきたいと思います。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
