Qiitaから定期的に好評記事の一覧がメールされてくるわけですが、パラパラっと見ていたら面白い記事が

ウォーターフォールの反省とアジャイルの成功に必要なもの #SIer – Qiita

わかる。

実際に私自身、前職では自社パッケージの開発を行っていて、現在は準委任や請負両方とも関わっていたりするので、言わんとしていることはよく分かる。
そして、携わっていた準委任で参画しているスクラムの案件がそれなりに終りを迎えつつあって、色々と思うところがあったので多少乱雑ではあるけれど書いてみた。
あくまで個人の感想ではあります。

請負で契約に縛られるのは誰なのか

記事では、「問題の原因は請負開発」とあって、そのインセンティブ構造だとかに対して触れられている。

ベンダー側の立場で利益を案件単位での利益を最大化するのであれば、当初契約締結時の仕様を最低限満たすものを、最小の労力で作り上げる事になる。
作りながら「この機能はこういうケースも対応できたほうがいいのでは？」ということに気づいても、当初見積もりからずれる行為であれば事前の要件として明記されていない限りは基本実施しない。
それは、怠慢とかそういうことではなくて、見積もりの前提が崩れ、その見積もりを下に作られているスケジュールからずれ、納期に影響を与える可能性がある。
言い方は悪いが「余計なものを作っていたら間に合いませんでした」って話になりかねないのだ。

残念なところはユーザー側の立場からも話が出ることはある。
RFPのような形で契約を進めていく場合、そのRFP記載内容からズレたことを行おうとした場合にはユーザー側でも承認プロセスを巻き直す必要がある事が多い。
きっちりかっちりした企業・プロジェクトであればなおのこと、「仕様書にかかれているかどうか」を担当者も判断基準にしている。

このあたり、システムに対して明るくない担当者であるケースも多いのでしょうがないところではある。
ユーザー企業側でシステム全てに詳しい人を割り当てることができるのか？とか考え始めると大変だなぁと思うわけです。

請負におけるベンダー側のインセンティブ

すべての開発者がそうだというような性善説を唱えるわけではないけれど、開発者は基本的に良いものを作りたいと考えていると思う（作れるかは別として）。
お蔵入りするためのものを開発なんてしたくないし、大きいシステムや影響の強いシステムを稼働させるのに臆病になることはあっても、やるからにはいいものを作りたい。

先に書いたように、営利企業である限り利益を生まなければならない以上限界はある。
ただ、最低限請負開発を回していると、要件的に問題がなければそれはいいのだが、ユーザ企業側に不満が残る最低限開発だとリピートされるかが怪しい

請負をする以上、案件を取ってくると言うことが必要になるうえで、顧客満足度を高めて、多少高くてもリピートされることをインセンティブにするという考え方になるのかなぁ、と思う。
サスティナブル的な感じだろうか。

内製か外注かの選択

記事でも書かれている、内製化の流れというのは何となく分かる。

一方で、書かれているようにエンジニアを抱える以上、それに付随した組織改革とエンジニアを（数とスキルの両面で）維持する必要が生じてくる。
ベンダーであれば、様々なプロジェクトを通して色々な経験ができる可能性はあるけれど、ユーザ企業の場合は必ずしもそういう環境を提供できる企業ばかりではないと思っている。
このあたりは、ユーザ企業含めて業界の構造がどうなっていくのかは楽しみだ
自社で内製化のために雇用した人材が維持できず、結局は会社対会社でその部分を担保しようとしているのが今だと思っている。

記事では要件が固まっている場合には内製で行うメリットがないとしているが、これに関しては違和感を感じる。

内製でするべきかどうかは、その作るシステムが自社にとって競争優位を生み出すものかどうかなのではないかな、と。
作り上げる時点で何を作るのかの要件が定まっていたとしても、今後、そのシステムを元に戦っていくのであれば自社で抑えておく必要はあるし、その部分を他社に任せてしまうのは良くない。

「要件が固まっている」が”今後変わることがない”という意味であれば別だけど、変わることのないシステムなんてあるのだろうか？と思ってしまうのはエンジニアサイドの視点なのかもしれない。

一方で、要件が固まっていて特に自社の競争優位に大きな影響を与えないシステムに関しては外注を・・・と思ったけれど、よほどのニッチな領域でない限り、パッケージ導入やAI、ローコードツールによる簡易的なものづくりを内製で・・・ってなっていくんだろう。

数年で取り巻く環境は目まぐるしく変わっていくので、身の振り方は常に考えておかないといけないところですね。

いつも楽しみにしているfukabori.fmが更新。
今回は来年二予定されているEMコンフに関しての紹介

122. EMConf JP 2025 w/ dora_e_m | fukabori.fm

ちなみに、11/14現在ではEM Conf JP 2025 のチケット購入は Coming Soon 状態
開催日は2/27ということでまだ結構時間がありますね
平日ということなので仕事を休めれば、行ってみたいところ。

EM。
難しい肩書だと思っています。

プロジェクト、ビジネスのマネジメントではなくエンジニアリングのマネジメントという位置づけ？
多分組織によってどこまでそれが許されるんだろうか？ということとか、そもそもジョブ定義として共通化なんてされていないんだろう。

そもそもの話として、そこまで多い人数のいない組織の場合、そのあたりの区別は曖昧で結局全てをマネジメントしないといけない状態になる認識でいる。
しっかりと役割として分担できるほどの人的にも金銭的にも余裕なんざないのである。

