ガリレオは 新宿三丁目駅C4出口直結、徒歩0分 という抜群のアクセスが魅力です。
雨の日でも濡れずにお越しいただけます。

会議室は30名収容可能で、リノベーションされたばかりのビル内にあり、とても清潔で快適な空間です。天井はコンクリート打ちっぱなしのデザインで、シンプルながらもスタイリッシュな雰囲気を演出しています。

さらに、プロジェクターやWi-Fiをはじめ、会議やセミナーに必要な設備を完備。大切な打ち合わせや研修、勉強会など、さまざまな用途にご利用いただけます。

当社はこれまでシステム開発を中心に事業を展開してきましたが、新たな挑戦として貸会議室事業に踏み出しました。ガリレオを通じて、地域の皆さまや企業活動に貢献できる場を提供してまいります。

ご利用のご予約は、以下のサイトから受け付けております。
貸会議室ガリレオ 予約サイトは以下からお願いします。

ぜひ、新宿での会議やイベントに「ガリレオ」をご活用ください。

The post 貸会議室「ガリレオ」オープンのお知らせ first appeared on 株式会社Altus-Five.

ラウンドロビン設計は、3人以上がいる開発で、何かを設計するときに、いったん、全員が各々でラフスケッチをするところから始めて、スケッチを隣の人に回して1回転させて、自分の案との違いを確認し、そこに追加で自分のアイデアを書き加えて、さらに、1回転させて・・・・といくことを繰り返す設計手法です。

自分のアイデアと他の人のアイデアが組み合わさって、1人では考えつかなった設計に変化していって、短時間で洗練させられるようです。
原典なのかは不明だけと、「Design It! ―プログラマーのためのアーキテクティング入門」の第9章”アーキテクチャデザインスタジオを開く”で紹介されています。
この本によると、ワークショップ形式で全員で取り組んで90分で完成させると書かれてます。時間制限を設けることも大事なようです。
90分で終わるなら、普段の開発の中でも、取り入れてもいいかな。
設計レビューも不要だし、チーム内に新人の人が居ると教育にもなるし、良さそうです。
ただ、アイデアが発散したときに収束させるのが厄介かもしれないけど。

ラウンドロビンレビューは、レビューを複数名で、役割分担するのだけど、例えば以下のような役割で分担するとします。

• 仕様面が正しく実装されているかをレビューする役割
• テスタビリティをチェックする役割
• メンテナンス性をチェックする役割
• SOLID原則などの実装合理性や実装デザイン性をチェックする役割

役割をさらに、細かくして、1人複数の役割を分担してもよいと思います。
仕様面のチェックは、DB観点と画面観点で分けても良いし、SOLID原則は、それこそ、S/O/L/I/Dで分けても良いという具合に。
これのよいところは、大きいプルリク全体をマルっとレビューするときの気持ち的な負担が軽くなるように思います。
ただし、レビュー指摘が錯綜する可能性がありそうなので、それは、デメリットの1つかもしれないです。
本来、このラウンドロビンレビューは、役割を強制的に割り当てるので、メンバーのレベルが同程度のときに有効とされるのだけど、レベルが違う人が入っても、2～3回転させるルールにすると、弱いパートが補完されるし、教育観点が加わるので、それアリかもと思いました。
こちらは、WEBで記事を漁っていて見つけたものです。

アイデア出しのフレームワークにブレインライティングというのがありますが、ぐるぐる回すというところが、ちょっと似てるなと思いました。
ブレインライティングもやってみると、ちょっと面白いので、アイデアを量産しないといけない場面があったら、WEBでやり方を検索してみてください。

モブプロもラウンドロビンだし、他にも普段の仕事の中で、”ラウンドロビン○○” してみると良いかもです。

腕を胸の前で糸巻きするように回しながら、「ぐるぐる戦法」と言ってみるのも良いと思います。

The post ぐるぐる戦法 first appeared on 株式会社Altus-Five.

チームのメンバー構成とメンバーのスキルレベルによって、アウトプットできる成果物の量は異なります。 ベテラン1人とキャリア1年目、キャリア3年目の人のチームが目指すべき生産性を、定量的な絶対値で目標設定する場合、 ベテラン3人構成でのアウトプット量を “そうあるべきライン” として目指さないといけないのだろうか？ でも、その目標をクリアできるのは、キャリアの浅い人の成長を待つことになるので、何年か掛かります。 チーム構成は時と場合によって、さまざまなので、絶対的な指標は、あまり機能しないことは、想像に易いと思います。 そもそも絶対値の求め方というか計算式をどうするのかも難解です。

