浅野直樹の学習日記

この画面は、簡易表示です

未分類

私の業務効率化ツールとの付き合い方

Slack、Notion、GitHub、G Suiteなど、さまざまな業務効率化を使うことになり、これらの業務効率化ツールとどのように付き合っていけばよいかを整理したく、この記事を書きました。

 

業務効率化との付き合い方は、年代や働き方によって大きく異なると思いますが、この記事では一つのリアルな例を提供します。

 

個人史を振り返り、現在の姿をまとめ、概念整理をします。

 

1.個人史

(1)高校卒業まで(〜2001年)

私は1982年生まれでして、初めて電子メールを使ったのが2001年に高校を卒業する直前のことでした。今で言うガラケーのキャリアメールです。クラスメートとメールアドレスを交換し、その日は夜遅くまでやり取りしたことを覚えています。

思い出話はさておき、メールを最も原始的な業務効率化ツールに位置づけるとして、それ以前にツールを使ったことはないということになります。

現代でしたら、中学生や高校生でも日々の学習に業務効率化ツールを使うことがあるでしょうから、時代によって規定される部分が大きいです。もっとも、私は、当時の紙に手書きをするノートでさえ、極力作らないタイプでした。できるだけツールに頼らず自分の脳内で完結させたいという志向を一貫して持っています。

(2)大学時代(2001年〜2013年)

私は長く大学(大学院)に在籍しておりまして、2001年〜2013年の間を指します。

2001年に大学に入ってから初めてパソコン(PC)を本格的に使いました。それまでは中学校の技術家庭科の授業で意味もわからずパソコンを触った記憶が薄っすらあるくらいです。

エンジニア職にある者としては遅いパソコンデビューですけれども、少し上の先輩は卒論を手書きしていたほどですから、一般人としては平均的な姿かなと思います。私の記憶が正しければ、「京都大学 織田信長」というワードでインターネット検索をしてヒットした件数が1件や2件だったと2001年頃に何かに書かれていたので、それくらいの時代だと想像してください。

思い出話が過ぎました。業務効率化ツールに話を戻します。といっても相変わらず使っていたのはメールくらいです。パソコンで使うメールとしては、最初gooメールを使い、のちにGmailに移行して、現在まで使い続けています。私は今でもGmailを業務効率化ツールの主力として使っていますから、若い頃に身に着けた習慣を変えるのが難しいのかもしれません。

2013年までにメール以外の業務効率化ツールを使っていた記憶はありません。パソコンは日常的に使うようになっていたので、フォルダを階層別に整理して、塾で担当している生徒ごとに教材を格納するといった形でタスク管理をしていた記憶はあります。

TwitterやFacebookといったSNSが流行り始めた頃に試してみましたが、長続きしませんでした。その頃から現在に至るまで使い続けている人もたくさんいますから、SNSをどう使うかは個人の趣味嗜好によるのかなと思います。

(3)近年(2013年〜2024年)

この約10年でさまざまな業務効率化ツールに出会いました。塾やエンジニア関係その他いろいろな仕事をするようになったという個人的な事情と、各種ツールが登場したという時代がマッチしたのでしょう。

私はできるだけ脳内で完結させたい派であり、紙のスケジュール帳でさえ長らく使っていませんでした。複数の仕事を掛け持ちするようになり、また若い頃のように何でも覚えられないようになって、渋々紙のスケジュール帳を2013年の少し前に導入していました。

紙のスケジュール帳からGoogle カレンダーに切り替えたのは2014年12月です。これはGoogle カレンダー上に記録が残っているのではっきりしています。

LINEも2012年〜2013年あたりに使い始めました。プライベートに近いやり取りで使うことが多いです。

Slackは2018年に使い始めました。エンジニア関係の仕事をしている人から教えてもらいました。

GitHubを使い始めたのは2020年です。エンジニア的な仕事を本格的にするようになって導入しました。

Notionはごく最近登録しました。それがこの記事を書くことになったきっかけです。

kintone、Zoom、Chatworkなども、業務上で求められて使ったことがあります。

 

2.現在の姿

自分から主体的に使うのは、メール(Gmail)とスケジューラー(Google カレンダー)だけです。

メールはなるべく早く返信するようにして、返信し終えたりそもそも返信の必要がなかったりするメールはアーカイブして受信トレイから見えないようにしています。

そうすると、受信トレイが、返信対応しなければならない案件などのタスク管理を兼ねられます。

Slack、Notion、GitHubなどもメール通知に対応していますから、メールに一元化することができます。

メールという仕組みは一つの会社に依存しているわけではありませんし、共通のインターフェイスとして優れていると思っています。

世代のせいかメールが万能ツールだと思っている節が私にはありますが、月のカレンダーというビジュアルで予定を把握したいという思いも他方であり、スケジューラーはメールと別に利用しています。

締切があるようなタスクはスケジューラーのほうに書き込んで管理しています。

受信メールが起点とならない事柄については、Gmailの下書きかGoogle カレンダーにメモするようにしています。スマホからでも簡単に入力できますしね。

そうするとインターネット上に保存されるので消えてしまうことが基本的にありませんし、クロスデバイスで参照できますので。

