ZedBoardでのUVCデバイスの認識

とりあえず、UVCデバイスを認識するようになりました。

usb 1-1.4: new high-speed USB device number 5 using zynq-ehci
usb 1-1.4: New USB device found, idVendor=045e, idProduct=0772
usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.4: Product: MicrosoftR LifeCam Studio(TM)
usb 1-1.4: Manufacturer: Microsoft
hid-generic 0003:045E:0772.0004: device has no listeners, quitting

ZedboardのUSBポートの電源が入らない？

どうやらZedBoardのUSB OTGポートに電源が入っていない。 他の人も困っている様子。
http://forums.xilinx.com/t5/Embedded-Linux/zedboard-USB-host-not-work-in-petalinux2014-2-prebuild/m-p/521351#M10589

上記の記事は、「DTSファイルを書き換えたらマウスが動いた」という所で終わっている・・・

Petalinux-2014.4の以下のファイルを書き換えて、petalinux-buildしたら、とりあえず電源が入ってUSBデバイスを認識するようになった。

• subsystems/linux/configs/device-tree/system-top.dts

&usb0 {
dr_mode = "otg";
} ;

これを以下の様に書き換えて、petalinux-build

&usb0 {
dr_mode = "host";
} ;

本来はOTGでホストとしてもデバイスとしても動くのでしょうが、強制的にホスト動作にしてしまいました。

ZedBoard Rev.C とRev.Dの違い

ZedboardのRev.Cで動作していたSDカードが、Rev.Dでは動かないので、どういう事かと思い調べてみたところ、

http://zedboard.org/content/revd-boot-sd
によると、Rev.Cは、"rev. C board has a pre-production (ES silicon) Zynq device"とのことでした。
Rev.Dは製品版のZynqを使っているので、振る舞いが違うそうです。

1対1でのプログラミングの教育

以前、大人数相手のプログラミング演習をどうするかというエントリを書きましたが、今回は1対1のプログラミング教育（コーディング手法）について書きます。

最近4年生の卒業研究指導のために、主にC言語・Java言語でのプログラミングを教える機会がありました。何を教えるべきか、というのは指導対象の相手に依るのですが、何点かのポイントが重要であることを認識したので、書いておきます。

以下の教育内容は、プログラミングの初級者が中級の入り口に立つために必要な事という観点でまとめてみました。どのような人を対象としているかというと、
・C言語・Java言語のプログラミングは学んだ
・ついついmain関数や1つの関数の中に、全ての処理を突っ込んでしまう
・期待通りの動作をしないときに、どのようにデバッグしたら良いかわからん
という段階の人です。

＜教育内容＞
１、常に全体の動作が分かるように、コードを改善する。
２、適切にモジュール分割したコードを書く。
３、期待通りに動かないときは、状態を可視化するためのコードを書く。
４、修正・確認のサイクル(TAT)が速く回るように、コードを改善する。
５、入力・出力・期待値を用いたテストを行うコードを書く。

全ての教育内容で、「コードを書く・改善する」という形式にまとめています。
学生のプログラミングに対する考え方を矯正するのは、なかなか効果が見えないので、コードという形で教育の成果がアウトプットできるように、結果をコードに示すようにしました。

この内容を理解して使える段階に達すると、大幅にプログラミングが楽しくなってきます。ですので、学生の皆さんには是非これらのプログラミングスキルを身につけてほしい、と願います。

それでは、一つずつ説明します。

１、常に全体の動作が分かるように、コードを改善する。

プログラミングの経験が少なく、あまり大きなプログラムを書いたことが無い人の場合、「ついついmain関数や1つの関数の中に、全ての処理を突っ込んでしまう」というプログラムになりがちです。

その場合、自分の書いたプログラムを他人に説明するのも困難ですし、しばらくすると自分の書いたコードの意味するところが分からなくなってきます。すると、機能追加の必要があってプログラムの修正やデバッグをしようとしても、出来なくなってきます。

ですから、パッと見ただけでプログラムの全体の動作（もしくは、プログラムのある部分の動作）が分かるように、常にコードを改善（リファクタリング）し続ける必要があるわけです。

昔から言われている事ですが、基本的には関数を1画面内に収めましょう。そうすると、フローチャートにした場合も1画面に収まります。するとPPTスライド等で他人に説明することが出来るようになります。1画面に収まるサイズが、人間が「全体を把握する事の出来る限界」と思って良いです。