そこで、相対的なベロシティの方が有効となるわけです。 ベテラン1人とキャリア1年目、キャリア3年目で、現在のベロシティは 35 ポイントと出ているなら、 それを維持するか、少し上回るように、目標設定すると、達成感も得られるようになります。

気を付けないといけないのは、ストーリーポイントの見積でのブレでしょうか。 ついつい甘い見積になってしまう傾向のあるチームでも、常に甘い見積を出している場合には、相対的なベロシティは指標となり得ます。 しかし、甘かったり、辛かったりと、毎回見積がブレる場合には、ベロシティもブレるので、見積精度の観測も同時にやった方がよいのだろうと思います。

さて、ベロシティというとスクラムじゃないと使えないと思ってる人はいないだろうか？ 実は、私は、そう思ってました。 でも、どうやら、スクラムじゃなくても、ストーリーポイントでの見積とベロシティで生産性を計測できるようです。 イテレーションで期間を区切ってない開発の場合、計測時点で、タスクが完了していないこともあります。 その場合には、ストーリーポイントを、ベロシティ計測時点の進捗率で、換算します。 タスクA のストーリーポイントが 8 ポイントだとして、計測期間終了時の進捗率が 50% だとしたら、4ポイントのタスクに取り組んだことにして、 ベロシティを計算するということです。

スクラム以外でも、ベロシティを生産性指標に活用にしてみてはいかがでしょうか？

※今回の記事には、こちらの記事を参考にしました。 → アジャイル開発でストーリーポイントを見積もる手順

The post アジャイル開発（アジャイル風も含む）での生産性の計測 first appeared on 株式会社Altus-Five.

9時に起床して10時に仕事を始めると、12時には、ゴールデンタイムが終わるってことか、なんだか、もったいない。 10時に起床して即仕事を始めたら、ゴールデンタイムの1時間を昼休みで消費してしまってることになる。

どっちにしても、だいたいの人は、午前中いっぱいはゴールデンタイムなのだと思うけど、その時間に朝会とかをやってるのは、どうなんだろう？ 朝会じゃなくて夕会をやる方がいいのかもしれない。

脳の回復に関することを少し、紹介します。

• パワーナップ昼寝ですね。20分くらいの仮眠をとると、そのあとの効率がずいぶんと回復するようだ。 実際、昼寝すると、頭がスッキリした気になるので、効果はあるのだろう。
• マイクロナップ1分間、目をつぶる。 脳が処理してる情報の8割が視覚によるもので、それを遮ることで、脳は、ずいぶんと休憩できるのだそうだ。 会議に入る直前の1分間でマイクロナップすると、会議中の居眠りを予防できるとあった。

時間管理術を、少し紹介します。

• ポモドーロテクニック25分集中して、5分休憩するのを繰り返すのだけど、ポモドーロテクニックでも、休憩の5分は、寝るのが一番よいとあった。
• フロータイムテクニックポモドーロをアレンジしたもので、25分と5分という刻みを自分にあった時間でやるというもの。
  自分のちょうどよい時間を見つけるために、実際に作業を始めて集中できなくなるまでの時間と、休憩して再びやる気が戻って再開するまでの時間を記録して、自分のちょうどよい時間を把握するというやり方。

私は、6時頃に起きてるので、9時頃になるとゴールデンタイムが終わるってことか、確かにこの3時間は、集中できてる気がする。 そして、10時になると、いくつかのプロジェクトの朝会をハシゴして午前中が終わるのだけど、あぁ、もう10時かと、寂しさが過るのは、ゴールデンタイムが終わったからなのかもしれない。 会議や雑多なことに追われると、仕事が手につかなくなることがあるが、あれも、脳が疲れて機能しなくなった状態か。

パワーナップとマイクロナップを試してみようと思います。

みなさんも、脳の疲れを回復させながら効率よく仕事していきましょう！

The post 朝の3時間は脳のゴールデンタイム first appeared on 株式会社Altus-Five.

このプロジェクトでは、主に Python で LangChain、LlamaIndex、Ragas などを活用して開発検証を行っています。 今、LLM を使った開発は、このあたりのライブラリを使うのが主流であろうと思います。

私の役割は、調査のシナリオ立案と結果のレポート作成だったので、コードを書く機会は無く、 そのため、LLM 関連のプログラムを書くときの大変さとか難易度を肌感覚で掴めておらず、 やや、もどかしさを感じていたので、サンデープログラミングで実装の体験をすることにしました。

