SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

初めての省庁系システム開発

初めての省庁系システム開発(第1回)~誤字・脱字を侮るな~

それぞれに文化が存在する

  • このエントリーをはてなブックマークに追加

 この連載では、省庁系システム開発において、著者が経験したプロジェクトを例として、どのような技術を使用したかだけでなく、省庁系システム特有の掟などを書き綴っていきます。本記事では、省庁系特有の守り事について紹介します。

  • このエントリーをはてなブックマークに追加

はじめに

 一次請けであれ二次請けであれ、または準委任であれ、省庁系システムの開発は、初めて経験するものには戸惑いを与えます。金融系システムや流通系システムなどを経験した技術者にとって、知っておかないとうまく事が運ばないことがあるので注意が必要となってきます。技術面は後ほど紹介することとして、著者が4回の省庁系システム開発で学んだことは次の点です。

  1. 誤字・脱字を侮るな
  2. コミュニケーションルートを確保せよ
  3. 受領資料の意味を熟考せよ
  4. 査読すべき資料を早急に収集せよ
  5. 省庁の影にコンサルタントの気配あり
  6. 自社に馴染んだ開発手法に持ち込め

 第1回目の今回は、「誤字・脱字を侮るな」について解説していきたいと思います。

誤字・脱字は嫌われる

 どのような業界であれ、誤字・脱字は嫌われます。特に金融業界などはその傾向は高いと思われます。しかし、それ以上に省庁系のシステム開発での誤字・脱字は侮ると痛い目にあいます。少しくらいの間違いは大目に見てくれるだろうという方(私を含めた楽天家の人)は特に注意してください。誤字・脱字があるだけで、省庁の方は内容まで読んではくれません。内容にたどり着くまでの方便として誤字・脱字を取り除く必要があるという意識で望むのがいいでしょう。

 これは媚びへつらうわけではなく、そのような文化が省庁には存在するのだという認識の方が正しいと思います。省令に間違った表現があってはならないのは誰でも想像できるはずです。記憶に新しいところでは年金法に誤字・脱字が多量に見つかり、お偉いさんが平謝りしていたことです。このような仕事をしている人から見ると誤字・脱字はあってはならないということになります。一般に省庁内では「読み合わせ」という作業の中で、何度も誤字・脱字のチェックが行われていることを念頭においておきましょう。

 このような文化の中で仕事を行う以上、誤字・脱字が存在する場合、それは推敲が不十分であるから受け取る状態には至っていないと判断されても仕方ないと考えられます。

 では、なぜそれほどまでに神経を使う必要があるのでしょうか?それは「情報の陳腐化」です。一度誤字・脱字の提案・提言あるいは文書による質問をしてしまうと、それを修正したところで、すぐには受け取ってもらえないようになります。タイムリーさが重要な提案・提言にとっては命取りになるのです。

図1:誤字・脱字によるリスク
図1:誤字・脱字によるリスク

 当然のことですが、成果物については念には念を入れて提出する必要があります。

誤字・脱字を恐れるな

 たった今、「誤字・脱字は嫌われる」と書いたばかりなのになんだ?と思われた方も多い方と思います。実は、上で「提案・提言」と書いたことが少しヒントとなっています。すべてがすべて神経質になることはないということです。

 例えば、要件定義や基本設計では多くのQAや課題が発生し、お客様と共有する必要がある場合、それは急を要します。このような場合、失敗を恐れるあまり、疑問点・問題点を抱え込んでしまうと、工程自体が失敗しかねません。このあたりの事を当然省庁の方もご存じと見えて、提案・提言などよりも若干許容度が高いように思われます。あくまでも若干です。それでも心配だという方は、誤字・脱字専門にチェックする係を立てるのも1つの手であると思います。

図2:誤字・脱字専門のチェック係を用意する
図2:誤字・脱字専門のチェック係を用意する

 実際、著者のプロジェクトでは規模が大きかったということもあり、相当なベテランをその係に充て、その他のメンバは本来の仕事に専念できる体制を取ることで無駄な神経を使わないような工夫を施しました。省庁系に限らず、QAには根拠や求めていることが何かを記述することが必要です。何のために質問するのか。質問した結果どうなるのか?その質問でお客様に何を期待しているかなど明確になっていると回答が得られやすくなります。私が経験した省庁系プロジェクトではQA票の中に、前提条件、根拠、依頼事項を明確に項目として設け、迅速な回答を得られるよう工夫しました。

それでも戸惑うことがある

 「嫌われる」と書いたり、「恐れるな」と書いたり忙しい限りですが、時には思わぬ落とし穴に陥ることがあります。例えば、UMLのユースケース図で「〇〇〇を処理する」とユースケースに書いた時に、「主語は何か」と聞かれたとしても不思議ではありません。そこから伸びているアクターが主語に決まっているのは技術者にとっては当たり前ですが、知らない人にとっては分かりづらいものです。主語を明確にするという文化の中で、へんてこな人形の絵が線で結ばれているのですから理解できないのも無理もありません。かと言って、ここで諦めればいいというわけにもいきません。

 ここで後日公開予定の「省庁の陰にコンサルタントの気配あり」が役立ちます。コンサルタントと省庁は、状況により、別と見なしたり、同じと見なしたりする必要がありますが、ここでは同じと見なして進めることで道を開くことができます。コンサルタントとの良好な関係は要件定義時には特に重要となります。

 次回は、コミュニケーションにまつわる失敗と、うまく立ち回るためのコツを紹介します。

修正履歴

この記事は参考になりましたか?

  • このエントリーをはてなブックマークに追加
初めての省庁系システム開発連載記事一覧

もっと読む

この記事の著者

チャーリー・佐藤(チャーリー・サトウ)

ここ10数年、プロジェクト・マネージャやソフトウェア・アーキテクトという一見相いれない仕事を繰り返してきました。プログラミングも大好きで、自宅ではいろんな言語を楽しんでいます。年齢も40過ぎ、徹夜の連続では耐えられないようになってきました。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/4025 2009/06/22 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング