専門業者向けB2B ECサイトの保守開発において、複雑なドメイン知識と最新技術を組み合わせた包括的なソリューションを提供しました。レガシーシステムの段階的リプレースと機能追加により、お客様の事業継続性を保ちながらシステムの競争力向上を実現し、持続可能な成長基盤を構築いたしました。

技術要素

• Python
• BigQuery
• TypeScript
• React
• Next.js
• CI/CD
• 継続的デリバリー
• AI駆動開発

プロジェクトの特徴

• 複雑なドメイン知識への横断的対応力
  多岐にわたる専門分野を理解し統合的にシステム設計
• レガシーシステムの段階的リプレース戦略
  事業を止めずに安全かつ効率的にシステム近代化を実現
• 最新技術の積極的導入
  AI駆動開発など先端技術を活用した開発効率の向上
• 非機能要件への配慮した設計
  パフォーマンス・セキュリティを重視した堅牢な基盤構築

成果

• 事業継続性を保ちながらのシステム近代化の完遂
• 段階的リプレースによるシステム移行リスクの最小化
• CI/CD導入による開発・運用効率の大幅向上
• レガシー技術から最新技術への段階的移行の成功

Altus-Fiveの強み

複雑なドメインへの深い理解力と横断的対応力、レガシーシステムの近代化ノウハウ、最新技術の積極的導入により、お客様の事業を止めることなくシステム価値を向上させる提案力と実行力を発揮いたします。技術的課題と事業課題を同時に解決する総合的なソリューション提供が私たちの強みです。

The post 08 専門業者向けB2B ECサイト first appeared on 株式会社Altus-Five.

データパイプラインの基盤移行・統合と運用ルール整備を実施。可視化やリカバリ設計により、安定したデータ運用環境を構築しました。
最新のデータオーケストレーション技術を活用し、保守・運用の効率化と品質向上を実現しました。

技術要素

• Python
• dagster
• dbt
• Hadoop
• Athena
• Glue
• Docker
• PostgreSQL

プロジェクトの特徴

• データパイプラインの可視化
  dagster基盤による運用状況の見える化
• リカバリ設計
  途中からの復旧が可能な柔軟な設計
• 保守・運用ルール整備
  安定運用のための手順・ルールを策定

成果

• データ運用の安定化
• 保守・運用効率の向上
• 最新技術への対応
• 運用品質の向上

Altus-Fiveの強み

最新技術への対応力と運用ルール策定力で、複雑なデータ基盤の移行・運用も安定してリード。顧客の業務効率化と品質向上に貢献できる点が弊社の強みです。

The post 06 データパイプラインの開発・保守/運用 first appeared on 株式会社Altus-Five.

多様な派遣案件の中から IT系案件に特化 した検索ポータルを開発しました。
ITエンジニアとして働きたい求職者が、希望条件に沿った案件をスムーズに探せるように、直感的で高機能な検索体験を実現しています。

主な機能は以下の通りです：

• 全文検索によるキーワード検索
• スキル・勤務地・単価など、多様な検索軸による条件絞り込み
• レコメンドエンジン（協調フィルタリングを活用）による関連案件の提案
• ブログポータルサイトとの連動による情報発信
• 面談予約機能でスムーズなマッチングをサポート

技術要素

• Java / Spring Boot / JPA
• Apache Solr （全文検索）
• Apache Mahout による協調フィルタリング（レコメンド機能）

プロジェクトの特徴

この案件では、以下のような点で高い評価をいただきました：

• 超短納期でのリリースを実現
  限られたスケジュールの中、アーキテクチャ設計から開発・テスト・リリースまでを一気通貫で対応しました。
• 要件定義から弊社エンジニアがリード
  ご担当者様がシステムに詳しくなかったため、要件整理から開発に至るまで弊社が主体的に推進。ユーザー視点を踏まえた提案を行い、実務に即したシステムを構築しました。
• 検索精度 × 利便性の両立
  IT案件特有の検索ニーズを反映し、ユーザーが「探しやすい」「見つかりやすい」検索体験を提供しました。

成果