ついでに言いますと、インターネットの閲覧にはGoogle Chromeを使っておりまして、GmailとGoogle カレンダーのタブを常時開いています。

翻訳、決算作業、資格試験対策、業務用の連絡ツールなど、その時々で取り組んでいることに関するリンクをGoogle Chromeのブックマークバーの見えやすい場所に配置して、作業の取っ掛かりのハードルを少しでも下げるようにしています。

プログラミングのコードを本格的に書く場合はGitHubを使います。バージョン管理に優れていますし、デプロイでも使うことになりますから。

あとは取引相手が求めるままのツールを使います。

これが2024年現在の私の完成形です。

 

3.概念整理

業務効率化ツールとして必要となる機能を挙げると、コミュニケーション、スケジューラー、タスク管理、メモあたりになるでしょう。

コミュニケーションは相手があってのことですから、相手の希望するツールを使うという側面が大きいです。

スケジューラーも多くのツールで使うことができ、個人的にはできれば使いたくないのですが、たくさんの仕事を掛け持ちしているとそういうわけにもいきません。毎日決まった会社に出勤するという仕事であれば、スケジューラーを使わなくても何とかなるかもしれないと想像はします。

タスク管理は複雑なツールを使うくらいならさっさと片付けたほうがよい、時間がかかるものであれば少しずつ終わらせたいと思ってしまうので、基本的に使いません。私は、コミュニケーションやスケジューラーと紐つけて管理しています。

メモはおよそどのようなツールでも使える機能でしょう。そして、個人的には、極力メモは取りたくない派です。大事なことは脳内に入れたほうが早いです。忘れてしまうようなことは大事ではないと言いたいところです(仕事上の細かい数字などはメモに取ります)。

調べたことや考えたことをこうした記事にまとめるのも、そうすることで荷を下ろしてすっきりさせて、次の新しいことに取り組めるようにするという目的があったりします。

先に述べた現在の完成形を概念的に分解すると、このようになります。

とにかくシンプルにすっきりさせたいという思いが強いです。

 

 

 

 



AWSのLightsailでDjango設計図を使いできるだけ簡単にローカルで開発したプロジェクトを公開する

記事タイトルの通りです。

 

AWSのLightsailにはDjangoの設計図(テンプレート)が用意されているので簡単に公開できるのかなと思っていたのですが、意外と苦労しました。

 

そのための手順を説明した記事やドキュメントも不足気味です。

 

そこでこの記事にまとめました。

 

1.前提

ローカル環境でDjangoのプロジェクトの開発をして、GitHubで管理していることを前提とします。

GitHubのリポジトリの中にrequirements.txtファイルやmanage.pyファイルとDjangoのプロジェクトディレクトリがあり、Djangoのプロジェクトディレクトリの中にsettings.pyファイルがあると想定します。

ウェブサーバーはApache、データベースはMariaDB(MySQL)とします。

AWSのアカウントは設定済みとします。

 

2.インスタンスを作成する

インスタンスの作成は簡単です。

Lightsailからインスタンスを作成する画面で、設計図のところからDjangoを選ぶだけで、その他はデフォルトのままでよいです。

必要なら適当に変更してください。

表示言語設定は画面下部の赤丸で囲んだところにあるので、日本語がよければここから日本語に変更してください。

 

3.インスタンスに接続する

ターミナルのようなアイコンをクリックするか、縦に3つの点が並んでいるアイコンをクリックして「接続」を選ぶかして、ブラウザベースのSSHクライアントを立ち上げます。

黒い背景にコマンドを打ち込むターミナル画面が起動すれば成功です。

インスタンスを作成してから数分経過しないとうまく立ち上がらないです。

簡単さのためにこの記事ではブラウザベースのSSHクライアントを利用しますが、お使いのマシンからSSH接続しても構いません。

 

4.GitHubからリポジトリをクローンする

(1) リポジトリをクローンするためのディレクトリを作成する

どこでリポジトリをクローンしてもよいのですが、Bitnamiの公式チュートリアルのGet started with Djangoに従って配置したほうがわかりやすいです。

sudo mkdir /opt/bitnami/projects
sudo chown -R $USER /opt/bitnami/projects

コマンドの貼り付けは、右クリックからするようにしてください。

(2) GitHubのアカウントにSSHキーを追加する

秘密鍵と公開鍵を作成し、公開鍵をGitHubのアカウントに追加します。

秘密鍵と公開鍵を作成するコマンドは以下です。

ssh-keygen

いくつか質問をされますが、デフォルトのままエンターキーを押していけばよいでしょう。

次に、作成した公開鍵を表示します。

cat /home/bitnami/.ssh/id_rsa.pub

ssh-rsaから始まってbitnami@ip-172-26-9-251のような文字列で終わる暗号のような文字が表示されるはずですから、この全体を右クリックからコピーします。

それを以下のようなGitHubのSSHキー追加画面に貼り付けて追加します。

titleの部分は何でもよいです。

(3) GitHubからリポジトリをクローンする

これでGitHubからリポジトリをクローンできるはずです。

cd /opt/bitnami/projects/

