カテゴリー
development

ソフトウェア開発のお仕事

以下で紹介するのは当社人材募集ページで当社の開発の仕事の進め方を説明するために掲載している記事です。担当者がひとりで開発を進めている前提で解説していますが、基本的な進め方としては規模の大きくない開発プロジェクトの進め方として一般的なものです。

特にあまり開発経験の無い方には参考になると思い、以下にそのまま掲載します。

ご興味があれば 当社人材募集ページまで


インフォテックでは受託開発ビジネスを「カスタムソリューションサービス」と呼んでいます。文字通りお客様のニーズに合わせたソリューションを提供します。

以下では、インフォテックのソフトウェア技術者(業界ではSEやプログラマと呼ばれることの多い職種)の仕事内容を説明していきます。

当社の受託開発のプロセスそのものはごく常識的なものです。最大の特長は基本的にひとりでヒアリングから保守までのプロセスを担当することです。

つまり、当社の技術者はSEであり、プログラマであり、時にはコンサルタントでもあるのです。当社のエンジニアをソフトウェア技術者と呼ぶ理由のひとつです。

それでは当社の開発のプロセスに沿って仕事の内容を説明していきます。

ヒアリング

全てのプロジェクトはお客様の話を聞くことから始まります。既におつきあいのあるお客様の場合は、まず担当の技術者に声がかかります。要求が非常に具体的な場合もありますし、まったくあいまいな雑談のような相談もあります。

担当技術者はお客様の要求を分析し必要な材料を集めます。要求が具体的な場合には早速提案の作成を開始します。あいまいな場合にはいつまでにどのような提案がほしいのかをお客様に確認し、材料を集めなおします。

また、お客様の問題解決のアイデアが浮かんだときや他のお客様で面白いソリューション開発をしたときなどには私たちのほうから積極的に提案するようにしています。時には2年越し、3年越しの提案が実現することもあります。

提案

ヒアリングした材料をもとに、システムの概要を設計し、開発費の見積りを行い、提案書をまとめます。私たちはこの提案書を開発仕様書と呼んでいます。開発仕様書はいわゆる機能仕様にスケジュールや動作環境など開発及びシステムに関連する事項を加えたものです。

開発仕様書の内容は提案期日、システムの性格、お客様の状況などによりかなり異なります。場合によっては、主要な画面を作成してしまうこともありますし、基本的な機能や制限を記述するだけの場合もあります。

重要だと思われることは詳細に、そうでないものは簡単にあるいは省略して説明することになります。システムを成立させる基本的な要件の把握がプロとしての腕のみせどころです。

私たちは開発仕様書に記述したソフトウェアの開発を一式いくらという金額で提示し、原則として工数等の詳細は開示しません。お約束したものはいくら工数がかかろうが責任を持って納期までに提供するという請負契約の基本に立っています。

提案時に全ての仕様を明確にできないという前述の前提に立てばこれは相当のリスクになるはずなのですが、幸いにして今までのところだいたいうまくいっています。

開発

提案がお客様に承認され注文書が出ればいよいよ本格的な開発に入ります。最初に要求を再確認し、提案時に充分確認できなかった仕様の詳細をつめていき、必要に応じ仕様書を修正、追加していきます。

仕様変更等により当然予想工数が変わってきますが、よほどのことが無い限り、他の仕様を簡略にしたり、開発手順を工夫することにより提案時の予算に納めるようにします。

このプロセスが終わると仕様凍結とし、その後の仕様変更は原則として受け付けられないことをお客様に伝えます。

仕様が固まれば本格的な開発を始めます。仕様打合せの段階で基本設計や詳細設計の一部は進めておきます。画面仕様も大枠は決まっているはずです。各モジュールの詳細設計とコーディングに入ります。

一人で作業を進めるので詳細設計とコーディングは実際には混然となって進められます。各関数、モジュールについて適宜、単体テストを行いながら開発していきます。

動かしてみないと詳細な仕様が決定できないようなアプリケーションでは、プロトタイプを作成してお客様に確認してもらうケースもあります。プロジェクトの 規模が大きくないのでプロトタイプは最終的な実装につながるように工夫をします。プロトタイプを作らなくても開発途中で画面を確認してもらうことはよく行います。

パンを運ぶアリ2

各モジュールが完成すると総合テストを行います。実際には開発と並行して適宜テストを行っていますのでこの段階でのプログラムはほとんど完成状態の品質となっています。

ここではあらかじめ定めたテスト計画に従い、システム全体としての動作を確認します。必要に応じ他のメンバーの協力を得てマルチユーザアクセスなどのテストを行います。

納品

社内テストが終了するとお客様のシステムにソフトウェアを設置、関連ドキュメントを納品します。そのまま本稼動に入るケースから何ヶ月もテストするまでシステムにより実機上でのテスト期間はさまざまです。

設置作業はアプリケーションのみでOS等のシステム環境はお客様サイドで準備していただくというのが基本的な前提ですが、状況により、基本ソフトや ミドルウェア、ネットワーク設定も含めて当社で担当してしまうこともあります。お客様に動作を確認していただいた時点で検収書にサインをいただきます。

