どんな理由でも100%返金保証のハード・ソフト開発、きもと特急電子設計 Kimoto express electronic design

レンタルCTOコース

レンタルCTOコースは、月々9万円+税(1ヶ月単位で必要な期間だけ)で、月1.5時間×2のzoom打ち合わせとメールサポートをおこなうコースです。
必要に応じて、仕様書代行、設計代行、技術課題の解決、コードレビューなどをおこない、御社の開発をスピードアップします。
また、必要になった場合は、同じ料金で、マイコン何度でも試作検証+コンサルサービスに移行することができます。
最初の1ヶ月は無料で、いつでも解約可能、解約された場合でも仕様書などはそのままお使いいただいて構いません。

リスク管理と、段階的な開発計画

重要なのは、5ヶ年計画を作ってその通りに進めてはいけないということです。
せっかく社内の開発パワーを使うのですから、小さなゴール(典型的には2週間ごとにリリース)を作り、常に動いているものが見れる状態を維持してください。
このとき、重いが重要な機能をうまく分割しないと、動くものを2週間で作ることができません。
もちろん、作った結果うまくいかないことがわかることもありますので、その場合に手戻りが少なくなるような進め方とし、結果がわかったときは進め方を組み立て直します。
要はリスク管理なのですが、技術的なリスクのほかに、ビジネス上のリスクもあります。ですので、リスクの大きいものに早く着手してリスクが小さいことが確認できたら、今度は残っている大きいリスクに視点を移すようなことが必要です。
これを経験豊富なレンタルCTOがおこなうことで、プロジェクトを早く安全に完成させることができます。

エンジニアの本音を引き出す

多くの人が、エンジニアからの重要な情報を無視したり、言いにくくなるような空気を作っているのは、とても驚きます。
「この機能を何とかして4週間で作ってほしい」とか、ひどくなると「この機能は4週間で作ってください」という言葉が平気で聞かれます。
「この機能が間違いなく作れるには、あなたの予想では何週間くらいかかりますか」「この機能をどうしても4週間で作りたいとしたら、何を妥協しないといけませんか」「その場合、4週間でできる可能性はあなたの予想ではどれくらいですか」と聞けば、はるかに信頼性の高い情報を得ることができます。
そして、この情報を元に、限られたリソースをどう使うかがマネジメントの腕の見せどころです。ここでもレンタルCTOがお力になります。

仕様書・設計書

エンジニアが読む文書は、成果をあげる上でエンジニアはどんな情報を必要とするかをわかっている人が書く必要があります。
例えば、最大データ数が100件でいいなら1日で作れるが、1000件扱えるものを作るには1週間、ただし100件版を作ってから残りの部分も作り、あとで1000件に対応するには(「残りの部分」も直さないといけないので)1ヶ月かかるとします。
それを知っている人が文書を書けば「100件でいい」「いまは100件でいいが、2ヶ月後のバージョンでは1000件必要」「最初から1000件でないといけない」のように明記できます。
これを、知らない人が「念のため1000件必要」と言ってしまい、同じような意思決定ポイントが10箇所あるとすると、10日でできるはずのものが10週かかってしまいます。逆に「とにかく急ぐので100件でいい」といって、後で1000件に変更すると、10週で済むはずのものが10ヶ月かかってしまいます。
日本語を英語に翻訳する人は日本語と英語の両方を知らないといけないのと同様、プログラマのための仕様書や設計書を書く人は、その製品が使用される市場と、プログラムの、両方の知識が必要だということです。これもレンタルCTOが代行します。

コードの自動生成や、テストの自動化

開発案件によっては、例えばExcelなどで作った表からプログラムを自動生成することで、効率化できる場合があります。Excelの表を更新することでプログラムの動作を変えるようなことができるため、最初は大変ですが、トータルで開発が早く進みます。
同様に、テストも自動化できる部分を自動化しておくと、少しでも修正したらテストを走らせることができるため、問題を早く見つけることができます。
一方で、このような開発投資は保守の際に重荷になることもありますから、開発投資をどれくらいおこなうかの判断は、投資とリターンのバランスを見ておこなう必要があります。これもレンタルCTOが適切な判断をおこないます。
また、作った本人がテストすると抜けが発生しやすいため、レンタルCTOがテストシステム開発を代行することもします。

コード・回路図などのレビュー

成果物が問題なく動いている場合でも、いわゆる「悪い習慣」が隠れている場合があります。悪い習慣というのは、将来問題を引き起こしたり、めったに起きないシチュエーションで不具合を発生させたりします。
具体的には、例えば誤解しやすい名前があります。「send_read_command」という機能は「リードコマンドを送る」のか、それとも「コマンドを送信して読み出す」のか、名前からは判断しにくく、プログラム中で間違って使われている可能性があります。ひどくなると「sendread_command」が送受信で「send_read_command」が送信のみとか、「send」と「put」で機能が違うため使い分けないといけない、みたいなものもあります。
回路図だとよく「TX」が「送信」、「RX」が「受信」の意味で使われますが、「マイコンの送信」を「無線モジュールの受信」につなぐケースで「RF_TX」なんて名前をつけると、マイコンから無線モジュールに送信するのか、それとも無線モジュールがマイコンに送信するのか、混乱の元になります。これを「PIC to RF」を縮めて「P2R」などにすると、マイコン側にも無線モジュール側にも「P2R」と書けて意図も明確になるため、このようなトラブルを避けることができます。
こういったところもレンタルCTOがチェックやアドバイスをし、トラブルを未然に防止します。

技術課題の解決

予期しない問題にぶつかったときも、経験豊富な人であれば、解決手段や、一時的な回避手段など、複数の選択肢を用意できるものです。
例えば一部の機能をシステム外で実現する、初期段階では特定の環境だけで使用するなどです。
もちろん最終的にゴールにたどりつけないといけませんから、両立する形にする必要があります。
これをエンジニアに押しつけず、レンタルCTOが役割分担することで、エンジニアは得意な作業に集中することができ、生産性を上げることができます。

レンタルCTOにご関心がありますか

メールか電話で、zoom相談をお申し込みください(お問い合わせ)。
最初の1ヶ月は無料で、いつでも解約可能、解約された場合でも仕様書などはそのままお使いいただいて構いません。

レンタルCTOコース

リスク管理と、段階的な開発計画

エンジニアの本音を引き出す

仕様書・設計書

コードの自動生成や、テストの自動化

コード・回路図などのレビュー

技術課題の解決

レンタルCTOにご関心がありますか

一緒にお困りごとを解決しましょう。