Singleton

とあるパッケージの保守を10年ほどしていて、問い合わせを全てRedmine のチケットで管理していた。 カスタムフィールドにどの機能の話なのかカテゴリを用意して、チケット作成時に保守担当者に選択してもらっていた。ただ、後から分析しようと思ってカテゴリを見てみると、結構担当者によってまちまちというか、間違っていることも多かった。 これまでは分析のときにそれぞれ直していたが、どうにかチケット作成時に正しいカテゴリを選択してもらえないかと思い、fastText で自動化することにした。 fastText の導入環境 fastText とは、Facebook が作成した自然言語処理のライブラリだ。高速かつ簡単に利用できる。 今回は、これまでRedmine に蓄積した約2000の問い合わせを教師データに、問い合わせの内容から対象カテゴリを分類するようにした。 環境、ライブラリは以下の通り。 Windows10 PyCharm fastText janome 日本語をfastTextで処理する場合は、事前に分かち書きという処理をする必要がある。分かち書きにはMeCab というライブラリを使う情報が多いが、この自動化をした当時はpip install で ERROR: Command errored out with exit status 1: のエラーが出て解消するのが面倒だったので、簡単に入れられるjanome を採用した。 (※現在はmecab もpip install で簡単に入れられる様子) 事前準備 まずはfastText とjanome を導入する。 PyCharm でプロジェクトを作成し、View - Tool Windows - Terminal で以下を実行。 git clone https://github.com/facebookresearch/fastText.git cd fastText pip install . pip install janome モデルの作成 まずはRedmine からチケットをCSV エクスポートする。そしてカテゴリと問い合わせの題名+本文だけに加工する。こんなイメージだ

2020年10月に発売されたOculus Quest 2 という商品はご存知だろうか。 リンク 完全ワイヤレスのオールインワンVR。高額なPC や邪魔なケーブル類は不要で、単体で動作する。これまでのVR 製品より高解像度にも関わらず、値段はそれらより安い。ストレージ64GB なら4万円以下と破格の値段だ。 私はこの商品を発売日に購入した。それまでのVR 体験といえばハコスコくらいだった私は、大いなる期待を持って商品の到着を待った。 そして、その体験は素晴らしいものだった。しかし、私は3ヶ月後に全く使わなくなっていた。一体何が起こったのか、Oculus Quest 2の買ってよかった点と、使わなくなった理由を実体験を元に紹介する。 ちなみにAmazon のレビューにあるような、Facebook アカウントの停止などの不具合は一切起こらなかった。 買ってよかった点 ファーストインパクトがすごい これは感動の一言に尽きる。 顔を動かせば周囲を見渡すことができ、ものを掴んだり投げたりすることができる。その場にいながら雪山やサファリを見たり世界中を飛び回ることができる。また迫りくる敵の攻撃を避け、剣で切るといったような動作を実際に体を動かしながら楽しむこともできる。 友人との集まりでも活躍する。つけている人は上記の感動を体験でき、他の人はつけている人のコミカルな様子を楽しめる。 空間の制限がない 映画に出てくるハッカーのように、ディスプレイを目の前いっぱいに並べて作業をしたいと思ったことはないだろうか。とはいえ実際にそれをやるには費用がかかるし、大量のディスプレイを置く空間が必要だ。しかしOculus Quest 2 なら無料でそれを実現できる。 バーチャルデスクトップのアプリをいくつか試したが、Immersed という無料のアプリが最も理想に近かった。 ディスプレイの数、大きさ、湾曲まで自由にカスタマイズできる。また背景も選択でき、雪の降るロッジで温かい暖炉に当たりながらディスプレイに囲まれて仕事をする、というのも可能だ。 ちなみに私は大小合わせて6ディスプレイを配置して仕事をしてみたが、実際には3つしか使い切れなかった。