業務では、Python 版の LangChain を使用していましたが、日曜大工では、JavaScript版の LangChain を試してみることにしました。 さらに、LangChain は昨年あたりから LCEL という機能を推進しているので、これも試します。

PoC 案件と同じものを作っても面白くないので、私の手習いの実装テーマは「MD の英文テキストを日本語に翻訳する cli ツール」とします。そして、LangChain のマニュアルが、まだ日本語訳がないので、これを翻訳します。

LangChain のドキュメントは、コードのリポジトリの中に一緒にコミットされていて、主に MD と Jupyterノートブックで書かれています。 それらを、Docusaurus というドキュメントシステムで公開するようになっています。 手習いのゴールは、この英文のドキュメントを日本語訳して、Docusaurus でビルドして、日本語でドキュメントシステムが表示されるところまでとします。

Markdown パーサー

ChatGPT に MD のテキストを丸々投げると、max_token を超えることが懸念されるので、分割して翻訳します。 単純に文字数で chunk 分割すると、翻訳結果がおかしくなるので、文単位で分割するのは必須要件となります。 このために、MD ファイルを抽象構文木（AST）に変換し、文の正確な抽出を行います。 この変換には、 remark を使いました。

実際、MD を AST に変換してみると、どのドキュメントも、適度に空行が入っているので、AST の 1 つのテキストノードの中に、 max_token を超えるほどの長い文は、ほとんどありませんでした。 また、コードのブロックもノードタイプで識別できるので、翻訳対象から除外できます。 テストした中では、唯一、MDのテーブルが、テーブル全体で1つのテキストになるので、これだけは、改行を区切り文字として、分割する必要がありました。

翻訳処理

本記事の主題です。 LangChain を使って、 LCEL （LangChain Expression Language）で翻訳処理を実装します。

その前に、翻訳処理の仕様を簡単に説明すると、最初のプロンプトで英文から日本語に翻訳して、その結果を受けて、その翻訳が正しいかを、添削するプロンプトを実行します。添削結果には、翻訳の正確さを数値で出力するように指示して、その数値が閾値を超えるまで、添削を繰り返します。

最初の英文から日本語への翻訳 Chain

const etojPrompt = await DEFAULT_ETOJ_PROMPT;
const etojOutput = (await etojPrompt
  .pipe(model)
  .pipe(new JsonOutputParser())
  .withRetry({ stopAfterAttempt: MAX_LLM_RETRY_ATTEMPTS })
  .invoke(etojInput)) as EtojOutput;

この手習いをやり始めたときには、LCELじゃなくて、従来方式で実装していたのですが、 翻訳されたマニュアルを読んでいるうちに、LCEL で実装することが推奨されていることを知ったので、 せっかくなので、 LCEL での実装に切り替えてみました。 やってることは変わらないのだけど、コードの見通しがよくなったような気がします。

Python で実装すると、たぶん、こんな感じだと思います。

model = ChatOpenAI()
etojPrompt = ChatPromptTemplate.from_template(DEFAULT_ETOJ_PROMPT)
chain = etojPrompt | model | JsonOutputParser()
etojOutput = chain.invoke(etojInput)

| か pipe() かの違いはあるけど、機能的には同じです。

余談ですが、プロンプトの実装で、Python 版では、jinja2 のテンプレートエンジンを使えるんですが、 js 版では、テンプレートエンジンが使えません。 プロンプトの文字列をリアクティブに変数展開したいことがあるので ejs でもよいのでテンプレートエンジンを使えるようにしてほしいです。 今回の実装では、添削を何回か繰り返すときに、前に添削した内容と同じ添削結果を返してくることがあったので、 過去の添削結果を、添削用プロンプトの中に含めて、同じ添削結果を返さないように指示するのですが、 その処理の実装をしているときに、python だったら jinja2 が使えるのにな・・・と思いました。

添削 Chain

最初のチェーンと添削チェーンも、1つの LCEL でつなげた実装にしようかとも思ったのだけど、 正確さが閾値を超えたら終了する仕様を実装するには、カスタムチェーンを作る必要がありそうなので、 そこまではやらずに、チェーンを分けて、ループさせることにしました。

const proofreadChain = proofreadPrompt
  .pipe(model)
  .pipe(new JsonOutputParser())
  .withRetry({ stopAfterAttempt: MAX_LLM_RETRY_ATTEMPTS });

