ソフトウェア、セキュリティ & AI を、一人のエンジニアが構築し納品します。
ネイティブの C/C++ および Qt アプリケーション、COBOL のモダナイゼーション、本番環境向けの AI 統合、そして実践的なセキュリティ業務。あなたが依頼するのは私であり、ともに進めるのも私です。プロジェクトマネージャーも、引き継ぎもありません。
私と直接やり取りできます
最初のご相談から納品まで、すべてのプロジェクトを担当します。仲介者はいません。
完全なソースコード & ドキュメント
完全なソースコードとドキュメントを納品時にお渡しします。
事前に範囲を確定
作業開始前に範囲を固定して合意するため、予想外のことは起こりません。
納品後のサポート
納品ごとにバグ修正期間が含まれています。
私が行うこと
本格的なソフトウェアを構築する企業向けの実践的なサービス - カスタム開発、レガシーCOBOL移行、AI統合、モダンなエッジインフラ、そして実務レベルのセキュリティ。すべての案件を、長年の本番環境での経験をもとに、直接お届けします。
最新のテクニカルチュートリアルと知見
Web開発、プログラミング、セキュリティ、インフラ、人工知能まで幅広いトピックを扱う最新のブログ記事で最新情報をチェック。新しい技術を探求し、進化し続けるテクノロジーの世界で一歩先を行きましょう。
最初の一週間で成果を出す開発者オンボーディング
開発者のオンボーディングは、たいてい入社手続きや研修が何日で終わったかで測られます。しかしそれは、問題の逆側の端を見ています。本当に意味のある数字は別のところにあります。新しく入ったエンジニアが何かを変更し、そのうえで他のどこも壊していないと自信を持って言えるようになるまでに、どれだけの時間がかかるか。多くのチームでこの数字は、日数ではなく月数で測られてしまっています。 その遅れの原因が本人にあることは、めったにありません。原因は、システムのうちどれだけの部分が他人の頭の中にしか存在していないか、そして最初の二週間のうちどれだけの時間が、それを一回の割り込みごとに少しずつ引き出す作業に費やされ...
意味のある稼働率SLAとは
稼働率SLAは約束のように見えて、実際には返金規定のように振る舞います。提供側はそれを知っています。契約する側は知らないことが多く、可用性を買ったつもりでサービスレベル契約に署名しますが、実際に買っているのは、可用性が得られなかったときに受け取れるわずかな割引です。 それが必ずしも悪い取引だというわけではありません。ただ、多くの人が結んでいるつもりの取引とは別の取引であり、その違いはシステムが止まって、契約には何と書いてあるのかと誰かが尋ねた瞬間に効いてきます。 スリーナインは完璧に近く聞こえますが、月に43分の停止を許容します。 フォーナインが許容するのは4分です。平日の午後に43分の障害を...
ソフトウェアエスクロー：本当に必要なのは誰か
ソフトウェアエスクローは、日本語ではソースコード預託とも呼ばれ、もっともな不安に答えるために存在します。基幹システムを構築し運用してきたベンダーが事業をたたみ、こちらの手元には、依存しているのに保守できないものだけが残る、という不安です。エスクロー契約はソースコードを中立的な第三者に預けておき、実際にそうなったときにその第三者が利用者へ開示します。 不安そのものは正当です。ところがこの仕組みは誤解されやすく、その隔たりから、毎年費用だけがかかり、いざ必要になった日には役に立たない契約が生まれます。 署名の前に確かめておきたい、居心地の悪い問い: もし明日ソースコードが開示されたとして、社内の誰...
請負契約と準委任契約、どちらを選ぶか
請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。 リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいる...
小規模ソフトウェアチームの災害復旧
小規模なチームにおける災害復旧は、たいていの場合、誰も開いたことのないドキュメントの中の一行で終わっています。バックアップは有効になっています、という一文です。その記述自体は事実ですが、何かの答えになっているわけではありません。実際に障害が起きたときに戻ってくるデータがどれだけ古いものなのか、復元にどれくらいの時間がかかるのか、そしてこれまでに誰か一人でも最後まで復元をやり切ったことがあるのか、そのどれについても何ひとつ語っていないからです。 バックアップを持っているという状態と、実際に復旧できるという状態のあいだには、はっきりとした隔たりがあります。ほとんどの障害が本格的なインシデントへ変わ...
コンテンツプルーニング：削除がアクセスを増やす理由
コンテンツプルーニングは、検索最適化のなかで最も直感に反する作業です。ページが増えれば流入も増えるはずだ、という感覚が誰の頭にもあるからです。記事を公開する行為は資産が積み上がっていくように感じられます。ところが記事を消す行為は、誰かが費用を払って作らせた仕事をそのまま捨てているように感じられます。だからこそ、削除は最後まで先送りにされ、増え続けるページの山だけが残ります。 削除が効く仕組みは単純で、自分のサイトのページ同士が競合しているという一点に尽きます。自分のページのうち二本が同じ検索意図を狙っていると、本来なら一本に集まっていたはずの評価が二つに割れます。そして、どちらを見せるかを判断...
API のバージョン管理：いつ壊し、どう壊さないか
API のバージョン管理をめぐる議論は、たいてい間違った側から始まります。バージョン番号をどこに置くか、という話です。実のところ、それはこの主題のなかでもっとも結果を左右しない決定です。本当に重要なのは、そもそもどの変更が新しいバージョンを必要とするのかであり、ほとんどのチームはここを、油断する方向に読み違えます。純粋な追加にすぎないと信じたものを出荷し、どこかのクライアントが壊れるのです。 使える考え方はこうです。あなたの API は、呼び出す側が何を当てにしてよいかについての約束にほかなりません。まっとうな呼び出し側が当てにしていたものを無効にしてしまうなら、その変更は破壊的です。そして呼...
提案依頼書（RFP）の書き方：比較できる見積もりを得る
ソフトウェアの提案依頼書、いわゆるRFPは、本来、複数の発注先候補を横並びで比較できるようにするための文書です。ところが実際に出回っているものの多くは、その逆の結果を生んでいます。解決策を細かく指定しすぎて回答の幅を縛る一方で、金額を出すために誰もが必要とする情報のほうは抜け落ちているからです。結果として、桁が一つ違うほど開いた五つの見積もりが並び、どれも形式上は要求に答えているのに、同じものを測っている見積もりは一つもない、という状態になります。 よくある説明は、ベンダーが言葉を濁しているというものです。それが当たっている場合もたしかにあります。しかし圧倒的に多いのは、その文書に書かれている...
ソフトウェア保守費用：誰も予算に入れないもの
ソフトウェア保守費用は、成功したはずのプロジェクトを十八か月後に気まずい話し合いへと変えてしまう数字です。開発そのものは予算が組まれ、承認され、無事に納品されました。ところが本番稼働のあとに起きることは「サポート」という一言でまとめられ、誰かが勘で置いた金額があてがわれます。そしてその金額は、ほとんどの場合あまりにも小さすぎました。 理由は不注意ではなく、構造にあります。開発には値段をつけられる範囲があります。保守には範囲がありません。まだ起きていない出来事によって中身が決まるからです。脆弱性が見つかるライブラリ、取引先が変更するアプリケーション連携の仕様、誰も想定しなかった状況に行き当たる利...
追加のリソースやコラボレーションをお探しですか？
深い技術的ガイダンスが必要な場合、プロジェクトで協業したい場合、または専門的な見解を要する課題がある場合、ぜひお話しさせてください。あなたの目標達成にどのように貢献できるか、一緒に考えましょう。
お問い合わせ