その為には、処理をモジュール（C言語であれば関数・ファイル）に分ける必要があります。
ある関数の中での、処理のまとまりの単位で、更に小さい関数を作り、それを呼び出す形にするという事です。

初学者は、「モジュールに切り分けるためのC言語の文法」をあまり知らないことが多いので、その辺を次項で説明します。
＃なお、この辺のモジュールへの切り分けは、Javaであればかなり簡単になります。

２、適切にモジュール分割したコードを書く。

C言語でのモジュールは、関数・ファイルという2つのレベルがあります。

まず第1のレベルは関数単位のモジュールです。
前項で説明したように、最初はmain関数の中だけで完結していた処理も、長くなってくると関数を切り出す必要があります。以下にコード例を示します。

ファイル名：main1.c

int main() {
　処理１
　if(xxx) {
　　処理２
　}
　処理３
}

↓
ファイル名：main2.c

void func1() {
処理１
}
void func2() {
処理２
}
void func3() {
処理３
}

int main() {
　func1();
　if (xxx) {
　　func2();
　}
　func3();
}

main1.cのコードは数画面に及ぶmain関数だと思ってください。これをmain2.cのコードの様に書き換えると、処理１・処理２・処理３の意味合いが良く分かるようになります。

この際に問題になるのは、func1・func2・func3が、それぞれ共通の変数を使う場合でしょう。
その場合C言語では、グローバル変数を使うのが最も直観にあった解決法だと思います。
以下の、main3.cではcommon_dataというグローバル変数を宣言して、各関数内で使用することにしています。

ファイル名：main3.c

int common_data[100];

void func1() {
処理１(common_dataを使う)
}
void func2() {
処理２(common_dataを使う)
}
void func3() {
処理３(common_dataを使う)
}

int main() {
　func1();
　if (xxx) {
　　func2();
　}
　func3();
}

大事なことは、「処理を関数単位に分解して全体の処理を把握できるようにする」という事です。そのために、グローバル変数を用いても良いので、処理をまとまりとしてとらえるようにするようにしましょう。

但し、グローバル変数というのは、より大規模なプログラムや、マルチスレッド・マルチコア向けの並列プログラムを作成する際には問題となることがある、という事は気にしておいてください。これは、中級者から上級者に脱皮する際に、よく勉強しなければならない事です。

◆

第2のレベル（ファイル単位のモジュール）は、1つのファイルが数100行を超えたあたりから、検討する必要があると思います。つまり、ソースファイルを編集していて、どこに何の関数が書いてあるのか、把握不能になるコード量になってきたら、ファイルの分割を考えた方が良いです。また、中級者以降になると、自然と最初からファイル単位でのモジュール化を意識して書くようになってきます。

最初にJavaにおけるファイル単位のモジュール化について説明します。Javaでは１つのクラスは1つのjavaファイルに対応させるという原則があります。これにより、クラスとファイルとの関係が明瞭になっています。

一方C言語では、クラスという単位が無く、またどの程度の量を1つのファイルに記述するかという指針が無いため、混沌としがちです。

C言語でのファイル単位でのモジュール化について、私のお勧めは、クラスに相当する「処理やデータの1つのまとまり」を、1つのファイルのペアにまとめることです。
ファイルのペア、と言っているのは、ソースファイルとヘッダファイルのペア、という事です。

この際注意すべきなのは、ヘッダファイルには変数の実体を書かない事です。
ヘッダファイルは複数のソースファイルからインクルードされる宿命があるので、そこに実体があると、最後にリンクする際に、複数のオブジェクトファイル内に同じ変数の実体が存在するために重複してしまい、問題が生じます。その為、ヘッダファイルには、変数の実体を書かずに宣言のみをするようにします。

グローバル変数を、複数のソースファイルから共通に使用したいのであれば、ヘッダファイルにexternで宣言しておき、どこか一つのソースファイルに変数の実体を作ることで、別のファイルの関数からでもグローバル変数にアクセス可能になります。グローバル変数はなるべく使用を避けた方が良いのですが、C言語ではグローバル変数を用いて書くことが自然である場合が多いので、問題があることは認識しつつ使用可能であることを示しておきます。

なお「リンク」とか「オブジェクトファイル」といった用語が出てきましたが、ファイル単位でのモジュール化を使いこなすためには、どのように実行可能形式のファイルが出来上がるか、という過程を理解しておく必要があります。

以下は、開発環境がVisualStudioでもGCCでも共通の考え方です。
コンパイル：1つのソースファイルから、1つのオブジェクトファイルを作る
リンク：複数のオブジェクトファイルから、1つの実行可能ファイルを作る