const proofreadInput: ProofreadInput = {
  ...etojInput,
  ...etojOutput,
  histories: [
    { proofreadText: etojOutput.ja, correctness: 0.0, error: '' },
  ],
};
let answer = '';
for (let i = 0; i < MAX_PROOFREAD_ATTEMPTS; i++) {
  const proofreadOutput = (await proofreadChain
    .invoke(proofreadInput)) as ProofreadOutput;
  answer = proofreadOutput.proofreadText;
  if (proofreadOutput.correctness >= TRANSLATION_CORRECTNESS_THRESHOLD) {
    break;
  }
  proofreadInput.histories.push(proofreadOutput);
}
return answer;

LCEL の batch で、効率の良い並列処理を実行するには、カスタムな添削チェーンで、1本につなげた方がよいです。

まとめ

手習いのゴールとした LangChain のマニュアルを日本語訳してドキュメントシステムをローカルで動かすのは、うまく行きました。 LangChain のドキュメントシステムは、amazon linux 2 で実行するようになっていて、ビルドも、それ用になっているので、 開発環境とした ubuntu の devcontainer でビルドできるようにするのに、ひと手間必要でした。

さて、LCEL についてですが、慣れるまで、少し時間がかかりました。 もう少し “らしさ” を出せるかな・・・と思っていたのだけど、 LCEL にするために知恵を絞らないといけないのが、やや面倒だなと感じましたが、おそらく、その知恵を絞ることで、コードが改善されて可読性が上がるのかもしれないです。 でも、LCEL だろうが、LCEL じゃなかろうが、やってることは変わらないので、コスト見合いで、コダワリ過ぎには注意した方がよいかもしれません。

それから、反省点というか注意点ですが、実行時間と、APIの使用料が想定外にかかりました。 LangChain のマニュアルは、1000 ドキュメントくらいあって、何度か止まって再起動していて、 実行するだけで、トータルで 3 日以上かかり、API の利用料が、$500 ちょっとでした。 1ドキュメントを翻訳するのに $0.5 です。

$0.5 が高いか安いかは、人によると思いますが、私の場合、日本語の技術情報が少ない開発をするときに、 英語のマニュアルを、クラウドソーシングなどで翻訳してもらって、 日本語でザックリと読んで概略を掴んでから開発に入ることがあるのですが、 クラウドソーシングに比べると、全然、安いので、個人の財布で実行しようとは思いませんが、 今回作成した翻訳ツールは、実際に使っていこうと思います。

WEB で参照できる英文のマニュアルなら、Google 翻訳で、無料で翻訳することができますが、 日本語で検索しても、ヒットしないので、あらかじめ日本語訳しておくことは、有用だと思います。

少し面白そうな使い道としては、翻訳した MD ファイルを独自に追記編集するとかも有りだと思います。 開発を始めたばかりのときに読んだマニュアルは、まだ、十分に理解できないことがありますが、 開発が進んで、実際に動作を確認していくと、マニュアルに記載されている内容が、理解できたりします。 このときに、おらがチームのマニュアルに、理解の手助けになるようなメモを追加するとか、 実プロジェクトのコード片を追記したりして、独自にドキュメントを育てていくと、Google翻訳よりも、価値があるように思います。

実装した翻訳ツールは、こちらで公開しています。使ってみたい方は、APIの費用に注意して、ご利用なさってください。

最後に、このツールを追加改良したいことを書いておきます。

改良点

• 過去の翻訳結果をコンテキストとして加えてプロンプトを作成する翻訳した結果を RAG にして refine 法でプロンプトを作成すると、一貫性のある翻訳ができるようになるのではないかと思います。
• 並列化バッチ処理なので、 LCEL の batch で並列化したいです。実行時間も短縮化できますし。
• chatbot翻訳されたマニュアルで RAG を駆使して chatbot を動かしたいです。
• rst の翻訳LlamaIndex のマニュアルも翻訳しようとしたら、こちらは rst （reStructuredText）で書かれていました。 Sphinx です。python の docutils でパースする必要があります。

MIT で公開しているので、有志のご参加をお待ちしています。

The post js 版の LangChain で LCEL を試す first appeared on 株式会社Altus-Five.

ADR とは、アーキテクチャ上の設計判断を記録したもので、MD等の軽量なドキュメント形式で蓄積しようというものです。 記事中でも、参照がありますが、Michael Nygard氏がブログで紹介したところから広まっていったようです。 この記事も、Google翻訳して、読んでみることをお勧めします。