• エンジニアと案件のマッチング効率が大幅に向上
• レコメンドによる案件発見が増え、求職者の利用満足度が改善
• 導入企業様にとっても、案件紹介・面談設定のプロセスが効率化

Altus-Fiveの強み

本案件のように、システムに不慣れなお客様でも安心してお任せいただけます。
要件定義からリリースまで、私たちが伴走しながら、短期間で「本当に使えるシステム」を実現します。

The post 01 人材派遣会社様向け IT案件検索ポータル 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.

テキストエディタでドキュメントを書きたい

でも、以前、仕様書をマークダウンで書きたいという記事を書きましたが、エンジニアは、テキストエディタでドキュメントを書きたいので、しっくり来ない点も多々あるんです。

どの辺が不満かと言うと、まずは、 Confluence の wiki マークアップというのが、 textile の記法に近い感じで、マークダウンじゃないというところ。

Confluence のアドオン機能でマークダウンの記事も投稿できるのだけど、手元のエディタで書いたドキュメントを Confluence のマークダウン記事投稿画面に貼り付けないといけないので、なんだか心地よくないです。 git commit から push で投稿したいですよね。
ついでに、アドオン機能のマークダウンだと、マークダウンの文書間のリンクが、そのまま Confluence のページ間のリンクにならないんです。 Confluence のページが相対パスで指定するものじゃないので、そりゃそうなんだけど・・・、イマイチなんです。

Confluence と github wiki の同期

ユーザーと共有するドキュメントは、Confluence なんだけど、開発チーム内では、github の wiki で仕様書を書いているので、何か、同期するようなツールがないかなぁと、探してみたのだけど、ピッタリのツールは見つけられなかったです。ニッチすぎますからね、そりゃそうです。

それならば！ということで、ツールを作ることにしました。

ツールのポイントは、3つです。

• オリジナルのドキュメントは、マークダウンで書いていて、github wikiでバージョン管理する
• Confluence の画面を開いてテキストを貼り付ける的なことは止めたい
• Confluence 上でも、ドキュメント間のリンクが再現されること

テキストの貼り付けを止めるには？

何ページも、この操作をするのは、やりたくないので、マークダウンを Confluence wiki マークアップに変換して、 Confluence API でコマンドラインから、投稿することにしました。
探してみると、使えそうなものがいくつか見つかりました。 さすがに要求ピッタリのツールは無かったので、足りない部分は、専用の cli を自作することにしました。

• markdown2confluence-cws
  nodejs製のツールです。これで、マークダウンを Confluence wiki マークアップに変換します。
• confluence-api
  Confluence の API のラッパーライブラリです。
  https://github.com/johnpduane/confluence-api から fork したものです。一部のAPIがエラーで動かなかったので、修正して使っています。
• 専用cliツール
  上記の2つを使って、パラメータで指定されたmdファイルを変換して、APIで投稿するツールです。

ドキュメント間のリンクをどうするか？

Confluence のドキュメントは、ページタイトルがユニークになっているので、ページタイトルでリンクを張るようになっています。 wikiのリンクと言えば、この仕様の方が普通で、 redmine の wiki も backlog の wiki もこれです。
github wiki のmdファイルの相対パスでリンクを張る方が、wiki としては特殊なんだと思います。
また、Confluence の wiki の階層構造は、親ページを設定することで、表現しています。

いくつかやってみて、専用 cli の中でリンクを変換するやり方に落ち着きました。ついでにリンク切れチェックなんかもできました。
そして、Confluence 上のドキュメントは、ユーザー側でも、いろんな書類を作成しているので、開発側都合のページタイトルや階層をそのままにできないところもあり、マークダウンのドキュメントの中に、 Confluence 上でのページ名と親ページ名を Front-matter で持たせておくことにしました。

こんな感じです。

---
title: アカウント管理画面
parent: 画面仕様
---

**機能概要:**
アカウント管理画面の仕様について記載する。

**入力:** 
* パラメータ1
* パラメータ2
* パラメータ3

**処理詳細:** 

・・・・

Front-matter は、静的Webサイトジェネレータのjekyllでも使われていて、jekyllは、githubにblogを公開するツールなので、考え方としても、相性が良さそうです。

モヤモヤ解消