コンパイルはソースファイル単位で行われ、オブジェクトファイルが作られます。オブジェクトファイルの中には、関数や変数の名前・型情報と先頭アドレスのリスト、および関数単位で実行可能なコードが格納されています。リンクする際に、複数のオブジェクトファイルで同じ名前の変数や関数が見つかると、重複してしまい正常にリンク不可能です。ですので、各オブジェクトファイルにどの関数・変数が格納されるのか、よく意識して、ソースファイルとヘッダファイルへの配置を考える必要があります。そのための指針が、前述したように、クラスに相当する「処理やデータの1つのまとまり」を、1つのファイルのペアにまとめる、という事になります。

なお、複数のソースファイル・オブジェクトファイルを用いて、実行可能ファイルを作成する手順のことを、「分割コンパイル」といいます。ここで分割コンパイルの手順について詳しく説明することはしませんが、自分が見ても他人が見てもプログラムが理解可能な状態に保つためには、関数単位・ファイル単位でのモジュール化が必須であるという事を理解し、実践していくことをお勧めします。

なお、C言語でのファイル単位のモジュール分割を用いて、オブジェクト指向の設計をC言語にマッピングする方法については、以下の書籍が詳しいです。
http://www.cqpub.co.jp/hanbai/books/33/33391.htm

３、期待通りに動かないときは、状態を可視化するためのコードを書く。

期待通りに動かない時に、ソースコードを眺めながら、なんでだろ〜なんで動かないんだろう〜と時間が経過していくという事が、ありがちな風景です。VisualStudioやgdb等のデバッガを使うと、ソースコードを見て1行ずつ実行を進めながら、変数の値の変化を見て確かめることが出来ます。しかし、確認する対象が広範囲になってくると、局所的に変数を見ているだけでは不具合の原因が、なかなか分かりません。

そういう時には、現在の状態を分かりやすく表示するプログラムを作る、ということをすると、一気に目の前の霧が晴れる、という事が良くあります。シミュレーション対象の全体の状態の概要を出力する、とか、あるモジュールに着目して時系列で全ての内部状態を出力する、とか、デバッグの目的に合わせたプログラムを作るのです。

この際、本来のプログラムの中にprintfをいっぱい埋め込んでしまうと、雑然としてしまい、関数あたりの行数も伸びてしまいます。そのため、なるべくデバッグ用の観測コードと、本来のプログラムのロジックを分離するのが良い習慣だと思います。

基本的にはデバッグのための状態表示の関数を作って、調べたいところで呼び出すように作ると、デバッグ版と最終版(リリース版)を上手く分離することが出来るようになります。やり方は色々ですので、各自の好みに応じてで構わないと思います。

４、修正・確認のサイクル(TAT)が速く回るように、コードを改善する。

状態を可視化して、プログラムの何が問題なのかを分かりやすくできたとして、次に問題になるのが、プログラムの実行時間やコンパイル時間です。

バグの原因究明のためには、考えるための材料が必要です。前項で説明した、「状態の可視化」は、そのための材料を揃えるものです。デバッガでのステップ実行に頼っていると、時間がかかる上に同じ状態を実現するのに時間がかかりますので、デバッグしたい状態をなるべく早く再現するためのコードを一生懸命書くことで、結局はデバッグにかかる時間を短くすることが出来るようになります。

更に、以下の項目について考慮することで修正・確認のサイクル時間(TAT: Turn Around Time)を短くできますので試してみてください。

・問題のサイズをパラメータ化する
大規模なデータを扱うプログラムの場合、プログラムの最初に入力データを読み込むだけでかなりの時間を費やしてしまう事は良くあります。最初は小さい入力データで試してデバッグを十分行い、その後、実際に使用する入力データを用いた処理をするという手順を踏むことが、結局はトータルの開発時間を短くすることにつながることを、私たちは経験上知っています。

サイズをパラメータ化して、多少入力データのサイズが変わっても対応できるようなコードを作成することに時間を使いましょう。そうすることで、作成したプログラムを色々な用途や入力データに対応して使用できるようになります。

問題のサイズとして「０・１・２・３」ぐらいを試してあれば、問題のサイズが「いっぱい」の場合も大抵動きます。なお、問題のサイズが「いっぱい」である際に生じる問題については、大抵がメモリ不足が原因だったりします。