git clone git@github.com:GITHUBACCOUNT/GITHUBREPOSITORY.git

GITHUBACCOUNTとGITHUBREPOSITORYの部分は、ご自身のリポジトリに合わせてください。

初回の接続なので接続するかどうかを尋ねられますが、「yes」と入力してエンターキーを押してください。

 

5.pipコマンドでPythonのパッケージをインストールする

GitHubのリポジトリ直下に用意したrequirements.txtファイルを利用して必要なPythonのパッケージをインストールします。

cd /opt/bitnami/projects/GITHUBREPOSITORY

sudo pip install -r requirements.txt

GITHUBREPOSITORYは先ほどクローンしたGitHubのリポジトリ名です。

mysqlclientのインストールに失敗するはずなので、mysqlclient · PyPIに載っている以下のコマンドを実行してから再挑戦します。

sudo apt-get install python3-dev default-libmysqlclient-dev build-essential pkg-config

sudo pip install -r requirements.txt

インストールの確認を求められたら、yと入力してエンターキーを押してください。

Lightsail自体が仮想環境なのですから、Pythonの仮想環境を作成せず、sudoでpipを実行してインストールしています。

これが一番簡単です。

 

6.データベースを作成する

MariaDB(MySQL)が最初からインストールされてはいるのですが、Djangoで使うためのデータベースを自分で作成しなければなりません。

データベースに接続するためのパスワードがわからなくて私はハマりました。

ホームディレクトリのbitnami_application_passwordに書いてあるのですね。

ということでまずそのパスワードを表示します。

cat /home/bitnami/bitnami_application_password

パスワードが表示されたことを確認してから、次のコマンドを実行します。

mariadb -u root -p

パスワードの入力を求められるので、先ほど表示させたパスワードを右クリックからコピーし、右クリックで貼り付け、エンターキーを押します。

MariaDBに入ることができたら、以下のコマンドを実行して、データベースを作成します。

CREATE DATABASE XXXXXXXX;

XXXXXXXXの部分には、Djangoのプロジェクト名など、適当なデータベース名を指定してください。

データベースを無事に作成できたら以下のコマンドを実行してMariaDBから抜けます。

quit

 

7.Djangoの設定をする

(1) settings.pyを調整する

Get started with Djangoを参考にしてsettings.pyを調整します。

データベース接続の部分は以下のように設定します。

DATABASES = {
  'default': {
    'ENGINE': 'django.db.backends.mysql',
    'NAME': 'XXXXXXXX',
    'HOST': '/opt/bitnami/mariadb/tmp/mysql.sock',
    'PORT': '3306',
    'USER': 'root',
    'PASSWORD': 'PASSWORD'
  }
}

XXXXXXXXの部分は、先ほど作成したデータベース名にします。

PASSWORDの部分は、bitnami_application_passwordに書いてあるパスワードにします。

ALLOWED_HOSTSの部分は、接続確認を優先して、ひとまず*に設定します。

ALLOWED_HOSTS = ['*']

接続確認できたらドメイン名に設定し直してください。そのときにDEBUGもfalseにしてください。

Lightsailに配置すべきsettings.pyファイル全体をローカル環境のエディタで記載し、それをコピーして貼り付けるようにするのが簡単かなと思います。

まずsettings.pyファイルが存在しているかを確認します。

cat /opt/bitnami/projects/GITHUBREPOSITRY/DJANGOPROJECT/settings.py

GITHUBREPOSITRYは先ほどクローンしたGitHubのリポジトリ名、DJANGOPROJECTはそのリポジトリ直下にあるはずのDjangoのプロジェクト名です。これらは同じ名前にすることが一般的ですが、異なる名前でも構いません。

settings.pyファイルの存在確認ができたら、それをviで開いて、内容をいったん全部削除し、ローカル環境からコピーした内容を貼り付けます。

vi /opt/bitnami/projects/GITHUBREPOSITRY/DJANGOPROJECT/settings.py

viでsettings.pyファイルを開きますので、以下のコマンドを入力してエンターキーを押して内容をいったん全部削除します。

:%d

ローカル環境のエディタで作成したsettings.pyファイルの内容を全部コピーして、右クリックから貼り付けます。

そうするとviの入力モードになっていますから、Ctrl+Cを押してコマンドモードに移行し(Escではコマンドモードに移行できませんでした)、次のコマンドを実行して保存して終了します。

:wq

ここでは簡便さのために直接settings.pyファイルを編集しましたが、できれば.envファイルで設定するほうがよいです。

 

(2) データベースにmigrateする

ここからはLightsail特有の手順ではなくDjangoの標準的な手順です。

python /opt/bitnami/projects/DJANGOPROJECT/manage.py migrate

このようなコマンドでmigrateします。

上記は絶対パスで記載しましたが、DJANGOPROJECTディレクトリの中にいるなら以下のコマンドで実行できます。

python manage.py migrate

 

(3) 静的ファイルをcollectstaticで集める

これもmigrateと同じ要領です。

python /opt/bitnami/projects/DJANGOPROJECT/manage.py collectstatic

または

python manage.py collectstatic

 

8.Apacheの設定をする

