システムエンジニアやプログラマーにおける『ポートフォリオ』と『作品』
1. はじめに
近年，フリーランスのシステムエンジニアやプログラマー (以下，SE・PG と称します) が増加傾向にあります。それに伴い，イラストレーターやデザイナーなどのクリエイターと同様に，SE・PG が自身のポートフォリオを所持する機会も増えてくると思います。その一方で，「ポートフォリオに掲載できるようなソフトウェアや FLOSS を所持していない」や「何を作れば良いのかわからない」という意見をよく目にします。確かに，SE・PG が作成する成果物は多岐に渡るため，その全容を掴むのは容易ではありません。そこで，SE・PG の『作品』になると考えられるものをアプリケーション・ソースコード・ナレッジの視点から分類したので，その分類結果と筆者の考察を以下に記述します。
2. アプリケーション
「アプリケーション」という単語に含まれる意味は多岐に渡ります。例えば，スマートフォン上で動作するモバイルアプリケーションやブラウザ上で動作する Web アプリケーションなど様々です。本記事では，エンドユーザー向けに開発したプログラムを指す単語として用いります。
2.1. CUI
CUI は，Character User Interface の頭文字を取った略称です。ターミナルから操作する形式のアプリケーションを指す単語であり，FFmpeg や ImageMagick などが代表例に挙げられます。MS-DOS や UNIX が普及していた 1980 年代に主流となっていたアプリケーション形式です。下記の GUI が登場してからは，CUI アプリケーションをラッパーした GUI アプリケーションが主流になったことで，エンドユーザーが CUI アプリケーションに触れる機会は減ってきました。しかしながら，C 言語の getopt や Python の argparse などを用いることで比較的容易に CUI アプリケーションを開発することができるため，ポートフォリオに掲載する最初の『作品』としてはオススメの形式です。
2.2. GUI
GUI は，Graphical User Interface の頭文字を取った略称です。キーボードやマウスを用いて直感的な操作が行える形式のアプリケーションを指す単語であり，Adobe Products や Microsoft Office などが代表例に挙げられます。Windows や macOS などの GUI を搭載した OS が普及するのに伴って主流となっていった形式のアプリケーションです。初期の頃は，Win32 や Carbon といった OS に依存する API を叩くことで GUI アプリケーションを開発していました。そのため，非常に高い専門知識が要求され，クロスプラットホームに対応させるにも一苦労しました。その後，.NET Framework や JavaFX が登場したことによって，手軽にクロスプラットホームに対応させることができるようになりました。更に，Electron や Unity が登場したことによってGUI アプリケーション開発の敷居は徐々に低くなっています。しかしながら，CUI アプリケーションと比較すると開発ハードルは依然として高いため，最初の『作品』としてはオススメできない形式です。
2.3. Web アプリ
Web アプリは，ブラウザ上で動作する形式のアプリケーションを指す単語であり，Google の検索エンジンサイトや Amazon の EC サイトなどが代表例に挙げられます。初期の頃は，Java Servlet/JSP や LAMP などの環境を用いて開発していました。そのため，ネットワークに関する専門知識やサーバー費など開発ハードルは非常に高かったです。しかしながら，Angular や React，Vue.js などの Web アプリケーションフレームワークと AWS や Azure，
GCP などのクラウドサービスの登場によって開発ハードルやコストは大きく下がってきています。WebAssembly の登場など，Web 技術は今後も大きく発展していくと考えられます。そのため，Web アプリケーションの開発は，今後の投資という視点からもオススメです。
3. ソースコード
アプリケーションがエンドユーザー向けの成果物とするならば，ソースコードは SE・PG 向けの成果物として考えることができます。そのため，アプリケーションを開発する際に発生するソースコードも，SE・PG における『作品』になる成果物だと考えられます。
3.1. スクリプト
スクリプトは，Python や Ruby などの動的プログラミング言語のソースコードを指す場合が多いです。本記事では，静的・動的を問わず数十行から数百行程度の小さいソースコードを指す単語として用いります。作業を効率化する Excel VBA や教育用の Scratch も，公開することによって立派な『作品』になります。近年では，CodePen や GitHub Gist などスクリプトを公開できるサービスが増えてきているため，公開するハードルも低くなりつつあります。そのため，ポートフォリオに掲載する最初の『作品』としてはオススメです。
3.2. ライブラリ
ライブラリは，再利用可能なプログラム群を指す単語として用いられることが多いです。下記のフレームワークと似ているため，混同される場合が多いです。有名なライブラリは，他の目的を達成する過程で発生した成果物である場合が多いです。例えば，Bootstrap は Twitter 社が Web アプリケーションを開発する際に用いたソースコードを再利用可能な状態で公開したものです。TensorFlow も Google 社が機械学習をする際に用いたソースコードを再利用可能な状態で公開したものです。このように，ライブラリは副産物的な側面が強いため，ポートフォリオに掲載する『作品』としてライブラリを作成するのはオススメできません。
3.3. フレームワーク
フレームワークは，成果物を生成する基盤となるソフトウェアを指す単語として用いられることが多いです。上記のライブラリと似ているため混同される場合が多いです。ソーシャルコーディングが主流になってきた近年でも，非常に高い専門知識とマンパワーが必要になる場合が多いため，ポートフォリオに掲載する『作品』としてフレームワークを作成するのはオススメできません。
4. ナレッジ
ドキュメントの要約や翻訳は，初学者にとって非常に有り難い成果物です。そのため，アプリケーションやソースコードの陰に隠れて注目されにくいですが，ナレッジも SE・PG における立派な『作品』の一部です。
4.1. 解説
初学者に向けた入門記事や動画も SE・PG における立派な『作品』の一部です。また，上記のアプリケーションやソースコードなどの作成に比べると敷居も低いため，ポートフォリオに掲載する『作品』としてオススメできると思います。しかし，「使用したアプリケーションやソースコードのバージョンを明記する」や「引用元のドキュメントを明記する」などの情報リテラシーに気をつける必要があります。
4.2. 実践
アプリケーションやソフトウェアのチュートリアルだけでなく，システム開発を通じて発生した知恵や考察もソフトウェア工学の側面から価値があります。そのため，システム開発の過程で発生したアーキテクチャ図や不具合なども， SE・PG における立派な『作品』の一部だと考えられます。
4.3. 翻訳
アプリケーションやソフトウェアのドキュメントは基本的に英語で記述されており，初学者の敷居を高める要因の一つと考えられます。また，チュートリアルやハウツー情報も日本語より英語で記述されているものが多いです。そのため，これらの翻訳作業も SE・PG における立派な『作品』の一部だと考えられます。しかし，個人の記事や動画を無許可で翻訳して公開することは，転載に該当する場合があるた注意が必要です。
5. おわりに
ここまで，SE・PG における『ポートフォリオ』と『作品』というテーマに沿って，SE・PG の『作品』になると考えられるものをアプリケーション・ソースコード・ナレッジの視点から分類し，その分類結果と筆者の考察を記述してきました。筆者の経験上，SE・PG の『作品』としてアプリケーションやソフトウェアの印象が強いため，ナレッジの印象が薄い気がします。しかし，高品質なナレッジは応援するアプリケーションやソースコードの初学者獲得や規模拡大など，コミュニティに貢献することもできます。そのため，アプリケーションやソフトウェアの開発と同様に，SE・PG の『作品』として認識されることを願っています。