AIがあれば技術力より良い性格のほうが強い説に対する違和感
最近Xを見ていると「開発自体はコーディングAgentで出来るから今後は技術力より良い奴であることが重要」みたいな投稿をちょくちょく見る
これのニュアンスとしては、「技術力は高いが気難しいエンジニア」と「技術力はそこそこだが接しやすいエンジニア」がいた時にコーディングAgentが無い時代であれば、ある程度難易度の高いタスクは前者のエンジニアに投げざるを得なかった。しかし、コーディングAgentがあると後者のエンジニアにもタスクを投げることはできるので結果的に技術力より良い奴であることが重要と言われているのかなと思う。
※全然そんなニュアンスではないや、それは釣りだよという場合はすいません。
少し話はズレますが、最近Anthropic主催のOpus 4.6ハッカソンでソフトウェアは非専門家の弁護士が優勝したこともあり、技術力の重要性が低いとなっているのかと思う。
僕自身、最近の実装自体はコーディングAgentで書くことがほとんどなので実装力に関しては僕とジュニアエンジニアを比較してもそこまで変わらないんだろうと思う。
特に、そこそこ書いたことはあるがそこまで得意ではないフロントエンドのコードとかであればほぼほぼ変わらない自覚はある。
しかし次の2点は違うんだろうと思う
- 開発したシステムをリリースしても良いという判断
- ここで言う判断は、UI/UXよりは仕様や非機能要件が問題ないという意味での判断
- コーディングエージェントの効率
- システム開発のゴールをドキュメント化しコーディングAgentをより自律的に動かす技術
- E2E、静的型付けを行いコーディングAgentに自動で修正させるためにリッチな情報を渡すテクニック
これらは、コーディングAgentが無い時代かつ信頼がない状態であれば上記のことを行うことは気難しいエンジニアと言われる可能性はあると思う。
例えば
- 自動テストの浸透していない組織に対して自動テストの重要性を伝えても工数を増やすやつと思われたり
- 実装を急ぎがゆえに口頭でゴールを伝える組織に対して、認識の齟齬をなくすためにドキュメント化を進めたいと伝えると面倒と思われたり
シンプルに仕事に意欲がないがゆえに気難しいというわけではなく、 正しいことだがメリットが手間を上回るまでの時間がかかるようなことを進めるエンジニアも同じ様に気難しいと思われる可能性がある。
しかし、コーディングAgentが現れると速度感が変わりメリットが手間を上回る時間が誤差レベルになり、正しいが気難しいエンジニアは、コーディングAgentを使いこなし生産性がより高いエンジニアになることもあるかと思っている。
ドメイン知識について
エンジニアリング以外の業界でもエンジニアリング的な思考能力は必要なんだろうとも思う。 ここでいうエンジニアリング的な思考能力というのは、タスクをAI Agentが実行・検証できる粒度に分解する能力を指しています。
※エンジニアだけができるのではなく、僕がエンジニアとして重要な能力だと思っているため例と出しています
動画編集チェックをする例（※解像度が低くいし、間違っている可能性はありますが）
- 話に矛盾はないか？
- 場面展開時にノイズが入っていないか？
等の作業チェックリストレベルから
- 世の中の流行に沿っているか？
- コンプラインス的に問題はないか？
等の大枠レベルのチェックリストを チェックする人が明文化できるとそれをAI Agentに与えるとより自律的に動かすことができます。
「動画編集チェックできる」だけでなく、「動画編集チェックとは何をやればよいのかの明文化」という1つ抽象度が高いタスクをこなすことができる人がエンジニアに限らずAI Agent時代に活躍できるのかなと思います。
これらを思ったきっかけ
ハーネスエンジニアリングやループエンジニアリングについての記事を読んで、エンジニアはより難しい課題を解決していかないといけない世界になるよなーという考えを発散するために書きました
転職して1年経ったので振り返ってみる
去年の8月に転職してから約1年がたったのでどんな1年だったか振り返ってみようと思います。
普段1年の振り返りとかやらないのでどういう軸で振り返っていくか迷いましたが、 転職先はAI系の受託をメインとしている会社のためプロジェクト単位で振り返っていきます。
顧客情報やプロジェクト内容についてはかなりぼやかしています。
8~12月
入社して最初の携わった案件は製造業のクライアントで、案件内容としてはクライアント先に導入されている外観検査システムのパラメータの自動チューニングでした。 僕が入社する前にパラメータの自動チューニングのアルゴリズム自体はすでに検証が完了し、これからシステム化するというところでアサインされました。 クラウドはAWSで、システムの構成としてはざっくり
の3つとなっており、僕はその中でも「アノテーションUI」「コントローラ」を担当しました。 使用技術としてはアノテーションUIはVue.js、コントローラはPython/Djangoとなっております。
前職ではGCPを使っていたためAWSは慣れておらず権限周りやS3やAPI Gateway、Lambdaとかの使い方や制約に苦戦していました。 また、Djangoもほぼ使ったことなかったため最初はDjangoに精通した同僚のエンジニアに質問しながら進めていったのを覚えています。 余談ですが、restframeworkとlocalstackってかなり便利ですね。
技術面でも慣れないことがたくさんあって大変でしたが、一番理解に時間がかかったのは「クライアント先に導入されている外観検査システム」の仕組みの理解でした。 自動チューニングシステムを実装していく上で「クライアント先に導入されている外観検査システム」を理解していないとおかしな実装になってしまうため、深く理解している同僚のエンジニアに何度も質問しまくっていました。
8月下旬〜9月
上の案件とは並行で製造業の異常検知の案件をメインで担当させてもらいました。 問題内容をざっくり言うと、正常であれば10個セットで入って次工程にいくが、何らかの問題で9個以下まま次工程にいってしまう異常ケースを画像から自動検知したいというものでした。
この案件では異常検知を行うための画像は無かったため製造ラインを撮影してデータセットを作成するところから始まりました。 製造ラインを撮影するためのカメラ選定も先方の方と一緒に「撮影の高さは最大○○cmぐらいだから、この△△度以上の視野角があるカメラじゃないと難しい」みたいなことをSlackで会話しながら決めていきました。先方の方もエンジニアの方（しかも元高専生）だったため、かなり意思疎通はスムーズに進めることができました（むしろ助けてもらってた）。
製造ラインを撮影してデータセットを作成した後はアノテーションをしていきますがココもけっこう大変でした。 アノテーション自体は、ちゃんと10個セットになっていたら正常、9個以下だったら異常と判断するだけと難易度的には低いため、僕含め社内の人の3人で同じデータセットをアノテーションを進めていきました。
僕は初め難易度の低いアノテーションだから3人ともほぼ同じ結果となると思っていましたが、結果を見ると3人とも結構な数の異常を見逃してしまう結果となっていました。 アノテーション精度が低いと最終精度に意味を持たなくなってしまうため、アノテーションする人を外部にもお願いしアノテーションの質を高めることをしました。
アノテーションが終わってやっと、画像処理段階に入っていきます。 画像処理の手法としてはデータセットも豊富だったためCNNで進めていきました。 DeepLearningを使った画像処理はほぼやったことなかったため同僚のエンジニアに質問や手伝ってもらいながら実装を進めていった結果、 問題自体の難易度の低さとアノテーションの質の高さもあり結構良い精度のモデルを作ることができました。
11月
3つ目の案件はシステム開発でした。1つ目の案件とは違って0から作り上げていく担当ではなくすでに出来上がっているシステムの不具合の改修がメインでした。Python/Djangoで開発されていて、初めの案件の経験のおかげでフレームワーク自体には慣れていたのですが、システムの全体像を把握するのが大変でした。仕様書や設計書を見たり、テストを見たりして全体像を把握しつつissueに上がっている不具合の修正をやっていました。
不具合の改修がメインのこともあり
- 不具合について調査
- 不具合が再現するテストコードを追加
- テストコードを通すようにコードを修正
- p-r投げてマージ
のループが綺麗に回せていたので個人的には気持ちよく進めることができた案件でした。
1~4月
4つ目は動画に映っている人が所定の動作をしているかを検知する案件をメインで担当させてもらいました。 2つ目の案件と同じ様にこの案件もデータが無かったため、撮影してデータセットを作成する所から始まりました。 この案件ではモデルを開発し、開発したモデルをサーバではなく「Android上で動作させる」必要があったためかなり大変でした。
検知する動作が複合的な要素を持っていたため、モデルは1つのDeepLearningで完結させるやつではなくPoseNet等の複数のモデルを使用して特徴量を生成し 生成した特徴量をLightGBMで分類するというやり方で進めていきました。
開発したモデルをAndroid上で動作させるために必要な要素としては以下のものがありました
- 動画を画像にデコード
- DeepLearning系のモデルをTensorflow Lite形式にコンバート
- LightGBMをAndroidで動かす
また、速度面やLightGBMにC++のAPIが存在していこともあり、Android NDKを使ってC++で開発していきました。
やっぱり初めてやることには想定外の問題が起きてしまうもので、 TensorFlow Lite形式にコンバートしたモデルはTensorFlow Liteの標準オペレーション以外が使われていたため実行時にエラーが起きてしまったり、 LightGBMはAndroidで使われているlibcがglibcではなくbionic libcとなっているためエラーが出たりと大変な開発でした。
5月~
今年の5月からは去年の11月にやっていたシステム開発に再度アサインされました。 やることは前回と同様バグ改修にプラスして、高速化や負荷テストを進めています。
最初にやった高速化の時は、プロファイルをしてボトルネックを見つけるところから始めていき、 DBのアクセスがボトルネックだったのが分かったためRedisにキャッシュするようにコードを変更し、変更によって問題が起きないかのテストコードを書いていくことをしていきました。
また、タスクが投げられたわけではないですが、dictでこねくり回しているようなところをデータクラスに置き換えたり、コピペをしているのかテストの前処理に似たようなコードが量産されていたのでfixtureに置き換えたり等のリファクタリングをしたりしてます。
まとめ
最初の1年は画像処理をやったりシステム開発をやったりAndroid NDKと戦ったりと自力を試される充実した1年でした。 特にAndroid NDKみたいな低レイヤーと戦っている時は、学生時代にちゃんとC言語を学んでてよかったという場面があったため過去の自分を褒めたいです。
今年はコロナの影響で会社として仕事が減るかもしれないという懸念がありましたが、 逆に仕事が多くて大変みたいな状況なので去年以上に会社に貢献していこうと思います。
「10年戦えるデータ分析入門」の感想
こんにちはgoya813です。
最近データエンジニア的な仕事をやるようになって、色々情報収集していたらクックパッドの青木峰郎さんの
スライド「DWHに必要なこと〜１人で始めるCIO〜」を見つけ、そちらで紹介されていた本書に興味を持ち読み始めました。
著者について
著者の青木峰郎さんは現在はクックパッドに所属しており、ビッグデータ分析システム「たべみる」のアーキテクチャ設計から開発などをおこなっています。
本書以外にも「ふつうの〜」シリーズの本を出版されていたり、OSS界隈でも元Rubyコミッターであったりと幅広い分野で活躍されている方です。
要約
本書はSQLを使ったデータ分析と、そのためのデータ分析基盤構築について書かれた本です。
本の内容としては２部構成になっており
1部はプランナー向けにSQLというのはどういうものか、なぜ良いの、どうやって使うのかについて。
2部はエンジニア向けにデータ分析基盤の構築・運用方法についてとなっています。
印象に残った章
今回は特に印象に残った第8章と第11章、第13章について感想を書いていきます。
第8章
第8章は「ウィンドウ関数」について書かれている章です。 本書の中ではウィンドウ関数について
ウィンドウ関数（window function）は「分析関数」とも呼ばれる関数です。 たいへんざっくり言うと、group by節で作ったグループの中の行を見ながら、集約せずに計算することができます。
と説明しています。著者も「これだけだとまったく分からない」と書いていましたが、 僕も正直最初はまったく分からず、これがなんで分析関数と呼ばれるのだろうと思っていました。
しかし、この後にウィンドウ関数を使った「デシル分析」「時系列データの処理」などの具体的な例をクエリ交えての説明されており、そちらを読んでいくにつれて
- なぜウィンドウ関数が分析関数と呼ばれるのか
- なぜSQLでデータ分析をやるのか
がわかる章でした。
第11章
第11章は「データ分析基盤構築」について書かれている章です。
最近業務で「DWH」「データマート」という単語をよく聞くのですが、人によって違う認識を持っており、「何が正確なんだ！」と頭を悩ましていました。
そんな「DWH」「データマート」について本書では歴史と重要なポイントがまとめられているためとてもスッキリしました。
第2部は比較的エンジニア向けの内容となっていますが、個人的には第11章はエンジニアだけじゃなくプランナーの方にも読んでいただきたい章でした。
第13章
第13章は「SQLのバッチを作成するための仕組み」について書かれた章です。
僕も最近OLTPのRDBに溜まったデータを分析しやすい形に整形する仕事をやっていたので、まさに必要としていた情報でした。
データ整形をSQLでやる上での重要な考え方から、実際にどうやるのか、管理する為のソフトウェアについてなど全体をカバーしていたのでとても勉強になりました。
また
- データを整形する際のクエリは細かく分解
- 冪等性を持ったクエリにする
など、こうしたほうがいいだろうなと思ったことも書かれており、 自分の考えは悪くなかったんだなと安心できてよかったです。
SQLのテストもまさにどうしようかなと思っていたところだったので、 実際に設計・開発をする際に参考となる章でした。
最後に
本書はSQLを使ったデータ分析や基盤構築について深く書いているというよりは、なぜSQLなのか、データ分析の全体像はどうなるのかが多く書かれています。そのため、エンジニアとプランナー間の共通認識として活用できる本なのかなと感じました。
10年戦えるデータ分析入門 SQLを武器にデータ活用時代を生き抜く (Informatics &IDEA)
- 作者: 青木峰郎
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2015/06/30
- メディア: 単行本
- この商品を含むブログ (6件) を見る
RaspberryPiでパトランプを光らしてみた
北海道楽しかった！
初めに
- 今日まで北海道で生活をしていた老害OBです。
m教授からのお願いがあったため ICT Advent Calendar 2015の25日目を書きたいと思います。
(今日予定入ってないの？ 等の質問は却下とします)
社会人はブラックなのか？
- 皆さんはネットなどでブラック企業の記事(やm教授)などを見ているため、 会社に勤めることに不安を持っているのではないかと思います その為今回、老害OBの中でも珍しく進学ではなく就職をおこなった僕が 感じている社会人の良さについて挙げたいと思います。
1. 使えるお金が増える
- これは当たり前ですが大きい違いです。学生時代では外食といえばMacがほとんどだった僕ですが、社会人になってからは少し高い焼肉屋、寿司屋など色々な飲食店でご飯を食べることが出来るようになりました。
2. 新しい知識を吸収できる
- 学生時代でも新しい知識は吸収していました。しかし、会社に勤めると当たり前ですが自分より能力の高い先輩達がほとんどです。また、先輩たちは情報収集能力も高いため常に最新の技術に触れています。そのため、そのような先輩たちと接していると技術者としての基礎的な部分、最新の技術について吸収することができます。
3. 休日が休み
- 学生は休日にレポート作成や研究を行うことも多々あると思いますが、
社会人は平日は働きますが、休日は働かなくても大丈夫です(普通は)。 僕は北海道にいた時は休日に、余市や旭山動物園、クマ牧場、スキーなどたくさん遊びにいきました！
終わりに
- ICTの皆さんはこれからどんどん社会人になっていきますが、 社会人はとても楽しいので、社会人になることを楽しみにしていてください。
kotlinで簡単なアプリを作ってみた
kotlinで簡単なアプリを作ってみた
はじめに
前から使ってみようと思っていたkotlinを使って
今回はTODOアプリっぽいものを作ってみました！！
アプリ画面
予定を入力して登録ボタンを押すとTODOに追加することができます。
また、TODOの右側にある赤い奴を押すと削除ができます。
ソースコード
今回作成したアプリのソースコードは
https://github.com/goya813/TodayTodo
にあります！！
まだ、エミュレータでしか動作テストしていないので動かなかったらすいませんm(-_-)m
所感
まだ、kotlinライクな書き方が全然できてないので精進したいと思います！
参考にした記事
3次元再構成のやり方
3次元再構成
マーカーレスARを行うための技術として3次元再構成というものがあります。今回は3次元再構成について書いていきたいと思います。
3次元再構成とはなにか
3次元再構成を簡単に言うと複数の画像から奥行きを持った3次元データに拡張するという技術です。ここで重要なのが1枚の画像からは3次元再構成はできないという事です。
3次元再構成の原理
三角測量というものが3次元再構成の原理となっています。三角測量というのはある2点間の正確な距離がわかっている場合、測量したい点との距離は、2点との角度が知ることが出来たら、三角形の性質である「三角形の一辺とその両端角が分かれば三角形が確定する」を用いることによって求める事ができます。これを応用することによって3次元再構成を行うことができます。
3次元再構成を行うための要素
3次元再構成を行うためには以下のことをやる必要があります。
1. カメラ間の位置関係の推定
2. 画像間の対応点検出
3. 3次元化
1.のカメラ間の位置関係の推定についてですが、これはある2点間の距離と角度を求めることを指します。これは8点アルゴリズムという手法を用いて推定を行いました
2.の画像間の対応点検出についてですが、これは測量したい点を探すことを意味します。これはSIFT特徴量を用いることによって検出しました。
3.は1,2から測量する点の奥行きを求めることを指します。
実験
- 用意した画像
画像間の対応点検出した図
対応点を3次元再構成した図
- 3次元データを元にAR行った図
まとめ
最後の図を見るとマーカレスARっぽい事ができている事が解ると思います。
参考にした本
この本はとても丁寧に説明しているので初心者でもわかりやすいと思います
Written with StackEdit.
