IT専門家以外の人と話す時の資料の書き方

目的

「業務部門と仕様のすり合わせをする」「上長から承認をもらう」など、IT専門ではない人たちと会話する際に、あまり労力をかけずにスムーズに認識を合わせたいものです。

そこで、個人的に気を付けていることをここにまとめます。

設定

抽象的な話をしてもよくわからない気がするので、例に沿って説明します。

あなたはとあるサービスを運営している会社のIT担当です。 サービスを支える業務システムAの管理者用機能に、顧客ユーザーを一括で5人も登録できる大変ありがたい画面(下図)があります。

ある日、業務部門Xの担当者が要求をあげてきました。

「サービスの規模が拡大しており、csvファイルを取り込んで画面に入力できるようにしてほしい。」

あなたは、担当者としてこの要求に応える必要があります。 という設定です。

解説

準備

現状を把握する

まずは、業務上の課題を把握するために、現状の業務がどうなっているかを前後の業務や例外の処理も含めて理解する必要があります。

そのために、業務フロー図を活用します。(なければ作る。)

業務を実際に見て確認したところ、顧客がWeb申請する場合と紙の申請書を提出する2つのパターンがあることがわかりました。 そして、ユーザー数が増加しているのは、Web申請するユーザーということも分かりました。 (実際には本人確認が取れない場合などの例外フローがあると思います。)

INFO: こんな資料を作る暇は無い

ある程度知っている業務であれば1時間もあれば終わります。 また、知らなかった工程や例外フローを発見することにもなるので是非作成してみてください。

  

INFO: なぜ業務フローを作るのですか?

人類が行ってきたシステム開発の経験はソフトウェア工学として研究され、 どのように開発を進めればうまくいくのかという知識が共通フレームとしてまとめられています。 そういった標準で定義されたドキュメントを使えば、技術者間でのやりとりがスムーズになるからです。逆に、オリジナルの図や表は理解するのに負荷が大きい。

     

問題点を解決する方法を考える

業務を観察していると、現状の業務には下記の問題点があることが分かってきました。

  1. 顧客の数が多く、CSVファイルから1件ずつシステムへ入力する手間が大きくミスが起こりやすい。
  2. 営業部の担当者がわざわざCSVファイルを作成する手間がある。
  3. 紙の申請書を読み取って入力する手間が大きくミスが起こりやすい。

1,2,に関しては営業システムから直接データを取得する方法が良さそうです。

ただし、顧客が入力した氏名と免許証の氏名が一致しているかを担当者が確認する業務はどうしても必要です。そこで、顧客データと免許証画像を画面に表示し、登録を承認する画面が必要となりそうです。

3に関しては現状それほど数が多くないようなので、一旦現状維持とします。

上記の解決策をドキュメントへ反映した結果が下記となりました。

     

解決策の実現性を考える

案としてはまとまってきましたが、この案が実際に業務として実現できるかどうかを検証する必要があります。ここでのポイントは主に下記となります。

  1. 業務として運用できるかどうか
  2. 技術的に開発可能か
  3. 開発コストよりも大きいリターンを見込めるか

1については、問題なさそうですが、実際に業務部門の担当者に確認してみる必要があります。

2については、営業システムの担当者に問い合わせたところ、問題なく実現できそうであることが分かりました。

3については、業務部門Xのオペレーターの入力業務時間と営業部担当者のCSV作成業務が丸々無くなるのでかなりの効果が期待できそうです。(実際は計算を行って、○○人時分削減に対し、開発工数が××人時なので開発すべしとなります。)

資料作り(業務部門との打ち合わせ)

大きく2種類の資料を作成します。1つは議論を行うためのペーパーで、2つ目は先ほど作成したドキュメントです。 議論を行うためのペーパーでは、主に下記のことを気をつけて書きましょう。

  • 日本語の文章で記述する。(単語のみ、箇条書きのみは避ける。)
  • あいまいな言葉を使わず、明確な定義のある言葉のみを使う。
  • ITの専門用語は使わない。どうしても使う場合は説明をいれる。
  • 口頭での説明を前提とした図・表はなるべくつくらない。
  • 短くまとめる。(A4用紙1~2枚以内。)

作成した資料

drive.google.com

INFO: 業務部門から返事が無い

業務部門の人たちは忙しいというのもありますが、IT知識に乏しかったり、要件定義の経験が少ない方はIT担当者が質問していることの意味がいまいちわからないという場合があります。 何と返信すればいいかよくわからないメールを受け取ったら、すぐに返信しようとは思えないというのは、まあ分かるような気がします。 なるべくIT担当者側から素案を提示してあげるようにすると、スムーズにコミュニケーションがとれるかもしれません。

【Flutter】firestore-ios-sdk-frameworksとFirebase各種ライブラリのバージョン対応表

背景

FlutterのCI環境を構築する際に、Firebase Firestoreを導入しているとpod installが異様に時間がかかってしまう問題がある。 この件は、firestore-ios-sdk-frameworksを導入することで解消することができる。 その手順は下記リンクが参考になる。