本来であれば、ここでmanage.pyのrunserverを実行して確認するとよいのでしょうが、そのためにはファイアウォールの設定を追加するなどの手間が生じますので、いきなりウェブサーバーであるApacheの設定をします。

基本的にはDeploy a Django projectに書いてある手順に従います。

sudo cp /opt/bitnami/apache/conf/vhosts/sample-vhost.conf.disabled /opt/bitnami/apache/conf/vhosts/sample-vhost.conf
sudo cp /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf.disabled /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

コピーしたApacheの設定ファイル中のsampleをGITHUBREPOSITORYとDJANGOPROJECTに置換します。

GITHUBREPOSITORYとDJANGOPROJECTが同じ名前なら、以下のコマンドだけで置換できます。

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

GITHUBREPOSITORYとDJANGOPROJECTが異なる名前なら、以下のように2段階で置換します。

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s@GITHUBREPOSITORY/GITHUBREPOSITORY@GITHUBREPOSITORY/DJANGOPROJECT@g /opt/bitnami/apache/conf/vhosts/sample-vhost.conf

sed -i s/sample/GITHUBREPOSITORY/g /opt/bitnami/apache/conf/vhosts/sample-https-vhost.conf

sed -i s@GITHUBREPOSITORY/GITHUBREPOSITORY@GITHUBREPOSITORY/DJANGOPROJECT@g /opt/bitnami/apache/conf/vhosts/sample-httpsvhost.conf

最後にApacheを再起動します。

sudo /opt/bitnami/ctlscript.sh restart apache

 

9.ネットワークの設定をする

ブラウザでインスタンスを作成したページに戻り、「Django-1」のようなインスタンスの名前をクリックして、「ネットワーキング」というタブから、静的IPをアタッチします。

そこに表示されているパブリックIPV4アドレスの数字をブラウザのURL欄に打ち込むと、ページが表示されるはずです。

httpsではないためにブラウザが警告を発することがありますが、危険性を承知の上で続行するとページが表示されます。

 

10.HTTPSの設定をする

独自ドメインのAレコードに先ほど接続確認をしたパブリックIPV4アドレスの数字を設定してからの作業になります。

Auto-configure a Let’s Encrypt certificateに書いてある手順そのままです。

sudo /opt/bitnami/bncert-tool

リダイレクトの設定やメールアドレスなどを質問されるので、適当に答えてください。

 

11.ハマりやすいポイント

(1) ブラウザベースのSSHクライアント

ブラウザベースのSSHクライアントのコピーアンドペーストに少しハマりました。

結論としては、すべて右クリックで操作することです。

SSH接続のための公開鍵のコピーをコマンドでしようとしたら失敗しました。

また、viもEscキーでコマンドモードに戻れないなど、いつもの操作と挙動が異なり戸惑いました。

日本語が表示されず文字化けすることにも苦しめられました。

環境変数の変更などを試してみてもうまくいきませんでした。

文字化けしている部分をコピーしてSSHクライアント以外の場所に貼り付けると読めるようになるので、それで一時しのぎはできます。

 

(2) Pythonのパッケージ管理

結論としては、上記に記載したように、/opt/bitnami/projects/以下にDjangoのファイルを配置して、sudo pipでパッケージをインストールすることになります。

最初はホームディレクトリにDjangoのファイルを配置したせいで、wsgi.pyファイルで no module named DJANGOPROJECT(DJANGOPROJECTは具体的なプロジェクトの名前)エラーが発生してハマりました。

/opt/bitnami/apache/logs/error_logのApacheのエラーログを見てこのエラーに気づきました。

そのときはwsgi.pyファイルに以下の記述を追加して一時的に切り抜けました。

import sys
sys.path.append(os.path.dirname(os.path.abspath(__file__)))
sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..')

この記事の上の部分で説明したように公式ドキュメントに準拠した場所に配置すれば、このような一時しのぎは不要です。

 

(3) mysqlclientのインストールエラー

これも記事中に記載した通りです。

公式ドキュメントをきちんと読まなければなりませんね。

 

 



プログラミング学習にまつわる雑感(コーディング原則本等の自分なりのまとめ)

私は、この数年で、プログラミングスクールの講師や実際の現場でコードを書くなどのエンジニア関係の仕事の比重が高まり、プログラミング学習について考えることが多くなってきました。(それ以前の経験についてはWebサイト制作の個人史Webサイト制作の個人史2をご参照ください。)

仕事での実践とともに、趣味的に雑多なコードを書いたり学習をしたりしつつ、コーディング原則本なども読み漁りました。

そこで考えたことをこの記事にまとめます。本記事の末尾に掲げた10冊の本の内容を極度に圧縮した記事だと言えます。

私はエンジニアとしての経験が決して豊富ではありませんが、様々な分野での学びと教える経験は豊富なので、これからプログラミング学習を始めようとしている人だけでなく、経験豊富なエンジニアに対しても新しい視点を提供できればと思って執筆しました。

 

1.プログラミングの特徴

天下り的な記述をさせてもらうなら、プログラミングの特徴は次の2点だと私は考えるに至りました。