心理的安全性という言葉はご存知だろうか。 心理的安全性とは、対人関係においてリスクある行動を取ったときの結果に対する個人の認知の仕方、つまり、「無知、無能、ネガティブ、邪魔だと思われる可能性のある行動をしても、このチームなら大丈夫だ」と信じられるかどうかを意味します。 Google 「効果的なチームとは何か」を知る Google のプロジェクトでよいチームの条件なにか？を調査したところ、スキルが高いメンバで構成されたチームよりも、心理的安全性の高いチームのほうが成果を上げていたという結果が出て大きく広まった言葉だ。 こんなことを言ったり聞いたら無能と思われないか？という恐怖がないので、コミュニケーションは潤滑になるし、何か問題があれば発見されやすい。またアイデアも自由に議論できるのでイノベーションが起こりやすくなるというわけだ。 私のいる会社も、組織を大きくを変えよう、そのために心理的安全性は大切だとCxO (ぼかし)が説いて社内SNSで都度都度発信している。 その社内SNSのあるメッセージから、心理的安全性ってエラい人に何でも言っていいってことじゃないと思った話。 心理的安全性を説くCxO に送られたあるメッセージ ある日一人の社員がCxO 宛にこんなメッセージを送っていた。「改革って言うんだったら、毎日使っている社内システムのここ直してくださいよ！そのくらいすぐできますよね？」その後、その社員は別のチャンネルで「言ってやったぜ！」と仲間内に発信していた。 確かにそれは毎日使うシステムで、1クリック多い構成になっていたが、その手間がかかるのは1日1回だけだった。 もちろん私もその手間がなければ良いなとは思うが、正直傍から見ていると大事の前の小事というか、大きな改革を進めているCxO に対して言うことか？としか思えなかった。 恐らくその社員は、以前からその手間以外にも社内に色々な不満を持っていたのだろう。そこで心理的安全性を高め自由に議論しようというCxO に、これまでの不満をぶちまけたのだと思う。 正論をありのままぶつける人がいるチームは心理的安全性が低下する その社員からすれば、それは正論だったのだろう。大きな改革よりも、日々困っている私達を見てくれよ。こんなに困っているんだ。自由な議論を歓迎するなら言ってやると。 大きな改革の前にそんな小さなことを言ってはいけ