iOSビルドが遅い, cloud_firestoreビルドが遅い場合の対処法 ビルドを短くする方法 FlutterにCloud Firestoreを追加したら、pod installが永遠に終わらない件

ところが、「firestore-ios-sdk-framework」はバージョンによってはエラーが発生してしまうことがあり、うまくバージョンを指定してやる必要がある。 私が遭遇したのは下記のエラーで10.17.0以降で発生しているようだ。

github.com

Firestore以外のFirebase関連ライブラリを使用している場合、全てのバージョンを適切にそろえることがかなり大変だったので、バージョンの対応表を作成した。

firebase_ios_sdkと各種Flutterライブラリの対応表

drive.google.com

表の見方

cloud_firestore 4.14.0を使っている場合 cloud_forestore列の4.14.0に対応するfirebase_ios_sdkのバージョンは10.18.0だから、firestore-ios-sdk-frameworkに10.18.0を指定すればよいと分かる。

10.18.0でエラーが発生して10.15.0に変えたい場合は、10.15.0行の各種ライブラリのバージョンを指定してやればよいと分かる。

Flutter/Androidで動画再生時に発生する「format_supported=NO_EXCEEDS_CAPABILITIES」エラーの解決方法

こんにちは。 FlutterやAndroidの開発で動画を再生する際に、上記のエラーに遭遇したので、解決方法を記載しておきます。

エラーの詳細は下記のようなものです。

com.google.android.exoplayer2.ExoPlaybackException: MediaCodecVideoRenderer error, index=0, format=Format(1, null, null, video/avc, avc1.64003C, -1, null, [4000, 6000, 30.0], [-1, -1]), format_supported=NO_EXCEEDS_CAPABILITIES

結論

  • 端末が対応していないフォーマットのビデオを再生しようとしています。
  • 再生しようとしている動画ファイルのフォーマットを確認しましょう。(ffprobeで調べられます)
  • 再生しようとしている端末が対応している動画デコードフォーマットを確認しましょう。(Codec Infoで詳細な端末の情報を調べられます。)
  • 端末を変えるか、動画ファイルをより汎用的なフォーマットへ変更しましょう。

エラーの意味

まず「exoplayer2」という単語がありますが、Androidで動画再生を行っているソフトウェアで、元からインストールされているものです。

このソフトウェアが、「format_supported=NO_EXCEEDS_CAPABILITIES」というエラーを発しています。

こちらのページのエラー内容に関する記載によると、端末で対応していないフォーマットのビデオを再生しようとしたという内容のエラーであることが分かります。

どういうファイルを再生しようとしたのか

再生しようとしたファイルの情報もエラーに記載されています。 それがこの箇所です。

「video/avc, avc1.64003C」

一般的にh.264やavcと呼ばれるフォーマットです。 Androidは基本的にh.264に対応しているのですが、h.264には複数の設定(プロファイルやレベル)が存在し、端末がその設定に対応していない場合、上記のエラーが発生します。

Androidで対応しているビデオフォーマットについて

こちらのリンクに、Androidが最低限対応しているビデオのフォーマットが、Androidのバージョンごとに定義されています。

Android 14 互換性定義  |  Android オープンソース プロジェクト  |  Android Open Source Project

たとえばAndroid14であれば、下記のような記載があります。

ちなみに、上記でエラーが発生した動画のプロファイルは「h.264 High Profile Level 6.0」で、Android端末での動作が保証されているものではありませんでした。

動画のフォーマットの調べ方

ffmpegをダウンロード

ffmpeg.org

ffprobeを実行

解凍したフォルダで下記のコマンドを実行します

ffprobe -v error -show_format -show_streams <ファイル名>

するとこちらのような結果が表示され、コーデック、プロファイル、レベルなどの情報を取得できます。 この場合は「h.264 High Profile Level 6.0」であることがわかります。

参考情報

Firestoreのクラス関係を図で整理

FirestoreのSDKを使っていると、Collection/Document/QuerySnapshot/DocumentSnapshot、、、、、などなどなど、用語が多すぎてわけわからないことになるので整理しました。

基本的なデータモデルの話はこちらをご覧ください。

https://firebase.google.com/docs/firestore/data-model?hl=ja

各クラスの関係

上記の図を参考にいくつかの例を確認してみましょう 例は一応Node.jsでFirebase Admin SDKを使った場合を想定しています。

コレクションA内のドキュメントの数を取得する

const snapshot = await firestore.collection("A").get();
console.log(snapshot.docs.length);

コレクションC1内のドキュメントDに含まれるtextを取得

const docSnapshot = await firestore.collection("C1").doc("D").get();
if(docSnapshot.exists) {
  const obj = docSnapshot.data();
  console.log(obj.text);
}

上の図を参考にすると、とってもスムーズに書けますね😉

【Flutter】flutter_screenutilを使ってデザイン時から複数のアスペクト比に対応する画面設計

flutter_screenutilについて

pub.dev

スクリーンサイズが異なる端末でも、Widgetのサイズの比率を一定に保って表示してくれるパッケージです。