(1) プログラムは製作物であるとともにドキュメントである→動作だけでなくわかりやすさも重要

(2) 結果の正しさを容易に観測できる→素早い変化や修正に開かれていることが重要

(1)は、車やテレビなどほとんどすべての製作物はドキュメント(設計図や説明書)とは別個なのだけれども、プログラムは製作物がドキュメントでもあるということです。ですので、求める動作をすることはもちろん、わかりやすさも重要になります。

(2)は、例えば宇宙物理学や心理学や政治学は、(装置や倫理などの理由から)仮説を立ててもその正しさを観測するのが極めて困難であるのに対し、プログラミングでは意図した動作をするかどうかという正しさを容易に観測できるということです。農業は収穫物という形で結果の正しさが目に見えやすいですが、結果を得るまでに数か月から年単位の時間がかかる場合が多いので、分単位や秒単位でPDCAサイクルを回すことのできるプログラミングほどには結果の正しさを観測するのが容易ではありません。この特徴は、プログラミングでは、作って、確かめて、変更して…というプロセスを何度も繰り返すということにつながります。

ChatGPTをはじめとした生成AIでプログラミング関係の精度が高く利用価値があるというのも、この点に関わっているのではないかと私はにらんでいます。生成されたコードが正しく動作すればそれでよいと言えるからです。政治学に関する質問をして生成された回答の正しさをすぐに確かめる術はないこととは対照的です。

 

2.コーディング共通原則のまとめ

いくつかの本に書かれていて、概ね受け容れられているであろうコーディングの共通原則を、上記の2つの特徴を軸にまとめることができます。以下では、その観点から、私が重要だと捉えているコーディングの共通原則を取り上げてコメントします。

なお、リファクタリングにつきましては、以下の共通原則に従うように適宜コードを見直すことであって、水準が異なりますから、独立した項目にはしませんでした。

わかりやすい名前をつける

これがコーディング原則の第一歩かなと思います。(予約語などの不適切な名前は当然除外するとして)変数や関数などにどのような名前をつけても同じように動作しますが、ドキュメントとしての読みやすさは全然違ってきます。わかりやすい名前をつけると、脳の認知負荷が顕著に減ります。

読みやすいコードを書いてコメントで補う

プログラミングコードは製作物であるとともにドキュメントでもありますから、コード本体が読みやすいのが理想です。読みやすいコードを書けない場合は、コメントで補うべきです。その手の本によく書かれていることですが、数か月後の自分は他人も同然であり、数か月後に変更や修正をすることもよくありますから、わかりやすいコードとコメントはとても大切です。

DRY、KISS、YAGNI

それぞれ、Don’t repeat yourself(繰り返しを避ける)、Keep it simple stupid(シンプルで愚鈍にする)、You ain’t gonna need it(それはきっと必要にならない)の頭文字を取った原則です。繰り返しがなければコードが読みやすくなるとともに変更も1箇所で済み、シンプルであればわかりやすくて機能の追加もやりやすく、プログラムは変更が容易なので先回りしすぎず必要になったときに機能を付け加えると割り切って考えやすいです。

 

3.議論のあるコーディング原則

以下では議論のあるコーディング原則を取り上げます。混乱を招く可能性があるので、自信のない人は読み飛ばしてください。

オブジェクト指向か関数型か

要はわかりやすいほうを採用すればよいのではないでしょうか。オブジェクト指向にすると、コードのわかりづらい部分を設計図に相当するクラスの部分に書いてインスタンス化して使う部分の記述が簡潔になります。大規模なライブラリはオブジェクト指向で設計されていることが多いので、それを使う際には必然的にオブジェクト指向の記述になります。私は、大規模な仕組みを一から作ることはまずないので、自分で定義する場合には関数型にします。

テスト駆動開発

テスト駆動開発も、効率が上がりわかりやすくなるなら採用すればよいですし、そうでなければ無理に採用する必要はないと考えます。テストは結果の正しさの観測をさらに容易にする仕組みだと捉えることができます。ですので、結果の正しさを観測して変更することを何度も繰り返すことが予想される場合にはテストを書いたほうが効率的ですし、何が正しい動作であるのかがテストによりわかりやすくなります。他方で、テストを書くにも労力がかかり、テストコード自体は読みづらいことも多く、そのデメリットを上回りメリットがなければテストを書かなくてもよいのではないかと私は考えます。

疎結合と密結合

疎結合がもてはやされる風潮がありますが、今後必要とされるであろう変化や修正に開かれていることが重要だということに行き着くと私は考えます。例えば、(WP REST APIを駆使して意識的に疎結合にしようとしなければ)WordPressは簡単に始められることの裏返しとして密結合になりやすいですが、それが問題になるかどうかは状況次第です。小さな団体の外部告知用ホームページなら今後機能面の変更が必要になる可能性は低いのでWordPressで問題ないことがほとんどでしょうけれども、いろいろな機能の追加が予定されているウェブアプリをWordPressで作ろうとすると将来的に苦労する姿が目に浮かびます。仮想化やクラウドについても同様で、変化が見込まれそれらを使ったほうが合理的なら使えばよいし、必要なさそうなら使わなければよいです。