それでも学びは多いはずだし、そういう状態に持っていくことができればいいとは思うので、やさぐれていないで話を聞きに行きたいと思うところ。

スタッフの応募はすでに締め切られてしまっているのであくまで一参加者として。
楽しみであります

忙しいとしか言ってない気がするが、ここのところ忙しい。

忙しい中でもランニングだけは欠かすまいとしているので、必然的に疲れてしまったりなんだりで気が乗らず、自己研鑽として掲げているAWSの勉強がすっかり止まってしまっている。

うーん、SAA資格の有効期限。切れちゃうな。

とはいえ、このままではいけないのでなんとか切り替えなければ、と外部の情報を物色し始めました

Github Universe

GitHub Universe 2024

Githubが主催しているカンファレンスでVirtualであればFreeで参加することができます。
今年はやっぱりAI関連ですかね。

Universe 2024 – Curated Agenda (rainfocus.com)

Githubのカンファレンスは参加したことがありませんでしたが、もしかしたらコードも付いてくるかも？と思うと、テック系としては良い学びになりそうな予感がします。

来週からなので、楽しみです

5-Day Generative AI Intensive

Home (rsvp.withgoogle.com)

Googleが主催しているAI開発向けの5日間のコース。
5日間と言っても、1日あたりは2~3時間を想定しているそうな。

こちらも無料で受講が可能なので、レベル感はちょっとわからないですけれど申し込むだけ申し込んでみようかな？と。

ここのところ怠け気味なので、なんとか奮い立たせてやっていきたいところです

久しぶりにVBAをせこせこと書いているわけですが、関数の概略とかそういうのを全部自力で書くというのは骨の折れるもので、なんとなくの内容をClaudeに教えて関数を作ってもらいます。

当然、そのままでは動くわけもないのでエラーをつぶしていくわけですが、ぱっと見で何が誤っているのかがよくわからないエラーにぶつかりました

Dim tableNames(5)
For i = 1 to 5
    If i > 2 And tableNames(i) <> tableNames(i - 1) Then

ちょっと内容は端折りますが、2つの条件式があった場合に、一般的なプログラミング言語であれば一つ目の条件式評価の結果、以降の条件式を評価する必要がない場合はそもそも評価が実行されないのですよね。

これによって、Nullチェックや配列のインデックス範囲外アクセスを防いだりします。
ところがVBAでは、すべての条件式が評価されるようです。

初めて知りました。。。

何というか、やっぱりVBAは独特だなぁ。。。と

今月号のSoftware DesignはLLM特集
自分で手を動かしながらLLMを用いたアプリケーションを作ってみよう！ということなんだけど、経験上LLMに行き着くまでに挫折しそうな人が多いと感じた。

いわゆる環境構築だ

今回も紙面に環境構築のサンプルというか参考となるコマンドが載っているが、そもそもこれがなんのOS上で構築するためのコードなのかはどこにも説明されていない。

案の定、手元のWindows環境では動作しなかった。。

現場でも、環境構築の手順に関しては手順書が用意されていることが多いが、基本的にそれ通りに行くことを見たことがあまりない。

環境を構築するということは、必要となるライブラリなどを意識するうえでは大事なんだが、それを導入する、大本の環境を統一することが出来なければその先に進むことができなくなることはザラにある。

解決策の一つは、ベースとなる環境を統一してしまうことであり、やはりDockerなのではないかと思っている。

ローカル環境を汚すこともなく、共通の状態からスタートできるわけなので良いはずなんだがなかなかそういう説明をお目にかかれない。

なんとも非合理だ

もちろん、Docker上ではGUIを用いたIDEを動かすことは出来ないので開発環境としては辛いものがあるのは分かるが、せめて紙面のサンプルであればなんとかならんものかと思った。。

頭で気持ちをくじかれると、すごい徒労感が出てしまうんだよね。

GPTもいいのですが、最近はClaudeを使い始めています

Claude

日本語に関して、非常に自然な形での回答が返ってくることもいいのですが、Artifacts機能がなかなか素晴らしい。

簡単なツール作成であれば、それほど労力をかけずに作ることができるかもしれないポテンシャルを持っているように感じます。

ただ、GPTにしてもClaudeにしてもプログラムを書かせてもそれがそのまま動くということはなかなかなく、それなりに分かっている必要が出てしまいます。

Artifacts上で構築させたWebアプリケーションも、そもそもプレビューがエラーとなってしまうことも多々あり、GPTでは作成したコードの実行方法も教えてくれたのですがClaudeは聞かないと答えてくれません。

そして、往々にしてうまくいかないことも。。。
ただ、このあたりはすでにここまでできているのであればあと一歩。
壁を超えてくる日も近そうです。

WindowsとGPTが統合されて、ローカル環境のセットアップを含めて実行してくれるような未来も来るかもしれないと考えると、いよいよ持ってAI全盛期になりそうですね。

一方で、開発者に取って考えてみるとこれが開発の作業になってしまうと、楽ではあるものの開発者冥利に尽きるシーンに出くわすことが少なくなる。

さらに、とりあえずまずはAIに聞いてみると言うのは、スピードで考えれば良いことなのかもしれませんが、頭の中で論理立ててロジックを考えていくという訓練する場を減らすことにつながってしまう。
ローレベルの開発者がスキルアップをするシーンが奪われていくのではないかと要らぬ心配をしてしまいます。

それでも、使うメリットは高いと言わざるを得ないところが難しいですね。
良い付き合いができればいいと思うのですが。