以上、 Confluence でプロジェクト全体の文書共有してるけど、開発チーム内ではマークダウンで文書を書いて git で管理したいんだよなぁ・・・とモヤモヤしたときには、開発側文書を専用のcliツールで Confluence に共有してみては・・・というお話でした。

実際に、文書を投稿するときの cli は、こんな感じです。

vi docs/hoge.md
git add docs/hoge.md
git commit -m "update hoge"
git push origin master
npm run md2c docs/hoge.md  # これが専用cliツール

Confluenceの投稿画面を開いて、テキストを貼り付けるっていう気持ち悪さも、少しは解消されるんじゃないでしょうか。

専用cliについては、githubで公開しているので、詳しくは、そちらも参照してみてください。
https://github.com/a5doc/md2confluence

The post Confluenceのドキュメントをマークダウンで書きたい first appeared on 株式会社Altus-Five.

Excel方眼紙の仕様書をうんぬん言ってるんじゃなくて、それがWordの仕様書でも嫌なんです。HTMLになった仕様書をブラウザで見るのも嫌。

コーディングしながら、仕様書を見ながら、関連仕様をgrepして確認して、仕様書に間違いを見つけたら即修正して・・・と、こんな感じで、できるだけ、 実装の流れを止めずに仕事する ことってできないものか？
ということで、なるべくテキストエディタだけで仕事できたら良いんじゃない？というお話です。

wikiで仕様書を共有する

弊社の開発では、プロジェクト管理に Redmine、GitHub、GitLab、Backlog などを使ってますが、wikiにプロジェクトの概要や、各種手順、議事録などをまとめるため、マークダウンで文書を書くということが、日常的になっています。
でも、設計書の類は、Excelで執筆して、ファイルサーバーで共有するというやり方が大多数です。やはり、納品物としてマークダウンというのは、うーんって感じですね。

そんな中、先日、あるプロジェクトで、設計書としての納品物の体裁はなんでもよいというお客様がいたので、設計書もwikiで書いてwikiそのものを成果物にする試みを行いました。
そのプロジェクトで使用したのは、GitLabです。
コードの管理だけではなくて、wikiもあるし、課題管理もできて、且つ、プライベートリポジトリが無料というのも、プロジェクトの性質にマッチしてました。

wikiで記述したドキュメントは、以下の通りです。

• システム概要
• システム構成
• 機能一覧
• 画面一覧
• テーブル定義書
• 画面仕様書
• WEB APIインターフェース仕様書

githubやgitlabのwikiは、それ自体を git clone してエディタで書くことができるので、上記の仕様書は、エディタで執筆しています。

実際にやってみた印象は、 wikiだけでも十分に仕様書として成立する！ です。 でも、同時に、課題もいくつか見えました。

良い点

• ドキュメントをgitでバージョン管理できる
  excelファイルもバージョン管理できるけども、バイナリファイルなので、差分比較できない。
  wikiのテキストファイルは、差分比較ができてよい。
• テキストエディタの軽さ
  文書を執筆するときのアプリケーションの起動の軽さは心地よい。
• 検索性に優れている
  grepでテキスト検索できるので、目的のドキュメントをすぐに探せる。
• ドキュメント間のリンク
  ExcelやWordでもリンクが張れるけども、wikiの手軽さには、遠く及ばない。
• ブラウザで直接編集できる
  設計レビューなどでは、wikiを見ながら、指摘事項をその場で直接修正できる。レビューの指摘事項を、即、issueとしてメモできるのも、gitlabを使って感じた良い点でした。
• ドキュメントの共有が楽
  git pushで即共有なので、パスワード付きzipに圧縮して、メールで送信という手間がない。

イマイチな点

• マークダウンでテーブルを書くのが辛い
  よくあるexcelのテーブル定義書の様式で、テーブル定義を書いてみたのだけど、マークダウンでテーブルを書くのが、なにしろ辛い。
• 図が書けない
  テキストだけなので、表現力が乏しい。ちょっとした図を添えたいときに困る。
• 目次も手書き
  Wordなどは、目次を作ってくれるけれど、wikiは、自分で目次を書くしかない。