アジャイル開発では、体系的にまとめられた大きなドキュメントを作成することは行いません。 ドキュメントをまったく作成しないわけではないけれども、必要最小限なドキュメント構成になります。

この場合に問題になるのが、例えば、プロジェクトに新しく誰かが参加したときです。

システムの仕様だけではなく、過去の経緯なども、知らないので、アーキテクチャーの変更に迫られたときに、 過去の経緯に関係なく、盲目的に変更するしかありません。 このような変更は、地雷を踏んでしまったり、過去の問題が再燃する可能性があったり、とても怖い決断になります。

ADR は、なぜそのアーキテクチャーが必要なんだっけ？とかの導入経緯や、どういう影響があるんだっけ？を記録として残していきます。 体系的で重厚なドキュメントを書くのではなくて、なぜその決定がなされたかを記録します。

このやり方は、ThoughtWorks社のMartin Fowler氏も、technology radar で評価していました。 そして、現在の radar では、ADR を拡張して設計変更も同じ方式で管理する 「Design system decision records」（設計・デシジョン・レコード） を評価しています。

Google や Amazon も取り入れています。

• https://cloud.google.com/architecture/architecture-decision-records?hl=ja
• https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/adr-process.html
• https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/appendix.html

そして、この ADR のドキュメントは、その検討がされていた一時期だけ更新されるドキュメントで、それ以降のメンテナンスは、不要だというのがいいです。 後々、同じ領域の設計話題が出たときには、新しい ADR を作成して、過去の ADR へのリンクを張るだけで、過去の決定をたどることが可能となります。

直観的に、これは良いなと感じました。そして、アーキテクチャーの枠を超えて設計変更の経緯を追跡する「設計・デシジョン・レコード」がもっといいです。 設計書は書かないけど、設計変更の経緯は残すというのは、継続的なエンハンスの開発がされているアジャイルのプロジェクトに最適です。

サンプルです。例えば docs/ADR/adr-NNNN.md で追加していきます。

## Title
勤怠管理システムにおけるクラウドベース認証サービスの採用

## Status
Proposal

## Date
2024-01-26

## Context
既存の勤怠管理システムは、オンプレミスでの認証メカニズムを使用している。
しかし、リモートワークの増加とスケーラビリティの要求により、より柔軟かつセキュアな認証システムが求められている。

## Decision
AWS Cognitoのようなクラウドベースの認証サービスを導入して、ユーザー認証プロセスを管理する。

## Consequences
### Positive
スケーラビリティと可用性が向上し、リモートワークに対応しやすくなる。

### Negative
既存のシステムとの統合には初期コストがかかり、スタッフのトレーニングが必要。

## Compliance
- 新しい認証プロセスはGDPRおよびその他のデータ保護法規に準拠する必要がある。

## Notes
- Author: hoge
- Version: 0.1
- Changelog:
    - 0.1: Initial proposed version

とても、シンプルです。ADR に関して、このサンプルを読む以上の学習は不要です。独自にルールを追加して運営するのも寛容です。

ドキュメントがなくて、システムの仕様理解が進まないというプロジェクトは、たくさんあります。 だからと言って、今から、体系的にドキュメントを作れるわけでもないので、特段、対応策が講じられないのが現状ですよね。作ってしまうとメンテナンスに工数を取られるし。

でも、ADR なら、すぐに始められるし、とてもライトで強力な施策になるのではないでしょうか？

うちの会社の開発標準としても、組み込んで然るべきな気がしてます。

The post アーキテクチャー設計の意思決定を効率的に記録する「ADR」の導入 first appeared on 株式会社Altus-Five.

そして、 js.langchain のコードを見ていたら、これが、たくさん、使われてました。 例えば、以下のようなコードです。

export interface BaseLangChainParams {
    verbose?: boolean;
    callbacks?: Callbacks;
    tags?: string[];
    metadata?: Record<string, unknown>;
}