ドキュメントは、通常、ユーザー向けの操作説明書のほか設計仕様書を作成し納入します。設計仕様書はモジュール構成や各モジュールの仕様、データベース構成などを記述したものを納入します。

他の人がプログラムの保守ができるレベルで必要にして充分なものを提供できるように心がけています。ソースコードについては、基本的なコーディング規約を定めています。

保守

検収が終わるとシステムは晴れて本稼動ということになり、保守のフェイズに入ります。保守は原則としてそのシステムを開発した技術者が担当します。保守ではアプリケーションに起因するバグへの対応が建前ですが、原因があいまいな場合の切り分けなどにも対応するほか運用や利用方法についてもお客様の相談に応じます。

アプリケーションのバグについてはほとんどの場合、その日または翌日に直して修正版をお届けします。このへんは開発者が保守をしている強みです。

検収後、1年を経過すると1年ベースでの保守契約をお客様にお願いしています。ほとんどのケースで保守契約を結んでいただいています。これも担当技術者の担当になります。

また、運用開始後、システムの効果が確認されれば、さらなる仕様追加や変更の要求により、2次、3次の開発プロジェクトに発展することもよくあります。

レビュー

提案時には、見積が過小/過大ではないか、技術的に妥当なシステムか、代替案はないか、リスクに対応しているかなどの観点からレビューを行います。 経験の少ない技術者には先輩技術者が設計、開発などの各フェイズで適宜、レビューと指導を行います。参加する技術者の増大に応じ、今後、レビューをより組織的に運用していくことが大切だと考えています。

以上が受託開発業務の概要です。

イメージがつかめたでしょうか?ご質問がある場合は気軽にこちらまでお問合せください。

製品ビジネスもやっています

ところで、当社はソフトウェア製品の開発、販売も行っています。

PDFlibは、ドイツPDFlib社が開発したPDF文書をプログラムから生成するライブラリーソフトウェアです。同種のソフトの中でも定番とされる世界的なソフトウェアです。当社は日本の正規代理店としてPDFlibを独占的に販売・サポートしています。

日本を代表する大手メーカー、SIerからユーザ企業、中堅のソフトウェアハウス、個人のコンサルタントに至るまで七百社を超えるディベロッパーにご愛顧をいただいています。詳細は当社サイトPDFlibのページを参照してください。

PDFlibイラスト

販売契約をPDFlib社と直接結んでいるので、仕入など販売業務や技術サポートに関連して直接ドイツと(幸いにしてドイツ語ではなく英語ですが)やり取りすることもよくあります。

製品ビジネスは、受託開発における技術的な成果や蓄積を製品という形で収益化し、ビジネスをより安定で きること。製品の評価・企画やサポート業務により技術者により幅の広い活動の機会とキャリアパスを提供できることがメリットと考えており、今後も推進していきます。

きちんと受託開発をできるようになることがまず基本ですが、場合により製品ビジネスを含めより広い観点でのソフトウェア関連ビジネスに取り組んでもらう可能性もあります。このような分野に挑戦したい方も歓迎します。

【インフォテックの人材募集】次世代のインフォテックで活躍する仲間を探しています

カテゴリー
development

内製化に舵をきる星野リゾート

ホテル業界で革新を続ける星野リゾートがシステムの内製化に大きく舵をきっています。

星野代表は従来は「餅は餅屋」ということで内製化に否定的だったようですが、システム部門の提案を受け入れた形で開発力の強化に踏み切ったとのことです。

星野代表は内製化のねらいを、1)開発スピード、2)システムの全体最適化を上げていますが、システム部門が全体最適を意識し、社内エンジニアが現場にも意見を言うようになったことに満足しているようです。

現在、約30人の情報システム部門は半数が中途採用のエンジニア、半数が現場のスタッフ上がりという構成になっていて、業務知識とシステムノウハウの相乗効果を上げているとのことです。

また外部向けシステムはコーディングで社内システムはローコードという明確な区分のもとにシステム開発を進めているのも注目すべき点です。ローコードのツールとしてはサイボーズのkintoneを使用し、専門コンサルのサービスも活用しています。

ここ数年、エンドユーザ企業のシステム部門強化や内製化は日本のDX推進のための大きな課題として関心を持たれていますが、星野リゾートのケースはその先進的な試みといえるものでしょう。

本項は Facebook インフォテック公式ページ に2021年6月2日に掲載した記事を再掲しています。

【インフォテックの人材募集】次世代のインフォテックで活躍する仲間を探しています

カテゴリー
development

開発プロジェクトを壊す顧客担当者 “X”

システム開発の責任を問う訴訟第2審で顧客である野村證券が逆転敗訴したと5月12日の日経クロステックの記事が伝えています。

1審判決では、開発を受託した日本IBMに契約不履行で約16億円の支払を命じたものが、2審判決では野村證券側の請求を棄却、さらに未払の業務委託料の日本IBMへの支払を命じた真逆の判決となりました。