そもそも、何が一つの結合かということにも議論の余地があります。単純化をするべきか過度の単純化を避けるべきかという問題も、結局のところ中庸と言いますか、適度なバランスということになるのかなと思います。

 

4.「わかりやすさ」と「正しさ」の深堀り

ここまでは「わかりやすさ」と「正しさ」を自明で一つに定まるものと想定してきました。しかし、前節の議論からも垣間見えますように、「わかりやすさ」と「正しさ」は自明でもなければ一つに定まるとも限りません。

「わかりやすさ」は人によって大きく異なります。これは私の学び教える経験から自信を持って言えることです。同じ説明をしても、とてもわかりやすいと感じる人もいれば、まったくわからないと感じる人もいます。その人の前提知識や好みによって大きく左右されます。

コードにコメントを書くときも、未来の自分に向けるなら自分にとって難しく感じたことのメモを書きますし、非エンジニア向けならそうと意識して書きますし、プログラミングスクールの受講生向けなら教育的配慮をしますし、野球の好きな人が読むなら野球のたとえを使います。

使用しているプログラミング言語やフレームワークの慣習に従うと、その慣習を共有している人にとってはわかりやすくなります。ですので、私は、LaravelやDjangoを使うときに、標準的な構成にして、そのビジネスドメイン固有のロジックはUseCasesとして別のディレクトリに切り出すようにしています(5年間 Laravel を使って辿り着いた,全然頑張らない「なんちゃってクリーンアーキテクチャ」という落としどころが提示しているこの方法がわかりやすさの絶妙のバランスを保っていると私は感じています)。

本記事における「正しさ」は「依頼主が求める動作」という意味ですが、これにしても自明で一つに定まるとは限りません。求める動作を事前に依頼主が正確に見極めていることのほうが珍しいです。「顧客が本当に必要だったもの」という標題の下にで示されるブランコの絵は有名ですよね。

顧客が本当に必要だったものから学ぶこと | Casley Deep Innovations株式会社 技術ブログ

ここまでの記述からお気づきの方も多いかと存じますが、私は圧倒的にアジャイル派です。結果の正しさを容易に観測できるというプログラミングの特徴を最大限に活かせるからです。金融や人命に関わるようなミッションクリティカルで大規模なプロジェクトではなく、ウェブや業務効率化などの小規模プロジェクトに従事してきたという背景もアジャイルを推す理由になっています。

 

5.プログラミング学習のコツ

正しさ=求める動作をはっきりさせる

この流れからプログラミング学習のコツを考えるなら、正しさ=求める動作をはっきりさせるところからスタートすべきです。

現状に不満がなければわざわざプログラミングを学ぶ必要はありませんし、ZoomやkintoneなどのSaaSで解決できるならそのほうが早いです。車輪の再発明をする必要はありませんからね。怠惰は美徳という言葉もあります。どれほど美しいコードも、その仕事が必要ではなくコードがいらないことには劣ります。

自分では特に作りたいものはないけれどもプログラミング関係の仕事ができるようになりたいということでしたら、将来の顧客の立場で何を作りたいか考えてください。

正しさ=求める動作がはっきりしてきて、そのためにプログラミングが必要だということになりましたら、臆せず取り組んでください。自分は専門家ではないからと遠慮しなくてもよいです。何らかの動作を求めるその領域では自分が専門家です。正しさを決めるのはエンジニアではなく依頼主です。自分が作りたいものがあってプログラミングを学ぶということで依頼主とエンジニアが同一人物なら、自分が作りたいものが作れればそれでよいのです。

プロトタイプを早く形にする

その際には、欲張りすぎず、最小の労力で最大の効果が得られる部分を早く形にすることを目指すとよいです。リーンスタートアップで言うところのMVP(Minimum Viable Product、実用最小限の製品)です。80-10-10の法則と80:20の法則に共通して、少しの労力で大部分の仕事は片付けられるという含意があるということもあります。

スモールステップで少しずつ進むのがコツです。入試問題でも小問に沿って進んでいくと大きな問題も解けるということに似ています。余談ですが、私が入試科目とプログラミングを問わず教える仕事をするときには、いかに小問を刻んでいくかということを大切にしています。適切に小問を刻んで区切ることができれば、それだけで解決することも多いです。

最初はとにかく動けばよいという感覚で試行錯誤することになりますが、動くことを確認できたらきれいなコードにリファクタリングするようにすると、実は近道になります。

私の個人的な経験の紹介

私自身の実例をいくつかお伝えします。

まず、2000年から2010年頃にかけて、ホームページ(ウェブサイト)を作りたいと思いました。正しさ=求める動作は、インターネット上で内容を見ることができるということです。現在なら各種SNSやWordPressを使うでしょうが、当時はHTMLとCSSを新たに学びました。

次に、動的なサイトを作りたくなって、Perlを学ぶとともに、開発環境としてLinux(Ubuntu)を使い始めました。Linuxを使うことには、比較的古いPCでも無料のOSで快適にウェブブラウズや文書作成をしたいという目的もありました。それまで使っていたWindowsからLinuxにいきなり全面的に切り替えるのは困難だったため、併用しながら少しずつ置き換えていきました。最初はLinuxの世界に圧倒されましたが、ウェブブラウズさえできればいいのだと目的をはっきりさせると、案外簡単にできました。当時よりも現在のほうが環境が整っていますし、Linuxに挑戦してみることをみなさまにもお勧めします。