例えば下図のような2つのスクリーンサイズが異なる端末があるとします。

iPhone14上で、横を211(スクリーン横の1/3)、縦を130(スクリーン縦の1/4)となるようにContainerウィジェットを定義します。

//省略
ScreenUtilInit(
      designSize: const Size(390, 844),
      ....
//省略

Container(
  width: 130.w,
  height: 211.h,
  child:......
)

//省略

すると、アプリをiPhone SE 2022で起動した場合、Containerウィジェットのサイズが、スクリーンサイズに対して同じ比率になるようにflutter_screenutilが自動計算してくれます。

詳しい使い方は、解説しているサイトがいっぱいあるので調べてみてください。


アスペクト比が異なる画面でのレイアウト崩れ

デザイン時と異なるアスペクト比の端末でアプリを開いた際に、レイアウト崩れが発生します。特に、画像データなどの縦横比があらかじめ決まっているものを用いる場合が問題となります。

例として、下図の390x844(9:19.5)の画面サイズでデザインしたものが、画面サイズによってどのようにかわってくるのか確認してみましょう。

左が390x844(9:19.5)の画面のスクリーンショットです。こちらはデザインどおりに出力されています。 一方で、右は375x667(9:16)の画面で表示した場合ですか、明らかにレイアウトが崩れてしまっています。

  1. タイトルの背景画像が大きくなりすぎてしまっています。
  2. リストの各要素間の余白が無くなってしまっています。
  3. フレームに対して文字のサイズが小さくなってしまっています。

こういったレイアウトのズレを発生させないようにするにはどうすればよいかを考えていきたいと思います。


デザイン時に複数のアスペクト比を考慮にいれる

上記の問題を解決するため、「横方向の画面サイズの変化に対して、ウィジェットが影響をうけないようにする」というデザインの方針で進めます。

先ほどは9:19.5のアスペクト比のみを考慮してデザインを作成していましたが、使用される可能性のある複数の画面サイズを考慮してデザインを作成します。

とりあえず、世の中で最もよく使われる画面サイズを9:19.5、横長のものをを9:16、縦長のものを9:21としてデザインを作成します。

それらの高さを合わせて重ね、下図のような画面の枠を作成します。 こちらの枠をベースに進めます。

そして、その結果がこちらです。

いくつかポイントを確認しましょう。

①画面両端まで表示したい画像は最も横長の画面にあわせる

タイトルの背景画像を9:16の横幅に合わせます。幅の小さい画面の場合は、画像サイズを変えるのではなく、表示範囲を狭めることで調整できるようにします。

②Containerウィジェットの横幅を縦幅の比率ベースで決める

○○.wと書きたくなるころですが、そうすると、画面の横幅の変化の影響を受けてしまいますので、Containerウィジェットの縦幅265.hに対して、画像の縦横比を用いて265.h*200/147と計算します。

③縦に細長い画面のために画面両端にパディングをとる

細長い画面で表示すると、両端が隠されて見えなくなってしまいます。そこで、画面横幅の差に応じてパディングを設定します。今回は計算の結果14.5を確保していれば大丈夫でした。

④ScreenUtilの設定を変更する

下記のように設定を変更しましょう。

 /*省略*/

const designSize = Size(390, 844);

 /*省略*/

ScreenUtilInit(
  designSize: designSize ,
  minTextAdapt: true,
  scaleByHeight: MediaQuery.of(context).size.aspectRatio < designSize.aspectRatio,
  builder: (context, child) => /*省略*/
);

 /*省略*/


改善されたレイアウト

こんなかんじになります。

【Flutter】モバイル端末の画面サイズとアスペクト比について

画面サイズのアスペクト比別分類

こらちのサイトにて、よく使われる端末の画面サイズを調査し図示してみました。

分かること

以上のことから、国内向けのアプリであればデザインは9:19.5ベースで行い、9:16、9:20にも対応できるよう画面設計していくのがよさそうですね。

【Flutter】TabウィジェットでTabBarに画像を使用する

やりたいこと

図のように、画像データをタブに使用して、活性・非活性を切り替える。

タブ

アイコンやテキストを使う場合は、下記を参考に作成できるが、凝った画像データでタブの切り替えを表現しようとするとひと工夫必要となる。

docs.flutter.dev

気を付けるポイント

TabControllerのanimationのvalueを取得して、その値に応じてタブが現在活性なのかどうかを判定することができる。

Tab(
    height: 80,
    //タブが切り替わると、タブ内部のアニメーションの値が変化する。
    icon: AnimatedBuilder(animation: _tabController!.animation!, builder: (BuildContext context, Widget? child) {
      return Image(
              fit: BoxFit.fitWidth,
              height: 72,
              //アニメーションに合わせて、活性画像と非活性画像を切り替える。
              image: (_tabController == null || _tabController!.animation!.value.round() == index)
                  ? AssetImage(activeImage)
                  : AssetImage(inactiveImage),
          );
    },)
  );

ソースコード

おいときます。

github.com