iOS アプリを開発するときに、データの格納先としてCloudKit を選択することは多いのではないだろうか。CloudKit はiCloud 上のデータベースで、アプリ単位1PB まで利用できる。  CloudKit Dashboard という管理機能も備え、スキーマやレコードの管理もでき非常に便利なのだが、一つ大きな欠点がある。 CloudKit Dashboard からデータをエクスポートできない 報告や分析するときにデータをエクスポートして加工することは多いのではないだろうか。残念ながらCloudKit Dashboard 上では、そこまでグラフィカルな表現はできず、またデータのエクスポート機能も備えていない。 そこで今回はSwift5 でCloudKit のデータをCSV にExport する方法を書く。 Swift5 でCloudKit のデータをCSV にExport する ソースコード private func exportCloudKit(){ let df = DateFormatter() df.dateFormat = "yyyy-MM-dd HH:mm:ss" // Change header var text = "Created,Code,Name\n"; cloudKitLoadRecords() { (records, error) -> Void in if let error = error { print(error) } else { if let records = records { for record in records{ // Change Fields let date

実はこのブログは一度削除されている。といっても使っている途中に何か規約違反したとかではなく、Blogger を始めた瞬間に削除された。また、同じアカウントで新しいブログを立ち上げても、全て数分後に削除された。 Web を検索してもこのケースはあまり無いようなので対処法と経緯を書く。 対処法 再審査をリクエストして待つ 。 このケースでは4日後に復元された。対処法でも何でもないが、待つしか無かった。 経緯 Blogger のURL 、表示名を決めて、よし始めようと設定周りを見ていたら、急に「ブログを削除しました」のページになった。 そしてブログを削除しましたとのメールが来る。内容は「ブログについて審査の必要があるとの報告を受けて審査したところ、SPAM に関するBlogger のポリシーに違反している」とのこと。 始めた瞬間に報告を受けた？誰かに監視されている？と思ったけどメールに Blogger のコミュニティ ガイドライン  を見るように書いてあったので見てみた。 Singleton という名前がデザインパターンやウイスキーと同じなので「なりすましとアイデンティティの不実表示」なのかと思って、複数の別の名前でブログを立ち上げても数分後に全て削除された。 SPAM に関するBlogger のポリシーに違反しているとのことなので、SPAM の項目を参照したところ内容は以下の通り。 スパム行為を行わないでください。これには、望まれない宣伝や営利目的のコンテンツ、自動化されたプログラムによって作成された迷惑コンテンツ、大量勧誘と思われる迷惑な反復コンテンツや無意味なコンテンツなどが含まれます。 まだBlogger を始めたばかりなので、宣伝やコンテンツはない。気になったのは「自動化されたプログラム」の箇所。ブログ作成時に一つだけ操作ミスの心当たりがあった。 原因 ブログの表示名を確定して投稿の初期画面が表示された後に、ブラウザの戻るボタンを押してしまった その後進むボタンで戻ったとき、恐らく同じ設定のブログ作成リクエストが飛んでしまいSPAM と判断されたのだと思う。 なので同一アカウントで新しいブログを立ち上げても、自動化されたプログラムでブログを大量に立てようとしていると判断されて次々に削除されたのだと思う。 この場合は再審査をリクエストして待つしかない。このケースで

メールからタスクが発生することはまだ多い。その時メールの本文をコピーして、Redmineを開いて、チケット作成画面を開いて、説明欄に貼り付けてチケットを作成すると思うが、煩雑ではないだろうか。 Outlook からRedmine のチケットを作成するアドイン そこでOutlook アドインを作成した。以下からダウンロードできる。 https://f.easyuploader.app/20210804205153_6456326c.zip このアドインはOutlook(デスクトップ版)に、「Redmineに送る」右クリックメニューを追加する。 「Redmineに送る」右クリックメニューをクリックすると、メールの件名と本文を転記した状態でチケット作成フォームが開く。 チケット作成フォームを確定することで、Redmine にチケットを作成する。 インストール方法 SendToRedmine.zip をダウンロードして解凍する。 setup.exe を実行する。 SmartScreen のメッセージが表示された場合は、詳細情報→実行をクリックする。 インストールをクリックする。 インストール時にOutlook が起動していた場合は、アドインを読み込むため一度Outlook を再起動すると有効になる。 初期設定 Outlook 上部の「アドイン」 → 「設定」をクリックする。 RedmineUrl とApiKey を入力して、Project選択ボタンを押して確定すれば使用できるようになる。 各項目は以下の通り。 ・設定名：任意の文字列(※Project選択ボタンでプロジェクト選択すると上書きされる) ・RedmineUrl：Redmine のURL (http://example.com/redmine/ のよ

Outlook(デスクトップ版) では、いろいろな条件で本文に書いたURLのリンクが途切れる。例えば以下ようなURLだ。 長いURL マルチバイトの文字が入ったURL 空白が入ったURL メールがHTML形式であれば、ハイパーリンクにすればいいが、テキスト形式の場合はハイパーリンクが使えない。テキスト形式でも<>をつければ途切れないようになるが、毎回手動でつけるのは煩雑だ。 Outlook でリンクが途切れないように<>を自動でつけるアドイン そこでOutlook アドインを作成した。以下からダウンロードできる。 https://f.easyuploader.app/20210805063548_4b33376c.zip こういったメールを送信時に このように<>を自動でつけてくれる。\\ とhtml から始まる行が対象になる。 インストール方法 Complementor.zip をダウンロードして解凍する。 setup.exe を実行する。 SmartScreen のメッセージが表示された場合は、詳細情報→実行をクリックする。 インストールをクリックする。 インストール時にOutlook が起動していた場合は、アドインを読み込むため一度Outlook を再起動すると有効になる。一度有効になった後は、特に設定なく自動で<>を付与する。 ちなみに不要になった場合は、Windowsの「アプリと機能」からアンインストールできる。「Complementor」の名称で登録されている。

  同時期に走ったある2つのプロジェクトの話。 プロジェクトの規模、メンバのスキルはほぼ同じ。これまでウォーターフォール開発しか経験がなく、アジャイル開発は初めて。新しいプロダクトを作るプロジェクトで、アジャイル開発をチャレンジしてみようと始まった。 プロジェクトの成否を測るのは難しいが、一方はプロダクトリリース前にプロジェクトが中止になり、もう一方はプロダクトをリリースした。その違いは何だったのか。 ２つのプロジェクトに何が起こったのか ２つのプロジェクトはスクラムをベースにした。同じようにインセプションデッキを作成し、スプリントを分けて、プロダクトオーナー等の役割を決めて、デイリースタンドアップ、スプリントレトロスペクティブをした。 プロジェクトが進むに連れて、後に中止になったプロジェクトでは、機能の作り込みが膨らんだ。またアジャイルの名のもとに仕様変更が多数発生した。メンバーも疲弊した。 プロダクトをリリースしたプロジェクトでは、序盤にある作業をしていたので開発着手は遅れたが、機能の作り込みは膨らまず、仕様変更も抑えられ、メンバーと顧客の関係も良好のままリリースした。 初めてのアジャイル開発の成否を分けたもの プロダクトをリリースしたプロジェクトが、序盤にやっていた作業はインセプションデッキの深化だった。 その業務とはどんなものか、何が課題なのか、どう解決するのか、その先にどんな未来がまっているのか、どんなステップでその未来を目指すのか。顧客と一緒になって、それらをビジョンとして1つのドキュメントにまとめた。 徹底的にWhy, What, How をまとめた資料だ。これがあると顧客もメンバも間違わない。この機能は必要か？のような議論になったときに、それは今のステップではないと誰もが納得して判断できた。 これに対して、後に中止になったプロジェクトでは、そういった判断が効かなかった。あったほうがいい(かもしれない)機能は実装され、顧客がこうしたほうがいいと言ったものは優先度を上げて対応された。 必要なものはビジョンだ もちろん全く同じプロジェクトは存在しない。しかしこれは1つの事例だけではなかった。インセプションデッキを作らなかったり、形だけのインセプショ

近年は社内外のデジタルトランスフォーメーション(DX) を推進、支援する仕事をしている。 いろいろな業種の方と話をする機会が増えたが、現場ではまだDX への誤解が広がっているように思う。 DX したいということで話を聞いてみると、古いシステムを入れ替えたいという内容であったり、DX しましたということで話を聞いてみると、手作業だったものをRPA を導入して自動化したという内容だったりする。 なぜDX への誤解が広がったのか そもそもデジタルトランスフォーメーション(DX) とは 企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立すること。 出典:経済産業省 デジタルトランスフォーメーションを推進するためのガイドライン の定義とされているが、これと 2025年の崖 の話が合わさって、古いシステムは維持コストが高額になる→システムを刷新しないと生き残れない→システム刷新すれば新しい技術=デジタル技術だからDX は達成するになったのだと推測する。 システム刷新だけでは、なぜDX にならないのか 現場は非常に危機感を抱いている。そのうえで古いシステムを刷新したり、自動化したいということで、もちろんそれらはとても素晴らしい。 しかし、いまの業務そのものに疑問をもってプロセスや組織そのものを改善できないか検討していなかったり、自動化して空いた時間で何をするか検討がなされていないケースが多い。 そうなると、変化し続ける環境に変革することで適応し続けるという風土が育たない。一時的な効率化は起こるが、業務、組織、プロセスの変革が起こらず、その後が続かないためDX にならないのだ。 なぜそうしたいのか、どうしたいのか、その結果どうなるのか。必要なのは組織のビジョンだ。それらを描いてから、変革する上で必要なパーツとしてデジタルを活用すればいい。 重要なのはトランスフォーメーション。デジタルはあくまで手段に過ぎない。 もちろんデジタル自

総務省統計局の調査 によると日本の世帯数は約5,344万世帯。これに対し 厚生労働省の調査 によるとひとり親家庭は141万世帯、母子家庭は123万、父子家庭は18万世帯らしい。 つまり父子家庭は全体の0.3%ということだ。自分がそんなレアな存在になった実感はあまりないが、具体的にどんな生活をしているかはあまり知られていないのではないだろうか。 これからシングルファザーになる人に向けて(?)、また自分自身の整理のためにシングルファザー系エンジニアの生活実態を書く。 家族構成 私：エンジニア 長女：小学校低学年 次女：幼稚園 ちなみに私が親権をとった理由は相手のネグレクトだ。 一日のタイムテーブル 普段の平日の行動を起こしてみると以下のようになった。 案外普通ではないだろうか。幸い、娘たちも健康で小学校、幼稚園に楽しく行ってくれているため、送り出した後は自分の時間も持てている。 仕事は基本9:30 - 16:30の時短勤務で、コロナ以降はフルリモート(在宅勤務)だ。通勤がなくなり、仕事前後の時間を趣味に当てたり、昼休憩時に買い出しを済ませることができるようになったのは大きい。 仕事がオンラインでほぼ完結するエンジニア職はシングル家庭に向いているかもしれない(?)。 なお家事の時間短縮に大いに役立っている家電を以下の投稿で紹介しているので、気になったら参照してほしい。 子供を迎えたら、夕食を作り入浴、団らんの時間だ。就寝は大体21:00 - 21:30 になる。 困ったこと、悩み お母様方の井戸端会議に参加しづらい 子供を送った後、園の玄関前でお母様方が話し込んでいるのはよく見る光景だ。 これは私のコミュ力の問題だが、一体どんなタイミングでそれが発生し集合しているのかが分からない。一体何を話しているのか、どうやってスマートにその場に参加すればいいのか教えてほしい。 先生方にやたら気を使われる 父子家庭がレアケースでどう接したらいいのか測りかねているのか、私が威圧感を与えてしまっているのだろうか。先生方にやたら気を使われているように感じる。 先日娘を迎えに行った際には、先生から「いま制作をしているのですが、その、、、おばあちゃん宛にし

これまでRedmine の導入推進をしてきて、導入失敗しているプロジェクトにいくつかの共通項があったので、アンチパターンとしてまとめる。 Redmine 運用のアンチパターン 荒れ地 何も決めずにRedmine を使い始めて失敗した残骸。乱立したプロジェクト、カスタムフィールド、更新されないチケットたち。 最低限、チケットのトラッカーとステータスを決めて、定期の運用にRedmine をどう組み込むか決めてから始めよう。 溶岩流 大量の入力項目と必須項目。チケットを開くとカスタムフィールドで画面が埋まっている。 担当者にチケットの更新どころか作ることすらためらわせる。Excel台帳の列をそのままカスタムフィールドにしたときにありがち。 項目を1つにまとめられないか、そもそも必要か？を検討してからカスタムフィールドにしよう。管理項目はCSV エクスポート後に別で付与することも検討する。 神トラッカー タスクやToDoなどなんでもありなトラッカー名。 トラッカーで分類ができないので、溶岩流になりやすい。Redmine を使い始めるときにまず作業の分類はどんなものがあるかを考えてから、それをトラッカー名にすることを検討する。 ワープ 途中経過を記載しないチケット。ステータスの開始、終了だけが残っている。 ノウハウが全く残らないので、Redmine を使うメリットが感じられなくなる。作業の途中経過がノウハウ、資産になるのでコメントを記載しよう。 アンデット 終わらないチケットたち。 メモや備忘録のような完了基準がないチケットを作ると発生する。チケットが残り続けるので、残タスクの量が分かりづらくなったり、チケット一覧が大量に見えるので精神的負担になっていく。 そういったチケットは作らず、作業チケットの中にコメントで記載するようにする。 肥満児 1チケットに延々と記載が続く。担当者のモチベーションがガリガリ削られていく。 作業がどこまで進んだのか、また後から振り返って見たときに何が問題だったのか、どう解決したのか分かりづらくなる。 最初からある程度の作業で分けて子チケットにする。途中で長くなった場合は子チケットを作成する。 迷路 カスタムフィールド

  これまで開発プロジェクトにメンバーとして参加してきて、それから段々と認められてプロジェクトを任されたときは、とても嬉しかったと思う。 ただ、1担当からリーダーになるときは、これまでとは違った働き方、考え方をしたほうがいいポイントがある。 今回は初めてプロジェクトリーダーになった人に伝えたい働き方、考え方のポイントを書く。 リーダーが動かないとメンバーは動かない(動けない) まずはじめにリーダーになったとき、メンバーが思ったように動かないことに気づくと思う。でもメンバーを責めてはいけない。 メンバーは指示されたことをしっかりこなすように教育されている。逆に言うと指示されないことはしないようになっている。まずはメンバーにやってほしいタスク、作業の進め方、スケジュールを伝えよう。 リーダーの報告なしは、問題なしと受け取られる プロジェクトを進めていると、いろいろな問題、課題が発生する。そういった問題、課題は上司へ報告しよう。上司は複数のプロジェクトを見ているケースが多いので、報告がないプロジェクトは問題がないと捉えてしまいがち。 大抵の場合、これくらいはいいか、まだ取り戻せると思っていた内容が大きくなって取り返しのつかない状態になってしまう。その状態で報告を受けても、対処が難しくなる。問題が小さいうちに報告があると対処がしやすい。 はじめのうちは、どれを報告すべきか判断がしづらいと思うので、先に報告基準がまだはっきりしていないことを断って、全て報告してしまってよいと思う。その中で問題、課題の影響度、重要度の判断基準を学ぼう。 パーキンソンの法則を意識する 仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する Wikipedia パーキンソンの法則 メンバーにスケジュールを提示すると、そのタスクはスケジュールいっぱいまでかかる。また大抵何かしらの問題や割り込みが発生してスケジュールを超過する。 ただそれはメンバーが手を抜いているわけではなく、人間そういうものだと割り切ろう。予めバッファをもったスケジュールを組もう。 先を見る メンバーのときはその週の見通し、もしかしたら今日明日の見通しを立てておけばよかったかもしれない。 しかしリーダーは次のメンバーのタスクを用意しないといけないし、今発生している問

Chrome 拡張機能を作ってChrome ウェブストアに公開するときに、決済と配布地域は選択できるが、ストアの掲載情報にはすべての言語用しか書けない。日本語と英語でそれぞれ掲載情報を記載したい場合はどうすればよいか。 その場合は、拡張機能を多言語対応すると、複数言語で掲載情報を記載できるようになる。 Chrome 拡張機能を多言語対応する manifest.json に"default_locale"を追加 manifest.json に"default_locale"を追加する。下の例では英語をデフォルトにするため"en" で設定している。 { "name": "SharePoint Modern List See More", "description": "When displaying the item in the Modern List, display it in the state that clicked 'See More'.", "default_locale": "en", "version": "0.1", "manifest_version": 2, "content_scripts": [ { "matches": [ "https://*.sharepoint.com/*List*" ], "js": [ "jquery-2.2.0.min.js", "content_script.js" ], "run_at": "document_end", "all_frames": true } ] } _locales フォルダの作成 拡張機能のフォルダ配下に_locales フォルダを作成する。 _local

プロダクトのタスク管理にRedmine を10年ほど使い、他の部署にもRedmine の導入推進をしている。 その中で見えてきたRedmine 運用に失敗しないためのポイントを記載する。 今回は運用編。設定編はこちら 運用を失敗しないためのポイント(運用編) 定期のミーティングにRedmine を組み込み、チケットをベースに会話する まず、定期のミーティングでRedmine を利用することが最も重要だ。 普段の作業記録はRedmine で、ミーティングは別資料でとなっていると、作業者からは手間が増えただけと捉えられる。結果チケットの更新がされなくなっていく。 デイリーミーティングなどの定期の場でチケットをベースに会話することで、作業者にチケットを更新することの必要性を意識付ける。 なおRedmine 運用を始めたばかりのチケット更新で特にありがちなのが、ステータスの開始、終了だけが記録されていて、途中経過を書いていないケースだ。こうなると以前の台帳管理と何も変わらないと判断されて廃れていく。 Redmine の強みは随時更新できて作業の開始から終了までの記録が残ることだ。ミーティングの場では、作業状況のコメント入力と時間入力をチェックしよう。書いていなければ、話しながらその場で更新してもいい。 また作業の途中経過で調べた情報やハマったポイントは随時チケットに書いてもらおう。長期間プロジェクトを運用していると、後からその経緯を追うタイミングが必ずある。コメントと時間記録が大きなノウハウ、資産になる。 チケットは気軽に更新していいものだと作業者に意識付けをする 台帳管理に慣れている作業者は、チケットに誤った情報、調査途中の情報を書いてはいけないと思いがちだ。そのままRedmine 運用を始めると、これまでの進捗会、報告会のようにサマリした情報しかチケットに残さない。 前述の通り、Redmine の強みは随時更新できて作業の開始から終了までの記録が残ることだ。サマリされた情報にそこまで意味はない。結果を見れば分かるからだ。途中経過こそが重要な情報だ。チーム、メンバが辿った道のりを記録することが大きなノウハウ、資産になる。 私の場合は、最初に「チケット、コメントは報告書ではないので、調査途中の情報で仮に誤っていても問

プロダクトのタスク管理にRedmine を10年ほど使い、他の部署にもRedmine の導入推進をしている。 その中で見えてきたRedmine 導入時に陥りがちな設定ミスと、中長期で使う場合に避けたほうがよい設定がある。それらを避け、Redmine 運用に失敗しないためのポイントを記載する。 今回は設定編。 運用編はこちら 運用を失敗しないためのポイント(設定編) カスタムフィールドは最低限にする 典型的なアンチパターンとして、管理や分析用のカスタムフィールドが大量に登録され、チケット画面がカスタムフィールドで埋まっている状態がある。 こうなると入力する側としては、チケット作成のたびに多数の項目を埋める必要があり、チケット作成自体がされにくくなる。また更新するときも情報量が多くて気が滅入るので更新の頻度も下がる。こうなるとまずRedmine が定着しない。 まず重要なことはRedmine 使ってもらい定着させることだ。管理や分析に必要なカスタムフィールドは最小限にする。そういった項目はエクスポートしてからExcel などで追加し、管理、分析する方法もある。 あくまでRedmine は開発者、作業者ためのツールでFlyweight であるべきと考える。 モジュールは最低限にする 最初に導入したときは色々な機能を表示したくなる。しかし多く表示すればするほどRedmine に難しい印象を持たれて定着しづらくなるし、せっかくの情報が分散してしまうモジュールもある。なのでモジュールは最低限にしたほうがいい。 特に不要だと思うのは文書とフォーラム。 文書はファイル機能で代替できる。なおファイル機能の利用にも注意が必要だ。ファイルからチケットに飛べないので、どのタスクで発生したファイルなのか分かりづらくなるためだ。固定の設定ファイル等だけを登録するよう指導が必要だ。 フォーラムは議論がチケットに紐付かないので、ノウハウと作業が分散してしまう。あとから経緯を追いづらくなるため、議論の内容はチケットに残したほうがいい。 プラグインは最低限にする 色々と有用なプラグインはあるがRedmine のメジャーバージョンアップで動作しなくなることが割と多い。 Redmine のバージョンアップでは、レスポンスの向上や良い新

  AI がこれだけ一般化してGoogle やMicrosoft に登録するだけで使えるようになった現在、それらを技術要素の選択肢として検討できるかは、もはやビジネスの前提知識だ。 とはいえ何の目標もなく勉強するのも辛いので、AI の知識を体系的に学びつつ資格も取れるG検定について、合格したとき(2020#3)の勉強方法、対策方法を書く。 試験対策 G検定推薦図書で勉強する。なお分からないときに検索できるので 対策本は紙より電子書籍を推奨する。 (G検定は当日の書籍参照やネット検索が許可されている) 深層学習教科書 ディープラーニング G検定(ジェネラリスト)公式テキスト リンク 正直これだけでは合格できないが、AIの歴史や前提知識を体系的に勉強できるので、まずはこの本を読むといい。 徹底攻略 ディープラーニングG検定 ジェネラリスト問題集 徹底攻略 リンク 1.の知識を再確認しつつ、1.にない範囲を学習できる。1、2の理解が合格の最低ラインだと思う。試験形式 + 解説で勉強できるので、当日までに2周した。 AI白書 リンク 私は購入していないが、試験では法律関係や時事系の出題が割と多い。恐らくこの本でカバーできるのだと思う。 勉強時間 仕事前の30分、昼休憩の30分、仕事後の1時間の計2時間 / 日 を1ヶ月間継続した。 その他 ネット上に年代、人名、発言などをまとめたチートシートがある。正直それらを丸暗記してもあまり知識的な意味はないと思うので、一つ持っておくとよいと思う。 ただし、年代、人名、発言などの丸暗記ものの出題は少ない。また問題の単語をGoogle 検索しても答えに行き着かないケースが多かった。ちゃんと勉強して理解しておくことが大切だ。 また、合格ラインは6

ここ5年ほど、新卒入社した人のメンターになってプログラミング等を教えている。そこでは入社までのプログラミング経験の有無に関わらず、まずこの本をおすすめしている。 リンク サブタイトルに「3年目までに身につけたい」とあるが、正直3年目まででも難しいしと思うし、これまでプログラミングの経験がなく、これから始める人にはもっと難しいと思う。 それでもこの本を勧める理由は、プログラミングはもちろん、エンジニアの職に就くにあたって重要な原理原則がふんだんに書いてあるからだ。 この本は、過去様々な良書で語られてきた重要な要素を一冊にまとめたものだ。その分、要素の中には理解が難しいと感じる点もあるかもしれないが、全体を網羅するには非常にコスパがいい。 全部で7章あるが、はじめに読み込んで覚えるのは第2章まででいい。もっと言うと2.2 DRY と2.7 名前重要だけでもいいから頭に入れてプログラミングを始めてみてほしい。 この本を読むメリット レビューでたくさん指摘されても心が折れにくくなる 最初のうちはレビューでたくさん指摘される。 たくさん指摘されて、直したらまた指摘されてを繰り返すと「私プログラミングに向いてないかも、、、」と心が折れそうになると思う。 メンターも「こういう点に気をつけてみて」と伝えられればいいが、どこが良くないなのか要約して伝えられるとは限らない。 そんなとき、この本で原理原則を知っておくと、この指摘たちはこの原則に反しているから良くないんだと問題が集約される。そうすると対処もしやすくなるし、何もかも駄目なわけじゃないと少し心が軽くなる。 (そして大体の原因はDRY と名前重要に行き着く) 良い行い、悪い行いに名前がついて真似しやすくなる 周囲の先輩で、エンジニアとしての評価が高かったり、スキルが高いと言われているような人はいるだろうか。 そういった人にできるだけ早く近づく方法は、「真似」だ。コードや設計書の書き方、報告の仕方やチームの中での振る舞いを真似する。 まずは形から真似することで、良いポイントが何なのかだんだんと見えてきて、自分のものになっていく。コードの一つ一つや振る舞いから、その根底にある思想、原理原則が見えるよ

シングル家庭では、いかに自由な時間を作り出すか？がポイントになる。仕事、家事、育児に追われて、趣味や自己研鑽の時間が無くなるのは精神衛生上よろしくない。 使えるリソースは大人一人分。家庭維持をプロジェクトに置き換えて考えてみる。プロジェクトでリソース不足が発生しているときどうするか。 既存メンバを育成する まだ娘たちは小学校低学年。すぐの育成は難しい。そもそも子供は学校と遊びがメインタスクだと思う。 不要なタスクを排除する 家庭維持プロジェクトの場合、仕事家事育児のタスクを排除するとプロジェクト全体が悪化する恐れがある。 メンバを追加する 残念ながら、コロナ禍では新規メンバを探すのも容易ではなく、また既存メンバに負荷がかかる恐れもあるので見送る。 自動化する 今回はこの方法を採用する。 何を自動化するか 単発の作業に対して自動化してもコストに見合わないことが多い。繰り返し行う作業に対して自動化する。また例外の多い作業では自動化が上手く働かない。パターン化された作業について自動化する。 仕事家事育児のタスクの中では、比較的パターン化された家事が自動化の対象となる。 家事のどこを自動化するか 検討した結果以下を導入した。 ロボット掃除機 食洗機 ドラム式洗濯乾燥機 長い前置きの割には、よく言われてる新三種の神器だった。しかし、もはやこれなしでは生活できないほど毎日活躍している。 これらが革新的なのは、人間が動かなくていいという点だ。これまでの新製品は、吸引力が何％アップ！や洗浄力！など、既存の性能をいかに向上させるか？に焦点があたっていた。これに対し、新三種の神器は「人間の手間の一部を代替する」という点で、これまでの製品とは一線を画している。 ロボット掃除機 地味なタスクだが、やらないと徐々にプロジェクトを蝕んでいく。そんなタスクを文句も言わずに毎日こなしてくれる掃除屋だ。 おすすめ圧倒的なコスパを誇るAnker Eufyシリーズだ。ロボット掃除機はピンからキリまであるが、Eufy シリーズは比較的