それから、数学の教材を作るためにTeXを使い始めました。それまではWordのフィールドコードで数式を入力していたのですが、特に分数などを表示するのが面倒だったので、分数が登場する計算問題のプリントをTeXで作ることを当面の目標に据えました。最終的にはTeXとemathでグラフや図形も自由に描けるようになりました。

比較的最近のこととしては、Pythonで給与計算などの業務効率化をしました。これもExcel等でやっていた業務を少しずつPythonに置き換えていきました。

何をどのように学ぶかを計画する

正しさ=求める動作をはっきりさせたとしても、何をどのように学んでいくかは迷います。次々と新しい技術が登場することもあって全部を学ぶことは到底できませんが、古い技術にしがみついて非効率になるのも避けたいです。損得で考えるなら学習コストを固定費と見立てて損益分岐点を考えることになるでしょうが、将来的な投資という意味合いや好みや楽しさも考慮します。個人的には、LinuxやSQLあたりは長年の検証を経て安心感があるとともに陳腐化しにくいので将来を見据えた学習の投資をする価値があり、好みにも合致していて楽しいと感じます。

専門分野を持っている人がプログラミング学習をすることに意義がありますし、逆にエンジニアが特定のビジネス領域のことを知るのも同じように意義があります。この記事の最初のほうで述べたプログラミングの2つの特徴からそう言えます。わかりやすさも正しさも特定のビジネス領域の知識と大いに関係しますので。

人月の神話やブルックスの法則はコミュニケーションコストの大きさを示唆しています。自由な文章から判例を検索できる判例探索サービスを作りましたのように一人で全部完結させるとコミュニケーションコストはゼロです。

もっとも、一人でできることなどたかが知れているので、何らかの形での協力関係を築くことは必須です。フリーソフトウェアやOSSがそのための一つの形かもしれません。

具体的な学習法

何のために何を学ぶかをおよそ決めた後は実践あるのみです。定まったカリキュラムがあるわけではなく自分の実現したいことを中心に学ぶことになりますが、あまりにも断片的な事柄をインターネットで検索しても道に迷って時間を浪費しがちです。

そこで、どこかの時点で公式ドキュメントをざっと一通り読むことを私はお勧めします。わからないことがあっても深く気にせず、公式ドキュメントのどのあたりにどのような内容が書いてあったのかをだいたい把握しておくと、後が楽になります。私は、割と早い段階でLaravelの公式ドキュメントInstallation – Laravel 10.x – The PHP Framework For Web Artisansを一読したことが、そのときにはすっきり理解できなくても、後で大いに役立ったと感じております。

網羅的にまんべんなく学習するという意味では、資格試験を活用するのも吉です。資格試験は自分の知識に抜け落ちがないかの確認にもってこいです。日時を決めて受験を申し込むと勉強する気分が高まります。

本を読むことも、情報が古いかもしれないという欠点はありますが、安定的な知識を網羅できるという点で有効です。PCの画面にばかり向かっていると目が疲れるので、休憩を兼ねて本を読むこともできます。

もちろん、わからないことや気になったことをインターネットで調べることも日常的に行っています。日々新しい技術や概念が登場しますから、それを調べて学習できる生活の余裕があるということが一番大切かもしれません。

 

6.落ち穂拾い

UNIX哲学の一つに、設定やフィルタにテキストを用いるという原則があります。バイナリではなくテキストを扱うということは、わかりやすさの点から極めて重大な点です。

それに比べると、CUIかGUIかという点は、ケースバイケースかなと思います。テキストを扱うCUIのほうがわかりやすい場面もあれば、見た目で直感的に操作できるGUIのほうがわかりやすい場面もあります。一定の知識や技術のある人が繰り返し作業をするときはCUIが適しているとは言えそうです。

AWSの操作をするとして、慣れないうちはGUIで操作するのが簡単だけれども、慣れてきたらIaC(Infrastructure as Code)という点からもCUIベースに移行したほうがよいでしょう。

WordPressのブロックエディタは、従前の手法と比べるとGUI的な要素が強くなっており、わかりやすいと感じるかわかりにくいと感じるかは人それぞれでしょう。DRY原則に準拠していて素早い変化や修正に開かれていますから、フロントエンドから入った人がブロックエディタを極めるというのは一つの道なのかなと思います。

最後に大事なこととして、透明性が挙げられます。透明性はわかりやすさの前提条件ですし、透明性を高めて多様な観点から結果の正しさを観測することも頑健性につながります。

 

7.参考文献

本記事ではページ数を示して直接引用することはしませんでしたが、以下の文献で提示されていたアイデアを咀嚼して再構成しました。興味のある人はぜひ直接読んでみてください。

総合的なコーディング原則本


リーダブルコード : より良いコードを書くためのシンプルで実践的なテクニック


作 者: 

出版社: オライリー・ジャパン

