CaFeterria

ブログ

開発手法が異なるシステム間におけるインタフェース開発の進め方

2024.12.19

    私が参画しているプロジェクトでは、基幹システムはアジャイル型とウォーターフォール型を組み合わせたハイブリッド型、周辺システムはウォーターフォール型で開発している。

     

    このように開発手法の異なるシステム間のインターフェース開発を行う場合、基幹システムと周辺システム間の積極的なコミュニケーションによってマイルストーンを同期したうえでスケジュールの調整を図り、自システムの開発を遅延させないよう対応することが重要になると考える。

     

    私が担当する人事システムとの連携では、基幹システム側の要件検討が遅延しており、開発遅延リスクを抱えていた。
    そこで、基幹システム側には、人事システムとして要件確定が必要な時期を提示し、その期限内に要件が確定できないか調整しつつ、人事システム側とは、基幹システム側からの要件に依存しない機能を先行して開発する方向で対応した。

     

    両システムの間に立つ調整役として、今後も双方の進め方や作業内容を理解し、密にコミュニケーションを取りながら進めていく所存である。

     

    【投稿担当:G.F.】

    何がペーパーレス化を阻むのか

    2024.11.29

    打合せの度に印刷される資料、積み上がった書類に埋もれた机。ペーパーレス業務の浸透が進んでいない企業には、従来の仕事のやり方とのギャップや、そもそもやり方を変える事それ自体への抵抗等、様々な理由があり変革が困難と言われていますが、本当にそうでしょうか。

     

    例えば、経理部門の日次業務の一つである伝票と証憑の突合確認では、審査の品質を維持しつつある程度のスピードで処理する必要があり、証憑の確認に際しての“見やすさ”は重要な要素です。

    そんな中で単純にペーパーレスの推進だけを掲げても、ひとつのPC画面でウィンドウを切り替えたり分割しての作業となり、かえって業務効率が低下しかねません。

     

    だからといってペーパーレス化が不可能というわけではなく、例えば上のケースではサブモニターを用いることで紙印刷した場合の文書の見やすさに近づける等、対策は考えられます。適切な支援を行うことでペーパーレス化は十分に実現可能であると考えます。

     

    【投稿担当:W.K.】

    効率的な連結会計学習のススメ

    2024.10.25

    最近、ホールディングスと名の付く会社が増えてきました。

    子会社を複数持ち、それぞれで異なる事業を運営しています。

    子会社毎ではなくグループ全体の業績を把握する時に重要となるのが連結会計です。

     

    一方で、連結会計は専門性が相当に高く、とっつきにくいというイメージを持たれている方が多いのではないでしょうか。

    どのように短期間で体系的に学習を進めればよいか迷われる方が多いと思います。

    そのような方に、私自身が連結の知見向上に役に立った書籍をご紹介します。

     

    「図解でざっくり会計シリーズ5 連結会計のしくみ(第2版)」

    新日本有限責任監査法人(2014年)、中央経済社

    →図とイラスト付き、原則1ページで解説されており、最初に手に取る本としておすすめ

     

    「図解&設例 連結会計の基本と実務がわかる本」

    飯塚幸子(2014年)、中央経済社

    →連結会計業務の内容と、具体的にどのような仕訳を行う必要があるのかを理解したい方におすすめ

     

    「新セグメント会計基準対応 連結経営管理の実務 予算の立て方から円滑な導入まで」

    中田清穂、三浦直樹(2008年)、中央経済グループパブリッシング

    →少し古いですが、連結による経営管理の考え方を学べます。

    制度連結だけでなく管理連結、予算連結までも網羅しています

    【投稿担当:K.N.】

    要件定義フェーズの重要性

    2024.9.30

    最近、十数年ぶりに要件定義フェーズの重要性を再認識する状況に遭遇しました。

    (詳細は割愛しますが、クロージングフェーズで要件の認識相違が発覚)

     

    要件定義フェーズは、操作マニュアルやイメージ図等を使った所謂「紙芝居」で議論が進むケースが多く、認識相違が発生しやすいフェーズと考えています。

     

    紙芝居を見ながら実際に動作しているシステムをイメージできるようにコミュニケーション頻度・密度を上げつつ、様々なモノを活用しながら進めたつもりでしたが、少しだけ足りていなかったなと反省しています。

     

    「準備8割・実行2割」という言葉がありますが、PJの”準備”にあたる要件定義フェーズが非常に重要であることを改めて肝に銘じていきたいと思います。

     

    投稿担当:C.I.】

    業務プロセス理解の速度を左右するもの

    2024.8.28

    特殊な業界のプロジェクトが始まりました。

    業務プロセスの理解にかなりの時間がかかるのではないかと心配していましたが、意外にもスムーズに理解できました。

    おそらく、最初から「業務の目的」がなんとなく見えていたからだと思います。

     

    「業務のやり方」(業務フロー)は業界によって大きく異なりますが、「業務の目的」はそれほど変わりません。

    たとえば、購入・販売・在庫管理・資金の記録(不正やミスの防止)といった基本的な目的は、どの業界でも共通しています。

     

    そのため、「業務の目的」が分かれば、業務のあるべき姿やよくある問題、それに対する解決策も自然と見えてくるのです。

    これまで業界や業務を限定せずにさまざまなプロジェクトを経験してきたことに感謝しました。

     

    【投稿担当:K.G.】

    ◆レポート配信のお知らせ◆

    2024.7.22

    『Excelがデジタルサーバントになる日』 執筆者:遠藤
    https://www.crossfields.co.jp/cms/wp-content/uploads/2024/07/magazine_vol45.pdf

     

    MicoroSoftのExcelといえば、学生から社会人まで広く利用され、ビジネスツールとしても馴染み深いものかと思います。
    DXとしてマクロによる半自動化やRPAとの連携等、拡張しての利用も目にする機会が多くなりました。

     

    本稿では、長くシステムの設計・運用に関わってきた弊社エキスパートが、

    表計算ソフトの起源、Excelが台頭するまでの歴史を振り返りつつ、

    近年Excelに拡張された機能から見る、AIと絡めた更なる活用の道、

    次世代の「自動化」を担うツールとしての展望について論じます。

    体制の不備をどう乗り越えるか

    2024.7.19

    例えばデータ連携テストをする際、連携元システム、EAI、連携先システムと、システムごとに担当者を配置する体制がセオリーかなと思います。

    しかし、セオリー通りでは上手くいかないこともあります。

     

    私もセオリー通りの体制でデータ連携テストを実施し、なかなか解消されないエラーに四苦八苦する経験をしました。
    EAI内のマッピングが複雑化・ブラックボックス化する中、連携元システム担当としてEAIの仕様を深く理解しないままテストを進めた結果、EAI側でエラー発生時に主体的に原因究明できず、EAIチーム任せとなり解決に時間を要してしまったのです。

     

    もし体制として、システムを跨いで横断的な確認を行う担当者がいれば、上記のような苦労は無かったかと思います。

    しかし実際はそのような担当者は不在でした。
    テストをスムーズに進めるためには、担当システムを飛び越えて仕様理解を深める等、こうした体制の不備を姿勢でカバーしていくことが大切だなと感じました。

     

    ※EAI:複数の異なるシステムを連携させ、データやプロセスを統合する仕組み、またはそのツールのこと

    【投稿担当:T.O.】

    海外プロジェクトにおけるコミュニケーション

    2024.6.19

    近年グローバル化が進む中、世間では外国人とコミュニケーションをとるときには、

    何か特別な技術を身に着けないといけないかのように語られる印象がある。

     

    しかし、グローバルプロジェクトに1年間携わった実感としては、

    必ずしもそうではないと感じている。

    というのも、コミュニケーションの本質は漏れなく論理的に簡潔に伝えることであり、

    それは相手が誰であれ変わらないと考えるからだ。

     

    実際、私が参加したグローバルプロジェクトでは、

    多くのメンバーが相手と丁寧に交流しようとしていた。

    もちろん日本人と外国人で対話に対する意識の違いは存在すると思う。

    例えば外国人は発言に対するハードルが低くフランクに話す傾向があるが、

    日本人は必ずしもそうではない。

     

    日本人として、普段より発言量を増やしたり、

    明確な意思表示をするといった心がけは必要だと思うが、

    それらも漏れなく論理的に、簡潔に伝えるという本質があってのことで、

    一番重要なのはそこだと思う。

    【投稿担当:C.W.】

    テスト工程の重要性

    2024.5.16

    皆さんはユーザが安心して利用できるシステムを構築するには、何が重要だと思いますか。

     

    導入実績、要件定義、セキュリティ・・・色々な観点が挙げられると思いますが、システム開発の最後の砦として、テスト工程が非常に重要であると考えます。

     

    特に1020年以上利用されている、いわゆるレガシーシステムとの連携が必要となる場合は、仕様がブラックボックス化していることが多く、改修した機能が他の機能に思わぬ影響を及ぼすことや、未知の仕様によって想定外の挙動になることもあります。

     

    そのため、本番同様の検証環境を用意し、開発者の思い込みを排除した網羅的なテストを行うことが最低限必要です。

     

    具体的には、第三者によるテスト仕様書レビューやツールを用いたテスト自動化、また、過去の失敗事例などナレッジの共有を図ることで、テストおよびプロジェクト全体の品質向上に寄与すると考えます。

    投稿担当:T.N.】

    システムベンダの提案辞退を防ぐためには

    2024.4.18

    近年はITリソースの逼迫に伴い、

    システムベンダに提案を依頼しても辞退されるケースが増えています。

     

    私自身、プロジェクトの中でベンダの提案辞退を受け、

    候補が限定された状況で選定を行った経験があります。

     

    その経験からベンダに提案を依頼する際は、

    「要件を具体化する」

    「要件に優先度を付け、優先度が低い要件は代替案を提示する」

    「提案前に直接重要な要件とその実装イメージのすり合わせを行う」など

     

    ベンダが正しくプロジェクトのリスクを評価できる情報を伝えることが、

    重要だと身をもって認識しました。

     

    【投稿担当:S.K.】