・単純作業の自動化（Makefileの活用）
コンパイルしてリンクして実行するという一連の作業を、毎回コマンドを打って行っている人は、Makefileを使うことを検討しましょう。コンパイル・リンク以外の単純作業もMakefileを使うと自動化することが出来ます。

VisualStudioであれば自動化されていますが、その分中身が見えませんので、コンパイル・リンク以外の単純作業の自動化は、少し難しいかもしれません。

なんにせよ、単純作業はなるべくコンピュータにやらせるのが大事です。

実験で少しずつ条件を変えてシミュレーションをしたい場合であれば、以下の様な手段で、コンピュータに自動的に実験をやらせましょう。
・条件をコマンドラインパラメータとして与えるようにプログラムを作成
・シェルスクリプト（もしくはバッチファイル）で、順次入力データやコマンドラインパラメータを変更して実行する

５、入力・出力・期待値を用いたテストを行う。

以前のエントリで進捗報告の仕方について書きましたが、プログラムの開発の進捗を測る方法は、テストの結果、で示すのが一番です。一番の意味は、開発の進度を最も適切に表すという意味と、聞いている人が納得しやすい、という意味です。

入力とは、プログラムに与える入力のデータです。
出力とは、プログラムから出力される結果のデータです。
期待値とは、プログラムに出力して欲しい、正しい結果のデータです。

結果のデータを得るためには、状態を可視化するコードが必要です。すなわちテストをするためには、状態を可視化するコードを一生懸命書く必要があります。

そして、出力と期待値の一致比較を、まずは目視で行いますが、次第にプログラムにやらせるようにします（diffコマンドでも構いません）。

プログラムを改善・修正していると、以前通過したテストが再びNGになることがあります。テストを手動で行っていると、以前のテストは段々と面倒くさくなって実施しなくなります。
そのため、テストを自動化し、常にすべてのテストが通過することを確認しながら開発を進めることが、トータルとしての開発期間を短縮することにつながります。

＊＊＊

私はXP(Extreme Programming)の思想には非常に共感するところがあります。そのためコーディング教育は、XPを指向したものになっていると思います。ただしXPは中級〜上級者向けで、やや洗練されすぎておりプログラミングの初学者にはとっつきにくい所がありますので、なるべく噛み砕いて説明しました。

前回エントリ・本エントリで説明した5項目は、基本的には1人でやるプラクティス（習慣）です。XPは2人でやるものですが、その前提にあたるものであると位置づければ良いかな、と思います。この他に、タスク管理・バージョン管理システムを導入する、という指導もしていますが、おいおい書いていきます。

＊＊＊

私が教員として1年ぐらい過ごして感じた事は、「プログラミングは苦手」という意識でいる情報工学科の学生が多いことです。何とかして、「プログラミングは楽しい」と感じられる様にしてやりたいのですが。このエントリで書いたようなことが意識できるレベル(中級者)になれば、「プログラミングは楽しい」となりそうなのですが、1対多数の演習講義では、指導するのが難しいです。

つまり、現状の1対多数の演習講義では、プログラムの枠組みがあって、そこを埋めるというスタイルで演習を進めています。そのようなスタイルだと、自分で枠組みを決めていく（関数分割であったり）という訓練が出来ないのです。

そして枠組みを学生に考えさせると、その枠組みが「良い」か「悪い」かを判断する必要があります。枠組みは設計なので、なかなか一概に「良い」か「悪い」かを評価できるものではない、というのも教えづらいポイントです。基本的には、期限内に要求通りに動くコードが書ければ「良い」のですが、明らかに「悪い」設計については、設計レベルでもっと良い方法というのを教員が示してやる必要があります。

学生が作ってきたプログラムに対して、一例ずつ、より良い設計を考える、というのは時間がかかるものですので、少人数のPBL(Project Based Learning)にせざるを得ません。つまり、結局はシステム開発の会社での新人研修・OJTみたいなものになります。PBLの問題は、教える人によるばらつきが大きいことかな、と思います。しかしながら、問題はあるにせよ、学生が自分で枠組みを考えて設計する、ということは早めにやることが必要ですね。

覚醒

大学時代の師匠が色々と名言を私の心に残しているのですが、その中に「Education is firing!」というのがありました（後ほど調べると、良く言われる言い回しの様でしたが）。つまり、教育とは学生の心に火をつける事であって、一旦燃えたら、あとは自分自身で燃え続けるのだ、という事です。火をつけるまでが教育者の役割なんですね。例え話で、馬に水を飲ませるために水辺に連れて行くことは出来ても、馬が自ら水を飲まなければ、結局水を飲ませる事は出来ない、という言い方もする、アレですね。