• 章番号があった方が読みやすい
  MDの場合は、章番号を書かないことが普通なのだけど、長いページでは、章番号があった方が読みやすい（かもしれない）。章番号がついた設計書を見慣れているということもあるとは思うのだけど。
• リンク切れ
  手軽にリンクが張れるのはメリットなのだけど、リンク切れすることもよくある。
• 生産性は変わらない
  テキストファイルで仕様書を書いたからといって、設計書の生産性があがるわけではない。
• 成果物としての体裁の弱さ
  このプロジェクトでは、成果物をwikiのままでよかったのだけど、他のプロジェクトでも、このやり方を展開するには、せめて PDF にするくらいのことはできないと厳しい。

a5doc というツールを作りました

やはり、妥協のない文書を書くということにかけては、WordやExcelの方が優れています。
マークダウンは表現力を妥協することで得られるメリットを優先しているわけですが、そのメリットは、お客様のメリットというよりは、プログラミング好きなエンジニアのメリットのように思います。
でも、この内向きなメリットを生産性に結び付けられると、お客様にとってのメリットにもなります。

軽快なテキストエディタのメリットをそのままに、イマイチだった点を改善することができないだろうか・・・と、取り組み始めのが、補助ツール a5doc の開発です。

a5docは、仕様書を書いて保存したら、コミット前に実行して、チェックや自動補正、あるいは自動生成を行います。
例えば、プログラムの開発では、コミット前に lint 等を実行して、コーディングルールのチェックをしますが、そういった感じのことを設計書の執筆過程でもやってみようというわけです。

このツールは、特定のエディタのプラグインとして作ったのではなくて、nodejs で実行するプログラムにしました。 npmで公開してますので参照してみてください。

たった今、実装されている機能を少し説明します。

• 目次の作成
  githubとgitlabのwikiでは、_Sidebar.md を作成してコミットしておくと、右上に目次を表示することができるので、_Sidebar.md を自動生成します。
  目次が自動更新されない問題点は、緩和されると思います。
• テーブル定義の作成
  マークダウンのテーブルを書くのが辛いので、ymlファイルでテーブルの仕様を書いて、MDに変換します。
• ER図の作成
  ymlでテーブルの仕様が明確になっているので、ER図を自動生成できるようになってます。
  ER図は、PlantUMLで出力されます。
• swagger.ymlからAPI仕様書を作成
  APIもテーブル定義の方式と同じく、ymlを書いてMDに変換します。
  そして、APIのymlなら、わざわざ独自仕様を作成するまでもありません。swagger.ymlを書いて、MDに変換します。
  swagger.ymlなら、実装フェーズでも、有効活用できます。

・・・・

まだ実装された機能は少ないですが、これから追加していきたいと思っている機能は、ドキュメントの中から用語を自動的に抽出して用語集を自動生成したり、用語の揺れチェックをしたり、あるいは、自動的にリンクを張り込んだり・・・とか、そんなことを考えています。
こういうのは、ExcelやWordのドキュメントでは難しいけども、wikiで仕様書を書いてれば可能なことだったりします。
設計書の品質が高まることとか、設計工程の生産性が向上しそうなことを目的として、機能開発に取り組んでいきます。

a5docで作成された設計書は、単なるテキストファイルなので、a5docが無くなっても、設計書のメンテナンスができます。 捨てることも容易なツール ですので、一度、お試しください。

ちなみに、テーブル定義やAPIの仕様をymlで書くことによって、プログラムの一部分をひな形出力することもできそうです。
まぁ、今どきのフレームワークは、それ自身の中に、scaffold機能があるので、a5docは、そのscaffold機能を実行するコマンドラインのパラメータを自動生成するとかですかね。
ドキュメントだけじゃなくて、開発のサポートもできるツールにしていきたいなぁと思ってます。

テキストエディタで仕様書を書きたい

テキストエディタで仕様書を書きたい欲が抑えられなくて困ってる人いませんか？
プログラミングが好きな人たちの中には、何人か居るんじゃないでしょうか。
そんな人たちの目に留まるといいなぁ・・・。
きっと、同じような感性を持っている人だと思うので、いっしょに仕事してみたいですね。

The post 仕様書をマークダウンで書きたい first appeared on 株式会社Altus-Five.