export abstract class BaseLangChain<...> extends Runnable<...>
  implements BaseLangChainParams
{
  verbose: boolean;
  callbacks?: Callbacks;
  tags?: string[];
  metadata?: Record<string, unknown>;

  constructor(params: BaseLangChainParams) {
    super(params);
    this.verbose = params.verbose ?? getVerbosity();
    this.callbacks = params.callbacks;
    this.tags = params.tags ?? [];
    this.metadata = params.metadata ?? {};
  }
  ...

引数の型が同じものが連続していると、引数を指定する順番を間違って、バグになることがあります。 でも、上記の実装方法だと、それを防げます。

const chain = new BaseLangChain({
    verbose: false,
    tags: ['hoge'],
    metadata: { fuga: false, piyo: 'PIYO' },
});

Options Objectパターンというのを知らなかったので、最初見たときに、なんのために、Xxxx クラスと XxxxParams という interface を 実装するのか疑問だったのだけど、Options Objectパターンというプログラミングのベストプラクティスに則っているのだと、わかりました。 TypeScript や Java のように名前付き引数がない言語で、引数が多いときに、このパターンが、役に立ちそうです。 interfaceの実装が必要で、少し冗長になるので、引数が多いときに限定して使うと良いように思います。

ご参考まで。

The post TypeScriptで名前付き引数っぽい実装をするます。 first appeared on 株式会社Altus-Five.

特に最近は、 text-generation-webui というツールを使って、コードを書かずに LLM のダウンロードから、細かいパラメータ設定なども UI で行って chat を動かす記事が定番の1つのようです。

私も使ってみました。

Google Colab は、使ってないとインスタンスがダウンするので、text-generation-webui の Clob 用のノートブックには、 動かし続けることを目的とした音楽プレーヤーがついていて、それを再生することで、連続使用の状態を維持できるようになってました。 無料枠でそれをするのはモラルに反しないのだろうか？と思いながらも、お試しで、GPUインスタンス（T4 GPU）を選択して、 音楽プレーヤーを再生して連続使用状態にしてみたところ、GPUのインスタンスは、無料枠が短いようで、1日も持たずに、 1カ月分の無料枠を使い果たしました。

有料版は、Colab Pro が月額 1,179 円 で 100 コンピューティングユニットが使えて、Colab Pro+ が月額 5,767 円で 500 ユニットが使えるとなっています。 他にも、Colab Enterprize とかもあります。

コンピューティングユニットの上限を超えると、追加のチャージが必要で、1回のチャージが100ユニット単位です。
T4 GPU は、100ユニット＝51時間です。
1日8H、20日稼働で 160H、多少の残業も加えると、毎日の勤務時間中に常時起動しておくような使い方だと、Colab Pro+ が適したプランとなります。
1年だと、5,767 * 12 = 69,204円 です。
なお、100ユニット＝51時間 は、T4 GPU の場合で、V100 は 18.5時間、A100 は7.5時間 しか使えません。

T4 と V100 で codellama 13b を使ってみましたが、レスポンス性能は、同じようなものだったので、ひとまず、わざわざ、V100 や A100 を選択する必要はなさそうでした。 ひょっとすると、長いプロンプトを使ったりすると、レスポンス性能に違いが出てくるのかもしれないですが、そこまでは使い込んでいません。

codellama 13b は、オリジナルのモデルは、16G では動かないので、 llama.cpp でGPUのVRAMとCPUを併用するやり方で動かしました。 llama.cpp には、http server の機能もあるので、ひょっとすると、複数人で同時利用もできるのかもしれませんが、これも試していません。

NVIDIA の 16G メモリ以上のグラボの PC を自作すると、4、50万は、かかりそうなので、Colab Pro+ の方がリーズナブルかな・・・。
eGPU という外付け GPU もあるようなので、社内に小さい LLM サーバーが欲しい気もします。
社内に LLM サーバーがあったら、 CodeLlama を動かして、ChatGPT が禁止されているプロジェクトで、使えるようにして、 Open Interpreter などでコード作成を実行してみたい・・・、けど、すでにやってる人たちの記事を読むと、やっぱり GPT-4 じゃないと仕事には使えそうにないです。
だから、社内 LLM サーバーは、まだ早いかな・・・。

と思ってたら、ファインチューニング向けモデル「Mistral 7B Fine-Tune Optimized」が登場、特定タスクにおいてGPT-4を超える性能を発揮という記事を見て、ローカルで LLM を動かしてみたくなってきました。

7B は、ローカル LLM の中でも、一番小さい部類のモデルだけど、それでも、GPT-4 を超えることがあるとしたら、すごく使ってみたいです。

まずは、Google Colab で試してみてから考えようっと。

The post ローカル LLM を動かす first appeared on 株式会社Altus-Five.

GitHub や Gitlab などの API のあるコード管理を使っているなら、 CI や、品質計測用の日次バッチで、自動計測できそうです。

変更のリードタイム: first commit から、その commit が本番にリリースされるまでの時間

ブランチのログから取得できます。 ついでに API で Issue の着手から Close までの時間、 PR の作成から、マージまでの時間なんかも計測できます。

手戻り数: プロジェクト管理システムにおいて、プロセスの前段に戻ってきたタスクの数

例えば、あるタスクを「完了」に移動したが、実際にはバグがあった場合、タスクは前段に戻され「手戻り」となる。

と記載されてましたが、なんらかのルールを設けないと、計測に抜け漏れが出そうです。

私は、これまで、完了にしたタスクを戻すことはしてなくて、新しいタスクを作っていました。 タスク（Issueチケット）の動かし方を分析して、仕様変更で手戻りが発生したケース、バグによる手戻りのケースなどで分類分けして、 Issue チケットのワークフローをルールで決めておかないと、正しく計測できない気がします。

次のタスクに取り掛かって、前のタスクのバグが見つかったとしても、前のタスクの状態を戻さずに作業することも、よくあるので、厳密な管理は難しいかもしれません。 参考程度の指標として使うのがよいかもです。

ルールが決まったら、 API で回収できるので、自動化できます。

手戻り率: プロジェクト管理システムにおいて、プロセスの前段に戻ってきたタスクの割合

タスクが戻った回数をB、タスクが進んだ回数をFとすると、手戻り率は (B / (F + B)) * 100 で表せる。

上記のとおり、「手戻り」の識別方法を、どこまで厳密化できるかが課題ですが、参考指標にはできそうです。

コード行数（LOC：Line Of Code）

昔の開発では、プロジェクトの終了時に、開発したコードの行数を数えてたな・・・と、懐かしいです。 記事の中でも、「取り扱いが難しい指標」と記載されています。

本当に手が早い人で、コードの行数が多い＝生産性が高いと評価できる人もいるかもしれないけど、コピペ君が書いたコードかもしれないです。 LOC を生産性の指標とするのは、やや問題がありそうです。

ただし、コード量が多いとメンテナンスにかかるコストが大きくなるのは、そのとおりなので、バグの数を LOC で割ったものを「バグ密度」と定義して、品質の指標には、使えると思います。
保守性を推し量る指標にもなるかもしれません。

行数のカウント方法には、LOC、NLOC、LLOC、CLOC など、やり方がいくつかあり、さらに「2つの命令が書かれた行は2行と数える」「括弧だけの行を除く」というルールを設ける場合もあるようです。そこまでやると、なかなか大変ですが、 AST を使ってコードをパースすれば、計測できなくはないです。

どこまでやるかは検討するとして、自動化できます。

循環的複雑度（Cyclomatic Complexity）

大雑把にいえばコード内のif／else、for、switch、whileなどの分岐やループの数を数え上げたもの

だそうです。

ツールがあるので、自動化可能です。

• OCLint: C言語向けの静的解析ツール
• GMetrics: Java向けのメトリクス分析ツール
• Lizard: コマンドラインの循環的複雑度計測ツール（たくさんの言語がサポートされている）

循環的複雑度とそのコードが編集された回数には密接な関係があるそうで、 複雑なコードは修正回数が多くなるというのは、頷けるところです。

私としては、オブジェクト指向の複雑度も計測してほしいです。
オブジェクト指向が進むと、条件分岐じゃなくて、汎化と具象化で機能を入れ替えますが、 他人が書いた複雑なオブジェクト指向な実装は、コードの理解とデバッグ難易度が高いので、 ちょうどよい塩梅の指標が欲しいです。

コードの重複（Code Duplication, Clone Code）

DRY 原則としても有名です。コピペはやめましょう。

これも、ツールがあるので、自動化可能です。

• Clone Detective
• Simian
• PMD
• SonarQube

検出した重複コードを使ってコード品質を測定するなら、 例えば、プロジェクトのコード行数に対する重複コード行数の割合、 つまり「重複率」を測定することができます。 この「重複率」をKPIとして利用しているチームも多いでしょう。

との記載もありました。

また、以下のようにも。

（「重複率」は）低い方がより良いだろう、ということは自明だと思いますが、 先に紹介した循環的複雑度とは異なり、実は重複度に関しては明確な基準値はありません。

重複度に関しては、その絶対値よりも値の時系列変化に着目した方が良いでしょう。 ある程度の期間の中で何か著しい増加が観測されたら、 チームを集めてその原因や対処方法について検討してみて下さい。

グラフ表示できるとよさそうです。

その他の指標

以下は、健全なプロジェクトであれば、すでに取り組んでいるでしょう。

• ユニットテストとカバレッジ
• コードレビュー頻度
• 性能プロファイリング

まとめ

このような計測データを、プロジェクト別に集計するだけではなくて、個人別に集計すると、これまで見えていなかった課題が、見える化されるかもしれません。みなさんも、品質指標の計測の自動化に取り組んでみては、いかがでしょうか？

The post コードの品質を測定する方法 first appeared on 株式会社Altus-Five.

弊社は、この小さい開発会社なので、自社プロダクトを開発する分には、無償で使えるのだけど、受託開発で、依頼元の企業が大企業の場合、どうしたらよいのか、WEBで検索して調べたのだが、よくわからなかった。

仮に、開発会社がライセンスを持っていれば良いとして、納品したあとの保守を依頼元企業の保守チームが行う場合には、ライセンスが発生するので、予め Docker を開発に使うことに合意しておく必要はありそうだ。

WSL の Ubuntu でのみ Dcoker を使う

でも、有償なのは、 Docker Desktop であって、Docker Engine は無償で使ってよいので、 Docker Desktop を使わないで、 Docker を使う方法を調査した。

答えは簡単で、 Windows では、WSL の Ubuntu に apt コマンド等で docekr をインストールしたらよい、それだけだった。

Docker Desktop を使わないことのマイナス面は、なんだろうか？

• Dockerを操作する GUI が使えない
  「Use the WSL 2 based engine」で有効化される機能が使えない。
  これは、未調査なので、私の想像だけど、Windows と WSL とのメモリの共有はできないのではないかと想像する。
  他にも、ホストOSの Windows と連携して動く便利なものが動かないのだろう。
• PowerShell や GitBash 等から docker コマンドを使えない
• VSCode の devcontainer で使うときにひと手間かかる

VSCode の devcontainer の使い方

devcontainer が使えないわけではない。

WSL 側にも VSCode を入れてあるとしても、あれは vscode-server という headless のサーバー機能なので、Windows 側の VSCode が必要である。

そして、 VSCode が devcontainer を開始するときに、docker コマンドを使うようで、このコマンドを実行するのは、Windows 上からなので、Docker Desktop を入れてないと、エラーになる。

Docker Desktop が無い状態での devcontainer の使い方は、WSL側で、docker-compose 等を起動しておいて、 VSCode からは、そのコンテナにアタッチする形で、今までとほぼ同じように使える。

そして、 devcontainer cli というものが GitHub で公開されていて、これを使うと、以下のコマンドで、devcontainer を起動してくれる。

devcontainer up --workspace-folder .

devcontainer の設定は、 .devcontainer/devcontainer.json などで、設定しておくけど、これを読み込んで、コンテナを起動をしてくれる cli ツールである。

docker-compose で起動すると、 devcontainer.json に記載された extension が起動時にインストールされないので、この cli も使った方がよいだろう。

Docker Desktop の代替

ということで、Windows でも使い方を間違わなければ Docker は使って問題ない。

ちょっと、残念なのは、WindowsとWSLとのメモリの共有がされないので、WSLのディストリビューションに対してのメモリを、手動で割り当てておく必要がある。

あと、Docker Desktop の代替として、Podman というものがあるのだけど、これも少し使ってみたが、非常に荒っぽい言い方をすると、 上記のやり方を知っていれば、使う必要はなさそうだった。あまりメリットを感じなかった。

Podmanのインストール手順に従って、インストールを進めていくと、まずは、Podman Desktop（Docker Desktopのようなもの）が インストールされて、さらに GUI から、数ステップの操作を進めていくと、WSL に podman のディストリビューションの linux がインストールされて、 その linux の中に、Docker Engine 等の Docker 関連の OSS がインストールされて、コンテナの状態が操作できるようになる。

ただ、まだ枯れてない。
私が持っているプロジェクトの1つが、build できなかった。（buildが終わらない）
これがちょっと痛い！

Windows との連携機能が厚いわけでもなく、単なるダッシュボードみたいなもので、旨味が薄いので、 いまのところ Podman は使わなくてよいという判断である。 ホストOSとのメモリの共有ができるくらいの機能実装が出来るようになったら、再度、試してみることにしよう。

※ もしも、使い方が悪くて、動かないだけだったら、すみません。

最後に

いままで、合意のないまま Docker Desktop を使っていた人は、いったん、アンインストールして、上記のとおり、 linux 内でのみ docker を使うようにしましょう。

The post 開発会社が Docker のライセンスに準じて正しく使うために first appeared on 株式会社Altus-Five.