で、火をつけるためにどうしたらよいか、というのは私もあまり良く分からないのですが、私はその師匠に学部4年生で初めて出会って1年間ぐらいそばで過ごして、研究室の先輩を叱ったり、「私は世界一の仕事をこれまでしてきて、これからもしていくんだ」という演説をしたりしているのを聞いて、「何かこの人はすごい」「とても有名らしい」「周りの人がみんな凄いと言う」という気配に圧倒されて、なんかこの人についていけば自分も凄いことが出来るようになるではないかと思ったように思います。

また、師匠本人だけではなくて、研究室の先輩や会社から来ている研究員の方々が研究に取り組む姿を見て、自分も頑張ってみよう、と思ったのでしょう。結局、学部3年生までの不真面目な態度は一新されて、バイトもサークルも絶って、研究生活一筋になったのでした。人間は動物の一種なので、感覚を通じて本能で感じてしまう事には逆らえない、というか、論理を超えてしまう物なのです。

厨二的な言い方をすると、これが「覚醒」なのかもしれない、と最近思っています。（とはいえ、これも誰か大学教員の人が言っていたような気もしますが）。早い人だと大学に入る前に「覚醒」しているのかもしれませんが、私の場合は4年生でした。やはり道を究めるためには「覚醒」が必要で、一心不乱に一つのことに取り組む、考え抜くこと、そういう経験をしないといけません。

一説には、一万時間の経験で能力が開花すると言われます。それにしても、一万時間も何かをやり続けるためには、その最初のきっかけが必要で、それが「覚醒」もしくは「Firing」なのでしょう。

最近研究室の学生には「大学はコネを作るところなんだから、良く遊びにいってお互い仲良くなっておきなさい」と指導しています。

「覚醒途上の者」にとって、「覚醒」のためには「覚醒した者」との「交流」が必要であり、「交流」が新たな「覚醒者」を生むのだと、思っています（厨二的に）。また、大変な環境で共に戦った「戦友」との友情は、生涯残るものだと、思います。ということで、研究室の学生は、先輩や教員とよく交流しましょう。

研究テーマに関して、初めて勉強する際の効率の良い学習法

本日の研究グループミーティングでの指導内容と補足をメモしておきます。
先輩の論文などを読んで勉強しようとしている、主に研究初心者の4年生への全般的なアドバイスです。

◆１、何かを読んで勉強するときは、「何かをアウトプットする」ことを意識しましょう。

読んで理解を深めようとしているだけだと、どこまで理解したかがあいまいになり、数日すると何を勉強したか、忘れてしまいます。
「アウトプットする」、というのは、手書きのメモでもパワーポイントの資料でも構わないのですが、自分が理解したことを何かに書き留める、という事です。
書き留めることで、「勉強した成果」が積みあがるのが自分で実感できますので、自信につながります。

また、会社に入ってからの仕事でも、「調査」という仕事については、必ず「調査報告書」という成果物を作成することが求められます。成果を意識的にアウトプットする訓練は、今後の技術者人生に非常に有用です。

◆２、理解した内容は、周りの人に説明できるようにして、説明してみましょう。

理解した内容を誰かに説明すると、よく整理されて記憶に定着します。
また上手に説明する訓練にもなり大変有用です。説明してもらった人も、知識を増やすことが出来るので、有益です。
いわゆる、Win-Winってやつです。

◆３、読んでも理解が出来ない場合には、一人で抱え込まないで周りの人に聞きましょう。

うまく周りを巻き込むことが、効率の良い学習法です。
自分が理解した内容を書き留め、分かっていそうな人（教員など）にその内容を説明してみて、「これであっていますか？」と質問しましょう。すると、分かっている人にとっては、そのような質問には基本的にはYES/NOで答えられるので、短時間で済みます。また、質問した人が分かっていなかった場合でも、分かっていそうな人を紹介してもらえるかもしれません。

ところが、「〜が分からないで教えてください」という質問にすると、質問された人は、何から教えたらよいかを探るところから始める必要があるので、時間がかかります。すると、答える側も段々と質問に答えるのもおっくうになってしまい、「もうちょっと勉強してから来なさい」といわれてしまう危険があります。すると、質問をしに行く気力が萎えてしまうので危険です。そうならないように、上手い質問の仕方を身につけましょう。