発売日: 2012年10月05日

コーディング原則本として真っ先に挙げられるのが『リーダブルコード』でしょう。おもしろい絵と具体例が豊富で読みやすいので、最初に読む本としてお勧めします。


プリンシプルオブプログラミング : 3年目までに身につけたい一生役立つ101の原理原則


作 者: 

出版社: 秀和システム

発売日: 2016年06月08日

こちらの『プリンシプルオブプログラミング』も有名ですね。興味深い原則や法則を紹介してくれる本です。


プログラマが知るべき97のこと


作 者: 

出版社: オライリー・ジャパン

発売日: 2011年03月04日

『プログラマが知るべき97のこと』は、いろいろな人の意見や考えが寄せ集められており、インターネット上で全文を無料で読めますから、気軽に読めます。


ルールズ・オブ・プログラミング : より良いコードを書くための21のルール


作 者: 

出版社: オライリー・ジャパン

発売日: 2023年09月15日


『ルールズ・オブ・プログラミング』は新しめの本です。C++で書かれているゲームのコードが例に取られているので、読みやすいと感じる人もいれば読みにくいと感じる人もいるでしょう。

古典


人月の神話


作 者: 

出版社: 丸善出版

発売日: 2017年08月16日

『人月の神話』は古典的な部類ですね。歴史的な読み物と思っていただいてもよいかもしれません。プロジェクトマネジメント寄りです。


UNIXという考え方 : その設計思想と哲学


作 者: 

出版社: オーム社

発売日: 2001年07月30日

『UNIXという考え方』も古典的です。技術寄りです。


フリーソフトウェアと自由な社会 : Richard M.Stallmanエッセイ集


作 者: 

出版社: アスキー

発売日: 2003年09月04日

『フリーソフトウェアと自由な社会』は、フリーソフトウェアやオープンソースを考える書です。

各論


リファクタリング : 既存のコードを安全に改善する


作 者: 

出版社: オーム社

発売日: 2019年12月20日

『リファクタリング』というタイトルの通り、リファクタリングについて第一に読むべき本です。


テスト駆動開発


作 者: 

出版社: オーム社

発売日: 2017年11月10日

『テスト駆動開発』という書名にもなっている概念が斬新です。


エリック・エヴァンスのドメイン駆動設計 : ソフトウェア開発の実践 : ソフトウェアの核心にある複雑さに立ち向かう


作 者: 

出版社: 翔泳社

発売日: 2019年12月16日

『エリック・エヴァンスのドメイン駆動設計』はかなり読みにくいのですが、大事なことが書かれているような気がします。

 

 

 



自由な文章から判例を検索できる判例探索サービスを作りました

司法試験短答式過去問演習サイトの解説を作り始めましたでお伝えしましたように、司法試験短答式過去問演習サイトの解説を少しずつ作っています。

 

その過程で、短答式試験の選択肢となっているような自由な文章から判例を検索したいというニーズを強く感じました。

 

裁判例検索 | 裁判所 – Courts in Japanではキーワードから検索できても自由な文章に対応していませんし、Google等でその文章に「判例」というキーワードを加えて検索しても思うようにヒットしなかったからです。

 

それなら自分で作ってしまおうと思って作りました。

 

司法試験過去問題集

 

2023年11月中旬頃までの最高裁判例を対象としています。

 

技術的な詳細は追ってお伝えするとして、概要を紹介します。

 

以下のデモ動画の50秒あたりからが判例探索の部分です。

 

 

 

比較的うまく表示されたものを、2023年司法試験短答式試験からいくつか紹介します。

・憲法第9問

求める判例がトップに表示されています。

 

・民法第23問

この1ページ目の左から3番目の判例がここでは最適かなと思いました。

他の判例も読むと勉強になります。

この4ページ目の4番目の近時の判例は、民事訴訟法の論点とも大きく関わっています。

 

・刑法第20問

3番目の判例にこの問題の着想を得たのでしょうね。

 

検索する文章が長いほうがうまく表示される傾向にあります。

Legalscape、大規模言語モデルを活用した次世代型リーガルリサーチAIを開発——森・濱田松本法律事務所との協働により高い精度を達成し、今後の実用化を目指す (2023-06-12) | 株式会社Legalscape | リーガルスケープに対抗意識を燃やして試してみた結果も載せます。

この1ページ目の結果は、近いですが、ズバリの判例はありませんね。

この6ページ目の4番目にようやくズバリの判例がありました。

 

一人で趣味的に作ったにしては悪くありませんし、最近の司法試験では論文式試験でも判例の比重が高くなってきているような気もしますので、学習者としてはいろいろな判例に寄り道するのもしっかりとした力を涵養するのに役立つと思います。

 

 

 



令和5年司法試験成績通知(論文)

令和5年司法試験の成績通知を公開します。

試験科目 順位ランク
憲法 B
行政法 C
民法 B
商法 A
民事訴訟法 A
刑法 C
刑事訴訟法 D
選択科目 35.71
合計点 395.84
順位 1397

再現答案も過去の記事にありますので、ご参考になれば幸いです。

出来のよくない科目もありますが、どうにか合格できたという感じですね。




top