決は要件決定後も野村側が再三の仕様追加を行い、それがプロジェクトの遅延を招いたもので、その責任は顧客側にあるとのことです。記事ではその仕様追加を主導した顧客側担当者の”X”氏の言動が問題であったと指摘しています。”X”氏は概要設計頃から仕様変更や追加を連発し、プロジェクト見直しの際の仕様削減にも強く反対したようです。

開発が始まり、システムの形が見えるようになるにつれ、仕様変更や追加を行う”X氏”は当社のプロジェクトでもたまに出会います。開発を始める前に最終的な仕様書を説明、了解をもらっているはずですが、その時には十分検討をせず、あとで気づいたり、社内の確認が遅れたというケースがほとんどです。

自分の責任を感じて謙虚に言ってくる場合は可愛げもありますが、中には言ったことを言わなかった、そういう意味ではなかったといった理由にならない理由をあげ強硬に要求を通そうとする強烈な”X氏”がまれに現れます。その場合、言うことを聞いているとプロジェクトそのものが成り立たなくなるので、失注覚悟の厳しい交渉を行わざるを得ません。辛いですね。

最近はこの種の係争で、顧客側の責任を問う判決も増えているそうで、今回の判決もまじめに開発を行っている企業には追い風となることを期待します。

本項は Facebook インフォテック公式ページ に2021年5月26日に掲載した記事を再掲しています。

【インフォテックの人材募集】次世代のインフォテックで活躍する仲間を探しています

カテゴリー
development

IT企業に丸投げしたら、サービスに思想がこもらない

最近メディアでもよく紹介される[食べチョク」の運営会社ビビッドガーデン社長の秋元里奈氏がサイトやシステムをIT技術者を雇い内製している理由として述べたものです。

大手企業でもベンダーに丸投げすることが多かった日本のシステム開発も最近ようやく内製の動きが出てきています。DXへの関心が高まるなかで海外の企業がIT技術者を大量に獲得しようとしていることも契機になっているものと思われます。

日経クロステックの2月の記事では「ITの多重下請け壊す︖ ⽇本マイクロソフトが内製化促進」という見出しでマイクロソフトがユーザー企業のAzureの利用を支援するサービスを発表したことを報じています。

このようにユーザ企業内製化の機運は高まっていますが、その実現はとてもハードルが高いのではないかと危惧されます。

その大きな理由となっているのは多重下請構造を前提とした従来の開発の進め方です。内製の主なメリットは現状をよく理解したIT技術者が素早くシステムを開発し、問題が出ればすぐに変更を加えていくことです。いわゆるアジャイル型の開発スタイルが必然になっていきます。

ところが、従来の階層型開発はその真逆のスタイルです。要求をするひと、仕様をまとめるひと、設計するひと、プログラムするひと、テストをするひと、運用をするひとなどなど、分業を前提としています。このスタイルの問題点(プロジェクトあるある)は当社サイト記事「今の仕事に満足していますか?(ソフトウェア技術者編)で詳しく紹介しています。

階層型開発の問題点はいろいろありますが、大きな問題はユーザの要求を理解しそれを自分で開発できる技術者の育成が進まないことです。当社では従来、ヒアリングから保守までひとりで担当するスタイルで受託開発をしていますが、本当の意味でそれができるようになるには、やはり10年位はかかるのではないかと感じています。

ただでさえDXが遅れている日本の企業が忍耐強く技術者を育成することができるかどうかとても心配ですね。

本項は Facebook インフォテック公式ページ に2021年5月12日に掲載した記事を再掲しています。
カテゴリー
development

ココアの不思議

4月16日にコロナの接触確認アプリ「COCOA」の不具合放置に関する厚労省の内部調査が公表されました。

同日の日経新聞電子版では「多重委託、無責任の連鎖 COCOA不具合の重い教訓(有料記事)」という見出しで厳しく批判しています。

報告書を見ると、テスト環境がないのでテストしないままリリースしたなど、驚くべき実態が記述されています。問題のバグは、濃厚接触者の判定に関わる iOS とAndroidの提供APIの仕様の差を認識していなかったことによるとのことで、アプリの中心的な仕様を開発者が認識していないままコードをいじったことを示唆しています。

もともとの開発を行った「COVID-19Radar」もネット上で批判されているようですが、ボランティアで開発を行ったエンジニアに厚労省や仕事を引き継いだ事業者はもっとリスペクトを持つべきではなかったかとも感じます。

当初の契約で6社が重層的に分業し、総額3.9億円のプロジェクトになっている点も気になります。当社では他社が通常、4・5人のチームで開発するような業務アプリを通常ひとりのエンジニアがヒアリングから開発・保守まで担当するスタイルで開発しています。これで結構うまくいっています。

アプリの性格や運用形態からみて、少数の優秀なプログラマーのチームで開発する方式のほうがうまくいったような気がします。もっとも優秀なプログラマー自体が不足していますが。

本項は Facebook インフォテック公式ページ に2021年4月21日に掲載した記事を再掲しています。