卒論・修論の研究を進めるうえで、「質問が出来ないから質問が出来ない」という悪循環にはまってしまうことがあります。以下の記事を参考にしましょう。「質問の仕方」を気を付けるのは良いことですが、あまり質問に行く際の、ハードルを上げすぎないようにしましょう。

卒業研究・修士研究時の悪循環を防ごう（※Deepな話なので、閲覧注意）
http://d.hatena.ne.jp/next49/20081019/p2

定量的な報告 補足（進捗の数値化）

先日のエントリで、進捗の数値化について少し質問があったので補足を書きます。
＃ちなみに、これらはホントにごく一般的なプロジェクト管理の手法ですので、色々なキーワードをググれば直ぐに説明や例が出てきます。

1.進捗の数値化について
タスクレベルまで目標をブレイクダウン（分解）したという前提で、各タスクの進捗の数値化について、やり方を考えたいと思います。
タスクの性質によって、報告の仕方は異なると思いますが、以下に例を示します。

A、検討・調査など、タスクが完了しないと意味がないもの。　0%もしくは100%として報告
B、取り掛かることが大事なもの。テスト項目表の作成など。　作業が開始したら20%の進捗、完了したら100%の進捗として報告
C、仕様書・報告書の作成など、分量に成果が比例するもの。　報告書であれば、予定ページ数に対する現在ページ数の割合で報告

数値化するのが容易なCについては、問題ないと思います。
A/Bの違いは余りないと思いますが、「どうしてその進捗評価基準なのか」を自信をもって説明すればOKです。

進捗の数値化については、いろいろな考え方がありますので、プロジェクトを通じて同じ基準で評価していれば問題ないでしょう。

2.計画に対する進捗の報告の仕方
肝心のこれを書いていませんでしたが、計画はいわゆるガントチャートに書けばよいと思います。
縦方向に分解したタスク項目をツリー構造で示し、横方向に時間軸を示して、各タスクをスケジュールして配置します。

そして、各タスクの進捗状況を、タスクの棒の中に点を打つことで表現し、それらをすべてのタスクについて線でつないだのが、「イナズマチャート」です。
例はググると出てきます。

これでプロジェクト全体として現在遅れているのかどうかが一目で見渡せます。
計画に対して順調に進んでいれば、安心感が生まれます。
また、一つのタスクがネックになって、プロジェクト全体が進まない、ということも良く起こります。あるタスクが終わらないと、次のタスクが始められない、という「タスクの依存関係」が原因です。
この場合は、問題のタスクに対して、何らかのアクションをする必要があります。指導教員や上司に相談するなり、一人で抱え込まないことが重要です。

計画を立てたり、イナズマチャートで進捗報告することの良い点は、こうしたプロジェクトの問題点を明らかにすることが出来る事です。担当者しかプロジェクトの進み具合を把握していない、という状況は、その担当者が倒れたらそこでプロジェクトがおしまいです。なので、会社においては常に誰か他の人が仕事を継続できるようにプロジェクトの可視化・進捗報告というのをしてチームとして仕事を進めるわけです。

＃なお、タスクの依存関係については、計画を立てる段階で「ワークフロー図」を作成することで、明らかにする方法があります。これについては、いずれ機会があったら書きたいと思います。

＊＊＊

大学の研究に対して、会社みたいなことを持ち込んでも上手くいかないのでは、という考えは自問自答しています。特に学生にやらせることについては。ただ、会社に入ってチームでの技術開発をやるようになると、成果報告を定量的に、というのは上司からよく言われることなので、身につけておいて損はないスキルだと思います。

進捗報告の数値化には誤差がつきものですので、必ずしも実態を上手く表せているかどうかについては疑問が残ります。それが高じて「進捗報告の数値化など意味がない」とか「上司を納得させるためだけに進捗報告するのは無駄」といった考えに陥りがちです。特に上司との感情的な行き違いがある場合など、そのようなブラックな考えに染まりがちです。

進捗管理は時間も手間暇もかかりますので、私自身、一時そんな考えに支配されていました。なので、如何に時間と手間暇をかけずにやるかが重要だと思っています。
その為、「他人に見せるため」ではなくて、「自分のために」進捗管理するのが良いのではないか、と思っています。自分のためだけであれば、無駄なことはしませんので、時間もあまりかけなくて済むと思います。そうしておいて、もし説明を求められたら、ちょっと手間をかけて進捗報告する、というバランスが良いでしょう。

（会社で火のついたプロジェクトだと、進捗が良くないプロジェクトほど、頻繁に進捗報告を求められて、かえって進まない、ということが良くあります。これは精神を病む大きな原因になります）